Memitigasi OWASP Top 10:2025 di Google Cloud

Dokumen ini mengidentifikasi layanan dan strategi mitigasi yang dapat membantu Anda bertahan dari serangan tingkat aplikasi yang dijelaskan dalam OWASP Top 10:2025. Google Cloud Dibuat oleh Open Web Application Security (OWASP) Foundation, OWASP Top 10:2025 adalah daftar 10 risiko keamanan teratas dalam siklus proses pengembangan software (SDLC). Meskipun tidak ada layanan yang dapat menjamin perlindungan penuh terhadap risiko ini, penerapan layanan ini, jika relevan dalam arsitektur Anda, dapat menjadi solusi keamanan multi-lapisan yang kuat.

Infrastruktur Google dirancang untuk membantu Anda membangun, men-deploy, dan mengoperasikan layanan dengan kontrol keamanan yang kuat. Keamanan fisik dan operasional, enkripsi data saat nonaktif dan saat transit, serta banyak perlindungan infrastruktur mendasar lainnya dikelola oleh Google. Anda akan mewarisi manfaat ini dengan men-deploy aplikasi Anda ke Google Cloud, tetapi Anda mungkin perlu melakukan tindakan tambahan untuk membantu melindungi aplikasi Anda dari serangan tertentu.

Matriks kepatuhan

Layanan Google Cloud yang tercantum dalam tabel berikut dapat membantu melindungi dari 10 risiko keamanan teratas yang diidentifikasi oleh OWASP Top 10:2025:

Kategori OWASP Top 10:2025 Kontrol Primer Google Cloud dan Wiz

A01: Broken Access Control

Access Context Manager, Agent Gateway, Agent Identity, Apigee, Google Cloud Armor, Firebase App Check, Firebase Security Rules, Cloud Next Generation Firewall (Cloud NGFW), Identity-Aware Proxy (IAP), Identity and Access Management (IAM), Organization Policy Service, VPC Service Controls, Wiz Cloud

A02: Miskonfigurasi Keamanan

Access Context Manager, Cloud Asset Inventory, Google Security Operations, Organization Policy, Security Command Center Premium, VPC Service Controls, Wiz Cloud

A03: Kegagalan Supply Chain Software

Artifact Registry, Assured Open Source Software (Assured OSS), Binary Authorization, Cloud Build, Cloud Deploy, Cloud Workstations, CodeMender, Wiz Code

A04: Kegagalan Kriptografi

Apigee, Certificate Authority Service, Certificate Manager, Cloud Key Management Service, Cloud Load Balancing, Cloud Workstations, Confidential Computing, Organization Policy, Secret Manager, Sensitive Data Protection, Wiz Cloud

A05: Injeksi

Apigee, Cloud Armor, CodeMender, Firebase Security Rules, Cloud Next Generation Firewall (Cloud NGFW), Model Armor, Security Command Center Premium, VirusTotal, Wiz Code

A06: Desain yang Tidak Aman (Insecure Design)

Apigee, CodeMender, Mandiant, Wiz Cloud

A07: Kegagalan Autentikasi

Access Context Manager, Agent Identity, Apigee, Cloud Armor, Cloud Identity, Firebase App Check, Firebase Authentication, Google Cloud Fraud Defense, IAM (Privileged Access Manager, Workload Identity Federation, dan Workforce Identity Federation), IAP, Identity Platform, Security Command Center Premium, Secret Manager, Titan Security Keys, Wiz Code

A08: Kegagalan Integritas Software atau Data

Analisis Artefak, Assured OSS, Otorisasi Biner, Cloud Armor, Cloud Build, Cloud Deploy, Firebase App Check, Security Command Center Premium, VirusTotal, Wiz Defend

A09: Kegagalan Logging & Pemberitahuan Keamanan

Persetujuan Akses dan Transparansi Akses, Apigee, Google SecOps, Cloud Logging, Cloud Monitoring, Sensitive Data Protection, Wiz Defend

A10: Penanganan Kondisi Pengecualian yang Salah

Cloud Armor, Cloud Load Balancing, Error Reporting, Model Armor

Google Cloud layanan

Bagian berikut menjelaskan praktik terbaik 10 besar OWASP untuk layanan intiGoogle Cloud .

Persetujuan Akses dan Transparansi Akses

Transparansi Akses dan Persetujuan Akses memungkinkan verifikasi akses penyedia cloud. Dengan menggunakan Transparansi Akses, Anda dapat mencatat alasan untuk setiap akses yang dilakukan oleh staf Google. Persetujuan Akses memungkinkan Anda menyetujui atau menolak permintaan akses oleh personel Google yang bekerja untuk mendukung layanan Anda.

Berlaku untuk A09: Kegagalan Logging & Pemberitahuan Keamanan.

Tinjau praktik terbaik berikut:

  • Mengotomatiskan proses persetujuan akses. Untuk melakukannya, konfigurasi Access Approval untuk mengirim metadata permintaan persetujuan akses masuk ke topik Pub/Sub. Buat langganan Pub/Sub yang mengirimkan payload JSON ke endpoint webhook kustom Anda (seperti layanan Cloud Run yang diautentikasi, fungsi Cloud Run, atau gateway API perusahaan) untuk diproses.
  • Perlakukan log Transparansi Akses sebagai telemetri keamanan penting. Buat metrik berbasis log dan kebijakan pemberitahuan di Monitoring untuk menandai pusat operasi keamanan (SecOps) Anda jika personel Google mengakses resource sensitif tanpa tiket dukungan yang aktif dan sesuai.
  • Mengekspor log Transparansi Akses secara langsung ke Google SecOps atau SIEM perusahaan terpusat Anda.
  • Buat kebijakan kepatuhan untuk mengaudit aliran log Anda secara rutin dan memverifikasi bahwa peristiwa akses darurat berkorelasi dengan insiden berat yang didokumentasikan.auto_approved
  • Untuk kontrol kriptografi, gunakan Key Access Justifications untuk memaksa sistem meminta persetujuan dekripsi kunci secara terprogram.

Access Context Manager

Access Context Manager adalah mesin akses kontekstual Google Cloud. Dengan Access Context Manager, Anda dapat menentukan tingkat akses berbasis atribut (seperti rentang alamat IP klien, postur keamanan perangkat, dan lokasi geografis) untuk IAP, Kontrol Layanan VPC, dan IAM.

Berlaku untuk hal berikut:

  • A01: Kontrol Akses yang Rusak
  • A02: Kesalahan Konfigurasi Keamanan
  • A07: Kegagalan Autentikasi

Tinjau praktik terbaik berikut untuk A01: Kontrol Akses yang Rusak:

  • Buat tingkat keamanan bertingkat yang dapat digunakan kembali untuk kebijakan akses organisasi Anda. Buat tingkat akses dasar untuk menguji atribut standar. Untuk kondisi multi-faktor yang kompleks, deploy tingkat akses kustom untuk mengevaluasi status perangkat lanjutan dan sinyal endpoint pihak ketiga.
  • Gunakan Verifikasi Endpoint atau Chrome Enterprise Core untuk menerapkan batasan tingkat perangkat seperti enkripsi disk penuh, kunci layar aktif, dan versi sistem operasi yang disetujui.
  • Untuk membantu melindungi repositori data bernilai tinggi dengan Kontrol Layanan VPC, tambahkan tingkat akses ke aturan masuk Kontrol Layanan VPC Anda. Jika kunci akun layanan bocor, penyerang tidak dapat menggunakan kunci tersebut saja untuk membuat kueri BigQuery atau Cloud Storage dari alamat IP publik yang tidak sah atau mesin yang tidak tepercaya.
  • Untuk memperluas perlindungan zero-trust ke aplikasi web dan tunnel administratif VM, lampirkan tingkat akses langsung ke resource yang diamankan IAP.

Tinjau praktik terbaik berikut untuk A02: Kesalahan Konfigurasi Keamanan:

  • Terapkan kebijakan akses tercakup yang terikat ke folder tertentu untuk mendelegasikan pengelolaan kebijakan lokal kepada setiap tim project dan mengisolasi perubahannya dari seluruh organisasi.
  • Untuk mencegah aturan ingress yang tidak memiliki induk menjadi pintu belakang yang tidak terdeteksi, tinjau dan hapus secara rutin rentang IP yang dinonaktifkan, subnet partner yang sudah tidak berlaku, dan atribut perangkat yang sudah tidak berlaku.

Tinjau praktik terbaik berikut untuk A07: Kegagalan Autentikasi:

  • Gunakan binding akses pengguna untuk menetapkan durasi sesi maksimum yang ketat. Konfigurasi kebijakan autentikasi ulang untuk mewajibkan SECURITY_KEY (FIDO2 atau WebAuthn). Untuk menerapkan batasan yang lebih ketat pada lingkungan berisiko tinggi, konfigurasikan scopedAccessSettings untuk menggantikan durasi sesi default untuk aplikasi sensitif.

Agent Gateway dan Agent Identity

Agent Gateway dan Agent Identity menyediakan penerapan kebijakan jaringan khusus, pengelolaan siklus proses identitas, dan autentikasi kriptografis untuk agen AI dan alur kerja agentic.

Berlaku untuk hal berikut:

  • A01: Kontrol Akses yang Rusak
  • A07: Kegagalan Autentikasi

Tinjau praktik terbaik berikut untuk A01: Kontrol Akses yang Rusak:

  • Di lingkungan dengan sistem multi-agen, alat MCP eksternal, atau pipeline otonom, gunakan Agent Gateway sebagai titik penerapan jaringan dan kebijakan khusus untuk membantu memitigasi kegagalan kontrol akses agentic.
  • Konfigurasi kebijakan otorisasi terperinciuntuk identitas agen guna membatasi akses alat dan pengambilan data hanya ke resource yang diperlukan untuk alur kerja spesifik agen.

Tinjau praktik terbaik berikut untuk A07: Kegagalan Autentikasi:

  • Untuk mengautentikasi integrasi alat dan agen otonom tanpa menyematkan kunci API atau sandi statis, buat dan tetapkan Identitas Agen ke setiap agen.
  • Konfigurasi Identitas Agen untuk menerbitkan sertifikat X.509 sebagai kredensial agen. Sertifikat ini membantu mencegah pencurian token sehingga jika token akses dicegat, token tersebut tidak dapat digunakan dari lingkungan lain.

Apigee

Apigee menyediakan mekanisme tingkat gateway yang terpusat menggunakan proxy API untuk menerapkan standar kriptografi, memvalidasi payload yang ditandatangani, dan mengenkripsi data dalam pengiriman dan saat istirahat. Dengan bertindak sebagai gateway proxy terbalik untuk traffic API, Apigee menjalankan pemeriksaan batas dan struktur untuk membantu memvalidasi payload. Apigee menyediakan kebijakan autentikasi API, OAuth, dan verifikasi Token Web JSON (JWT) bawaan untuk menetapkan batas identitas yang kuat. Apigee mencakup beberapa cara untuk melakukan logging, pemantauan, penanganan error, dan logging audit.

Berlaku untuk hal berikut:

  • A01: Kontrol Akses yang Rusak
  • A04: Kegagalan Kriptografi
  • A05: Injeksi
  • A06: Desain yang Tidak Aman
  • A07: Kegagalan Autentikasi
  • A09: Kegagalan Logging & Pemberitahuan Keamanan

Tinjau praktik terbaik berikut untuk A01: Kontrol Akses yang Rusak:

Tinjau praktik terbaik berikut untuk A04: Kegagalan Kriptografi:

  • Enkripsi data sensitif di aplikasi Anda dan terapkan validasi kriptografi yang ketat sebelum traffic mencapai aplikasi backend Anda. Konfigurasi lingkungan Apigee Anda dengan kunci enkripsi yang dikelola pelanggan (CMEK) menggunakan Cloud KMS.
  • Gunakan TLS satu arah dan dua arah TLS untuk mengenkripsi informasi sensitif di tingkat protokol. Untuk integrasi bisnis server-ke-server atau berisiko tinggi, konfigurasikan mutual TLS (mTLS) di gateway masuk Apigee.
  • Gunakan kebijakan VerifyJWT dan VerifyJWS untuk mewajibkan token masuk memiliki tanda tangan kriptografi yang valid sebelum permintaan diproses. Gunakan teknik OAuth standar dan pertimbangkan untuk menerapkan HMAC, hashing payload, validasi state atau nonce, dan Proof Key for Code Exchange (PKCE) untuk memperkuat setiap permintaan secara kriptografis.
  • Samarkan data sensitif sehingga data dienkripsi dan disembunyikan saat menggunakan alat Apigee Debug.

Tinjau praktik terbaik berikut untuk A05: Injection:

Tinjau praktik terbaik berikut untuk A06: Desain yang Tidak Aman:

  • Memvalidasi permintaan masuk dengan kebijakan OASValidation untuk pesan permintaan atau respons masuk terhadap Spesifikasi OpenAPI.
  • Mengurangi lonjakan traffic dan kelebihan beban backend dengan menerapkan kebijakan SpikeArrestdan kebijakan Quota.
  • Gunakan Aturan penanganan kesalahan untuk mencegat error backend (seperti kerusakan database) dan menulis ulang error tersebut menjadi respons HTTP generik.

Tinjau praktik terbaik berikut untuk A07: Kegagalan Autentikasi:

  • Terapkan validasi kunci API untuk API yang menghadap developer agar Apigee dapat memeriksa apakah kunci API aplikasi klien ada, valid, dan diizinkan untuk mengakses resource API yang diminta.
  • Untuk membantu mencegah pencurian token sesi dan serangan replay, terapkan Demonstrating Proof-of-Possession (DPoP). DPoP mengikat token ke kunci publik pengirim untuk memitigasi pemutaran ulang token.
  • Lindungi endpoint login dan pembuatan token dari serangan brute force otomatis dengan menggabungkan batas frekuensi SpikeArrest dengan integrasi reCAPTCHA Enterprise.

Tinjau praktik terbaik berikut untuk A09: Kegagalan Logging & Pemberitahuan Keamanan:

  • Streaming metadata transaksi API terstruktur secara asinkron ke Logging atau SIEM pihak ketiga. Lampirkan MessageLogging kebijakan ke PostClientFlow, yang berjalan setelah respons dikirimkan ke klien.
  • Memusatkan log audit platform untuk melacak modifikasi pada proxy API, kredensial, dan lingkungan deployment. Untuk membantu mencegah modifikasi proxy yang tidak sah tanpa diketahui, integrasikan Apigee dengan Cloud Audit Logs. Untuk mengetahui informasi selengkapnya, lihat Logging audit Apigee dan Logging audit Pengelolaan API Apigee.
  • Konfigurasi Peringatan Advanced API Security di Monitoring untuk memberi tahu tim SecOps tentang kampanye scraping otomatis, penyalahgunaan kredensial, dan regresi skor keamanan.
  • Bersihkan variabel yang diberikan pengguna dalam template pesan log Anda dengan membungkusnya dalam fungsi escapeJSON().
  • Jika Anda melakukan streaming metadata log ke SIEM eksternal, konfigurasikan kebijakan MessageLogging untuk menggunakan Syslog melalui TLS (port TCP 6514) guna mengenkripsi data Anda dalam pengiriman.

Artifact Registry dan Artifact Analysis

Artifact Registry adalah satu tempat bagi organisasi Anda untuk mengelola image container dan paket bahasa. Artifact Analysis menyediakan pemindaian kerentanan terintegrasi, pembuatan Software Bill of Materials (SBOM), dan penyimpanan metadata untuk artefak yang disimpan di Artifact Registry.

Berlaku untuk hal berikut:

  • A03: Kegagalan Supply Chain Software
  • A08: Kegagalan Integritas Software atau Data

Tinjau praktik terbaik berikut untuk A03: Kegagalan Supply Chain Software:

  • Kurangi permukaan serangan dan bantu mencegah deployment image lama yang rentan dengan mengonfigurasi kebijakan pembersihan untuk menghapus image kandidat rilis yang tidak diberi versi, tidak diberi tag, atau sudah usang setelah periode retensi data yang telah ditentukan sebelumnya.
  • Lindungi dari serangan kebingungan dependensi dengan mengonfigurasi repositori virtual dengan prioritas repositori upstream yang memprioritaskan repositori artefak internal daripada registry publik.
  • Terapkan tag image yang tidak dapat diubah atau deploy secara ketat berdasarkan ringkasan kriptografis (sha256:...) untuk mencegah serangan mutasi tag.

Tinjau praktik terbaik berikut untuk A08: Kegagalan Integritas Software atau Data:

Assured OSS

Assured OSS memungkinkan Anda memasukkan paket OSS yang divalidasi dan digunakan Google ke dalam alur kerja developer Anda sendiri.

Berlaku untuk hal berikut:

  • A03: Kegagalan Supply Chain Software
  • A08: Kegagalan Integritas Software atau Data

Tinjau praktik terbaik berikut untuk A03: Kegagalan Supply Chain Software:

  • Konfigurasi repositori jarak jauh untuk mengarah ke upstream Assured OSS.
  • Pastikan bahwa library open source dalam build Anda berisi tanda tangan Google yang valid dan catatan provenance build SLSA yang dapat diverifikasi. Konfigurasi parameter kualitas di Cloud Build untuk memverifikasi pengesahan ini sebelum mengompilasi biner aplikasi.
  • Konfigurasi pengelola paket (seperti pip.conf, settings.xml, atau build.gradle) di image dasar Cloud Workstations Anda agar hanya mengarah ke repositori Assured OSS internal Anda.
  • Gunakan metadata yang dihasilkan oleh Assured OSS untuk menentukan apakah CVE yang baru diungkapkan dalam paket open source dapat dieksploitasi dalam konteks deployment spesifik Anda.

Tinjau praktik terbaik berikut untuk A08: Kegagalan Integritas Software atau Data:

Otorisasi Biner

Otorisasi Biner memverifikasi integritas container sehingga hanya image container tepercaya yang di-deploy. Anda dapat membuat kebijakan untuk mengizinkan atau menolak deployment berdasarkan ada atau tidaknya pengesahan. Otorisasi Biner menerapkan kebijakan di tingkat cluster, sehingga Anda dapat mengonfigurasi kebijakan yang berbeda untuk lingkungan yang berbeda.

Berlaku untuk hal berikut:

  • A03: Kegagalan Supply Chain Software
  • A08: Kegagalan Integritas Software atau Data

Tinjau praktik terbaik berikut untuk A03: Kegagalan Supply Chain Software:

  • Konfigurasi pipeline deployment untuk mereferensikan dan menerapkan image container berdasarkan ringkasan kriptografi SHA-256 yang unik dan tetap (seperti @sha256).
  • Deploy Validasi Berkelanjutan Otorisasi Biner di cluster GKE Anda untuk memantau Pod aktif terhadap kebijakan platform Anda, dan membuat pemberitahuan di Logging jika menjalankan container tidak lagi mematuhi kebijakan.

Tinjau praktik terbaik berikut untuk A08: Kegagalan Integritas Software atau Data:

  • Terapkan pembuatan pengesahan otomatis di pipeline Cloud Build atau GitHub Actions Anda. Buat persyaratan pengesahan progresif sehingga image melewati gerbang validasi berurutan saat image semakin mendekati produksi.
  • Untuk insiden produksi dengan tingkat keparahan tinggi, aktifkan deployment darurat breakglass. Konfigurasi kebijakan pemberitahuan Monitoring pada peristiwa log audit breakglass untuk memberi tahu tim SecOps Anda saat terjadi bypass penerimaan.

CA Service and Certificate Manager

Certificate Authority Service (CA Service) menyederhanakan deployment dan pengelolaan certificate authority (CA) pribadi. Certificate Manager menyediakan penyediaan, perpanjangan, dan pengelolaan sertifikat TLS secara terpusat untuk Cloud Load Balancing dan Cloud CDN.

Berlaku untuk A04: Kegagalan Kriptografi.

Tinjau praktik terbaik berikut:

  • Gunakan CA Service untuk mengotomatiskan penerbitan dan pengelolaan siklus proses sertifikat pribadi. Deploy CA root dan perantara yang didukung oleh Cloud HSM untuk melindungi kunci pribadi, dan gunakan template sertifikat untuk menerapkan kebijakan kriptografi (seperti panjang kunci minimum dan penggunaan kunci yang diperluas yang diizinkan).
  • Aktifkan Cloud Audit Logs untuk memantau peristiwa administratif berisiko tinggi (seperti pencabutan CA, pembaruan kebijakan, atau lonjakan permintaan sertifikat yang tiba-tiba). Merutekan pemberitahuan ke Google SecOps untuk mendeteksi potensi ancaman dari pihak internal atau pipeline CI/CD yang disusupi.
  • Konfigurasi Pengelola Sertifikat untuk menggunakan sertifikat yang dikelola Google yang dipasangkan dengan otorisasi DNS. Certificate Manager memvalidasi kepemilikan domain, menerbitkan sertifikat X.509, dan menangani perpanjangan 30 hari sebelum masa berlaku berakhir.
  • Lampirkan peta sertifikat ke proxy HTTPS target untuk mengaktifkan pemilihan sertifikat dinamis dan rotasi sertifikat tanpa memerlukan mulai ulang proxy atau konfigurasi ulang load balancer.
  • Untuk load balancing hibrida atau microservice internal, konfigurasi peta sertifikat untuk menerbitkan sertifikat pribadi secara langsung dari kumpulan CA Service CA pribadi.
  • Konfigurasi peta sertifikat agar sesuai dengan permintaan Indikasi Nama Server (SNI) masuk ke sertifikat tertentu.

Inventaris Aset Cloud

Inventaris Aset Cloud memungkinkan Anda memantau infrastruktur Anda di Google Cloud untuk infrastruktur IT yang tidak memiliki pemilik atau tidak sah.

Berlaku untuk A02: Kesalahan Konfigurasi Keamanan.

Tinjau praktik terbaik berikut:

  • Siapkan notifikasi untuk memberi tahu Anda jika ada resource yang berjalan secara tidak terduga, yang mungkin tidak diamankan dengan benar atau menggunakan software usang.
  • Gunakan Penganalisis Kebijakan IAM untuk menemukan kontrol akses yang salah dikonfigurasi, seperti bucket penyimpanan publik dengan izin allUsers, peran akun layanan dengan hak istimewa berlebih, atau identitas yang tidak terkait.
  • Mengekspor snapshot aset ke BigQuery untuk mengaudit konfigurasi infrastruktur dari waktu ke waktu dan mempertahankan catatan kepatuhan dasar di seluruh lingkungan multi-project.

Cloud Armor

Cloud Armor adalah firewall aplikasi web (WAF) adaptif yang Anda deploy di edge jaringan Google Cloud untuk membantu memberikan pertahanan dari serangan DDoS dan memblokir payload injeksi SQLi atau XSS. Cloud Armor menyertakan aturan WAF yang telah dikonfigurasi sebelumnya untuk melindungi dari kerentanan 10 risiko teratas OWASP, membatasi permukaan serangan pada endpoint autentikasi Anda, dan memblokir kredensial yang disusupi.

Berlaku untuk hal berikut:

  • A01: Kontrol Akses yang Rusak
  • A05: Injeksi
  • A07: Kegagalan Autentikasi
  • A08: Kegagalan Integritas Software atau Data
  • A10: Penanganan Kondisi Pengecualian yang Salah

Tinjau praktik terbaik berikut untuk A01: Kontrol Akses yang Rusak:

Tinjau praktik terbaik berikut untuk A05: Injection:

Tinjau praktik terbaik berikut untuk A07: Kegagalan Autentikasi:

  • Batasi akses ke endpoint autentikasi dan administratif untuk alamat IP atau negara yang diizinkan.
  • Aktifkan evaluatePreconfiguredWaf untuk mencegat dan memblokir permintaan yang dirancang untuk mengeksploitasi kerentanan status sesi dan pembajakan sesi.
  • Gunakan securityPolicies.patchRule API untuk memblokir permintaan masuk yang berisi parameter yang disusupi di string kueri atau header di edge jaringan.

Tinjau praktik terbaik berikut untuk A08: Kegagalan Integritas Software atau Data:

  • Batasi endpoint yang menerima objek berserial berisiko tinggi dari sumber yang tidak tepercaya ke sekumpulan alamat IP tepercaya dengan aturan penolakan yang serupa dengan berikut ini:

    request.path.contains('/endpoint') && !inIpRange(origin.ip, '192.0.2.1/32')

  • Deploy aturan kustom untuk memeriksa kata kunci isi permintaan terkait pola eksekusi khusus bahasa dan tanda tangan deserialisasi yang tidak aman.

Tinjau praktik terbaik berikut untuk A10: Penanganan Kondisi Pengecualian yang Salah:

  • Aktifkan Adaptive Protection Google Cloud Armor di kebijakan keamanan Anda untuk membuat dasar pola traffic normal, mengonfigurasi pemberitahuan tentang anomali L7, dan membuat aturan WAF yang ditargetkan dengan tanda tangan serangan.
  • Konfigurasi aturan pembatasan kecepatan Cloud Armor di endpoint penting (misalnya, /login, /checkout, atau API penelusuran). Aturan pembatasan kapasitas membatasi permintaan berdasarkan per-IP klien atau header HTTP (misalnya, membatasi klien hingga 100 permintaan per menit) dan menampilkan kode status HTTP 429 Too Many Requests.
  • Tetapkan aturan default prioritas terendah dalam kebijakan keamanan Cloud Armor Anda ke Deny (kode status: 403 atau 404).

Cloud Build dan Cloud Deploy

Cloud Build dan Cloud Deploy menyediakan pipeline continuous integration dan continuous delivery (CI/CD) yang terintegrasi dan aman di Google Cloud. Cloud Build membuat artefak dengan provenance SLSA yang dapat diverifikasi dan pengesahan kriptografi, serta Cloud Deploy mengelola peluncuran progresif, persetujuan target, dan verifikasi otomatis di seluruh GKE dan Cloud Run.

Berlaku untuk hal berikut:

  • A03: Kegagalan Supply Chain Software
  • A08: Kegagalan Integritas Software atau Data

Tinjau praktik terbaik berikut untuk A03: Kegagalan Supply Chain Software:

  • Tetapkan requestedVerifyOption: VERIFIED di file cloudbuild.yaml Anda untuk mewajibkan provenans yang dapat diverifikasi.
  • Deploy pool pribadi Cloud Build yang di-peering dengan jaringan VPC pribadi Anda untuk build perusahaan yang sensitif.
  • Konfigurasi pemicu build untuk dijalankan dengan akun layanan khusus yang dikelola pengguna. Berikan hanya izin yang diperlukan untuk mengizinkan IAM kepada akun layanan ini (seperti Penulis Artifact Registry (roles/artifactregistry.writer) dan Penulis Log (roles/logging.logWriter)).
  • Mewajibkan persetujuan manual pada pemicu Cloud Build yang menargetkan lingkungan staging atau produksi.
  • Batasi alat build CI (seperti Cloud Build, GitHub Actions, atau GitLab) ke peran Cloud Deploy Releaser (roles/clouddeploy.releaser) agar pipeline build hanya dapat membuat rilis.
  • Untuk mewajibkan persetujuan manual, konfigurasi manifes pipeline pengiriman (delivery-pipeline.yaml) dengan requireApproval: true di target staging dan produksi Anda.
  • Konfigurasi lingkungan eksekusi dengan akun layanan khusus target (misalnya, satu akun layanan dengan izin yang terbatas pada namespace penyiapan, dan akun layanan terpisah yang diaudit untuk produksi).
  • Deploy hook kustom untuk menjalankan pernyataan keamanan di luar band selama siklus proses peluncuran. Gunakan hook pra-deployment untuk memverifikasi apakah cluster target memenuhi dasar kepatuhan dan hook pasca-deployment untuk memulai pemindaian kerentanan otomatis terhadap endpoint container aktif.

Tinjau praktik terbaik berikut untuk A08: Kegagalan Integritas Software atau Data:

  • Integrasikan Cloud Build dengan Cloud KMS dan Artifact Analysis untuk membuat dan menandatangani pengesahan kriptografi saat pengujian unit dan pengujian analisis statis berhasil diselesaikan.
  • Gunakan ringkasan SHA-256 kriptografi yang tidak dapat diubah (misalnya, golang@sha256:...) dalam langkah-langkah builder di cloudbuild.yaml.
  • Simpan konfigurasi build di repositori yang dikontrol versinya dan dilindungi oleh aturan perlindungan cabang (seperti mewajibkan peninjauan oleh dua orang pada permintaan pull). Membatasi izin modifikasi pemicu untuk administrator platform yang berwenang menggunakan akun layanan yang dikelola pengguna.
  • Promosikan deployment manifest yang identik dan telah di-render sebelumnya serta ringkasan image container yang tidak dapat diubah di seluruh tahap target tanpa membiarkan pipeline CI mengubah manifes antara staging dan produksi.
  • Tentukan tugas verifikasi deployment otomatis di dalam manifes skaffold.yaml Anda. Cloud Deploy menjalankan penampung verifikasi ini setelah pod di-deploy untuk menjalankan pemeriksaan kondisi dinamis, pengujian integrasi, dan pernyataan kontrak API.
  • Gunakan strategi deployment canary. Jika pengujian verifikasi Skaffold gagal atau Pemantauan mendeteksi nilai minimum anomali selama fase canary, Cloud Deploy akan menghentikan peluncuran dan melakukan rollback traffic ke versi rilis baik yang terakhir diketahui.
  • Konfigurasi cluster GKE dan Cloud Run untuk menerapkan kebijakan Otorisasi Biner. Saat Cloud Deploy menerapkan manifes, pengontrol penerimaan target akan memverifikasi secara kriptografis ringkasan image container dan menolak artefak yang tidak tepercaya.

Cloud Identity dan Kunci Keamanan Titan

Cloud Identity menyediakan pengelolaan identitas, siklus proses kredensial, dan akses terpusat di seluruh Google Clouddan Google Workspace. Kunci Keamanan Titan adalah perangkat keamanan berbasis hardware yang tahan terhadap phishing dan menggunakan kriptografi kunci publik berdasarkan standar FIDO2 atau WebAuthn.

Berlaku untuk A07: Kegagalan Autentikasi.

Tinjau praktik terbaik berikut:

  • Untuk membantu melindungi dari serangan phishing man-in-the-middle (MITM), konfigurasi Verifikasi 2 Langkah (2SV) dan tetapkan metode yang diizinkan ke Hanya Kunci Keamanan (FIDO2, WebAuthn, atau Kunci Keamanan Titan).
  • Konfigurasi single sign-on (SSO) berbasis SAML 2.0 atau OIDC dengan penyedia identitas perusahaan Anda bersama dengan penyediaan otomatis.
  • Tetapkan Google Cloud kebijakan durasi sesi ke nilai maksimum yang rendah untuk mewajibkan pengguna melakukan autentikasi ulang secara berkala.
  • Daftarkan Kunci Keamanan Titan sebagai kunci sandi untuk mengaktifkan autentikasi tanpa sandi, sehingga secara signifikan mengurangi risiko serangan brute force dan pencurian kredensial.
  • Wajibkan Verifikasi 2 Langkah dengan Kunci Keamanan Titan untuk identitas istimewa Anda (seperti pemilik project, administrator penagihan, dan tim SecOps) dengan menerapkan kebijakan kunci keamanan di Cloud Identity. Mendaftarkan pengguna berisiko tinggi ke Program Perlindungan Lanjutan.

Cloud KMS

Cloud KMS mengelola kunci kriptografis simetris dan asimetris untuk layanan yang kompatibel dan di aplikasi Anda sendiri. Google Cloud Anda dapat membuat, menggunakan, merotasi, dan menghancurkan kunci kriptografi untuk enkripsi simetris, penandatanganan asimetris, enkripsi asimetris, dan penandatanganan MAC.

Berlaku untuk A04: Kegagalan Kriptografi.

Tinjau praktik terbaik berikut:

  • Gunakan Autokey Cloud KMS untuk mengotomatiskan penyediaan dan penetapan. Dengan Autokey, Anda tidak perlu menyediakan ring kunci, kunci, dan akun layanan sebelumnya. Sebagai gantinya, kunci dan key ring dibuat sesuai permintaan sebagai bagian dari pembuatan resource.
  • Gunakan kunci Cloud KMS untuk mengenkripsi payload sensitif sebelum payload dikirim ke bucket penyimpanan atau database. Anda dapat menggunakan Cloud KMS API atau library klien untuk menggunakan kunci Cloud KMS Anda untuk enkripsi sisi klien.
  • Verifikasi integritas data menyeluruh dengan memvalidasi checksum selama pengiriman.
  • Untuk workload kepatuhan dan peraturan yang ketat, simpan dan jalankan operasi kriptografi Anda menggunakan Cloud HSM. Cloud HSM menyimpan kunci Anda di modul keamanan hardware yang divalidasi FIPS 140-3 Level 3.
  • Konfigurasi jadwal rotasi kunci otomatis dalam jangka waktu yang ditetapkan (misalnya, setiap 90 hari).

Cloud Load Balancing

Cloud Load Balancing adalah layanan terkelola yang terdistribusi sepenuhnya, serta software-defined yang mendistribusikan traffic pengguna di beberapa instance dan region backend.

Berlaku untuk hal berikut:

  • A04: Kegagalan Kriptografi
  • A10: Penanganan Kondisi Pengecualian yang Salah

Tinjau praktik terbaik berikut untuk A04: Kegagalan Kriptografi:

Tinjau praktik terbaik berikut untuk A10: Penanganan Kondisi Pengecualian yang Salah:

Google Cloud Observability (Logging, Monitoring, dan Error Reporting)

Google Cloud Observability menyediakan pengelolaan log full-stack dengan Logging, metrik dan pemberitahuan dengan Monitoring, serta pelacakan error aplikasi real-time dengan Error Reporting.

Berlaku untuk hal berikut:

  • A09: Kegagalan Logging & Pemberitahuan Keamanan
  • A10: Penanganan Kondisi Pengecualian yang Salah

Tinjau praktik terbaik berikut untuk A09: Kegagalan Logging & Pemberitahuan Keamanan:

  • Aktifkan Log Akses Data untuk repositori data bernilai tinggi (seperti Cloud Storage, BigQuery, dan Spanner) yang menyimpan data sensitif. Log Akses Data memungkinkan Anda mengaudit setiap peristiwa baca, tulis, dan kueri untuk data sensitif.
  • Terapkan Penguncian Bucket dan kebijakan retensi untuk bucket Logging kustom guna membantu mencegah penyerang atau administrator yang tidak sah menghapus log untuk menutupi jejak mereka.
  • Gunakan sink gabungan untuk mengumpulkan dan merutekan entri log ke dalam satu repositori pusat untuk tim SecOps Anda. Konfigurasi penyadapan sink gabungan untuk menghindari penyimpanan log bervolume tinggi seperti log Akses Data di lebih dari satu tempat.
  • Konfigurasi kebijakan pemberitahuan berbasis log untuk indikator penting terjadinya pelanggaran, seperti error IAM Izin Ditolak, pembuatan kunci API yang tidak terduga, atau perubahan konfigurasi firewall yang tiba-tiba.
  • Deploy kebijakan pemberitahuan berbasis log di Logs Explorer atau Monitoring. Tentukan filter persis yang menargetkan peristiwa tingkat keparahan tinggi, seperti modifikasi kebijakan IAM yang tidak sah atau pencabutan kunci KMS, sehingga notifikasi insiden dibuat saat entri log yang cocok diserap.
  • Buat metrik penghitung berbasis log di Logging untuk mengonversi entri log yang cocok menjadi data deret waktu. Kemudian, buat kebijakan pemberitahuan berbasis metrik di Monitoring yang memulai insiden saat laju melebihi batas tertentu (misalnya, lebih dari 50 upaya login yang gagal dalam lima menit).
  • Konfigurasi kebijakan pemberitahuan berbasis log yang memantau panggilan administratif ke Cloud Logging API dan memberikan pemberitahuan jika ada modifikasi sink ekspor log atau penghapusan bucket yang tidak terduga.
  • Konfigurasi saluran notifikasi dengan template dokumentasi yang jelas. Sertakan deep link langsung ke kueri Logs Explorer, prosedur operasi standar (SOP) untuk engineer yang bertugas, dan langkah-langkah perbaikan eksplisit untuk membantu penanganan insiden yang cepat.

Tinjau praktik terbaik berikut untuk A10: Penanganan Kondisi Pengecualian yang Salah:

  • Integrasikan SDK Pelaporan Error secara langsung ke dalam kode aplikasi Anda atau konfigurasi Logging untuk mengurai format pengecualian JSON terstruktur.
  • Konfigurasi saluran notifikasi Error Reporting atau kebijakan pemberitahuan Monitoring untuk memberi tahu tim SecOps Anda saat ada class pengecualian baru yang muncul.

Cloud NGFW

Cloud NGFW adalah layanan firewall terkelola yang memungkinkan inspeksi stateful dan kontrol aplikasi Lapisan 7 untuk traffic utara-selatan dan traffic timur-barat.

Berlaku untuk hal berikut:

  • A01: Kontrol Akses yang Rusak
  • A05: Injeksi

Tinjau praktik terbaik berikut untuk A01: Kontrol Akses yang Rusak:

Tinjau praktik terbaik berikut untuk A05: Injection:

  • Konfigurasi layanan deteksi dan pencegahan intrusi dengan grup profil keamanan yang menolak ancaman yang cocok dengan injeksi SQL, injeksi perintah OS, dan tanda tangan eksploitasi eksekusi kode jarak jauh.
  • Konfigurasi pemeriksaan TLS Cloud NGFW untuk mendekripsi traffic HTTPS masuk dan keluar, menerapkan pemeriksaan tanda tangan injeksi IPS ke payload teks biasa, dan mengenkripsi ulang sesi sebelum pengiriman ke backend.
  • Terapkan aturan firewall egress berbasis FQDN di database backend dan subnet Compute. Membatasi koneksi keluar ke domain eksternal yang telah disetujui dan ditentukan sebelumnya untuk membantu mencegah aplikasi yang rentan membuat shell terbalik yang tidak sah.
  • Aktifkan logging aturan firewall di profil pencegahan ancaman dan rute log ini ke Google SecOps untuk mengorelasikan tanda tangan injeksi jaringan yang diblokir dengan telemetri tingkat host, sehingga mengidentifikasi beban kerja yang ditargetkan untuk patch prioritas.

Cloud Workstations

Cloud Workstations menyediakan lingkungan pengembangan terkelola di Google Cloud dengan keamanan dan penyesuaian bawaan.

Berlaku untuk hal berikut:

  • A03: Kegagalan Supply Chain Software
  • A04: Kegagalan Kriptografi

Tinjau praktik terbaik berikut untuk A03: Kegagalan Supply Chain Software:

  • Buat image container dasar kustom yang disimpan di Artifact Registry yang telah menginstal alat keamanan, ekstensi developer tepercaya, dan runtime bahasa yang disetujui.
  • Deploy cluster workstation Anda dengan ingress dan egress IP pribadi serta di dalam perimeter Kontrol Layanan VPC.
  • Konfigurasi Cloud Workstations untuk merutekan traffic sesi melalui IAP. Mewajibkan developer untuk mengautentikasi menggunakan kredensial perusahaan dengan autentikasi multi-faktor (MFA) yang diaktifkan dan menerapkan peran dengan hak istimewa paling rendah (misalnya, Pengguna Cloud Workstations (roles/workstations.user)).
  • Konfigurasi konfigurasi workstation dengan batas waktu tunggu yang rendah (misalnya, berhenti otomatis setelah dua jam tidak aktif). Saat workstation dimulai ulang, Cloud Workstations akan menarik image container yang telah di-patch keamanannya, sehingga developer dapat bekerja di lingkungan yang bersih.

Tinjau praktik terbaik berikut untuk A04: Kegagalan Kriptografi:

CodeMender

CodeMender adalah agen engineering AI otonom yang khusus. CodeMender dapat menerapkan patch pada kerentanan yang baru ditemukan dan menulis ulang kode lama yang ada untuk mengatasi kerentanan yang ada. Anda dapat menginstal dan mengonfigurasi CodeMender di Gemini Enterprise Agent Platform.

Berlaku untuk hal berikut:

  • A03: Kegagalan Supply Chain Software
  • A05: Injeksi
  • A06: Desain yang Tidak Aman

Tinjau praktik terbaik berikut untuk A03: Kegagalan Supply Chain Software:

  • Integrasikan CLI CodeMender ke dalam ruang kerja developer lokal dan pipeline CI/CD untuk memindai modul yang ditargetkan, memverifikasi kemungkinan eksploitasi, dan mendeteksi kelemahan keamanan sebelum kode di-commit.
  • Impor Analisis Komposisi Software (SCA) dan laporan kerentanan dependensi ke dalam CodeMender untuk menjalankan verifikasi eksploitasi bukti konsep, memfilter positif palsu sebelum peninjauan developer.

Tinjau praktik terbaik berikut untuk A05: Injection:

  • Jalankan pembuatan patch otomatis di dalam sandbox lokal yang terisolasi untuk menulis ulang logika yang rentan (seperti membersihkan input). Pastikan pengujian unit lulus dan PoC tidak lagi dapat dieksploitasi sebelum membuat permintaan pull.

Tinjau praktik terbaik berikut untuk A06: Desain yang Tidak Aman:

  • Lakukan refaktorisasi logika kode arsitektur lama atau tidak aman menggunakan mesin patch iteratif CodeMender, dengan memberikan batasan coding eksplisit untuk menerapkan pola desain yang aman di seluruh modul aplikasi.
  • Pertahankan peninjauan dengan campur tangan manusiauntuk permintaan pull dan perbedaan yang dihasilkan CodeMender guna memverifikasi bahwa perubahan yang diusulkan sesuai dengan pedoman coding aman Anda.

Confidential Computing

Confidential Computing membantu melindungi data aktif dengan menjaga data tetap terenkripsi dalam memori saat data sedang diproses. Dengan menggunakan Trusted Execution Environment (TEE) berbasis hardware, Confidential Computing membantu memastikan bahwa data sensitif dan kunci kriptografi Anda tidak dapat diakses oleh hypervisor, sistem operasi host, atau administrator infrastruktur.

Berlaku untuk A04: Kegagalan Kriptografi.

Tinjau praktik terbaik berikut:

  • Gunakan Confidential VMs atau Confidential Google Kubernetes Engine Nodes untuk workload yang sangat sensitif (seperti PII, catatan keuangan, atau bobot model AI eksklusif).
  • Jika beberapa organisasi harus mengumpulkan data sensitif untuk analisis atau pelatihan AI (tanpa saling mengekspos data mentah), gunakan Confidential Space untuk menerapkan pengesahan kriptografi dan isolasi data.

Firebase (Firebase Authentication, Firebase App Check, dan Aturan Keamanan Firebase)

Firebase menyediakan kontrol keamanan yang berfokus pada developer di seluruh identitas, pengesahan klien, dan akses database. Firebase Authentication menangani identitas pengguna dan pengelolaan sesi, App Check memvalidasi integritas aplikasi klien, dan Aturan Keamanan Firebase menerapkan kontrol akses berbasis atribut dan validasi skema untuk Firestore dan Cloud Storage.

Berlaku untuk hal berikut:

  • A01: Kontrol Akses yang Rusak
  • A05: Injeksi
  • A07: Kegagalan Autentikasi
  • A08: Kegagalan Integritas Software atau Data

Tinjau praktik terbaik berikut untuk A01: Kontrol Akses yang Rusak:

  • Cakupan baca dan tulis ke ID pengguna yang diautentikasi di Aturan Keamanan Firebase. Jangan pernah menggunakan aturan default permisif seperti allow read, write: if true;.
  • Untuk peran administratif, gunakan Firebase Admin SDK untuk menetapkan klaim kustom pada token ID pengguna, dan validasi klaim tersebut dalam aturan keamanan Anda, bukan mengizinkan penulisan profil sisi klien.
  • Terapkan App Check di Aturan Keamanan Firebase untuk memblokir akses klien yang tidak diautentikasi atau dipalsukan di lapisan database.

Tinjau praktik terbaik berikut untuk A05: Injection:

  • Terapkan validasi payload struktural di Aturan Keamanan dengan memeriksa jenis kolom dokumen yang masuk, panjang string, dan ukuran objek untuk menolak payload tulis yang salah bentuk atau berbahaya sebelum penyerapan database.

Tinjau praktik terbaik berikut untuk A07: Kegagalan Autentikasi:

  • Lakukan upgrade ke Firebase Authentication dengan Identity Platform untuk mengaktifkan perlindungan tingkat perusahaan seperti MFA dengan TOTP dan fungsi pemblokiran.
  • Verifikasi token ID Firebase di backend Anda menggunakan Firebase Admin SDK sebelum memberikan akses ke data aplikasi sensitif.
  • Gunakan penyedia debug untuk membuat token debug sementara dan tercakup untuk developer dan pipeline CI/CD Anda di lingkungan staging.

Tinjau praktik terbaik berikut untuk A08: Kegagalan Integritas Software atau Data:

  • Menerapkan penyedia pengesahan yang didukung hardware untuk memverifikasi integritas klien. Konfigurasi App Check untuk menggunakan Android Play Integrity dan Apple App Attest.
  • Deploy middleware verifikasi token App Check di backend API Cloud Run dan Kubernetes Engine API untuk menolak permintaan yang berasal dari kunci API yang di-scrap, skrip otomatis, atau lingkungan yang di-emulasi.

Fraud Defense

Fraud Defense adalah platform terpadu untuk pertahanan terhadap penipuan dan penyalahgunaan, termasuk perlindungan bot, akun, dan transaksi untuk web. reCAPTCHA, sebuah penawaran yang merupakan bagian dari Fraud Defense, memfilter bot dan bentuk otomatisasi serta traffic massal lainnya dengan menilai tingkat risiko upaya akses.

Berlaku untuk A07: Kegagalan Autentikasi.

Tinjau praktik terbaik berikut:

  • Integrasikan reCAPTCHA dengan WAF yang ada, seperti Google Cloud Armor, untuk mengeluarkan tantangan otomatis atau memblokir traffic bot berisiko tinggi sebelum permintaan mencapai endpoint autentikasi.
  • Lindungi akun saat login, reset sandi, dan endpoint perpanjangan sesi. Dapatkan skor risiko pengambilalihan akun (ATO) berdasarkan kecepatan login pengguna dan sidik jari perangkat.
  • Lindungi diri Anda dari penipuan pulsa SMS di formulir pendaftaran dan 2FA dengan mengevaluasi profil risiko nomor telepon sebelum mengirim pesan SMS keluar.
  • Untuk mengurangi positif palsu dan melatih model penilaian risiko khusus situs, anotasi dan kirimkan masukan transaksi secara rutin.
  • Memeriksa sandi selama alur login pengguna dan pembuatan akun untuk mendeteksi apakah kredensial yang dikirimkan muncul di database pelanggaran data pihak ketiga di seluruh web.

Google SecOps

Google Security Operations adalah platform operasi keamanan yang menggabungkan analisis telemetri keamanan (SIEM), orkestrasi, otomatisasi, dan respons keamanan (SOAR), serta threat intelligence Mandiant terdepan ke dalam satu platform.

Berlaku untuk hal berikut:

  • A02: Kesalahan Konfigurasi Keamanan
  • A09: Kegagalan Logging & Pemberitahuan Keamanan

Tinjau praktik terbaik berikut untuk A02: Kesalahan Konfigurasi Keamanan:

  • Masukkan temuan dari Security Command Center ke Google SecOps untuk menggabungkan temuan kesalahan konfigurasi statis (misalnya, PUBLIC_BUCKET_ACL atau CMEK_DISABLED) dengan telemetri firewall dan jaringan live.
  • Buat playbook respons SOAR otomatis untuk menjalankan tindakan pembatasan.
  • Gunakan Gemini untuk mempercepat triage kesalahan konfigurasi dan menerima ringkasan sintetis aset yang salah dikonfigurasi, peran IAM yang dilampirkan, dan panduan perbaikan langkah demi langkah.

Tinjau praktik terbaik berikut untuk A09: Kegagalan Logging & Pemberitahuan Keamanan:

  • Menormalisasi telemetri log ke model data terpadu (UDM) untuk memungkinkan penelusuran dan korelasi multi-cloud yang cepat dan standar tanpa overhead penguraian log mentah.
  • Tulis aturan deteksi YARA-L 2.0 untuk memantau perubahan konfigurasi berisiko tinggi seperti menonaktifkan Login OS, menghapus sink Logging, atau memodifikasi perimeter Kontrol Layanan VPC.
  • Gunakan Deteksi yang dikurasi Applied Threat Intelligence untuk mengevaluasi data peristiwa Anda berdasarkan data Mandiant Threat Intelligence.
  • Gunakan Gemini di Google SecOps untuk membuat aturan deteksi YARA-L dari deskripsi bahasa alami dan meringkas linimasa insiden multi-tahap yang kompleks menjadi ringkasan insiden eksekutif.

Identity-Aware Proxy

IAP membuat lapisan otorisasi pusat untuk aplikasi yang diakses oleh HTTPS dan koneksi TCP administratif. IAP memverifikasi identitas dan konteks pengguna sebelum memberikan akses ke Cloud Run, App Engine, Compute Engine, GKE, dan resource lokal.

Berlaku untuk hal berikut:

  • A01: Kontrol Akses yang Rusak
  • A07: Kegagalan Autentikasi

Tinjau praktik terbaik berikut untuk A01: Kontrol Akses yang Rusak:

  • Menerapkan kontrol akses terperinci ke aplikasi web, VM, Google Cloud API, dan aplikasi Google Workspace berdasarkan identitas pengguna, keanggotaan grup, dan konteks permintaan.
  • Integrasikan dengan Agent Gateway untuk menerapkan kontrol akses untuk identitas agen Anda.
  • Gunakan Penerusan TCP IAP untuk membuat tunnel HTTPS terenkripsi ke instance backend Anda dan menghapus endpoint SSH (port 22) dan RDP (port 3389) yang menghadap internet.

Tinjau praktik terbaik berikut untuk A07: Kegagalan Autentikasi:

  • Mengautentikasi pengguna yang mengakses antarmuka administratif dan aplikasi web melalui IAP menggunakan identitas yang disediakan di IAM atau Cloud Identity.
  • Verifikasi pernyataan JWT yang ditandatangani di dalam header x-goog-iap-jwt-assertion di lapisan aplikasi. Validasi tanda tangan terhadap kunci publik Google dan verifikasi bahwa klaim audiens (aud) cocok dengan ID layanan backend Anda.
  • Untuk membantu mencegah penyerang melewati autentikasi IAP, konfigurasikan setelan ingress Cloud Run untuk mengizinkan traffic internal dan Cloud Load Balancing saja, dengan memblokir akses publik langsung ke URL penampung backend Anda. Untuk VM atau node GKE, konfigurasikan aturan firewall VPC agar hanya menerima traffic ingress yang berasal dari rentang IP load balancer.

Identity and Access Management

Identity and Access Management (IAM) memungkinkan Anda mengelola akses terperinci ke layanan dan resource di Google Cloud. IAM mencakup fitur seperti berikut:

Berlaku untuk hal berikut:

  • A01: Kontrol Akses yang Rusak
  • A07: Kegagalan Autentikasi

Tinjau praktik terbaik berikut untuk A01: Kontrol Akses yang Rusak:

  • Gunakan peran bawaan atau peran khusus (bukan peran dasar) untuk membatasi izin ke kebutuhan pengguna atau resource tertentu.
  • Batasi izin untuk memberikan peran Service Account User (roles/iam.serviceAccountUser) dan Service Account Token Creator (roles/iam.serviceAccountTokenCreator).
  • Gunakan Pemberi Rekomendasi IAM untuk menganalisis log penggunaan aktif organisasi Anda dan menghapus akun dengan hak istimewa berlebih.
  • Tulis Kondisi IAM dalam binding peran Anda untuk menambahkan otorisasi kontekstual dan membatasi akses berdasarkan tanggal, waktu, atau alamat IP asal.
  • Deploy kebijakan Principal Access Boundary (PAB)untuk menentukan organisasi, folder, atau project yang dapat diakses oleh kumpulan akun utama. Jika penyerang mencuri sesi aktif atau akun layanan secara tidak sengaja diberi peran IAM yang luas, PAB akan memblokir akses jika resource yang ditentukan berada di luar batas yang ditetapkan untuk identitas.
  • Lampirkan kebijakan penolakan IAM di level organisasi atau folder untuk memblokir izin berisiko tinggi (seperti iam.serviceAccountKeys.create atau resourcemanager.projects.delete).
  • Saat mengonfigurasi aturan penolakan IAM, deklarasikan grup keamanan breakglass khusus dalam daftar exceptionPrincipals. Gunakan tag resource dalam kondisi penolakan Anda (seperti resource.matchTag('env', 'prod')) sehingga tindakan destruktif diblokir pada resource produksi sekaligus memungkinkan fleksibilitas operasional developer dalam project sandbox pengembangan.

Tinjau praktik terbaik berikut untuk A07: Kegagalan Autentikasi yang berlaku untuk Privileged Access Manager:

  • Konversi peran administratif penting (seperti Pemilik (roles/owner), Organization Administrator (roles/resourcemanager.organizationAdmin), dan Security Admin (roles/iam.securityAdmin)) dari binding IAM statis menjadi hak istimewa Privileged Access Manager. Konfigurasi hak ini untuk mewajibkan justifikasi operasional sebelum peningkatan diberikan.
  • Untuk lingkungan produksi, konfigurasi kebijakan pemberian hak istimewa Privileged Access Manager dengan pemberi persetujuan wajib seperti grup SecOps pusat atau ketua tim.
  • Konfigurasi durasi maksimum pada hak Privileged Access Manager ke jendela operasional realistis terpendek (misalnya, dua jam untuk pemeliharaan standar, 30 menit untuk tindakan breakglass). Setelah timer berakhir, Google Cloud menghapus pengikatan peran IAM sementara.
  • Kelola infrastruktur Terraform menggunakan resource IAM non-otoritatif (misalnya, google_project_iam_member atau google_folder_iam_member, bukan google_project_iam_policy atau google_project_iam_binding). Praktik ini menghindari penimpaan pipeline Terraform atau desinkronisasi pengikatan peran Privileged Access Manager sementara saat administrator secara aktif memulihkan insiden.
  • Aktifkan Cloud Audit Logs di Privileged Access Manager untuk mencatat tindakan pemberian hak dan peristiwa habis masa berlaku. Masukkan log ini ke Google SecOps untuk memberikan peringatan tentang pola eskalasi yang mencurigakan, seperti beberapa permintaan eskalasi di luar jam kerja atau permintaan berulang dari geolokasi yang tidak terduga.

Tinjau praktik terbaik berikut untuk A07: Kegagalan Autentikasi yang berlaku untuk Workforce Identity Federation:

  • Deploy pool identitas tenaga kerja menggunakan SAML 2.0 atau OpenID Connect (OIDC) untuk menggabungkan penyedia identitas eksternal denganGoogle Cloud.
  • Konfigurasi durasi sesi di workforce identity pool Anda untuk membatasi masa aktif token pengguna gabungan.
  • Terapkan kondisi atribut pada penyedia identitas tenaga kerja untuk memitigasi pemalsuan token IdP multi-tenant atau peniruan identitas lintas organisasi.
  • Petakan keanggotaan grup eksternal untuk menetapkan peran IAM ke set utama grup gabungan (misalnya, principalSet://iam.googleapis.com/.../attribute.group/security-engineers).

Tinjau praktik terbaik berikut untuk A07: Kegagalan Autentikasi yang berlaku untuk Workload Identity Federation:

  • Buat workload identity pool dan penyedia untuk beban kerja eksternal. Gunakan token OIDC berjangka pendek, tukar secara dinamis menggunakan Layanan Token Keamanan untuk token akses sementara yang akan berakhir dalam beberapa menit.
  • Terapkan kondisi atribut pada penyedia identitas beban kerja sehingga platform multi-tenant eksternal tidak dapat mengautentikasi ke pool Anda dari akun atau repositori yang tidak sah.
  • Mengikat peran IAM secara langsung ke set akun utama tertentu yang difilter menurut atribut yang dipetakan kustom.
  • Saat mengonfigurasi akses beban kerja, berikan peran IAM secara langsung ke ID principalSet:// gabungan di resource target.
  • Untuk menerapkan Workload Identity Federation, tetapkan batasan constraints/iam.disableServiceAccountKeyCreation pada organisasi Anda.

Identity Platform

Identity Platform adalah platform pengelolaan akses dan identitas pelanggan (CIAM) untuk Google Cloud pelanggan. Identity Platform menyediakan autentikasi dengan dukungan multi-protokol menggunakan SDK dan API. Identity Platform mendukung MFA, integrasi dengan layanan autentikasi pihak ketiga, dan pelacakan aktivitas yang dapat diaudit.

Berlaku untuk A07: Kegagalan Autentikasi.

Tinjau praktik terbaik berikut:

  • Aktifkan MFA di seluruh basis pengguna Anda. Prioritaskan metode yang tahan terhadap phishing, seperti TOTP (aplikasi pengautentikasi) atau WebAuthn (biometrik dan kunci keamanan).
  • Men-deploy fungsi Cloud Run pemblokiran menggunakan pemicu beforeCreate dan beforeSignIn untuk menjalankan kode keamanan kustom sebelum pengguna disimpan atau diberi token. Dengan praktik ini, Anda dapat memblokir domain email sekali pakai, membatasi alamat IP, atau mewajibkan verifikasi email.
  • Lakukan integrasi dengan reCAPTCHA Enterprise untuk menilai permintaan login, pendaftaran, dan reset sandi untuk traffic bot, upaya credential stuffing, dan penyalahgunaan otomatis.
  • Konfigurasi kebijakan sandi untuk menerapkan panjang karakter minimum, mewajibkan kompleksitas karakter tertentu (seperti angka dan simbol), dan memblokir urutan yang dapat diprediksi.
  • Jika menggunakan MFA berbasis telepon, konfigurasikan wilayah SMS dan aktifkan pertahanan SMS reCAPTCHA untuk membatasi pesan verifikasi ke kode negara tempat pengguna target Anda berada.

Solusi AI Security Consulting Mandiant

Solusi AI Security Consulting Mandiant dapat mengevaluasi arsitektur software, proses bisnis, dan deployment cloud yang Anda usulkan pada tahap awal siklus proses pengembangan. Dengan menerapkan intelijen ancaman garis depan pada desain sistem Anda, konsultan Mandiant membantu mengungkap kekurangan logis tersembunyi, batas kepercayaan yang hilang, dan risiko arsitektur sebelum satu baris kode pun ditulis.

Berlaku untuk A06: Desain yang Tidak Aman.

Tinjau praktik terbaik berikut:

  • Libatkan konsultan Mandiant sebelum pengembangan dimulai untuk menyelesaikan workshop arsitektur dan menerapkan kontrol keamanan sejak awal.
  • Berkolaborasi dengan pakar pemodelan ancaman untuk memetakan diagram alur data aplikasi Anda. Tentukan tempat data sensitif melintasi batas kepercayaan untuk mengidentifikasi tempat kontrol autentikasi, enkripsi, dan validasi yang ketat harus diterapkan.
  • Gunakan framework pemodelan ancaman terstruktur (seperti STRIDE) selama workshop arsitektur Anda. Konsultan Mandiant dapat membantu memprioritaskan kekurangan desain yang ditemukan berdasarkan eksploitasi di dunia nyata dan dampak bisnis.
  • Tetapkan dasar tata kelola AI yang aman untuk alur kerja agentic dan deployment LLM, dengan menentukan batas kepercayaan yang jelas antara agen AI, server MCP, dan sumber data backend perusahaan.

Model Armor

Model Armor dirancang untuk menyaring perintah, respons, dan panggilan alat MCP LLM. Model Armor memeriksa payload AI generatif untuk membantu mendeteksi dan memblokir injeksi perintah, upaya jailbreak, URL berbahaya, konten toksik, dan kebocoran data sensitif.

Berlaku untuk hal berikut:

  • A05: Injeksi
  • A10: Penanganan Kondisi Pengecualian yang Salah

Tinjau praktik terbaik berikut untuk A05: Injection:

  • Men-deploy kebijakan Model Armor secara inline di lapisan gateway API menggunakan integrasi Apigee atau Agent Gateway untuk menyaring perintah yang masuk dan respons model yang keluar sebelum traffic mencapai mesin inferensi atau runtime alat.
  • Konfigurasi setelan minimum di tingkat organisasi atau folder untuk membuat batas keamanan dasar wajib yang tidak dapat dilewati oleh masing-masing tim project.
  • Buat template Model Armor kustom dengan nilai minimum keyakinan yang disesuaikan (misalnya, LOW_AND_ABOVE atau MEDIUM_AND_ABOVE) untuk deteksi injeksi perintah dan upaya peretasan pada endpoint publik.
  • Aktifkan deteksi URL berbahaya serta pemindaian PDF dan file di template Model Armor Anda untuk memeriksa URL yang disematkan berdasarkan database threat intelligence Google. Menghapus perintah yang berisi vektor malware atau phishing sebelum dieksekusi.
  • Aktifkan Sensitive Data Protection di template Model Armoruntuk memeriksa traffic keluar model. Konfigurasi de-identifikasi atau penyamaran otomatis untuk mengganti data sensitif yang terdeteksi dengan placeholder sebelum respons keluar dari batas.

Tinjau praktik terbaik berikut untuk A10: Penanganan Kondisi Pengecualian yang Salah:

  • Konfigurasi kode aplikasi Anda untuk mencegat putusan MATCH_FOUND dan menampilkan respons umum, sehingga sistem tidak secara default mengeksekusi perintah atau mengekspos rekaman aktivitas pengecualian mentah.
  • Terapkan arsitektur fail-closed (fail-secure) dalam kode aplikasi Anda untuk menolak perintah AI generatif yang masuk jika panggilan Model Armor API mengalami waktu tunggu jaringan, batas kecepatan, atau error HTTP 5xx yang tidak tertangani.

Kebijakan Organisasi

Kebijakan Organisasi memberi Anda kontrol terpusat dan terprogram atas Google Cloud resource organisasi Anda.

Berlaku untuk hal berikut:

  • A01: Kontrol Akses yang Rusak
  • A02: Kesalahan Konfigurasi Keamanan
  • A04: Kegagalan Kriptografi

Tinjau praktik terbaik berikut untuk A01: Kontrol Akses yang Rusak:

  • Menerapkan constraints/storage.publicAccessPrevention untuk menggantikan kebijakan IAM atau ACL tingkat bucket yang mencoba memberikan akses ke allUsers atau allAuthenticatedUsers.
  • Terapkan constraints/iam.allowedPolicyMemberDomains untuk membatasi binding kebijakan IAM secara ketat ke ID pelanggan Google Workspace atau Cloud Identity terverifikasi Anda.
  • Terapkan constraints/iam.disableServiceAccountKeyCreation di seluruh folder produksi untuk membantu mencegah pengguna mendownload kunci akun layanan, sehingga memaksa tim engineering mengadopsi alternatif berjangka pendek seperti Federasi Identitas Beban Kerja.
  • Terapkan constraints/iam.automaticIamGrantsForDefaultServiceAccounts agar Google Cloud tidak otomatis memberikan peran Editor (roles/editor) yang permisif ke akun layanan default.
  • Untuk persyaratan yang tidak tercakup oleh batasan standar, deploy batasan kustom untuk menerapkan konfigurasi resource yang terperinci. Pertimbangkan untuk membatasi pembuatan VM hanya untuk family mesin yang disetujui, membatasi ukuran penyediaan disk persisten, atau mewajibkan konfigurasi tag firewall jaringan tertentu.

Tinjau praktik terbaik berikut untuk A02: Kesalahan Konfigurasi Keamanan:

Tinjau praktik terbaik berikut untuk A04: Kegagalan Kriptografi:

  • Untuk mewajibkan CMEK, terapkan constraints/gcp.restrictNonCmekServices di organisasi atau folder tingkat teratas, tetapkan jenis kebijakan ke Deny, dan cantumkan layanan Google Cloud yang didukung. Sebelum menerapkan batasan, verifikasi bahwa agen layanan untuk setiap layanan target ada dan diberi peran Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) pada ring kunci yang relevan.
  • Terapkan constraints/gcp.restrictCmekCryptoKeyProjects untuk membatasi pemilihan kunci ke project Cloud KMS khusus.

Secret Manager

Secret Manager memungkinkan aplikasi dan pipeline mengakses nilai secret yang diberi nama berdasarkan izin yang diberikan dengan IAM. Jika diaktifkan, interaksi dengan Secret Manager akan membuat jejak audit yang dapat Anda gunakan untuk membantu kebutuhan forensik dan kepatuhan.

Berlaku untuk hal berikut:

  • A04: Kegagalan Kriptografi
  • A07: Kegagalan Autentikasi

Tinjau praktik terbaik berikut untuk A04: Kegagalan Kriptografi:

Tinjau praktik terbaik berikut untuk A07: Kegagalan Autentikasi:

  • Hapus nilai sensitif seperti kunci API dari kode sumber, file .env, dan konfigurasi build penampung, lalu simpan kredensial di Secret Manager. Mengambil nilai yang didekripsi saat runtime menggunakan library klienGoogle Cloud , driver CSI Secret Store GKE, atau binding secret Cloud Run.
  • Terapkan binding kebijakan IAM langsung ke setiap rahasia, dengan memberikan peran Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) hanya pada rahasia tertentu yang diperlukan oleh microservice.
  • Mengonfigurasi jadwal rotasi otomatis di Secret Manager. Saat interval rotasi dimulai, Secret Manager memublikasikan notifikasi SECRET_ROTATE ke topik Pub/Sub yang ditentukan. Konfigurasi Cloud Run Functions atau layanan Cloud Run untuk membaca notifikasi, membuat nilai secret baru, menambahkan versi baru ke Secret Manager, dan menghancurkan versi yang tidak digunakan lagi.
  • Aktifkan Cloud Audit Logs di Secret Manager untuk melacak peristiwa pembuatan, penghancuran, dan akses payload versi rahasia. Rute log ini ke Google SecOps untuk memberikan pemberitahuan tentang peristiwa akses yang mencurigakan, seperti akun layanan yang disusupi mengakses secret di luar jam operasional standar atau mencoba membaca resource secret yang tidak disetujui.

Security Command Center Premium

Security Command Center Premium memungkinkan Anda menemukan dan mengatasi kesalahan konfigurasi keamanan dan ancaman runtime aktif, termasuk kegagalan identifikasi dan autentikasi, di lingkungan Google Cloud dan aplikasi web Anda. Layanan Web Security Scanner dapat memantau kerentanan aplikasi, termasuk kerentanan entity eksternal XML (XXE), dengan pemindaian yang dirancang untuk mencakup 10 kontrol teratas OWASP.

Berlaku untuk hal berikut:

  • A02: Kesalahan Konfigurasi Keamanan
  • A05: Injeksi
  • A07: Kegagalan Autentikasi
  • A08: Kegagalan Integritas Software atau Data

Tinjau praktik terbaik berikut untuk A02: Kesalahan Konfigurasi Keamanan:

  • Terapkan framework bawaan (seperti Tolok Ukur CIS atau NIST) menggunakan Compliance Manager untuk menilai konfigurasi cloud Anda terhadap framework keamanan peraturan dan tolok ukur industri.
  • Aktifkan Pengelolaan Hak Akses Infrastruktur Cloud untuk mengelola identitas yang memiliki akses ke resource dalam deployment cloud Anda dan mengurangi potensi kerentanan yang diakibatkan oleh kesalahan konfigurasi.
  • Tinjau dan perbaiki temuan Web Security Scanneruntuk memperbaiki header keamanan respons HTTP yang salah dikonfigurasi, header asal CORS yang tidak valid, dan penayangan konten campuran.

Tinjau praktik terbaik berikut untuk A05: Injection:

Tinjau praktik terbaik berikut untuk A07: Kegagalan Autentikasi:

Tinjau praktik terbaik berikut untuk A08: Kegagalan Integritas Software atau Data:

  • Konfigurasi Web Security Scanner untuk memindai endpoint web terkait bug eksekusi berbasis tanda tangan dan menghasilkan temuan STRUTS_INSECURE_DESERIALIZATION dengan tingkat keparahan tinggi jika aplikasi menjalankan versi Apache Struts yang rentan.
  • Atasi temuan STRUTS_INSECURE_DESERIALIZATION dengan mengupgrade versi library framework yang rentan atau men-deploy Assured OSS untuk menarik pengganti yang diverifikasi Google.

Sensitive Data Protection

Sensitive Data Protection memungkinkan Anda memindai semua data sensitif yang berpotensi disimpan dalam bucket, database, perintah AI generatif, atau payload aplikasi streaming untuk membantu mencegah kebocoran informasi yang tidak diinginkan. Jika data yang tidak diizinkan teridentifikasi, Sensitive Data Protection dapat melaporkan atau menyamarkannya.

Berlaku untuk hal berikut:

  • A04: Kegagalan Kriptografi
  • A09: Kegagalan Logging & Pemberitahuan Keamanan

Tinjau praktik terbaik berikut untuk A04: Kegagalan Kriptografi:

  • Aktifkan penemuan data sensitif untuk terus memindai aset penyimpanan dan database Anda, membuat profil data, dan melaporkan metrik untuk laporan audit.
  • Gunakan enkripsi yang tidak mengacak format, hashing kriptografi, atau tokenisasi berbasis kunci untuk melakukan de-identifikasi data sensitif.
  • Deploy template de-identifikasi yang dapat digunakan kembali dan dikelola secara terpusat untuk menerapkan kebijakan inspeksi dan penyamaran kriptografi yang konsisten di seluruh tim pengembangan.
  • Menganalisis payload perintah untuk membantu mencegah kebocoran data perusahaan yang sensitif atau PII ke pipeline pelatihan AI generatif.

Tinjau praktik terbaik berikut untuk A09: Kegagalan Logging & Pemberitahuan Keamanan:

  • Konfigurasi sink Logging Anda untuk mengirim log aplikasi ke topik Pub/Sub. Lampirkan pelanggan Cloud Run yang menggunakan Sensitive Data Protection API untuk memindai dan melakukan de-identifikasi payload log sebelum menulis log yang sudah dibersihkan ke bucket Logging akhir Anda.
  • Gunakan filter pengecualian di Sink logging untuk merutekan hanya log tidak terstruktur berisiko tinggi (seperti error aplikasi mentah, payload pendaftaran pengguna, dan log transaksi) melalui pipeline sanitasi.

VirusTotal

VirusTotal API adalah platform pemindaian file dan intelijen ancaman yang menganalisis file, URL, domain, dan alamat IP yang mencurigakan untuk mendeteksi malware, trojan, dan payload berbahaya. Dengan mengintegrasikan VirusTotal API ke dalam pipeline penyerapan file, Anda dapat memindai upload yang tidak tepercaya sebelum file diproses oleh sistem aplikasi.

Berlaku untuk hal berikut:

  • A08: Kegagalan Integritas Software atau Data
  • A05: Injeksi

Tinjau praktik terbaik berikut untuk A08: Kegagalan Integritas Software atau Data:

  • Men-deploy aturan pencocokan tanda tangan YARA-X kustom untuk memindai struktur file yang masuk untuk mencari pola biner dan tekstual berbahaya yang diketahui, sehingga memungkinkan deteksi varian malware yang bermutasi.

Tinjau praktik terbaik berikut untuk A05: Injection:

  • Gunakan modul Pemindaian Pribadi VirusTotal untuk memindai upload sensitif secara terpisah dan tidak membagikan file yang diupload kepada pihak ketiga.
  • Terapkan pembatasan frekuensi API dan penanganan pengecualian dalam kode penyerapan Anda untuk menangkap kode status HTTP 429 Too Many Requests.

Kontrol Layanan VPC

Kontrol Layanan VPC memungkinkan Anda membuat perimeter di sekitar resource Google Cloud untuk membantu mencegah pemindahan data yang tidak sah dan mengurangi serangan Pemalsuan Permintaan Sisi Server (SSRF). Kontrol Layanan VPC menolak panggilan API yang melewati batas perimeter kecuali jika diizinkan secara eksplisit oleh aturan ingress dan egress.

Berlaku untuk hal berikut:

  • A01: Kontrol Akses yang Rusak
  • A02: Kesalahan Konfigurasi Keamanan

Tinjau praktik terbaik berikut untuk A01: Kontrol Akses yang Rusak:

  • Sertakan layanan penting (seperti Cloud Storage, BigQuery, Spanner, dan Agent Platform) dalam perimeter layanan untuk membatasi akses API ke jaringan VPC yang diotorisasi dan identitas tepercaya.
  • Konfigurasi aturan perimeter keluar pada resource serverless untuk memblokir pemindahan data yang tidak sah yang disebabkan oleh panggilan API keluar ke tujuan eksternal di luar perimeter.
  • Batasi akses API lintas perimeter dan lintas organisasi menggunakan aturan masuk dan keluar yang eksplisit yang menentukan sumber project yang disetujui, target API, dan identitas pemanggil.

Tinjau praktik terbaik berikut untuk A02: Kesalahan Konfigurasi Keamanan:

  • Kelompokkan project ke dalam perimeter khusus yang diatur berdasarkan tingkat keamanan lingkungan (misalnya, perimeter produksi). Gunakan layanan yang dapat diakses VPC untuk membatasi API Google internal mana yang dapat dipanggil di dalam perimeter.
  • Merutekan permintaan API keluar dari workload serverless melalui jaringan VPC. Konfigurasi layanan Cloud Run dan fungsi Cloud Run untuk menggunakan traffic keluar VPC langsung atau Konektor Akses VPC Serverless dengan ingress yang ditetapkan secara ketat ke khusus internal.
  • Ikat tingkat akses Access Context Manager ke aturan masuk perimeter yang mengevaluasi kombinasi sub-jaringan IP perusahaan, klaim identitas yang diautentikasi, dan sinyal kesehatan perangkat Verifikasi Endpoint.
  • Pertahankan proses administratif breakglass yang telah disetujui sebelumnya untuk respons insiden darurat, dan siapkan Peringatan pemantauan pada setiap peristiwa pelanggaran perimeter yang tidak terduga.

Layanan Wiz

Bagian berikut menjelaskan praktik terbaik OWASP Top 10 untuk layanan Wiz yang terintegrasi dengan Google Cloud.

Wiz Code

Wiz Code memperluas keamanan cloud ke dalam alur kerja developer dan pipeline CI/CD. Wiz Code mengorelasikan telemetri kode ke cloud, memindai Infrastruktur sebagai Kode (IaC), menganalisis dependensi (SCA), mendeteksi kredensial yang terekspos, dan melakukan pengujian keamanan aplikasi statis (SAST).

Berlaku untuk hal berikut:

  • A03: Kegagalan Supply Chain Software
  • A05: Injeksi
  • A07: Kegagalan Autentikasi

Tinjau praktik terbaik berikut untuk A03: Kegagalan Supply Chain Software:

  • Integrasikan Wiz CLI ke dalam pipeline CI/CD untuk memblokir permintaan pull agar tidak digabungkan jika permintaan tersebut memperkenalkan CVE penting, secret yang terekspos, atau kesalahan konfigurasi IaC yang parah ke dalam cabang yang dilindungi.
  • Buat dan ekspor SBOM untuk setiap build guna mempertahankan visibilitas rantai pasokan berkelanjutan di Wiz Cloud.
  • Deploy ekstensi Wiz Code IDE untuk memberikan masukan developer secara real-time, menangkap paket yang rentan, kunci API yang dikodekan secara permanen, dan error sintaksis sebelum commit kode.
  • Integrasikan Wiz Code dengan CodeMender dalam pipeline CI/CD untuk membuat, menguji, dan mengirimkan permintaan pull saat dependensi pihak ketiga yang rentan terdeteksi.

Tinjau praktik terbaik berikut untuk A05: Injection:

  • Memblokir permintaan pull agar tidak digabungkan jika pemindai SAST mendeteksi input pengguna yang tidak tepercaya yang mengalir ke kueri database atau perintah OS tanpa sanitasi yang tepat.
  • Integrasikan plugin Wiz Code ke IDE developer untuk memberikan alert real-time jika developer mengetik kueri SQL atau pola eksekusi perintah yang tidak aman dan menggabungkan.
  • Saat Wiz Code menandai kelemahan injeksi, arahkan rekaman jejak aliran data ke CodeMender untuk menyusun patch perbaikan yang terverifikasi.

Tinjau praktik terbaik berikut untuk A07: Kegagalan Autentikasi:

  • Terapkan pemindaian rahasia otomatis di IDE developer, hook pra-commit lokal, dan di pipeline CI/CD untuk mendeteksi kredensial yang terekspos.
  • Untuk mengurangi pencurian kredensial, ganti kredensial statis yang memiliki masa berlaku lama dengan token dinamis yang memiliki masa berlaku singkat dan akses terikat identitas (seperti Workload Identity Federation atau autentikasi berbasis OIDC).
  • Terapkan playbook respons insiden otomatis untuk menghapus rahasia yang terdeteksi dari kode, variabel lingkungan, dan log build.

Wiz Cloud

Wiz Cloud menganalisis lingkungan multi-cloud untuk mengidentifikasi kesalahan konfigurasi keamanan, eksposur data sensitif, dan risiko identitas. Dengan menggunakan Wiz Security Graph, Wiz Cloud mengorelasikan faktor risiko di seluruh lapisan infrastruktur untuk menyoroti jalur serangan penting.

Berlaku untuk hal berikut:

  • A01: Kontrol Akses yang Rusak
  • A02: Kesalahan Konfigurasi Keamanan
  • A04: Kegagalan Kriptografi
  • A06: Desain yang Tidak Aman

Tinjau praktik terbaik berikut untuk A01: Kontrol Akses yang Rusak:

  • Melacak dan menandai jalur eskalasi hak istimewa multi-hop yang kompleks di seluruh peran dan kebijakan IAM untuk mengidentifikasi tempat penyerang dapat bergerak secara lateral atau meningkatkan hak istimewa.
  • Memetakan izin akses aktif di seluruh akun pengguna, akun layanan, dan agen AI ke penyimpanan data penting, serta mencabut hak istimewa yang berlebihan.
  • Mengintegrasikan temuan hak identitas dengan platform orkestrasi untuk mengganti binding peran administratif permanen dengan akses just-in-time (JIT).
  • Pantau dan visualisasikan pergerakan data untuk mendeteksi kapan PII produksi disalin atau disinkronkan ke lingkungan penyiapan atau pengembangan yang tidak aman.

Tinjau praktik terbaik berikut untuk A02: Kesalahan Konfigurasi Keamanan:

  • Menilai dan memprioritaskan risiko konfigurasi cloud dengan mengorelasikan kesalahan konfigurasi dengan berbagai faktor serangan menggunakan Wiz Security Graph.
  • Terapkan framework kepatuhan bawaan (seperti OWASP Top 10, CIS Benchmarks, dan NIST) untuk mengukur konfigurasi cloud terhadap standar industri.
  • Integrasikan pemindai Wiz CLI ke dalam pipeline CI/CD untuk meninjau build atau memperbaiki kesalahan konfigurasi IaC sebelum deployment.

Tinjau praktik terbaik berikut untuk A04: Kegagalan Kriptografi:

  • Prioritaskan perbaikan database dan bucket penyimpanan yang berisi kredensial teks biasa, kunci yang tidak di-hash, atau data sensitif yang disimpan tanpa enkripsi.
  • Jalankan penemuan data Wiz Cloud di seluruh direktori pelatihan AI, database vektor, dan pipeline RAG untuk memverifikasi bahwa data eksklusif dan PII disamarkan sebelum penyerapan LLM.
  • Pindai lingkungan untuk mengidentifikasi aset data yang tidak terkelola dan hapus data yang berlebihan untuk meminimalkan permukaan serangan Anda.

Tinjau praktik terbaik berikut untuk A06: Desain yang Tidak Aman:

  • Arahkan Wiz Red Agent untuk menganalisis antarmuka arsitektur logis dan menyimulasikan jalur serangan untuk menemukan kelemahan desain yang tidak aman sebelum deployment produksi.
  • Meneruskan konteks rantai serangan yang divalidasi dari Wiz Red Agent ke CodeMender untuk mengidentifikasi akar masalah dan membuat permintaan pull arsitektur yang telah diuji.

Wiz Defend

Wiz Defend menyediakan deteksi dan respons cloud (CDR), perlindungan runtime workload, dan keamanan penerimaan Kubernetes. Wiz Defend memantau aktivitas bidang kontrol, mendeteksi anomali runtime, menerapkan kebijakan penerimaan penampung, dan memicu penanganan otomatis.

Berlaku untuk hal berikut:

  • A08: Kegagalan Integritas Software atau Data
  • A09: Kegagalan Logging & Pemberitahuan Keamanan

Tinjau praktik terbaik berikut untuk A08: Kegagalan Integritas Software atau Data:

  • Konfigurasi aturan penerimaan Wiz Defend untuk memeriksa dan menolak manifes deployment Kubernetes yang mencoba menjalankan container dengan hak istimewa root, meminta namespace jaringan host, atau mengaktifkan privileged: true.
  • Konfigurasi webhook penerimaan keamanan penting dengan failurePolicy: Fail (fail-closed) dalam produksi untuk memblokir container yang tidak tepercaya jika webhook tidak dapat dijangkau.

Tinjau praktik terbaik berikut untuk A09: Kegagalan Logging & Pemberitahuan Keamanan:

  • Ekspor Google Cloud log audit menggunakan sink log ke topik Pub/Sub agar Wiz Defend dapat menyerap dan menganalisis aktivitas control plane dan peristiwa workload.
  • Deploy Wiz Runtime Sensor di cluster GKE dan VM Compute Engine bernilai tinggi untuk mendeteksi ancaman runtime, eksploitasi dalam memori, dan kompromi aktif.
  • Mengotomatiskan playbook pembatasan untuk segera menonaktifkan akun layanan IAM yang disusupi atau mengisolasi workload yang disusupi.
  • Gunakan Wiz Blue Agent untuk menyelidiki deteksi runtime, yang mengorelasikan telemetri proses langsung dan konteks identitas untuk menentukan penyebab utama dan aset yang terpengaruh.

Mempertahankan kepatuhan terhadap OWASP Top 10:2025

Wiz menyertakan framework kepatuhan OWASP Top 10 2025 yang memungkinkan Anda menilai dan memantau postur keamanan Anda. Framework kepatuhan OWASP Top 10 2025 memetakan kebijakan Wiz bawaan ke kategori risiko OWASP yang relevan dan membuat temuan jika kontrol tidak mematuhi. Anda dapat melacak skor kepatuhan Anda dari waktu ke waktu. Jika diperlukan, Anda dapat menyesuaikan framework kepatuhan OWASP Top 10 2025 agar sesuai dengan persyaratan bisnis Anda.

Langkah berikutnya

Tinjau katalog praktik terbaik keamanan untuk mengetahui praktik terbaik tambahan.