Praktik terbaik operasi

Last reviewed 2023-12-20 UTC

Bagian ini memperkenalkan operasi yang harus Anda pertimbangkan saat men-deploy dan mengoperasikan workload 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 dengan hak istimewa berlebih. 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 diautentikasi dengan kunci akun layanan, seperti server lokal yang memerlukan akses ke layanan Google Cloud dan tidak dapat menggunakan federasi identitas beban kerja. 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 data yang tidak sah antara organisasi Google Cloud 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 organisasi Google Cloud, sebaiknya tentukan dengan jelas ancaman yang ditangani oleh struktur perimeter yang lebih kompleks dan jalur akses antar-perimeter yang diperlukan untuk operasi yang diinginkan.

Untuk menerapkan Kontrol Layanan VPC, evaluasi hal berikut:

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 eskalasi 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 Framework Arsitektur Google Cloud: Pengoptimalan Biaya untuk mengelola biaya, termasuk yang 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 akan mencapai 120% dari 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.

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 workload, 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 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 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 memungkinkan, Anda dapat menghindari duplikasi dengan mempertahankan log dan temuan Google Cloud hanya di Google Cloud. Dalam skenario ini, pastikan tim yang ada memiliki akses dan pelatihan yang tepat untuk menangani log dan temuan 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 serangkaian batasan kebijakan organisasi yang direkomendasikan pada layanan Google 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 IAM dan konfigurasi 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 berubah 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 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 terpusat Cloud KMS yang berada 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 CICD 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 dana@example.com untuk penggunaan sehari-hari dan admin-dana@example.com 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 mengganggu satu sama lain.
  • 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 selanjutnya