Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Respon insiden dan forensik
<a name="incident-response-and-forensics"></a>

Kemampuan Anda untuk bereaksi cepat terhadap suatu insiden dapat membantu meminimalkan kerusakan yang disebabkan oleh pelanggaran. Memiliki sistem peringatan yang andal yang dapat memperingatkan Anda tentang perilaku mencurigakan adalah langkah pertama dalam rencana respons insiden yang baik. Ketika sebuah insiden muncul, Anda harus segera memutuskan apakah akan menghancurkan dan mengganti wadah yang terkena dampak, atau mengisolasi dan memeriksa wadah. Jika Anda memilih untuk mengisolasi wadah sebagai bagian dari penyelidikan forensik dan analisis akar penyebab, maka serangkaian kegiatan berikut harus diikuti:

## Contoh rencana respons insiden
<a name="_sample_incident_response_plan"></a>

### Identifikasi Pod yang menyinggung dan node pekerja
<a name="_identify_the_offending_pod_and_worker_node"></a>

Tindakan pertama Anda harus mengisolasi kerusakan. Mulailah dengan mengidentifikasi di mana pelanggaran terjadi dan mengisolasi Pod tersebut dan simpulnya dari infrastruktur lainnya.

### Identifikasi Pod dan node pekerja yang menyinggung menggunakan nama beban kerja
<a name="_identify_the_offending_pods_and_worker_nodes_using_workload_name"></a>

Jika Anda mengetahui nama dan namespace dari pod yang menyinggung, Anda dapat mengidentifikasi node pekerja yang menjalankan pod sebagai berikut:

```
kubectl get pods <name> --namespace <namespace> -o=jsonpath='{.spec.nodeName}{"\n"}'
```

Jika [Sumber Daya Beban Kerja](https://kubernetes.io/docs/concepts/workloads/controllers/) seperti Deployment telah dikompromikan, kemungkinan semua Pod yang merupakan bagian dari sumber daya beban kerja dikompromikan. Gunakan perintah berikut untuk membuat daftar semua pod dari Workload Resource dan node yang sedang dijalankan:

```
selector=$(kubectl get deployments <name> \
 --namespace <namespace> -o json | jq -j \
'.spec.selector.matchLabels | to_entries | .[] | "\(.key)=\(.value)"')

kubectl get pods --namespace <namespace> --selector=$selector \
-o json | jq -r '.items[] | "\(.metadata.name) \(.spec.nodeName)"'
```

Perintah di atas adalah untuk penerapan. Anda dapat menjalankan perintah yang sama untuk sumber daya beban kerja lainnya seperti replicasets,, statefulsets, dll.

### Identifikasi Pod dan node pekerja yang melanggar menggunakan nama akun layanan
<a name="_identify_the_offending_pods_and_worker_nodes_using_service_account_name"></a>

Dalam beberapa kasus, Anda dapat mengidentifikasi bahwa akun layanan disusupi. Kemungkinan pod yang menggunakan akun layanan yang diidentifikasi dikompromikan. Anda dapat mengidentifikasi semua pod menggunakan akun layanan dan node yang dijalankan dengan perintah berikut:

```
kubectl get pods -o json --namespace <namespace> | \
    jq -r '.items[] |
    select(.spec.serviceAccount == "<service account name>") |
    "\(.metadata.name) \(.spec.nodeName)"'
```

### Identifikasi Pod dengan gambar dan node pekerja yang rentan atau disusupi
<a name="_identify_pods_with_vulnerable_or_compromised_images_and_worker_nodes"></a>

Dalam beberapa kasus, Anda mungkin menemukan bahwa image kontainer yang digunakan dalam pod di klaster Anda berbahaya atau disusupi. Gambar kontainer berbahaya atau dikompromikan, jika ditemukan mengandung malware, adalah gambar buruk yang diketahui atau memiliki CVE yang telah dieksploitasi. Anda harus mempertimbangkan semua pod menggunakan image kontainer yang dikompromikan. Anda dapat mengidentifikasi pod menggunakan image dan node yang mereka jalankan dengan perintah berikut:

```
IMAGE=<Name of the malicious/compromised image>

kubectl get pods -o json --all-namespaces | \
    jq -r --arg image "$IMAGE" '.items[] |
    select(.spec.containers[] | .image == $image) |
    "\(.metadata.name) \(.metadata.namespace) \(.spec.nodeName)"'
```

### Mengisolasi Pod dengan membuat Kebijakan Jaringan yang menolak semua lalu lintas masuk dan keluar ke pod
<a name="_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod"></a>

Menyangkal semua aturan lalu lintas dapat membantu menghentikan serangan yang sudah berlangsung dengan memutuskan semua koneksi ke pod. Kebijakan Jaringan berikut akan berlaku untuk pod dengan label`app=web`.

```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  - Egress
```

**penting**  
Kebijakan Jaringan mungkin terbukti tidak efektif jika penyerang telah mendapatkan akses ke host yang mendasarinya. Jika Anda mencurigai hal itu terjadi, Anda dapat menggunakan [AWS Security Groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) untuk mengisolasi host yang disusupi dari host lain. Saat mengubah grup keamanan host, ketahuilah bahwa itu akan memengaruhi semua kontainer yang berjalan di host tersebut.

### Mencabut kredensi keamanan sementara yang ditetapkan ke pod atau node pekerja jika perlu
<a name="_revoke_temporary_security_credentials_assigned_to_the_pod_or_worker_node_if_necessary"></a>

Jika node pekerja telah diberi peran IAM yang memungkinkan Pod mendapatkan akses ke sumber daya AWS lainnya, hapus peran tersebut dari instance untuk mencegah kerusakan lebih lanjut dari serangan. Demikian pula, jika Pod telah diberi peran IAM, evaluasi apakah Anda dapat menghapus kebijakan IAM dari peran dengan aman tanpa memengaruhi beban kerja lainnya.

### Cordon simpul pekerja
<a name="_cordon_the_worker_node"></a>

Dengan menutup node pekerja yang terkena dampak, Anda memberi tahu penjadwal untuk menghindari penjadwalan pod ke node yang terpengaruh. Ini akan memungkinkan Anda untuk menghapus node untuk studi forensik tanpa mengganggu beban kerja lainnya.

**catatan**  
Panduan ini tidak berlaku untuk Fargate di mana setiap pod Fargate berjalan di lingkungan kotak pasirnya sendiri. Alih-alih mengepung, serapkan pod Fargate yang terpengaruh dengan menerapkan kebijakan jaringan yang menyangkal semua lalu lintas masuk dan keluar.

### Aktifkan perlindungan penghentian pada node pekerja yang terkena dampak
<a name="_enable_termination_protection_on_impacted_worker_node"></a>

Seorang penyerang dapat mencoba untuk menghapus kesalahan mereka dengan mengakhiri node yang terpengaruh. Mengaktifkan [perlindungan terminasi](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#Using_ChangingDisableAPITermination) dapat mencegah hal ini terjadi. [Perlindungan skala dalam instance akan melindungi node dari peristiwa scale-in](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html#instance-protection).

**Awas**  
Anda tidak dapat mengaktifkan perlindungan penghentian pada instans Spot.

### Beri label pelanggaran Pod/Node dengan label yang menunjukkan bahwa itu adalah bagian dari penyelidikan aktif
<a name="_label_the_offending_podnode_with_a_label_indicating_that_it_is_part_of_an_active_investigation"></a>

Ini akan berfungsi sebagai peringatan bagi administrator klaster untuk tidak mengutak-atik yang terkena dampak Pods/Nodes sampai penyelidikan selesai.

### Tangkap artefak yang mudah menguap pada node pekerja
<a name="_capture_volatile_artifacts_on_the_worker_node"></a>
+  **Tangkap memori sistem operasi**. Ini akan menangkap daemon Docker (atau runtime kontainer lainnya) dan subprosesnya per kontainer. Ini dapat dicapai dengan menggunakan alat seperti [LiME](https://github.com/504ensicsLabs/LiME) dan [Volatilitas](https://www.volatilityfoundation.org/), atau melalui alat tingkat yang lebih tinggi seperti [Automated Forensics Orchestrator untuk Amazon](https://aws.amazon.com/solutions/implementations/automated-forensics-orchestrator-for-amazon-ec2/) EC2 yang dibangun di atasnya.
+  **Lakukan dump pohon netstat dari proses yang berjalan dan port terbuka**. Ini akan menangkap daemon docker dan subprosesnya per kontainer.
+  **Jalankan perintah untuk menyimpan status tingkat kontainer sebelum bukti diubah**. Anda dapat menggunakan kemampuan runtime kontainer untuk menangkap informasi tentang kontainer yang sedang berjalan. Misalnya, dengan Containerd, Anda dapat melakukan hal berikut:
  +  `crictl ps`untuk proses yang berjalan.
  +  `crictl logs CONTAINER`untuk log yang dimiliki tingkat daemon.

    Hal yang sama dapat dicapai dengan containerd menggunakan [nerdctl CLI](https://github.com/containerd/nerdctl), sebagai pengganti (misalnya). `docker` `nerdctl inspect` Beberapa perintah tambahan tersedia tergantung pada runtime kontainer. Misalnya, Docker `docker diff` harus melihat perubahan pada sistem file kontainer atau `docker checkpoint` untuk menyimpan semua status kontainer termasuk memori volatil (RAM). Lihat [posting blog Kubernetes ini](https://kubernetes.io/blog/2022/12/05/forensic-container-checkpointing-alpha/) untuk diskusi tentang kemampuan serupa dengan runtime containerd atau CRI-O.
+  **Jeda wadah untuk penangkapan forensik**.
+  **Cuplikan volume EBS instans**.

### Menerapkan ulang Pod atau Sumber Daya Beban Kerja yang dikompromikan
<a name="_redeploy_compromised_pod_or_workload_resource"></a>

Setelah mengumpulkan data untuk analisis forensik, Anda dapat menerapkan ulang pod atau sumber daya beban kerja yang dikompromikan.

Pertama-tama luncurkan perbaikan untuk kerentanan yang dikompromikan dan mulai pod pengganti baru. Kemudian hapus pod yang rentan.

Jika pod yang rentan dikelola oleh sumber daya beban kerja Kubernetes tingkat tinggi (misalnya, Deployment atau DaemonSet), menghapusnya akan menjadwalkan yang baru. Jadi pod yang rentan akan diluncurkan lagi. Dalam hal ini, Anda harus menerapkan sumber daya beban kerja pengganti baru setelah memperbaiki kerentanan. Maka Anda harus menghapus beban kerja yang rentan.

## Rekomendasi
<a name="_recommendations"></a>

### Tinjau Whitepaper Respons Insiden Keamanan AWS
<a name="_review_the_aws_security_incident_response_whitepaper"></a>

Meskipun bagian ini memberikan gambaran singkat bersama dengan beberapa rekomendasi untuk menangani dugaan pelanggaran keamanan, topik ini dibahas secara mendalam dalam white paper, [AWS Security](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) Incident Response.

### Berlatih hari permainan keamanan
<a name="_practice_security_game_days"></a>

Bagilah praktisi keamanan Anda menjadi 2 tim: merah dan biru. Tim merah akan fokus pada menyelidiki sistem yang berbeda untuk kerentanan sementara tim biru akan bertanggung jawab untuk bertahan melawan mereka. Jika Anda tidak memiliki cukup praktisi keamanan untuk membuat tim terpisah, pertimbangkan untuk menyewa entitas luar yang memiliki pengetahuan tentang eksploitasi Kubernetes.

 [Kubesploit](https://github.com/cyberark/kubesploit) adalah kerangka pengujian penetrasi CyberArk yang dapat Anda gunakan untuk melakukan hari permainan. Tidak seperti alat lain yang memindai cluster Anda untuk kerentanan, kubesploit mensimulasikan serangan dunia nyata. Ini memberi tim biru Anda kesempatan untuk melatih responsnya terhadap serangan dan mengukur efektivitasnya.

### Jalankan tes penetrasi terhadap cluster Anda
<a name="_run_penetration_tests_against_your_cluster"></a>

Menyerang cluster Anda secara berkala dapat membantu Anda menemukan kerentanan dan kesalahan konfigurasi. Sebelum memulai, ikuti [pedoman pengujian penetrasi](https://aws.amazon.com/security/penetration-testing/) sebelum melakukan tes terhadap cluster Anda.

## Alat dan sumber daya
<a name="_tools_and_resources"></a>
+  [kube-hunter](https://github.com/aquasecurity/kube-hunter), alat pengujian penetrasi untuk Kubernetes.
+  [Gremlin](https://www.gremlin.com/product/#kubernetes), toolkit rekayasa kekacauan yang dapat Anda gunakan untuk mensimulasikan serangan terhadap aplikasi dan infrastruktur Anda.
+  [Menyerang dan Mempertahankan Instalasi Kubernetes](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2019/findings/AtredisPartners_Attacking_Kubernetes-v1.0.pdf) 
+  [kubesploit](https://www.cyberark.com/resources/threat-research-blog/kubesploit-a-new-offensive-tool-for-testing-containerized-environments) 
+  [NeuVector oleh SUSE](https://www.suse.com/neuvector/) open source, platform keamanan wadah tanpa kepercayaan, menyediakan pelaporan kerentanan dan risiko serta pemberitahuan peristiwa keamanan
+  [Ancaman Persisten Tingkat Lanjut](https://www.youtube.com/watch?v=CH7S5rE3j8w) 
+  [Serangan dan Pertahanan Praktis Kubernetes](https://www.youtube.com/watch?v=LtCx3zZpOfs) 
+  [Mengkompromikan Cluster Kubernetes dengan Memanfaatkan Izin RBAC](https://www.youtube.com/watch?v=1LMo0CftVC4)