Praktik terbaik operasi

Last reviewed 2025-05-15 UTC

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

Memperbarui resource dasar

Meskipun cetak biru memberikan titik awal yang telah ditentukan untuk lingkungan fondasi Anda, persyaratan fondasi Anda dapat berkembang seiring waktu. Setelah deployment awal, Anda dapat menyesuaikan setelan konfigurasi atau membuat layanan bersama baru yang akan digunakan oleh semua workload.

Untuk mengubah resource dasar, sebaiknya lakukan semua perubahan melalui pipeline dasar. Tinjau strategi percabangan untuk mengetahui pengantar alur penulisan kode, penggabungannya, dan pemicuan pipeline deployment.

Menentukan atribut untuk project workload baru

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

• API Google Cloud yang akan diaktifkan
• VPC Bersama mana yang akan digunakan, atau apakah akan membuat jaringan VPC baru
• Peran IAM mana 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 dituju 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 Anda juga menggunakan pemberi rekomendasi IAM untuk mengidentifikasi kebijakan yang mengizinkan pemberian peran dengan hak istimewa berlebih. Rancang proses untuk meninjau rekomendasi secara berkala atau menerapkan rekomendasi secara otomatis ke dalam pipeline deployment Anda.

Mengoordinasikan 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 dituju antar-komponen beban kerja, 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 workload 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 kepada tim beban kerja.

Mengoptimalkan lingkungan Anda dengan portofolio Active Assist

Selain pemberi rekomendasi IAM, Google Cloud menyediakan portofolio layanan Active Assist untuk memberikan 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.

Rancang 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 harus menjadi tanggung jawab pemilik workload, lalu terapkan peran IAM untuk mengakses rekomendasi tersebut.

Memberikan pengecualian pada kebijakan organisasi

Blueprint ini 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 merupakan kontrol keamanan yang penting karena kunci akun layanan yang bocor dapat menimbulkan dampak negatif yang signifikan, dan sebagian besar skenario harus menggunakan alternatif yang lebih aman untuk kunci akun layanan guna melakukan autentikasi. Namun, mungkin ada kasus penggunaan yang hanya dapat diautentikasi dengan kunci akun layanan, seperti server lokal yang memerlukan akses ke layanan dan tidak dapat menggunakan Workload Identity Federation.Google Cloud 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 bagi beban kerja untuk meminta pengecualian terhadap kebijakan, dan memastikan bahwa pengambil keputusan yang bertanggung jawab untuk memberikan pengecualian memiliki pengetahuan teknis untuk memvalidasi kasus penggunaan dan berkonsultasi tentang apakah kontrol tambahan harus diterapkan untuk mengompensasi. Saat Anda memberikan pengecualian pada workload, ubah batasan kebijakan organisasi sesempit mungkin. Anda juga dapat menambahkan batasan secara kondisional ke kebijakan organisasi dengan menentukan tag yang memberikan pengecualian atau penerapan untuk kebijakan, lalu menerapkan tag ke project dan folder.

Melindungi resource Anda dengan Kontrol Layanan VPC

Blueprint ini membantu menyiapkan lingkungan Anda untuk Kontrol Layanan VPC dengan menerapkan konfigurasi prasyarat seperti VIP terbatas. Namun, cetak biru awalnya men-deploy Kontrol Layanan VPC hanya dalam mode uji coba karena beralih ke mode diterapkan dapat menjadi proses yang mengganggu dan memerlukan perencanaan yang unik untuk organisasi Anda.

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

Perimeter Kontrol Layanan VPC ditujukan untuk kontrol eksfiltrasi antara organisasi Anda dan sumber eksternal. Google Cloud Perimeter tidak dimaksudkan untuk menggantikan atau menduplikasi kebijakan izin untuk kontrol akses terperinci ke project atau resource individual. Saat Anda mendesain dan membangun perimeter, sebaiknya gunakan perimeter terpadu umum untuk mengurangi beban pengelolaan.

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

Untuk menerapkan Kontrol Layanan VPC, evaluasi hal berikut:

• Kasus penggunaan mana yang memerlukan Kontrol Layanan VPC.
• Apakah Google Cloud layanan yang diperlukan mendukung Kontrol Layanan VPC.
• Cara mengonfigurasi akses breakglass untuk mengubah perimeter jika hal itu mengganggu pipeline otomatisasi Anda.
• Cara menggunakan praktik terbaik untuk mengaktifkan Kontrol Layanan VPC guna mendesain dan menerapkan perimeter Anda.

Setelah Anda mengubah perimeter dari mode uji coba ke mode diterapkan, sebaiknya rancang proses untuk menambahkan project baru secara konsisten ke perimeter yang benar, dan proses untuk merancang pengecualian saat developer memiliki kasus penggunaan baru yang ditolak oleh konfigurasi perimeter Anda saat ini.

Menguji perubahan di seluruh organisasi dalam organisasi terpisah

Sebaiknya Anda tidak pernah men-deploy perubahan ke produksi tanpa melakukan 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 dan Cloud Identity, pertimbangkan untuk membuat organisasi terpisah untuk tujuan pengujian.

Mengontrol akses jarak jauh ke mesin virtual

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

Untuk skenario yang memerlukan akses jarak jauh, sebaiknya Anda mengelola akses pengguna menggunakan Login OS jika memungkinkan. Pendekatan ini menggunakan layanan terkelola untuk menerapkan kontrol akses, pengelolaan siklus proses akun, verifikasi 2 langkah, dan audit logging. Google Cloud Atau, jika Anda harus mengizinkan akses melalui kunci SSH di 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 eskalasi hak istimewa, jadi Anda harus merancang 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 berlebih dengan merencanakan pemberitahuan anggaran

Cetak biru ini menerapkan praktik terbaik yang diperkenalkan dalam Google Cloud Well-Architected Framework: 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 antar-pusat biaya.

• Tetapkan anggaran dan nilai minimum pemberitahuan.

Anda bertanggung jawab untuk merencanakan anggaran dan mengonfigurasi pemberitahuan penagihan. Blueprint membuat pemberitahuan anggaran untuk project beban kerja saat perkiraan pembelanjaan akan mencapai 120% dari anggaran. Pendekatan ini memungkinkan tim pusat mengidentifikasi dan memitigasi insiden pembelanjaan berlebih yang signifikan. Peningkatan pembelanjaan yang signifikan dan tidak terduga 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 Billing category of Essential Contacts. Pemberitahuan anggaran terkait dengan penggunaan anggaran yang Anda tentukan untuk setiap project. Notifikasi penagihan dari Kontak Penting terkait dengan pembaruan harga, kesalahan, dan kredit.

Bergantung pada kasus penggunaan, Anda dapat menetapkan anggaran berdasarkan biaya seluruh folder lingkungan, atau semua project yang terkait dengan pusat biaya tertentu, daripada menetapkan anggaran terperinci untuk setiap project. Sebaiknya Anda juga mendelegasikan setelan anggaran dan pemberitahuan kepada pemilik beban kerja yang dapat menetapkan nilai minimum pemberitahuan yang lebih terperinci untuk pemantauan sehari-hari.

Untuk panduan tentang pengoptimalan biaya, lihat Mengoptimalkan biaya dengan hub FinOps.

Mengalokasikan biaya di antara pusat biaya internal

Konsol ini memungkinkan Anda melihat laporan penagihan untuk melihat dan memperkirakan biaya dalam berbagai 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 menurut 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 memasukkan data yang diperoleh dari kueri ini ke dalam proses internal Anda.

Menyerap 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 mengagregasi 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 Anda, 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 terlalu tinggi, Anda dapat menghindari duplikasi dengan menyimpan log dan temuan hanya diGoogle Cloud. Google Cloud Dalam skenario ini, pastikan tim yang sudah ada memiliki akses dan pelatihan yang tepat untuk menangani log dan temuan secara langsung diGoogle Cloud.

• Untuk log audit, rancang tampilan log untuk memberikan akses ke subset log di bucket log terpusat Anda kepada masing-masing tim, bukan menduplikasi log ke beberapa bucket yang 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 mengembangkan pustaka kontrol Anda

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

Kontrol kebijakan yang diterapkan oleh cetak biru	Panduan untuk memperluas kontrol ini
Security Command Center mendeteksi kerentanan dan ancaman dari berbagai sumber keamanan.	Tentukan modul kustom untuk Security Health Analytics dan modul kustom untuk Event Threat Detection.
Layanan Kebijakan Organisasi menerapkan serangkaian 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 dasar untuk konfigurasi yang dapat diterima sebelum deployment.	Kembangkan batasan tambahan berdasarkan panduan di GoogleCloudPlatform/policy-library.
Pemberitahuan pada metrik berbasis log dan metrik performa mengonfigurasi metrik berbasis log untuk memberikan pemberitahuan tentang perubahan pada kebijakan IAM dan konfigurasi beberapa resource sensitif.	Rancang metrik berbasis log dan kebijakan pemberitahuan tambahan untuk peristiwa log yang menurut Anda seharusnya tidak terjadi di lingkungan Anda.
Solusi kustom untuk analisis log otomatis secara rutin mengkueri log untuk menemukan aktivitas mencurigakan dan membuat temuan Security Command Center.	Tulis kueri tambahan untuk membuat temuan bagi peristiwa keamanan yang ingin Anda pantau, menggunakan analisis log keamanan sebagai referensi.
Solusi kustom untuk merespons perubahan aset membuat temuan Security Command Center dan dapat mengotomatiskan tindakan perbaikan.	Buat feed Inventaris Aset Cloud tambahan untuk memantau perubahan jenis aset tertentu dan tulis fungsi Cloud Run tambahan dengan logika kustom untuk merespons pelanggaran kebijakan.

Kontrol ini dapat berkembang seiring perubahan persyaratan dan kematangan Anda di 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 Anda untuk data dalam penyimpanan. Sebaiknya Anda mengevaluasi apakah enkripsi default sudah cukup, atau apakah Anda memiliki persyaratan kepatuhan yang mengharuskan Anda menggunakan Cloud KMS untuk mengelola kunci sendiri. Untuk mengetahui 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 yang terpusat di bawah kendali 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 kepada 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 memastikan bahwa jenis resource tertentu selalu memerlukan kunci CMEK dan hanya kunci CMEK dari daftar yang diizinkan dari project tepercaya yang dapat digunakan.

Menyimpan dan mengaudit kredensial aplikasi dengan Secret Manager

Sebaiknya Anda tidak pernah melakukan commit rahasia sensitif (seperti kunci API, sandi, dan sertifikat pribadi) ke repositori kode sumber. Sebagai gantinya, lakukan 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 tertentu, bukan ke semua secret dalam project.

Jika memungkinkan, Anda harus membuat secret produksi secara otomatis dalam pipeline CI/CD dan menjaganya agar 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.

Cetak biru 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 rahasia 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 sebaiknya perubahan pada resource fondasi dikelola melalui IaC yang dikontrol versi dan di-deploy oleh pipeline fondasi, Anda mungkin memiliki skenario darurat atau pengecualian yang memerlukan akses istimewa untuk mengubah lingkungan Anda secara langsung. Sebaiknya Anda merencanakan akun breakglass (terkadang disebut akun firecall atau darurat) yang memiliki akses dengan hak istimewa tinggi ke lingkungan Anda jika terjadi keadaan darurat atau saat proses otomatisasi gagal.

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 dalam organisasi.
Pipeline fondasi administrator	Akses darurat untuk mengubah resource di project CICD Anda diGoogle Cloud dan repositori Git eksternal jika otomatisasi pipeline dasar rusak.
Operasi atau SRE	Tim operasi atau SRE memerlukan akses istimewa untuk merespons gangguan atau insiden. Hal ini dapat mencakup tugas seperti memulai ulang VM atau memulihkan data.

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

• Gunakan alat yang sudah ada untuk pengelolaan akses istimewa guna menambahkan pengguna sementara ke grup yang telah ditentukan sebelumnya dengan peran IAM yang sangat istimewa atau gunakan kredensial akun yang sangat istimewa.
• Menyediakan akun terlebih dahulu yang 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 istimewa tepat waktu yang memungkinkan developer melakukan eskalasi sendiri ke peran yang lebih istimewa.

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

• Bagaimana Anda merancang cakupan dan perincian akses breakglass? Misalnya, Anda dapat mendesain mekanisme breakglass yang berbeda untuk unit bisnis yang berbeda guna memastikan bahwa unit bisnis tersebut tidak dapat mengganggu satu sama lain.
• Bagaimana mekanisme Anda mencegah penyalahgunaan? Apakah Anda memerlukan persetujuan? Misalnya, Anda mungkin memiliki operasi terpisah di mana satu orang memegang kredensial dan satu orang memegang token MFA.
• Bagaimana cara mengaudit dan memberikan pemberitahuan terkait akses breakglass? Misalnya, Anda dapat mengonfigurasi modul Event Threat Detection kustom untuk membuat temuan keamanan saat akun darurat 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 rancang alur kerja otomatis yang memungkinkan pengguna melakukan operasi tanpa memerlukan eskalasi hak istimewa untuk identitas penggunanya. Pendekatan ini dapat membantu mengurangi kesalahan manusia dan meningkatkan keamanan.

Untuk sistem yang memerlukan intervensi rutin, mengotomatiskan perbaikan mungkin merupakan solusi terbaik. Google mendorong pelanggan untuk menerapkan pendekatan produksi tanpa sentuhan guna melakukan semua perubahan produksi menggunakan otomatisasi, proxy yang aman, atau breakglass yang diaudit. Google menyediakan buku SRE bagi pelanggan yang ingin menerapkan pendekatan SRE Google.

Langkah berikutnya

• Baca Deploy cetak biru (dokumen berikutnya dalam rangkaian ini).