SEC03-BP03 Menerapkan proses akses darurat

Anda telah menentukan dan mendokumentasikan mode kegagalan yang terhitung sebagai sebuah keadaan darurat: pertimbangkan keadaan normal Anda dan sistem yang diandalkan oleh para pengguna untuk mengelola beban kerja mereka. Pertimbangkan bagaimana masing-masing dependensi ini dapat gagal dan menyebabkan terjadinya sebuah keadaan darurat. Anda mungkin akan menemukan pertanyaan dan praktik-praktik terbaik dalam Pilar Keandalan yang berguna untuk mengidentifikasi mode kegagalan dan merancang arsitektur sistem yang lebih tangguh untuk meminimalkan kemungkinan terjadinya kegagalan.

Anda telah mendokumentasikan langkah-langkah yang harus diikuti untuk mengonfirmasi bahwa kegagalan dianggap sebagai keadaan darurat. Misalnya, Anda dapat meminta administrator identitas Anda untuk memeriksa status penyedia identitas utama dan siaga Anda dan, jika keduanya tidak tersedia, maka Anda harus mengumumkan peristiwa darurat untuk kegagalan penyedia identitas.

Anda telah menentukan sebuah proses akses darurat khusus untuk masing-masing jenis mode darurat atau kegagalan. Pengkhususan ini dapat mengurangi godaan di pihak pengguna Anda untuk terlalu sering menggunakan sebuah proses umum untuk semua jenis keadaan darurat. Proses akses darurat Anda menggambarkan keadaan di mana masing-masing proses harus digunakan dan, sebaliknya, situasi di mana proses tidak boleh digunakan dan menunjuk ke proses alternatif yang mungkin berlaku.

Proses Anda didokumentasikan dengan baik dengan instruksi yang mendetail dan playbook yang dapat diikuti dengan cepat dan dengan efisien. Ingatlah bahwa sebuah peristiwa darurat dapat menjadi saat-saat yang memusingkan bagi para pengguna Anda dan mereka sedang berada di bawah tekanan waktu yang ekstrem, jadi buatlah desain proses yang sesederhana mungkin.

Anda tidak memiliki proses akses darurat yang didokumentasikan dengan baik dan teruji dengan baik. Pengguna Anda tidak siap untuk menghadapi sebuah keadaan darurat dan mengikuti proses yang diimprovisasi ketika ada sebuah peristiwa darurat yang muncul.

Proses akses darurat Anda bergantung pada sistem yang sama (seperti penyedia identitas tersentralisasi) dengan mekanisme akses normal Anda. Ini artinya, kegagalan sistem tersebut dapat memengaruhi mekanisme akses normal dan darurat Anda dan akan mengganggu kemampuan Anda untuk pulih dari kegagalan tersebut.

Proses akses darurat Anda digunakan dalam situasi yang tidak darurat. Misalnya, pengguna Anda sering kali menyalahgunakan proses akses darurat karena mereka merasa lebih mudah melakukan perubahan secara langsung daripada mengirimkan perubahan melalui sebuah pipeline.

Proses akses darurat Anda tidak menghasilkan log yang memadai untuk mengaudit proses tersebut, atau log tersebut tidak dipantau untuk mendapatkan peringatan mengenai adanya potensi penyalahgunaan proses.

Dengan memiliki proses akses darurat yang didokumentasikan dengan baik dan teruji dengan baik, Anda dapat mengurangi waktu yang dibutuhkan pengguna untuk merespons dan menyelesaikan sebuah peristiwa darurat. Hal ini dapat menghasilkan lebih sedikit waktu henti dan ketersediaan yang lebih tinggi untuk layanan-layanan yang Anda berikan kepada pelanggan Anda.

Anda dapat melacak setiap permintaan akses darurat dan mendeteksi serta memberikan peringatan mengenai adanya upaya penyalahgunaan proses untuk peristiwa yang tidak darurat.

Dokumentasikan kondisi awal (pre-conditions) dan asumsi mengenai proses tersebut: kapan proses tersebut harus digunakan dan kapan proses tersebut tidak boleh digunakan. Penting untuk memiliki detail mode kegagalan dan mendokumentasikan asumsi, seperti status keadaan sistem-sistem terkait lainnya. Misalnya, proses untuk Mode Kegagalan 2 mengasumsikan bahwa penyedia identitas tersedia, tetapi konfigurasi yang ditetapkan di AWS sudah dimodifikasi atau telah kedaluwarsa.

Sejak awal, buat sumber daya yang dibutuhkan oleh proses akses darurat (SEC10-BP05). Misalnya, buat akses Akun AWS darurat di awal dengan pengguna IAM dan peran IAM, dan peran IAM lintas akun di semua akun beban kerja. Hal ini akan memastikan bahwa semua sumber daya ini siap dan tersedia ketika ada sebuah peristiwa darurat yang terjadi. Dengan membuat sumber daya sebelumnya, artinya Anda tidak memiliki dependensi pada API bidang kontrol AWS (digunakan untuk membuat dan memodifikasi sumber daya AWS) yang mungkin tidak akan tersedia ketika ada keadaan darurat yang terjadi. Selanjutnya, dengan membuat sumber daya IAM sebelumnya, artinya Anda tidak perlu memperhitungkan potensi penundaan yang disebabkan terjadinya konsistensi di akhir.

Sertakan proses-proses akses darurat sebagai bagian dari rencana manajemen insiden Anda (SEC10-BP02). Dokumentasikan bagaimana peristiwa darurat dilacak dan dikomunikasikan kepada orang lain yang ada dalam organisasi Anda, seperti tim sejawat, pimpinan Anda, dan, jika ada, secara eksternal kepada para pelanggan dan partner bisnis Anda.

Tentukan proses permintaan akses darurat yang ada dalam sistem alur kerja permintaan layanan yang ada, jika Anda memilikinya. Biasanya, sistem alur kerja semacam ini akan memungkinkan Anda untuk membuat formulir penerimaan informasi untuk mengumpulkan informasi tentang permintaan, melacak permintaan melalui setiap tahap alur kerja, dan menambahkan langkah-langkah persetujuan otomatis dan manual. Hubungkan setiap permintaan dengan sebuah peristiwa darurat terkait yang dilacak dalam sistem manajemen insiden Anda. Dengan memiliki sistem yang seragam untuk akses darurat, Anda dapat melacak permintaan tersebut dalam satu sistem tunggal, menganalisis tren penggunaan, dan meningkatkan kualitas proses Anda.

Pastikan bahwa proses akses darurat Anda hanya dapat dimulai oleh pengguna yang berwenang dan itu memerlukan persetujuan dari rekan sejawat atau manajemen pengguna yang sesuai. Proses persetujuan harus beroperasi secara efektif baik di dalam maupun di luar jam kerja. Tentukan bagaimana permintaan persetujuan mengizinkan pemberi persetujuan sekunder jika pemberi persetujuan utama tidak tersedia dan bagaimana permintaan itu dieskalasikan ke rantai manajemen Anda hingga mendapatkan persetujuan.

Terapkan mekanisme pencatatan log, pemantauan, dan peringatan yang efektif untuk proses dan mekanisme akses darurat. Buat log audit yang mendetail untuk semua upaya yang berhasil dan upaya yang gagal dalam mendapatkan akses darurat. Korelasikan aktivitas dengan peristiwa darurat yang sedang berlangsung dari sistem manajemen insiden Anda, dan jalankan peringatan jika tindakan terjadi di luar periode waktu yang diharapkan atau jika akun akses darurat digunakan selama operasi normal. Akun akses darurat hanya boleh diakses selama keadaan darurat karena prosedur break-glass dapat dianggap sebagai backdoor. Integrasikan dengan alat informasi keamanan dan manajemen peristiwa (SIEM) Anda atau AWS Security Hub untuk melaporkan dan mengaudit semua aktivitas selama periode akses darurat. Setelah kembali ke operasi normal, rotasikan kredensial akses darurat secara otomatis, dan beri tahu tim yang relevan.

Lakukan pengujian terhadap proses akses darurat secara berkala untuk memverifikasi bahwa langkah-langkahnya sudah jelas dan memberikan tingkat akses yang benar dengan cepat dan efisien. Proses akses darurat Anda harus diuji sebagai bagian dari simulasi respons insiden (SEC10-BP07) dan tes pemulihan bencana (REL13-BP03).

Anda dapat membuat satu set pengguna IAM untuk administrator darurat Anda yang ada di akun akses darurat dengan kata sandi yang kuat dan token MFA yang sudah dikaitkan. Set pengguna IAM ini memiliki izin untuk mengambil peran IAM yang kemudian akan memungkinkan akses lintas akun ke Akun AWS tempat di mana akses darurat diperlukan. Kami sarankan Anda untuk membuat pengguna sesedikit mungkin dan menetapkan masing-masing pengguna ke satu administrator darurat. Selama keadaan darurat, pengguna administrator darurat masuk ke akun akses darurat dengan menggunakan kata sandi dan kode token MFA mereka, beralih ke peran IAM akses darurat yang ada di akun darurat, dan pada akhirnya beralih ke peran IAM akses darurat yang ada di akun beban kerja untuk melakukan tindakan perubahan darurat. Kelebihan pendekatan ini adalah setiap pengguna IAM ditugaskan ke satu administrator darurat dan Anda dapat mengetahui pengguna mana yang masuk dengan melakukan peninjauan pada peristiwa CloudTrail. Kelemahan pendekatan ini adalah Anda harus mempertahankan beberapa pengguna IAM dengan kata sandi berumur panjang dan token MFA yang sudah dikaitkan.

Anda dapat menggunakan pengguna root Akun AWS akses darurat untuk masuk ke akun akses darurat, mengambil peran IAM untuk akses darurat, dan mengambil peran lintas akun yang ada di akun beban kerja. Kami merekomendasikan Anda untuk menggunakan pengaturan kata sandi yang kuat dan beberapa token MFA untuk pengguna root tersebut. Kami juga menyarankan Anda untuk menyimpan kata sandi dan token MFA di sebuah brankas kredensial korporasi yang aman yang memberlakukan autentikasi dan otorisasi yang kuat. Anda harus mengamankan kata sandi dan faktor pengaturan ulang token MFA: atur alamat email akun ke sebuah daftar distribusi email yang dipantau oleh administrator keamanan cloud Anda, dan atur nomor telepon akun ke nomor telepon bersama yang juga dipantau oleh administrator keamanan. Keunggulan pendekatan ini adalah bahwa hanya ada satu set kredensial pengguna root yang harus dikelola. Kelemahan pendekatan ini adalah karena ini merupakan pengguna bersama, maka ada beberapa administrator yang memiliki kemampuan untuk masuk sebagai pengguna root. Anda harus melakukan audit terhadap peristiwa log brankas korporasi Anda untuk mengidentifikasi administrator mana yang menggunakan kata sandi pengguna root.

Buatlah sebuah Akun AWS yang ditujukan khusus untuk proses akses darurat. Di awal, buatlah sumber daya IAM yang dibutuhkan di dalam akun tersebut, seperti peran IAM atau pengguna IAM, dan Penyedia Identitas IAM opsional. Selain itu, buatlah di awal, peran IAM lintas akun di dalam Akun AWS beban kerja yang memiliki hubungan kepercayaan dengan peran IAM yang sesuai di akun akses darurat tersebut. Anda dapat menggunakan AWS CloudFormation StackSets dengan AWS Organizations untuk membuat sumber daya tersebut di akun anggota yang ada dalam organisasi Anda.

Buatlah kebijakan kontrol layanan (SCP) AWS Organizations untuk menyangkal penghapusan dan modifikasi peran IAM lintas akun yang ada dalam anggota Akun AWS.

Aktifkan CloudTrail untuk Akun AWS akses darurat dan kirimkan peristiwa jejak ke bucket S3 pusat yang ada di Akun AWS pengumpulan log Anda. Jika Anda menggunakan AWS Control Tower untuk menyiapkan dan mengatur lingkungan multi-akun AWS Anda, maka setiap akun yang Anda buat dengan menggunakan AWS Control Tower atau Anda daftarkan di AWS Control Tower akan memiliki CloudTrail yang diaktifkan secara default dan dikirim ke bucket S3 dalam sebuah Akun AWS arsip log khusus.

Pantau aktivitas yang terjadi di akun akses darurat dengan membuat aturan EventBridge yang cocok saat login konsol dan aktivitas API berdasarkan peran IAM darurat. Kirimkan notifikasi ke pusat operasi keamanan Anda ketika ada aktivitas yang terjadi di luar peristiwa darurat yang sedang berlangsung yang terlacak dalam sistem manajemen insiden Anda.

Buatlah sumber daya di awal tergantung pada mekanisme yang Anda pilih untuk akses darurat:

Sebagaimana diuraikan dalam langkah Siapkan akses darurat ke AWS Management Console, di Akun AWS akses darurat, buat sebuah Penyedia Identitas IAM untuk mengaktifkan federasi SAML langsung dari penyedia identitas Anda.

Buat grup operasi darurat di IdP Anda tanpa anggota.

Buat peran IAM yang sesuai dengan grup operasi darurat yang ada di akun akses darurat.

SEC02-BP04 Mengandalkan penyedia identitas tersentralisasi

SEC03-BP02 Memberikan hak akses paling rendah

SEC10-BP02 Membuat rencana manajemen insiden

SEC10-BP07 Menjalankan game day

Menyiapkan akses darurat ke AWS Management Console

Mengaktifkan pengguna gabungan SAML 2.0 untuk mengakses AWS Management Console

Akses pecah kaca

AWS re:invent 2022 - Menyederhanakan akses tenaga kerja Anda dengan Pusat Identitas IAM

AWS re:Inforce 2022 - Pembahasan mendalam tentang AWS Identity and Access Management (IAM)

Peran Pecah Kaca AWS

Kerangka kerja playbook pelanggan AWS

Contoh playbook respons insiden AWS