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:
Untuk terhubung ke lingkungan lokal yang ada, siapkan hal berikut:
|
Langkah-langkah untuk men-deploy terraform-example-foundation dari GitHub |
Ikuti petunjuk README untuk setiap tahap guna men-deploy terraform-example-foundation dari GitHub:
|
Langkah tambahan setelah deployment IaC |
Setelah Anda men-deploy kode Terraform, selesaikan langkah-langkah berikut:
|
Kontrol administratif tambahan untuk pelanggan dengan workload sensitif
Google Cloud menyediakan 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 Pusat praktik terbaik keamanan Google Cloud.
Evaluasi apakah kontrol berikut sesuai untuk fondasi Anda berdasarkan persyaratan kepatuhan, selera risiko, dan sensitivitas data.
Kontrol | Deskripsi |
---|---|
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. |
|
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. |
|
Assured Workloads menyediakan kontrol kepatuhan tambahan yang membantu Anda memenuhi rezim peraturan tertentu. Blueprint menyediakan variabel opsional di pipeline deployment untuk pengaktifan. |
|
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. |
|
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. |
|
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). |
|
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. |
|
Dengan Google Cloud, Anda dapat 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 resource Google Cloud. Tabel berikut menjelaskan konvensi yang direkomendasikan untuk nama resource dalam blueprint.
Resource | Konvensi penamaan |
---|---|
Folder |
Contoh:
|
ID Project |
Contoh: |
Jaringan VPC |
Contoh: |
Subnet |
Contoh: |
Kebijakan firewall |
Misalnya:
|
Cloud Router |
Contoh: |
Koneksi Cloud Interconnect |
Contoh: |
Lampiran VLAN Cloud Interconnect |
Contoh:
|
Grup |
Dengan
Contoh:
|
Peran khusus |
Dengan Contoh: |
Akun layanan |
Dengan keterangan:
Contoh:
|
Bucket penyimpanan |
Dengan keterangan:
Contoh:
|
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 zona landing Google Cloud Anda memperkenalkan skenario saat Anda mungkin lebih memilih beberapa organisasi, seperti berikut:
|
Struktur folder: Blueprint memiliki struktur folder
yang sederhana, dengan beban kerja dibagi menjadi folder |
Menentukan hierarki resource untuk zona landing Google Cloud Anda memperkenalkan pendekatan lain untuk menyusun struktur folder berdasarkan cara Anda ingin mengelola resource dan mewarisi kebijakan, seperti:
|
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 penggabungan 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 beban kerja 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 region Google 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 region Google Cloud 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 |
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 |
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 penjaga kunci 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 layanan Google Cloud dari lokal: Blueprint mengonfigurasi endpoint Private Service Connect 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 |
Langkah selanjutnya
- Terapkan blueprint menggunakan fondasi contoh Terraform di GitHub.
- Pelajari lebih lanjut prinsip desain praktik terbaik dengan Framework Arsitektur Google Cloud.
Tinjau library blueprint untuk membantu Anda mempercepat desain dan pembuatan workload perusahaan umum, termasuk hal berikut:
Lihat solusi terkait untuk di-deploy di atas lingkungan fondasi Anda.
Untuk mendapatkan akses ke lingkungan demonstrasi, hubungi kami di security-foundations-blueprint-support@google.com.