Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Saat mengotorisasi akses ke kunci KMS, AWS KMS evaluasi hal berikut:
-
Kebijakan kunci yang dilampirkan pada kunci KMS. Kebijakan kunci selalu didefinisikan di Akun AWS dan Wilayah yang memiliki kunci KMS.
-
Semua kebijakan IAM yang dilampirkan pada pengguna atau peran yang membuat permintaan. Kebijakan IAM yang mengatur penggunaan kunci KMS oleh prinsipal selalu didefinisikan dalam prinsipal. Akun AWS
-
Semua hibah yang berlaku untuk kunci KMS.
-
Jenis kebijakan lain yang mungkin berlaku untuk permintaan untuk menggunakan kunci KMS, seperti kebijakan kontrol AWS Organizations layanan dan kebijakan titik akhir VPC. Kebijakan ini bersifat opsional dan mengaktifkan semua tindakan secara default, namun Anda dapat menggunakannya untuk membatasi izin yang diberikan kepada perwakilan.
AWS KMS mengevaluasi mekanisme kebijakan ini bersama-sama untuk menentukan apakah akses ke kunci KMS diperbolehkan atau ditolak. Untuk melakukan ini, AWS KMS gunakan proses yang mirip dengan yang digambarkan dalam diagram alur berikut. Bagan alur berikut memberikan representasi visual dari proses evaluasi kebijakan.
Bagan alur ini dibagi menjadi dua bagian. Bagian-bagian ini tampaknya berurutan, tetapi biasanya dievaluasi pada waktu yang sama.
-
Otorisasi penggunaan menentukan apakah Anda diizinkan untuk menggunakan kunci KMS berdasarkan kebijakan utama, kebijakan IAM, hibah, dan kebijakan lain yang berlaku.
-
Kepercayaan kunci menentukan apakah Anda harus mempercayai kunci KMS yang diizinkan untuk Anda gunakan. Secara umum, Anda mempercayai sumber daya di Anda Akun AWS. Namun, Anda juga dapat merasa yakin tentang menggunakan kunci KMS dalam hal yang berbeda Akun AWS jika hibah atau kebijakan IAM di akun Anda memungkinkan Anda untuk menggunakan kunci KMS.
Anda dapat menggunakan diagram alur ini untuk mengetahui mengapa penelepon diizinkan atau ditolak izin untuk menggunakan kunci KMS. Anda juga dapat menggunakannya untuk mengevaluasi kebijakan dan pemberian izin. Misalnya, bagan alur menunjukkan bahwa pemanggil dapat ditolak aksesnya oleh pernyataan DENY eksplisit, atau dengan tidak adanya pernyataan ALLOW eksplisit, dalam kebijakan kunci, kebijakan IAM, atau pemberian izin.
Bagan alur dapat menjelaskan beberapa skenario izin umum.
Contoh Izin
Contoh 1: Pengguna ditolak akses ke kunci KMS di Akun AWS
Alice adalah pengguna IAM di 111122223333. Akun AWS Dia ditolak akses ke kunci KMS dalam hal yang sama Akun AWS. Mengapa Alice tidak bisa menggunakan tombol KMS?
Dalam hal ini, Alice ditolak akses ke kunci KMS karena tidak ada kebijakan kunci, kebijakan IAM, atau hibah yang memberinya izin yang diperlukan. Kebijakan kunci kunci KMS memungkinkan Akun AWS untuk menggunakan kebijakan IAM untuk mengontrol akses ke kunci KMS, tetapi tidak ada kebijakan IAM yang memberikan izin kepada Alice untuk menggunakan kunci KMS.
Pertimbangkan kebijakan yang relevan untuk contoh ini.
-
Kunci KMS yang ingin digunakan Alice memiliki kebijakan kunci default. Kebijakan ini memungkinkan pemilik Akun AWS kunci KMS untuk menggunakan kebijakan IAM untuk mengontrol akses ke kunci KMS. Kebijakan kunci ini memenuhi syarat Apakah kebijakan kunci MENGIZINKAN akun pemanggil menggunakan kebijakan IAM untuk mengontrol akses ke kunci? dalam bagan alur.
{ "Version" : "2012-10-17", "Id" : "key-test-1", "Statement" : [ { "Sid" : "Delegate to IAM policies", "Effect" : "Allow", "Principal" : { "AWS" : "arn:aws:iam::111122223333:root" }, "Action" : "kms:*", "Resource" : "*" } ] } -
Namun, tidak ada kebijakan kunci, kebijakan IAM, atau hibah yang memberikan izin kepada Alice untuk menggunakan kunci KMS. Oleh karena itu, Alice ditolak izinnya untuk menggunakan kunci KMS.
Contoh 2: Pengguna mengasumsikan peran dengan izin untuk menggunakan kunci KMS dalam yang berbeda Akun AWS
Bob adalah pengguna di akun 1 (111122223333). Dia diizinkan untuk menggunakan kunci KMS di akun 2 (444455556666) dalam operasi kriptografi. Bagaimana ini mungkin?
Tip
Saat mengevaluasi izin lintas akun, ingatlah bahwa kebijakan kunci ditentukan dalam akun kunci KMS. Kebijakan IAM ditentukan dalam akun pemanggil, bahkan ketika pemanggil berada dalam akun yang berbeda. Untuk detail tentang menyediakan akses lintas akun ke kunci KMS, lihat. Memungkinkan pengguna di akun lain untuk menggunakan kunci KMS
-
Kebijakan kunci untuk kunci KMS di akun 2 memungkinkan akun 2 menggunakan kebijakan IAM untuk mengontrol akses ke kunci KMS.
-
Kebijakan kunci untuk kunci KMS di akun 2 memungkinkan akun 1 untuk menggunakan kunci KMS dalam operasi kriptografi. Namun, akun 1 harus menggunakan kebijakan IAM untuk memberikan akses prinsipal ke kunci KMS.
-
Kebijakan IAM di akun 1 memungkinkan
Engineeringperan untuk menggunakan kunci KMS di akun 2 untuk operasi kriptografi. -
Bob, pengguna di akun 1, memiliki izin untuk mengasumsikan peran
Engineering. -
Bob dapat mempercayai kunci KMS ini, karena meskipun tidak ada di akunnya, kebijakan IAM di akunnya memberinya izin eksplisit untuk menggunakan kunci KMS ini.
Pertimbangkan kebijakan yang memungkinkan Bob, pengguna di akun 1, menggunakan kunci KMS di akun 2.
-
Kebijakan kunci untuk kunci KMS memungkinkan akun 2 (444455556666, akun yang memiliki kunci KMS) untuk menggunakan kebijakan IAM untuk mengontrol akses ke kunci KMS. Kebijakan kunci ini juga memungkinkan akun 1 (111122223333) untuk menggunakan kunci KMS dalam operasi kriptografi (ditentukan dalam elemen pernyataan kebijakan).
ActionNamun, tidak ada seorang pun di akun 1 yang dapat menggunakan kunci KMS di akun 2 hingga akun 1 mendefinisikan kebijakan IAM yang memberikan akses kepada prinsipal ke kunci KMS.Dalam bagan alur, kebijakan kunci ini di akun 2 memenuhi syaratApakah kebijakan kunci memungkinkan akun pemanggil menggunakan kebijakan IAM untuk mengontrol akses ke kunci?.
{ "Id": "key-policy-acct-2", "Version": "2012-10-17", "Statement": [ { "Sid": "Permission to use IAM policies", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::444455556666:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow account 1 to use this KMS key", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncryptFrom", "kms:ReEncryptTo", "kms:GenerateDataKey", "kms:GenerateDataKeyWithoutPlaintext", "kms:DescribeKey" ], "Resource": "*" } ] } -
Kebijakan IAM di penelepon Akun AWS (akun 1, 111122223333) memberikan izin utama untuk melakukan operasi kriptografi menggunakan kunci KMS di akun 2 (444455556666). Elemen
Actionmendelegasikan akses yang sama yang diberikan kebijakan kunci di akun 2 ke akun 1 kepada perwakilan. Untuk memberikan izin ini ke peranEngineeringdalam akun 1, kebijakan inline ini akan disematkan dalam peranEngineering.Kebijakan IAM lintas akun seperti ini hanya efektif jika kebijakan kunci untuk kunci KMS di akun 2 memberikan izin akun 1 untuk menggunakan kunci KMS. Selain itu, akun 1 hanya dapat memberikan izin perwakilannya untuk melakukan tindakan yang diberikan kebijakan kunci kepada akun.
Dalam bagan alur, ini memenuhi syarat Apakah kebijakan IAM mengizinkan pemanggil untuk melakukan tindakan ini?.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncryptFrom", "kms:ReEncryptTo", "kms:GenerateDataKey", "kms:GenerateDataKeyWithoutPlaintext", "kms:DescribeKey" ], "Resource": [ "arn:aws:kms:us-west-2:444455556666:key/1234abcd-12ab-34cd-56ef-1234567890ab" ] } ] } -
Elemen terakhir yang dibutuhkan adalah penentuan peran
Engineeringdalam akun 1.AssumeRolePolicyDocumentdalam peran memungkinkan Bob untuk mengasumsikan peranEngineering.{ "Role": { "Arn": "arn:aws:iam::111122223333:role/Engineering", "CreateDate": "2019-05-16T00:09:25Z", "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": { "Principal": { "AWS": "arn:aws:iam::111122223333:user/bob" }, "Effect": "Allow", "Action": "sts:AssumeRole" } }, "Path": "/", "RoleName": "Engineering", "RoleId": "AROA4KJY2TU23Y7NK62MV" } }
