Memitigasi insiden keamanan

Standard

---

Dokumen ini menjelaskan mitigasi umum dan respons terhadap potensi insiden keamanan di cluster dan container Google Kubernetes Engine (GKE).

Dokumen ini ditujukan untuk Spesialis keamanan yang mencari panduan saat merespons insiden keamanan GKE. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise umum.

Saran di Memperkuat keamanan cluster Anda dapat meningkatkan keamanan workload GKE Anda. Namun, insiden keamanan dapat terjadi meskipun tindakan untuk melindungi workload Anda sudah diterapkan.

Mendeteksi insiden

Untuk mendeteksi potensi insiden, sebaiknya Anda menyiapkan proses yang mengumpulkan dan memantau log workload. Kemudian, siapkan pemberitahuan berdasarkan peristiwa tidak normal yang terdeteksi dari log. Pemberitahuan memberi tahu tim keamanan Anda jika sesuatu yang tidak biasa terdeteksi. Tim keamanan Anda kemudian dapat meninjau potensi insiden.

Menghasilkan pemberitahuan dari log

Anda dapat menyesuaikan pemberitahuan berdasarkan metrik atau tindakan tertentu. Misalnya, memberi tahu penggunaan CPU yang tinggi di node GKE dapat mengindikasikan bahwa node tersebut disusupi untuk melakukan penambangan kripto.

Pemberitahuan akan dibuat di tempat Anda menggabungkan log dan metrik. Misalnya, Anda dapat menggunakan Logging Audit GKE dengan pemberitahuan berdasarkan log di Cloud Logging.

Untuk mempelajari selengkapnya tentang kueri yang berhubungan dengan keamanan, lihat dokumentasi Logging Audit.

Merespons insiden keamanan

Setelah Anda diberi tahu tentang suatu insiden, ambil tindakan. Perbaiki kerentanan jika Anda bisa. Jika Anda tidak mengetahui akar masalah kerentanan atau belum menyiapkan perbaikan, terapkan mitigasi.

Mitigasi yang dapat Anda ambil tergantung pada tingkat keparahan insiden dan keyakinan Anda bahwa masalah tersebut telah diidentifikasi.

Panduan ini membahas tindakan yang dapat Anda ambil setelah mendeteksi insiden pada workload yang berjalan di GKE. Dengan meningkatkan urutan tingkat keparahan, Anda dapat:

• Mengambil snapshot disk VM host. Snapshot memungkinkan Anda melakukan beberapa tindakan forensik pada status VM saat anomali terjadi setelah workload di-deploy ulang atau dihapus.

• Memeriksa VM saat workload terus berjalan. Terhubung ke VM host atau container workload dapat memberikan informasi tentang tindakan penyerang. Sebaiknya kurangi akses sebelum memeriksa VM live.

• Men-deploy ulang container. Deploy ulang mengakhiri proses yang sedang berjalan di container yang terpengaruh dan memulai ulang proses tersebut.

• Menghapus workload. Menghapus workload mengakhiri proses yang sedang berjalan di container yang terpengaruh tanpa memulai ulang.

Mitigasi ini dijelaskan di bagian berikut.

Sebelum memulai

Metode yang digunakan dalam topik ini menggunakan informasi berikut:

• Nama Pod yang menurut Anda telah disusupi, atau POD_NAME.
• Nama VM host yang menjalankan container atau Pod, atau NODE_NAME.

Selain itu, sebelum mengambil tindakan apa pun, pertimbangkan apakah akan ada reaksi negatif dari penyerang jika mereka ditemukan. Penyerang dapat memutuskan untuk menghapus data atau menghancurkan workload. Jika risikonya terlalu tinggi, pertimbangkan mitigasi yang lebih drastis seperti menghapus workload sebelum melakukan penyelidikan lebih lanjut.

Mengambil snapshot disk VM

Pembuatan snapshot disk VM memungkinkan penyelidikan forensik setelah workload di-deploy ulang atau dihapus. Snapshot dapat dibuat saat disk dipasang ke instance yang sedang berjalan.

Catatan: Snapshot hanya menangkap status yang ditulis ke disk. Snapshot tidak menangkap konten memori VM.

1. Untuk mengambil snapshot persistent disk, temukan disk yang terpasang ke VM Anda terlebih dahulu. Jalankan perintah berikut dan lihat kolom source:

   gcloud compute instances describe NODE_NAME --zone COMPUTE_ZONE \
       --format="flattened([disks])"
   

2. Cari baris yang berisi disks[NUMBER].source. Outputnya mirip dengan yang berikut ini:

   disks[0].source: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/COMPUTE_ZONE/disks/DISK_NAME
   

   Nama disk adalah bagian dari nama sumber setelah garis miring terakhir. Misalnya, nama disk adalah gke-cluster-pool-1-abcdeffff-zgt8.

3. Untuk menyelesaikan snapshot, jalankan perintah berikut:

   gcloud compute disks snapshot DISK_NAME
   

Untuk mengetahui informasi selengkapnya, lihat Membuat snapshot persistent disk di dokumentasi Compute Engine.

Memeriksa VM saat workload terus berjalan

Perhatian: Pada insiden parah, workload di node atau cluster yang sama juga dapat disusupi. Hal ini dikenal sebagai container escape. Pantau semua workload Anda untuk menemukan perilaku yang tidak normal dan ambil tindakan yang sesuai.

Selain itu, pertimbangkan akses apa yang mungkin dimiliki penyerang sebelum mengambil tindakan. Jika Anda mencurigai container telah disusupi dan khawatir memberi tahu penyerang, Anda dapat terhubung ke container tersebut dan memeriksanya. Pemeriksaan berguna untuk investigasi cepat sebelum mengambil tindakan yang lebih mengganggu. Pemeriksaan juga merupakan pendekatan yang paling tidak mengganggu workload, tetapi tidak menghentikan insiden.

Atau, untuk menghindari logging ke mesin dengan kredensial istimewa, Anda dapat menganalisis workload dengan menyiapkan forensik live (seperti Respons Cepat GRR), agen di node, atau penyaringan jaringan.

Mengurangi akses sebelum memeriksa VM live

Dengan menghalangi, mengosongkan, dan membatasi akses jaringan ke VM yang menghosting container yang disusupi, Anda dapat memisahkan sebagian container yang disusupi dari container lainnya di cluster Anda. Membatasi akses ke VM mengurangi risiko, namun tidak mencegah penyerang bergerak secara lateral di lingkungan Anda jika mereka memanfaatkan kerentanan penting.

Menghalangi node dan mengosongkan workload lain dari node tersebut

Menghalangi dan mengosongkan node akan memindahkan workload yang ditempatkan bersama container yang disusupi ke VM lain di cluster Anda. Penghalangan dan pengosongan mengurangi kemampuan penyerang untuk memengaruhi workload lain di node yang sama. Hal ini tidak selalu mencegah mereka untuk memeriksa status persisten workload (misalnya, dengan memeriksa konten image container).

Perhatian: kubectl cordon menandai node sebagai 'tidak dapat dijadwalkan', yang memiliki efek samping yaitu pengontrol layanan menghapus node dari daftar target node LoadBalancer apa pun yang sebelumnya memenuhi syarat, secara efektif menghapus traffic load balancer yang masuk dari node yang dihalangi. Masalah ini berlaku untuk GKE versi 1.18 dan yang lebih lama.

1. Gunakan kubectl untuk menghalangi node dan memastikan tidak ada Pod lain yang dijadwalkan di node tersebut:

   kubectl cordon NODE_NAME
   

   Perhatian: Pengosongan mengeluarkan workload lain dari node yang sama, yang dapat menyebabkan periode nonaktif. Penggunaan kubectl drain akan mematuhi PodDisruptionBudgets, tetapi menganggap Pod dikonfigurasi agar secara otomatis dibuat ulang di node lain setelah penghapusan.

   Setelah menghalangi node, kosongi node Pod lain.

2. Beri label pada Pod yang dikarantina:

   kubectl label pods POD_NAME quarantine=true
   

   Ganti POD_NAME dengan nama Pod yang ingin Anda karantina.

3. Kosongi node Pod yang tidak diberi label dengan quarantine:

   kubectl drain NODE_NAME --pod-selector='!quarantine'
   

Membatasi akses jaringan ke node

Sebaiknya blokir traffic internal dan eksternal agar tidak mengakses VM host. Selanjutnya, izinkan koneksi masuk dari VM tertentu di jaringan atau VPC Anda untuk terhubung ke VM yang dikarantina.

Langkah pertama adalah mengabaikan VM dari Grup Instance Terkelola yang memilikinya. Mengabaikan VM mencegah node ditandai sebagai tidak responsif dan diperbaiki secara otomatis (dibuat ulang) sebelum investigasi selesai.

Untuk mengabaikan VM, jalankan perintah berikut:

gcloud compute instance-groups managed abandon-instances INSTANCE_GROUP_NAME \
    --instances=NODE_NAME

Membuat firewall VM

Membuat firewall antara container yang terpengaruh dan workload lain di jaringan yang sama membantu mencegah penyerang berpindah ke bagian lain lingkungan saat Anda melakukan analisis lebih lanjut. Karena Anda sudah mengosongkan VM container lain, hal ini hanya memengaruhi container yang dikarantina.

Petunjuk berikut tentang cara membuat VM yang dapat mencegah:

• Koneksi keluar baru ke VM lain di cluster Anda menggunakan aturan traffic keluar.
• Koneksi masuk ke VM yang disusupi menggunakan aturan traffic masuk.

Catatan: Firewall memiliki beberapa keterbatasan.

1. Menambahkan aturan firewall tidak menutup koneksi yang sudah ada. Menghapus alamat IP eksternal VM (dijelaskan di bagian berikut) memutus koneksi yang sudah ada dari internet eksternal, meskipun bukan berasal dari dalam jaringan Anda.
2. Penyerang yang menyusupi container dengan hak istimewa atau keluar dari container tanpa hak istimewa dapat mengakses metadata VM. Sebaiknya gunakan node GKE yang Terlindungi untuk menghapus kunci bootstrap dengan hak istimewa dari server metadata.

Untuk menonaktifkan firewall VM dari instance lainnya, ikuti langkah berikut untuk node yang menghosting Pod yang ingin dikarantina:

1. Beri tag pada instance agar Anda dapat menerapkan aturan firewall baru.

   Catatan: Pastikan tag tidak bertentangan dengan VM lain sebelum menerapkannya.

   gcloud compute instances add-tags NODE_NAME \
       --zone COMPUTE_ZONE \
       --tags quarantine
   

2. Buat aturan firewall untuk menolak semua traffic TCP keluar dari instance yang memiliki tag quarantine:

   gcloud compute firewall-rules create quarantine-egress-deny \
       --network NETWORK_NAME \
       --action deny \
       --direction egress \
       --rules tcp \
       --destination-ranges 0.0.0.0/0 \
       --priority 0 \
       --target-tags quarantine
   

3. Buat aturan firewall untuk menolak semua traffic TCP masuk ke instance dengan tag quarantine. Beri priority dari 1 pada aturan traffic masuk ini, yang memungkinkan Anda menggantinya dengan aturan lain yang mengizinkan SSH dari VM yang ditentukan.

   gcloud compute firewall-rules create quarantine-ingress-deny \
       --network NETWORK_NAME \
       --action deny \
       --direction ingress \
       --rules tcp \
       --source-ranges 0.0.0.0/0 \
       --priority 1 \
       --target-tags quarantine
   

Menghapus alamat IP eksternal VM

Menghapus alamat IP eksternal VM menghentikan koneksi jaringan yang sudah ada di luar VPC Anda.

Untuk menghapus alamat eksternal VM, lakukan langkah berikut:

1. Temukan dan hapus konfigurasi akses yang mengaitkan IP eksternal dengan VM. Pertama-tama, temukan konfigurasi akses dengan menjelaskan VM:

   gcloud compute instances describe NODE_NAME \
       --zone COMPUTE_ZONE --format="flattened([networkInterfaces])"
   

   Cari baris yang berisi name dan natIP. Hal tersebut terlihat seperti ini:

   networkInterfaces[0].accessConfigs[0].name:              ACCESS_CONFIG_NAME
   networkInterfaces[0].accessConfigs[0].natIP:             EXTERNAL_IP_ADDRESS
   

2. Temukan nilai natIP yang cocok dengan IP eksternal yang ingin Anda hapus. Catat nama konfigurasi akses.

3. Untuk menghapus IP eksternal, jalankan perintah berikut:

   gcloud compute instances delete-access-config NODE_NAME \
       --access-config-name "ACCESS_CONFIG_NAME"
   

SSH ke VM host melalui VM perantara

Setelah menghapus IP eksternal VM host, Anda tidak dapat menjalankan ssh dari luar VPC. Anda mengaksesnya dari VM lain di jaringan yang sama. Untuk bagian selanjutnya, kami menyebutnya sebagai VM perantara.

Prasyarat

• VM perantara dengan akses ke subnetwork VM host. Jika Anda belum memilikinya, buat VM untuk tujuan ini.
• Alamat IP internal VM perantara.
• Kunci publik SSH dari VM perantara. Untuk mempelajari lebih lanjut, lihat Mengelola Kunci SSH

Menghubungkan ke VM host

1. Tambahkan kunci publik VM perantara ke VM host. Untuk mengetahui informasi selengkapnya, lihat Menambahkan dan Menghapus kunci SSH di dokumentasi Compute Engine.

2. Tambahkan tag ke VM perantara.

   Catatan: Pastikan tag tersebut tidak bertentangan dengan VM lain di jaringan Anda sebelum menerapkannya.

   gcloud compute instances add-tags INTERMEDIATE_NODE_NAME \
     --zone COMPUTE_ZONE \
     --tags intermediate
   

3. Tambahkan aturan izin traffic masuk untuk mengganti aturan penolakan yang Anda tambahkan sebelumnya. Untuk menambahkan aturan, jalankan perintah berikut.

   gcloud compute firewall-rules create quarantine-ingress-allow \
       --network NETWORK_NAME \
       --action allow \
       --direction ingress \
       --rules tcp:22 \
       --source-tags intermediate \
       --priority 0 \
       --target-tags quarantine
   

   Aturan ini mengizinkan traffic masuk di port 22 (SSH) dari VM di jaringan Anda dengan tag intermediate. Aturan ini menggantikan aturan penolakan dengan priority dari 0.

4. Hubungkan ke VM yang dikarantina menggunakan IP internal:

   ssh -i KEY_PATH USER@QUARANTINED_VM_INTERNAL_IP
   

   Ganti kode berikut:

   • KEY_PATH: jalur ke kunci pribadi SSH Anda.
   • USER: alamat email akun Google Cloud Anda.
   • QUARANTINED_VM_INTERNAL_IP: alamat IP internal.

Men-deploy ulang container

Dengan men-deploy ulang container, Anda memulai salinan baru container tersebut dan menghapus container yang telah disusupi.

Anda men-deploy ulang container dengan menghapus Pod yang menghostingnya. Jika Pod dikelola oleh konstruksi Kubernetes dengan level lebih tinggi (misalnya, Deployment atau DaemonSet), penghapusan Pod akan menjadwalkan Pod baru. Pod ini menjalankan container baru.

Deployment ulang dapat dilakukan jika:

• Anda telah mengetahui penyebab kerentanan.
• Menurut Anda, penyerang memerlukan upaya atau waktu yang signifikan untuk menyusupi container Anda kembali.
• Anda merasa container mungkin segera disusupi lagi dan Anda tidak ingin menanganinya secara offline, jadi Anda berencana untuk menempatkannya di sandbox untuk membatasi dampaknya.

Catatan: Jika Anda memiliki perbaikan untuk kerentanan, luncurkan perbaikan terlebih dahulu, lalu migrasikan traffic ke workload pengganti. Men-deploy ulang Pod tidak memperbaiki masalah keamanan. Penyerang mungkin mengulangi rantai eksploit yang sama. Serangan dapat berlanjut hingga perbaikan diterapkan.

Saat men-deploy ulang workload, jika kemungkinan terjadinya penyusupan lain tinggi, pertimbangkan untuk menempatkan workload di lingkungan sandbox seperti GKE Sandbox. Sandbox membatasi akses ke kernel node host jika penyerang menyusupi container lagi.

Untuk men-deploy ulang container di Kubernetes, hapus Pod yang berisi container:

kubectl delete pods POD_NAME --grace-period=10

Jika container di Pod yang dihapus terus berjalan, Anda dapat menghapus workload.

Untuk men-deploy ulang container dalam sandbox, ikuti petunjuk di Memperkuat isolasi workload dengan GKE Sandbox.

Menghapus workload

Menghapus workload, seperti Deployment atau DaemonSet, menyebabkan semua Pod anggota dihapus. Semua container di dalam Pod tersebut berhenti berjalan. Menghapus workload dapat dilakukan jika:

• Anda ingin menghentikan serangan yang sedang berlangsung.
• Anda bersedia untuk menangani workload secara offline.
• Menghentikan serangan dengan segera lebih penting daripada waktu beroperasi aplikasi atau analisis forensik.

Perhatian: Jika workload dihapus, seluruh aplikasi akan offline.

Untuk menghapus workload, gunakan kubectl delete CONTROLLER_TYPE. Misalnya, untuk menghapus Deployment, jalankan perintah berikut:

kubectl delete deployments DEPLOYMENT

Jika penghapusan workload tidak menghapus semua Pod atau container terkait, Anda dapat menghapus container secara manual menggunakan alat CLI runtime container, biasanya docker. Jika node Anda menjalankan containerd, gunakan crictl.

Catatan: Jika Anda menghapus container secara manual sebelum menghapus workload, Kubernetes men-deploy ulang container tersebut.

Docker

Peringatan: Di GKE versi 1.24 dan yang lebih baru, jenis image node berbasis Docker tidak didukung. Pada GKE versi 1.23, Anda juga tidak dapat membuat node pool baru dengan jenis image node Docker. Anda harus bermigrasi ke jenis image node dalam containerd. Untuk mempelajari perubahan ini lebih lanjut, lihat Tentang penghentian penggunaan image node Docker.

Untuk menghentikan container dalam menggunakan runtime container Docker, Anda dapat menggunakan docker stop atau docker kill.

docker stop menghentikan container dengan mengirimkan sinyal SIGTERM ke proses root, dan menunggu 10 detik hingga proses keluar secara default. Jika proses belum keluar dalam jangka waktu tersebut, proses akan mengirimkan sinyal SIGKILL. Anda dapat menentukan masa tenggang ini dengan opsi --time.

docker stop --time TIME_IN_SECONDS CONTAINER

docker kill adalah metode tercepat untuk menghentikan container. Sinyal SIGKILL langsung dikirim.

docker kill CONTAINER

Anda juga dapat menghentikan dan menghapus container dalam satu perintah dengan docker rm -f:

docker rm -f CONTAINER

containerd

Jika menggunakan runtime containerd di GKE, Anda akan menghentikan atau menghapus container dengan crictl.

Untuk menghentikan container di containerd, jalankan perintah berikut:

crictl stop CONTAINER

Untuk menghapus container di containerd, jalankan perintah berikut:

crictl rm -f CONTAINER

Menghapus VM host

Peringatan: Penghapusan VM menghentikan workload yang ditempatkan bersama di node. Halangi dan kosongi node terlebih dahulu untuk membatasi gangguan.

Jika tidak dapat menghapus container, Anda dapat menghapus mesin virtual yang menghosting container yang terpengaruh.

Jika Pod masih terlihat, Anda dapat menemukan nama VM host dengan perintah berikut:

kubectl get pods --all-namespaces \
  -o=custom-columns=POD_NAME:.metadata.name,INSTANCE_NAME:.spec.nodeName \
  --field-selector=metadata.name=POD_NAME

Untuk menghapus VM host, jalankan perintah gcloud berikut:

gcloud compute instance-groups managed delete-instances INSTANCE_GROUP_NAME \
    --instances=NODE_NAME

Dengan mengabaikan instance dari Grup Instance Terkelola, ukuran grup berkurang menjadi satu VM. Anda dapat menambahkan kembali satu instance ke grup secara manual dengan perintah berikut:

gcloud compute instance-groups managed resize INSTANCE_GROUP_NAME \
    --size=SIZE

Langkah berikutnya

• Melakukan forensik pada container
• Melakukan hardening pada keamanan cluster Anda
• Analisis forensik untuk aplikasi GKE