SEC03-BP03 Menerapkan proses akses darurat - Pilar Keamanan
Panduan implementasi Sumber daya

SEC03-BP03 Menerapkan proses akses darurat

Buat proses yang memungkinkan akses darurat ke beban kerja Anda jika terjadi masalah pada penyedia identitas terpusat Anda.

Anda harus merancang proses untuk berbagai mode kegagalan yang dapat mengakibatkan peristiwa darurat. Misalnya, dalam keadaan normal, pengguna tenaga kerja Anda melakukan federasi ke cloud menggunakan penyedia identitas terpusat (SEC02-BP04) untuk mengelola beban kerja mereka. Namun, jika penyedia identitas terpusat Anda gagal, atau konfigurasi untuk federasi di cloud diubah, maka pengguna tenaga kerja Anda mungkin tidak dapat melakukan federasi ke cloud. Proses akses darurat memungkinkan administrator yang berwenang untuk mengakses sumber daya cloud Anda melalui cara alternatif (seperti bentuk federasi alternatif atau akses pengguna langsung) untuk memperbaiki masalah dengan konfigurasi federasi atau beban kerja Anda. Proses akses darurat digunakan sampai mekanisme federasi normal dipulihkan.

Hasil yang diinginkan:

  • Anda telah menentukan dan mendokumentasikan mode kegagalan yang terhitung sebagai keadaan darurat: pertimbangkan keadaan normal Anda dan sistem yang diandalkan oleh pengguna Anda untuk mengelola beban kerja mereka. Pertimbangkan bagaimana setiap dependensi ini dapat gagal dan menyebabkan keadaan darurat. Anda dapat menemukan pertanyaan dan praktik terbaik di Pilar Keandalan yang berguna untuk mengidentifikasi mode kegagalan dan merancang sistem yang lebih tangguh untuk meminimalkan kemungkinan kegagalan.

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

  • Anda telah menentukan proses akses darurat khusus untuk setiap jenis mode darurat atau kegagalan. Pengkhususan ini dapat mengurangi godaan di pihak pengguna Anda untuk terlalu sering menggunakan proses umum untuk semua jenis keadaan darurat. Proses akses darurat Anda menggambarkan keadaan di mana setiap 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 efisien. Ingatlah bahwa peristiwa darurat dapat menjadi saat yang memusingkan bagi pengguna Anda dan mereka sedang di bawah tekanan waktu yang ekstrem, jadi rancanglah proses Anda sesederhana mungkin.

Antipola umum:

  • Anda tidak memiliki proses akses darurat yang terdokumentasi dengan baik dan teruji dengan baik. Pengguna Anda tidak siap menghadapi keadaan darurat dan mengikuti proses improvisasi ketika peristiwa darurat muncul.

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

  • Proses akses darurat Anda digunakan dalam situasi non-darurat. Misalnya, pengguna Anda sering menyalahgunakan proses akses darurat karena mereka merasa lebih mudah melakukan perubahan secara langsung daripada mengirimkan perubahan melalui pipeline.

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

Manfaat menjalankan praktik terbaik ini:

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

  • Anda dapat melacak setiap permintaan akses darurat dan mendeteksi serta memberikan peringatan adanya upaya penyalahgunaan proses untuk peristiwa non-darurat.

Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan: Sedang

Panduan implementasi

Bagian ini memberikan panduan dalam membuat proses akses darurat untuk beberapa mode kegagalan yang berkaitan dengan beban kerja yang di-deploy di AWS, dimulai dengan panduan umum yang berlaku untuk semua mode kegagalan dan dilanjutkan dengan panduan khusus berdasarkan jenis mode kegagalan.

Panduan umum untuk semua mode kegagalan

Pertimbangkan hal berikut saat Anda merancang proses akses darurat untuk mode kegagalan:

  • Dokumentasikan kondisi awal dan asumsi tentang proses tersebut: kapan proses tersebut harus digunakan dan kapan proses tersebut tidak boleh digunakan. Penting untuk memiliki detail mode kegagalan dan mendokumentasikan asumsi, seperti keadaan sistem terkait lainnya. Misalnya, proses untuk Mode Kegagalan 2 mengasumsikan bahwa penyedia identitas tersedia, tetapi konfigurasi di AWS dimodifikasi atau telah kedaluwarsa.

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

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

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

  • Pastikan proses akses darurat Anda hanya dapat dimulai oleh pengguna yang berwenang dan 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 ditingkatkan ke rantai manajemen Anda hingga disetujui.

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

  • Uji proses akses darurat secara berkala untuk memverifikasi bahwa langkah-langkahnya 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).

Mode Kegagalan 1: Penyedia identitas yang digunakan untuk federasi ke AWS tidak tersedia

Seperti yang dijelaskan dalam SEC02-BP04 Mengandalkan penyedia identitas terpusat, kami sarankan Anda mengandalkan penyedia identitas terpusat untuk memfederasi pengguna tenaga kerja Anda untuk memberikan akses ke Akun AWS. Anda dapat melakukan federasi ke beberapa Akun AWS di organisasi AWS Anda menggunakan IAM Identity Center, atau Anda dapat melakukan federasi ke Akun AWS secara terpisah menggunakan IAM. Dalam kedua kasus tersebut, pengguna tenaga kerja melakukan autentikasi dengan penyedia identitas terpusat Anda sebelum diarahkan ke titik akhir masuk AWS ke masuk tunggal.

Apabila penyedia identitas terpusat Anda tidak tersedia, pengguna tenaga kerja Anda tidak dapat melakukan federasi ke Akun AWS atau mengelola beban kerja mereka. Dalam peristiwa darurat ini, Anda dapat menyediakan proses akses darurat untuk sekelompok kecil administrator untuk mengakses Akun AWS untuk melakukan tugas-tugas penting yang tidak dapat ditunda sampai penyedia identitas terpusat Anda kembali aktif. Misalnya, penyedia identitas Anda tidak tersedia selama 4 jam dan selama periode tersebut Anda perlu mengubah batas atas grup Amazon EC2 Auto Scaling di sebuah akun Produksi untuk menangani lonjakan lalu lintas pelanggan yang tidak terduga. Administrator darurat Anda harus mengikuti proses akses darurat untuk mendapatkan akses ke Akun AWS khusus produksi dan membuat perubahan yang diperlukan.

Proses akses darurat tersebut bergantung pada Akun AWS akses darurat yang telah dibuat sebelumnya yang digunakan semata-mata untuk akses darurat dan memiliki sumber daya AWS (seperti peran IAM danIAM users) untuk mendukung proses akses darurat. Selama operasi normal, tidak ada yang boleh mengakses akun akses darurat tersebut dan Anda harus memantau dan memperingatkan penyalahgunaan akun ini (untuk lebih jelasnya, lihat bagian panduan umum sebelumnya).

Akun akses darurat memiliki peran IAM akses darurat dengan izin untuk mengambil peran lintas akun di dalam Akun AWS yang memerlukan akses darurat. Peran IAM ini telah dibuat sebelumnya dan dikonfigurasi dengan kebijakan kepercayaan yang mempercayai peran IAM akun darurat.

Proses akses darurat dapat menggunakan salah satu pendekatan berikut:

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

  • 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 di akun beban kerja. Kami merekomendasikan pengaturan kata sandi yang kuat dan beberapa token MFA untuk pengguna root. Kami juga menyarankan Anda menyimpan kata sandi dan token MFA di brankas kredensial korporasi aman yang memberlakukan autentikasi dan otorisasi yang kuat. Anda harus mengamankan kata sandi dan faktor pengaturan ulang token MFA: atur 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 ada satu set kredensial pengguna root untuk dikelola. Kelemahannya adalah karena ini merupakan pengguna bersama, beberapa administrator memiliki kemampuan untuk masuk sebagai pengguna root. Anda harus mengaudit peristiwa log brankas korporasi Anda untuk mengidentifikasi administrator mana yang menggunakan kata sandi pengguna root.

Mode Kegagalan 2: Konfigurasi penyedia identitas di AWS dimodifikasi atau telah kedaluwarsa

Agar pengguna tenaga kerja Anda dapat melakukan federasi ke Akun AWS, Anda dapat mengonfigurasi IAM Identity Center dengan penyedia identitas eksternal atau membuat Penyedia Identitas IAM (SEC02-BP04). Biasanya, Anda mengonfigurasinya dengan mengimpor dokumen XML metadata SAML yang disediakan oleh penyedia identitas Anda. Dokumen metadata XML tersebut mencakup sertifikat X.509 yang sesuai dengan kunci privat yang digunakan oleh penyedia identitas untuk menandatangani pernyataan SAML-nya.

Konfigurasi di sisi AWS ini dapat diubah atau dihapus secara tidak sengaja oleh administrator. Dalam skenario lain, sertifikat X.509 yang diimpor ke dalam AWS dapat kedaluwarsa dan XML metadata baru dengan sertifikat baru belum diimpor ke AWS. Kedua skenario ini dapat mengganggu federasi ke AWS untuk pengguna tenaga kerja Anda, yang mengakibatkan keadaan darurat.

Dalam keadaan darurat seperti ini, Anda dapat memberikan akses ke AWS kepada administrator identitas Anda untuk memperbaiki masalah federasi tersebut. Misalnya, administrator identitas Anda menggunakan proses akses darurat untuk masuk ke Akun AWS akses darurat, beralih ke peran di akun administrator Pusat Identitas, dan memperbarui konfigurasi penyedia identitas eksternal dengan mengimpor dokumen XML metadata SAML terbaru dari penyedia identitas Anda untuk mengaktifkan kembali federasi. Setelah federasi diperbaiki, pengguna tenaga kerja Anda melanjutkan penggunaan proses operasi normal untuk melakukan federasi ke akun beban kerja mereka.

Anda dapat mengikuti pendekatan yang dijelaskan dalam Mode Kegagalan 1 sebelumnya untuk membuat proses akses darurat. Anda dapat memberikan hak akses paling sedikit kepada administrator identitas Anda untuk mengakses hanya akun administrator Pusat Identitas dan melakukan tindakan pada Pusat Identitas di akun tersebut.

Mode Kegagalan 3: Gangguan Pusat Identitas

Apabila terjadi gangguan IAM Identity Center atau Wilayah AWS, kami sarankan Anda menyiapkan konfigurasi yang dapat Anda gunakan untuk menyediakan akses sementara ke AWS Management Console.

Proses akses darurat tersebut menggunakan federasi langsung dari penyedia identitas Anda ke IAM dalam akun darurat. Untuk detail tentang proses dan pertimbangan desain, lihat Menyiapkan akses darurat ke AWS Management Console.

Langkah implementasi

Langkah-langkah umum untuk semua mode kegagalan

  • Buat Akun AWS yang ditujukan khusus untuk proses akses darurat. Di awal, buat sumber daya IAM yang dibutuhkan di dalam akun seperti peran IAM atau IAM users, dan Penyedia Identitas IAM opsional. Selain itu, buat di awal peran IAM lintas akun di dalam Akun AWS beban kerja dengan hubungan kepercayaan 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 dalam organisasi Anda.

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

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

  • Pantau aktivitas 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 aktivitas terjadi di luar peristiwa darurat yang sedang berlangsung yang dilacak dalam sistem manajemen insiden Anda.

Langkah-langkah tambahan untuk Mode Kegagalan 1: Penyedia identitas yang digunakan untuk melakukan federasi ke AWS tidak tersedia dan Mode Kegagalan 2: Konfigurasi penyedia identitas di AWS dimodifikasi atau telah kedaluwarsa

  • Buat sumber daya di awal tergantung mekanisme yang Anda pilih untuk akses darurat:

    • Menggunakan IAM users buat IAM users di awal dengan kata sandi yang kuat serta perangkat MFA terkait.

    • Menggunakan pengguna root akun darurat: konfigurasikan pengguna root dengan kata sandi yang kuat dan simpan kata sandi di dalam brankas kredensial korporasi Anda. Kaitkan beberapa perangkat MFA fisik dengan pengguna root dan simpan perangkat di lokasi yang dapat diakses dengan cepat oleh anggota tim administrator darurat Anda.

Langkah-langkah tambahan untuk Mode Kegagalan 3: Gangguan pusat identitas

  • Seperti yang dijelaskan dalam Menyiapkan akses darurat ke AWS Management Console, di Akun AWS akses darurat, buat sebuah Penyedia Identitas IAM untuk mengaktifkan federasi SAFL langsung dari penyedia identitas Anda.

  • Buat grup operasi darurat di IdP Anda tanpa anggota.

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

Sumber daya

Praktik terbaik Well-Architected terkait:

Dokumen terkait:

Video terkait:

Contoh terkait: