Dokumen ini menjelaskan penerapan tingkat akses dan memberikan rekomendasi untuk memulai penegakan perimeter layanan berdasarkan daftar yang diizinkan.
Saat menyelesaikan eksekusi dry run workload, Anda mengidentifikasi daftar alamat IP dan identitas yang perlu ditambahkan ke daftar yang diizinkan. Anda mungkin juga menemukan bahwa beberapa workload memerlukan daftar yang diizinkan berbasis perangkat. Untuk memberikan akses kontrol ke resource Google Cloud yang dilindungi, Anda dapat menggunakan level akses Kontrol Layanan VPC. Beberapa cara praktis yang dapat Anda gunakan untuk menerapkan tingkat akses didasarkan pada alamat IP, identitas, atau perangkat.
Untuk mengetahui informasi selengkapnya, lihat Akses kontekstual dengan aturan ingress.
Memberikan akses berdasarkan IP sumber
Anda hanya dapat menggunakan rentang CIDR IP publik di tingkat akses untuk daftar yang diizinkan berbasis IP. Karena metode ini mengizinkan semua API yang dilindungi dari rentang IP ini, lingkungan di balik IP ini harus dipercaya dan dikontrol. Skenario penggunaan umum untuk daftar yang diizinkan ini adalah untuk mengizinkan akses perimeter dari jaringan lokal. Diagram berikut menunjukkan cara daftar yang diizinkan berbasis IP memblokir dan mengizinkan akses perimeter:
Dalam diagram sebelumnya, identitas yang valid mencoba mengakses perimeter. Upaya akses akan ditolak jika berasal dari alamat IP internet apa pun. Namun, akses diizinkan jika berasal dari alamat IP publik perusahaan.
Variasi pada skenario ini adalah saat Anda mengizinkan akses perimeter dari
resource pribadi yang di-deploy di project atau organisasi lain. Dalam kasus penggunaan
ini, gateway Cloud NAT diperlukan dalam project sumber.
Cloud NAT
memiliki integrasi dengan Akses Google Pribadi
yang otomatis mengaktifkan Akses Google Pribadi di subnet resource,
dan membuat traffic ke API dan layanan Google tetap bersifat internal, bukan merutekannya
ke internet menggunakan alamat IP eksternal gateway Cloud NAT.
Saat traffic dirutekan dalam jaringan Google internal, kolom RequestMetadata.caller_ip dari objek AuditLog akan disamarkan menjadi gce-internal-ip. Untuk mengizinkan akses perimeter dalam hal ini, Anda perlu
mengonfigurasi aturan masuk untuk mengizinkan akses berdasarkan atribut lain seperti
project atau akun layanan, bukan mengonfigurasi level akses berdasarkan
alamat IP sumber eksternal.
Memberikan akses berdasarkan identitas pemanggil
Untuk menerapkan daftar yang diizinkan berbasis identitas, Anda menambahkan akun layanan dan administrator super organisasi ke daftar yang diizinkan. Perimeter terbuka untuk identitas ini dari alamat IP mana pun, jadi Anda harus memastikan bahwa identitas tersebut dijaga dengan baik. Anda juga harus memastikan bahwa Anda tidak membuat kunci untuk akun layanan yang telah ditambahkan ke daftar yang diizinkan. Menambahkan identitas pengguna ke daftar yang diizinkan (grup tidak dapat ditambahkan ke daftar yang diizinkan) di perimeter jarang dilakukan.
Resource dalam perimeter dapat diakses melalui VM dalam perimeter, dari jaringan lokal tepercaya, atau dari perangkat tepercaya. Sebaiknya gunakan Cloud Workstations untuk mengakses resource dalam perimeter karena Kontrol Layanan VPC tidak mendukung Cloud Shell.
Akses yang memenuhi syarat berdasarkan atribut perangkat pemanggil
Kepercayaan perangkat, yang juga disebut endpoint tepercaya, bergantung pada pengguna organisasi yang valid yang login ke browser Chrome atau Chromebook. Kepercayaan berlaku untuk sesi login OS. Misalnya, pengguna Windows yang login dan menjalankan sesi Chrome (browser tidak perlu dibuka) dapat berhasil memanggil perintah gcloud CLI di API perimeter yang dilindungi. Namun, sesi pengguna Windows yang berbeda di komputer yang sama tidak dapat memanggil perintah di API perimeter yang dilindungi.
Kondisi perangkat berikut berguna untuk membangun kepercayaan perangkat:
Chrome OS Terverifikasi adalah kondisi yang sangat aman dan terverifikasi secara kriptografis yang menunjukkan bahwa pengguna organisasi yang valid login ke Chromebook yang di-booting dengan aman. Ini adalah kondisi kepercayaan tingkat 1 yang direkomendasikan.
Memerlukan persetujuan admin untuk akses perangkat memungkinkan administrator Cloud Identity menyetujui setiap perangkat sebelum akses diberikan. Secara default, perangkat disetujui secara otomatis jika memiliki pengguna organisasi yang valid yang login. Namun, sebaiknya nonaktifkan opsi persetujuan otomatis.
Perlu perangkat milik perusahaan mengandalkan agen Chrome yang mengambil nomor seri dari OS, yang biasanya berasal dari BIOS. Nomor ini harus cocok dengan nomor seri yang ada yang telah Anda masukkan ke Cloud Identity.
Karena nomor seri tidak memiliki otoritas di perangkat non-Chrome OS, pengguna dengan hak istimewa administrator yang ditingkatkan mungkin dapat melakukan spoofing pada nomor seri. Sebaiknya gunakan kondisi ini hanya sebagai pemeriksaan tingkat 2.
Untuk contoh pelacak guna memberikan akses terkontrol berdasarkan kondisi yang dibahas dalam daftar sebelumnya, lihat Template orientasi Kontrol Layanan VPC - daftar yang diizinkan (PDF).
Memulai penerapan
Setelah mendesain daftar yang diizinkan dan memperbarui tingkat akses, sebaiknya jalankan kembali workload untuk mengonfirmasi bahwa tidak ada pelanggaran. Jika beban kerja dijalankan tanpa pelanggaran, Anda dapat memulai penerapan Kontrol Layanan VPC tanpa memengaruhi aplikasi.
Saat Anda merencanakan penerapan, sertakan hal berikut:
- Pilih tanggal penerapan dan sampaikan tanggal tersebut kepada semua tim terkait.
- Pastikan tim operasi keamanan dan respons insiden mengetahui deployment. Selain itu, pastikan individu dengan izin yang sesuai memeriksa log dan menyetujui daftar yang diizinkan tambahan, jika diperlukan.
- Pastikan tim respons situasi dapat membuka kasus dukungan Google Cloud, jika ada pertanyaan atau masalah.
- Buat atau ubah perimeter dan tingkat akses menggunakan alat otomatisasi seperti Terraform. Sebaiknya jangan lakukan tugas ini secara manual.
Saat Anda memulai penerapan, mulailah dengan memindahkan project yang terkait dengan satu beban kerja dari perimeter uji coba ke perimeter aktif. Pastikan untuk memberi waktu bagi aplikasi agar berjalan dengan benar saat Anda mengamati log pelanggaran. Ulangi proses untuk beban kerja lainnya satu per satu.
Untuk menampilkan pelanggaran yang diblokir, konfigurasi sink logging gabungan yang mengirim log audit untuk semua project dalam perimeter ke BigQuery. Kemudian, jalankan kueri berikut:
SELECT
receiveTimestamp, #time of violation
Resource.labels.service, #protected Google Cloud service being blocked
protopayload_auditlog.methodName, #method name being called
resource.labels.project_id as PROJECT, #protected project blocking the call
protopayload_auditlog.authenticationInfo.principalEmail, #caller identity
protopayload_auditlog.requestMetadata.callerIp, #caller IP
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') as DRYRUN, #dry-run indicator
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.violationReason') as REASON, #reason for violation
protopayload_auditlog.metadataJson, #raw violation entry
FROM `BQ_DATASOURCE_NAME.cloudaudit_googleapis_com_policy_*`
WHERE JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') is null #exclude logs from a dry-run perimeter
Langkah selanjutnya
- Pelajari cara mengizinkan akses ke resource yang dilindungi dari luar perimeter.
- Pelajari cara mencantumkan, memperbarui, dan menghapus perimeter layanan.