Dokumen ini menjelaskan penerapan tingkat akses dan memberikan rekomendasi untuk memulai penerapan perimeter layanan berdasarkan daftar yang diizinkan.
Setelah 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 beban kerja memerlukan daftar berbasis perangkat yang diizinkan. Untuk memberikan akses terkontrol ke resource Google Cloud yang dilindungi, Anda dapat menggunakan tingkat akses Kontrol Layanan VPC. Beberapa cara praktis untuk menerapkan tingkat akses didasarkan pada alamat IP, identitas, atau perangkat.
Untuk mengetahui informasi selengkapnya, lihat Akses kontekstual dengan aturan masuk.
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 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 berupaya mengakses perimeter. Upaya akses akan ditolak jika berasal dari alamat IP internet mana pun. Namun, akses akan diizinkan jika berasal dari alamat IP publik perusahaan.
Memberikan akses berdasarkan identitas penelepon
Untuk menerapkan daftar yang diizinkan berbasis identitas, Anda dapat menambahkan akun layanan dan administrator super organisasi ke daftar yang diizinkan. Perimeter terbuka untuk identitas ini dari alamat IP mana pun, jadi Anda perlu memastikan bahwa identitas 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) adalah hal yang tidak umum.
Resource dalam perimeter dapat diakses melalui VM dalam perimeter, dari jaringan lokal tepercaya, atau dari perangkat tepercaya. Sebaiknya gunakan Cloud Workstations untuk mengakses resource di dalam perimeter karena Kontrol Layanan VPC tidak mendukung Cloud Shell.
Memenuhi syarat akses berdasarkan atribut perangkat penelepon
Kepercayaan perangkat, 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 memanggil perintah CLI gcloud pada API perimeter yang dilindungi. Namun, sesi pengguna Windows yang berbeda di komputer yang sama tidak dapat memanggil perintah pada API perimeter yang dilindungi.
Kondisi perangkat berikut berguna untuk membangun kepercayaan perangkat:
Chrome OS Terverifikasi adalah kondisi sangat aman dan terverifikasi secara kriptografi yang menunjukkan bahwa pengguna organisasi yang valid login ke Chromebook yang di-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 apa pun diberikan. Secara default, perangkat akan disetujui secara otomatis jika memiliki pengguna organisasi yang valid untuk login. Namun, sebaiknya nonaktifkan opsi persetujuan otomatis.
Wajibkan perangkat milik perusahaan bergantung pada agen Chrome yang mengambil nomor seri dari OS, yang biasanya berasal dari BIOS. Nomor ini harus sama dengan nomor seri yang ada yang telah Anda masukkan ke Cloud Identity.
Karena nomor seri tidak resmi di perangkat non-ChromeOS, pengguna dengan hak istimewa administrator yang ditingkatkan mungkin dapat melakukan spoofing 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).
Mulai penerapan
Setelah Anda mendesain daftar yang diizinkan dan memperbarui tingkat akses, sebaiknya jalankan beban kerja lagi untuk mengonfirmasi bahwa tidak ada pelanggaran apa pun. Jika beban kerja dijalankan tanpa pelanggaran, Anda dapat memulai penerapan Kontrol Layanan VPC tanpa memengaruhi aplikasi.
Saat Anda merencanakan penegakan, sertakan hal berikut:
- Pilih tanggal penegakan dan informasikan tanggal tersebut kepada semua tim terkait.
- Pastikan tim operasi keamanan dan respons insiden mengetahui deployment tersebut. Selain itu, pastikan individu dengan izin yang sesuai memeriksa log dan menyetujui daftar yang diizinkan lainnya, jika diperlukan.
- Pastikan tim respons situasi dapat membuka kasus dukungan Google Cloud, jika ada pertanyaan atau masalah.
- Buat atau ubah tingkat akses dan perimeter menggunakan alat otomatisasi seperti Terraform. Sebaiknya jangan menjalankan tugas ini secara manual.
Saat Anda memulai penerapan, mulai dengan memindahkan project yang terkait dengan satu beban kerja dari perimeter uji coba ke perimeter live. Pastikan Anda memberikan waktu agar aplikasi dapat berjalan dengan benar saat Anda mengamati log pelanggaran. Ulangi proses tersebut untuk beban kerja yang tersisa satu per satu.
Untuk menampilkan pelanggaran yang diblokir, konfigurasikan sink logging gabungan yang mengirimkan log audit untuk semua project di perimeter ke BigQuery. Lalu, 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.