Blueprint dasar-dasar perusahaan

Last reviewed 2023-12-20 UTC

Anda dapat mencetak halaman ini atau menyimpan halaman dalam format PDF menggunakan fungsi cetak browser dan memilih opsi Simpan sebagai PDF. Untuk versi standar halaman ini, kembali ke Blueprint dasar-dasar perusahaan.

Konten ini terakhir diperbarui pada Desember 2023, dan menampilkan status quo pada saat konten tersebut ditulis. Kebijakan dan sistem keamanan Google dapat berubah di masa mendatang, seiring upaya kami untuk terus meningkatkan perlindungan bagi pelanggan.

Dokumen ini menjelaskan praktik terbaik yang memungkinkan Anda men-deploy kumpulan resource dasar di Google Cloud. Fondasi cloud adalah dasar dari resource, konfigurasi, dan kemampuan yang memungkinkan perusahaan mengadopsi Google Cloud untuk kebutuhan bisnis mereka. Dasar yang dirancang dengan baik memungkinkan pemerintahan, kontrol keamanan, skala, visibilitas, dan akses yang konsisten ke layanan bersama di semua workload di lingkungan Google Cloud Anda. Setelah men-deploy kontrol dan tata kelola yang dijelaskan dalam dokumen ini, Anda dapat men-deploy workload ke Google Cloud.

Blueprint fondasi perusahaan (sebelumnya dikenal sebagai blueprint fondasi keamanan) ditujukan untuk arsitek, praktisi keamanan, dan tim engineering platform yang bertanggung jawab untuk mendesain lingkungan siap perusahaan di Google Cloud. Cetak biru ini terdiri dari hal-hal berikut:

• Repositori GitHub terraform-example-foundation yang berisi aset Terraform yang dapat di-deploy.
• Panduan yang menjelaskan arsitektur, desain, dan kontrol yang Anda terapkan dengan blueprint (dokumen ini).

Anda dapat menggunakan panduan ini dengan salah satu dari dua cara berikut:

• Untuk membuat fondasi lengkap berdasarkan praktik terbaik Google. Anda dapat men-deploy semua rekomendasi dari panduan ini sebagai titik awal, lalu menyesuaikan lingkungan untuk memenuhi persyaratan khusus bisnis Anda.
• Untuk meninjau lingkungan yang ada di Google Cloud. Anda dapat membandingkan komponen tertentu dari desain Anda dengan praktik terbaik yang direkomendasikan Google.

Kasus penggunaan yang didukung

Blueprint fondasi perusahaan menyediakan lapisan dasar resource dan konfigurasi yang membantu mengaktifkan semua jenis workload di Google Cloud. Baik Anda memigrasikan workload komputasi yang ada ke Google Cloud, mem-build aplikasi web dalam penampung, atau membuat workload big data dan machine learning, blueprint fondasi perusahaan membantu Anda mem-build lingkungan untuk mendukung workload perusahaan dalam skala besar.

Setelah men-deploy blueprint fondasi perusahaan, Anda dapat men-deploy workload secara langsung atau men-deploy blueprint tambahan untuk mendukung workload kompleks yang memerlukan kemampuan tambahan.

Model keamanan defense-in-depth

LayananGoogle Cloud mendapatkan manfaat dari desain keamanan infrastruktur Google yang mendasarinya. Anda bertanggung jawab untuk mendesain keamanan ke dalam sistem yang Anda build di atas Google Cloud. Blueprint fondasi perusahaan membantu Anda menerapkan model keamanan defense-in-depth untuk Google Cloud layanan dan beban kerja Anda.

Diagram berikut menunjukkan model keamanan pertahanan yang mendalam untuk organisasi Google Cloud Anda yang menggabungkan kontrol arsitektur, kontrol kebijakan, dan kontrol detektif.

Diagram ini menjelaskan kontrol berikut:

• Kontrol kebijakan adalah batasan terprogram yang menerapkan konfigurasi resource yang dapat diterima dan mencegah konfigurasi berisiko. Blueprint ini menggunakan kombinasi kontrol kebijakan, termasuk validasi infrastruktur sebagai kode (IaC) dalam pipeline dan batasan kebijakan organisasi Anda.
• Kontrol arsitektur adalah konfigurasi resource Google Cloud seperti jaringan dan hierarki resource. Arsitektur blueprint didasarkan pada praktik terbaik keamanan.
• Kontrol detektif memungkinkan Anda mendeteksi perilaku anomali atau berbahaya dalam organisasi. Blueprint ini menggunakan fitur platform seperti Security Command Center, terintegrasi dengan kontrol dan alur kerja detektif yang ada seperti pusat operasi keamanan (SOC), serta menyediakan kemampuan untuk menerapkan kontrol detektif kustom.

Keputusan penting

Bagian ini merangkum keputusan arsitektur tingkat tinggi dari blueprint.

Diagram ini menjelaskan bagaimana layanan Google Cloud berkontribusi pada keputusan arsitektur utama:

• Cloud Build: Resource infrastruktur dikelola menggunakan model GitOps. IaC deklaratif ditulis di Terraform dan dikelola dalam sistem kontrol versi untuk peninjauan dan persetujuan, dan resource di-deploy menggunakan Cloud Build sebagai alat otomatisasi continuous integration dan continuous deployment (CI/CD). Pipeline ini juga menerapkan pemeriksaan kebijakan sebagai kode untuk memvalidasi bahwa resource memenuhi konfigurasi yang diharapkan sebelum deployment.
• Cloud Identity: Pengguna dan keanggotaan grup disinkronkan dari penyedia identitas yang ada. Kontrol untuk pengelolaan siklus proses akun pengguna dan single sign-on (SSO) bergantung pada kontrol dan proses yang ada dari penyedia identitas Anda.
• Identity and Access Management (IAM): Kebijakan izinkan (sebelumnya dikenal sebagai kebijakan IAM) mengizinkan akses ke resource dan diterapkan ke grup berdasarkan fungsi tugas. Pengguna ditambahkan ke grup yang sesuai untuk menerima akses hanya lihat ke resource foundation. Semua perubahan pada resource dasar di-deploy melalui pipeline CI/CD yang menggunakan identitas akun layanan dengan hak istimewa.
• Resource Manager: Semua resource dikelola dalam satu organisasi, dengan hierarki resource folder yang mengatur project menurut lingkungan. Project diberi label dengan metadata untuk tata kelola, termasuk atribusi biaya.
• Jaringan: Topologi jaringan menggunakan VPC Bersama untuk menyediakan resource jaringan bagi workload di beberapa region dan zona, yang dipisahkan berdasarkan lingkungan, dan dikelola secara terpusat. Semua jalur jaringan antara host lokal, Google Cloud resource di jaringan VPC, dan Google Cloud layanan bersifat pribadi. Tidak ada traffic keluar ke atau traffic masuk dari internet publik yang diizinkan secara default.
• Cloud Logging: Sink log gabungan dikonfigurasi untuk mengumpulkan log yang relevan untuk keamanan dan audit ke dalam project terpusat untuk retensi, analisis, dan ekspor jangka panjang ke sistem eksternal.
• Layanan Kebijakan Organisasi: Batasan kebijakan organisasi dikonfigurasi untuk mencegah berbagai konfigurasi berisiko tinggi.
• Secret Manager: Project terpusat dibuat untuk tim yang bertanggung jawab mengelola dan mengaudit penggunaan secret aplikasi sensitif untuk membantu memenuhi persyaratan kepatuhan.
• Cloud Key Management Service (Cloud KMS): Project terpusat dibuat untuk tim yang bertanggung jawab mengelola dan mengaudit kunci enkripsi untuk membantu memenuhi persyaratan kepatuhan.
• Security Command Center: Kemampuan pemantauan dan deteksi ancaman disediakan menggunakan kombinasi kontrol keamanan bawaan dari Security Command Center dan solusi kustom yang memungkinkan Anda mendeteksi dan merespons peristiwa keamanan.

Untuk alternatif keputusan utama ini, lihat alternatif.

Langkah berikutnya

• Baca tentang autentikasi dan otorisasi (dokumen berikutnya dalam rangkaian ini).

Autentikasi dan otorisasi

Bagian ini memperkenalkan cara menggunakan Cloud Identity untuk mengelola identitas yang digunakan karyawan Anda untuk mengakses layanan Google Cloud.

Penyedia identitas eksternal sebagai sumber tepercaya

Sebaiknya gabungkan akun Cloud Identity Anda dengan penyedia identitas yang sudah ada. Federasi membantu Anda memastikan bahwa proses pengelolaan akun yang ada berlaku untuk Google Cloud dan layanan Google lainnya.

Jika belum memiliki penyedia identitas, Anda dapat membuat akun pengguna langsung di Cloud Identity.

Catatan: Jika Anda sudah menggunakan Google Workspace, Cloud Identity menggunakan konsol, kontrol administratif, dan akun pengguna yang sama dengan akun Google Workspace Anda.

Diagram berikut menunjukkan tampilan umum federasi identitas dan single sign-on (SSO). Contoh ini menggunakan Microsoft Active Directory, yang berada di lingkungan lokal, sebagai contoh penyedia identitas.

Diagram ini menjelaskan praktik terbaik berikut:

• Identitas pengguna dikelola di domain Active Directory yang berada di lingkungan lokal dan digabungkan ke Cloud Identity. Active Directory menggunakan Google Cloud Directory Sync untuk menyediakan identitas ke Cloud Identity.
• Pengguna yang mencoba login ke layanan Google akan dialihkan ke penyedia identitas eksternal untuk single sign-on dengan SAML, menggunakan kredensial yang ada untuk melakukan autentikasi. Tidak ada sandi yang disinkronkan dengan Cloud Identity.

Tabel berikut memberikan link ke panduan penyiapan untuk penyedia identitas.

Penyedia identitas	Panduan
Active Directory	Penyediaan akun pengguna Active Directory Single sign-on Active Directory
Microsoft Entra ID (sebelumnya Azure AD)	Menggabungkan Google Cloud dengan Microsoft Entra ID
Penyedia identitas eksternal lainnya (misalnya, Ping atau Okta)	Mengintegrasikan Ping Identity Solutions dengan Google Identity Services Menggunakan Okta dengan Penyedia Google Cloud Praktik terbaik untuk menggabungkan Google Cloud dengan penyedia identitas eksternal

Sebaiknya Anda menerapkan autentikasi multi-faktor di penyedia identitas dengan mekanisme yang tahan terhadap phishing seperti Kunci Keamanan Titan.

Setelan yang direkomendasikan untuk Cloud Identity tidak diotomatiskan melalui kode Terraform dalam blueprint ini. Lihat kontrol administratif untuk Cloud Identity untuk mengetahui setelan keamanan yang direkomendasikan yang harus Anda konfigurasikan selain men-deploy kode Terraform.

Grup untuk kontrol akses

Akun utama adalah identitas yang dapat diberi akses ke resource. Akun utama mencakup Akun Google untuk pengguna, grup Google, akun Google Workspace, domain Cloud Identity, dan akun layanan. Beberapa layanan juga memungkinkan Anda memberikan akses ke semua pengguna yang melakukan autentikasi dengan Akun Google, atau ke semua pengguna di internet. Agar akun utama dapat berinteraksi dengan layanan Google Cloud , Anda harus memberikan peran kepadanya di Identity and Access Management (IAM).

Untuk mengelola peran IAM dalam skala besar, sebaiknya tetapkan pengguna ke grup berdasarkan fungsi tugas dan persyaratan akses mereka, lalu berikan peran IAM ke grup tersebut. Anda harus menambahkan pengguna ke grup menggunakan proses di penyedia identitas yang ada untuk pembuatan dan keanggotaan grup.

Sebaiknya jangan berikan peran IAM kepada pengguna perorangan karena penetapan perorangan dapat meningkatkan kompleksitas pengelolaan dan pengauditan peran.

Blueprint mengonfigurasi grup dan peran untuk akses hanya lihat ke resource dasar. Sebaiknya deploy semua resource dalam blueprint melalui pipeline fondasi, dan jangan berikan peran kepada pengguna untuk grup agar dapat mengubah resource fondasi di luar pipeline.

Tabel berikut menunjukkan grup yang dikonfigurasi oleh blueprint untuk melihat resource foundation.

Nama	Deskripsi	Peran	Cakupan
[e-mail]	Administrator dengan hak istimewa tinggi yang dapat memberikan peran IAM di tingkat organisasi. Mereka dapat mengakses peran lainnya. Hak istimewa ini tidak direkomendasikan untuk penggunaan sehari-hari.	Organization Administrator	organisasi
[e-mail]	Administrator dengan hak istimewa tinggi yang dapat mengubah akun Penagihan Cloud. Hak istimewa ini tidak direkomendasikan untuk penggunaan harian.	Billing Account Admin	organisasi
[e-mail]	Tim yang bertanggung jawab untuk melihat dan menganalisis pengeluaran di semua project.	Billing Account Viewer	organisasi
		BigQuery User	project penagihan
[e-mail]	Tim yang bertanggung jawab untuk mengaudit log terkait keamanan.	Logs Viewer BigQuery User	project logging
[e-mail]	Tim yang bertanggung jawab untuk meninjau keamanan cloud.	Security Reviewer	organisasi
[e-mail]	Tim yang bertanggung jawab untuk melihat dan mengelola konfigurasi jaringan.	Penampil Jaringan Compute	organisasi
[e-mail]	Tim yang bertanggung jawab untuk mengonfigurasi Security Command Center.	Security Center Admin Editor	organisasi
[e-mail]	Tim yang bertanggung jawab mengelola, menyimpan, dan mengaudit kredensial dan secret lainnya yang digunakan oleh aplikasi.	Secret Manager Admin	project secret
[e-mail]	Tim yang bertanggung jawab untuk menerapkan pengelolaan kunci enkripsi guna memenuhi persyaratan kepatuhan.	Cloud KMS Viewer	project kms

Saat mem-build workload Anda sendiri di atas fondasi, Anda membuat grup tambahan dan memberikan peran IAM yang didasarkan pada persyaratan akses untuk setiap workload.

Sebaiknya hindari peran dasar (seperti Pemilik, Editor, atau Pengakses lihat-saja) dan gunakan peran standar sebagai gantinya. Peran dasar terlalu permisif dan berpotensi menimbulkan risiko keamanan. Peran Pemilik dan Editor dapat menyebabkan eskalasi hak istimewa dan pergerakan lateral, dan peran Pelihat mencakup akses untuk membaca semua data. Untuk praktik terbaik tentang peran IAM, lihat Menggunakan IAM dengan aman.

Akun admin super

Pengguna Cloud Identity dengan akun admin super akan mengabaikan setelan SSO organisasi dan melakukan autentikasi langsung ke Cloud Identity. Pengecualian ini memang disengaja, sehingga admin super masih dapat mengakses konsol Cloud Identity jika terjadi kesalahan konfigurasi atau pemadaman SSO. Namun, hal ini berarti Anda harus mempertimbangkan perlindungan tambahan untuk akun admin super.

Untuk melindungi akun admin super, sebaiknya Anda selalu menerapkan verifikasi 2 langkah dengan kunci keamanan di Cloud Identity. Untuk informasi selengkapnya, lihat Praktik terbaik keamanan untuk akun administrator.

Masalah pada akun pengguna konsumen

Jika Anda tidak menggunakan Cloud Identity atau Google Workspace sebelum diaktifkan di Google Cloud, karyawan organisasi Anda mungkin sudah menggunakan akun konsumen yang terkait dengan identitas email perusahaan mereka untuk mengakses layanan Google lainnya seperti Google Marketing Platform atau YouTube. Akun konsumen adalah akun yang sepenuhnya dimiliki dan dikelola oleh individu yang membuatnya. Karena akun tersebut tidak berada di bawah kendali organisasi Anda dan mungkin mencakup data pribadi dan perusahaan, Anda harus memutuskan cara menggabungkan akun ini dengan akun perusahaan lainnya.

Sebaiknya Anda menggabungkan akun pengguna konsumen yang ada sebagai bagian dari orientasi ke Google Cloud. Jika Anda belum menggunakan Google Workspace untuk semua akun pengguna, sebaiknya blokir pembuatan akun konsumen baru.

Kontrol administratif untuk Cloud Identity

Cloud Identity memiliki berbagai kontrol administratif yang tidak otomatis oleh kode Terraform dalam blueprint. Sebaiknya terapkan setiap kontrol keamanan praktik terbaik ini di awal proses pembuatan fondasi Anda.

Kontrol	Deskripsi
Men-deploy verifikasi 2 langkah	Akun pengguna mungkin disusupi melalui phishing, rekayasa sosial, penyemprotan sandi, atau berbagai ancaman lainnya. Verifikasi 2 langkah membantu mengurangi ancaman ini. Sebaiknya Anda menerapkan verifikasi 2 langkah untuk semua akun pengguna di organisasi dengan mekanisme yang tahan terhadap phishing, seperti Kunci Keamanan Titan atau kunci lain yang didasarkan pada standar FIDO U2F (CTAP1) yang tahan terhadap phishing.
Menetapkan durasi sesi untuk Google Cloud layanan	Token OAuth persisten di workstation developer dapat menjadi risiko keamanan jika terekspos. Sebaiknya tetapkan kebijakan autentikasi ulang untuk mewajibkan autentikasi setiap 16 jam menggunakan kunci keamanan.
Menetapkan durasi sesi untuk Layanan Google	(Khusus pelanggan Google Workspace) Sesi web persisten di seluruh layanan Google lainnya dapat menjadi risiko keamanan jika diekspos. Sebaiknya terapkan durasi sesi web maksimum dan sesuaikan dengan kontrol durasi sesi di penyedia SSO Anda.
Membagikan data dari Cloud Identity dengan Google Cloud layanan	Log audit Aktivitas Admin dari Google Workspace atau Cloud Identity biasanya dikelola dan dilihat di Konsol Admin, secara terpisah dari log Anda di lingkungan Google Cloud . Log ini berisi informasi yang relevan untuk lingkungan Google Cloud Anda, seperti peristiwa login pengguna. Sebaiknya bagikan log audit Cloud Identity ke lingkunganGoogle Cloud untuk mengelola log dari semua sumber secara terpusat.
Menyiapkan verifikasi pasca SSO	Blueprint ini mengasumsikan bahwa Anda menyiapkan SSO dengan penyedia identitas eksternal. Sebaiknya aktifkan lapisan kontrol tambahan berdasarkan analisis risiko login Google. Setelah Anda menerapkan setelan ini, pengguna mungkin melihat verifikasi login berbasis risiko tambahan saat login jika Google menilai bahwa login pengguna mencurigakan.
Memperbaiki masalah pada akun pengguna konsumen	Pengguna dengan alamat email yang valid di domain Anda, tetapi tidak memiliki Akun Google, dapat mendaftar ke akun konsumen yang tidak dikelola. Akun ini mungkin berisi data perusahaan, tetapi tidak dikontrol oleh proses pengelolaan siklus proses akun Anda. Sebaiknya Anda mengambil langkah-langkah untuk memastikan bahwa semua akun pengguna adalah akun terkelola.
Menonaktifkan pemulihan akun untuk akun admin super	Pemulihan mandiri akun admin super dinonaktifkan secara default untuk semua pelanggan baru (pelanggan lama mungkin mengaktifkan setelan ini). Menonaktifkan setelan ini membantu memitigasi risiko bahwa ponsel yang disusupi, email yang disusupi, atau serangan manipulasi psikologis dapat memungkinkan penyerang mendapatkan hak istimewa admin super atas lingkungan Anda. Rencanakan proses internal bagi admin super untuk menghubungi admin super lain di organisasi Anda jika mereka kehilangan akses ke akun mereka, dan pastikan semua admin super memahami proses untuk pemulihan dengan bantuan dukungan.
Menerapkan dan memantau persyaratan sandi untuk pengguna	Pada umumnya, sandi pengguna dikelola melalui penyedia identitas eksternal Anda, tetapi akun admin super mengabaikan SSO dan harus menggunakan sandi untuk login ke Cloud Identity. Nonaktifkan penggunaan kembali sandi dan pantau kekuatan sandi untuk pengguna yang menggunakan sandi untuk login ke Cloud Identity, terutama akun admin super.
Menetapkan kebijakan seluruh organisasi untuk menggunakan grup	Secara default, akun pengguna eksternal dapat ditambahkan ke grup di Cloud Identity. Sebaiknya konfigurasikan setelan berbagi agar pemilik grup tidak dapat menambahkan anggota eksternal. Perhatikan bahwa batasan ini tidak berlaku untuk akun admin super atau administrator lain yang didelegasikan dengan izin admin Grup. Karena federasi dari penyedia identitas Anda berjalan dengan hak istimewa administrator, setelan berbagi grup tidak berlaku untuk sinkronisasi grup ini. Sebaiknya tinjau kontrol di penyedia identitas dan mekanisme sinkronisasi untuk memastikan bahwa anggota non-domain tidak ditambahkan ke grup, atau Anda menerapkan pembatasan grup.

Langkah berikutnya

• Baca tentang struktur organisasi (dokumen berikutnya dalam seri ini).

Struktur organisasi

Node root untuk mengelola resource di Google Cloud adalah organisasi. Organisasi Google Cloud menyediakan hierarki resource yang menyediakan struktur kepemilikan untuk resource dan titik lampiran bagi kebijakan organisasi dan kontrol akses. Hierarki resource terdiri dari folder, project, dan resource serta menentukan struktur dan penggunaan layanan Google Cloud dalam organisasi.

Resource yang lebih rendah dalam hierarki mewarisi kebijakan seperti kebijakan izin IAM dan kebijakan organisasi. Semua izin akses ditolak secara default, hingga Anda menerapkan kebijakan izin secara langsung ke resource atau resource mewarisi kebijakan izin dari level yang lebih tinggi dalam hierarki resource.

Diagram berikut menunjukkan folder dan project yang di-deploy oleh blueprint.

Bagian berikut menjelaskan folder dan project dalam diagram.

Folder

Blueprint menggunakan folder untuk mengelompokkan project berdasarkan lingkungannya. Pengelompokan logis ini digunakan untuk menerapkan konfigurasi seperti kebijakan izin dan kebijakan organisasi di tingkat folder, lalu semua resource dalam folder mewarisi kebijakan tersebut. Tabel berikut menjelaskan folder yang merupakan bagian dari blueprint.

Folder	Deskripsi
bootstrap	Berisi project yang digunakan untuk men-deploy komponen fondasi.
common	Berisi project dengan resource yang dibagikan oleh semua lingkungan.
production	Berisi project dengan resource produksi.
nonproduction	Berisi salinan lingkungan produksi yang memungkinkan Anda menguji workload sebelum mempromosikannya ke produksi.
development	Berisi resource cloud yang digunakan untuk pengembangan.
networking	Berisi resource jaringan yang dibagikan oleh semua lingkungan.

Project

Blueprint menggunakan project untuk mengelompokkan setiap resource berdasarkan fungsinya dan batas yang dimaksudkan untuk kontrol akses. Tabel berikut menjelaskan project yang disertakan dalam blueprint.

Folder	Project	Deskripsi
bootstrap	prj-b-cicd	Berisi pipeline deployment yang digunakan untuk mem-build komponen dasar organisasi. Untuk mengetahui informasi selengkapnya, lihat metodologi deployment.
	prj-b-seed	Berisi status Terraform dari infrastruktur dan akun layanan Terraform yang diperlukan untuk menjalankan pipeline. Untuk mengetahui informasi selengkapnya, lihat metodologi deployment.
common	prj-c-secrets	Berisi rahasia tingkat tinggi organisasi. Untuk mengetahui informasi selengkapnya, lihat menyimpan kredensial aplikasi dengan Secret Manager.
	prj-c-logging	Berisi sumber log gabungan untuk log audit. Untuk mengetahui informasi selengkapnya, lihat logging terpusat untuk keamanan dan audit.
	prj-c-scc	Berisi referensi untuk membantu mengonfigurasi pemberitahuan Security Command Center dan pemantauan keamanan kustom lainnya. Untuk informasi selengkapnya, lihat pemantauan ancaman dengan Security Command Center.
	prj-c-billing-export	Berisi set data BigQuery dengan ekspor penagihan organisasi. Untuk informasi selengkapnya, lihat mengalokasikan biaya antara pusat biaya internal.
	prj-c-infra-pipeline	Berisi pipeline infrastruktur untuk men-deploy resource seperti VM dan database yang akan digunakan oleh workload. Untuk mengetahui informasi selengkapnya, lihat lapisan pipeline.
	prj-c-kms	Berisi kunci enkripsi tingkat organisasi. Untuk informasi selengkapnya, lihat mengelola kunci enkripsi.
networking	prj-net-{env}-shared-base	Berisi project host untuk jaringan VPC Bersama bagi workload yang tidak memerlukan Kontrol Layanan VPC. Untuk mengetahui informasi selengkapnya, lihat topologi jaringan.
	prj-net-{env}-shared-restricted	Berisi project host untuk jaringan VPC Bersama bagi workload yang memerlukan Kontrol Layanan VPC. Untuk mengetahui informasi selengkapnya, lihat topologi jaringan.
	prj-net-interconnect	Berisi koneksi Cloud Interconnect yang menyediakan konektivitas antara lingkungan lokal Anda dan Google Cloud. Untuk mengetahui informasi selengkapnya, lihat konektivitas hybrid.
	prj-net-dns-hub	Berisi resource untuk titik komunikasi terpusat antara sistem DNS lokal dan Cloud DNS. Untuk informasi selengkapnya, lihat penyiapan DNS terpusat.
prj-{env}-secrets	Berisi rahasia tingkat folder. Untuk mengetahui informasi selengkapnya, lihat menyimpan dan mengaudit kredensial aplikasi dengan Secret Manager.
prj-{env}-kms	Berisi kunci enkripsi tingkat folder. Untuk informasi selengkapnya, lihat mengelola kunci enkripsi.
project aplikasi	Berisi berbagai project tempat Anda membuat resource untuk aplikasi. Untuk informasi selengkapnya, lihat pola deployment project dan lapisan pipeline.

Tata kelola untuk kepemilikan resource

Sebaiknya terapkan label secara konsisten ke project Anda untuk membantu pemerintahan dan alokasi biaya. Tabel berikut menjelaskan label project yang ditambahkan ke setiap project untuk tata kelola dalam blueprint.

Label	Deskripsi
application	Nama aplikasi atau beban kerja yang dapat dibaca manusia dan dikaitkan dengan project.
businesscode	Kode singkat yang menjelaskan unit bisnis mana yang memiliki project. Kode shared digunakan untuk project umum yang tidak terikat secara eksplisit dengan unit bisnis.
billingcode	Kode yang digunakan untuk memberikan informasi penagihan balik.
primarycontact	Nama pengguna kontak utama yang bertanggung jawab atas project. Karena label project tidak dapat menyertakan karakter khusus seperti ampersand (@), label tersebut ditetapkan ke nama pengguna tanpa akhiran @example.com.
secondarycontact	Nama pengguna kontak sekunder sekunder yang bertanggung jawab atas project. Karena label project tidak dapat menyertakan karakter khusus seperti @, tetapkan hanya nama pengguna tanpa akhiran @example.com.
environment	Nilai yang mengidentifikasi jenis lingkungan, seperti bootstrap, common, production, non-production,development, atau network.
envcode	Nilai yang mengidentifikasi jenis lingkungan, disingkat menjadi b, c, p, n, d, atau net.
vpc	ID jaringan VPC yang diharapkan akan digunakan project ini.

Google terkadang mengirimkan notifikasi penting seperti penangguhan akun atau pembaruan pada persyaratan produk. Blueprint menggunakan Kontak Penting untuk mengirim notifikasi tersebut ke grup yang Anda konfigurasi selama deployment. Kontak Penting dikonfigurasi di node organisasi dan diwarisi oleh semua project dalam organisasi. Sebaiknya tinjau grup ini dan pastikan email dipantau dengan andal.

Kontak Penting digunakan untuk tujuan yang berbeda dengan kolom primarycontact dan secondarycontact yang dikonfigurasi dalam label project. Kontak di label project ditujukan untuk tata kelola internal. Misalnya, jika Anda mengidentifikasi resource yang tidak mematuhi kebijakan di project workload dan perlu menghubungi pemiliknya, Anda dapat menggunakan kolom primarycontact untuk menemukan orang atau tim yang bertanggung jawab atas workload tersebut.

Langkah berikutnya

• Baca tentang jaringan (dokumen berikutnya dalam seri ini).

Jaringan

Jaringan diperlukan agar resource dapat berkomunikasi dalam organisasi Google Cloud Anda dan antara lingkungan cloud dan lingkungan lokal. Bagian ini menjelaskan struktur dalam blueprint untuk jaringan VPC, ruang alamat IP, DNS, kebijakan firewall, dan konektivitas ke lingkungan lokal.

Topologi jaringan

Repositori blueprint menyediakan opsi berikut untuk topologi jaringan Anda:

• Gunakan jaringan VPC Bersama terpisah untuk setiap lingkungan, tanpa traffic jaringan yang diizinkan secara langsung di antara lingkungan.
• Gunakan model hub-and-spoke yang menambahkan jaringan hub untuk menghubungkan setiap lingkungan di Google Cloud, dengan traffic jaringan di antara lingkungan yang dibatasi oleh peralatan virtual jaringan (NVA).

Pilih topologi jaringan Shared VPC ganda jika Anda tidak ingin konektivitas jaringan langsung antar-lingkungan. Pilih topologi jaringan hub-and-spoke jika Anda ingin mengizinkan konektivitas jaringan antar-lingkungan yang difilter oleh NVA, seperti saat Anda mengandalkan alat yang ada yang memerlukan jalur jaringan langsung ke setiap server di lingkungan Anda.

Kedua topologi tersebut menggunakan VPC Bersama sebagai konstruksi jaringan utama karena VPC Bersama memungkinkan pemisahan tanggung jawab yang jelas. Administrator jaringan mengelola resource jaringan dalam project host terpusat, dan tim workload men-deploy resource aplikasi mereka sendiri dan menggunakan resource jaringan dalam project layanan yang dilampirkan ke project host.

Kedua topologi tersebut menyertakan versi dasar dan versi terbatas dari setiap jaringan VPC. Jaringan VPC dasar digunakan untuk resource yang berisi data non-sensitif, dan jaringan VPC yang dibatasi digunakan untuk resource dengan data sensitif yang memerlukan Kontrol Layanan VPC. Untuk informasi selengkapnya tentang cara menerapkan Kontrol Layanan VPC, lihat Melindungi resource Anda dengan Kontrol Layanan VPC.

Topologi jaringan VPC Bersama ganda

Jika Anda memerlukan isolasi jaringan antara jaringan pengembangan, non-produksi, dan produksi di Google Cloud, sebaiknya gunakan topologi jaringan VPC Bersama ganda. Topologi ini menggunakan jaringan VPC Bersama yang terpisah untuk setiap lingkungan, dengan setiap lingkungan juga dibagi antara jaringan VPC Bersama dasar dan jaringan VPC Bersama terbatas.

Diagram berikut menunjukkan topologi jaringan VPC Bersama ganda.

Diagram ini menjelaskan konsep utama topologi VPC Bersama ganda ini:

• Setiap lingkungan (produksi, non-produksi, dan pengembangan) memiliki satu jaringan VPC Bersama untuk jaringan dasar dan satu jaringan VPC Bersama untuk jaringan yang dibatasi. Diagram ini hanya menunjukkan lingkungan produksi, tetapi pola yang sama diulang untuk setiap lingkungan.
• Setiap jaringan VPC Bersama memiliki dua subnet, dengan setiap subnet di region yang berbeda.
• Konektivitas dengan resource lokal diaktifkan melalui empat lampiran VLAN ke instance Dedicated Interconnect untuk setiap jaringan VPC Bersama, menggunakan empat layanan Cloud Router (dua di setiap region untuk redundansi). Untuk informasi selengkapnya, lihat Konektivitas hybrid antara lingkungan lokal dan Google Cloud.

Berdasarkan desainnya, topologi ini tidak mengizinkan traffic jaringan mengalir langsung di antara lingkungan. Jika Anda memerlukan traffic jaringan untuk mengalir langsung antar-lingkungan, Anda harus melakukan langkah tambahan untuk mengizinkan jalur jaringan ini. Misalnya, Anda dapat mengonfigurasi endpoint Private Service Connect untuk mengekspos layanan dari satu jaringan VPC ke jaringan VPC lain. Atau, Anda dapat mengonfigurasi jaringan lokal untuk mengizinkan traffic mengalir dari satu lingkunganGoogle Cloud ke lingkungan lokal, lalu ke lingkungan Google Cloud lain.

Topologi jaringan hub-and-spoke

Jika Anda men-deploy resource di Google Cloud yang memerlukan jalur jaringan langsung ke resource di beberapa lingkungan, sebaiknya gunakan topologi jaringan hub-and-spoke.

Topologi hub-and-spoke menggunakan beberapa konsep yang merupakan bagian dari topologi VPC Bersama ganda, tetapi mengubah topologi untuk menambahkan jaringan hub. Diagram berikut menunjukkan topologi hub-and-spoke.

Diagram ini menjelaskan konsep utama topologi jaringan hub-and-spoke berikut:

• Model ini menambahkan jaringan hub, dan setiap jaringan pengembangan, non-produksi, dan produksi (spoke) terhubung ke jaringan hub melalui VPC Network Peering. Atau, jika Anda memperkirakan akan melampaui batas kuota, Anda dapat menggunakan gateway VPN dengan ketersediaan tinggi (HA).
• Konektivitas ke jaringan lokal hanya diizinkan melalui jaringan hub. Semua jaringan spoke dapat berkomunikasi dengan resource bersama di jaringan hub dan menggunakan jalur ini untuk terhubung ke jaringan lokal.
• Jaringan hub menyertakan NVA untuk setiap wilayah, yang di-deploy secara redundan di belakang instance Load Balancer Jaringan internal. NVA ini berfungsi sebagai gateway untuk mengizinkan atau menolak traffic agar dapat berkomunikasi antar-jaringan spoke.
• Jaringan hub juga menghosting alat yang memerlukan konektivitas ke semua jaringan lainnya. Misalnya, Anda dapat men-deploy alat di instance VM untuk pengelolaan konfigurasi ke lingkungan umum.
• Model hub-and-spoke diduplikasi untuk versi dasar dan versi terbatas dari setiap jaringan.

Untuk mengaktifkan traffic spoke-to-spoke, blueprint men-deploy NVA di jaringan VPC Bersama hub yang berfungsi sebagai gateway antarjaringan. Rute ditukar dari jaringan VPC hub-ke-spoke melalui pertukaran rute kustom. Dalam skenario ini, konektivitas antara spoke harus dirutekan melalui NVA karena Peering Jaringan VPC bersifat non-transitif, sehingga jaringan VPC spoke tidak dapat saling bertukar data secara langsung. Anda harus mengonfigurasi peralatan virtual untuk mengizinkan traffic secara selektif di antara spoke.

Pola deployment project

Saat membuat project baru untuk beban kerja, Anda harus memutuskan cara resource dalam project ini terhubung ke jaringan yang ada. Tabel berikut menjelaskan pola untuk men-deploy project yang digunakan dalam blueprint.

Pola	Deskripsi	Contoh penggunaan
Project dasar bersama	Project ini dikonfigurasi sebagai project layanan ke project host VPC Bersama dasar. Gunakan pola ini jika resource dalam project Anda memiliki kriteria berikut: Memerlukan konektivitas jaringan ke lingkungan atau resource lokal di topologi VPC Bersama yang sama. Memerlukan jalur jaringan ke layanan Google yang terdapat di alamat IP virtual pribadi. Tidak memerlukan Kontrol Layanan VPC.	example_base_shared_vpc_project.tf
Project bersama yang dibatasi	Project ini dikonfigurasi sebagai project layanan ke project host VPC Bersama yang dibatasi. Gunakan pola ini jika resource dalam project Anda memiliki kriteria berikut: Memerlukan konektivitas jaringan ke lingkungan atau resource lokal di topologi VPC Bersama yang sama. Memerlukan jalur jaringan ke layanan Google yang terdapat di alamat IP virtual yang dibatasi. Wajibkan Kontrol Layanan VPC.	example_restricted_shared_vpc_project.tf
Project mengambang	Project mengambang tidak terhubung ke jaringan VPC lain dalam topologi Anda. Gunakan pola ini jika resource dalam project Anda memiliki kriteria berikut: Tidak memerlukan konektivitas mesh penuh ke lingkungan atau resource lokal di topologi VPC Bersama. Tidak memerlukan jaringan VPC, atau Anda ingin mengelola jaringan VPC untuk project ini secara terpisah dari topologi jaringan VPC utama (seperti saat Anda ingin menggunakan rentang alamat IP yang bertentangan dengan rentang yang sudah digunakan). Anda mungkin memiliki skenario saat ingin mempertahankan jaringan VPC project mengambang terpisah dari topologi jaringan VPC utama, tetapi juga ingin mengekspos sejumlah terbatas endpoint di antara jaringan. Dalam hal ini, publikasikan layanan menggunakan Private Service Connect untuk berbagi akses jaringan ke setiap endpoint di seluruh jaringan VPC tanpa mengekspos seluruh jaringan.	example_floating_project.tf
Project peering	Project peering membuat jaringan VPC-nya sendiri dan melakukan peering ke jaringan VPC lain dalam topologi Anda. Gunakan pola ini jika resource dalam project Anda memiliki kriteria berikut: Memerlukan konektivitas jaringan di jaringan VPC yang di-peering secara langsung, tetapi tidak memerlukan konektivitas transitif ke lingkungan lokal atau jaringan VPC lainnya. Harus mengelola jaringan VPC untuk project ini secara terpisah dari topologi jaringan utama Anda. Jika Anda membuat project peering, Anda bertanggung jawab untuk mengalokasikan rentang alamat IP yang tidak bertentangan dan merencanakan kuota grup peering.	example_peering_project.tf

Alokasi alamat IP

Bagian ini memperkenalkan cara arsitektur blueprint mengalokasikan rentang alamat IP. Anda mungkin perlu mengubah rentang alamat IP tertentu yang digunakan berdasarkan ketersediaan alamat IP di lingkungan hybrid yang ada.

Tabel berikut memberikan perincian ruang alamat IP yang dialokasikan untuk blueprint. Lingkungan hub hanya berlaku dalam topologi hub-and-spoke.

Tujuan	Jenis VPC	Wilayah	Lingkungan hub	Lingkungan pengembangan	Lingkungan non-produksi	Lingkungan produksi
Rentang subnet utama	Dasar	Region 1	10.0.0.0/18	10.0.64.0/18	10.0.128.0/18	10.0.192.0/18
		Region 2	10.1.0.0/18	10.1.64.0/18	10.1.128.0/18	10.1.192.0/18
		Belum dialokasikan	10.{2-7}.0.0/18	10.{2-7}.64.0/18	10.{2-7}.128.0/18	10.{2-7}.192.0/18
	Dibatasi	Region 1	10.8.0.0/18	10.8.64.0/18	10.8.128.0/18	10.8.192.0/18
		Region 2	10.9.0.0/18	10.9.64.0/18	10.9.128.0/18	10.9.192.0/18
		Belum dialokasikan	10.{10-15}.0.0/18	10.{10-15}.64.0/18	10.{10-15}.128.0/18	10.{10-15}.192.0/18
Akses layanan pribadi	Dasar	Global	10.16.0.0/21	10.16.8.0/21	10.16.16.0/21	10.16.24.0/21
	Dibatasi	Global	10.16.32.0/21	10.16.40.0/21	10.16.48.0/21	10.16.56.0/21
Endpoint Private Service Connect	Dasar	Global	10.17.0.1/32	10.17.0.2/32	10.17.0.3/32	10.17.0.4/32
	Dibatasi	Global	10.17.0.5/32	10.17.0.6/32	10.17.0.7/32	10.17.0.8/32
Subnet khusus proxy	Dasar	Region 1	10.18.0.0/23	10.18.2.0/23	10.18.4.0/23	10.18.6.0/23
		Region 2	10.19.0.0/23	10.19.2.0/23	10.19.4.0/23	10.19.6.0/23
		Belum dialokasikan	10.{20-25}.0.0/23	10.{20-25}.2.0/23	10.{20-25}.4.0/23	10.{20-25}.6.0/23
	Dibatasi	Region 1	10.26.0.0/23	10.26.2.0/23	10.26.4.0/23	10.26.6.0/23
		Region 2	10.27.0.0/23	10.27.2.0/23	10.27.4.0/23	10.27.6.0/23
		Belum dialokasikan	10.{28-33}.0.0/23	10.{28-33}.2.0/23	10.{28-33}.4.0/23	10.{28-33}.6.0/23
Rentang subnet sekunder	Dasar	Region 1	100.64.0.0/18	100.64.64.0/18	100.64.128.0/18	100.64.192.0/18
		Region 2	100.65.0.0/18	100.65.64.0/18	100.65.128.0/18	100.65.192.0/18
		Belum dialokasikan	100.{66-71}.0.0/18	100.{66-71}.64.0/18	100.{66-71}.128.0/18	100.{66-71}.192.0/18
	Dibatasi	Region 1	100.72.0.0/18	100.72.64.0/18	100.72.128.0/18	100.72.192.0/18
		Region 2	100.73.0.0/18	100.73.64.0/18	100.73.128.0/18	100.73.192.0/18
		Belum dialokasikan	100.{74-79}.0.0/18	100.{74-79}.64.0/18	100.{74-79}.128.0/18	100.{74-79}.192.0/18

Tabel sebelumnya menunjukkan konsep ini untuk mengalokasikan rentang alamat IP:

• Alokasi alamat IP dibagi lagi menjadi beberapa rentang untuk setiap kombinasi VPC Bersama dasar, VPC Bersama yang dibatasi, region, dan lingkungan.
• Beberapa resource bersifat global dan tidak memerlukan subdivisi untuk setiap region.
• Secara default, untuk resource regional, blueprint di-deploy di dua region. Selain itu, ada rentang alamat IP yang tidak digunakan sehingga Anda dapat memperluas ke enam region tambahan.
• Jaringan hub hanya digunakan dalam topologi jaringan hub-and-spoke, sedangkan lingkungan pengembangan, non-produksi, dan produksi digunakan dalam kedua topologi jaringan.

Tabel berikut memperkenalkan cara penggunaan setiap jenis rentang alamat IP.

Tujuan	Deskripsi
Rentang subnet utama	Resource yang Anda deploy ke jaringan VPC, seperti instance virtual machine, menggunakan alamat IP internal dari rentang ini.
Akses layanan pribadi	Beberapa Google Cloud layanan seperti Cloud SQL mengharuskan Anda mengalokasikan rentang subnet terlebih dahulu untuk akses layanan pribadi. Blueprint mencadangkan rentang /21 secara global untuk setiap jaringan VPC Bersama guna mengalokasikan alamat IP untuk layanan yang memerlukan akses layanan pribadi. Saat membuat layanan yang bergantung pada akses layanan pribadi, Anda mengalokasikan subnet /24 regional dari rentang /21 yang dicadangkan.
Private Service Connect	Blueprint menyediakan setiap jaringan VPC dengan endpoint Private Service Connect untuk berkomunikasi dengan Google Cloud API. Endpoint ini memungkinkan resource Anda di jaringan VPC menjangkau Google Cloud API tanpa mengandalkan traffic keluar ke internet atau rentang internet yang diiklankan secara publik.
Load balancer berbasis proxy	Beberapa jenis Load Balancer Aplikasi mengharuskan Anda melakukan pra-alokasi subnet khusus proxy. Meskipun blueprint tidak men-deploy Application Load Balancer yang memerlukan rentang ini, mengalokasikan rentang terlebih dahulu akan membantu mengurangi hambatan untuk workload saat perlu meminta rentang subnet baru untuk mengaktifkan resource load balancer tertentu.
Rentang subnet sekunder	Beberapa kasus penggunaan, seperti beban kerja berbasis container, memerlukan rentang sekunder. Blueprint mengalokasikan rentang dari ruang alamat IP RFC 6598 untuk rentang sekunder.

Penyiapan DNS terpusat

Untuk resolusi DNS antara Google Cloud dan lingkungan lokal, sebaiknya Anda menggunakan pendekatan campuran dengan dua sistem DNS yang kredibel. Dalam pendekatan ini, Cloud DNS menangani resolusi DNS otoritatif untuk lingkunganGoogle Cloud dan server DNS lokal yang ada menangani resolusi DNS otoritatif untuk resource lokal. Lingkungan lokal dan lingkungan Google Cloud Anda melakukan pencarian DNS di antara lingkungan melalui permintaan penerusan.

Diagram berikut menunjukkan topologi DNS di beberapa jaringan VPC yang digunakan dalam blueprint.

Diagram ini menjelaskan komponen desain DNS berikut yang di-deploy oleh blueprint:

• Project hub DNS di folder umum adalah titik pusat pertukaran DNS antara lingkungan lokal dan lingkungan Google Cloud. Penerusan DNS menggunakan instance Dedicated Interconnect dan Cloud Router yang sama yang sudah dikonfigurasi dalam topologi jaringan Anda.
  • Dalam topologi VPC Bersama ganda, hub DNS menggunakan jaringan VPC Bersama produksi dasar.
  • Dalam topologi hub-and-spoke, hub DNS menggunakan jaringan VPC Bersama hub dasar.
• Server di setiap jaringan VPC Bersama dapat me-resolve data DNS dari jaringan VPC Bersama lainnya melalui penerusan DNS, yang dikonfigurasi antara Cloud DNS di setiap project host VPC Bersama dan hub DNS.
• Server lokal dapat me-resolve data DNS di lingkungan Google Cloudmenggunakan kebijakan server DNS yang mengizinkan kueri dari server lokal. Blueprint mengonfigurasi kebijakan server masuk di hub DNS untuk mengalokasikan alamat IP, dan server DNS lokal meneruskan permintaan ke alamat ini. Semua permintaan DNS ke Google Cloud akan menjangkau hub DNS terlebih dahulu, yang kemudian me-resolve data dari peer DNS.
• Server di Google Cloud dapat me-resolve data DNS di lingkungan lokal menggunakan zona penerusan yang mengkueri server lokal. Semua permintaan DNS ke lingkungan lokal berasal dari hub DNS. Sumber permintaan DNS adalah 35.199.192.0/19.

Kebijakan firewall

Google Cloud memiliki beberapa jenis kebijakan firewall. Kebijakan firewall hierarkis diterapkan di tingkat organisasi atau folder untuk mewarisi aturan kebijakan firewall secara konsisten di semua resource dalam hierarki. Selain itu, Anda dapat mengonfigurasi kebijakan firewall jaringan untuk setiap jaringan VPC. Blueprint ini menggabungkan kebijakan firewall ini untuk menerapkan konfigurasi umum di semua lingkungan menggunakan kebijakan firewall Hierarkis dan untuk menerapkan konfigurasi yang lebih spesifik di setiap jaringan VPC menggunakan kebijakan firewall jaringan.

Blueprint tidak menggunakan aturan firewall VPC lama. Sebaiknya gunakan hanya kebijakan firewall dan hindari penggunaan campuran dengan aturan firewall VPC lama.

Kebijakan firewall hierarkis

Blueprint menentukan satu kebijakan firewall hierarkis dan melampirkan kebijakan ke setiap folder produksi, non-produksi, pengembangan, bootstrap, dan umum. Kebijakan firewall hierarkis ini berisi aturan yang harus diterapkan secara luas di semua lingkungan, dan mendelegasikan evaluasi aturan yang lebih terperinci ke kebijakan firewall jaringan untuk setiap lingkungan.

Tabel berikut menjelaskan aturan kebijakan firewall hierarkis yang di-deploy oleh blueprint.

Deskripsi aturan	Direction of traffic	Filter (rentang IPv4)	Protocols and ports	Tindakan
Delegasikan evaluasi traffic masuk dari RFC 1918 ke tingkat yang lebih rendah dalam hierarki.	Ingress	192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12	all	Go to next
Delegasikan evaluasi traffic keluar ke RFC 1918 ke tingkat yang lebih rendah dalam hierarki.	Egress	192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12	all	Go to next
IAP untuk penerusan TCP	Ingress	35.235.240.0/20	tcp:22,3389	Allow
Aktifasi server Windows	Egress	35.190.247.13/32	tcp:1688	Allow
Health check untuk Cloud Load Balancing	Ingress	130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22	tcp:80,443	Allow

Kebijakan firewall jaringan

Blueprint mengonfigurasi kebijakan firewall jaringan untuk setiap jaringan. Setiap kebijakan firewall jaringan dimulai dengan serangkaian aturan minimum yang mengizinkan akses ke layanan Google Cloud dan menolak keluar ke semua alamat IP lainnya.

Dalam model hub-and-spoke, kebijakan firewall jaringan berisi aturan tambahan untuk mengizinkan komunikasi antar-spoke. Kebijakan firewall jaringan mengizinkan traffic keluar dari satu spoke ke hub atau spoke lain, dan mengizinkan traffic masuk dari NVA di jaringan hub.

Tabel berikut menjelaskan aturan dalam kebijakan firewall jaringan global yang di-deploy untuk setiap jaringan VPC dalam blueprint.

Deskripsi aturan	Direction of traffic	Filter	Protocols and ports
Izinkan traffic keluar ke Google Cloud API.	Egress	Endpoint Private Service Connect yang dikonfigurasi untuk setiap jaringan. Lihat Akses pribadi ke Google API.	tcp:443
Menolak traffic keluar yang tidak cocok dengan aturan lain.	Egress	semua	all
Mengizinkan traffic keluar dari satu spoke ke spoke lain (khusus model hub-and-spoke).	Egress	Agregat dari semua alamat IP yang digunakan dalam topologi hub-and-spoke. Traffic yang keluar dari VPC spoke dirutekan ke NVA di jaringan hub terlebih dahulu.	all
Mengizinkan traffic masuk ke spoke dari NVA di jaringan hub (khusus model hub-and-spoke).	Ingress	Traffic yang berasal dari NVA di jaringan hub.	all

Saat Anda pertama kali men-deploy blueprint, instance VM di jaringan VPC dapat berkomunikasi dengan layanan Google Cloud , tetapi tidak dengan resource infrastruktur lain di jaringan VPC yang sama. Agar instance VM dapat berkomunikasi, Anda harus menambahkan aturan tambahan ke kebijakan firewall jaringan dan tag yang secara eksplisit mengizinkan instance VM untuk berkomunikasi. Tag ditambahkan ke instance VM, dan traffic dievaluasi berdasarkan tag tersebut. Tag juga memiliki kontrol IAM sehingga Anda dapat menentukannya secara terpusat dan mendelegasikan penggunaannya ke tim lain.

Catatan: Semua referensi ke tag dalam dokumen ini merujuk ke tag dengan kontrol IAM. Sebaiknya jangan gunakan aturan firewall VPC dengan tag jaringan lama.

Diagram berikut menunjukkan contoh cara menambahkan tag kustom dan aturan kebijakan firewall jaringan untuk memungkinkan workload berkomunikasi di dalam jaringan VPC.

Diagram ini menunjukkan konsep berikut dari contoh ini:

• Kebijakan firewall jaringan berisi Aturan 1 yang menolak traffic keluar dari semua sumber dengan prioritas 65530.
• Kebijakan firewall jaringan berisi Aturan 2 yang mengizinkan traffic masuk dari instance dengan tag service=frontend ke instance dengan tag service=backend dengan prioritas 999.
• VM instance-2 dapat menerima traffic dari instance-1 karena traffic cocok dengan tag yang diizinkan oleh Aturan 2. Aturan 2 dicocokkan sebelum Aturan 1 dievaluasi, berdasarkan nilai prioritas.
• VM instance-3 tidak menerima traffic. Satu-satunya aturan kebijakan firewall yang cocok dengan traffic ini adalah Aturan 1, sehingga traffic keluar dari instance-1 akan ditolak.

Akses pribadi ke Google Cloud API

Agar resource di jaringan VPC atau lingkungan lokal Anda dapat menjangkau layananGoogle Cloud , sebaiknya gunakan konektivitas pribadi, bukan traffic internet keluar ke endpoint API publik. Blueprint mengonfigurasi Akses Google Pribadi di setiap subnet dan membuat endpoint internal dengan Private Service Connect untuk berkomunikasi dengan layanan Google Cloud . Jika digunakan bersama, kontrol ini akan mengizinkan jalur pribadi ke layanan Google Cloud , tanpa mengandalkan traffic keluar internet atau rentang internet yang diiklankan secara publik.

Blueprint mengonfigurasi endpoint Private Service Connect dengan paket API untuk membedakan layanan mana yang dapat diakses di jaringan mana. Jaringan dasar menggunakan paket all-apis dan dapat menjangkau layanan Google apa pun, dan jaringan yang dibatasi menggunakan paket vpcsc yang memungkinkan akses ke kumpulan layanan terbatas yang mendukung Kontrol Layanan VPC.

Untuk akses dari host yang berada di lingkungan lokal, sebaiknya Anda menggunakan konvensi FQDN kustom untuk setiap endpoint, seperti yang dijelaskan dalam tabel berikut. Blueprint menggunakan endpoint Private Service Connect unik untuk setiap jaringan VPC, yang dikonfigurasi untuk akses ke kumpulan paket API yang berbeda. Oleh karena itu, Anda harus mempertimbangkan cara me-rutekan traffic layanan dari lingkungan lokal ke jaringan VPC dengan endpoint API yang benar, dan jika Anda menggunakan Kontrol Layanan VPC, pastikan traffic ke layanan Google Cloud mencapai endpoint di dalam perimeter yang diinginkan. Konfigurasikan kontrol lokal Anda untuk DNS, firewall, dan router agar mengizinkan akses ke endpoint ini, dan konfigurasikan host lokal untuk menggunakan endpoint yang sesuai. Untuk informasi selengkapnya, lihat mengakses Google API melalui endpoint.

Tabel berikut menjelaskan endpoint Private Service Connect yang dibuat untuk setiap jaringan.

VPC	Lingkungan	Paket API	Alamat IP endpoint Private Service Connect			FQDN Kustom
Dasar	Umum	all-apis	10.17.0.1/32			c.private.googleapis.com
	Pengembangan	all-apis	10.17.0.2/32			d.private.googleapis.com
	Non-produksi	all-apis	10.17.0.3/32			n.private.googleapis.com
	Produksi	all-apis	10.17.0.4/32			p.private.googleapis.com
Dibatasi	Umum	vpcsc	10.17.0.5/32			c.restricted.googleapis.com
	Pengembangan	vpcsc	10.17.0.6/32			d.restricted.googleapis.com
	Non-produksi	vpcsc	10.17.0.7/32			n.restricted.googleapis.com
	Produksi	vpcsc	10.17.0.8/32			p.restricted.googleapis.com

Untuk memastikan bahwa traffic untuk layanan Google Cloud memiliki pencarian DNS ke endpoint yang benar, blueprint mengonfigurasi zona DNS pribadi untuk setiap jaringan VPC. Tabel berikut menjelaskan zona DNS pribadi ini.

Nama zona pribadi	Nama DNS	Jenis data	Data
googleapis.com.	*.googleapis.com.	CNAME	private.googleapis.com. (untuk jaringan dasar) atau restricted.googleapis.com. (untuk jaringan terbatas)
	private.googleapis.com (untuk jaringan dasar) atau restricted.googleapis.com (untuk jaringan terbatas)	A	Alamat IP endpoint Private Service Connect untuk jaringan VPC tersebut.
gcr.io.	*.gcr.io	CNAME	gcr.io.
	gcr.io	A	Alamat IP endpoint Private Service Connect untuk jaringan VPC tersebut.
pkg.dev.	*.pkg.dev.	CNAME	pkg.dev.
	pkg.dev.	A	Alamat IP endpoint Private Service Connect untuk jaringan VPC tersebut.

Blueprint memiliki konfigurasi tambahan untuk memastikan bahwa endpoint Private Service Connect ini digunakan secara konsisten. Setiap jaringan VPC Bersama juga menerapkan hal berikut:

• Aturan kebijakan firewall jaringan yang mengizinkan traffic keluar dari semua sumber ke alamat IP endpoint Private Service Connect di TCP:443.
• Aturan kebijakan firewall jaringan yang menolak traffic keluar ke 0.0.0.0/0, yang mencakup domain default yang digunakan untuk akses ke layanan Google Cloud .

Konektivitas internet

Blueprint tidak mengizinkan traffic masuk atau keluar antara jaringan VPC-nya dan internet. Untuk beban kerja yang memerlukan konektivitas internet, Anda harus melakukan langkah-langkah tambahan untuk mendesain jalur akses yang diperlukan.

Untuk beban kerja yang memerlukan traffic keluar ke internet, sebaiknya Anda mengelola traffic keluar melalui Cloud NAT untuk mengizinkan traffic keluar tanpa koneksi masuk yang tidak diminta, atau melalui Secure Web Proxy untuk kontrol yang lebih terperinci guna mengizinkan traffic keluar hanya ke layanan web yang tepercaya.

Untuk beban kerja yang memerlukan traffic masuk dari internet, sebaiknya Anda mendesain beban kerja dengan Cloud Load Balancing dan Google Cloud Armor untuk mendapatkan manfaat dari perlindungan DDoS dan WAF.

Sebaiknya Anda tidak mendesain beban kerja yang memungkinkan konektivitas langsung antara internet dan VM menggunakan alamat IP eksternal di VM.

Konektivitas hybrid antara lingkungan lokal dan Google Cloud

Untuk membangun konektivitas antara lingkungan lokal dan Google Cloud, sebaiknya gunakan Dedicated Interconnect untuk memaksimalkan keamanan dan keandalan. Koneksi Dedicated Interconnect adalah link langsung antara jaringan lokal dan Google Cloud.

Diagram berikut memperkenalkan konektivitas hybrid antara lingkungan lokal dan jaringan Virtual Private Cloud Google.

Diagram ini menjelaskan komponen pola berikut untuk ketersediaan 99,99% untuk Dedicated Interconnect:

• Empat koneksi Dedicated Interconnect, dengan dua koneksi di satu area metropolitan (metro) dan dua koneksi di metro lain. Dalam setiap metro, ada dua zona berbeda dalam fasilitas kolokasi.
• Koneksi dibagi menjadi dua pasangan, dan setiap pasangan terhubung ke pusat data lokal yang terpisah.
• Lampiran VLAN digunakan untuk menghubungkan setiap instance Dedicated Interconnect ke Cloud Router yang terpasang ke topologi VPC Bersama.
• Setiap jaringan VPC Bersama memiliki empat Cloud Router, dua di setiap region, dengan mode pemilihan rute dinamis yang ditetapkan ke global sehingga setiap Cloud Router dapat mengumumkan semua subnet, terlepas dari region.

Dengan perutean dinamis global, Cloud Router mengiklankan rute ke semua subnet di jaringan VPC. Cloud Router mengiklankan rute ke subnet jarak jauh (subnet di luar region Cloud Router) dengan prioritas yang lebih rendah dibandingkan dengan subnet lokal (subnet yang berada di region Cloud Router). Secara opsional, Anda dapat mengubah awalan dan prioritas yang diiklankan saat mengonfigurasi sesi BGP untuk Cloud Router.

Traffic dari Google Cloud ke lingkungan lokal menggunakan Cloud Router yang terdekat dengan resource cloud. Dalam satu region, beberapa rute ke jaringan lokal memiliki nilai multi-exit discriminator (MED) yang sama, dan Google Cloud menggunakan perutean equal cost multi-path (ECMP) untuk mendistribusikan traffic keluar di antara semua rute yang mungkin.

Perubahan konfigurasi lokal

Untuk mengonfigurasi konektivitas antara lingkungan lokal dan Google Cloud, Anda harus mengonfigurasi perubahan tambahan di lingkungan lokal. Kode Terraform dalam blueprint akan otomatis mengonfigurasi resourceGoogle Cloud , tetapi tidak mengubah resource jaringan on-premise Anda.

Beberapa komponen untuk konektivitas campuran dari lingkungan lokal Anda ke Google Cloud otomatis diaktifkan oleh blueprint, termasuk hal berikut:

• Cloud DNS dikonfigurasi dengan penerusan DNS di antara semua jaringan VPC Bersama ke satu hub, seperti yang dijelaskan dalam Penyiapan DNS. Kebijakan server Cloud DNS dikonfigurasi dengan alamat IP penerusan masuk.
• Cloud Router dikonfigurasi untuk mengekspor rute untuk semua subnet dan rute kustom untuk alamat IP yang digunakan oleh endpoint Private Service Connect.

Untuk mengaktifkan konektivitas hybrid, Anda harus melakukan langkah-langkah tambahan berikut:

1. Pesan koneksi Dedicated Interconnect.
2. Konfigurasikan router dan firewall lokal untuk mengizinkan traffic keluar ke ruang alamat IP internal yang ditentukan dalam alokasi ruang alamat IP.
3. Konfigurasikan server DNS lokal Anda untuk meneruskan pencarian DNS yang terikat untuk Google Cloud ke alamat IP forwarder masuk yang sudah dikonfigurasi oleh blueprint.
4. Konfigurasikan server DNS, firewall, dan router lokal untuk menerima kueri DNS dari zona penerusan Cloud DNS (35.199.192.0/19).
5. Konfigurasikan server DNS lokal untuk merespons kueri dari host lokal ke layanan Google Cloud dengan alamat IP yang ditentukan dalam akses pribadi ke Cloud API.
6. Untuk enkripsi dalam pengiriman melalui koneksi Dedicated Interconnect, konfigurasikan MACsec untuk Cloud Interconnect atau konfigurasikan VPN dengan ketersediaan tinggi (HA) melalui Cloud Interconnect untuk enkripsi IPsec.

Untuk informasi selengkapnya, lihat Akses Google Pribadi untuk host lokal.

Langkah berikutnya

• Baca kontrol detektif (dokumen berikutnya dalam rangkaian ini).

Kontrol Detektif

Kemampuan pemantauan dan deteksi ancaman disediakan menggunakan kombinasi kontrol keamanan bawaan dari Security Command Center dan solusi kustom yang memungkinkan Anda mendeteksi dan merespons peristiwa keamanan.

Logging terpusat untuk keamanan dan audit

Blueprint mengonfigurasi kemampuan logging untuk melacak dan menganalisis perubahan pada resource Google Cloud Anda dengan log yang digabungkan ke satu project.

Diagram berikut menunjukkan cara blueprint menggabungkan log dari beberapa sumber di beberapa project ke dalam sink log terpusat.

Diagram ini menjelaskan hal berikut:

• Sink log dikonfigurasi di node organisasi untuk menggabungkan log dari semua project dalam hierarki resource.
• Beberapa sink log dikonfigurasi untuk mengirim log yang cocok dengan filter ke berbagai tujuan untuk penyimpanan dan analisis.
• Project prj-c-logging berisi semua resource untuk penyimpanan dan analitik log.
• Jika ingin, Anda dapat mengonfigurasi alat tambahan untuk mengekspor log ke SIEM.

Blueprint menggunakan sumber log yang berbeda dan menyertakan log ini dalam filter sink log sehingga log dapat diekspor ke tujuan terpusat. Tabel berikut menjelaskan sumber log.

Sumber log	Deskripsi
Log audit Aktivitas Admin	Anda tidak dapat mengonfigurasi, menonaktifkan, atau mengecualikan log audit Aktivitas Admin.
Log audit Peristiwa Sistem	Anda tidak dapat mengonfigurasi, menonaktifkan, atau mengecualikan log audit Peristiwa Sistem.
Log audit Kebijakan Ditolak	Anda tidak dapat mengonfigurasi atau menonaktifkan log audit Kebijakan Ditolak, tetapi Anda dapat mengecualikannya secara opsional dengan filter pengecualian.
Log audit Akses Data	Secara default, blueprint tidak mengaktifkan log akses data karena volume dan biaya log ini dapat menjadi tinggi. Untuk menentukan apakah Anda harus mengaktifkan log akses data, evaluasi tempat beban kerja Anda menangani data sensitif dan pertimbangkan apakah Anda memiliki persyaratan untuk mengaktifkan log akses data untuk setiap layanan dan lingkungan yang menangani data sensitif.
VPC Flow Logs	Blueprint ini mengaktifkan VPC Flow Logs untuk setiap subnet. Blueprint ini mengonfigurasi pengambilan sampel log untuk mengambil sampel 50% log guna mengurangi biaya. Jika membuat subnet tambahan, Anda harus memastikan bahwa Log Aliran VPC diaktifkan untuk setiap subnet.
Firewall Rules Logging	Blueprint ini mengaktifkan Firewall Rules Logging untuk setiap aturan kebijakan firewall. Jika membuat aturan kebijakan firewall tambahan untuk workload, Anda harus memastikan bahwa Firewall Rules Logging diaktifkan untuk setiap aturan baru.
Pembuatan log Cloud DNS	Blueprint ini mengaktifkan log Cloud DNS untuk zona terkelola. Jika membuat zona terkelola tambahan, Anda harus mengaktifkan log DNS tersebut.
Logging audit Google Workspace	Memerlukan langkah pengaktifan satu kali yang tidak diotomatiskan oleh blueprint. Untuk mengetahui informasi selengkapnya, lihat Berbagi data dengan layananGoogle Cloud .
Log Transparansi Akses	Memerlukan langkah pengaktifan satu kali yang tidak diotomatiskan oleh blueprint. Untuk informasi selengkapnya, lihat Mengaktifkan Transparansi Akses.

Tabel berikut menjelaskan sink log dan cara penggunaannya dengan tujuan yang didukung dalam blueprint.

Sink	Tujuan	Tujuan
sk-c-logging-la	Log yang dirutekan ke bucket Cloud Logging dengan Log Analytics dan set data BigQuery tertaut diaktifkan	Menganalisis log secara aktif. Jalankan investigasi ad hoc menggunakan Logs Explorer di konsol, atau tulis kueri, laporan, dan tampilan SQL menggunakan set data BigQuery tertaut.
sk-c-logging-bkt	Log yang dirutekan ke Cloud Storage	Menyimpan log dalam jangka panjang untuk tujuan kepatuhan, audit, dan pelacakan insiden. Secara opsional, jika Anda memiliki persyaratan kepatuhan untuk retensi data wajib, sebaiknya konfigurasikan Bucket Lock.
sk-c-logging-pub	Log yang dirutekan ke Pub/Sub	Mengekspor log ke platform eksternal seperti SIEM yang ada. Hal ini memerlukan pekerjaan tambahan untuk berintegrasi dengan SIEM Anda, seperti mekanisme berikut: Untuk banyak alat, integrasi pihak ketiga dengan Pub/Sub adalah metode yang lebih disukai untuk menyerap log. Untuk Google Security Operations, Anda dapat menyerap Google Cloud data ke Google Security Operations tanpa menyediakan infrastruktur tambahan. Untuk Splunk, Anda dapat men-streaming log dari Google Cloud ke Splunk menggunakan Dataflow.

Untuk panduan mengaktifkan jenis log tambahan dan menulis filter sink log, lihat alat cakupan log.

Pemantauan ancaman dengan Security Command Center

Sebaiknya aktifkan Security Command Center Premium untuk organisasi Anda guna mendeteksi ancaman, kerentanan, dan kesalahan konfigurasi secara otomatis di Google Cloud resource Anda. Security Command Center membuat temuan keamanan dari beberapa sumber, termasuk yang berikut:

• Security Health Analytics: mendeteksi kerentanan dan kesalahan konfigurasi umum di seluruh resource Google Cloud.
• Eksposur jalur serangan: menampilkan simulasi jalur tentang cara penyerang dapat mengeksploitasi resource bernilai tinggi Anda, berdasarkan kerentanan dan kesalahan konfigurasi yang terdeteksi oleh sumber Security Command Center lainnya.
• Event Threat Detection: menerapkan logika deteksi dan kecerdasan ancaman eksklusif terhadap log Anda untuk mengidentifikasi ancaman hampir secara real time.
• Container Threat Detection: mendeteksi serangan runtime container yang umum.
• Virtual Machine Threat Detection: mendeteksi aplikasi yang berpotensi berbahaya yang berjalan di virtual machine.
• Web Security Scanner: memindai kerentanan OWASP Top Ten di aplikasi yang ditampilkan di web di Compute Engine, App Engine, atau Google Kubernetes Engine.

Untuk informasi selengkapnya tentang kerentanan dan ancaman yang ditangani oleh Security Command Center, lihat Sumber Security Command Center.

Anda harus mengaktifkan Security Command Center setelah men-deploy blueprint. Untuk mendapatkan petunjuk, lihat Mengaktifkan Security Command Center untuk organisasi.

Setelah mengaktifkan Security Command Center, sebaiknya ekspor temuan yang dihasilkan oleh Security Command Center ke alat atau proses yang ada untuk menentukan prioritas dan merespons ancaman. Blueprint membuat project prj-c-scc dengan topik Pub/Sub yang akan digunakan untuk integrasi ini. Bergantung pada alat yang ada, gunakan salah satu metode berikut untuk mengekspor temuan:

• Jika Anda menggunakan konsol untuk mengelola temuan keamanan langsung di Security Command Center, konfigurasikan peran level folder dan level project untuk Security Command Center agar tim dapat melihat dan mengelola temuan keamanan hanya untuk project yang menjadi tanggung jawab mereka.

• Jika Anda menggunakan Google SecOps sebagai SIEM, transfer Google Cloud data ke Google SecOps.

• Jika Anda menggunakan alat SIEM atau SOAR dengan integrasi ke Security Command Center, bagikan data dengan Cortex XSOAR, Elastic Stack, ServiceNow, Splunk, atau QRadar.

• Jika Anda menggunakan alat eksternal yang dapat menyerap temuan dari Pub/Sub, konfigurasikan ekspor berkelanjutan ke Pub/Sub dan konfigurasikan alat yang ada untuk menyerap temuan dari topik Pub/Sub.

Solusi kustom untuk analisis log otomatis

Anda mungkin memiliki persyaratan untuk membuat pemberitahuan peristiwa keamanan yang didasarkan pada kueri kustom terhadap log. Kueri kustom dapat membantu melengkapi kemampuan SIEM dengan menganalisis log di Google Cloud dan hanya mengekspor peristiwa yang layak diselidiki, terutama jika Anda tidak memiliki kapasitas untuk mengekspor semua log cloud ke SIEM.

Blueprint ini membantu mengaktifkan analisis log ini dengan menyiapkan sumber log terpusat yang dapat Anda buat kueri menggunakan set data BigQuery tertaut. Untuk mengotomatiskan kemampuan ini, Anda harus menerapkan contoh kode di bq-log-alerting dan memperluas kemampuan fondasi. Kode contoh memungkinkan Anda membuat kueri secara rutin pada sumber log dan mengirim temuan kustom ke Security Command Center.

Diagram berikut memperkenalkan alur tingkat tinggi analisis log otomatis.

Diagram ini menunjukkan konsep analisis log otomatis berikut:

• Log dari berbagai sumber digabungkan ke dalam bucket log terpusat dengan analisis log dan set data BigQuery tertaut.
• Tampilan BigQuery dikonfigurasi untuk mengkueri log peristiwa keamanan yang ingin Anda pantau.
• Cloud Scheduler mengirim peristiwa ke topik Pub/Sub setiap 15 menit dan memicu fungsi Cloud Run.
• Fungsi Cloud Run membuat kueri tampilan untuk peristiwa baru. Jika menemukan peristiwa, Cloud Function akan mendorongnya ke Security Command Center sebagai temuan kustom.
• Security Command Center memublikasikan notifikasi tentang temuan baru ke topik Pub/Sub lain.
• Alat eksternal seperti SIEM berlangganan topik Pub/Sub untuk menyerap temuan baru.

Sampel ini memiliki beberapa kasus penggunaan untuk membuat kueri perilaku yang berpotensi mencurigakan. Contohnya mencakup login dari daftar admin super atau akun dengan hak istimewa tinggi lainnya yang Anda tentukan, perubahan pada setelan logging, atau perubahan pada rute jaringan. Anda dapat memperluas kasus penggunaan dengan menulis tampilan kueri baru untuk persyaratan Anda. Tulis kueri Anda sendiri atau lihat analisis log keamanan untuk library kueri SQL guna membantu Anda menganalisis log Google Cloud .

Solusi kustom untuk merespons perubahan aset

Untuk merespons peristiwa secara real time, sebaiknya gunakan Inventaris Aset Cloud untuk memantau perubahan aset. Dalam solusi kustom ini, feed aset dikonfigurasi untuk memicu notifikasi ke Pub/Sub tentang perubahan pada resource secara real time, lalu fungsi Cloud Run menjalankan kode kustom untuk menerapkan logika bisnis Anda sendiri berdasarkan apakah perubahan tersebut harus diizinkan.

Blueprint ini memiliki contoh solusi tata kelola kustom yang memantau perubahan IAM yang menambahkan peran yang sangat sensitif, termasuk Admin Organisasi, Pemilik, dan Editor. Diagram berikut menjelaskan solusi ini.

Diagram sebelumnya menunjukkan konsep berikut:

• Perubahan dilakukan pada kebijakan izin.
• Feed Inventaris Aset Cloud mengirimkan notifikasi real-time tentang perubahan kebijakan izin ke Pub/Sub.
• Pub/Sub memicu fungsi.
• Fungsi Cloud Run menjalankan kode kustom untuk menerapkan kebijakan Anda. Contoh fungsi ini memiliki logika untuk menilai apakah perubahan telah menambahkan peran Admin, Pemilik, atau Editor Organisasi ke kebijakan izin. Jika demikian, fungsi akan membuat temuan keamanan kustom dan mengirimkannya ke Security Command Center.
• Secara opsional, Anda dapat menggunakan model ini untuk mengotomatiskan upaya perbaikan. Tulis logika bisnis tambahan di fungsi Cloud Run untuk otomatis mengambil tindakan atas temuan tersebut, seperti mengembalikan kebijakan izin ke statusnya sebelumnya.

Selain itu, Anda dapat memperluas infrastruktur dan logika yang digunakan oleh solusi contoh ini untuk menambahkan respons kustom ke peristiwa lain yang penting bagi bisnis Anda.

Langkah berikutnya

• Baca artikel tentang kontrol pencegahan (dokumen berikutnya dalam rangkaian ini).

Kontrol pencegahan untuk konfigurasi resource yang dapat diterima

Sebaiknya tentukan batasan kebijakan yang menerapkan konfigurasi resource yang dapat diterima dan mencegah konfigurasi berisiko. Blueprint ini menggunakan kombinasi batasan kebijakan organisasi dan validasi infrastruktur sebagai kode (IaC) di pipeline Anda. Kontrol ini mencegah pembuatan resource yang tidak memenuhi pedoman kebijakan Anda. Menerapkan kontrol ini sejak awal dalam desain dan build workload membantu Anda menghindari pekerjaan perbaikan di lain waktu.

Batasan kebijakan organisasi

Layanan Kebijakan Organisasi menerapkan batasan untuk memastikan bahwa konfigurasi resource tertentu tidak dapat dibuat di organisasi Google Cloud Anda, bahkan oleh seseorang dengan peran IAM yang cukup istimewa.

Blueprint menerapkan kebijakan di node organisasi sehingga kontrol ini diwarisi oleh semua folder dan project dalam organisasi. Kumpulan kebijakan ini dirancang untuk mencegah konfigurasi berisiko tinggi tertentu, seperti mengekspos VM ke internet publik atau memberikan akses publik ke bucket penyimpanan, kecuali jika Anda sengaja mengizinkan pengecualian terhadap kebijakan.

Tabel berikut memperkenalkan batasan kebijakan organisasi yang diterapkan dalam blueprint:

Batasan kebijakan organisasi	Deskripsi
compute.disableNestedVirtualization	Virtualisasi bertingkat di VM Compute Engine dapat menghindari pemantauan dan alat keamanan lainnya untuk VM Anda jika dikonfigurasi dengan buruk. Batasan ini mencegah pembuatan virtualisasi bertingkat.
compute.disableSerialPortAccess	Peran IAM seperti compute.instanceAdmin memungkinkan akses dengan hak istimewa ke port serial instance menggunakan kunci SSH. Jika kunci SSH terekspos, penyerang dapat mengakses port serial dan mengabaikan kontrol jaringan dan firewall. Batasan ini mencegah akses port serial.
compute.disableVpcExternalIpv6	Subnet IPv6 eksternal dapat terekspos ke akses internet yang tidak sah jika dikonfigurasi dengan buruk. Batasan ini mencegah pembuatan subnet IPv6 eksternal.
compute.requireOsLogin	Perilaku default penetapan kunci SSH dalam metadata dapat mengizinkan akses jarak jauh yang tidak sah ke VM jika kunci terekspos. Batasan ini mewajibkan penggunaan Login OS, bukan kunci SSH berbasis metadata.
compute.restrictProtocolForwardingCreationForTypes	Penerusan protokol VM untuk alamat IP eksternal dapat menyebabkan traffic keluar internet yang tidak sah jika penerusan dikonfigurasi dengan buruk. Batasan ini memungkinkan penerusan protokol VM hanya untuk alamat internal.
compute.restrictXpnProjectLienRemoval	Menghapus project host VPC Bersama dapat mengganggu semua project layanan yang menggunakan resource jaringan. Batasan ini mencegah penghapusan project host VPC Bersama secara tidak sengaja atau berbahaya dengan mencegah penghapusan lien project pada project ini.
compute.setNewProjectDefaultToZonalDNSOnly	Setelan lama untuk DNS internal global (seluruh project) tidak direkomendasikan karena mengurangi ketersediaan layanan. Batasan ini mencegah penggunaan setelan lama.
compute.skipDefaultNetworkCreation	Jaringan VPC default dan aturan firewall VPC default yang terlalu permisif dibuat di setiap project baru yang mengaktifkan Compute Engine API. Batasan ini akan melewati pembuatan jaringan default dan aturan firewall VPC default.
compute.vmExternalIpAccess	Secara default, VM dibuat dengan alamat IPv4 eksternal yang dapat menyebabkan akses internet tidak sah. Batasan ini mengonfigurasi daftar yang diizinkan kosong untuk alamat IP eksternal yang dapat digunakan VM dan menolak semua alamat IP lainnya.
essentialcontacts.allowedContactDomains	Secara default, Kontak Penting dapat dikonfigurasi untuk mengirim notifikasi tentang domain Anda ke domain lain. Batasan ini mewajibkan bahwa hanya alamat email di domain yang disetujui yang dapat ditetapkan sebagai penerima untuk Kontak Penting.
iam.allowedPolicyMemberDomains	Secara default, kebijakan izin dapat diberikan ke Akun Google apa pun, termasuk akun yang tidak dikelola, dan akun milik organisasi eksternal. Batasan ini memastikan bahwa kebijakan izin di organisasi Anda hanya dapat diberikan ke akun terkelola dari domain Anda sendiri. Secara opsional, Anda dapat mengizinkan domain tambahan.
iam.automaticIamGrantsForDefaultServiceAccounts	Secara default, akun layanan default secara otomatis diberi peran yang terlalu permisif. Batasan ini mencegah pemberian peran IAM otomatis ke akun layanan default.
iam.disableServiceAccountKeyCreation	Kunci akun layanan adalah kredensial persisten berisiko tinggi, dan dalam sebagian besar kasus, alternatif yang lebih aman untuk kunci akun layanan dapat digunakan. Batasan ini mencegah pembuatan kunci akun layanan.
iam.disableServiceAccountKeyUpload	Mengupload materi kunci akun layanan dapat meningkatkan risiko jika materi kunci terekspos. Batasan ini mencegah upload kunci akun layanan.
sql.restrictAuthorizedNetworks	Instance Cloud SQL dapat terekspos ke akses internet yang tidak diautentikasi jika instance dikonfigurasi untuk menggunakan jaringan resmi tanpa Proxy Auth Cloud SQL. Kebijakan ini mencegah konfigurasi jaringan yang diotorisasi untuk akses database dan memaksa penggunaan Proxy Auth Cloud SQL.
sql.restrictPublicIp	Instance Cloud SQL dapat terekspos ke akses internet yang tidak diautentikasi jika instance dibuat dengan alamat IP publik. Batasan ini mencegah alamat IP publik di instance Cloud SQL.
storage.uniformBucketLevelAccess	Secara default, objek di Cloud Storage dapat diakses melalui Daftar Kontrol Akses (ACL) lama, bukan IAM, yang dapat menyebabkan kontrol akses tidak konsisten dan eksposur yang tidak disengaja jika salah dikonfigurasi. Akses ACL lama tidak terpengaruh oleh batasan iam.allowedPolicyMemberDomains. Batasan ini menerapkan bahwa akses hanya dapat dikonfigurasi melalui akses level bucket seragam IAM, bukan ACL lama.
storage.publicAccessPrevention	Bucket Cloud Storage dapat terekspos ke akses internet yang tidak diautentikasi jika salah dikonfigurasi. Batasan ini mencegah ACL dan izin IAM yang memberikan akses ke allUsers dan allAuthenticatedUsers.

Kebijakan ini adalah titik awal yang kami rekomendasikan untuk sebagian besar pelanggan dan sebagian besar skenario, tetapi Anda mungkin perlu mengubah batasan kebijakan organisasi untuk menampung jenis beban kerja tertentu. Misalnya, beban kerja yang menggunakan bucket Cloud Storage sebagai backend untuk Cloud CDN guna menghosting resource publik diblokir oleh storage.publicAccessPrevention, atau aplikasi Cloud Run yang ditampilkan ke publik dan tidak memerlukan autentikasi diblokir oleh iam.allowedPolicyMemberDomains. Dalam kasus ini, ubah kebijakan organisasi di level folder atau project untuk mengizinkan pengecualian yang sempit. Anda juga dapat menambahkan batasan secara bersyarat ke kebijakan organisasi dengan menentukan tag yang memberikan pengecualian atau penerapan untuk kebijakan, lalu menerapkan tag tersebut ke project dan folder.

Untuk batasan tambahan, lihat batasan yang tersedia dan batasan kustom.

Validasi pra-deployment infrastruktur sebagai kode

Blueprint ini menggunakan pendekatan GitOps untuk mengelola infrastruktur, yang berarti bahwa semua perubahan infrastruktur diterapkan melalui infrastruktur sebagai kode (IaC) yang dikontrol versi dan dapat divalidasi sebelum di-deploy.

Kebijakan yang diterapkan dalam blueprint menentukan konfigurasi resource yang dapat diterima dan dapat di-deploy oleh pipeline Anda. Jika kode yang dikirim ke repositori GitHub Anda tidak lulus pemeriksaan kebijakan, tidak ada resource yang di-deploy.

Untuk informasi tentang cara penggunaan pipeline dan cara kontrol diterapkan melalui otomatisasi CI/CD, lihat metodologi deployment.

Langkah berikutnya

• Baca tentang metodologi deployment (dokumen berikutnya dalam rangkaian ini)

Metodologi penerapan

Sebaiknya gunakan infrastruktur deklaratif untuk men-deploy fondasi Anda dengan cara yang konsisten dan dapat dikontrol. Pendekatan ini membantu mengaktifkan tata kelola yang konsisten dengan menerapkan kontrol kebijakan tentang konfigurasi resource yang dapat diterima ke dalam pipeline Anda. Blueprint di-deploy menggunakan alur GitOps, dengan Terraform digunakan untuk menentukan infrastruktur sebagai kode (IaC), repositori Git untuk kontrol versi dan persetujuan kode, serta Cloud Build untuk otomatisasi CI/CD di pipeline deployment. Untuk pengantar konsep ini, lihat mengelola infrastruktur sebagai kode dengan Terraform, Cloud Build, dan GitOps.

Bagian berikut menjelaskan cara pipeline deployment digunakan untuk mengelola resource di organisasi Anda.

Lapisan pipeline

Untuk memisahkan tim dan stack teknologi yang bertanggung jawab untuk mengelola berbagai lapisan lingkungan Anda, sebaiknya gunakan model yang menggunakan pipeline dan persona yang berbeda, yang bertanggung jawab untuk setiap lapisan stack.

Diagram berikut memperkenalkan model yang kami rekomendasikan untuk memisahkan pipeline fondasi, pipeline infrastruktur, dan pipeline aplikasi.

Diagram ini memperkenalkan lapisan pipeline dalam model ini:

• Pipeline foundation men-deploy resource foundation yang digunakan di seluruh platform. Sebaiknya satu tim pusat bertanggung jawab untuk mengelola resource fondasi yang digunakan oleh beberapa unit bisnis dan beban kerja.
• Pipeline infrastruktur men-deploy project dan infrastruktur yang digunakan oleh workload, seperti instance VM atau database. Blueprint menyiapkan pipeline infrastruktur terpisah untuk setiap unit bisnis, atau Anda mungkin lebih memilih satu pipeline infrastruktur yang digunakan oleh beberapa tim.
• Pipeline aplikasi men-deploy artefak untuk setiap beban kerja, seperti container atau image. Anda mungkin memiliki banyak tim aplikasi yang berbeda dengan pipeline aplikasi individual.

Bagian berikut memperkenalkan penggunaan setiap lapisan pipeline.

Pipeline fondasi

Pipeline fondasi men-deploy resource fondasi. Alat ini juga menyiapkan pipeline infrastruktur yang digunakan untuk men-deploy infrastruktur yang digunakan oleh beban kerja.

Untuk membuat pipeline dasar, Anda harus meng-clone atau melakukan fork terraform-example-foundation ke repositori Git Anda sendiri terlebih dahulu. Ikuti langkah-langkah dalam file README 0-bootstrap untuk mengonfigurasi folder dan resource bootstrap Anda.

Tahap

Deskripsi

0-bootstrap

Melakukan bootstrap organisasi Google Cloud . Langkah ini juga mengonfigurasi pipeline CI/CD untuk kode blueprint di tahap berikutnya. Project CICD berisi pipeline fondasi Cloud Build untuk men-deploy resource. Project seed mencakup bucket Cloud Storage yang berisi status Terraform dari infrastruktur dasar dan mencakup akun layanan dengan hak istimewa tinggi yang digunakan oleh pipeline dasar untuk membuat resource. Status Terraform dilindungi melalui penyimpanan Pembuatan Versi Objek. Saat berjalan, pipeline CI/CD akan bertindak sebagai akun layanan yang dikelola di project seed.

Setelah Anda membuat pipeline fondasi di tahap 0-bootstrap, tahap berikut akan men-deploy resource di pipeline fondasi. Tinjau petunjuk README untuk setiap tahap dan terapkan setiap tahap secara berurutan.

Tahap	Deskripsi
1-org	Menyiapkan folder bersama tingkat teratas, project untuk layanan bersama, logging tingkat organisasi, dan setelan keamanan dasar melalui kebijakan organisasi.
2-environments	Menyiapkan lingkungan pengembangan, non-produksi, dan produksi dalam Google Cloud organisasi yang telah Anda buat.
3-networks-dual-svpc atau 3-networks-hub-and-spoke	Menyiapkan VPC bersama dalam topologi yang Anda pilih dan resource jaringan terkait.

Pipeline infrastruktur

Pipeline infrastruktur men-deploy project dan infrastruktur (misalnya, instance VM dan database) yang digunakan oleh workload. Pipeline foundation men-deploy beberapa pipeline infrastruktur. Pemisahan antara pipeline fondasi dan pipeline infrastruktur ini memungkinkan pemisahan antara resource seluruh platform dan resource khusus beban kerja.

Diagram berikut menjelaskan cara blueprint mengonfigurasi beberapa pipeline infrastruktur yang ditujukan untuk digunakan oleh tim terpisah.

Diagram ini menjelaskan konsep utama berikut:

• Setiap pipeline infrastruktur digunakan untuk mengelola resource infrastruktur secara terpisah dari resource fondasi.
• Setiap unit bisnis memiliki pipeline infrastrukturnya sendiri, yang dikelola dalam project khusus di folder common.
• Setiap pipeline infrastruktur memiliki akun layanan dengan izin untuk men-deploy resource hanya ke project yang terkait dengan unit bisnis tersebut. Strategi ini menciptakan pemisahan tugas antara akun layanan dengan hak istimewa yang digunakan untuk pipeline fondasi dan yang digunakan oleh setiap pipeline infrastruktur

Pendekatan ini dengan beberapa pipeline infrastruktur direkomendasikan jika Anda memiliki beberapa entitas di dalam organisasi yang memiliki keterampilan dan keinginan untuk mengelola infrastrukturnya secara terpisah, terutama jika mereka memiliki persyaratan yang berbeda seperti jenis kebijakan validasi pipeline yang ingin mereka terapkan. Atau, Anda mungkin lebih memilih untuk memiliki satu pipeline infrastruktur yang dikelola oleh satu tim dengan kebijakan validasi yang konsisten.

Di terraform-example-foundation, tahap 4 mengonfigurasi pipeline infrastruktur, dan tahap 5 menunjukkan contoh penggunaan pipeline tersebut untuk men-deploy resource infrastruktur.

Tahap	Deskripsi
4-projects	Menyiapkan struktur folder, project, dan pipeline infrastruktur.
5-app-infra (opsional)	Men-deploy project workload dengan instance Compute Engine menggunakan pipeline infrastruktur sebagai contoh.

Pipeline aplikasi

Pipeline aplikasi bertanggung jawab untuk men-deploy artefak aplikasi untuk setiap beban kerja, seperti image atau penampung Kubernetes yang menjalankan logika bisnis aplikasi Anda. Artefak ini di-deploy ke resource infrastruktur yang di-deploy oleh pipeline infrastruktur Anda.

Blueprint dasar-dasar perusahaan menyiapkan pipeline fondasi dan pipeline infrastruktur, tetapi tidak men-deploy pipeline aplikasi. Untuk contoh pipeline aplikasi, lihat blueprint aplikasi perusahaan.

Mengotomatiskan pipeline dengan Cloud Build

Blueprint menggunakan Cloud Build untuk mengotomatiskan proses CI/CD. Tabel berikut menjelaskan kontrol yang di-build ke dalam pipeline fondasi dan pipeline infrastruktur yang di-deploy oleh repositori terraform-example-foundation. Jika Anda mengembangkan pipeline Anda sendiri menggunakan alat otomatisasi CI/CD lainnya, sebaiknya terapkan kontrol serupa.

Kontrol	Deskripsi
Memisahkan konfigurasi build untuk memvalidasi kode sebelum men-deploy	Blueprint menggunakan dua file konfigurasi build Cloud Build untuk seluruh pipeline, dan setiap repositori yang terkait dengan tahap memiliki dua pemicu Cloud Build yang terkait dengan file konfigurasi build tersebut. Saat kode di-push ke cabang repositori, file konfigurasi build dipicu untuk terlebih dahulu menjalankan cloudbuild-tf-plan.yaml yang memvalidasi kode Anda dengan pemeriksaan kebijakan dan rencana Terraform terhadap cabang tersebut, lalu cloudbuild-tf-apply.yaml menjalankan terraform apply pada hasil rencana tersebut.
Pemeriksaan kebijakan Terraform	Blueprint ini mencakup serangkaian batasan Open Policy Agent yang diterapkan oleh validasi kebijakan di Google Cloud CLI. Batasan ini menentukan konfigurasi resource yang dapat diterima yang dapat di-deploy oleh pipeline Anda. Jika build tidak memenuhi kebijakan dalam konfigurasi build pertama, konfigurasi build kedua tidak akan men-deploy resource apa pun. Kebijakan yang diterapkan dalam blueprint di-fork dari GoogleCloudPlatform/policy-library di GitHub. Anda dapat menulis kebijakan tambahan untuk library guna menerapkan kebijakan kustom untuk memenuhi persyaratan Anda.
Prinsip hak istimewa terendah	Pipeline fondasi memiliki akun layanan yang berbeda untuk setiap tahap dengan kebijakan izin yang hanya memberikan peran IAM minimum untuk tahap tersebut. Setiap pemicu Cloud Build berjalan sebagai akun layanan tertentu untuk tahap tersebut. Menggunakan akun yang berbeda membantu mengurangi risiko bahwa mengubah satu repositori dapat memengaruhi resource yang dikelola oleh repositori lain. Untuk memahami peran IAM tertentu yang diterapkan ke setiap akun layanan, lihat kode Terraform sa.tf di tahap bootstrap.
Kumpulan pribadi Cloud Build	Blueprint menggunakan kumpulan pribadi Cloud Build. Dengan pool pribadi, Anda dapat menerapkan kontrol tambahan secara opsional, seperti membatasi akses ke repositori publik atau menjalankan Cloud Build di dalam perimeter Kontrol Layanan VPC.
Builder kustom Cloud Build	Blueprint membuat builder kustom-nya sendiri untuk menjalankan Terraform. Untuk informasi selengkapnya, lihat 0-bootstrap/Dockerfile. Kontrol ini memastikan bahwa pipeline berjalan secara konsisten dengan kumpulan library yang diketahui pada versi yang disematkan.
Persetujuan deployment	Secara opsional, Anda dapat menambahkan tahap persetujuan manual ke Cloud Build. Persetujuan ini menambahkan titik pemeriksaan tambahan setelah build dipicu, tetapi sebelum dijalankan sehingga pengguna dengan hak istimewa dapat menyetujui build secara manual.

Strategi cabang

Sebaiknya gunakan strategi cabang persisten untuk mengirimkan kode ke sistem Git Anda dan men-deploy resource melalui pipeline foundation. Diagram berikut menjelaskan strategi cabang persisten.

Diagram ini menjelaskan tiga cabang persisten di Git (pengembangan, non-produksi, dan produksi) yang mencerminkan lingkungan Google Cloud yang sesuai. Ada juga beberapa cabang fitur sementara yang tidak sesuai dengan resource yang di-deploy di lingkunganGoogle Cloud Anda.

Sebaiknya terapkan proses permintaan pull (PR) ke sistem Git Anda sehingga kode apa pun yang digabungkan ke cabang persisten memiliki PR yang disetujui.

Untuk mengembangkan kode dengan strategi cabang persisten ini, ikuti langkah-langkah tingkat tinggi berikut:

1. Saat Anda mengembangkan kemampuan baru atau mengerjakan perbaikan bug, buat cabang baru berdasarkan cabang pengembangan. Gunakan konvensi penamaan untuk cabang Anda yang menyertakan jenis perubahan, nomor tiket, atau ID lainnya, dan deskripsi yang dapat dibaca manusia, seperti feature/123456-org-policies.
2. Setelah menyelesaikan pekerjaan di cabang fitur, buka PR yang menargetkan cabang pengembangan.
3. Saat Anda mengirimkan PR, PR akan memicu pipeline fondasi untuk menjalankan terraform plan dan terraform validate guna melakukan staging dan memverifikasi perubahan.
4. Setelah Anda memvalidasi perubahan pada kode, gabungkan fitur atau perbaikan bug ke dalam cabang pengembangan.
5. Proses penggabungan memicu pipeline fondasi untuk menjalankan terraform apply guna men-deploy perubahan terbaru di cabang pengembangan ke lingkungan pengembangan.
6. Tinjau perubahan di lingkungan pengembangan menggunakan peninjauan manual, pengujian fungsional, atau pengujian menyeluruh yang relevan dengan kasus penggunaan Anda. Kemudian, promosikan perubahan ke lingkungan non-produksi dengan membuka PR yang menargetkan cabang non-produksi dan menggabungkan perubahan Anda.
7. Untuk men-deploy resource ke lingkungan produksi, ulangi proses yang sama seperti langkah 6: tinjau dan validasi resource yang di-deploy, buka PR ke cabang produksi, lalu gabungkan.

Langkah berikutnya

• Baca praktik terbaik operasi (dokumen berikutnya dalam rangkaian ini).

Praktik terbaik operasi

Bagian ini memperkenalkan operasi yang harus Anda pertimbangkan saat men-deploy dan mengoperasikan beban kerja tambahan ke lingkungan Google Cloud . Bagian ini tidak dimaksudkan untuk mencakup semua operasi di lingkungan cloud Anda, tetapi memperkenalkan keputusan yang terkait dengan rekomendasi arsitektur dan resource yang di-deploy oleh blueprint.

Memperbarui resource foundation

Meskipun blueprint memberikan titik awal yang bersifat subjektif untuk lingkungan fondasi, persyaratan fondasi Anda mungkin bertambah seiring waktu. Setelah deployment awal, Anda dapat menyesuaikan setelan konfigurasi atau mem-build layanan bersama baru untuk digunakan oleh semua workload.

Untuk mengubah resource fondasi, sebaiknya Anda melakukan semua perubahan melalui pipeline fondasi. Tinjau strategi percabangan untuk mengetahui pengantar alur penulisan kode, menggabungkannya, dan memicu pipeline deployment.

Menentukan atribut untuk project workload baru

Saat membuat project baru melalui modul factory project dari pipeline otomatisasi, Anda harus mengonfigurasi berbagai atribut. Proses Anda untuk mendesain dan membuat project untuk workload baru harus mencakup keputusan untuk hal berikut:

• Google Cloud API yang akan diaktifkan
• VPC Bersama mana yang akan digunakan, atau apakah akan membuat jaringan VPC baru
• Peran IAM yang akan dibuat untuk project-service-account awal yang dibuat oleh pipeline
• Label project yang akan diterapkan
• Folder tempat project di-deploy
• Akun penagihan yang akan digunakan
• Apakah akan menambahkan project ke perimeter Kontrol Layanan VPC
• Apakah akan mengonfigurasi anggaran dan nilai minimum pemberitahuan penagihan untuk project

Untuk referensi lengkap atribut yang dapat dikonfigurasi untuk setiap project, lihat variabel input untuk factory project di pipeline otomatisasi.

Mengelola izin dalam skala besar

Saat men-deploy project workload di atas fondasi, Anda harus mempertimbangkan cara memberikan akses kepada developer dan konsumen yang dimaksud untuk project tersebut. Sebaiknya tambahkan pengguna ke grup yang dikelola oleh penyedia identitas yang ada, sinkronkan grup dengan Cloud Identity, lalu terapkan peran IAM ke grup. Selalu ingat prinsip hak istimewa terendah.

Sebaiknya gunakan juga rekomendasi IAM untuk mengidentifikasi kebijakan izin yang memberikan peran yang terlalu banyak hak istimewa. Buat desain proses untuk meninjau rekomendasi secara berkala atau menerapkan rekomendasi secara otomatis ke dalam pipeline deployment Anda.

Mengkoordinasikan perubahan antara tim jaringan dan tim aplikasi

Topologi jaringan yang di-deploy oleh blueprint mengasumsikan bahwa Anda memiliki tim yang bertanggung jawab untuk mengelola resource jaringan, dan tim terpisah yang bertanggung jawab untuk men-deploy resource infrastruktur workload. Saat tim beban kerja men-deploy infrastruktur, mereka harus membuat aturan firewall untuk mengizinkan jalur akses yang diinginkan di antara komponen beban kerja mereka, tetapi mereka tidak memiliki izin untuk mengubah kebijakan firewall jaringan itu sendiri.

Rencanakan cara tim akan bekerja sama untuk mengoordinasikan perubahan pada resource jaringan terpusat yang diperlukan untuk men-deploy aplikasi. Misalnya, Anda dapat mendesain proses saat tim beban kerja meminta tag untuk aplikasi mereka. Tim jaringan kemudian membuat tag dan menambahkan aturan ke kebijakan firewall jaringan yang memungkinkan traffic mengalir di antara resource dengan tag, dan mendelegasikan peran IAM untuk menggunakan tag ke tim beban kerja.

Optimalkan lingkungan Anda dengan portofolio Active Assist

Selain pemberi rekomendasi IAM, Google Cloud menyediakan portofolio layanan Active Assist untuk membuat rekomendasi tentang cara mengoptimalkan lingkungan Anda. Misalnya, insight firewall atau pemberi rekomendasi project tanpa pengawasan memberikan rekomendasi yang dapat ditindaklanjuti yang dapat membantu memperketat postur keamanan Anda.

Buat desain proses untuk meninjau rekomendasi secara berkala atau menerapkan rekomendasi secara otomatis ke pipeline deployment Anda. Tentukan rekomendasi mana yang harus dikelola oleh tim pusat dan mana yang menjadi tanggung jawab pemilik beban kerja, serta terapkan peran IAM untuk mengakses rekomendasi tersebut.

Memberikan pengecualian pada kebijakan organisasi

Blueprint menerapkan serangkaian batasan kebijakan organisasi yang direkomendasikan untuk sebagian besar pelanggan dalam sebagian besar skenario, tetapi Anda mungkin memiliki kasus penggunaan yang sah yang memerlukan pengecualian terbatas pada kebijakan organisasi yang Anda terapkan secara luas.

Misalnya, blueprint menerapkan batasan iam.disableServiceAccountKeyCreation. Batasan ini adalah kontrol keamanan yang penting karena kunci akun layanan yang bocor dapat memiliki dampak negatif yang signifikan, dan sebagian besar skenario harus menggunakan alternatif yang lebih aman untuk kunci akun layanan untuk melakukan autentikasi. Namun, mungkin ada kasus penggunaan yang hanya dapat mengautentikasi dengan kunci akun layanan, seperti server lokal yang memerlukan akses ke layananGoogle Cloud dan tidak dapat menggunakan workload identity federation. Dalam skenario ini, Anda dapat memutuskan untuk mengizinkan pengecualian terhadap kebijakan, selama kontrol kompensasi tambahan seperti praktik terbaik untuk mengelola kunci akun layanan diterapkan.

Oleh karena itu, Anda harus mendesain proses untuk beban kerja guna meminta pengecualian terhadap kebijakan, dan memastikan bahwa pembuat keputusan yang bertanggung jawab untuk memberikan pengecualian memiliki pengetahuan teknis untuk memvalidasi kasus penggunaan dan berkonsultasi tentang apakah kontrol tambahan harus diterapkan untuk mengimbanginya. Saat Anda memberikan pengecualian ke workload, ubah batasan kebijakan organisasi sesempit mungkin. Anda juga dapat menambahkan batasan secara bersyarat ke kebijakan organisasi dengan menentukan tag yang memberikan pengecualian atau penerapan untuk kebijakan, lalu menerapkan tag tersebut ke project dan folder.

Melindungi resource Anda dengan Kontrol Layanan VPC

Blueprint ini membantu menyiapkan lingkungan Anda untuk Kontrol Layanan VPC dengan memisahkan jaringan dasar dan jaringan terbatas. Namun, secara default, kode Terraform tidak mengaktifkan Kontrol Layanan VPC karena pengaktifan ini dapat menjadi proses yang mengganggu.

Perimeter menolak akses ke layanan Google Cloud yang dibatasi dari traffic yang berasal dari luar perimeter, yang mencakup konsol, workstation developer, dan pipeline fondasi yang digunakan untuk men-deploy resource. Jika menggunakan Kontrol Layanan VPC, Anda harus mendesain pengecualian pada perimeter yang mengizinkan jalur akses yang Anda inginkan.

Perimeter Kontrol Layanan VPC ditujukan untuk kontrol pemindahan yang tidak sah antara Google Cloud organisasi Anda dan sumber eksternal. Perimeter ini tidak dimaksudkan untuk menggantikan atau menduplikasi kebijakan izin untuk kontrol akses terperinci ke setiap project atau resource. Saat Anda mendesain dan merancang perimeter, sebaiknya gunakan perimeter terpadu umum untuk overhead pengelolaan yang lebih rendah.

Jika Anda harus mendesain beberapa perimeter untuk mengontrol traffic layanan secara terperinci dalam Google Cloud organisasi, sebaiknya tentukan dengan jelas ancaman yang ditangani oleh struktur perimeter yang lebih kompleks dan jalur akses di antara perimeter yang diperlukan untuk operasi yang diinginkan.

Untuk menerapkan Kontrol Layanan VPC, evaluasi hal berikut:

• Kasus penggunaan mana yang memerlukan Kontrol Layanan VPC.

• Apakah layanan Google Cloud yang diperlukan mendukung Kontrol Layanan VPC.

• Cara mengonfigurasi akses breakglass untuk mengubah perimeter jika mengganggu pipeline otomatisasi Anda.

• Cara menggunakan praktik terbaik untuk mengaktifkan Kontrol Layanan VPC guna mendesain dan menerapkan perimeter Anda.

Setelah perimeter diaktifkan, sebaiknya Anda mendesain proses untuk menambahkan project baru secara konsisten ke perimeter yang benar, dan proses untuk mendesain pengecualian saat developer memiliki kasus penggunaan baru yang ditolak oleh konfigurasi perimeter Anda saat ini.

Menguji perubahan seluruh organisasi di organisasi terpisah

Sebaiknya jangan pernah men-deploy perubahan ke produksi tanpa pengujian. Untuk resource beban kerja, pendekatan ini difasilitasi oleh lingkungan terpisah untuk pengembangan, non-produksi, dan produksi. Namun, beberapa resource di organisasi tidak memiliki lingkungan terpisah untuk memfasilitasi pengujian.

Untuk perubahan di tingkat organisasi, atau perubahan lain yang dapat memengaruhi lingkungan produksi seperti konfigurasi antara penyedia identitas Anda dan Cloud Identity, pertimbangkan untuk membuat organisasi terpisah untuk tujuan pengujian.

Mengontrol akses jarak jauh ke virtual machine

Karena kami merekomendasikan agar Anda men-deploy infrastruktur yang tidak dapat diubah melalui pipeline fondasi, pipeline infrastruktur, dan pipeline aplikasi, sebaiknya Anda hanya memberikan akses langsung ke virtual machine kepada developer melalui SSH atau RDP untuk kasus penggunaan terbatas atau luar biasa.

Untuk skenario yang memerlukan akses jarak jauh, sebaiknya kelola akses pengguna menggunakan Login OS jika memungkinkan. Pendekatan ini menggunakan layanan Google Cloud terkelola untuk menerapkan kontrol akses, pengelolaan siklus proses akun, verifikasi dua langkah, dan logging audit. Atau, jika Anda harus mengizinkan akses melalui kunci SSH dalam metadata atau kredensial RDP, Anda bertanggung jawab untuk mengelola siklus proses kredensial dan menyimpan kredensial dengan aman di luar Google Cloud.

Dalam skenario apa pun, pengguna dengan akses SSH atau RDP ke VM dapat menjadi risiko escalation hak istimewa, jadi Anda harus mendesain model akses dengan mempertimbangkan hal ini. Pengguna dapat menjalankan kode di VM tersebut dengan hak istimewa akun layanan terkait atau membuat kueri server metadata untuk melihat token akses yang digunakan untuk mengautentikasi permintaan API. Akses ini kemudian dapat menjadi eskalasi hak istimewa jika Anda tidak sengaja mengizinkan pengguna beroperasi dengan hak istimewa akun layanan.

Mengurangi pembelanjaan yang berlebihan dengan merencanakan pemberitahuan anggaran

Blueprint ini menerapkan praktik terbaik yang diperkenalkan dalam Google Cloud Framework Arsitektur: Pengoptimalan Biaya untuk mengelola biaya, termasuk hal berikut:

• Gunakan satu akun penagihan di semua project dalam fondasi perusahaan.

• Tetapkan label metadata billingcode ke setiap project yang digunakan untuk mengalokasikan biaya di antara pusat biaya.

• Menetapkan anggaran dan nilai minimum pemberitahuan.

Anda bertanggung jawab untuk merencanakan anggaran dan mengonfigurasi pemberitahuan penagihan. Blueprint ini membuat pemberitahuan anggaran untuk project beban kerja saat perkiraan pembelanjaan berada di jalur untuk mencapai 120% anggaran. Pendekatan ini memungkinkan tim pusat mengidentifikasi dan memitigasi insiden pembelanjaan yang berlebihan secara signifikan. Peningkatan pengeluaran yang tidak terduga secara signifikan tanpa penyebab yang jelas dapat menjadi indikator insiden keamanan dan harus diselidiki dari perspektif kontrol biaya dan keamanan.

Catatan: Pemberitahuan anggaran mencakup jenis notifikasi yang berbeda dengan kategori Penagihan Kontak Penting. Pemberitahuan anggaran terkait dengan penggunaan anggaran yang Anda tentukan untuk setiap project. Notifikasi penagihan dari Kontak Penting terkait pembaruan harga, error, dan kredit.

Bergantung pada kasus penggunaan, Anda dapat menetapkan anggaran yang didasarkan pada biaya seluruh folder lingkungan, atau semua project yang terkait dengan pusat biaya tertentu, bukan menetapkan anggaran terperinci untuk setiap project. Sebaiknya Anda juga mendelegasikan setelan anggaran dan pemberitahuan kepada pemilik beban kerja yang mungkin menetapkan nilai minimum pemberitahuan yang lebih terperinci untuk pemantauan harian mereka.

Untuk panduan tentang cara membangun kemampuan FinOps, termasuk memperkirakan anggaran untuk beban kerja, lihat Memulai FinOps di Google Cloud.

Mengalokasikan biaya di antara pusat biaya internal

Konsol ini memungkinkan Anda melihat laporan penagihan untuk melihat dan memperkirakan biaya dalam beberapa dimensi. Selain laporan bawaan, sebaiknya ekspor data penagihan ke set data BigQuery di project prj-c-billing-export. Data penagihan yang diekspor memungkinkan Anda mengalokasikan biaya pada dimensi kustom, seperti pusat biaya internal, berdasarkan metadata label project seperti billingcode.

Kueri SQL berikut adalah contoh kueri untuk memahami biaya semua project yang dikelompokkan berdasarkan label project billingcode.

#standardSQL
SELECT
   (SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
   service.description AS description,
   SUM(cost) AS charges,
   SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC

Untuk menyiapkan ekspor ini, lihat mengekspor data Penagihan Cloud ke BigQuery.

Jika Anda memerlukan akuntansi internal atau penagihan balik antar-pusat biaya, Anda bertanggung jawab untuk menggabungkan data yang diperoleh dari kueri ini ke dalam proses internal Anda.

Mengambil temuan dari kontrol detektif ke SIEM yang ada

Meskipun resource dasar membantu Anda mengonfigurasi tujuan gabungan untuk log audit dan temuan keamanan, Anda bertanggung jawab untuk memutuskan cara menggunakan dan memanfaatkan sinyal ini.

Jika Anda memiliki persyaratan untuk menggabungkan log di semua lingkungan cloud dan lokal ke dalam SIEM yang ada, tentukan cara menyerap log dari project prj-c-logging dan temuan dari Security Command Center ke dalam alat dan proses yang ada. Anda dapat membuat satu ekspor untuk semua log dan temuan jika satu tim bertanggung jawab untuk memantau keamanan di seluruh lingkungan, atau Anda dapat membuat beberapa ekspor yang difilter ke kumpulan log dan temuan yang diperlukan untuk beberapa tim dengan tanggung jawab yang berbeda.

Atau, jika volume dan biaya log tidak dapat dihindari, Anda dapat menghindari duplikasi dengan mempertahankan log dan temuan Google Cloud hanya diGoogle Cloud. Dalam skenario ini, pastikan tim yang ada memiliki akses dan pelatihan yang tepat untuk menangani log dan temuan secara langsung di Google Cloud.

• Untuk log audit, desain tampilan log untuk memberikan akses ke sebagian log di bucket log terpusat kepada setiap tim, bukan menduplikasi log ke beberapa bucket yang akan meningkatkan biaya penyimpanan log.
• Untuk temuan keamanan, berikan peran tingkat folder dan tingkat project untuk Security Command Center agar tim dapat melihat dan mengelola temuan keamanan hanya untuk project yang menjadi tanggung jawab mereka, langsung di konsol.

Terus kembangkan library kontrol Anda

Blueprint dimulai dengan dasar pengukuran kontrol untuk mendeteksi dan mencegah ancaman. Sebaiknya tinjau kontrol ini dan tambahkan kontrol tambahan berdasarkan persyaratan Anda. Tabel berikut merangkum mekanisme untuk menerapkan kebijakan tata kelola dan cara memperluasnya untuk persyaratan tambahan Anda:

Kontrol kebijakan yang diterapkan oleh blueprint	Panduan untuk memperluas kontrol ini
Security Command Center mendeteksi kerentanan dan ancaman dari beberapa sumber keamanan.	Tentukan modul kustom untuk Security Health Analytics dan modul kustom untuk Event Threat Detection.
Layanan Kebijakan Organisasi menerapkan kumpulan batasan kebijakan organisasi yang direkomendasikan pada layananGoogle Cloud .	Terapkan batasan tambahan dari daftar batasan yang tersedia yang sudah dibuat sebelumnya atau buat batasan kustom.
Kebijakan Open Policy Agent (OPA) memvalidasi kode di pipeline fondasi untuk konfigurasi yang dapat diterima sebelum deployment.	Kembangkan batasan tambahan berdasarkan panduan di GoogleCloudPlatform/policy-library.
Pemberitahuan tentang metrik berbasis log dan metrik performa mengonfigurasi metrik berbasis log untuk memberikan pemberitahuan tentang perubahan pada kebijakan dan konfigurasi IAM untuk beberapa resource sensitif.	Buat desain metrik berbasis log dan kebijakan pemberitahuan tambahan untuk peristiwa log yang Anda perkirakan tidak akan terjadi di lingkungan Anda.
Solusi kustom untuk analisis log otomatis secara rutin membuat kueri log untuk aktivitas yang mencurigakan dan membuat temuan Security Command Center.	Tulis kueri tambahan untuk membuat temuan peristiwa keamanan yang ingin Anda amati, menggunakan analisis log keamanan sebagai referensi.
Solusi kustom untuk merespons perubahan aset membuat temuan Security Command Center dan dapat mengotomatiskan tindakan penyelesaian.	Buat feed Inventaris Aset Cloud tambahan untuk memantau perubahan jenis aset tertentu dan menulis fungsi Cloud Run tambahan dengan logika kustom untuk merespons pelanggaran kebijakan.

Kontrol ini dapat berkembang seiring perubahan persyaratan dan kematangan Anda pada Google Cloud .

Mengelola kunci enkripsi dengan Cloud Key Management Service

Google Cloud menyediakan enkripsi default dalam penyimpanan untuk semua konten pelanggan, tetapi juga menyediakan Cloud Key Management Service (Cloud KMS) untuk memberi Anda kontrol tambahan atas kunci enkripsi untuk data dalam penyimpanan. Sebaiknya nilai apakah enkripsi default sudah memadai, atau apakah Anda memiliki persyaratan kepatuhan yang mengharuskan Anda menggunakan Cloud KMS untuk mengelola kunci sendiri. Untuk informasi selengkapnya, lihat menentukan cara memenuhi persyaratan kepatuhan untuk enkripsi dalam penyimpanan.

Blueprint menyediakan project prj-c-kms di folder umum dan project prj-{env}-kms di setiap folder lingkungan untuk mengelola kunci enkripsi secara terpusat. Pendekatan ini memungkinkan tim pusat mengaudit dan mengelola kunci enkripsi yang digunakan oleh resource dalam project beban kerja, untuk memenuhi persyaratan peraturan dan kepatuhan.

Bergantung pada model operasional Anda, Anda mungkin lebih memilih satu instance project Cloud KMS terpusat di bawah kontrol satu tim, Anda mungkin lebih memilih untuk mengelola kunci enkripsi secara terpisah di setiap lingkungan, atau Anda mungkin lebih memilih beberapa instance terdistribusi sehingga akuntabilitas untuk kunci enkripsi dapat didelegasikan ke tim yang sesuai. Ubah contoh kode Terraform sesuai kebutuhan agar sesuai dengan model operasional Anda.

Secara opsional, Anda dapat menerapkan kebijakan organisasi kunci enkripsi yang dikelola pelanggan (CMEK) untuk menerapkan bahwa jenis resource tertentu selalu memerlukan kunci CMEK dan hanya kunci CMEK dari daftar yang diizinkan untuk project tepercaya yang dapat digunakan.

Menyimpan dan mengaudit kredensial aplikasi dengan Secret Manager

Sebaiknya Anda tidak pernah melakukan secret sensitif (seperti kunci API, sandi, dan sertifikat pribadi) ke repositori kode sumber. Sebagai gantinya, commit secret ke Secret Manager dan berikan peran IAM Secret Manager Secret Accessor kepada pengguna atau akun layanan yang perlu mengakses secret. Sebaiknya Anda memberikan peran IAM ke secret individual, bukan ke semua secret dalam project.

Jika memungkinkan, Anda harus membuat secret produksi secara otomatis dalam pipeline CI/CD dan membuatnya tidak dapat diakses oleh pengguna manusia kecuali dalam situasi breakglass. Dalam skenario ini, pastikan Anda tidak memberikan peran IAM untuk melihat secret ini kepada pengguna atau grup mana pun.

Blueprint menyediakan satu project prj-c-secrets di folder umum dan project prj-{env}-secrets di setiap folder lingkungan untuk mengelola secret secara terpusat. Pendekatan ini memungkinkan tim pusat mengaudit dan mengelola secret yang digunakan oleh aplikasi untuk memenuhi persyaratan peraturan dan kepatuhan.

Bergantung pada model operasional Anda, Anda mungkin lebih memilih satu instance Secret Manager terpusat di bawah kontrol satu tim, atau Anda mungkin lebih memilih untuk mengelola secret secara terpisah di setiap lingkungan, atau Anda mungkin lebih memilih beberapa instance Secret Manager terdistribusi sehingga setiap tim workload dapat mengelola secret mereka sendiri. Ubah contoh kode Terraform sesuai kebutuhan agar sesuai dengan model operasional Anda.

Merencanakan akses breakglass ke akun dengan hak istimewa tinggi

Meskipun kami merekomendasikan agar perubahan pada resource fondasi dikelola melalui IaC yang dikontrol versi yang di-deploy oleh pipeline fondasi, Anda mungkin memiliki skenario darurat atau luar biasa yang memerlukan akses dengan hak istimewa untuk mengubah lingkungan secara langsung. Sebaiknya Anda merencanakan akun breakglass (terkadang disebut akun panggilan darurat atau akun darurat) yang memiliki akses dengan hak istimewa tinggi ke lingkungan Anda jika terjadi keadaan darurat atau saat proses otomatisasi mengalami gangguan.

Tabel berikut menjelaskan beberapa contoh tujuan akun breakglass.

Tujuan akses darurat	Deskripsi
Admin super	Akses darurat ke peran Admin super yang digunakan dengan Cloud Identity, misalnya, untuk memperbaiki masalah yang terkait dengan federasi identitas atau autentikasi multi-faktor (MFA).
Administrator organisasi	Akses darurat ke peran Administrator Organisasi, yang kemudian dapat memberikan akses ke peran IAM lainnya di organisasi.
Administrator pipeline fondasi	Akses darurat untuk mengubah resource dalam project CI/CD Anda di Google Cloud dan repositori Git eksternal jika otomatisasi pipeline fondasi mengalami gangguan.
Operasi atau SRE	Tim operasi atau SRE memerlukan akses dengan hak istimewa untuk merespons pemadaman layanan atau insiden. Hal ini dapat mencakup tugas seperti memulai ulang VM atau memulihkan data.

Mekanisme Anda untuk mengizinkan akses breakglass bergantung pada alat dan prosedur yang sudah ada, tetapi beberapa contoh mekanisme mencakup hal berikut:

• Gunakan alat yang ada untuk pengelolaan akses dengan hak istimewa guna menambahkan sementara pengguna ke grup yang telah ditentukan sebelumnya dengan peran IAM yang memiliki hak istimewa tinggi atau gunakan kredensial akun yang memiliki hak istimewa tinggi.
• Akun pra-penyediaan hanya ditujukan untuk penggunaan administrator. Misalnya, developer Dana mungkin memiliki identitas [e-mail] untuk penggunaan sehari-hari dan [e-mail] untuk akses breakglass.
• Gunakan aplikasi seperti akses hak istimewa tepat waktu yang memungkinkan developer melakukan eskalasi mandiri ke peran yang lebih istimewa.

Terlepas dari mekanisme yang Anda gunakan, pertimbangkan cara Anda secara operasional menjawab pertanyaan berikut:

• Bagaimana cara Anda mendesain cakupan dan perincian akses breakglass? Misalnya, Anda dapat mendesain mekanisme breakglass yang berbeda untuk unit bisnis yang berbeda untuk memastikan bahwa keduanya tidak dapat saling mengganggu.
• Bagaimana mekanisme Anda mencegah penyalahgunaan? Apakah Anda memerlukan persetujuan? Misalnya, Anda mungkin memiliki operasi terpisah dengan satu orang memegang kredensial dan satu orang memegang token MFA.
• Bagaimana cara Anda mengaudit dan memberikan pemberitahuan tentang akses breakglass? Misalnya, Anda dapat mengonfigurasi modul Event Threat Detection kustom untuk membuat temuan keamanan saat akun breakglass yang telah ditentukan sebelumnya digunakan.
• Bagaimana cara menghapus akses breakglass dan melanjutkan operasi normal setelah insiden berakhir?

Untuk tugas eskalasi hak istimewa umum dan mengembalikan perubahan, sebaiknya desain alur kerja otomatis tempat pengguna dapat melakukan operasi tanpa memerlukan eskalasi hak istimewa untuk identitas pengguna mereka. Pendekatan ini dapat membantu mengurangi error manusia dan meningkatkan keamanan.

Untuk sistem yang memerlukan intervensi rutin, mengotomatiskan perbaikan mungkin merupakan solusi terbaik. Google mendorong pelanggan untuk mengadopsi pendekatan produksi zero-touch untuk melakukan semua perubahan produksi menggunakan otomatisasi, proxy aman, atau breakglass yang diaudit. Google menyediakan buku SRE untuk pelanggan yang ingin mengadopsi pendekatan SRE Google.

Langkah berikutnya

• Baca Men-deploy blueprint (dokumen berikutnya dalam seri ini).

Men-deploy blueprint

Bagian ini menjelaskan proses yang dapat Anda gunakan untuk men-deploy blueprint, konvensi penamaannya, dan alternatif untuk rekomendasi blueprint.

Menyatukan semuanya

Untuk men-deploy fondasi perusahaan Anda sendiri sesuai dengan praktik terbaik dan rekomendasi dari blueprint ini, ikuti tugas tingkat tinggi yang diringkas di bagian ini. Deployment memerlukan kombinasi langkah penyiapan prasyarat, deployment otomatis melalui terraform-example-foundation di GitHub, dan langkah tambahan yang harus dikonfigurasi secara manual setelah deployment fondasi awal selesai.

Proses	Langkah
Prasyarat sebelum men-deploy resource pipeline dasar	Selesaikan langkah-langkah berikut sebelum men-deploy pipeline fondasi: Buat akun Cloud Identity dan verifikasi kepemilikan domain. Ajukan permohonan akun penagihan dengan invoice kepada Google Cloud tim penjualan Anda atau buat akun penagihan layanan mandiri. Terapkan praktik terbaik keamanan untuk akun administrator. Verifikasi dan rekonsiliasi masalah terkait akun pengguna konsumen. Konfigurasikan penyedia identitas eksternal sebagai sumber tepercaya untuk menyinkronkan akun pengguna dan SSO. Sediakan grup untuk kontrol akses yang diperlukan untuk menjalankan blueprint. Tentukan topologi jaringan yang akan Anda gunakan. Tentukan alat pengelolaan kode sumber Anda. Petunjuk untuk terraform-example-foundation ditulis ke repositori Git yang dihosting di Cloud Source Repositories. Tentukan alat otomatisasi CI/CD Anda. terraform-example-foundation menyediakan kumpulan petunjuk yang berbeda untuk berbagai alat otomatisasi. Untuk terhubung ke lingkungan lokal yang ada, siapkan hal berikut: Rencanakan alokasi alamat IP berdasarkan jumlah dan ukuran rentang yang diperlukan oleh blueprint. Pesan koneksi Dedicated Interconnect Anda.
Langkah-langkah untuk men-deploy terraform-example-foundation dari GitHub	Ikuti petunjuk README untuk setiap tahap guna men-deploy terraform-example-foundation dari GitHub: Tahap 0-bootstrap untuk membuat pipeline fondasi. Jika menggunakan akun penagihan layanan mandiri, Anda harus meminta kuota project tambahan sebelum melanjutkan ke tahap berikutnya. Tahap 1-org untuk mengonfigurasi resource tingkat organisasi. Lakukan staging 2-environments untuk membuat lingkungan. Lakukan staging pada 3-networks-dual-svpc or 3-networks-hub-and-spoke untuk membuat resource jaringan dalam topologi pilihan Anda. Tahap 4-projects untuk membuat pipeline infrastruktur. Secara opsional, tahapkan 5-app-infra untuk contoh penggunaan pipeline infrastruktur.
Langkah tambahan setelah deployment IaC	Setelah Anda men-deploy kode Terraform, selesaikan langkah-langkah berikut: Selesaikan perubahan konfigurasi lokal. Aktifkan Security Command Center Premium. Ekspor data Penagihan Cloud ke BigQuery. Daftar ke paket Cloud Customer Care. Aktifkan log Transparansi Akses. Bagikan data dari Cloud Identity dengan Google Cloud. Terapkan kontrol administratif untuk Cloud Identity yang tidak diotomatiskan oleh deployment IaC. Pertimbangkan kontrol administrative tambahan untuk pelanggan dengan workload sensitif mana yang sesuai untuk kasus penggunaan Anda. Tinjau praktik terbaik operasi dan rencanakan cara menghubungkan operasi dan kemampuan yang ada ke resource dasar.

Kontrol administratif tambahan untuk pelanggan dengan workload sensitif

Google Cloud memberikan kontrol administratif tambahan yang dapat membantu persyaratan keamanan dan kepatuhan Anda. Namun, beberapa kontrol melibatkan biaya tambahan atau kompromi operasional yang mungkin tidak sesuai untuk setiap pelanggan. Kontrol ini juga memerlukan input yang disesuaikan untuk persyaratan khusus Anda yang tidak dapat sepenuhnya diotomatiskan dalam blueprint dengan nilai default untuk semua pelanggan.

Bagian ini memperkenalkan kontrol keamanan yang Anda terapkan secara terpusat ke fondasi Anda. Bagian ini tidak dimaksudkan untuk menjelaskan semua kontrol keamanan yang dapat Anda terapkan ke workload tertentu. Untuk informasi selengkapnya tentang produk dan solusi keamanan Google, lihat Google Cloud pusat praktik terbaik keamanan.

Evaluasi apakah kontrol berikut sesuai untuk fondasi Anda berdasarkan persyaratan kepatuhan, selera risiko, dan sensitivitas data.

Kontrol	Deskripsi
Melindungi resource Anda dengan Kontrol Layanan VPC	Kontrol Layanan VPC memungkinkan Anda menentukan kebijakan keamanan yang mencegah akses ke layanan yang dikelola Google di luar perimeter tepercaya, memblokir akses ke data dari lokasi yang tidak tepercaya, dan memitigasi risiko pemindahan data yang tidak sah. Namun, Kontrol Layanan VPC dapat menyebabkan layanan yang ada rusak hingga Anda menentukan pengecualian untuk mengizinkan pola akses yang diinginkan. Evaluasi apakah nilai mitigasi risiko pemindahan data yang tidak sah membenarkan peningkatan kompleksitas dan overhead operasional dari penerapan Kontrol Layanan VPC. Blueprint menyiapkan jaringan yang dibatasi dan variabel opsional untuk mengonfigurasi Kontrol Layanan VPC, tetapi perimeter tidak diaktifkan hingga Anda melakukan langkah-langkah tambahan untuk mendesain dan mengaktifkannya.
Membatasi lokasi resource	Anda mungkin memiliki persyaratan peraturan bahwa resource cloud hanya boleh di-deploy di lokasi geografis yang disetujui. Batasan kebijakan organisasi ini menerapkan bahwa resource hanya dapat di-deploy dalam daftar lokasi yang Anda tentukan.
Mengaktifkan Assured Workloads	Assured Workloads menyediakan kontrol kepatuhan tambahan yang membantu Anda memenuhi rezim peraturan tertentu. Blueprint menyediakan variabel opsional di pipeline deployment untuk pengaktifan.
Mengaktifkan log akses data	Anda mungkin memiliki persyaratan untuk mencatat semua akses ke data atau resource sensitif tertentu. Evaluasi tempat beban kerja Anda menangani data sensitif yang memerlukan log akses data, dan aktifkan log untuk setiap layanan dan lingkungan yang menangani data sensitif.
Mengaktifkan Persetujuan Akses	Persetujuan Akses memastikan bahwa Cloud Customer Care dan engineering memerlukan persetujuan eksplisit Anda setiap kali mereka perlu mengakses konten pelanggan Anda. Evaluasi proses operasional yang diperlukan untuk meninjau permintaan Access Approval guna mengurangi kemungkinan penundaan dalam menyelesaikan insiden dukungan.
Mengaktifkan Key Access Justifications	Justifikasi Akses Kunci memungkinkan Anda mengontrol secara terprogram apakah Google dapat mengakses kunci enkripsi Anda, termasuk untuk operasi otomatis dan agar Layanan Pelanggan dapat mengakses konten pelanggan Anda. Evaluasi biaya dan overhead operasional yang terkait dengan Key Access Justifications serta dependensinya pada Cloud External Key Manager (Cloud EKM).
Menonaktifkan Cloud Shell	Cloud Shell adalah lingkungan pengembangan online. Shell ini dihosting di server yang dikelola Google di luar lingkungan Anda, sehingga tidak tunduk pada kontrol yang mungkin telah Anda terapkan di workstation developer Anda sendiri. Jika Anda ingin mengontrol secara ketat workstation mana yang dapat digunakan developer untuk mengakses resource cloud, nonaktifkan Cloud Shell. Anda juga dapat mengevaluasi Cloud Workstations untuk opsi workstation yang dapat dikonfigurasi di lingkungan Anda sendiri.
Membatasi akses ke konsol Google Cloud	Google Cloud memungkinkan Anda membatasi akses ke konsol Google Cloud berdasarkan atribut tingkat akses seperti keanggotaan grup, rentang alamat IP tepercaya, dan verifikasi perangkat. Beberapa atribut memerlukan langganan tambahan ke Chrome Enterprise Premium. Evaluasi pola akses yang Anda percayai untuk akses pengguna ke aplikasi berbasis web seperti konsol sebagai bagian dari pen-deployment zero trust yang lebih besar.

Konvensi penamaan

Sebaiknya Anda memiliki konvensi penamaan standar untuk resourceGoogle Cloud . Tabel berikut menjelaskan konvensi yang direkomendasikan untuk nama resource dalam blueprint.

Resource	Konvensi penamaan
Folder	fldr-environment environment adalah deskripsi resource tingkat folder dalam organisasi Google Cloud. Misalnya, bootstrap, common, production, nonproduction, development, atau network. Contoh: fldr-production
ID Project	prj-environmentcode-description-randomid environmentcode adalah bentuk singkat dari kolom lingkungan (salah satu dari b, c, p, n, d, atau net). Project host VPC Bersama menggunakan environmentcode dari lingkungan terkait. Project untuk resource jaringan yang digunakan bersama di seluruh lingkungan, seperti project interconnect, menggunakan kode lingkungan net. description adalah informasi tambahan tentang project. Anda dapat menggunakan singkatan yang singkat dan dapat dibaca manusia. randomid adalah akhiran acak untuk mencegah konflik nama resource yang harus unik secara global dan untuk mengurangi serangan penyerang yang menebak nama resource. Blueprint akan otomatis menambahkan ID alfanumerik empat karakter secara acak. Contoh: prj-c-logging-a1b2
Jaringan VPC	vpc-environmentcode-vpctype-vpcconfig environmentcode adalah bentuk singkat dari kolom lingkungan (salah satu dari b, c, p, n, d, atau net). vpctype adalah salah satu dari shared, float, atau peer. vpcconfig adalah base atau restricted untuk menunjukkan apakah jaringan dimaksudkan untuk digunakan dengan Kontrol Layanan VPC atau tidak. Contoh: vpc-p-shared-base
Subnet	sn-environmentcode-vpctype-vpcconfig-region{-description} environmentcode adalah bentuk singkat dari kolom lingkungan (salah satu dari b, c, p, n, d, atau net). vpctype adalah salah satu dari shared, float, atau peer. vpcconfig adalah base atau restricted untuk menunjukkan apakah jaringan dimaksudkan untuk digunakan dengan Kontrol Layanan VPC atau tidak. region adalah region Google Cloud yang valid tempat resource berada. Sebaiknya hapus tanda hubung dan gunakan bentuk singkatan dari beberapa wilayah dan rute untuk menghindari batas karakter. Misalnya, au (Australia), na (Amerika Utara), sa (Amerika Selatan), eu (Eropa), se (tenggara), atau ne (timur laut). description adalah informasi tambahan tentang subnet. Anda dapat menggunakan singkatan pendek yang dapat dibaca manusia. Contoh: sn-p-shared-restricted-uswest1
Kebijakan firewall	fw-firewalltype-scope-environmentcode{-description} firewalltype adalah hierarchical atau network. scope adalah global atau wilayah Google Cloud tempat resource berada. Sebaiknya hapus tanda hubung dan gunakan bentuk singkatan dari beberapa wilayah dan rute untuk menghindari batas karakter. Misalnya, au (Australia), na (Amerika Utara), sa (Amerika Selatan), eu (Eropa), se (tenggara), atau ne (timur laut). environmentcode adalah bentuk singkat dari kolom lingkungan (salah satu dari b, c, p, n, d, atau net) yang memiliki resource kebijakan. description adalah informasi tambahan tentang kebijakan firewall hierarkis. Anda dapat menggunakan singkatan pendek yang dapat dibaca manusia. Misalnya: fw-hierarchical-global-c-01 fw-network-uswest1-p-shared-base
Cloud Router	cr-environmentcode-vpctype-vpcconfig-region{-description} environmentcode adalah bentuk singkat dari kolom lingkungan (salah satu dari b, c, p, n, d, atau net). vpctype adalah salah satu dari shared, float, atau peer. vpcconfig adalah base atau restricted untuk menunjukkan apakah jaringan dimaksudkan untuk digunakan dengan Kontrol Layanan VPC atau tidak. region adalah region Google Cloud yang valid tempat resource berada. Sebaiknya hapus tanda hubung dan gunakan bentuk singkatan dari beberapa wilayah dan rute untuk menghindari batas karakter. Misalnya, au (Australia), na (Amerika Utara), sa (Amerika Selatan), eu (Eropa), se (tenggara), atau ne (timur laut). description adalah informasi tambahan tentang Cloud Router. Anda dapat menggunakan singkatan pendek yang dapat dibaca manusia. Contoh: cr-p-shared-base-useast1-cr1
Koneksi Cloud Interconnect	ic-dc-colo dc adalah nama pusat data Anda yang terhubung ke Cloud Interconnect. colo adalah nama fasilitas kolokasi yang di-peering dengan Cloud Interconnect dari pusat data lokal. Contoh: ic-mydatacenter-lgazone1
Lampiran VLAN Cloud Interconnect	vl-dc-colo-environmentcode-vpctype-vpcconfig-region{-description} dc adalah nama pusat data Anda yang terhubung ke Cloud Interconnect. colo adalah nama fasilitas kolokasi yang di-peering dengan Cloud Interconnect dari pusat data lokal. environmentcode adalah bentuk singkat dari kolom lingkungan (salah satu dari b, c, p, n, d, atau net). vpctype adalah salah satu dari shared, float, atau peer. vpcconfig adalah base atau restricted untuk menunjukkan apakah jaringan dimaksudkan untuk digunakan dengan Kontrol Layanan VPC atau tidak. region adalah region Google Cloud yang valid tempat resource berada. Sebaiknya hapus tanda hubung dan gunakan bentuk singkatan dari beberapa wilayah dan rute untuk menghindari batas karakter. Misalnya, au (Australia), na (Amerika Utara), sa (Amerika Selatan), eu (Eropa), se (tenggara), atau ne (timur laut). description adalah informasi tambahan tentang VLAN. Anda dapat menggunakan singkatan pendek yang dapat dibaca manusia. Contoh: vl-mydatacenter-lgazone1-p-shared-base-useast1-cr1
Grup	[e-mail] Dengan description adalah informasi tambahan tentang grup. Anda dapat menggunakan singkatan singkat yang dapat dibaca manusia. Contoh: [e-mail]
Peran khusus	rl-description Dengan description adalah informasi tambahan tentang peran. Anda dapat menggunakan singkatan yang pendek dan dapat dibaca manusia. Contoh: rl-customcomputeadmin
Akun layanan	sa-description@projectid. Dengan keterangan: description adalah informasi tambahan tentang akun layanan. Anda dapat menggunakan singkatan pendek yang dapat dibaca manusia. projectid adalah ID project yang unik secara global. Contoh: sa-terraform-net@prj-b-seed-a1b2.
Bucket penyimpanan	bkt-projectid-description Dengan keterangan: projectid adalah ID project yang unik secara global. description adalah informasi tambahan tentang bucket penyimpanan. Anda dapat menggunakan singkatan pendek yang dapat dibaca manusia. Contoh: bkt-prj-c-infra-pipeline-a1b2-app-artifacts

Alternatif untuk rekomendasi default

Praktik terbaik yang direkomendasikan dalam blueprint mungkin tidak cocok untuk setiap pelanggan. Anda dapat menyesuaikan rekomendasi apa pun untuk memenuhi persyaratan spesifik Anda. Tabel berikut memperkenalkan beberapa variasi umum yang mungkin Anda perlukan berdasarkan stack teknologi dan cara kerja yang ada.

Area keputusan	Alternatif yang memungkinkan
Organisasi: Blueprint menggunakan satu organisasi sebagai node root untuk semua resource.	Menentukan hierarki resource untuk Google Cloud zona landing memperkenalkan skenario saat Anda mungkin lebih memilih beberapa organisasi, seperti berikut: Organisasi Anda menyertakan sub-perusahaan yang kemungkinan akan dijual di masa mendatang atau yang dijalankan sebagai entitas yang sepenuhnya terpisah. Anda ingin bereksperimen di lingkungan sandbox tanpa konektivitas ke organisasi yang ada.
Struktur folder: Blueprint memiliki struktur folder yang sederhana, dengan beban kerja dibagi menjadi folder production, non-production dan development di lapisan atas.	Menentukan hierarki resource untuk Google Cloud zona landing memperkenalkan pendekatan lain untuk menyusun folder berdasarkan cara Anda ingin mengelola resource dan mewarisi kebijakan, seperti: Folder berdasarkan lingkungan aplikasi Folder berdasarkan entitas regional atau anak perusahaan Folder berdasarkan framework akuntabilitas
Kebijakan organisasi: Blueprint menerapkan semua batasan kebijakan organisasi di node organisasi.	Anda mungkin memiliki kebijakan keamanan atau cara kerja yang berbeda untuk berbagai bagian bisnis. Dalam skenario ini, terapkan batasan kebijakan organisasi di node yang lebih rendah dalam hierarki resource. Tinjau daftar lengkap batasan kebijakan organisasi yang membantu memenuhi persyaratan Anda.
Alat pipeline deployment: Blueprint menggunakan Cloud Build untuk menjalankan pipeline otomatisasi.	Anda mungkin lebih memilih produk lain untuk pipeline deployment, seperti Terraform Enterprise, GitLab Runners, GitHub Actions, atau Jenkins. Blueprint menyertakan rute alternatif untuk setiap produk.
Repositori kode untuk deployment: Blueprint menggunakan Cloud Source Repositories sebagai repositori Git pribadi terkelola.	Gunakan sistem kontrol versi pilihan Anda untuk mengelola repositori kode, seperti GitLab, GitHub, atau Bitbucket. Jika Anda menggunakan repositori pribadi yang dihosting di lingkungan lokal, konfigurasikan jalur jaringan pribadi dari repositori ke lingkungan Google Cloud.
Penyedia identitas: Blueprint mengasumsikan Active Directory lokal dan menggabungkan identitas ke Cloud Identity menggunakan Google Cloud Directory Sync.	Jika sudah menggunakan Google Workspace, Anda dapat menggunakan identitas Google yang sudah dikelola di Google Workspace. Jika tidak memiliki penyedia identitas, Anda dapat membuat dan mengelola identitas pengguna langsung di Cloud Identity. Jika sudah memiliki penyedia identitas, seperti Okta, Ping, atau Azure Entra ID, Anda dapat mengelola akun pengguna di penyedia identitas yang ada dan menyinkronkannya ke Cloud Identity. Jika Anda memiliki kedaulatan data atau persyaratan kepatuhan yang mencegah Anda menggunakan Cloud Identity, dan jika Anda tidak memerlukan identitas pengguna Google terkelola untuk layanan Google lainnya seperti Google Ads atau Google Marketing Platform, Anda mungkin lebih memilih federasi identitas tenaga kerja. Dalam skenario ini, perhatikan batasan pada layanan yang didukung.
Beberapa region: Blueprint men-deploy resource regional ke dua region Google Cloud yang berbeda untuk membantu mengaktifkan desain workload dengan mempertimbangkan persyaratan ketersediaan tinggi dan pemulihan dari bencana.	Jika memiliki pengguna akhir di lebih banyak lokasi geografis, Anda dapat mengonfigurasi lebih banyak region Google Cloud untuk membuat resource yang lebih dekat dengan pengguna akhir dengan latensi yang lebih rendah. Jika Anda memiliki batasan kedaulatan data atau kebutuhan ketersediaan Anda dapat dipenuhi di satu region, Anda mungkin hanya mengonfigurasi satu regionGoogle Cloud .
Alokasi alamat IP: Blueprint menyediakan kumpulan rentang alamat IP.	Anda mungkin perlu mengubah rentang alamat IP tertentu yang digunakan berdasarkan ketersediaan alamat IP di lingkungan hybrid yang ada. Jika Anda mengubah rentang alamat IP, gunakan blueprint sebagai panduan untuk jumlah dan ukuran rentang yang diperlukan, dan tinjau rentang alamat IP yang valid untuk Google Cloud.
Jaringan hybrid: Blueprint menggunakan Dedicated Interconnect di beberapa situs fisik dan Google Cloud region untuk bandwidth dan ketersediaan maksimum.	Bergantung pada persyaratan biaya, bandwidth, dan keandalan, Anda dapat mengonfigurasi Partner Interconnect atau Cloud VPN. Jika Anda perlu mulai men-deploy resource dengan konektivitas pribadi sebelum Dedicated Interconnect dapat diselesaikan, Anda dapat memulai dengan Cloud VPN dan beralih untuk menggunakan Dedicated Interconnect nanti. Jika tidak memiliki lingkungan lokal, Anda mungkin tidak memerlukan jaringan campuran sama sekali.
Perimeter Kontrol Layanan VPC: Blueprint merekomendasikan satu perimeter yang mencakup semua project layanan yang terkait dengan jaringan VPC yang dibatasi. Project yang terkait dengan jaringan VPC dasar tidak disertakan di dalam perimeter.	Anda mungkin memiliki kasus penggunaan yang memerlukan beberapa perimeter untuk organisasi atau Anda mungkin memutuskan untuk tidak menggunakan Kontrol Layanan VPC sama sekali. Untuk mengetahui informasinya, lihat menentukan cara memitigasi pemindahan data yang tidak sah melalui Google API.
Secret Manager: Blueprint men-deploy project untuk menggunakan Secret Manager di folder common untuk secret seluruh organisasi, dan project di setiap folder lingkungan untuk secret khusus lingkungan.	Jika Anda memiliki satu tim yang bertanggung jawab untuk mengelola dan mengaudit secret sensitif di seluruh organisasi, Anda mungkin lebih memilih untuk hanya menggunakan satu project untuk mengelola akses ke secret. Jika Anda mengizinkan tim workload mengelola secret mereka sendiri, Anda mungkin tidak menggunakan project terpusat untuk mengelola akses ke secret, dan sebagai gantinya mengizinkan tim menggunakan instance Secret Manager mereka sendiri dalam project workload.
Cloud KMS: Blueprint men-deploy project untuk menggunakan Cloud KMS di folder common untuk kunci di seluruh organisasi, dan project untuk setiap folder lingkungan untuk kunci di setiap lingkungan.	Jika Anda memiliki satu tim yang bertanggung jawab untuk mengelola dan mengaudit kunci enkripsi di seluruh organisasi, sebaiknya gunakan satu project saja untuk mengelola akses ke kunci. Pendekatan terpusat dapat membantu memenuhi persyaratan kepatuhan seperti kustodian kunci enkripsi PCI. Jika Anda mengizinkan tim workload mengelola kunci mereka sendiri, Anda mungkin tidak menggunakan project terpusat untuk mengelola akses ke kunci, dan sebagai gantinya mengizinkan tim menggunakan instance Cloud KMS mereka sendiri dalam project workload.
Sink log gabungan: Blueprint mengonfigurasi kumpulan sink log di node organisasi sehingga tim keamanan pusat dapat meninjau log audit dari seluruh organisasi.	Anda mungkin memiliki tim yang berbeda yang bertanggung jawab untuk mengaudit berbagai bagian bisnis, dan tim ini mungkin memerlukan log yang berbeda untuk melakukan tugas mereka. Dalam skenario ini, desain beberapa sink gabungan di folder dan project yang sesuai, lalu buat filter sehingga setiap tim hanya menerima log yang diperlukan, atau desain tampilan log untuk kontrol akses terperinci ke bucket log umum.
Perincian pipeline infrastruktur: Blueprint ini menggunakan model yang memungkinkan setiap unit bisnis memiliki pipeline infrastruktur terpisah untuk mengelola project workload mereka.	Anda mungkin lebih memilih satu pipeline infrastruktur yang dikelola oleh tim pusat jika memiliki tim pusat yang bertanggung jawab untuk men-deploy semua project dan infrastruktur. Tim pusat ini dapat menerima permintaan pull dari tim beban kerja untuk ditinjau dan disetujui sebelum pembuatan project, atau tim dapat membuat permintaan pull sendiri sebagai respons terhadap sistem tiket. Anda mungkin lebih memilih pipeline yang lebih terperinci jika setiap tim beban kerja memiliki kemampuan untuk menyesuaikan pipeline mereka sendiri dan Anda ingin mendesain akun layanan dengan hak istimewa yang lebih terperinci untuk pipeline tersebut.
Ekspor SIEM:Blueprint ini mengelola semua temuan keamanan di Security Command Center.	Tentukan apakah Anda akan mengekspor temuan keamanan dari Security Command Center ke alat seperti Google Security Operations atau SIEM yang ada, atau apakah tim akan menggunakan konsol untuk melihat dan mengelola temuan keamanan. Anda dapat mengonfigurasi beberapa ekspor dengan filter unik untuk tim yang berbeda dengan cakupan dan tanggung jawab yang berbeda.
Penelusuran DNS untuk Google Cloud layanan dari lokal: Blueprint mengonfigurasi endpoint Private Service Connect yang unik untuk setiap VPC Bersama, yang dapat membantu mengaktifkan desain dengan beberapa perimeter Kontrol Layanan VPC.	Anda mungkin tidak memerlukan perutean dari lingkungan lokal ke endpoint Private Service Connect pada tingkat perincian ini jika Anda tidak memerlukan beberapa perimeter Kontrol Layanan VPC. Daripada memetakan host lokal ke endpoint Private Service Connect menurut lingkungan, Anda dapat menyederhanakan desain ini untuk menggunakan satu endpoint Private Service Connect dengan paket API yang sesuai, atau menggunakan endpoint generik untuk private.googleapis.com dan restricted.googleapis.com.

Langkah berikutnya

• Terapkan blueprint menggunakan fondasi contoh Terraform di GitHub.
• Pelajari lebih lanjut prinsip desain praktik terbaik dengan Google Cloud Framework Arsitektur.

• Tinjau library blueprint untuk membantu Anda mempercepat desain dan pembuatan workload perusahaan umum, termasuk yang berikut ini:

  • Mengimpor data dari Google Cloud ke data warehouse BigQuery yang aman

  • Mengimpor data dari jaringan eksternal ke data warehouse BigQuery yang aman

  • Men-deploy arsitektur serverless yang aman menggunakan fungsi Cloud Run

  • Men-deploy arsitektur serverless yang aman menggunakan Cloud Run

• Lihat solusi terkait untuk di-deploy di atas lingkungan fondasi Anda.

• Untuk mendapatkan akses ke lingkungan demonstrasi, hubungi kami di [e-mail].