Praktik terbaik manajemen kunci untuk AWS KMS

Saat menggunakan AWS Key Management Service (AWS KMS), ada beberapa keputusan desain mendasar yang harus Anda buat. Ini termasuk apakah akan menggunakan model terpusat atau terdesentralisasi untuk manajemen dan akses kunci, jenis kunci yang akan digunakan, dan jenis penyimpanan kunci yang akan digunakan. Bagian berikut membantu Anda membuat keputusan yang tepat untuk organisasi dan kasus penggunaan Anda. Bagian ini diakhiri dengan pertimbangan penting untuk menonaktifkan dan menghapus kunci KMS, termasuk tindakan yang harus Anda ambil untuk membantu melindungi data dan kunci Anda.

Memilih model terpusat atau terdesentralisasi

AWS merekomendasikan agar Anda menggunakan beberapa akun Akun AWS dan mengelola akun tersebut sebagai satu organisasi AWS Organizations. Ada dua pendekatan luas untuk mengelola AWS KMS keys di lingkungan multi-akun.

Pendekatan pertama adalah pendekatan terdesentralisasi, di mana Anda membuat kunci di setiap akun yang menggunakan kunci tersebut. Saat Anda menyimpan kunci KMS di akun yang sama dengan sumber daya yang mereka lindungi, lebih mudah untuk mendelegasikan izin ke administrator lokal yang memahami persyaratan akses untuk kepala sekolah dan kunci mereka AWS . Anda dapat mengotorisasi penggunaan kunci hanya dengan menggunakan kebijakan kunci, atau Anda dapat menggabungkan kebijakan kunci dan kebijakan berbasis identitas di AWS Identity and Access Management (IAM).

Pendekatan kedua adalah pendekatan terpusat, di mana Anda mempertahankan kunci KMS dalam satu atau beberapa yang ditunjuk. Akun AWS Anda mengizinkan akun lain hanya menggunakan kunci untuk operasi kriptografi. Anda mengelola kunci, siklus hidupnya, dan izinnya dari akun terpusat. Anda mengizinkan Akun AWS orang lain untuk menggunakan kunci tetapi tidak mengizinkan izin lain. Akun eksternal tidak dapat mengelola apa pun tentang siklus hidup kunci atau izin akses. Model terpusat ini dapat membantu meminimalkan risiko penghapusan kunci yang tidak diinginkan atau eskalasi hak istimewa oleh administrator atau pengguna yang didelegasikan.

Opsi yang Anda pilih tergantung pada beberapa faktor. Pertimbangkan hal berikut saat memilih pendekatan:

1. Apakah Anda memiliki proses otomatis atau manual untuk menyediakan kunci dan akses sumber daya? Ini termasuk sumber daya seperti pipeline penyebaran dan templat infrastruktur sebagai kode (IAc). Alat-alat ini dapat membantu Anda menyebarkan dan mengelola sumber daya (seperti kunci KMS, kebijakan utama, peran IAM, dan kebijakan IAM) di banyak hal. Akun AWS Jika Anda tidak memiliki alat penyebaran ini, pendekatan terpusat untuk manajemen kunci mungkin lebih mudah dikelola untuk bisnis Anda.

2. Apakah Anda memiliki kontrol administratif atas semua Akun AWS yang berisi sumber daya yang menggunakan kunci KMS? Jika demikian, model terpusat dapat menyederhanakan manajemen dan menghilangkan kebutuhan untuk beralih Akun AWS untuk mengelola kunci. Perhatikan, bagaimanapun, bahwa peran IAM dan izin pengguna untuk menggunakan kunci masih harus dikelola per akun.

3. Apakah Anda perlu menawarkan akses untuk menggunakan kunci KMS Anda kepada pelanggan atau mitra yang memiliki sumber daya Akun AWS dan sumber daya mereka sendiri? Untuk kunci ini, pendekatan terpusat dapat mengurangi beban administrasi pada pelanggan dan mitra Anda.

4. Apakah Anda memiliki persyaratan otorisasi untuk akses ke AWS sumber daya yang lebih baik diselesaikan dengan pendekatan akses terpusat atau lokal? Misalnya, jika aplikasi atau unit bisnis yang berbeda bertanggung jawab untuk mengelola keamanan data mereka sendiri, pendekatan terdesentralisasi untuk manajemen kunci lebih baik.

5. Apakah Anda melebihi kuota sumber daya layanan untuk? AWS KMS Karena kuota ini ditetapkan per Akun AWS, model terdesentralisasi mendistribusikan beban di seluruh akun, secara efektif mengalikan kuota layanan.

   catatan

   Model manajemen untuk kunci tidak relevan ketika mempertimbangkan kuota permintaan karena kuota ini diterapkan pada prinsipal akun yang membuat permintaan terhadap kunci, bukan akun yang memiliki atau mengelola kunci.

Secara umum, kami menyarankan Anda memulai dengan pendekatan terdesentralisasi kecuali Anda dapat mengartikulasikan kebutuhan akan model kunci KMS terpusat.

Memilih kunci yang dikelola pelanggan, kunci AWS terkelola, atau kunci AWS yang dimiliki

Kunci KMS yang Anda buat dan kelola untuk digunakan dalam aplikasi kriptografi Anda sendiri dikenal sebagai kunci yang dikelola pelanggan. Layanan AWS dapat menggunakan kunci yang dikelola pelanggan untuk mengenkripsi data yang disimpan layanan atas nama Anda. Kunci yang dikelola pelanggan disarankan jika Anda ingin kontrol penuh atas siklus hidup dan penggunaan kunci Anda. Ada biaya bulanan untuk memiliki kunci yang dikelola pelanggan di akun Anda. Selain itu, permintaan untuk menggunakan atau mengelola kunci dikenakan biaya penggunaan. Untuk informasi selengkapnya, lihat harga AWS KMS.

Jika Anda Layanan AWS ingin mengenkripsi data Anda tetapi tidak ingin overhead atau biaya mengelola kunci, Anda dapat menggunakan kunci AWS terkelola. Jenis kunci ini ada di akun Anda, tetapi hanya dapat digunakan dalam keadaan tertentu. Ini hanya dapat digunakan dalam konteks tempat Layanan AWS Anda beroperasi, dan hanya dapat digunakan oleh kepala sekolah dalam akun yang berisi kunci. Anda tidak dapat mengelola apa pun tentang siklus hidup atau izin kunci ini. Beberapa Layanan AWS menggunakan kunci AWS terkelola. Format alias kunci AWS terkelola adalahaws/<service code>. Misalnya, aws/ebs kunci hanya dapat digunakan untuk mengenkripsi volume Amazon Elastic Block Store (Amazon EBS) di akun yang sama dengan kunci dan hanya dapat digunakan oleh prinsipal IAM di akun tersebut. Kunci AWS terkelola hanya dapat digunakan oleh pengguna di akun itu dan untuk sumber daya di akun itu. Anda tidak dapat membagikan sumber daya yang dienkripsi di bawah kunci AWS terkelola dengan akun lain. Jika ini adalah batasan untuk kasus penggunaan Anda, sebaiknya gunakan kunci yang dikelola pelanggan; Anda dapat membagikan penggunaan kunci itu dengan akun lain. Anda tidak dikenakan biaya untuk keberadaan kunci AWS terkelola di akun Anda, tetapi Anda dikenakan biaya untuk setiap penggunaan jenis kunci ini oleh Layanan AWS yang ditetapkan ke kunci.

Kunci AWS terkelola adalah tipe kunci lama yang tidak lagi dibuat untuk yang baru Layanan AWS pada tahun 2021. Sebagai gantinya, new (dan legacy) Layanan AWS menggunakan kunci yang AWS dimiliki untuk mengenkripsi data Anda secara default. AWS kunci yang dimiliki adalah kumpulan kunci KMS yang Layanan AWS dimiliki dan dikelola untuk digunakan dalam beberapa. Akun AWS Meskipun kunci ini tidak ada dalam Anda Akun AWS, Layanan AWS dapat menggunakannya untuk melindungi sumber daya di akun Anda.

Kami menyarankan Anda menggunakan kunci yang dikelola pelanggan saat kontrol granular paling penting dan menggunakan kunci yang AWS dimiliki saat kenyamanan paling penting.

Tabel berikut menjelaskan perbedaan kebijakan, pencatatan, manajemen, dan harga utama antara setiap jenis kunci. Untuk informasi selengkapnya tentang tipe kunci, lihat AWS KMS konsep.

Pertimbangan	Kunci yang dikelola pelanggan	AWS kunci terkelola	AWS kunci yang dimiliki
Kebijakan utama	Dikendalikan secara eksklusif oleh pelanggan	Dikendalikan oleh layanan; dapat dilihat oleh pelanggan	Dikontrol secara eksklusif dan hanya dapat dilihat oleh Layanan AWS yang mengenkripsi data Anda
Pencatatan log	AWS CloudTrail jejak pelanggan atau toko data acara	CloudTrail jejak pelanggan atau toko data acara	Tidak dapat dilihat oleh pelanggan
Manajemen siklus hidup	Pelanggan mengelola rotasi, penghapusan, dan Wilayah AWS	Layanan AWS mengelola rotasi (tahunan), penghapusan, dan Wilayah	Layanan AWS mengelola rotasi (tahunan), penghapusan, dan Wilayah
Penetapan Harga	Biaya bulanan untuk keberadaan kunci (pro-rated per jam); penelepon dikenakan biaya untuk penggunaan API	Tidak ada biaya untuk keberadaan kunci; penelepon dikenakan biaya untuk penggunaan API	Tidak ada biaya untuk pelanggan

Memilih toko AWS KMS kunci

Toko kunci adalah lokasi yang aman untuk menyimpan dan menggunakan bahan kunci kriptografi. Praktik terbaik industri untuk toko utama adalah dengan menggunakan perangkat yang dikenal sebagai modul keamanan perangkat keras (HSM) yang telah divalidasi di bawah NIST Federal Information Processing Standards (FIPS) 140 Cryptographic Module Validation Program di Security Level 3. Ada program lain untuk mendukung toko-toko utama yang digunakan untuk memproses pembayaran. AWS Payment Cryptographyadalah layanan yang dapat Anda gunakan untuk melindungi data yang terkait dengan beban kerja pembayaran Anda.

AWS KMS mendukung beberapa jenis penyimpanan kunci untuk membantu melindungi materi kunci Anda saat menggunakan AWS KMS untuk membuat dan mengelola kunci enkripsi Anda. Semua opsi penyimpanan utama yang disediakan oleh terus AWS KMS divalidasi di bawah FIPS 140 di Security Level 3. Mereka dirancang untuk mencegah siapa pun, termasuk AWS operator, mengakses kunci teks biasa Anda atau menggunakannya tanpa izin Anda. Untuk informasi selengkapnya tentang jenis toko utama yang tersedia, lihat Toko kunci dalam AWS KMS dokumentasi.

Toko kunci AWS KMS standar adalah pilihan terbaik untuk sebagian besar beban kerja. Jika Anda perlu memilih jenis toko kunci yang berbeda, pertimbangkan dengan cermat apakah peraturan atau persyaratan lain (seperti internal) mandat membuat pilihan ini, dan pertimbangkan dengan cermat biaya dan manfaatnya.

Menghapus dan menonaktifkan tombol KMS

Penghapusan kunci KMS dapat memiliki dampak yang signifikan. Sebelum Anda menghapus kunci KMS yang tidak lagi ingin Anda gunakan, pertimbangkan apakah cukup untuk mengatur status kunci ke Dinonaktifkan. Sementara kunci dinonaktifkan, itu tidak dapat digunakan untuk operasi kriptografi. Itu masih ada di AWS, dan Anda dapat mengaktifkannya kembali di masa depan jika diperlukan. Kunci yang dinonaktifkan terus dikenakan biaya penyimpanan. Kami menyarankan Anda menonaktifkan kunci alih-alih menghapusnya sampai Anda yakin bahwa kunci tersebut tidak melindungi data atau kunci data apa pun.

penting

Menghapus kunci harus direncanakan dengan cermat. Data tidak dapat didekripsi jika kunci yang sesuai telah dihapus. AWS tidak memiliki sarana untuk memulihkan kunci yang dihapus setelah dihapus. Seperti operasi penting lainnya di AWS, Anda harus menerapkan kebijakan yang membatasi siapa yang dapat menjadwalkan kunci untuk dihapus dan memerlukan otentikasi multi-faktor (MFA) untuk penghapusan kunci.

Untuk membantu mencegah penghapusan kunci yang tidak disengaja, AWS KMS memberlakukan periode tunggu minimum default tujuh hari setelah eksekusi DeleteKey panggilan sebelum menghapus kunci. Anda dapat mengatur masa tunggu ke nilai maksimum 30 hari. Selama masa tunggu, kunci masih disimpan AWS KMS dalam status Penghapusan Tertunda. Itu tidak dapat digunakan untuk mengenkripsi atau mendekripsi operasi. Setiap upaya untuk menggunakan kunci yang berada dalam status Penghapusan Tertunda untuk enkripsi atau dekripsi dicatat. AWS CloudTrail Anda dapat mengatur CloudWatch alarm Amazon untuk acara ini di CloudTrail log Anda. Jika Anda menerima alarm pada acara ini, Anda dapat memilih untuk membatalkan proses penghapusan jika diperlukan. Sampai masa tunggu berakhir, Anda dapat memulihkan kunci dari status Penghapusan Tertunda dan mengembalikannya ke status Dinonaktifkan atau Diaktifkan.

Penghapusan kunci Multi-region mengharuskan Anda menghapus replika sebelum salinan asli. Untuk informasi selengkapnya, lihat Menghapus kunci Multi-wilayah.

Jika Anda menggunakan kunci dengan bahan kunci impor, Anda dapat segera menghapus materi kunci yang diimpor. Ini berbeda dengan menghapus kunci KMS dalam beberapa cara. Saat Anda melakukan DeleteImportedKeyMaterial tindakan, AWS KMS menghapus materi kunci, dan status kunci berubah menjadi Impor tertunda. Setelah Anda menghapus materi kunci, kuncinya segera tidak dapat digunakan. Tidak ada masa tunggu. Untuk mengaktifkan penggunaan kunci lagi, Anda perlu mengimpor materi kunci yang sama lagi. Masa tunggu penghapusan kunci KMS juga berlaku untuk kunci KMS dengan bahan kunci impor.

Jika kunci data dilindungi oleh kunci KMS dan secara aktif digunakan oleh Layanan AWS, mereka tidak langsung terpengaruh jika kunci KMS terkait dinonaktifkan atau jika materi kunci yang diimpor dihapus. Misalnya, katakan bahwa kunci dengan bahan impor digunakan untuk mengenkripsi objek dengan SSE-KMS. Anda mengunggah objek ke bucket Amazon Simple Storage Service (Amazon S3) Simple Storage Service (Amazon S3). Sebelum Anda mengunggah objek ke bucket, Anda mengimpor materi ke kunci Anda. Setelah objek diunggah, Anda menghapus materi kunci yang diimpor dari kunci itu. Objek tetap berada di bucket dalam keadaan terenkripsi, tetapi tidak ada yang dapat mengakses objek sampai materi kunci yang dihapus diimpor kembali ke kunci. Meskipun aliran ini memerlukan otomatisasi yang tepat untuk mengimpor dan menghapus materi kunci dari kunci, ini dapat memberikan tingkat kontrol tambahan dalam suatu lingkungan.

AWS menawarkan panduan preskriptif untuk membantu Anda memantau dan memulihkan (jika perlu) penghapusan kunci KMS yang dijadwalkan. Untuk informasi selengkapnya, lihat Memantau dan memulihkan penghapusan kunci yang dijadwalkan. AWS KMS