Kasus penggunaan umum untuk kebijakan keamanan

Halaman ini menampilkan kasus penggunaan umum untuk kebijakan keamanan Google Cloud Armor. Kebijakan keamanan Cloud Armor dapat melindungi aplikasi Anda dengan fitur seperti daftar IP yang diizinkan dan ditolak, serta aturan yang telah dikonfigurasi sebelumnya untuk mencegah serangan web umum.

Mengontrol akses ke aplikasi dan layanan web Anda

Bagian ini menyajikan beberapa cara untuk menggunakan kebijakan keamanan Cloud Armor guna mengontrol akses ke aplikasi atau layanan Anda.

Mengaktifkan akses untuk pengguna di alamat IP tertentu dengan daftar yang diizinkan

Kasus penggunaan umum untuk menempatkan alamat IP pengguna dalam daftar yang diizinkan adalah saat Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik Anda hanya diakses oleh sekumpulan pengguna tertentu. Dalam contoh berikut, hanya pengguna dari organisasi Anda yang diizinkan mengakses layanan di balik load balancer Anda. Pengguna ini memiliki alamat IP atau blok alamat yang ditetapkan oleh organisasi Anda. Anda dapat menempatkan alamat IP atau rentang CIDR ini dalam daftar yang diizinkan sehingga hanya pengguna ini yang memiliki akses ke load balancer.

Anda mengontrol akses ke Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik dengan mengonfigurasi daftar yang diizinkan dengan alamat IP sumber atau rentang CIDR sumber yang diizinkan untuk mengakses load balancer Anda. Bagian berikut menjelaskan lebih lanjut konfigurasi ini.

Dalam konfigurasi ini, Anda hanya ingin mengizinkan pengguna dari organisasi Anda dengan alamat IP dari rentang IP untuk mengakses Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik. Anda ingin semua traffic lainnya ditolak.

Untuk membuat konfigurasi ini, ikuti langkah-langkah berikut:

1. Buat kebijakan keamanan Cloud Armor.
2. Dalam kebijakan keamanan, tambahkan aturan yang menambahkan rentang ke daftar yang diizinkan sebagai aturan pertama. Aturan ini memiliki deskripsi allow [RANGE], dengan [RANGE] adalah rentang IP yang diinginkan.
3. Ubah aturan default dalam kebijakan dari aturan izin menjadi aturan penolakan. Aturan default mengatur traffic yang tidak cocok dengan aturan sebelumnya. Ini adalah aturan terakhir dalam kebijakan. Mengubah aturan dari allow menjadi deny akan memblokir semua traffic yang tidak berasal dari rentang dalam daftar yang diizinkan.
4. Kaitkan kebijakan ini dengan Load Balancer Aplikasi eksternal global atau layanan backend Load Balancer Aplikasi klasik.

Jika organisasi Anda menggunakan penyedia keamanan pihak ketiga untuk membersihkan traffic, Anda dapat menambahkan alamat IP penyedia keamanan ke daftar yang diizinkan untuk memastikan bahwa hanya traffic yang telah dibersihkan yang dapat mengakses Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik dan backend.

Dalam ilustrasi berikut, penyedia pihak ketiga diidentifikasi oleh rentang CIDR 192.0.2.0/24, dan rentang ini ada dalam daftar yang diizinkan.

Memblokir akses untuk pengguna di alamat IP tertentu dengan daftar yang tidak diizinkan

Gunakan daftar tolak untuk membuat kebijakan keamanan Cloud Armor yang menolak traffic dari alamat IP atau rentang CIDR. Dalam ilustrasi berikut, kebijakan keamanan Cloud Armor memiliki aturan deny yang memblokir traffic dari alamat IP 198.51.100.1, tempat pengguna berbahaya telah diidentifikasi.

Aturan kustom untuk memfilter berdasarkan parameter Lapisan 3 hingga Lapisan 7

Gunakan bahasa aturan kustom Cloud Armor untuk menentukan satu atau beberapa ekspresi dalam kondisi kecocokan aturan. Saat menerima permintaan, Cloud Armor mengevaluasi permintaan tersebut berdasarkan ekspresi ini. Jika ada kecocokan, tindakan aturan akan berlaku, baik menolak atau mengizinkan traffic masuk.

Contoh berikut adalah ekspresi yang ditulis dalam ekstensi Cloud Armor dari Common Expression Language (CEL). Untuk mengetahui informasi selengkapnya, lihat Referensi bahasa aturan kustom.

Untuk menentukan ekspresi dalam aturan, gunakan flag --expression gcloud atau konsolTrusted Cloud . Untuk mengetahui informasi selengkapnya, lihat Membuat kebijakan, aturan, dan ekspresi keamanan Cloud Armor.

Dalam contoh berikut, permintaan dari 2001:db8::/32 (seperti penguji alfa Anda) di region AU cocok dengan ekspresi berikut:

origin.region_code == "AU" && inIpRange(origin.ip, '2001:db8::/32')

Contoh berikut cocok dengan permintaan dari 192.0.2.0/24 dan dengan agen pengguna yang berisi string WordPress:

inIpRange(origin.ip, '192.0.2.0/24') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')

Untuk contoh tambahan, lihat Contoh ekspresi dalam referensi bahasa aturan kustom.

Melindungi deployment Anda dari serangan lapisan aplikasi dan membantu memitigasi 10 risiko teratas versi OWASP

Anda dapat menggunakan Cloud Armor untuk melindungi server asal Cloud CDN dari serangan lapisan aplikasi (L7) seperti injeksi SQL (SQLi) dan pembuatan skrip lintas situs (XSS). Konten dalam cache bersifat statis dan mungkin tidak menimbulkan risiko serangan bertarget dari web. Namun, server asal konten yang mendasarinya mungkin merupakan aplikasi dinamis dengan kerentanan aplikasi web yang diketahui atau potensial. Persyaratan keamanan atau kepatuhan Anda mungkin mengharuskan Anda memitigasi risiko ini untuk mencegah eksploitasi kerentanan dari internet berhasil menyerang server asal.

Untuk mengurangi risiko, ikuti langkah-langkah berikut:

1. Buat atau identifikasi layanan backend dengan CDN yang diaktifkan.
2. Buat kebijakan keamanan Cloud Armor.
3. Buat satu atau beberapa aturan dalam kebijakan keamanan untuk menolak serangan L7.
4. Konfigurasi salah satu target kebijakan keamanan sebagai layanan backend yang Anda buat atau identifikasi pada langkah 1.

Anda juga dapat menggunakan aturan yang telah dikonfigurasi sebelumnya untuk mendeteksi dan memblokir serangan umum di lapisan aplikasi. Aturan yang telah dikonfigurasi sebelumnya adalah set ekspresi yang telah ditentukan sebelumnya yang dapat Anda tambahkan ke kebijakan keamanan Cloud Armor. Untuk menambahkan set ekspresi ini ke aturan, gunakan flag gcloud --expression atau konsol Trusted Cloud . Untuk mengetahui informasi selengkapnya, lihat Membuat kebijakan, aturan, dan ekspresi keamanan.

Aturan yang telah dikonfigurasi sebelumnya memeriksa hingga 8 kB pertama isi permintaan secara default. Namun, Anda dapat mengonfigurasi batas ini per kebijakan. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi batas pemeriksaan ini untuk isi permintaan saat menggunakan aturan WAF yang telah dikonfigurasi sebelumnya, lihat Batasan pemeriksaan isi POST dan PATCH.

Untuk mengetahui informasi selengkapnya tentang aturan yang telah dikonfigurasi sebelumnya, lihat Aturan yang telah dikonfigurasi sebelumnya dalam referensi bahasa aturan kustom.

Contoh berikut menggunakan aturan yang telah dikonfigurasi sebelumnya untuk memitigasi serangan pembuatan skrip lintas situs (XSS):

evaluatePreconfiguredWaf('xss-stable')

Contoh berikut menggunakan aturan yang telah dikonfigurasi sebelumnya untuk memitigasi serangan injeksi SQL (SQLi):

evaluatePreconfiguredWaf('sqli-stable')

Anda juga dapat menggabungkan aturan yang telah dikonfigurasi sebelumnya dengan ekspresi lain. Contoh berikut menggunakan aturan yang telah dikonfigurasi untuk memitigasi serangan SQLi dari rentang alamat IP 192.0.2.1/24:

inIpRange(origin.ip, '192.0.2.1/24') && evaluatePreconfiguredWaf('sqli-stable')

Mitigasi 10 teratas OWASP untuk beban kerja hybrid

Cloud Armor menawarkan mitigasi untuk serangan berikut, baik yang di-deploy di Trusted Cloud,lokal, atau di penyedia pihak ketiga:

• Injeksi SQL (SQLi)
• Pembuatan skrip lintas situs (XSS)
• Penyertaan File Lokal (LFI)
• Penyertaan File Jarak Jauh (RFI)
• Eksekusi Kode Jarak Jauh (RCE)

Anda dapat menggunakan kemampuan ini untuk mengatasi beberapa risiko keamanan aplikasi web yang paling umum, termasuk risiko yang diidentifikasi dalam daftar OWASP Top 10.

Aturan WAF yang telah dikonfigurasi sebelumnya di Cloud Armor dapat ditambahkan ke kebijakan keamanan untuk mendeteksi dan menolak permintaan lapisan 7 yang tidak diinginkan yang berisi upaya SQLi atau XSS. Cloud Armor mendeteksi permintaan berbahaya dan menolaknya di edge infrastruktur Google. Permintaan tidak di-proxy ke layanan backend, terlepas dari tempat layanan backend di-deploy.

Untuk melindungi workload yang tidak dihostingTrusted Clouddari serangan ini di edge jaringan Google, ikuti langkah-langkah berikut:

1. Konfigurasi Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik dengan layanan backend yang memiliki NEG internet sebagai backend.
2. Buat kebijakan keamanan Cloud Armor.
3. Tambahkan aturan SQLi dan XSS yang telah dikonfigurasi sebelumnya ke kebijakan.
4. Lampirkan kebijakan keamanan ke layanan backend yang Anda buat pada langkah 1.
5. Pantau aktivitas Cloud Armor menggunakan Cloud Logging, Cloud Monitoring, dan temuan yang dikirim ke Security Command Center.

Kontrol akses Layer 7 dan serangan penghapusan cache

Bergantung pada arsitektur aplikasi, Anda dapat mengonfigurasi satu layanan backend untuk menayangkan permintaan untuk berbagai URL, termasuk konten yang dapat di-cache dan yang tidak dapat di-cache. Dalam skenario deployment tersebut, buat kebijakan keamanan Cloud Armor yang menolak traffic yang tidak diinginkan di jalur permintaan tertentu, tetapi mengizinkan semua klien mengakses konten statis di jalur permintaan yang berbeda.

Dalam situasi lain, meskipun konten ditayangkan secara efisien dari cache, klien yang berbahaya atau rusak dapat menghasilkan permintaan bervolume tinggi yang menyebabkan cache tidak ditemukan dan mengharuskan server asal yang mendasarinya mengambil atau membuat konten yang diminta. Hal ini dapat membebani resource yang terbatas dan berdampak negatif pada ketersediaan aplikasi untuk semua pengguna. Anda dapat membuat kebijakan keamanan Cloud Armor untuk mencocokkan tanda tangan klien yang menyebabkan masalah dan menolak permintaan sebelum mencapai server asal dan memengaruhi performa.

Untuk melakukannya, ikuti langkah-langkah berikut:

1. Buat kebijakan keamanan Cloud Armor.

2. Konfigurasi aturan; misalnya, aturan berikut menolak akses ke "/admin":

   request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>')
   

3. Lampirkan kebijakan keamanan dari langkah 1 ke layanan backend yang mengaktifkan Cloud CDN.

Langkah berikutnya

• Mengonfigurasi kebijakan keamanan
• Mempelajari bahasa aturan kustom
• Menyesuaikan aturan WAF