Ringkasan kebijakan keamanan

Halaman ini menjelaskan cara menggunakan kebijakan keamanan Google Cloud Armor untuk melindungi deployment Cloud de Confiance by S3NS Anda.

Kebijakan keamanan Cloud Armor tersedia untuk Load Balancer Aplikasi eksternal regional.

Backend ke layanan backend dapat berupa salah satu dari berikut:

• Grup instance
• Semua jenis grup endpoint jaringan (NEG) yang didukung oleh load balancer Anda

Saat Anda menggunakan Cloud Armor untuk melindungi deployment hybrid atau arsitektur multicloud, backend harus berupa NEG internet atau NEG hybrid. Cloud Armor juga melindungi NEG tanpa server saat traffic dirutekan melalui load balancer. Untuk mengetahui informasi tentang cara merutekan traffic melalui load balancer sebelum mencapai NEG tanpa server, lihat Kontrol ingress.

Melindungi deployment Cloud de Confiance Anda dengan kebijakan keamanan Cloud Armor

Kebijakan keamanan Cloud Armor memungkinkan Anda mengizinkan, menolak, membatasi kapasitas, atau mengalihkan permintaan ke layanan backend Anda di Cloud de Confiance edge, sedekat mungkin dengan sumber traffic masuk. Hal ini mencegah traffic yang tidak diinginkan menggunakan resource atau memasuki jaringan Virtual Private Cloud (VPC) Anda.

Persyaratan

• Skema load balancing layanan backend harus berupa EXTERNAL_MANAGED.
• Protokol layanan backend harus berupa salah satu dari HTTP, HTTPS, HTTP/2, UDP, TCP, SSL, atau UNSPECIFIED.

Tentang kebijakan keamanan Cloud Armor

Kebijakan keamanan Cloud Armor adalah serangkaian aturan yang cocok dengan atribut dari jaringan Lapisan 3 hingga Lapisan 7 untuk melindungi aplikasi atau layanan yang dapat diakses dari luar. Setiap aturan dievaluasi sehubungan dengan traffic masuk.

Aturan kebijakan keamanan Cloud Armor terdiri dari kondisi kecocokan dan tindakan yang harus dilakukan saat kondisi tersebut terpenuhi. Misalnya, kondisi dapat berupa apakah alamat IP klien dari traffic masuk cocok dengan alamat IP tertentu atau rentang CIDR (juga dikenal sebagai aturan daftar yang diizinkan dan daftar tolak untuk alamat IP). Alternatifnya, dengan menggunakan referensi bahasa aturan khusus Cloud Armor, Anda dapat membuat kondisi kustom yang cocok dengan berbagai atribut traffic masuk, seperti jalur URL, metode permintaan, atau nilai header permintaan.

Saat permintaan masuk cocok dengan kondisi dalam aturan kebijakan keamanan, Cloud Armor akan mengizinkan, menolak, atau mengalihkan permintaan, berdasarkan apakah aturan tersebut adalah aturan izin, aturan penolakan, atau aturan pengalihan.

Cloud Armor menyediakan dua kategori kebijakan keamanan: kebijakan keamanan hierarkis dan kebijakan keamanan tingkat layanan. Kebijakan keamanan hierarkis dilampirkan di tingkat organisasi, folder, atau project, sedangkan kebijakan keamanan tingkat layanan dikaitkan dengan satu atau beberapa layanan backend. Untuk mengetahui informasi selengkapnya tentang kebijakan keamanan hierarkis, lihat Ringkasan kebijakan keamanan hierarkis.

Layanan backend dapat memiliki dua kebijakan keamanan tingkat layanan yang terkait dengannya secara bersamaan, tetapi tidak dapat memiliki dua kebijakan keamanan backend atau dua kebijakan keamanan edge secara bersamaan. Namun, semua layanan backend Anda tidak harus dikaitkan dengan kebijakan keamanan yang sama. Untuk melampirkan dan menghapus kebijakan keamanan dari layanan dan fitur backend yang didukung, lihat Melampirkan dan menghapus kebijakan keamanan.

Jika kebijakan keamanan Cloud Armor dikaitkan dengan layanan backend apa pun, kebijakan tersebut tidak dapat dihapus. Layanan backend dapat dihapus, terlepas dari apakah layanan tersebut memiliki kebijakan keamanan terkait.

Jika beberapa aturan penerusan mengarah ke layanan backend yang memiliki kebijakan keamanan terkait, aturan kebijakan akan diterapkan untuk semua traffic yang masuk ke setiap alamat IP aturan penerusan.

Dalam diagram berikut, kebijakan keamanan Cloud Armor internal-users-policy dikaitkan dengan layanan backend test-network.

• Anda dapat secara opsional menggunakan protokol QUIC dengan load balancer yang menggunakan Cloud Armor.

• Anda dapat menggunakan kebijakan keamanan backend dengan GKE dan pengontrol ingress default.

• Anda dapat menggunakan kebijakan keamanan default untuk membatasi traffic yang melebihi batas yang ditentukan pengguna saat Anda mengonfigurasi Load Balancer Aplikasi eksternal regional.

Selain itu, Anda dapat mengonfigurasi aturan WAF yang telah dikonfigurasi sebelumnya di Google Cloud Armor, yang merupakan aturan firewall aplikasi web (WAF) kompleks dengan puluhan signature yang dikompilasi dari standar industri open source. Setiap signature sesuai dengan aturan deteksi serangan dalam rangkaian aturan. Google menawarkan aturan ini apa adanya. Aturan ini memungkinkan Cloud Armor mengevaluasi puluhan signature traffic yang berbeda dengan merujuk pada aturan yang diberi nama dengan mudah, alih-alih mengharuskan Anda menentukan setiap signature secara manual. Untuk mengetahui informasi selengkapnya tentang aturan WAF yang telah dikonfigurasi sebelumnya, lihat ringkasan aturan WAF yang telah dikonfigurasi sebelumnya.

Jenis kebijakan keamanan

Tabel berikut menunjukkan jenis kebijakan keamanan tingkat layanan dan semua yang dapat Anda lakukan dengannya. Tanda centang () menunjukkan bahwa jenis kebijakan keamanan mendukung fitur tersebut.

Kebijakan keamanan backend

Kebijakan keamanan backend memiliki nilai flag type opsional CLOUD_ARMOR. Jika Anda tidak menetapkan flag type, nilai defaultnya adalah CLOUD_ARMOR.

Kebijakan keamanan layanan internal

Kebijakan keamanan layanan internal memungkinkan Anda mengonfigurasi pembatasan kapasitas fairshare dengan Cloud Service Mesh. Anda harus melampirkan kebijakan keamanan layanan internal ke kebijakan endpoint Cloud Service Mesh, bukan ke layanan backend atau bucket backend. Untuk mempelajari lebih lanjut tentang kebijakan keamanan layanan internal, lihat Mengonfigurasi pembatasan kapasitas dengan Cloud Armor di dokumentasi Cloud Service Mesh.

Urutan evaluasi aturan

Urutan evaluasi aturan ditentukan oleh prioritas aturan, dari nomor terendah hingga nomor tertinggi. Aturan dengan nilai numerik terendah yang ditetapkan memiliki prioritas logis tertinggi dan dievaluasi sebelum aturan dengan prioritas logis yang lebih rendah. Prioritas numerik minimum adalah 0. Prioritas aturan menurun seiring bertambahnya nomor (1, 2, 3, N+1). Anda tidak dapat mengonfigurasi dua aturan atau lebih dengan prioritas yang sama. Prioritas untuk setiap aturan harus ditetapkan ke nomor dari 0 hingga 2147483646 inklusif. Nilai prioritas 2147483647, juga dikenal sebagai INT-MAX, dicadangkan untuk aturan default.

Angka prioritas dapat memiliki kesenjangan. Dengan adanya kesenjangan ini, Anda dapat menambahkan atau menghapus aturan di masa mendatang tanpa memengaruhi aturan lainnya. Misalnya, 1, 2, 3, 4, 5, 9, 12, 16 adalah rangkaian nomor prioritas yang valid, yang memungkinkan Anda menambahkan aturan bernomor 6 hingga 8, 10 hingga 11, dan 13 hingga 15 di masa mendatang. Anda tidak perlu mengubah aturan yang ada, kecuali urutan eksekusinya.

Biasanya, aturan prioritas tertinggi yang cocok dengan permintaan akan diterapkan. Namun, terdapat pengecualian saat permintaan dengan isi dievaluasi berdasarkan aturan yang telah dikonfigurasi sebelumnya yang menggunakan evaluatePreconfiguredWaf. Pengecualiannya adalah sebagai berikut:

Untuk permintaan dengan isi, Cloud Armor menerima header permintaan sebelum isi (payload). Karena menerima informasi header terlebih dahulu, Cloud Armor mengevaluasi aturan yang cocok dengan header, tetapi tidak cocok dengan aturan yang telah dikonfigurasi sebelumnya pada isi. Jika terdapat beberapa aturan berbasis header, Cloud Armor akan mengevaluasinya berdasarkan prioritasnya, seperti yang diharapkan. Perhatikan bahwa tindakan redirect dan penyisipan tindakan header kustom hanya berfungsi selama fase pemrosesan header. Tindakan redirect, jika cocok selama fase pemrosesan isi berikut, akan diterjemahkan ke tindakan deny. Tindakan header permintaan kustom, jika cocok selama fase pemrosesan isi, tidak akan berlaku.

Setelah menerima isi permintaan, Cloud Armor akan mengevaluasi aturan yang berlaku untuk header maupun isi permintaan. Karena itu, aturan prioritas yang lebih rendah dan yang mengizinkan header permintaan dapat dicocokkan sebelum aturan prioritas yang lebih tinggi dan memblokir isi permintaan. Dalam kasus tersebut, bagian header HTTP dari permintaan mungkin dikirim ke layanan backend target, tetapi isi dengan konten yang berpotensi berbahaya akan diblokir. Cloud Armor memeriksa hingga 64 kB pertama (sesuai dengan batas pemeriksaan yang dikonfigurasi, yaitu 8 kB, 16 kB, 32 kB, 48 kB, atau 64 kB) dari isi permintaan. Untuk mengetahui informasi selengkapnya tentang batasan ini, lihat Batasan pemeriksaan isi permintaan.

Ekspresi evaluatePreconfiguredWaf() untuk aturan yang telah dikonfigurasi sebelumnya adalah satu-satunya ekspresi yang dievaluasi berdasarkan isi permintaan. Semua ekspresi lainnya dievaluasi hanya berdasarkan header permintaan. Pemeriksaan isi terbatas pada batas pemeriksaan yang dikonfigurasi, hingga 64 kB pertama (baik 8 kB, 16 kB, 32 kB, 48 kB, atau 64 kB) dari isi permintaan dan didekode seperti parameter kueri URL. Cloud Armor dapat mengurai dan menerapkan aturan WAF yang telah dikonfigurasi sebelumnya untuk isi berformat JSON (Content-Type = "application/json"). Namun, Cloud Armor tidak mendukung decoder berbasis Content-Type/Content-Encoding HTTP lainnya seperti XML, Gzip, atau UTF-16.

Contoh

Dalam contoh berikut, aturan 1, 2, dan 3 dievaluasi dalam urutan tersebut untuk kolom header IP dan HTTP. Namun, jika alamat IP 9.9.9.1 meluncurkan serangan XSS dalam isi, hanya isi yang diblokir (oleh aturan 2). Header HTTP diteruskan ke backend (oleh aturan 3).

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: evaluatePreconfiguredWaf('xss-stable')
action: deny(403)
priority: 2
Rule3
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 3
Rule-default
action: deny(403)
priority: INT-MAX

Dalam contoh berikut, kebijakan mengizinkan IP 9.9.9.1 tanpa memindai berdasarkan serangan XSS:

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 2
Rule3
expr: evaluatePreconfiguredWaf('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX

Aturan default

Setiap kebijakan keamanan Cloud Armor berisi aturan default yang dicocokkan jika tidak ada aturan prioritas lebih tinggi yang cocok atau jika tidak ada aturan lain dalam kebijakan. Aturan default otomatis diberi prioritas 2147483647 (INT-MAX), dan selalu ada dalam kebijakan keamanan.

Anda tidak dapat menghapus aturan default, tetapi dapat mengubahnya. Tindakan default untuk aturan default adalah deny, tetapi Anda dapat mengubah tindakan menjadi allow.

Sidik jari

Setiap kebijakan keamanan Cloud Armor memiliki kolom fingerprint. Sidik jari adalah hash konten yang disimpan dalam kebijakan. Saat Anda membuat kebijakan baru, jangan berikan nilai kolom ini. Jika Anda memberikan nilai, nilai tersebut akan diabaikan. Namun, saat memperbarui kebijakan keamanan, Anda harus menentukan sidik jari saat ini, yang Anda dapatkan saat mengekspor atau mendeskripsikan kebijakan (masing-masing menggunakan EXPORT atau DESCRIBE).

Sidik jari melindungi Anda agar tidak mengganti update pengguna lain. Jika sidik jari yang Anda berikan sudah tidak berlaku, berarti kebijakan keamanan telah diperbarui sejak terakhir kali Anda mengambil sidik jari. Untuk memeriksa perbedaan dan mengambil sidik jari terbaru, jalankan perintah DESCRIBE.

Bahasa aturan dan mesin penerapan

Bahasa aturan dan mesin penerapan menyediakan hal berikut:

• Kemampuan untuk menulis ekspresi aturan khusus yang dapat mencocokkan berbagai atribut permintaan masuk Layer 3 hingga Layer 7. Cloud Armor menyediakan atribut bahasa aturan khusus untuk menulis kondisi kecocokan kustom.

• Kemampuan untuk menggabungkan hingga 5 subekspresi dalam satu aturan.

• Kemampuan untuk menolak atau mengizinkan permintaan berdasarkan kode region permintaan yang masuk. Kode region didasarkan pada kode ISO 3166-1 alpha 2. Kode region terkadang sesuai dengan negara tertentu, tetapi beberapa kode mencakup negara beserta area terkaitnya. Misalnya, kode US mencakup semua negara bagian Amerika Serikat, satu distrik, dan enam area terpencil.

Jenis aturan

Cloud Armor memiliki jenis aturan berikut.

Aturan daftar yang diizinkan dan daftar tolak untuk alamat IP

Anda dapat membuat aturan daftar yang diizinkan dan daftar tolak untuk alamat IP dalam kebijakan keamanan. Beberapa contoh mencakup hal berikut:

Anda dapat membuat aturan daftar yang diizinkan dan daftar tolak untuk alamat IP dalam kebijakan keamanan. Beberapa contoh mencakup hal berikut:

• Penambahan alamat IP atau rentang CIDR ke daftar tolak memungkinkan Anda memblokir alamat IP klien atau rentang CIDR agar tidak mengakses load balancer yang didukung.

• Dengan menambahkan alamat IP atau rentang CIDR ke daftar yang diizinkan, Anda dapat mengizinkan alamat IP klien atau rentang CIDR untuk mengakses load balancer yang didukung.

• Alamat IPv4 dan IPv6 didukung dalam aturan daftar yang diizinkan dan daftar tolak.

• Aturan penolakan dapat menampilkan kode status HTTP 403 Unauthorized, 404 Access Denied, atau 502 Bad Gateway.

• Aturan tindakan yang melebihi batas dapat menampilkan kode status HTTP 429 Too Many Requests.

Aturan geografi klien

Anda dapat mengizinkan atau menolak permintaan yang berasal dari area geografis tertentu yang ditentukan oleh kode negara Unicode.

Cloud Armor menggunakan database geolokasi IP kami sendiri untuk mengidentifikasi lokasi geografis permintaan. Database diperbarui secara rutin. Meskipun kami tidak dapat menjamin frekuensi update tertentu, selama operasi normal, pemetaan yang digunakan Cloud Armor diperbarui sekitar seminggu sekali.

Pemetaan yang diperbarui harus disebarkan ke infrastruktur Google secara global. Proses peluncuran terjadi secara bertahap, biasanya selama beberapa hari, di beberapa zona dan region tempat Cloud Armor di-deploy. Karena proses peluncuran bertahap ini, permintaan dari alamat IP klien yang sama mungkin ditangani secara tidak konsisten selama peluncuran saat pemetaan geolokasi untuk alamat IP klien telah berubah.

Aturan WAF yang telah dikonfigurasi sebelumnya

Cloud Armor menyediakan daftar lengkap aturan WAF yang telah dikonfigurasi sebelumnya berdasarkan OWASP Core Rule Set (CRS) untuk membantu Anda mendeteksi hal-hal berikut:

• Serangan injeksi SQL
• Serangan pembuatan skrip lintas situs
• Serangan penyertaan file lokal
• Serangan penyertaan file jarak jauh
• Serangan eksekusi kode jarak jauh
• Serangan penerapan metode
• Serangan deteksi pemindai
• Serangan protokol
• Serangan injeksi PHP
• Serangan fiksasi sesi
• Serangan Java
• Serangan NodeJS

Untuk mengetahui detailnya, lihat Ringkasan aturan WAF yang telah dikonfigurasi sebelumnya oleh Cloud Armor.

Aturan pembatasan kapasitas

Anda dapat menggunakan aturan pembatasan kapasitas untuk melakukan hal berikut:

• Membatasi permintaan per klien berdasarkan batas yang Anda konfigurasi.
• Memblokir sementara klien yang melebihi batas permintaan yang Anda tetapkan untuk durasi yang dikonfigurasi.

Saat Anda menggunakan pembatasan kapasitas dengan Load Balancer Jaringan proxy eksternal global atau Load Balancer Jaringan proxy klasik, batasan berikut berlaku:

• Cloud Armor hanya menerapkan tindakan pembatasan kapasitas seperti pembatasan atau pemblokiran pada permintaan koneksi baru dari klien.
• Hanya jenis kunci ALL dan IP yang didukung.
• Jika Anda mencoba menggunakan jenis kunci HTTP-HEADER atau HTTP-COOKIE dengan load balancer TCP/SSL, jenis kunci akan ditafsirkan sebagai ALL, dan XFF-IP juga ditafsirkan sebagai IP.

Untuk mengetahui informasi selengkapnya tentang pembatasan kapasitas dan cara kerjanya, lihat Ringkasan pembatasan kapasitas.

Mode pratinjau

Anda dapat melihat pratinjau efek aturan tanpa menerapkannya. Dalam mode pratinjau, tindakan dicatat di Cloud Monitoring. Anda dapat memilih untuk melihat pratinjau setiap aturan dalam kebijakan keamanan, atau Anda dapat melihat pratinjau setiap aturan dalam kebijakan. Anda akan dikenai biaya per permintaan normal untuk aturan dalam mode pratinjau.

Anda dapat mengaktifkan mode pratinjau untuk aturan menggunakan Google Cloud CLI dan flag --preview dari perintah gcloud compute security-policies rules update.

Untuk menonaktifkan mode pratinjau, gunakan flag --no-preview. Anda juga dapat menggunakan konsolCloud de Confiance .

Jika permintaan memicu pratinjau, Cloud Armor akan terus mengevaluasi aturan lain hingga menemukan kecocokan. Aturan yang cocok dan aturan pratinjau tersedia di log.

Respons error kustom

Saat menggunakan Load Balancer Aplikasi eksternal global, Anda dapat mengonfigurasi respons error kustom untuk kode status HTTP bagi error yang dihasilkan load balancer atau instance backend. Selain itu, Anda dapat mengonfigurasi kode error kustom untuk traffic yang ditolak Cloud Armor dengan mengonfigurasi halaman respons kustom untuk kode status seri 4xx atau seri 5xx yang sama, yang digunakan oleh aturan kebijakan keamanan yang ada.

Untuk mengetahui informasi selengkapnya tentang respons error kustom, lihat Ringkasan respons error kustom. Untuk langkah-langkah konfigurasi, lihat Mengonfigurasi respons error kustom.

Logging

Cloud Armor memiliki logging yang ekstensif dan memungkinkan Anda menentukan seberapa panjang logging Anda. Log Cloud Armor dibuat berdasarkan aturan pertama (prioritas tertinggi) yang cocok dengan permintaan masuk, terlepas dari apakah kebijakan keamanan dalam mode pratinjau atau tidak. Artinya, log tidak dibuat untuk aturan yang tidak cocok, atau untuk aturan yang cocok dengan prioritas yang lebih rendah.

Untuk mengetahui informasi selengkapnya tentang logging, lihat Menggunakan logging permintaan. Untuk mengetahui informasi selengkapnya tentang logging panjang, lihat Logging panjang. Untuk melihat log Cloud Armor, lihat Melihat log.

Batasan

Bagian berikut menjelaskan batasan untuk kebijakan keamanan.

Batasan pemeriksaan isi permintaan

Ekspresi evaluatePreconfiguredWaf untuk aturan yang telah dikonfigurasi sebelumnya adalah satu-satunya ekspresi yang dievaluasi Cloud Armor berdasarkan isi permintaan. Di antara jenis permintaan HTTP dengan isi permintaan, Cloud Armor hanya memproses permintaan dengan isi.

Pemeriksaan dibatasi hingga batas pemeriksaan yang dikonfigurasi, hingga 64 kB pertama (baik 8 kB, 16 kB, 32 kB, 48 kB, atau 64 kB) dari isi permintaan. Untuk mempelajari lebih lanjut tentang cara mengonfigurasi batas pemeriksaan untuk isi permintaan saat menggunakan aturan WAF yang telah dikonfigurasi sebelumnya, lihat Memperbarui batas pemeriksaan untuk aturan WAF yang telah dikonfigurasi sebelumnya.

Bagian isi permintaan lainnya mungkin berisi payload yang akan cocok dengan signature aturan WAF, yang mungkin diterima aplikasi Anda. Untuk mengurangi risiko isi permintaan yang ukurannya melebihi batas pemeriksaan yang dikonfigurasi, hingga 64 kB pertama (baik 8 kB, 16 kB, 32 kB, 48 kB, atau 64 kB), lihat Mengurangi risiko pada isi permintaan yang melebihi batas pemeriksaan yang dikonfigurasi.

Cloud Armor dapat mengurai dan menerapkan aturan WAF yang telah dikonfigurasi sebelumnya untuk isi permintaan yang dienkode URL secara default dan berformat JSON (Content-Type = "application/json"), yang dalam hal ini, aturan diterapkan secara independen pada nama dan nilai yang didekode dalam data. Untuk jenis konten dan jenis encoding lainnya, Cloud Armor tidak mendekode data, tetapi menerapkan aturan yang telah dikonfigurasi sebelumnya pada data mentah.

Cara penanganan koneksi WebSocket

Load Balancer Aplikasi eksternal global memiliki dukungan bawaan untuk protokol WebSocket. Saluran WebSocket dimulai dari permintaan HTTP(S). Cloud Armor dapat mencegah pembuatan saluran WebSocket, misalnya, jika daftar alamat IP yang ditolak memblokir alamat IP klien. Namun, transaksi berikutnya di saluran tidak sesuai dengan protokol HTTP, dan Cloud Armor tidak mengevaluasi pesan apa pun setelah permintaan pertama.

Cara penanganan koneksi gRPC

Load Balancer Aplikasi eksternal global memiliki dukungan bawaan untuk protokol gRPC. gRPC adalah framework open source yang menggunakan HTTP/2 sebagai protokol dasarnya. Panggilan gRPC dimulai dari permintaan HTTP(S) POST. Anda dapat mengonfigurasi Cloud Armor untuk mencegah pembuatan panggilan gRPC, misalnya, dengan menggunakan daftar alamat IP yang ditolak, yang memblokir alamat IP klien. Namun, Anda mungkin melihat bahwa load balancer masih melaporkan respons kode status HTTP 200 OK dalam log dan metriknya. Hal ini tidak berarti bahwa Cloud Armor tidak berfungsi sebagaimana mestinya.

Langkah berikutnya

• Mengonfigurasi kebijakan keamanan Cloud Armor
• Memecahkan masalah Cloud Armor