Daftar Periksa Penguatan Keamanan GCP untuk Tim Kecil dan Menengah

Jalur ancaman umum di GCP

Sebagian besar insiden cloud dimulai dengan kesenjangan kepemilikan atau konfigurasi yang kecil. Carilah jalur ini sebelum penyerang melakukannya.

• Pengguna, akun layanan, atau identitas beban kerja dengan izin berlebih dapat mengubah satu kredensial yang dicuri menjadi akses luas di seluruh proyek.
• Titik akhir manajemen yang terekspos, port debug, atau aturan firewall permisif dapat melewati setiap kontrol yang dirancang untuk lalu lintas aplikasi normal.
• Bucket penyimpanan publik atau URL bertanda tangan yang terlalu luas dapat membocorkan data pelanggan tanpa adanya tanda pembobolan aplikasi yang terlihat.
• Beban kerja usang menimbulkan risiko jangka panjang ketika image lama, namespace yang terlupakan, akun layanan yang tidak digunakan, dan sumber daya tanpa pemilik tetap dapat di-deploy.
• Bukti audit yang tidak ada atau hanya disimpan sebentar menyulitkan identifikasi siapa yang mengubah kebijakan, kapan akses dimulai, dan data mana yang berhasil dijangkau.
• Cadangan yang belum diuji hanyalah sebuah harapan. Kegagalan pemulihan, retensi yang tidak lengkap, dan kunci enkripsi yang tidak dapat diakses dapat mengubah peristiwa keamanan menjadi kerugian permanen.

Identitas dan akses

Perlakukan identitas sebagai bidang kontrol utama. Setiap manusia, proses otomatisasi, dan beban kerja harus memiliki identitas tersendiri dengan tujuan yang terbatas.

Jadikan batas sumber daya eksplisit

Gunakan organisasi dan folder sebagai pagar pembatas, dan pisahkan pengembangan, staging, dan produksi ke dalam proyek atau batas kepercayaan yang lebih kuat. Terapkan kebijakan organisasi pada tingkat tertinggi yang praktis, batasi penggunaan layanan, dan hindari berbagi proyek produksi antarproduk yang tidak terkait.

Berikan peran minimum pada cakupan yang paling sempit

Utamakan peran bawaan atau peran khusus daripada peran dasar yang luas, berikan peran tersebut kepada grup dan identitas beban kerja, dan gunakan kondisi IAM jika nama atau tag sumber daya dapat mempersempit akses. Tinjau izin yang tidak digunakan dan hapus akses produksi permanen yang seharusnya hanya tersedia melalui proses akses darurat (break-glass).

Hapus kredensial yang berumur panjang

Gunakan Workload Identity Federation for GKE agar pod menerima kredensial berumur pendek tanpa kunci akun layanan yang diekspor. Blokir pembuatan dan pengunggahan kunci dengan kebijakan organisasi jika memungkinkan, inventarisasi kunci yang tersisa, dan kirim peringatan untuk perubahan IAM berisiko tinggi di Cloud Audit Logs.

Jaringan dan tepi

Asumsikan bahwa beberapa cacat aplikasi pada akhirnya dapat dijangkau dari jaringan. Batasi apa yang dapat diakses oleh cacat tersebut.

Mulai dari menolak semua, lalu tambahkan jalur yang ditetapkan secara eksplisit

Gunakan aturan firewall VPC dengan hak akses minimum dan NetworkPolicy Kubernetes untuk lalu lintas pod. Pisahkan lingkungan ke dalam jaringan yang berbeda, dokumentasikan setiap jalur ingress, dan hapus aturan debug yang luas yang mengizinkan port manajemen atau semua protokol dari rentang alamat yang besar.

Jadikan node dan bidang kontrol privat

Nonaktifkan alamat IP eksternal pada node GKE. Utamakan titik akhir bidang kontrol privat berbasis DNS, dan jika titik akhir IP tidak dapat dihindari, batasi dengan jaringan yang diizinkan. Berikan beban kerja jalur egress yang dirancang secara sengaja, bukan akses internet yang luas.

Publikasikan hanya layanan publik yang disengaja

Ekspos aplikasi melalui gateway atau load balancer yang telah ditinjau, bukan melalui alamat pod atau node yang kebetulan tersedia. Lakukan terminasi TLS dengan sertifikat terkelola, batasi host dan jalur ingress, terapkan batas permintaan dan batas laju, dan tempatkan antarmuka administrasi di balik akses berbasis identitas.

Data dan rahasia

Lindungi data saat disimpan, saat transit, dan saat digunakan, lalu buktikan bahwa Anda dapat memulihkannya. Penemuan data adalah bagian dari kontrol.

Cegah akses publik yang tidak disengaja

Terapkan pencegahan akses publik dan akses level bucket yang seragam di Cloud Storage. Klasifikasikan bucket berdasarkan sensitivitas, batasi akses ke objek dan kunci, aktifkan logging untuk data bernilai tinggi, dan gunakan kunci enkripsi yang dikelola pelanggan jika model risiko atau kepatuhan Anda mengharuskannya.

Jauhkan rahasia dari image dan kode sumber

Simpan kredensial di Secret Manager dan berikan akses ke identitas beban kerja tertentu dan versi secret tertentu. Rotasikan secret secara terencana, hindari menyalinnya ke Git atau image container, dan jangan anggap Kubernetes Secrets biasa sebagai batas perlindungan yang lengkap.

Uji pemulihan, bukan hanya pembuatan cadangan

Tentukan target titik pemulihan dan waktu pemulihan (RPO/RTO), simpan salinan di luar domain kegagalan produksi, dan lindungi akses ke cadangan dan kunci enkripsi dari identitas beban kerja. Lakukan pemulihan ke lingkungan terisolasi secara terjadwal, verifikasi data, dan catat waktu yang dibutuhkan serta setiap langkah manual.

Penguatan GKE

GKE mengamankan bidang kontrol terkelola, tetapi konfigurasi klaster, namespace, kebijakan admission, dan beban kerja Anda tetap menjadi tanggung jawab Anda untuk dikelola.

Jadikan namespace sebagai kontrak isolasi

Pisahkan tim dan lingkungan ke dalam namespace atau klaster, ikat peran Kubernetes RBAC yang sempit di sana, dan terapkan kuota sumber daya serta NetworkPolicy. Hindari akses tulis di seluruh klaster untuk pengiriman aplikasi, dan berikan setiap beban kerja akun layanannya sendiri saat memerlukan identitas tersendiri.

Hanya izinkan image dan konfigurasi yang Anda percayai

Terapkan standar Pod Security restricted atau aturan Policy Controller yang setara. Deploy image berdasarkan digest yang tidak dapat diubah, pindai image untuk menemukan kerentanan, gunakan Binary Authorization jika asal-usul image penting, dan tolak akses host yang tidak terduga, eskalasi hak istimewa, serta binding cluster-admin.

Hapus otoritas container yang tidak diperlukan

Jalankan sebagai non-root, lepaskan capability Linux, gunakan sistem file root read-only jika memungkinkan, dan terapkan profil seccomp RuntimeDefault. Jangan me-mount token akun layanan tanpa kebutuhan, hindari container privileged dan namespace host, batasi akun layanan node seminimal mungkin, dan gunakan Shielded Nodes serta Container-Optimized OS.

Deteksi dan pemulihan

Kontrol bisa gagal. Andalkan bukti dan tindakan yang telah dilatih, bukan keyakinan bahwa tidak ada yang melakukan kesalahan.

Kumpulkan bukti yang Anda perlukan

Simpan Cloud Audit Logs serta log sistem dan beban kerja GKE di tujuan terpusat dengan retensi yang sesuai dengan kebutuhan investigasi Anda. Aktifkan log audit Akses Data secara selektif untuk data sensitif, batasi akses ke log, dan catat perubahan administratif pada IAM, firewall, penyimpanan, dan konfigurasi klaster.

Kirim peringatan untuk perubahan yang berdampak pada keamanan

Kirim peringatan untuk paparan penyimpanan publik, perubahan firewall atau IAM yang luas, kunci akun layanan yang tidak terduga, penolakan admission, paparan bidang kontrol, kegagalan autentikasi berulang, logging yang dinonaktifkan, pencadangan yang gagal, dan sertifikat yang akan kedaluwarsa. Arahkan setiap peringatan ke pemiliknya beserta langkah-langkah untuk mengonfirmasi atau menolaknya.

Latih respons Anda

Tulis runbook singkat untuk kredensial yang bocor, data yang terekspos ke publik, beban kerja yang disusupi, serta region atau proyek yang hilang. Cantumkan siapa yang berwenang menyetujui tindakan penahanan, cara mencabut akses, cara menjaga bukti, dan cara memulihkan layanan. Uji runbook bersama orang-orang yang akan menggunakannya.

Daftar periksa 30, 60, dan 90 hari yang diprioritaskan

Jika Anda memulai dari garis dasar yang tidak lengkap, urutkan pekerjaan untuk mengurangi paparan terlebih dahulu dan buat tinjauan selanjutnya dapat diulangi.

Hari 1 hingga 30: hentikan jalur yang sudah jelas

Inventarisasi proyek dan pemiliknya, hapus kredensial yang tidak terpakai dan berumur panjang, pastikan logging audit aktif, blokir bucket publik, tinjau aturan firewall dan pemberian izin IAM yang paling luas, identifikasi celah pencadangan produksi, dan perbaiki setiap titik akhir publik tanpa pemilik. Tetapkan pemilik dan tenggat waktu untuk setiap temuan.

Hari 31 hingga 60: buat garis dasar dapat diulang

Pindahkan konfigurasi jaringan, identitas, dan beban kerja ke infrastruktur sebagai kode (IaC) yang ditinjau dan pengiriman GitOps. Terapkan Workload Identity, node privat, Pod Security restricted, pemeriksaan image tepercaya, log terpusat, dan peringatan untuk perubahan yang paling penting.

Hari 61 hingga 90: buktikan dan pertahankan

Jalankan pengujian pemulihan dan latihan tabletop insiden, tinjau akses istimewa dan masa berlaku pengecualian, pindai ulang image dan dependensi, verifikasi bahwa pemilik menerima peringatan, dan ukur celah yang tersisa. Jadwalkan pemeriksaan dalam siklus peninjauan berkala sebelum bukti menjadi usang.

Gunakan daftar periksa ini sebagai titik awal. Snow Tree dapat menerapkan garis dasar ini melalui operasi platform terkelola atau layanan konsultasi yang terfokus.

Platform terkelola · Konsultasi

Referensi resmi

Gunakan panduan Google terkini sebagai sumber kebenaran teknis ketika default platform atau kemampuan produk berubah.

• Google Cloud: Praktik terbaik untuk penguatan klaster GKE Anda
• Google Cloud: Praktik terbaik keamanan GKE