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-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 Anda 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 yang sensitif
Google Cloud memberikan kontrol administratif tambahan yang dapat membantu persyaratan keamanan dan kepatuhan Anda. Namun, beberapa kontrol memerlukan kompromi biaya atau operasional tambahan yang mungkin tidak sesuai untuk setiap pelanggan. Kontrol ini juga memerlukan input yang disesuaikan untuk persyaratan spesifik Anda yang tidak dapat sepenuhnya diotomatiskan dalam blueprint dengan nilai default untuk semua pelanggan.
Bagian ini memperkenalkan kontrol keamanan yang diterapkan secara terpusat pada fondasi Anda. Bagian ini tidak dimaksudkan untuk mencakup semua kontrol keamanan yang dapat Anda terapkan pada workload tertentu. Untuk mengetahui informasi selengkapnya tentang produk dan solusi keamanan Google, lihat Pusat praktik terbaik keamanan Google Cloud.
Evaluasi apakah kontrol berikut sesuai untuk dasar Anda berdasarkan persyaratan kepatuhan, tingkat risiko, dan sensitivitas data Anda.
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 gangguan pada layanan yang ada hingga Anda menentukan pengecualian untuk mengizinkan pola akses yang diinginkan. Lakukan evaluasi apakah nilai memitigasi risiko pemindahan yang tidak sah sesuai dengan peningkatan kompleksitas dan overhead operasional dari pengadopsian Kontrol Layanan VPC. Blueprint menyiapkan jaringan terbatas dan variabel opsional untuk mengonfigurasi Kontrol Layanan VPC, tetapi perimeter tidak akan diaktifkan hingga Anda mengambil 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 memberlakukan bahwa resource hanya dapat di-deploy dalam daftar lokasi yang Anda tentukan. |
|
Assured Workloads menyediakan kontrol kepatuhan tambahan yang membantu Anda memenuhi peraturan peraturan tertentu. Blueprint menyediakan variabel opsional dalam pipeline deployment untuk pengaktifan. |
|
Anda mungkin memiliki persyaratan untuk mencatat semua akses ke data atau resource sensitif tertentu. Lakukan evaluasi di mana beban kerja Anda menangani data sensitif yang memerlukan log akses data, serta aktifkan log untuk setiap layanan dan lingkungan yang bekerja dengan data sensitif. |
|
Persetujuan Akses memastikan bahwa Layanan Pelanggan dan engineer Cloud memerlukan persetujuan eksplisit Anda setiap kali mereka perlu mengakses konten pelanggan Anda. Evaluasi proses operasional yang diperlukan untuk meninjau permintaan Persetujuan Akses guna mengurangi kemungkinan keterlambatan dalam menyelesaikan insiden dukungan. |
|
Key Access Justifications 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 terhadap 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 pada 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 mengetahui opsi workstation yang dapat dikonfigurasi di lingkungan Anda sendiri. |
|
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 BeyondCorp Enterprise. Evaluasi pola akses yang Anda percayai untuk akses pengguna ke aplikasi berbasis web seperti konsol sebagai bagian dari 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:
|
Project ID |
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 |
Jika Contoh: |
Akun layanan |
Dengan keterangan:
Contoh:
|
Bucket penyimpanan |
Dengan keterangan:
Contoh:
|
Alternatif untuk rekomendasi default
Praktik terbaik yang direkomendasikan dalam cetak biru mungkin tidak sesuai untuk setiap pelanggan. Anda dapat menyesuaikan rekomendasi apa pun untuk memenuhi kebutuhan spesifik Anda. Tabel berikut memperkenalkan beberapa variasi umum yang mungkin diperlukan berdasarkan technology stack 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 akan memperkenalkan skenario di mana Anda mungkin memilih beberapa organisasi, seperti berikut:
|
Struktur folder: Blueprint memiliki struktur folder
sederhana, dengan workload yang 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 pada node organisasi. |
Anda mungkin memiliki kebijakan keamanan atau cara kerja yang berbeda untuk berbagai bagian bisnis. Dalam skenario ini, terapkan batasan kebijakan organisasi pada 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 Anda, seperti Terraform Enterprise, GitLab Runners, GitHub Actions, atau Jenkins. Cetak biru tersebut berisi arah alternatif untuk setiap produk. |
Repositori kode untuk deployment: Blueprint menggunakan Cloud Source Repositories sebagai repositori Git pribadi yang 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 Anda, konfigurasikan jalur jaringan pribadi dari repositori Anda ke lingkungan Google Cloud Anda. |
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 secara langsung di Cloud Identity. Jika sudah memiliki penyedia identitas, seperti Okta, Ping, atau ID Azure Entra, Anda dapat mengelola akun pengguna di penyedia identitas yang sudah ada dan menyinkronkannya ke Cloud Identity. Jika Anda memiliki persyaratan kedaulatan data atau kepatuhan yang mencegah Anda menggunakan Cloud Identity, dan jika Anda tidak mewajibkan identitas pengguna Google terkelola untuk layanan Google lainnya seperti Google Ads atau Google Marketing Platform, maka Anda dapat lebih memilih federasi identitas tenaga kerja. Dalam skenario ini, perhatikan batasan terkait 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 (disaster recovery). |
Jika memiliki pengguna akhir di lokasi yang lebih banyak secara geografis, Anda dapat mengonfigurasi lebih banyak region Google Cloud untuk membuat resource yang lebih dekat dengan pengguna akhir dengan latensi yang lebih rendah. Jika memiliki batasan kedaulatan data atau kebutuhan ketersediaan Anda dapat terpenuhi di satu region, Anda mungkin hanya mengonfigurasi satu region Google Cloud. |
Alokasi alamat IP: Blueprint menyediakan serangkaian rentang alamat IP. |
Anda mungkin perlu mengubah rentang alamat IP spesifik yang digunakan berdasarkan ketersediaan alamat IP di lingkungan hybrid yang ada. Jika Anda mengubah rentang alamat IP, gunakan cetak biru sebagai panduan untuk jumlah dan ukuran rentang yang diperlukan, dan tinjau rentang alamat IP yang valid untuk Google Cloud. |
Hybrid networking: Blueprint menggunakan Dedicatated Interconnect di beberapa situs fisik dan region Google Cloud untuk mendapatkan bandwidth dan ketersediaan maksimum. |
Bergantung pada persyaratan biaya, bandwidth, dan keandalan Anda, 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 kemudian beralih menggunakan Dedicated Interconnect. Jika Anda belum memiliki lingkungan lokal, Anda mungkin tidak memerlukan jaringan hybrid. |
Perimeter Kontrol Layanan VPC: Cetak biru merekomendasikan satu perimeter yang mencakup semua project layanan yang terkait dengan jaringan VPC terbatas. 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 mendapatkan informasi, lihat memutuskan cara mengurangi pemindahan data yang tidak sah melalui Google API. |
Secret Manager: Blueprint men-deploy project untuk menggunakan Secret Manager di folder |
Jika memiliki satu tim yang bertanggung jawab mengelola dan mengaudit secret sensitif di seluruh organisasi, sebaiknya Anda hanya menggunakan satu project untuk mengelola akses ke secret. Jika mengizinkan tim beban kerja mengelola secret mereka sendiri, Anda mungkin tidak akan menggunakan project terpusat untuk mengelola akses ke secret, dan mengizinkan tim menggunakan instance Secret Manager mereka sendiri dalam project beban kerja. |
Cloud KMS: Blueprint men-deploy project untuk menggunakan Cloud KMS di folder |
Jika memiliki satu tim yang bertanggung jawab mengelola dan mengaudit kunci enkripsi di seluruh organisasi, Anda dapat memilih untuk menggunakan satu project saja untuk mengelola akses ke kunci. Pendekatan terpusat dapat membantu memenuhi persyaratan kepatuhan seperti penanggung jawab utama PCI. Jika mengizinkan tim workload mengelola kuncinya sendiri, Anda mungkin tidak menggunakan project terpusat untuk mengelola akses ke kunci, dan mengizinkan tim menggunakan instance Cloud KMS mereka sendiri dalam project workload. |
Sink log gabungan: Cetak biru mengonfigurasi sekumpulan sink log di node organisasi sehingga tim keamanan pusat dapat meninjau log audit dari seluruh organisasi. |
Anda mungkin memiliki tim 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, serta buat filter sehingga setiap tim hanya menerima log yang diperlukan, atau desain tampilan log untuk kontrol akses terperinci ke bucket log umum. |
Project cakupan pemantauan: Blueprint mengonfigurasi satu project cakupan pemantauan untuk setiap lingkungan. |
Anda dapat mengonfigurasi cakupan project yang lebih terperinci yang dikelola oleh tim yang berbeda, dengan cakupan kumpulan project yang berisi aplikasi yang dikelola oleh setiap tim. |
Perincian pipeline infrastruktur: Blueprint menggunakan model di mana setiap unit bisnis memiliki pipeline infrastruktur terpisah untuk mengelola project workload mereka. |
Anda mungkin lebih memilih pipeline infrastruktur tunggal yang dikelola oleh tim pusat jika Anda memiliki tim pusat yang bertanggung jawab untuk men-deploy semua project dan infrastruktur. Tim pusat ini dapat menerima permintaan pull dari tim workload untuk ditinjau dan disetujui sebelum pembuatan project, atau tim dapat membuat permintaan pull itu sendiri sebagai respons terhadap sistem bertiket. Anda mungkin lebih menyukai pipeline yang lebih terperinci jika tim beban kerja individual memiliki kemampuan untuk menyesuaikan pipeline mereka sendiri dan Anda ingin mendesain akun layanan dengan hak istimewa yang lebih terperinci untuk pipeline. |
Ekspor SIEM:Blueprint mengelola semua temuan keamanan di Security Command Center. |
Tentukan apakah Anda akan mengekspor temuan keamanan dari Security Command Center ke alat seperti Chronicle atau SIEM yang sudah 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. |
Pencarian DNS untuk layanan Google Cloud dari infrastruktur 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 pemilihan rute dari lingkungan lokal ke endpoint Private Service Connect pada tingkat perincian ini jika tidak memerlukan beberapa perimeter Kontrol Layanan VPC. Daripada
memetakan host lokal ke endpoint Private Service Connect berdasarkan
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
- Implementasikan blueprint menggunakan fondasi contoh Terraform di GitHub.
- Pelajari lebih lanjut prinsip-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 melakukan deployment di lingkungan dasar Anda.
Untuk akses ke lingkungan demonstrasi, hubungi kami di security-foundations-blueprint-support@google.com.