Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Pemecahan masalah ABAC untuk AWS KMS
Mengontrol akses ke KMS kunci berdasarkan tag dan aliasnya nyaman dan kuat. Namun, ini rentan akan beberapa kesalahan yang dapat diprediksi yang ingin Anda cegah.
Akses berubah karena perubahan tag
Jika tag dihapus atau nilainya diubah, prinsipal yang memiliki akses ke KMS kunci hanya berdasarkan tag tersebut akan ditolak akses ke kunci tersebut. KMS Ini juga dapat terjadi ketika tag yang disertakan dalam pernyataan kebijakan penolakan ditambahkan ke KMS kunci. Menambahkan tag terkait kebijakan ke KMS kunci dapat memungkinkan akses ke prinsipal yang harus ditolak aksesnya ke kunci. KMS
Misalnya, misalkan prinsipal memiliki akses ke KMS kunci berdasarkan Project=Alpha tag, seperti izin yang diberikan oleh pernyataan IAM kebijakan contoh berikut.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "IAMPolicyWithResourceTag", "Effect": "Allow", "Action": [ "kms:GenerateDataKeyWithoutPlaintext", "kms:Decrypt" ], "Resource": "arn:aws:kms:ap-southeast-1:111122223333:key/*", "Condition": { "StringEquals": { "aws:ResourceTag/Project": "Alpha" } } } ] }
Jika tag dihapus dari KMS kunci tersebut atau nilai tag diubah, prinsipal tidak lagi memiliki izin untuk menggunakan KMS kunci untuk operasi yang ditentukan. Ini mungkin menjadi jelas ketika prinsipal mencoba membaca atau menulis data dalam AWS layanan yang menggunakan kunci yang dikelola pelanggan Untuk melacak perubahan tag, tinjau CloudTrail log TagResourceatau UntagResource entri Anda.
Untuk memulihkan akses tanpa memperbarui kebijakan, ubah tag pada KMS tombol. Tindakan ini memiliki dampak minimal selain jangka waktu singkat saat diterapkan di seluruh AWS KMS. Agar kesalahan seperti ini tidak terjadi, hanya berikan izin penandaan dan penghapusan tanda untuk perwakilan yang memerlukannya dan batasi izin penandaan untuk tag yang perlu dikelola.. Sebelum mengubah tag, cari kebijakan untuk mendeteksi akses yang bergantung pada tag, dan dapatkan KMS kunci di semua Wilayah yang memiliki tag. Anda dapat mempertimbangkan untuk membuat CloudWatch alarm Amazon ketika tag tertentu diubah.
Perubahan akses karena perubahan alias
Jika alias dihapus atau dikaitkan dengan KMS kunci yang berbeda, prinsipal yang memiliki akses ke KMS kunci hanya berdasarkan alias tersebut akan ditolak akses ke kunci tersebut. KMS Ini juga dapat terjadi ketika alias yang terkait dengan KMS kunci disertakan dalam pernyataan kebijakan penolakan. Menambahkan alias terkait kebijakan ke KMS kunci juga dapat memungkinkan akses ke kepala sekolah yang harus ditolak aksesnya ke kunci. KMS
Misalnya, pernyataan IAM kebijakan berikut menggunakan kms: ResourceAliases condition key untuk mengizinkan akses ke KMS kunci di Wilayah akun yang berbeda dengan alias yang ditentukan.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AliasBasedIAMPolicy", "Effect": "Allow", "Action": [ "kms:List*", "kms:Describe*", "kms:Decrypt" ], "Resource": "arn:aws:kms:*:111122223333:key/*", "Condition": { "ForAnyValue:StringEquals": { "kms:ResourceAliases": [ "alias/ProjectAlpha", "alias/ProjectAlpha_Test", "alias/ProjectAlpha_Dev" ] } } } ] }
Untuk melacak perubahan alias, tinjau CloudTrail log Anda untuk CreateAlias, UpdateAlias, dan DeleteAliasentri.
Untuk memulihkan akses tanpa memperbarui kebijakan, ubah alias yang terkait dengan KMS kunci. Karena setiap alias dapat dikaitkan dengan hanya satu KMS kunci di akun dan Wilayah, mengelola alias sedikit lebih sulit daripada mengelola tag. Memulihkan akses ke beberapa prinsipal pada satu KMS kunci dapat menolak akses prinsipal yang sama atau lainnya ke kunci yang berbeda. KMS
Agar kesalahan ini tidak terjadi, berikan izin manajemen alias hanya untuk perwakilan yang memerlukannya dan batasi izin manajemen-alias untuk alias yang perlu dikelola. Sebelum memperbarui atau menghapus alias, cari kebijakan untuk mendeteksi akses yang bergantung pada alias, dan temukan KMS kunci di semua Wilayah yang terkait dengan alias.
Akses ditolak karena kuota alias
Pengguna yang diberi wewenang untuk menggunakan KMS kunci dengan ResourceAliases kondisi kms: akan mendapatkan AccessDenied pengecualian jika KMS kunci melebihi alias default per kuota KMS kunci untuk akun dan Wilayah tersebut.
Untuk memulihkan akses, hapus alias yang terkait dengan KMS kunci sehingga sesuai dengan kuota. Atau gunakan mekanisme alternatif untuk memberi pengguna akses ke KMS kunci.
Perubahan otorisasi yang tertunda
Perubahan yang Anda buat pada tag dan alias mungkin membutuhkan waktu hingga lima menit untuk memengaruhi otorisasi KMS kunci. Akibatnya, perubahan tag atau alias mungkin tercermin dalam tanggapan dari API operasi sebelum mempengaruhi otorisasi. Penundaan ini kemungkinan akan lebih lama daripada penundaan konsistensi akhirnya singkat yang mempengaruhi sebagian besar AWS KMS operasi.
Misalnya, Anda mungkin memiliki IAM kebijakan yang memungkinkan prinsipal tertentu menggunakan KMS kunci apa pun dengan tag. "Purpose"="Test" Kemudian Anda menambahkan "Purpose"="Test" tag ke KMS kunci. Meskipun TagResourceoperasi selesai dan ListResourceTagsrespons mengonfirmasi bahwa tag ditetapkan ke KMS kunci, prinsipal mungkin tidak memiliki akses ke KMS kunci hingga lima menit.
Agar tidak terjadi kesalahan, buat perkiraan penundaan ke dalam kode Anda.
Permintaan gagal karena pembaruan alias
Saat memperbarui alias, Anda mengaitkan alias yang ada dengan kunci yang berbedaKMS.
Dekripsi dan ReEncryptpermintaan yang menentukan nama alias atau alias ARN mungkin gagal karena alias sekarang dikaitkan dengan KMS kunci yang tidak mengenkripsi ciphertext. Situasi ini biasanya menampilkan IncorrectKeyException atau NotFoundException. Atau jika permintaan tidak memiliki KeyId atau DestinationKeyId parameter, operasi mungkin gagal dengan AccessDenied pengecualian karena pemanggil tidak lagi memiliki akses ke KMS kunci yang mengenkripsi ciphertext.
Anda dapat melacak perubahan dengan melihat CloudTrail log untuk CreateAlias, UpdateAlias, dan entri DeleteAliaslog. Anda juga dapat menggunakan nilai LastUpdatedDate bidang dalam ListAliasesrespons untuk mendeteksi perubahan.
Misalnya, ListAliasescontoh respons berikut menunjukkan bahwa ProjectAlpha_Test alias dalam kms:ResourceAliases kondisi telah diperbarui. Akibatnya, kepala sekolah yang memiliki akses berdasarkan alias kehilangan akses ke kunci yang terkait sebelumnya. KMS Sebaliknya, mereka memiliki akses ke KMS kunci yang baru terkait.
$aws kms list-aliases --query 'Aliases[?starts_with(AliasName, `alias/ProjectAlpha`)]'{ "Aliases": [ { "AliasName": "alias/ProjectAlpha_Test", "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Test", "TargetKeyId": "0987dcba-09fe-87dc-65ba-ab0987654321", "CreationDate": 1566518783.394, "LastUpdatedDate": 1605308931.903 }, { "AliasName": "alias/ProjectAlpha_Restricted", "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Restricted", "TargetKeyId": "1234abcd-12ab-34cd-56ef-1234567890ab", "CreationDate": 1553410800.010, "LastUpdatedDate": 1553410800.010 } ] }
Memperbaiki perubahan ini tidaklah mudah. Anda dapat memperbarui alias lagi untuk mengaitkannya dengan KMS kunci asli. Namun, sebelum Anda bertindak, Anda perlu mempertimbangkan efek perubahan itu pada KMS kunci yang saat ini terkait. Jika kepala sekolah menggunakan KMS kunci terakhir dalam operasi kriptografi, mereka mungkin memerlukan akses lanjutan ke sana. Dalam hal ini, Anda mungkin ingin memperbarui kebijakan untuk memastikan bahwa kepala sekolah memiliki izin untuk menggunakan kedua kunci. KMS
Anda dapat mencegah kesalahan seperti ini: Sebelum memperbarui alias, cari kebijakan untuk mendeteksi akses yang bergantung pada alias. Kemudian dapatkan KMS kunci di semua Wilayah yang terkait dengan alias. Berikan izin manajemen alias hanya untuk perwakilan yang memerlukannya dan batasi izin manajemen-alias untuk alias yang perlu dikelola.
