Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
SEC10-BP05 Akses pra-penyediaan
Verifikasi bahwa responden insiden memiliki akses yang benar yang telah disediakan sebelumnya AWS untuk mengurangi waktu yang diperlukan untuk penyelidikan hingga pemulihan.
Anti-pola umum:
-
Menggunakan akun root untuk merespons insiden.
-
Mengubah akun-akun yang ada.
-
Memanipulasi IAM izin secara langsung saat memberikan elevasi just-in-time hak istimewa.
Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan: Sedang
Panduan implementasi
AWS merekomendasikan mengurangi atau menghilangkan ketergantungan pada kredensi berumur panjang sedapat mungkin, demi kredensi sementara dan mekanisme eskalasi hak istimewa. just-in-time Kredensial berumur panjang rentang terkena risiko keamanan dan meningkatkan biaya overhead operasional. Untuk sebagian besar tugas manajemen, serta tugas respons insiden, kami sarankan Anda untuk menerapkan federasi identitas
Kami menyarankan penggunaan peningkatan hak akses sementara di sebagian besar skenario respons insiden. Cara yang benar untuk melakukan hal itu adalah dengan menggunakan AWS Security Token Service dan kebijakan sesi untuk mencakup akses.
Terdapat skenario di mana identitas terfederasi tidak tersedia, seperti:
-
Pemadaman yang berkaitan dengan penyedia identitas (IdP) yang terganggu.
-
Kesalahan konfigurasi atau kesalahan manusiawi yang menyebabkan rusaknya sistem manajemen akses terfederasi.
-
Aktivitas berbahaya seperti peristiwa penolakan layanan (DDoS) terdistribusi atau rendering tidak tersedianya sistem.
Dalam kasus sebelumnya, harus ada akses kaca pecah darurat yang dikonfigurasi untuk memungkinkan penyelidikan dan perbaikan insiden dilakukan secara tepat waktu. Kami menyarankan Anda menggunakan pengguna, grup, atau peran dengan izin yang sesuai untuk melakukan tugas dan mengakses AWS sumber daya. Gunakan pengguna root hanya untuk tugas yang memerlukan kredensial pengguna root. Untuk memverifikasi bahwa responden insiden memiliki tingkat akses yang benar AWS dan sistem lain yang relevan, kami merekomendasikan pra-penyediaan akun khusus. Akun-akun tersebut memerlukan akses istimewa, dan harus dikontrol dan dipantau secara ketat. Akun-akun tersebut harus dibuat dengan hak akses paling rendah yang diperlukan untuk menjalankan tugas yang diperlukan, dan tingkat akses harus didasarkan pada playbook yang dibuat sebagai bagian dari rencana manajemen insiden.
Gunakan pengguna dan peran yang dibuat khusus sebagai praktik terbaik. Meningkatnya akses pengguna atau peran untuk sementara melalui penambahan IAM kebijakan membuat tidak jelas akses apa yang dimiliki pengguna selama insiden, dan risiko hak istimewa yang meningkat tidak dicabut.
Penting untuk menghapus dependensi sebanyak mungkin untuk memastikan akses dapat diperoleh dalam sebanyak mungkin skenario kegagalan. Untuk mendukung hal ini, buat buku pedoman untuk memverifikasi bahwa pengguna respons insiden dibuat sebagai pengguna di akun keamanan khusus, dan tidak dikelola melalui solusi Federation atau single sign-on () SSO yang ada. Tiap-tiap perespons harus memiliki akun dengan nama mereka sendiri. Konfigurasi akun harus menerapkan kebijakan kata sandi yang kuat dan otentikasi multi-faktor (). MFA Jika buku pedoman respons insiden hanya memerlukan akses ke AWS Management Console, pengguna tidak boleh memiliki kunci akses yang dikonfigurasi dan harus secara eksplisit dilarang membuat kunci akses. Ini dapat dikonfigurasi dengan IAM kebijakan atau kebijakan kontrol layanan (SCPs) seperti yang disebutkan dalam Praktik Terbaik AWS Keamanan untuk AWS Organizations SCPs. Pengguna tidak boleh memiliki hak ases selain kemampuan untuk mengambil peran respons insiden di akun-akun lainnya.
Selama insiden, mungkin diperlukan pemberian akses ke individu internal atau eksternal untuk mendukung aktivitas penyelidikan, perbaikan, atau pemulihan. Pada kasus ini, gunakan mekanisme playbook yang disebutkan sebelumnya, dan harus ada proses untuk memverifikasi bahwa akses tambahan apa pun segera dicabut setelah insiden selesai.
Untuk memverifikasi bahwa penggunaan peran respons insiden dapat dipantau dan diaudit dengan benar, penting bahwa IAM akun yang dibuat untuk tujuan ini tidak dibagi antar individu, dan bahwa tidak digunakan kecuali diperlukan untuk tugas tertentu. Pengguna root akun AWS Jika pengguna root diperlukan (misalnya, IAM akses ke akun tertentu tidak tersedia), gunakan proses terpisah dengan buku pedoman yang tersedia untuk memverifikasi ketersediaan kredenal masuk pengguna root dan token. MFA
Untuk mengonfigurasi IAM kebijakan untuk peran respons insiden, pertimbangkan untuk menggunakan IAMAccess Analyzer untuk membuat kebijakan berdasarkan AWS CloudTrail log. Untuk melakukannya, berikan akses administrator ke peran respons insiden di akun non-produksi dan jalankan playbook Anda. Setelah selesai, kebijakan dapat dibuat yang hanya mengizinkan tindakan yang diambil. Kebijakan ini kemudian dapat diterapkan ke semua peran respons insiden di semua akun. Anda mungkin ingin membuat IAM kebijakan terpisah untuk setiap buku pedoman agar manajemen dan audit lebih mudah. Contoh playbook dapat mencakup rencana respons untuk ransomware, pembobolan data, hilangnya akses produksi, dan skenario lain.
Gunakan akun respons insiden untuk mengambil IAMperan respons insiden khusus di akun lain Akun AWS. Peran ini harus dikonfigurasi agar hanya dapat diasumsikan oleh pengguna di akun keamanan, dan hubungan kepercayaan harus mengharuskan prinsipal panggilan telah diautentikasi menggunakan. MFA Peran harus menggunakan kebijakan dengan cakupan ketat untuk mengontrol akses. IAM Pastikan bahwa semua AssumeRole permintaan untuk peran ini masuk CloudTrail dan diperingatkan, dan tindakan apa pun yang diambil menggunakan peran ini dicatat.
Sangat disarankan agar IAM akun dan IAM peran diberi nama dengan jelas agar mudah ditemukan di CloudTrail log. Contohnya adalah memberi nama IAM akun <USER_ID>-BREAK-GLASSBREAK-GLASS-ROLE.
CloudTraildigunakan untuk mencatat API aktivitas di AWS akun Anda dan harus digunakan untuk mengonfigurasi peringatan tentang penggunaan peran respons insidenAssumeRole peristiwa yang terkait dengan IAM peran respons insiden:
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<INCIDENT_RESPONSE_ROLE_ARN>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
Karena peran respons insiden kemungkinan memiliki tingkat akses yang tinggi, peringatan-peringatan ini harus menjangkau grup yang luas dan ditindaklanjuti segera.
Selama insiden, ada kemungkinan bahwa responden mungkin memerlukan akses ke sistem yang tidak diamankan secara langsung. IAM Ini dapat mencakup instans Amazon Elastic Compute Cloud, database Amazon Relational Database Service, atau platform ( software-as-a-serviceSaaS). Sangat disarankan bahwa daripada menggunakan protokol asli seperti SSH atauRDP, AWS Systems Manager Session Managerdigunakan untuk semua akses administratif ke instans AmazonEC2. Akses ini dapat dikontrol menggunakanIAM, yang aman dan diaudit. Dimungkinkan juga untuk mengotomatiskan bagian dari playbook Anda dengan menggunakan dokumen AWS Systems Manager Run Command, yang dapat mengurangi kesalahan pengguna dan meningkatkan waktu untuk pemulihan. Untuk akses ke database dan alat pihak ketiga, kami sarankan untuk menyimpan kredensi akses AWS Secrets Manager dan memberikan akses ke peran responden insiden.
Terakhir, pengelolaan IAM akun respons insiden harus ditambahkan ke proses Joiner, Movers, dan Leavers Anda dan ditinjau dan diuji secara berkala untuk memverifikasi bahwa hanya akses yang dimaksudkan yang diizinkan.
Sumber daya
Dokumen terkait:
-
Mengelola akses sementara yang ditinggikan ke AWS lingkungan Anda
-
Menggunakan IAM Access Analyzer untuk menghasilkan kebijakan IAM
-
Praktik Terbaik untuk Kebijakan Kontrol AWS Organizations Layanan di Lingkungan Multi-Akun
-
Cara Menerima Pemberitahuan Saat Kunci Akses Root AWS Akun Anda Digunakan
-
Buat izin sesi berbutir halus menggunakan kebijakan terkelola IAM
Video terkait:
Contoh terkait:
