Logika evaluasi kebijakan

Ketika kepala sekolah mencoba menggunakan AWS Management Console, AWS API, atau, prinsipal tersebut AWS CLI mengirimkan permintaan ke AWS. Ketika AWS layanan menerima permintaan, AWS selesaikan beberapa langkah untuk menentukan apakah akan mengizinkan atau menolak permintaan tersebut.

1. Otentikasi — AWS pertama mengotentikasi prinsipal yang membuat permintaan, jika perlu. Langkah ini tidak diperlukan untuk beberapa layanan, seperti Amazon S3 yang memungkinkan beberapa permintaan dari pengguna anonim.

2. Memproses konteks permintaan AWS Memproses informasi yang dikumpulkan dalam permintaan untuk menentukan kebijakan mana yang berlaku untuk permintaan tersebut.

3. Mengevaluasi kebijakan dalam satu akun AWS Mengevaluasi semua jenis kebijakan, yang mempengaruhi urutan di mana kebijakan dievaluasi.

4. Menentukan apakah permintaan diizinkan atau ditolak dalamsebuah akun.— AWS kemudian memproses kebijakan terhadap konteks permintaan untuk menentukan apakah permintaan diizinkan atau ditolak.

Memproses konteks permintaan

AWS memproses permintaan untuk mengumpulkan informasi berikut ke dalam konteks permintaan:

• Tindakan (atau operasi) – Tindakan atau operasi yang ingin dilakukan oleh prinsipal.

• Resources — Objek AWS sumber daya di mana tindakan atau operasi dilakukan.

• Prinsipal – Pengguna, peran, pengguna gabungan, atau aplikasi yang mengirimkan permintaan tersebut. Informasi tentang prinsipal mencakup kebijakan yang terkait dengan prinsipal tersebut

• Data lingkungan – Informasi tentang alamat IP, agen pengguna, status yang diaktifkan SSL, atau waktu hari.

• Data sumber daya – Data terkait sumber daya yang diminta. Ini dapat mencakup informasi seperti nama tabel DynamoDB atau tag pada instans Amazon EC2.

AWS kemudian menggunakan informasi ini untuk menemukan kebijakan yang berlaku untuk konteks permintaan.

Mengevaluasi kebijakan dalam satu akun

Cara AWS mengevaluasi kebijakan tergantung pada jenis kebijakan yang berlaku untuk konteks permintaan. Jenis kebijakan berikut, yang tercantum dalam urutan frekuensi, tersedia untuk digunakan dalam satu Akun AWS. Untuk informasi selengkapnya tentang tipe kebijakan ini, lihat Kebijakan dan Izin di IAM. Untuk mempelajari cara AWS mengevaluasi kebijakan untuk akses lintas akun, lihat. Logika evaluasi kebijakan lintas akun

1. Kebijakan berbasis identitas – Kebijakan berbasis identitas diterapkan pada identitas IAM (pengguna, kelompok pengguna, atau peran) dan memberikan izin kepada entitas IAM (pengguna dan peran). Jika hanya kebijakan berbasis identitas yang berlaku untuk permintaan, maka AWS periksa semua kebijakan tersebut untuk setidaknya satu. Allow

2. Kebijakan berbasis sumber daya — Kebijakan berbasis sumber daya memberikan izin kepada prinsipal (akun, pengguna, peran, dan kepala sesi seperti sesi peran dan pengguna gabungan IAM) yang ditentukan sebagai prinsipal. Izin menentukan apa yang dapat dilakukan oleh prinsipal dengan sumber daya yang memiliki kebijakan tersebut. Jika kebijakan berbasis sumber daya dan kebijakan berbasis identitas berlaku untuk permintaan, AWS periksa setidaknya satu kebijakan. Allow Ketika kebijakan berbasis sumber daya dievaluasi, ARN utama yang ditentukan dalam kebijakan menentukan apakah penolakan implisit dalam jenis kebijakan lain berlaku untuk keputusan akhir.

3. Batas izin IAM – Batas izin adalah fitur lanjutan yang mengatur izin maksimum yang dapat diberikan oleh kebijakan berbasis identitas kepada entitas IAM (pengguna atau peran). Saat Anda menetapkan batas izin untuk suatu entitas, entitas hanya dapat melakukan tindakan yang diizinkan oleh kedua kebijakan berbasis identitas dan batas izinnya. Dalam beberapa kasus, penolakan implisit dalam batas izin dapat membatasi izin yang diberikan oleh kebijakan berbasis sumber daya. Untuk mempelajari lebih lanjut, lihat Menentukan apakah permintaan diizinkan atau ditolak dalamsebuah akun. nanti dalam topik ini.

4. AWS Organizations Service Control Policies (SCPs) — Organizations SCP menentukan izin maksimum untuk organisasi atau unit organisasi (OU). Maksimum SCP berlaku untuk prinsipal di akun anggota, termasuk masing-masing. Pengguna root akun AWS Jika SCP ada, kebijakan berbasis identitas dan berbasis sumber daya memberikan izin kepada prinsipal dalam akun anggota hanya jika kebijakan tersebut dan SCP mengizinkan tindakan. Jika kedua batas izin dan SCP ada, maka batas, SCP, dan kebijakan berbasis identitas semuanya harus mengizinkan tindakan.

5. Kebijakan sesi – Kebijakan sesi adalah kebijakan tingkat lanjut yang Anda teruskan sebagai parameter saat Anda secara terprogram membuat sesi sementara untuk pengguna peran atau pengguna gabungan. Untuk membuat sesi peran secara terprogram, gunakan salah satu operasi API AssumeRole*. Saat Anda melakukan ini dan meneruskan kebijakan sesi, izin sesi yang dihasilkan adalah perpotongan antara kebijakan berbasis identitas entitas IAM dan kebijakan sesi. Untuk membuat sesi pengguna federasi, Anda menggunakan kunci akses pengguna IAM untuk memanggil operasi API secara terprogram. GetFederationToken Kebijakan berbasis sumber daya memiliki efek yang berbeda pada evaluasi izin kebijakan sesi. Perbedaannya bergantung pada apakah ARN pengguna atau peran atau ARN sesi dicantumkan sebagai prinsip utama dalam kebijakan berbasis sumber daya. Untuk informasi selengkapnya, lihat Kebijakan sesi.

Ingat, penolakan secara tegas dalam salah satu kebijakan ini membatalkan izin.

Mengevaluasi kebijakan berbasis identitas dengan kebijakan berbasis sumber daya

Kebijakan berbasis identitas dan kebijakan berbasis sumber daya memberikan izin kepada identitas atau sumber daya yang melekat padanya. Ketika entitas IAM (pengguna atau peran) meminta akses ke sumber daya dalam akun yang sama, AWS mengevaluasi semua izin yang diberikan oleh kebijakan berbasis identitas dan sumber daya. Izin yang dihasilkan adalah izin total dari dua tipe. Jika suatu tindakan diizinkan oleh kebijakan berbasis identitas, kebijakan berbasis sumber daya, atau keduanya, maka izinkan tindakan tersebut. AWS Penolakan secara tegas dalam salah satu kebijakan ini membatalkan izin.

Mengevaluasi kebijakan berbasis identitas dengan batas izin

Saat AWS mengevaluasi kebijakan berbasis identitas dan batas izin untuk pengguna, izin yang dihasilkan adalah persimpangan dari dua kategori. Artinya ketika Anda menambahkan batas izin ke pengguna dengan kebijakan berbasis identitas yang ada, Anda mungkin mengurangi tindakan yang dapat dilakukan pengguna. Atau, saat Anda menghapus batas izin dari pengguna, Anda mungkin meningkatkan tindakan yang dapat mereka lakukan. Penolakan secara tegas dalam salah satu kebijakan ini membatalkan izin. Untuk melihat informasi tentang cara tipe kebijakan lain dievaluasi dengan batas izin, lihat Mengevaluasi izin efektif dengan batasan.

Mengevaluasi kebijakan berbasis identitas dengan Organizations SCP

Ketika pengguna memiliki akun yang merupakan anggota dari sebuah organisasi, izin yang dihasilkan adalah perpotongan kebijakan pengguna dan SCP. Ini berarti bahwa tindakan harus diizinkan oleh kebijakan berbasis identitas dan SCP. Penolakan secara tegas dalam salah satu kebijakan ini membatalkan izin.

Anda dapat mempelajari apakah akun Anda adalah anggota organisasi di AWS Organizations. Anggota organisasi dapat dipengaruhi oleh SCP. Untuk melihat data ini menggunakan AWS CLI perintah atau operasi AWS API, Anda harus memiliki izin untuk organizations:DescribeOrganization tindakan untuk entitas Organizations Anda. Anda harus memiliki izin tambahan untuk melakukan operasi di konsol Organisasi. Untuk mengetahui apakah SCP menolak akses ke permintaan tertentu, atau untuk mengubah izin efektif Anda, hubungi administrator Anda. AWS Organizations

Menentukan apakah permintaan diizinkan atau ditolak dalamsebuah akun.

Asumsikan bahwa prinsipal mengirimkan permintaan AWS untuk mengakses sumber daya di akun yang sama dengan entitas prinsipal. Kode AWS penegakan memutuskan apakah permintaan tersebut harus diizinkan atau ditolak. AWS mengevaluasi semua kebijakan yang berlaku untuk konteks permintaan. Berikut ini adalah ringkasan logika AWS evaluasi untuk kebijakan dalam satu akun.

• Secara default, semua permintaan ditolak secara implisit dengan pengecualian Pengguna root akun AWS, yang memiliki akses penuh.

• Izin eksplisit dalam kebijakan berbasis identitas atau berbasis sumber daya akan membatalkan pengaturan default ini.

• Jika ada batasan izin, Organisasi SCP, atau kebijakan sesi ada, hal ini dapat mengesampingkan izin dengan penolakan implisit.

• Penolakan secara tegas dalam kebijakan apa pun akan mengesampingkan izin apa pun.

Bagan alir berikut ini memberikan perincian tentang cara pengambilan keputusan. Diagram alir ini tidak mencakup dampak kebijakan berbasis sumber daya dan penolakan implisit dalam jenis kebijakan lainnya.

1. Evaluasi penolakan – Secara default, semua permintaan ditolak. Ini disebut penolakan implisit. Kode AWS penegakan mengevaluasi semua kebijakan dalam akun yang berlaku untuk permintaan. Ini termasuk AWS Organizations SCP, kebijakan berbasis sumber daya, kebijakan berbasis identitas, batas izin IAM, dan kebijakan sesi. Dalam semua kebijakan tersebut, kode penegakan mencari pernyataan Deny yang berlaku untuk permintaan. Ini disebut penolakan secara tegas. Jika kode penegakan menemukan bahkan satu penolakan eksplisit yang berlaku, kode mengembalikan keputusan akhir Deny. Jika tidak ada penolakan eksplisit, evaluasi kode penegakan hukum berlanjut.

2. Organizations SCP — Kemudian kode penegakan mengevaluasi kebijakan kontrol AWS Organizations layanan (SCP) yang berlaku untuk permintaan. SCP berlaku untuk prinsipal akun tempat SCP dilampirkan. Jika kode penegakan tidak menemukan Allow pernyataan yang berlaku di SCP, permintaan tersebut ditolak secara eksplisit, bahkan jika penolakan tersebut tersirat. Kode penegakan mengembalikan keputusan akhir Deny. Jika tidak ada SCP, atau jika SCP mengizinkan tindakan yang diminta, evaluasi kode penegakan berlanjut.

3. Kebijakan berbasis sumber daya — Dalam akun yang sama, kebijakan berbasis sumber daya berdampak pada evaluasi kebijakan secara berbeda tergantung pada jenis prinsipal yang mengakses sumber daya, dan prinsip yang diizinkan dalam kebijakan berbasis sumber daya. Bergantung pada jenis prinsipal, kebijakan berbasis sumber daya dapat menghasilkan keputusan akhirAllow, bahkan jika ada penolakan implisit dalam kebijakan berbasis identitas, batas izin, atau kebijakan sesi. Allow

   Untuk sebagian besar sumber daya, Anda hanya memerlukan izin eksplisit untuk prinsipal baik dalam kebijakan berbasis identitas atau kebijakan berbasis sumber daya untuk memberikan akses. Kebijakan kepercayaan peran IAM dan kebijakan kunci KMS adalah pengecualian untuk logika ini, karena mereka harus secara eksplisit mengizinkan akses untuk prinsipal.

   Logika kebijakan berbasis sumber daya berbeda dari jenis kebijakan lain jika prinsipal yang ditentukan adalah pengguna IAM, peran IAM, atau prinsipal sesi. Prinsipal sesi termasuk sesi peran IAM atau sesi pengguna federasi IAM. Jika kebijakan berbasis sumber daya memberikan izin langsung kepada pengguna IAM atau kepala sesi yang membuat permintaan, maka penolakan implisit dalam kebijakan berbasis identitas, batas izin, atau kebijakan sesi tidak memengaruhi keputusan akhir.

   Tabel berikut membantu Anda memahami dampak kebijakan berbasis sumber daya untuk tipe utama yang berbeda ketika penolakan implisit hadir dalam kebijakan berbasis identitas, batas izin, dan kebijakan sesi.

   Kebijakan berbasis sumber daya dan penolakan implisit dalam jenis kebijakan lain (akun yang sama)
   Prinsipal membuat permintaan	Kebijakan berbasis sumber daya	Kebijakan berbasis identitas	Batas izin	Kebijakan Sesi	Hasil	Alasan
   Peran IAM	Tidak berlaku	Tidak berlaku	Tidak berlaku	Tidak berlaku	Tidak berlaku	Peran itu sendiri tidak dapat membuat permintaan. Permintaan dibuat dengan sesi peran setelah peran diasumsikan.
   Sesi peran IAM	Memungkinkan peran ARN	Menyangkal secara implisit	Menyangkal secara implisit	Menyangkal secara implisit	DENY	Batas izin dan kebijakan sesi dievaluasi sebagai bagian dari keputusan akhir. Penyangkalan implisit di salah satu kebijakan menghasilkan keputusan DENY.
   	Memungkinkan sesi peran ARN	Menyangkal secara implisit	Menyangkal secara implisit	Menyangkal secara implisit	IZINKAN	Izin diberikan langsung ke sesi. Jenis kebijakan lain tidak mempengaruhi keputusan.
   Pengguna IAM	Mengizinkan ARN pengguna IAM	Menyangkal secara implisit	Menyangkal secara implisit	Tidak berlaku	IZINKAN	Izin diberikan langsung kepada pengguna. Jenis kebijakan lain tidak mempengaruhi keputusan.
   Pengguna federasi IAM () GetFederationToken	Mengizinkan ARN pengguna IAM	Menyangkal secara implisit	Menyangkal secara implisit	Menyangkal secara implisit	DENY	Penolakan implisit baik dalam batas izin atau kebijakan sesi menghasilkan DENY.
   	Mengizinkan ARN sesi pengguna federasi IAM	Menyangkal secara implisit	Menyangkal secara implisit	Menyangkal secara implisit	IZINKAN	Izin diberikan langsung ke sesi. Jenis kebijakan lain tidak mempengaruhi keputusan.
   pengguna root	Mengizinkan pengguna root ARN	Tidak berlaku	Tidak berlaku	Tidak berlaku	IZINKAN	Pengguna root memiliki akses lengkap dan tidak terbatas ke semua sumber daya di Anda Akun AWS. Untuk mempelajari cara mengontrol akses ke pengguna root untuk akun AWS Organizations, lihat Kebijakan kontrol layanan (SCP) di Panduan Pengguna Organizations.
   AWS layanan utama	Memungkinkan prinsipal AWS layanan	Tidak berlaku	Tidak berlaku	Tidak berlaku	IZINKAN	Ketika kebijakan berbasis sumber daya memberikan izin langsung ke kepala AWS layanan, jenis kebijakan lain tidak memengaruhi keputusan.

   • Peran IAM — Kebijakan berbasis sumber daya yang memberikan izin ke ARN peran IAM dibatasi oleh penolakan implisit dalam batas izin atau kebijakan sesi. Anda dapat menentukan peran ARN dalam elemen Principal atau kunci aws:PrincipalArn kondisi. Dalam kedua kasus tersebut, prinsipal yang membuat permintaan adalah sesi peran IAM.

     Batas izin dan kebijakan sesi tidak membatasi izin yang diberikan menggunakan kunci aws:PrincipalArn kondisi dengan wildcard (*) di elemen Principal, kecuali kebijakan berbasis identitas berisi penolakan eksplisit. Untuk informasi selengkapnya, lihat Kepala peran IAM.

     Contoh peran ARN

     arn:aws:iam::111122223333:role/examplerole

   • Sesi peran IAM — Dalam akun yang sama, kebijakan berbasis sumber daya yang memberikan izin ke sesi peran IAM ARN memberikan izin langsung ke sesi peran yang diasumsikan. Izin yang diberikan langsung ke sesi tidak dibatasi oleh penolakan implisit dalam kebijakan berbasis identitas, batas izin, atau kebijakan sesi. Ketika Anda mengambil peran dan membuat permintaan, kepala sekolah yang membuat permintaan adalah sesi peran IAM ARN dan bukan ARN dari peran itu sendiri. Untuk informasi selengkapnya, lihat Kepala sesi peran.

     Contoh sesi peran ARN

     arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname

   • Pengguna IAM — Dalam akun yang sama, kebijakan berbasis sumber daya yang memberikan izin kepada ARN pengguna IAM (yang bukan sesi pengguna gabungan) tidak dibatasi oleh penolakan implisit dalam kebijakan berbasis identitas atau batas izin.

     Contoh pengguna ARN IAM

     arn:aws:iam::111122223333:user/exampleuser

   • Sesi pengguna federasi IAM — Sesi pengguna federasi IAM adalah sesi yang dibuat dengan menelepon. GetFederationToken Ketika pengguna federasi membuat permintaan, kepala sekolah yang membuat permintaan adalah pengguna federasi ARN dan bukan ARN dari pengguna IAM yang berfederasi. Dalam akun yang sama, kebijakan berbasis sumber daya yang memberikan izin kepada pengguna federasi ARN memberikan izin langsung ke sesi. Izin yang diberikan langsung ke sesi tidak dibatasi oleh penolakan implisit dalam kebijakan berbasis identitas, batas izin, atau kebijakan sesi.

     Namun, jika kebijakan berbasis sumber daya memberikan izin kepada ARN pengguna IAM yang berfederasi, maka permintaan yang dibuat oleh pengguna federasi selama sesi dibatasi oleh penolakan implisit dalam batas izin atau kebijakan sesi.

     Contoh ARN sesi pengguna federasi IAM

     arn:aws:sts::111122223333:federated-user/exampleuser

4. Kebijakan berbasis identitas – Kemudian kode tersebut memeriksa kebijakan berbasis identitas untuk prinsipal. Untuk pengguna IAM, ini termasuk kebijakan pengguna dan kebijakan dari grup tempat pengguna berada. Jika tidak ada kebijakan berbasis identitas atau tidak ada pernyataan dalam kebijakan berbasis identitas yang memungkinkan tindakan yang diminta, maka permintaan tersebut ditolak secara implisit dan kode mengembalikan keputusan akhir Deny. Jika ada pernyataan dalam kebijakan berbasis identitas yang berlaku yang memungkinkan tindakan yang diminta, kode akan berlanjut.

5. Batas izin IAM — Kode kemudian memeriksa apakah entitas IAM yang digunakan oleh prinsipal memiliki batas izin. Jika kebijakan yang digunakan untuk menetapkan batas izin tidak mengizinkan tindakan yang diminta, maka permintaan tersebut ditolak secara implisit. Kode tersebut memberikan keputusan akhir Tolak. Jika tidak ada batasan izin, atau jika batas izin memungkinkan tindakan yang diminta, kode berlanjut.

6. Kebijakan sesi — Kode kemudian memeriksa apakah prinsipal adalah prinsipal sesi. Prinsipal sesi termasuk sesi peran IAM atau sesi pengguna federasi IAM. Jika kepala sekolah bukan kepala sesi, kode penegakan mengembalikan keputusan akhir Izinkan.

   Untuk prinsipal sesi, kode memeriksa apakah kebijakan sesi diteruskan dalam permintaan. Anda dapat meneruskan kebijakan sesi saat menggunakan AWS CLI atau AWS API untuk mendapatkan kredensil sementara untuk peran atau pengguna federasi IAM.

   • Jika kebijakan sesi hadir dan tidak mengizinkan tindakan yang diminta, maka permintaan tersebut ditolak secara implisit. Kode tersebut memberikan keputusan akhir Tolak.

   • Jika tidak ada kebijakan sesi, kode memeriksa apakah prinsipal adalah sesi peran. Jika kepala sekolah adalah sesi peran, maka permintaan tersebut Diizinkan. Jika tidak, permintaan secara implisit ditolak dan kode mengembalikan keputusan akhir Deny.

   • Jika kebijakan sesi hadir dan memungkinkan tindakan yang diminta, maka kode penegakan mengembalikan keputusan akhir Izinkan.

7. Kesalahan — Jika kode AWS penegakan menemukan kesalahan pada titik mana pun selama evaluasi, maka itu menghasilkan pengecualian dan menutup.

Contoh evaluasi kebijakan berbasis identitas dan kebijakan berbasis sumber daya

Tipe kebijakan yang paling umum adalah kebijakan berbasis identitas dan kebijakan berbasis sumber daya. Ketika akses ke sumber daya diminta, AWS evaluasi semua izin yang diberikan oleh kebijakan untuk setidaknya satu Izinkan dalam akun yang sama. Penolakan eksplisit dalam salah satu kebijakan mengesampingkan izin.

penting

Jika kebijakan berbasis identitas atau kebijakan berbasis sumber daya dalam akun yang sama mengizinkan permintaan dan yang lainnya tidak, permintaan tetap diizinkan.

Asumsikan bahwa Carlos memiliki nama pengguna carlossalazar dan dia mencoba menyimpan file ke bucket Amazon S3 carlossalazar-logs.

Juga asumsikan bahwa kebijakan berikut ini diberlakukan pada pengguna IAM carlossalazar.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ListRead",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowS3Self",
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::carlossalazar/*",
                "arn:aws:s3:::carlossalazar"
            ]
        },
        {
            "Sid": "DenyS3Logs",
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::*log*"
        }
    ]
}

Pernyataan AllowS3ListRead dalam kebijakan ini memungkinkan Carlos melihat daftar semua bucket di akun. Pernyataan AllowS3Self memungkinkan Carlos mendapatkan akses penuh ke bucket dengan nama yang sama dengan nama penggunanya. Pernyataan DenyS3Logs menolak akses Carlos ke setiap bucket S3 mana pun dengan log dalam namanya.

Selain itu, kebijakan berbasis sumber daya berikut (disebut kebijakan buket) dilampirkan ke bucket carlossalazar.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/carlossalazar"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::carlossalazar/*",
                "arn:aws:s3:::carlossalazar"
            ]
        }
    ]
}

Kebijakan ini menetapkan bahwa hanya pengguna carlossalazar yang dapat mengakses bucket carlossalazar.

Ketika Carlos membuat permintaannya untuk menyimpan file ke carlossalazar-logs ember, AWS tentukan kebijakan apa yang berlaku untuk permintaan tersebut. Dalam kasus ini, hanya kebijakan berbasis identitas dan kebijakan berbasis sumber daya yang berlaku. Keduanya adalah kebijakan izin. Karena batas izin tidak berlaku, logika evaluasi dikurangi ke logika berikut.

AWS pertama memeriksa Deny pernyataan yang berlaku untuk konteks permintaan. Ia menemukan satu, karena kebijakan berbasis identitas secara eksplisit menyangkal akses Carlos ke bucket S3 yang digunakan untuk logging. Akses Carlos ditolak.

Asumsikan bahwa dia kemudian menyadari kesalahannya dan mencoba menyimpan file ke carlossalazar ember. AWS memeriksa Deny pernyataan dan tidak menemukannya. Kemudian memeriksa kebijakan izin. Baik kebijakan berbasis identitas maupun kebijakan berbasis sumber daya mengizinkan permintaan tersebut. Oleh karena itu, AWS memungkinkan permintaan. Jika salah satu dari mereka menolak pernyataan tersebut secara tegas, permintaan tersebut akan ditolak. Jika salah satu tipe kebijakan mengizinkan permintaan tersebut dan tipe yang lainnya tidak, permintaan tersebut masih diperbolehkan.

Perbedaan antara penolakan tegas dan implisit.

Permintaan menghasilkan penolakan eksplisit jika kebijakan yang berlaku mencakup pernyataan Deny. Jika kebijakan yang berlaku untuk permintaan mencakup pernyataan Allow dan Deny, pernyataan Deny mengalahkan pernyataan Allow. Permintaan ditolak secara tegas.

Penolakan implisit terjadi saat tidak ada pernyataan Deny yang berlaku, tetapi juga tidak ada pernyataan Allow. Karena prinsipal IAM ditolak aksesnya secara default, mereka harus secara eksplisit diizinkan untuk melakukan tindakan. Jika tidak, akse pengguna akan ditolak secara implisit.

Saat Anda merancang strategi otorisasi, Anda harus membuat kebijakan dengan pernyataan Allow agar prinsipal Anda berhasil membuat permintaan. Namun, Anda dapat memilih kombinasi penyangkalan eksplisit dan implisit.

Misalnya, Anda dapat membuat kebijakan berikut yang mencakup tindakan yang diizinkan, tindakan yang ditolak secara implisit, dan tindakan yang ditolak secara eksplisit. AllowGetListPernyataan ini memungkinkan akses hanya-baca ke tindakan IAM yang dimulai dengan awalan dan. Get List Semua tindakan lain di IAM, seperti ditolak iam:CreatePolicy secara implisit. DenyReportsPernyataan tersebut secara eksplisit menolak akses ke laporan IAM dengan menolak akses ke tindakan yang menyertakan akhiran, seperti. Report iam:GetOrganizationsAccessReport Jika seseorang menambahkan kebijakan lain ke prinsipal ini untuk memberi mereka akses ke laporan IAM, sepertiiam:GenerateCredentialReport, permintaan terkait laporan masih ditolak karena penolakan eksplisit ini.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowGetList",
            "Effect": "Allow",
            "Action": [
                "iam:Get*",
                "iam:List*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DenyReports",
            "Effect": "Deny",
            "Action": "iam:*Report",
            "Resource": "*"
        }
    ]
}