Dokumen ini menjelaskan penerapan tingkat akses dan memberikan rekomendasi untuk memulai penerapan perimeter layanan berdasarkan daftar yang diizinkan.
Saat menyelesaikan eksekusi uji coba workload, Anda akan 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 terkontrol ke resource Google Cloud yang dilindungi, Anda dapat menggunakan tingkat akses Kontrol Layanan VPC. Beberapa cara praktis yang dapat Anda lakukan untuk menerapkan tingkat akses adalah berdasarkan 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 tepercaya dan terkontrol. 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, sebuah identitas yang valid mencoba mengakses perimeter. Upaya akses tersebut ditolak jika berasal dari alamat IP internet mana pun. Namun, akses diizinkan jika berasal dari alamat IP publik perusahaan.
Variasi 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 di project sumber.
Cloud NAT memiliki integrasi dengan Akses Google Pribadi yang secara otomatis mengaktifkan Akses Google Pribadi di subnet resource, dan menjaga traffic ke API dan layanan Google tetap internal, bukan merutekannya ke internet menggunakan alamat IP eksternal gateway Cloud NAT.
Karena traffic dirutekan dalam jaringan Google internal, kolom RequestMetadata.caller_ip dalam objek AuditLog disamarkan menjadi gce-internal-ip. Untuk mengizinkan akses perimeter dalam hal ini, Anda perlu
mengonfigurasi aturan ingress untuk mengizinkan akses berdasarkan atribut lain seperti
project atau akun layanan, bukan mengonfigurasi tingkat akses berdasarkan
alamat IP sumber eksternal.
Memberikan akses berdasarkan identitas pemanggil
Untuk menerapkan daftar yang diizinkan berbasis identitas, Anda perlu menambahkan akun layanan dan administrator super organisasi ke daftar yang diizinkan. Perimeter akan terbuka untuk identitas-identitas ini dari alamat IP mana pun, jadi Anda harus memastikan bahwa identitas tersebut terlindungi dengan baik. Anda juga harus memastikan bahwa Anda menghindari pembuatan kunci untuk akun layanan yang telah Anda tambahkan ke daftar yang diizinkan. Menambahkan identitas pengguna ke daftar yang diizinkan (grup tidak dapat ditambahkan ke daftar yang diizinkan) di perimeter adalah hal yang 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.
Menentukan kelayakan akses berdasarkan atribut perangkat pemanggil
Kepercayaan perangkat, yang juga disebut endpoint tepercaya, bergantung pada adanya pengguna organisasi yang valid dan telah login ke browser Chrome atau ke Chromebook. Kepercayaan ini berlaku untuk sesi login OS. Misalnya, pengguna Windows yang login dan menjalankan sesi Chrome (browser tidak perlu dibuka) dapat memanggil perintah gcloud CLI di API perimeter yang dilindungi dengan berhasil. 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 kriptografi yang menunjukkan bahwa pengguna organisasi yang valid telah login ke Chromebook yang booting dengan aman. Ini adalah kondisi kepercayaan tingkat 1 yang direkomendasikan.
Mewajibkan persetujuan admin untuk akses perangkat memungkinkan administrator Cloud Identity menyetujui setiap perangkat sebelum akses diberikan. Secara default, perangkat disetujui secara otomatis jika pengguna organisasi yang valid telah login. Namun, kami sarankan untuk menonaktifkan opsi persetujuan otomatis.
Memerlukan perangkat milik perusahaan mengandalkan agen Chrome untuk mengambil nomor seri dari OS, yang biasanya berasal dari BIOS. Nomor ini harus cocok dengan nomor seri yang sudah ada yang telah Anda masukkan ke Cloud Identity.
Karena nomor seri tidak bersifat otoritatif di perangkat non-Chrome OS, pengguna dengan hak istimewa administrator yang lebih tinggi mungkin dapat memalsukan nomor seri. Sebaiknya gunakan kondisi ini hanya sebagai pemeriksaan tingkat 2.
Untuk melihat contoh pelacak pemberian akses terkontrol berdasarkan kondisi yang dibahas dalam daftar sebelumnya, lihat Template orientasi Kontrol Layanan VPC - daftar yang diizinkan (PDF).
Mulai penerapan
Setelah mendesain daftar yang diizinkan dan memperbarui tingkat akses, sebaiknya jalankan kembali workload untuk mengonfirmasi bahwa tidak ada pelanggaran. Jika workload 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 tahu tentang deployment. Selain itu, pastikan individu dengan izin yang sesuai memeriksa log dan menyetujui daftar yang diizinkan tambahan, jika perlu.
- 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 workload dari perimeter uji coba ke perimeter aktif. Pastikan Anda memberikan waktu yang cukup agar aplikasi berjalan dengan benar selagi Anda mengamati log pelanggaran. Ulangi proses untuk workload yang tersisa 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 berikutnya
- Pelajari cara mengizinkan akses ke resource terlindungi dari luar perimeter.
- Pelajari cara mencantumkan, memperbarui, dan menghapus perimeter layanan.