Senarai Semak Pengerasan Keselamatan GCP untuk Pasukan Kecil dan Sederhana

Laluan ancaman GCP yang biasa

Kebanyakan insiden awan bermula dengan jurang kecil dalam pemilikan atau konfigurasi. Cari laluan ini sebelum penyerang menemuinya.

• Pengguna, akaun perkhidmatan atau identiti beban kerja yang mempunyai kebenaran berlebihan boleh menukar satu bukti kelayakan yang dicuri menjadi akses luas merentas projek.
• Titik akhir pengurusan yang terdedah, port nyahpepijat atau peraturan tembok api yang terlalu longgar boleh memintas setiap kawalan yang direka untuk trafik aplikasi biasa.
• Baldi storan awam atau URL bertandatangan yang terlalu luas boleh mendedahkan data pelanggan tanpa kompromi aplikasi yang boleh dilihat.
• Beban kerja yang lapuk menimbulkan risiko berpanjangan apabila imej lama, ruang nama yang terlupa, akaun perkhidmatan yang tidak digunakan dan sumber tanpa pemilik masih boleh dikerahkan.
• Bukti audit yang tiada atau disimpan untuk tempoh singkat menyukarkan anda mengenal pasti siapa yang mengubah dasar, bila akses bermula dan data mana yang telah dicapai.
• Sandaran yang belum diuji hanyalah harapan. Kegagalan pemulihan, pengekalan yang tidak lengkap dan kunci penyulitan yang tidak boleh diakses boleh mengubah peristiwa keselamatan menjadi kehilangan kekal.

Identiti dan akses

Anggap identiti sebagai satah kawalan utama. Setiap manusia, proses automasi dan beban kerja harus mempunyai identiti tersendiri dengan tujuan yang terhad.

Jadikan sempadan sumber jelas

Gunakan organisasi dan folder untuk pagar keselamatan, dan pisahkan pembangunan, pementasan dan pengeluaran ke dalam projek atau sempadan kepercayaan yang lebih kukuh. Terapkan dasar organisasi pada tahap tertinggi yang praktikal, hadkan penggunaan perkhidmatan dan elakkan berkongsi projek pengeluaran merentas produk yang tidak berkaitan.

Berikan peranan minimum pada skop yang paling sempit

Utamakan peranan yang dipratentukan atau tersuai berbanding peranan primitif yang luas, berikannya kepada kumpulan dan identiti beban kerja, dan gunakan syarat IAM apabila nama sumber atau teg boleh menyempitkan akses. Semak kebenaran yang tidak digunakan dan alih keluar akses pengeluaran tetap yang sepatutnya hanya tersedia melalui proses akses kecemasan (break-glass).

Alih keluar bukti kelayakan jangka panjang

Gunakan Workload Identity Federation for GKE supaya pod menerima bukti kelayakan jangka pendek tanpa kunci akaun perkhidmatan yang dieksport. Sekat penciptaan dan muat naik kunci dengan dasar organisasi jika boleh, buat inventori sebarang kunci yang tinggal dan cetuskan makluman bagi perubahan IAM berisiko tinggi dalam Cloud Audit Logs.

Rangkaian dan tepi

Anggapkan bahawa beberapa kecacatan aplikasi akhirnya boleh dicapai dari rangkaian. Hadkan apa yang kecacatan itu boleh akses.

Mulakan dengan tolak semua, kemudian tambah laluan yang dinamakan

Gunakan peraturan tembok api VPC berkeistimewaan minimum dan NetworkPolicies Kubernetes untuk trafik pod. Asingkan persekitaran ke dalam rangkaian yang berbeza, dokumentasikan setiap laluan ingress dan alih keluar peraturan nyahpepijat yang luas yang membenarkan port pengurusan atau semua protokol daripada julat alamat yang besar.

Pastikan nod dan satah kawalan kekal peribadi

Lumpuhkan alamat IP luaran pada nod GKE. Utamakan titik akhir satah kawalan peribadi berasaskan DNS, dan apabila titik akhir IP tidak dapat dielakkan, hadkannya dengan rangkaian yang diberi kuasa. Berikan beban kerja laluan keluar (egress) yang disengajakan dan bukannya akses internet yang luas.

Terbitkan hanya perkhidmatan awam yang disengajakan

Dedahkan aplikasi melalui gateway atau pengimbang beban yang telah disemak, bukan melalui alamat pod atau nod yang kebetulan terdedah. Lakukan penamatan TLS menggunakan sijil terurus, hadkan hos dan laluan ingress, kenakan had permintaan dan had kadar, dan letakkan antara muka pentadbiran di sebalik akses berasaskan identiti.

Data dan rahsia

Lindungi data dalam simpanan, dalam transit dan semasa digunakan, kemudian buktikan bahawa anda boleh memulihkannya. Penemuan data adalah sebahagian daripada kawalan.

Cegah akses awam secara tidak sengaja

Kuatkuasakan pencegahan akses awam dan akses peringkat baldi seragam pada Cloud Storage. Klasifikasikan baldi mengikut kepekaan, hadkan akses objek dan kunci, dayakan pengelogan untuk data bernilai tinggi dan gunakan kunci penyulitan yang diurus pelanggan apabila model risiko atau pematuhan anda memerlukannya.

Jauhkan rahsia daripada imej dan kod sumber

Simpan bukti kelayakan dalam Secret Manager dan berikan akses kepada identiti beban kerja dan versi rahsia yang tertentu. Putar rahsia secara terancang, elakkan menyalinnya ke dalam Git atau imej kontena, dan jangan anggap Kubernetes Secrets biasa sebagai sempadan perlindungan yang lengkap.

Uji pemulihan, bukan sekadar penciptaan sandaran

Tentukan sasaran titik pemulihan dan masa pemulihan (RPO/RTO), simpan salinan di luar domain kegagalan pengeluaran, dan lindungi akses kepada sandaran dan kunci penyulitan daripada identiti beban kerja. Pulihkan ke persekitaran terpencil mengikut jadual, sahkan data dan rekodkan masa yang diambil serta sebarang langkah manual.

Pengerasan GKE

GKE melindungi satah kawalan terurus, tetapi konfigurasi kluster, ruang nama, dasar kawalan kemasukan (admission) dan beban kerja anda kekal di bawah tadbir urus anda.

Jadikan ruang nama sebagai kontrak pengasingan

Asingkan pasukan dan persekitaran ke dalam ruang nama atau kluster, ikat peranan Kubernetes RBAC yang sempit di sana dan gunakan kuota sumber serta NetworkPolicies. Elakkan akses tulis seluruh kluster untuk penghantaran aplikasi dan berikan setiap beban kerja akaun perkhidmatannya sendiri apabila ia memerlukan identiti tersendiri.

Benarkan hanya imej dan konfigurasi yang anda percayai

Kuatkuasakan standard Pod Security terhad (restricted) atau peraturan Policy Controller yang setara. Kerahkan imej menggunakan digest yang tidak boleh diubah, imbasnya untuk mengesan kerentanan, gunakan Binary Authorization apabila asal usul imej penting, dan tolak akses hos yang tidak dijangka, peningkatan keistimewaan serta pengikatan cluster-admin.

Alih keluar kuasa kontena yang tidak perlu

Jalankan sebagai pengguna bukan root, gugurkan keupayaan Linux, gunakan sistem fail root baca sahaja jika boleh, dan gunakan profil seccomp RuntimeDefault. Jangan lekapkan token akaun perkhidmatan tanpa keperluan, elakkan mod berkeistimewaan dan ruang nama hos, kekalkan keizinan akaun perkhidmatan nod pada tahap minimum dan gunakan Shielded Nodes serta Container-Optimized OS.

Pengesanan dan pemulihan

Kawalan boleh gagal. Bergantunglah pada bukti dan tindakan yang telah dilatih, bukan pada keyakinan bahawa tiada siapa yang melakukan kesilapan.

Kumpul bukti yang anda perlukan

Simpan Cloud Audit Logs serta log sistem dan beban kerja GKE di destinasi berpusat dengan tempoh pengekalan yang sepadan dengan keperluan penyiasatan anda. Dayakan log audit Akses Data secara selektif untuk data sensitif, hadkan akses kepada log dan rekodkan perubahan pentadbiran pada IAM, tembok api, storan dan konfigurasi kluster.

Cetuskan makluman bagi perubahan yang memberi kesan keselamatan

Cetuskan makluman bagi pendedahan storan awam, perubahan tembok api atau IAM yang luas, kunci akaun perkhidmatan yang tidak dijangka, penolakan kawalan kemasukan, pendedahan satah kawalan, kegagalan pengesahan berulang, pengelogan yang dilumpuhkan, sandaran yang gagal dan sijil yang hampir tamat tempoh. Halakan setiap makluman kepada pemilik beserta langkah untuk mengesahkan atau menolaknya.

Latih tubi tindak balas

Tulis runbook ringkas untuk bukti kelayakan yang bocor, data yang terdedah kepada awam, beban kerja yang terjejas serta rantau atau projek yang hilang. Nyatakan siapa yang boleh membenarkan pembendungan, cara membatalkan akses, cara memelihara bukti dan cara memulihkan perkhidmatan. Uji runbook bersama orang yang akan menggunakannya.

Senarai semak 30, 60, dan 90 hari yang diutamakan

Jika anda bermula daripada garis dasar yang tidak lengkap, susun kerja supaya pendedahan dikurangkan dahulu dan semakan seterusnya boleh diulang.

Hari 1 hingga 30: hentikan laluan yang jelas

Buat inventori projek dan pemilik, alih keluar bukti kelayakan yang tidak digunakan dan jangka panjang, sahkan pengelogan audit, sekat baldi awam, semak peraturan tembok api dan pemberian IAM yang paling luas, kenal pasti jurang sandaran pengeluaran dan betulkan sebarang titik akhir awam yang tiada pemilik. Tetapkan pemilik dan tarikh akhir bagi setiap penemuan.

Hari 31 hingga 60: jadikan garis dasar boleh diulang

Pindahkan konfigurasi rangkaian, identiti dan beban kerja ke dalam infrastruktur sebagai kod yang disemak dan penghantaran GitOps. Terima pakai Workload Identity, nod peribadi, Pod Security terhad, semakan imej dipercayai, log berpusat dan makluman bagi perubahan yang paling penting.

Hari 61 hingga 90: buktikan dan pertahankannya

Jalankan ujian pemulihan dan latihan simulasi insiden (tabletop), semak akses berkeistimewaan dan tamat tempoh pengecualian, imbas imej dan kebergantungan sekali lagi, sahkan bahawa pemilik menerima makluman dan ukur jurang yang masih ada. Letakkan semakan ini pada kitaran semakan berkala sebelum bukti menjadi lapuk.

Gunakan senarai semak ini sebagai titik permulaan. Snow Tree boleh menerapkan garis dasar ini melalui operasi platform terurus atau penglibatan perundingan yang berfokus.

Platform terurus · Perundingan

Rujukan rasmi

Gunakan panduan semasa Google sebagai sumber kebenaran teknikal apabila tetapan lalai platform atau keupayaan produk berubah.

• Google Cloud: Amalan terbaik untuk pengerasan kluster GKE anda
• Google Cloud: Amalan terbaik keselamatan GKE