Dokumen ini memberikan rekomendasi untuk membantu Anda mempertahankan akses berkelanjutan ke resource Google Cloud . Kelangsungan bisnis bertujuan untuk memastikan bahwa organisasi Anda dapat mempertahankan operasi penting, bahkan selama gangguan seperti pemadaman atau bencana. Tujuan ini mencakup akses karyawan yang berkelanjutan saat layanan dan infrastruktur penting tidak tersedia.
Dokumen ini ditujukan untuk profesional keamanan atau keandalan yang bertanggung jawab atas Identity and Access Management (IAM) dan pemeliharaan akses aman ke Google Cloud. Dokumen ini mengasumsikan bahwa Anda sudah memahami Cloud Identity, Google Workspace, dan pengelolaan IAM.
Untuk membantu Anda bersiap menghadapi pemadaman dan memastikan akses berkelanjutan, dokumen ini menguraikan langkah-langkah yang direkomendasikan berikut yang dapat Anda terapkan. Anda dapat memilih untuk melakukan semua atau beberapa langkah ini, tetapi sebaiknya terapkan langkah-langkah tersebut dalam urutan berikut.
Menyiapkan akses darurat: Mengaktifkan akses terakhir ke Google Cloud resource.
Sebaiknya siapkan akses darurat untuk semua Google Cloud organisasi Anda, terlepas dari persyaratan kelangsungan bisnis masing-masing.
Menyediakan alternatif autentikasi untuk pengguna penting: Jika organisasi Anda menggunakan single sign-on (SSO), gangguan apa pun yang memengaruhi penyedia identitas (IdP) eksternal Anda dapat memengaruhi kemampuan karyawan untuk melakukan autentikasi dan menggunakan Google Cloud.
Untuk mengurangi dampak keseluruhan gangguan IdP pada organisasi Anda, berikan alternatif autentikasi bagi pengguna yang penting bagi bisnis agar dapat terus mengakses Google Cloud resource.
Menggunakan IdP cadangan: Untuk memungkinkan semua pengguna mengakses Google Cloud resource selama gangguan IdP, Anda dapat mempertahankan IdP pengganti.
IdP pengganti dapat membantu meminimalkan dampak gangguan lebih lanjut, tetapi opsi ini mungkin tidak hemat biaya untuk setiap organisasi.
Bagian berikut menjelaskan langkah-langkah dan praktik terbaik yang direkomendasikan ini.
Menyiapkan akses darurat
Tujuan akses darurat adalah untuk mengaktifkan akses terakhir ke Google Cloud resource dan mencegah situasi saat Anda mungkin kehilangan akses sepenuhnya.
Pengguna akses darurat dicirikan oleh properti berikut:
- Mereka adalah pengguna yang Anda buat di akun Cloud Identity atau Google Workspace Anda.
- Mereka memiliki hak istimewa admin super, yang memberi pengguna akses yang memadai untuk mengatasi kesalahan konfigurasi apa pun yang memengaruhi Cloud Identity, Google Workspace, atau Google Cloud resource Anda.
- Mereka tidak terkait dengan karyawan tertentu di organisasi dan dikecualikan dari siklus proses Joiner, Mover, dan Leaver (JML) akun pengguna reguler.
- Mereka dikecualikan dari SSO.
Bagian berikut menjelaskan praktik terbaik yang direkomendasikan untuk diikuti saat Anda mengelola dan mengamankan pengguna akses darurat.
Membuat pengguna akses darurat untuk setiap lingkungan
Untuk Google Cloud lingkungan yang menghosting workload produksi, akses darurat sangat penting. Untuk Google Cloud lingkungan yang digunakan untuk tujuan pengujian atau staging, hilangnya akses masih dapat mengganggu.
Untuk memastikan akses berkelanjutan ke semualingkungan Anda, Google Cloud buat dan pertahankan pengguna akses darurat di Cloud Identity atau Google Workspace untuk setiap lingkungan.
Memastikan redundansi akses darurat
Satu pengguna akses darurat adalah satu titik kegagalan. Dalam skenario ini, kunci keamanan yang rusak, sandi yang hilang, atau penangguhan akun dapat mengganggu akses ke akun. Untuk mengurangi risiko ini, Anda dapat membuat lebih dari satu pengguna akses darurat untuk setiap akun Cloud Identity atau Google Workspace.
Pengguna akses darurat memiliki hak istimewa yang tinggi, jadi jangan buat terlalu banyak. Untuk sebagian besar organisasi, sebaiknya buat minimal dua dan maksimal lima pengguna akses darurat untuk setiap akun Cloud Identity atau Google Workspace.
Menggunakan unit organisasi terpisah untuk pengguna akses darurat
Pengguna akses darurat memerlukan konfigurasi khusus dan tidak tunduk pada siklus proses JML yang mungkin Anda ikuti untuk akun pengguna lain.
Untuk memisahkan pengguna akses darurat dari akun pengguna reguler, gunakan unit organisasi (OU) khusus untuk pengguna akses darurat. OU terpisah memungkinkan Anda menerapkan konfigurasi kustom hanya untuk pengguna darurat.
Menggunakan kunci keamanan FIDO untuk verifikasi 2 langkah
Gunakan kunci keamanan Fast IDentity Online (FIDO) untuk verifikasi 2 langkah.
Karena pengguna akses darurat adalah pengguna dengan hak istimewa tinggi di akun Cloud Identity atau Google Workspace Anda, Anda harus melindungi pengguna ini dengan menggunakan verifikasi 2 langkah.
Di antara metode verifikasi 2 langkah yang didukung Cloud Identity dan Google Workspace, sebaiknya gunakan kunci keamanan FIDO. Metode ini memberikan perlindungan terhadap phishing dan keamanan yang kuat. Untuk memastikan bahwa semua pengguna akses darurat Anda menggunakan kunci keamanan FIDO untuk verifikasi 2 langkah, lakukan hal berikut:
- Di OU yang berisi pengguna akses darurat Anda, konfigurasikan verifikasi 2 langkah untuk hanya mengizinkan kunci keamanan sebagai metode autentikasi.
- Untuk semua pengguna akses darurat, aktifkan verifikasi 2 langkah.
- Untuk setiap pengguna akses darurat, daftarkan dua atau lebih kunci keamanan FIDO.
Saat Anda mendaftarkan beberapa kunci untuk setiap pengguna, Anda membantu mengurangi risiko kehilangan akses karena kunci keamanan yang rusak. Anda juga meningkatkan kemungkinan pengguna dapat mengakses setidaknya satu kunci dalam keadaan darurat.
Anda dapat menggunakan kumpulan kunci keamanan yang sama untuk beberapa pengguna akses darurat. Namun, sebaiknya gunakan kunci keamanan yang berbeda untuk setiap pengguna akses darurat.
Menggunakan kontrol keamanan fisik untuk melindungi kredensial dan kunci keamanan
Saat menyimpan kredensial dan kunci keamanan pengguna akses darurat, Anda harus menyeimbangkan perlindungan yang kuat dengan ketersediaan selama keadaan darurat:
- Mencegah personel yang tidak berwenang mengakses kredensial pengguna akses darurat. Pengguna akses darurat hanya boleh menggunakan kredensial ini dalam keadaan darurat.
- Memastikan bahwa personel yang berwenang dapat mengakses kredensial dengan penundaan minimal selama keadaan darurat.
Sebaiknya jangan mengandalkan pengelola sandi berbasis software. Sebaliknya, sebaiknya andalkan kontrol keamanan fisik untuk melindungi kredensial dan kunci keamanan pengguna akses darurat.
Saat memilih kontrol keamanan fisik yang akan diterapkan, pertimbangkan hal berikut:
- Meningkatkan ketersediaan:
- Simpan salinan sandi di beberapa lokasi fisik, seperti di beberapa brankas keamanan di kantor yang berbeda.
- Daftarkan beberapa kunci keamanan untuk setiap pengguna akses darurat, dan simpan satu kunci di setiap lokasi kantor yang relevan.
- Meningkatkan keamanan: Simpan sandi dan kunci keamanan di lokasi yang berbeda.
Menghindari otomatisasi untuk rotasi sandi
Mungkin akan bermanfaat untuk mengotomatiskan rotasi sandi bagi pengguna akses darurat. Namun, otomatisasi ini dapat meningkatkan risiko kompromi keamanan. Pengguna akses darurat memiliki hak istimewa admin super. Untuk merotasi sandi pengguna admin super, alat atau skrip otomatisasi juga harus memiliki hak istimewa admin super. Persyaratan ini dapat menyebabkan alat menjadi target yang menarik bagi penyerang.
Untuk memastikan Anda tidak melemahkan postur keamanan secara keseluruhan, jangan gunakan otomatisasi untuk merotasi sandi.
Menggunakan sandi yang kuat
Untuk membantu melindungi pengguna akses darurat, pastikan mereka menggunakan sandi yang panjang dan kuat. Untuk menerapkan tingkat kompleksitas sandi minimum, gunakan OU khusus seperti yang dijelaskan sebelumnya, dan terapkan persyaratan sandi.
Kecuali jika Anda merotasi sandi secara manual, nonaktifkan masa berlaku sandi untuk semua pengguna akses darurat.
Mengecualikan pengguna akses darurat dari kebijakan akses
Selama keadaan darurat, kebijakan akses kontekstual dapat menyebabkan situasi saat pengguna akses darurat pun tidak dapat mengakses resource tertentu. Untuk mengurangi risiko ini, kecualikan setidaknya satu pengguna akses darurat dari semua tingkat akses dalam kebijakan akses Anda.
Pengecualian ini membantu Anda memastikan bahwa setidaknya salah satu pengguna akses darurat Anda memiliki akses berkelanjutan ke resource. Jika terjadi keadaan darurat atau kebijakan akses kontekstual yang salah konfigurasi, pengguna akses darurat ini dapat mempertahankan aksesnya.
Menyiapkan pemberitahuan untuk peristiwa pengguna akses darurat
Aktivitas pengguna akses darurat di luar peristiwa darurat kemungkinan menunjukkan perilaku mencurigakan. Untuk mendapatkan notifikasi tentang peristiwa apa pun yang terkait dengan aktivitas dari pengguna akses darurat, buat aturan pelaporan di konsol Google Admin. Saat membuat aturan pelaporan, Anda dapat menetapkan kondisi seperti berikut:
- Sumber data: Peristiwa log pengguna.
Atribut di tab Pembuat kondisi: Gunakan atribut dan operator untuk membuat filter bagi OU yang berisi pengguna akses darurat dan peristiwa Anda.
Misalnya, Anda dapat menetapkan atribut dan operator untuk membuat filter yang mirip dengan pernyataan bersyarat berikut:
Actor organizational unit Is /Privileged AND (Event Is Successful login OR Event Is Failed login OR Event Is Account password change)Nilai minimum: Setiap 1 jam jika jumlah > 0
Tindakan: Kirim notifikasi email
Penerima email: Pilih grup yang berisi anggota tim keamanan Anda yang relevan
Menyediakan alternatif autentikasi untuk pengguna penting
Jika organisasi Anda menggunakan SSO untuk mengizinkan karyawan melakukan autentikasi ke layanan Google, ketersediaan IdP pihak ketiga Anda akan menjadi penting. Gangguan apa pun pada IdP Anda dapat mencegah karyawan mengakses alat dan resource penting.
Meskipun akses darurat membantu Anda memastikan akses administratif berkelanjutan, akses darurat tidak mengatasi kebutuhan karyawan selama pemadaman IdP.
Untuk mengurangi potensi efek gangguan IdP, Anda dapat mengonfigurasi akun Cloud Identity atau Google Workspace Anda untuk menggunakan penggantian autentikasi bagi pengguna penting. Anda dapat menggunakan rencana penggantian berikut:
- Selama operasi normal, Anda mengizinkan pengguna melakukan autentikasi menggunakan SSO.
- Selama pemadaman IdP, Anda akan menonaktifkan SSO secara selektif untuk pengguna penting ini dan mengizinkan mereka melakukan autentikasi menggunakan kredensial login Google, yang Anda sediakan terlebih dahulu.
Bagian berikut menjelaskan praktik terbaik yang direkomendasikan saat Anda mengizinkan pengguna penting melakukan autentikasi selama pemadaman IdP eksternal.
Berfokus pada pengguna dengan hak istimewa
Agar pengguna penting dapat melakukan autentikasi selama pemadaman IdP, pengguna harus memiliki kredensial login Google yang valid seperti berikut:
- Sandi dengan kunci keamanan untuk autentikasi faktor kedua.
- Kunci sandi.
Saat Anda menyediakan kredensial login Google untuk pengguna yang biasanya menggunakan SSO, Anda mungkin meningkatkan overhead operasional dan gesekan pengguna dengan cara berikut:
- Anda mungkin tidak dapat menyinkronkan sandi pengguna secara otomatis, bergantung pada IdP Anda. Oleh karena itu, Anda mungkin harus meminta pengguna untuk menetapkan sandi secara manual.
- Anda mungkin perlu meminta pengguna untuk mendaftarkan kunci sandi atau mendaftar ke verifikasi 2 langkah. Langkah ini biasanya tidak diperlukan untuk pengguna SSO.
Untuk menyeimbangkan manfaat akses tanpa gangguan ke layanan Google dengan overhead tambahan, fokuslah pada pengguna dengan hak istimewa dan yang penting bagi bisnis. Pengguna ini lebih cenderung mendapatkan manfaat signifikan dari akses tanpa gangguan, dan mungkin hanya sebagian kecil dari basis pengguna Anda secara keseluruhan.
Menggunakan kesempatan untuk mengaktifkan verifikasi pasca-SSO
Saat Anda menyediakan autentikasi alternatif untuk pengguna dengan hak istimewa, hasil yang tidak diinginkan mungkin adalah overhead tambahan. Untuk membantu mengimbangi overhead ini, Anda juga dapat mengaktifkan verifikasi pasca-SSO untuk pengguna ini.
Secara default, saat Anda menyiapkan SSO untuk pengguna, mereka tidak diwajibkan untuk melakukan verifikasi 2 langkah. Meskipun praktik ini nyaman, jika IdP disusupi, pengguna mana pun yang tidak mengaktifkan verifikasi pasca-SSO dapat menjadi target serangan pemalsuan kredensial.
Verifikasi pasca-SSO membantu Anda mengurangi potensi efek kompromi IdP karena pengguna harus melakukan verifikasi 2 langkah setelah setiap upaya SSO. Jika Anda menyediakan kredensial login Google untuk pengguna dengan hak istimewa, verifikasi pasca-SSO dapat membantu meningkatkan postur keamanan akun pengguna ini tanpa overhead tambahan.
Menggunakan OU terpisah untuk pengguna dengan hak istimewa
Pengguna dengan hak istimewa yang dapat melakukan autentikasi selama pemadaman IdP eksternal memerlukan konfigurasi khusus. Konfigurasi ini berbeda dengan konfigurasi untuk pengguna reguler dan untuk pengguna akses darurat.
Untuk membantu Anda memisahkan pengguna dengan hak istimewa dari akun pengguna lainnya, gunakan OU khusus untuk pengguna dengan hak istimewa. OU terpisah ini membantu Anda menerapkan kebijakan kustom seperti verifikasi pasca-SSO hanya untuk pengguna dengan hak istimewa ini.
OU terpisah juga membantu Anda menonaktifkan SSO secara selektif untuk pengguna dengan hak istimewa selama pemadaman IdP. Untuk menonaktifkan SSO untuk OU, Anda dapat mengubah penetapan profil SSO.
Menggunakan IdP cadangan
Saat Anda menyediakan alternatif autentikasi untuk pengguna penting selama pemadaman IdP, Anda membantu mengurangi efek pemadaman IdP tersebut pada organisasi Anda. Namun, strategi mitigasi ini mungkin tidak cukup untuk mempertahankan kapasitas operasional penuh. Banyak pengguna mungkin masih tidak dapat mengakses aplikasi dan layanan penting.
Untuk mengurangi lebih lanjut potensi efek pemadaman IdP, Anda dapat melakukan failover ke IdP cadangan. Anda dapat menggunakan rencana cadangan berikut:
- Selama operasi normal, Anda mengizinkan pengguna melakukan autentikasi menggunakan SSO dan IdP utama Anda.
- Selama pemadaman IdP, Anda mengubah konfigurasi SSO akun Cloud Identity atau Google Workspace Anda untuk beralih ke IdP cadangan.
IdP cadangan tidak harus berasal dari vendor yang sama. Saat membuat IdP cadangan, gunakan konfigurasi yang cocok dengan konfigurasi IdP utama Anda. Untuk memastikan bahwa IdP cadangan memungkinkan semua pengguna Anda melakukan autentikasi dan mengakses layanan Google, IdP cadangan harus menggunakan salinan terbaru dari basis pengguna IdP utama.
IdP cadangan dapat membantu menyediakan akses darurat yang komprehensif. Namun, Anda harus menimbang keunggulan ini dengan risiko tambahan yang mungkin ditimbulkan oleh IdP cadangan. Potensi risiko ini mencakup hal berikut:
- Jika IdP cadangan memiliki keamanan yang lebih lemah daripada IdP utama, postur keamanan lingkungan Anda secara keseluruhan mungkin juga lebih lemah selama failover. Google Cloud
- Jika IdP utama dan IdP cadangan berbeda dalam cara menerbitkan pernyataan SAML, IdP dapat menempatkan pengguna pada risiko serangan spoofing.
Bagian berikut menjelaskan praktik terbaik yang direkomendasikan saat Anda menggunakan IdP cadangan untuk akses darurat.
Membuat profil SAML terpisah untuk IdP cadangan
Cloud Identity dan Google Workspace memungkinkan Anda membuat beberapa profil SAML. Setiap profil SAML dapat merujuk ke IdP SAML yang berbeda.
Untuk meminimalkan jumlah pekerjaan yang diperlukan untuk melakukan failover ke IdP cadangan, siapkan profil SAML untuk IdP cadangan terlebih dahulu:
- Buat profil SAML terpisah untuk IdP utama dan untuk IdP cadangan Anda.
- Konfigurasikan penetapan profil SSO untuk menetapkan hanya profil SAML IdP utama selama operasi normal.
- Ubah penetapan profil SSO untuk menggunakan profil SAML IdP cadangan selama pemadaman IdP. Jangan ubah setelan profil SAML individual.
Menggunakan IdP lokal yang ada
Anda tidak perlu menyediakan IdP tambahan untuk berfungsi sebagai cadangan. Sebagai gantinya, periksa apakah Anda dapat menggunakan IdP lokal yang ada untuk tujuan ini. Misalnya, organisasi Anda mungkin menggunakan Active Directory sebagai sumber tepercaya untuk identitas, dan mungkin juga menggunakan Active Directory Federation Services (AD FS) untuk SSO. Dalam skenario ini, Anda mungkin dapat menggunakan AD FS sebagai IdP cadangan.
Pendekatan penggunaan kembali ini dapat membantu Anda membatasi biaya dan overhead pemeliharaan.
Menyiapkan IdP cadangan untuk menangani beban yang diperlukan
Saat Anda mengalihkan autentikasi ke IdP cadangan, IdP tersebut harus menangani semua permintaan autentikasi yang biasanya ditangani oleh IdP utama Anda.
Saat Anda men-deploy dan menentukan ukuran IdP cadangan, ingatlah bahwa jumlah permintaan yang diharapkan bergantung pada faktor-faktor berikut:
- Jumlah pengguna di akun Cloud Identity atau Google Workspace Anda.
- Durasi sesi yang dikonfigurasi Google Cloud .
Misalnya, jika durasi sesi antara 8 dan 24 jam, permintaan autentikasi mungkin melonjak pada pagi hari saat karyawan memulai hari kerja mereka.
Menguji prosedur failover secara berkala
Untuk membantu memastikan bahwa proses failover SSO berfungsi dengan andal, Anda harus memverifikasi proses tersebut secara berkala. Saat Anda menguji prosedur failover, lakukan hal berikut:
- Ubah penetapan profil SSO satu atau beberapa OU atau grup secara manual untuk menggunakan IdP cadangan.
- Pastikan SSO dengan IdP cadangan berfungsi seperti yang diharapkan.
- Pastikan sertifikat penandatanganan sudah yang terbaru.
Langkah berikutnya
- Tinjau praktik terbaik keamanan untuk akun administrator.
- Pelajari lebih lanjut tentang praktik terbaik untuk menggabungkan Google Cloud dengan penyedia identitas eksternal.
- Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.
Kontributor
Penulis: Johannes Passing | Cloud Solutions Architect
Kontributor lainnya: Ido Flatow | Cloud Solutions Architect