Izin pemecahan masalah AWS KMS - AWS Key Management Service
Contoh 1: Pengguna ditolak akses ke KMS kunci di Akun AWSContoh 2: Pengguna mengasumsikan peran dengan izin untuk menggunakan KMS kunci di yang berbeda Akun AWS

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Izin pemecahan masalah AWS KMS

Saat mengotorisasi akses ke KMS kunci, AWS KMS evaluasi hal berikut:

  • Kebijakan kunci yang dilampirkan pada KMS kunci. Kebijakan kunci selalu didefinisikan di Akun AWS dan Wilayah yang memiliki KMS kunci.

  • Semua IAMkebijakan yang dilampirkan pada pengguna atau peran yang membuat permintaan. IAMkebijakan yang mengatur penggunaan KMS kunci oleh prinsipal selalu didefinisikan dalam prinsipal. Akun AWS

  • Semua hibah yang berlaku untuk KMS kunci.

  • Jenis kebijakan lain yang mungkin berlaku untuk permintaan untuk menggunakan KMS kunci, seperti kebijakan kontrol AWS Organizations layanan dan kebijakan VPC titik akhir. 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 KMS kunci diizinkan 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 yang menjelaskan 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 KMS kunci berdasarkan kebijakan utama, IAM kebijakan, hibah, dan kebijakan lain yang berlaku.

  • Kepercayaan kunci menentukan apakah Anda harus mempercayai KMS kunci yang diizinkan untuk Anda gunakan. Secara umum, Anda mempercayai sumber daya di Anda Akun AWS. Namun, Anda juga dapat merasa yakin tentang menggunakan KMS kunci yang berbeda Akun AWS jika hibah atau IAM kebijakan di akun Anda memungkinkan Anda untuk menggunakan KMS kunci tersebut.

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, diagram alur menunjukkan bahwa pemanggil dapat ditolak aksesnya dengan pernyataan eksplisit, atau dengan tidak adanya DENY pernyataan eksplisitALLOW, dalam kebijakan, IAM kebijakan, atau hibah utama.

Bagan alur dapat menjelaskan beberapa skenario izin umum.

Contoh 1: Pengguna ditolak akses ke KMS kunci di Akun AWS

Alice adalah IAM pengguna di Akun AWS 111122223333. Dia ditolak akses ke KMS kunci yang sama Akun AWS. Mengapa Alice tidak bisa menggunakan KMS kuncinya?

Dalam hal ini, Alice ditolak akses ke KMS kunci karena tidak ada kebijakan kunci, IAM kebijakan, atau hibah yang memberinya izin yang diperlukan. Kebijakan kunci dari KMS kunci memungkinkan IAM kebijakan Akun AWS untuk menggunakan untuk mengontrol akses ke KMS kunci, tetapi tidak ada IAM kebijakan yang memberikan izin kepada Alice untuk menggunakan KMS kunci tersebut.

Bagan alur yang menjelaskan proses evaluasi kebijakan

Pertimbangkan kebijakan yang relevan untuk contoh ini.

  • KMSKunci yang ingin digunakan Alice memiliki kebijakan kunci default. Kebijakan ini Akun AWS memungkinkan pemilik KMS kunci untuk menggunakan IAM kebijakan untuk mengontrol akses ke KMS kunci. Kebijakan kunci ini memenuhi kebijakan Apakah kunci yang digunakan ALLOW oleh penelepon untuk menggunakan IAM kebijakan untuk mengontrol akses ke kunci? kondisi di flowchart.

    {
  "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, IAM kebijakan, atau hibah yang memberikan izin kepada Alice untuk menggunakan KMS kunci tersebut. Oleh karena itu, Alice ditolak izinnya untuk menggunakan KMS kunci tersebut.

Tampilkan lebih banyakTampilkan lebih sedikit

Contoh 2: Pengguna mengasumsikan peran dengan izin untuk menggunakan KMS kunci di yang berbeda Akun AWS

Bob adalah pengguna di akun 1 (111122223333). Dia diizinkan untuk menggunakan KMS kunci di akun 2 (444455556666) dalam operasi kriptografi. Bagaimana ini mungkin?

Tip

Saat mengevaluasi izin lintas akun, ingatlah bahwa kebijakan kunci ditentukan di akun KMS kunci. IAMKebijakan ditentukan di akun pemanggil, bahkan ketika pemanggil berada di akun yang berbeda. Untuk detail tentang menyediakan akses lintas akun ke KMS kunci, lihatMemungkinkan pengguna di akun lain untuk menggunakan KMS kunci.

  • Kebijakan kunci untuk KMS kunci di akun 2 memungkinkan akun 2 menggunakan IAM kebijakan untuk mengontrol akses ke KMS kunci.

  • Kebijakan kunci untuk KMS kunci di akun 2 memungkinkan akun 1 untuk menggunakan KMS kunci dalam operasi kriptografi. Namun, akun 1 harus menggunakan IAM kebijakan untuk memberikan akses kepada prinsipalnya ke kunci. KMS

  • IAMKebijakan di akun 1 memungkinkan Engineering peran untuk menggunakan KMS kunci di akun 2 untuk operasi kriptografi.

  • Bob, pengguna di akun 1, memiliki izin untuk mengasumsikan peran Engineering.

  • Bob dapat mempercayai KMS kunci ini, karena meskipun tidak ada di akunnya, IAM kebijakan di akunnya memberinya izin eksplisit untuk menggunakan KMS kunci ini.

Bagan alur yang menjelaskan proses evaluasi kebijakan

Pertimbangkan kebijakan yang memungkinkan Bob, pengguna di akun 1, menggunakan KMS kunci di akun 2.

  • Kebijakan kunci untuk KMS kunci memungkinkan akun 2 (444455556666, akun yang memiliki KMS kunci) untuk menggunakan IAM kebijakan untuk mengontrol akses ke kunci. KMS Kebijakan kunci ini juga memungkinkan akun 1 (111122223333) untuk menggunakan KMS kunci dalam operasi kriptografi (ditentukan dalam elemen pernyataan kebijakan). Action Namun, tidak ada seorang pun di akun 1 yang dapat menggunakan KMS kunci di akun 2 hingga akun 1 mendefinisikan IAM kebijakan yang memberikan akses kepada prinsipal ke kunci tersebut. KMS

    Dalam diagram alur, kebijakan kunci di akun 2 ini memenuhi Apakah kebijakan kunci akun ALLOW pemanggil untuk menggunakan IAM kebijakan untuk mengontrol akses ke kunci? kondisi. 

    {
    "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": "*"
        }
    ]
}

  • IAMKebijakan dalam penelepon Akun AWS (akun 1, 111122223333) memberikan izin utama untuk melakukan operasi kriptografi menggunakan kunci di akun 2 (444455556666). KMS Elemen Action mendelegasikan akses yang sama yang diberikan kebijakan kunci di akun 2 ke akun 1 kepada perwakilan. Untuk memberikan izin ini ke peran Engineering dalam akun 1, kebijakan inline ini akan disematkan dalam peran Engineering.

    IAMKebijakan lintas akun seperti ini hanya efektif ketika kebijakan kunci untuk KMS kunci di akun 2 memberikan izin akun 1 untuk menggunakan KMS kunci. Selain itu, akun 1 hanya dapat memberikan izin perwakilannya untuk melakukan tindakan yang diberikan kebijakan kunci kepada akun.

    Dalam diagram alur, ini memenuhi Apakah IAM kebijakan mengizinkan pemanggil untuk melakukan tindakan ini? kondisi.

    {
    "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 Engineering dalam akun 1. AssumeRolePolicyDocument dalam peran memungkinkan Bob untuk mengasumsikan peran Engineering.

    {
    "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"
    }
}
Tampilkan lebih banyakTampilkan lebih sedikit