Halaman ini menampilkan kasus penggunaan umum untuk kebijakan keamanan Google Cloud Armor. Kebijakan keamanan Google Cloud Armor dapat melindungi aplikasi Anda dengan fitur seperti daftar yang diizinkan dan ditolak alamat IP, 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 Google 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:
- Buat kebijakan keamanan Google Cloud Armor.
- 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. - 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
menjadideny
akan memblokir semua traffic yang tidak berasal dari rentang dalam daftar yang diizinkan. - 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 yang ditolak untuk membuat kebijakan keamanan Google Cloud Armor yang menolak traffic dari alamat IP atau rentang CIDR. Dalam ilustrasi berikut, kebijakan keamanan Google 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 Google Cloud Armor untuk menentukan satu atau beberapa ekspresi dalam kondisi pencocokan aturan. Saat menerima permintaan, Google Cloud Armor akan 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 Google 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
konsolGoogle Cloud . Untuk mengetahui informasi selengkapnya, lihat
Membuat kebijakan, aturan, dan ekspresi keamanan Google 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 Google 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:
- Buat atau identifikasi layanan backend dengan CDN yang diaktifkan.
- Buat kebijakan keamanan Google Cloud Armor.
- Buat satu atau beberapa aturan dalam kebijakan keamanan untuk menolak serangan L7.
- 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 Google Cloud Armor. Untuk menambahkan set ekspresi ini ke aturan, gunakan flag --expression
gcloud atau konsol Google 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
Google Cloud Armor menawarkan mitigasi untuk serangan berikut, baik yang di-deploy di Google Cloud,infrastruktur 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 Google Cloud Armor dapat ditambahkan ke kebijakan keamanan untuk mendeteksi dan menolak permintaan Lapisan 7 yang tidak diinginkan yang berisi upaya SQLi atau XSS. Google 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 dihostingGoogle Clouddari serangan ini di edge jaringan Google, ikuti langkah-langkah berikut:
- Konfigurasi Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik dengan layanan backend yang memiliki NEG internet sebagai backend.
- Buat kebijakan keamanan Google Cloud Armor.
- Tambahkan aturan SQLi dan XSS yang telah dikonfigurasi sebelumnya ke kebijakan.
- Lampirkan kebijakan keamanan ke layanan backend yang Anda buat pada langkah 1.
- Pantau aktivitas Google Cloud Armor menggunakan Cloud Logging, Cloud Monitoring, dan temuan yang dikirim ke Security Command Center.
Pertahanan DDoS dan pemantauan lapisan 7 server asal eksternal Cloud CDN
Deployment Cloud CDN dengan server asal eksternal dapat menggunakan infrastruktur edge Google sebagai frontend untuk proxy, caching, dan pemfilteran lapisan 7 Google Cloud Armor. Dengan menggunakan NEG internet, server asal dapat berada di lokasi atau dengan penyedia infrastruktur pihak ketiga.
Google Cloud Armor dan infrastruktur edge Google lainnya memitigasi dan menghentikan serangan L3/L4, memberikan notifikasi tentang aktivitas Lapisan 7 yang mencurigakan, dan siap menolak permintaan Lapisan 7 yang tidak diinginkan dengan aturan kustom. Logging dan telemetri Google Cloud Armor di seluruh Cloud Logging, Cloud Monitoring, dan Security Command Center memberikan insight yang dapat ditindaklanjuti untuk aplikasi yang dilindungi, terlepas dari tempat aplikasi tersebut di-deploy.
Untuk mengaktifkan perlindungan Google Cloud Armor bagi server asal eksternal CDN, ikuti langkah-langkah berikut:
- Konfigurasi Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik dengan layanan backend yang memiliki NEG internet sebagai backend.
- Aktifkan Cloud CDN untuk layanan backend ini.
- Buat kebijakan keamanan Google Cloud Armor.
- Lampirkan kebijakan keamanan ke layanan backend yang Anda buat pada langkah 1.
- Akses pemberitahuan, logging, dan telemetri Google Cloud Armor di Security Command Center, Cloud Logging, dan Cloud Monitoring.
Selain itu, Anda dapat menggunakan kebijakan keamanan edge untuk melindungi konten yang disimpan dalam cache. Untuk mengetahui informasi selengkapnya tentang kebijakan keamanan edge, lihat Ringkasan kebijakan keamanan.
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 Google 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 Google 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:
- Buat kebijakan keamanan Google Cloud Armor.
Konfigurasi aturan; misalnya, aturan berikut menolak akses ke
"/admin"
:request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>')
Lampirkan kebijakan keamanan dari langkah 1 ke layanan backend yang mengaktifkan Cloud CDN.