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

Logika evaluasi kebijakan lintas akun

Anda dapat mengizinkan prinsipal di satu akun untuk mengakses sumber daya di akun kedua. Hal ini dikenal sebagai akses lintas akun. Saat Anda mengizinkan akses lintas akun, akun yang memiliki prinsipal disebut akun tepercaya. Akun yang memiliki sumber daya disebut akun kepercayaan.

Untuk memungkinkan akses lintas akun, Anda melampirkan kebijakan berbasis sumber daya ke sumber daya yang ingin Anda bagikan. Anda juga harus melampirkan kebijakan berbasis identitas pada identitas yang bertindak sebagai kepala sekolah dalam permintaan. Kebijakan berbasis sumber daya dalam akun kepercayaan harus menyebutkan prinsipal akun tepercaya yang akan memiliki akses ke sumber daya tersebut. Anda dapat menentukan seluruh akun atau penggunanya, IAM pengguna gabungan, IAM peran, atau sesi peran yang dianggap. Anda juga dapat menentukan AWS layanan sebagai kepala sekolah. Untuk informasi selengkapnya, lihat Cara menentukan kepala sekolah.

Kebijakan berbasis identitas prinsipal harus mengizinkan akses yang diminta ke sumber daya dalam layanan kepercayaan. Anda dapat melakukan ini dengan menentukan ARN sumber daya.

DiIAM, Anda dapat melampirkan kebijakan berbasis sumber daya ke IAM peran untuk mengizinkan kepala sekolah di akun lain mengambil peran tersebut. Kebijakan berbasis sumber daya peran ini disebut kebijakan kepercayaan peran. Setelah mengambil peran tersebut, prinsipal yang diizinkan dapat menggunakan kredensial sementara yang dihasilkan untuk mengakses beberapa sumber daya dalam akun Anda. Akses ini ditetapkan dalam kebijakan izin berbasis identitas dari peran tersebut. Untuk mempelajari cara memungkinkan akses lintas akun menggunakan peran berbeda dengan mengizinkan akses lintas akun menggunakan kebijakan berbasis sumber daya lainnya, lihat Akses sumber daya lintas akun di IAM.

Menentukan apakah permintaan lintas akun diizinkan atau ditolak.

Untuk permintaan lintas akun, pemohon dalam AccountA tepercaya harus memiliki kebijakan berbasis identitas. Kebijakan yang harus memungkinkan mereka membuat permintaan ke sumber daya dalam AccountB kepercayaan. Selain itu, kebijakan berbasis sumber daya di AccountB harus mengizinkan pemohon di AccountA untuk mengakses sumber daya.

Saat Anda membuat permintaan lintas akun, AWS lakukan dua evaluasi. AWS mengevaluasi permintaan di akun kepercayaan dan akun tepercaya. Untuk informasi selengkapnya tentang bagaimana permintaan dievaluasi di satu akun, lihat Bagaimana logika kode AWS penegakan mengevaluasi permintaan untuk mengizinkan atau menolak akses. Permintaan hanya diperbolehkan jika kedua evaluasi menghasilkan keputusan Allow.

Contoh evaluasi kebijakan lintas akun

Contoh berikut menunjukkan skenario di mana peran dalam satu akun diberikan izin oleh kebijakan berbasis sumber daya di akun kedua.

Asumsikan bahwa Carlos adalah pengembang dengan IAM peran yang disebutkan Demo di akun 11111111111111. Dia ingin menyimpan file ke bucket Amazon S3 amzn-s3-demo-bucket-production-logs di akun 222222222222.

Asumsikan juga bahwa kebijakan berikut melekat pada Demo IAM peran tersebut.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ListRead",
            "Effect": "Allow",
            "Action": "s3:ListAllMyBuckets",
            "Resource": "*"
        },
        {
            "Sid": "AllowS3ProductionObjectActions",
            "Effect": "Allow",
            "Action": "s3:*Object*",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*"
        },
        {
            "Sid": "DenyS3Logs",
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::*log*",
                "arn:aws:s3:::*log*/*"
            ]
        }
    ]
}

Pernyataan AllowS3ListRead dalam kebijakan ini memungkinkan Carlos melihat daftar semua bucket di Amazon S3. Pernyataan AllowS3ProductionObjectActions memungkinkan Carlos sepenuhnya mengakses objek di bucket amzn-s3-demo-bucket-production.

Selain itu, kebijakan berbasis sumber daya berikut (disebut kebijakan buket) diberlakukan untuk bucket amzn-s3-demo-bucket-production di akun 222222222222.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject*",
                "s3:PutObject*",
                "s3:ReplicateObject",
                "s3:RestoreObject"
            ],
            "Principal": { "AWS": "arn:aws:iam::111111111111:role/Demo" },
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*"
        }
    ]
}

Kebijakan ini memungkinkan Demo peran untuk mengakses objek di amzn-s3-demo-bucket-production bucket. Peran dapat membuat dan mengedit, tetapi tidak menghapus objek di ember. Peran tidak dapat mengelola ember itu sendiri.

Ketika Carlos membuat permintaannya untuk menyimpan file ke amzn-s3-demo-bucket-production-logs ember, AWS tentukan kebijakan apa yang berlaku untuk permintaan tersebut. Dalam hal ini, kebijakan berbasis identitas yang melekat pada Demo peran adalah satu-satunya kebijakan yang berlaku di akun. 111111111111 Di akun 222222222222, tidak ada kebijakan berbasis sumber daya yang dilampirkan ke bucket amzn-s3-demo-bucket-production-logs. Ketika AWS mengevaluasi akun111111111111, ia mengembalikan keputusan. Deny Ini karena pernyataan DenyS3Logs dalam kebijakan berbasis identitas secara eksplisit menolak akses ke bucket log. Untuk informasi selengkapnya tentang bagaimana permintaan dievaluasi di satu akun, lihat Bagaimana logika kode AWS penegakan mengevaluasi permintaan untuk mengizinkan atau menolak akses.

Karena permintaan tersebut secara tegas ditolak di dalam salah satu akun, keputusan akhir adalah menolak permintaan tersebut.

Asumsikan bahwa Carlos kemudian menyadari kesalahannya dan mencoba menyimpan file ke ember. Production AWS pertama memeriksa akun 111111111111 untuk menentukan apakah permintaan diizinkan. Hanya kebijakan berbasis identitas yang berlaku, dan memungkinkan permintaan. AWS kemudian memeriksa akun222222222222. Hanya kebijakan berbasis sumber daya yang dilampirkan pada bucket Production yang berlaku, dan ini mengizinkan permintaan. Karena kedua akun mengizinkan permintaan tersebut, keputusan akhir adalah untuk mengizinkan permintaan tersebut.