Halaman ini menampilkan kasus penggunaan umum untuk kebijakan keamanan Google Cloud Armor. Kebijakan keamanan Cloud Armor dapat melindungi aplikasi Anda dengan fitur seperti daftar alamat 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 sejumlah 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. Pada 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 Cloud Armor.
- Dalam kebijakan keamanan, tambahkan aturan yang menambahkan rentang ke daftar yang diizinkan
sebagai aturan pertama. Aturan ini memiliki deskripsi
allow [RANGE], dan[RANGE]adalah rentang IP yang diinginkan. - Ubah aturan default dalam kebijakan dari aturan izinkan menjadi aturan
tolak. Aturan default mengatur traffic yang tidak cocok dengan
aturan sebelumnya. Ini adalah aturan terakhir dalam kebijakan. Mengubah aturan
dari
allowmenjadidenyakan 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 tolak
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 khusus untuk memfilter berdasarkan parameter Lapisan 3 hingga Lapisan 7
Gunakan bahasa aturan khusus 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 khusus.
Untuk menentukan ekspresi dalam aturan, gunakan flag --expression gcloud atau
konsolGoogle Cloud . Untuk mengetahui informasi selengkapnya, lihat
Membuat ekspresi, aturan, dan kebijakan keamanan Cloud Armor.
Pada 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 khusus.
Melindungi deployment Anda dari serangan lapisan aplikasi dan membantu mengatasi 10 risiko teratas 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 yang ditargetkan 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 mengurangi risiko ini untuk mencegah eksploitasi kerentanan dari internet agar tidak berhasil menyerang server asal.
Untuk mengurangi risiko, ikuti langkah-langkah berikut:
- Buat atau identifikasi layanan backend dengan CDN yang diaktifkan.
- Buat kebijakan keamanan Cloud Armor.
- Buat satu atau beberapa aturan dalam kebijakan keamanan untuk mencegah 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 kumpulan ekspresi yang telah ditentukan sebelumnya yang dapat Anda tambahkan ke
kebijakan keamanan Cloud Armor. Untuk menambahkan kumpulan ekspresi ini ke aturan,
gunakan flag --expression gcloud atau konsol Google Cloud .
Untuk mengetahui informasi selengkapnya, lihat
Membuat ekspresi, aturan, dan kebijakan 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 permintaan.
Untuk mengetahui informasi selengkapnya tentang aturan yang telah dikonfigurasi sebelumnya, lihat Aturan yang telah dikonfigurasi sebelumnya dalam referensi bahasa aturan khusus.
Contoh berikut menggunakan aturan yang telah dikonfigurasi sebelumnya untuk mengatasi serangan pembuatan skrip lintas situs (XSS):
evaluatePreconfiguredWaf('xss-stable')
Contoh berikut menggunakan aturan yang telah dikonfigurasi sebelumnya untuk mengatasi 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 sebelumnya untuk mengatasi serangan SQLi dari
rentang alamat IP 192.0.2.1/24:
inIpRange(origin.ip, '192.0.2.1/24') && evaluatePreconfiguredWaf('sqli-stable')
10 mitigasi terbaik OWASP untuk workload hybrid
Cloud Armor menawarkan mitigasi untuk serangan berikut, baik yang di-deploy di Google 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 10 Teratas OWASP.
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 di mana 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 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 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 Cloud Armor. Dengan menggunakan NEG internet, server asal dapat ditempatkan secara lokal atau dengan penyedia infrastruktur pihak ketiga.
Cloud Armor dan infrastruktur edge Google lainnya mengatasi dan menghentikan serangan L3/L4, memberikan notifikasi tentang aktivitas Lapisan 7 yang mencurigakan, dan siap menolak permintaan Lapisan 7 yang tidak diinginkan dengan aturan khusus. Logging dan telemetri Cloud Armor di Cloud Logging, Cloud Monitoring, dan Security Command Center memberikan insight yang dapat ditindaklanjuti untuk aplikasi yang dilindungi, terlepas dari di mana aplikasi tersebut di-deploy.
Untuk mengaktifkan perlindungan 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 Cloud Armor.
- Lampirkan kebijakan keamanan ke layanan backend yang Anda buat pada langkah 1.
- Akses pemberitahuan, logging, dan telemetri 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 Lapisan 7 dan serangan cache busting
Tergantung pada arsitektur aplikasi, Anda dapat mengonfigurasi satu layanan backend guna 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 disajikan 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:
- Buat kebijakan keamanan 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 telah mengaktifkan Cloud CDN.