SEC10-BP05 Menyediakan akses di awal

Verifikasi staf respons insiden memiliki akses yang benar yang telah disediakan sebelumnya di AWS untuk mengurangi waktu yang diperlukan untuk penyelidikan hingga pemulihan.

Antipola umum:

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

Panduan implementasi

AWS menyarankan Anda untuk sebisa mungkin mengurangi atau menghilangkan kebergantungan pada kredensial berumur panjang, dan memilih kredensial sementara dan mekanisme peningkatan hak akses hanya saat diperlukan. Kredensial berumur panjang rentang terkena risiko keamanan dan meningkatkan biaya overhead operasional. Untuk sebagian besar tugas manajemen, serta tugas respons insiden, kami menyarankan Anda untuk mengimplementasikan federasi identitas bersamaan dengan peningkatan sementara untuk akses administratif. Di model ini, seorang pengguna meminta peningkatan ke tingkat hak akses yang lebih tinggi (seperti peran respons insiden) dan, apabila pengguna tersebut memenuhi syarat peningkatan hak, permintaan tersebut dikirimkan ke seorang pemberi persetujuan. Jika permintaan tersebut disetujui, pengguna menerima serangkaian kredensial AWS sementara yang dapat digunakan untuk menyelesaikan tugas-tugas mereka. Setelah kredensial ini kedaluwarsa, pengguna harus mengirimkan permintaan peningkatan baru.

Kami menyarankan penggunaan peningkatan hak akses sementara di sebagian besar skenario respons insiden. Cara tepat untuk melakukannya adalah dengan menggunakan AWS Security Token Service dan kebijakan sesi untuk membuat cakupan akses.

Terdapat skenario di mana identitas terfederasi tidak tersedia, seperti:

Pada kasus-kasus di atas, harus terdapat akses mendesak (break glass) yang dikonfigurasi untuk mengizinkan penyelidikan dan perbaikan peristiwa secara cepat. Sebaiknya gunakan juga pengguna IAM dengan izin yang tepat untuk menjalankan tugas dan mengakses sumber daya AWS. Gunakan kredensial root hanya untuk tugas yang memerlukan akses pengguna root. Untuk memverifikasi bahwa tim respons insiden memiliki tingkat akses yang tepat ke AWS dan sistem yang relevan lainnya, sebaiknya sediakan akun-akun pengguna khusus sejak awal. Akun pengguna tersebut memerlukan akses istimewa, dan harus dikontrol dan dipantau secara ketat. Akun-akun tersebut harus dibuat dengan hak akses paling sedikit 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. Peningkatan akses pengguna atau peran sementara melalui penambahan kebijakan IAM menjadikannya tidak jelas terkait akses apa yang dimiliki pengguna selama insiden, dan terdapat risiko tidak dicabutnya peningkatan hak akses tersebut.

Penting untuk menghapus dependensi sebanyak mungkin untuk memastikan akses dapat diperoleh dalam sebanyak mungkin skenario kegagalan. Untuk mendukung hal ini, buatlah playbook untuk memastikan pengguna respons insiden dibuat sebagai pengguna AWS Identity and Access Management di dalam akun keamanan khusus, dan bukan dikelola melalui solusi Federasi atau masuk tunggal (SSO) yang ada. Tiap-tiap perespons harus memiliki akun dengan nama mereka sendiri. Konfigurasi akun harus menegakkan kebijakan kata sandi yang kuat dan autentikasi multi-faktor (MFA). Jika playbook respons insiden hanya memerlukan akses ke AWS Management Console, pengguna tidak boleh memiliki kunci akses yang dikonfigurasi dan harus dilarang secara tegas untuk membuat kunci akses. Hal ini dapat dikonfigurasi dengan kebijakan IAM atau kebijakan kontrol layanan (SCP) sebagaimana disebutkan dalam Praktik Terbaik Keamanan AWS untu AWS Organizations SCP. 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 memastikan bahwa penggunaan peran respons insiden dapat dipantau dan diaudit dengan layak, penting untuk tidak membagikan akun pengguna IAM yang dibuat untuk tujuan ini kepada individu lain, serta tidak menggunakan pengguna root Akun AWS kecuali diperlukan untuk tugas tertentu. Jika pengguna root diperlukan (sebagai contoh, akses IAM ke akun tertentu tidak tersedia), gunakan proses terpisah dengan playbook yang tersedia untuk memverifikasi ketersediaan kata sandi pengguna root dan token MFA.

Untuk mengonfigurasi kebijakan IAM untuk peran respons insiden, pertimbangkan menggunakan IAM Access Analyzer untuk menghasilkan kebijakan berdasarkan log AWS CloudTrail. 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 kebijakan IAM terpisah untuk setiap playbook untuk mempermudah manajemen dan audit. Contoh playbook dapat mencakup rencana respons untuk ransomware, pembobolan data, hilangnya akses produksi, dan skenario lain.

Gunakan akun pengguna respons insiden untuk mengambil peran IAM respons insiden khusus di Akun AWS lain. Peran-peran ini harus dikonfigurasi hanya agar dapat diambil oleh pengguna di akun keamanan, dan hubungan kepercayaan harus mewajibkan bahwa principal pemanggil telah mengautentikasi menggunakan MFA. Peran-peran tersebut harus menggunakan kebijakan IAM dengan cakupan yang ketat untuk mengontrol akses. Pastikan bahwa semua permintaan AssumeRole untuk peran-peran ini dicatat dalam log di CloudTrail dan dibuatkan peringatan, dan bahwa tindakan apa pun yang diambil menggunakan peran-peran ini dicatat dalam log.

Sangat disarankan akun pengguna IAM serta IAM role disebutkan secara jelas agar dapat ditemukan dengan mudah di log CloudTrail. Contohnya adalah dengan menamai akun IAM dengan <USER_ID>-BREAK-GLASS dan IAM role dengan BREAK-GLASS-ROLE.

CloudTrail digunakan untuk membuat log aktivitas API di akun AWS Anda dan harus digunakan untuk mengonfigurasi peringatan penggunaan peran respons insiden. Lihat postingan blog tentang konfigurasi perintanan saat kunci root digunakan. Instruksi dapat dimodifikasi untuk mengonfigurasi filter-ke-filter metrik Amazon CloudWatch pada peristiwa AssumeRole terkait dengan IAM role 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, terdapat kemungkinan bahwa perespons mungkin memerlukan akses ke sistem yang tidak diamankan secara langsung oleh IAM. Sistem-sistem tersebut dapat mencakup instans Amazon Elastic Compute Cloud, basis data Amazon Relational Database Service, atau platform perangkat lunak sebagai layanan (SaaS). Sangat disarankan untuk tidak menggunakan protokol native seperti SSH atau RDP, melainkan AWS Systems Manager Session Manager untuk semua akses administratif ke instans Amazon EC2. Akses ini dapat dikontrol menggunakan IAM, yang aman dan diaudit. Memungkinkan juga untuk mengotomatisasi bagian-bagian playbook Anda menggunakan dokumen AWS Systems Manager Run Command, yang dapat mengurangi kesalahan pengguna dan mempercepat waktu pemulihan. Untuk akses ke basis data dan alat-alat pihak ketiga, kami sarankan menyimpan kredensial akses di AWS Secrets Manager dan memberikan akses ke peran perespons insiden.

Terakhir, manajemen akun pengguna IAM perespons insiden harus ditambahkan ke proses Joiners, Movers, dan Leavers Anda dan ditinjau serta diuji secara berkala untuk memastikan bahwa yang diizinkan hanyalah akses yang diinginkan.

Sumber daya

Dokumen terkait:

Video terkait:

Contoh terkait: