SEC03-BP03 Menetapkan 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 AWS dimodifikasi atau telah kedaluwarsa.

Pra-buat sumber daya yang dibutuhkan oleh proses akses darurat (SEC10-BP05). Misalnya, pra-buat akses darurat Akun AWS dengan IAM pengguna dan peran, dan IAM peran 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, Anda tidak memiliki ketergantungan pada bidang AWS kontrol APIs (digunakan untuk membuat dan memodifikasi AWS sumber daya) yang mungkin tidak tersedia dalam keadaan darurat. Selanjutnya, dengan membuat IAM sumber daya sebelumnya, Anda tidak perlu memperhitungkan potensi penundaan karena konsistensi akhirnya.

Sertakan 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 mau pun di luar jam kerja. Tentukan bagaimana permintaan persetujuan mengizinkan pemberi persetujuan sekunder jika pemberi persetujuan utama tidak tersedia dan bagaimana permintaan itu ditingkatkan ke rantai manajemen Anda hingga mendapatkan persetujuan.

Pastikan bahwa proses tersebut menghasilkan log dan peristiwa audit yang mendetail, baik untuk upaya yang berhasil maupun upaya yang gagal mendapatkan akses darurat. Pantau proses permintaan serta mekanisme akses darurat untuk mendeteksi adanya penyalahgunaan atau akses yang tidak sah. Korelasikan aktivitas dengan peristiwa darurat yang sedang berlangsung dari sistem manajemen insiden Anda dan munculkan peringatan ketika ada tindakan yang terjadi di luar periode waktu yang diharapkan. Misalnya, Anda harus memantau dan memberikan peringatan mengenai aktivitas dalam akses darurat Akun AWS, karena akun tersebut tidak boleh digunakan dalam operasi normal.

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 (-BP03). REL13

Anda dapat membuat serangkaian IAMpengguna untuk administrator darurat Anda di akun akses darurat dengan kata sandi dan MFA token kuat yang terkait. IAMPengguna ini memiliki izin untuk mengambil IAM peran yang kemudian memungkinkan akses lintas akun ke Akun AWS tempat 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 menggunakan kata sandi dan kode MFA token mereka, beralih ke IAM peran akses darurat di akun darurat, dan akhirnya beralih ke IAM peran akses darurat di akun beban kerja untuk melakukan tindakan perubahan darurat. Keuntungan dari pendekatan ini adalah bahwa setiap IAM pengguna ditugaskan ke satu administrator darurat dan Anda dapat mengetahui pengguna mana yang masuk dengan meninjau peristiwa. CloudTrail Kerugiannya adalah Anda harus mempertahankan banyak IAM pengguna dengan kata sandi dan MFA token berumur panjang yang terkait.

Anda dapat menggunakan pengguna Akun AWS root akses darurat untuk masuk ke akun akses darurat, mengambil IAM peran untuk akses darurat, dan mengambil peran lintas akun di akun beban kerja. Kami merekomendasikan pengaturan kata sandi yang kuat dan beberapa MFA token untuk pengguna root. Kami juga merekomendasikan untuk menyimpan kata sandi dan MFA token di brankas kredensi perusahaan yang aman yang memberlakukan otentikasi dan otorisasi yang kuat. Anda harus mengamankan faktor pengaturan ulang kata sandi dan MFA token: setel alamat email akun ke daftar distribusi email yang dipantau oleh administrator keamanan cloud Anda, dan 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.

Buat yang Akun AWS didedikasikan untuk proses akses darurat. Pra-buat IAM sumber daya yang dibutuhkan dalam akun seperti IAM peran atau IAM pengguna, dan Penyedia IAM Identitas opsional. Selain itu, pra-buat IAM peran lintas akun dalam beban kerja dengan hubungan kepercayaan Akun AWS dengan IAM peran yang sesuai di akun akses darurat. Anda dapat menggunakan AWS CloudFormation StackSets dengan AWS Organizations untuk membuat sumber daya tersebut di akun anggota di organisasi Anda.

Buat kebijakan kontrol AWS Organizations layanan (SCPs) untuk menolak penghapusan dan modifikasi IAM peran lintas akun di anggota. Akun AWS

CloudTrail Aktifkan akses darurat Akun AWS dan kirim peristiwa jejak ke bucket S3 pusat di koleksi Akun AWS log Anda. Jika Anda menggunakannya AWS Control Tower untuk mengatur dan mengatur lingkungan AWS multi-akun, maka setiap akun yang Anda buat menggunakan AWS Control Tower atau mendaftar AWS Control Tower telah CloudTrail diaktifkan secara default dan dikirim ke bucket S3 dalam arsip log khusus. Akun AWS

Pantau aktivitas akun akses darurat dengan membuat EventBridge aturan yang cocok saat login konsol dan API aktivitas berdasarkan IAM peran 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 dijelaskan dalam Mengatur akses darurat ke AWS Management Console, dalam akses darurat Akun AWS, buat Penyedia IAM Identitas untuk mengaktifkan SAML federasi langsung dari penyedia identitas Anda.

Buat grup operasi darurat di IdP Anda tanpa anggota.

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

SEC02-BP04 Mengandalkan penyedia identitas terpusat

SEC03-BP02 Berikan akses hak istimewa paling sedikit

SEC10-BP02 Mengembangkan rencana manajemen insiden

SEC10-BP07 Jalankan hari permainan

Mengatur akses darurat ke AWS Management Console

Mengaktifkan SAML 2.0 pengguna federasi untuk mengakses AWS Management Console

Akses pecah kaca

AWS re:invent 2022 - Sederhanakan akses tenaga kerja Anda yang ada dengan Identity Center IAM

AWS Re: inforce 2022 - AWS Identity and Access Management () IAM menyelam dalam

Peran Pecah Kaca AWS

Kerangka kerja playbook pelanggan AWS

Contoh playbook respons insiden AWS