Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Logika evaluasi kebijakan Ketika seorang prinsipal mencoba menggunakan Konsol Manajemen AWS, AWS API, atau AWS CLI, prinsipal tersebut 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. 1. **[Memproses konteks permintaan](reference_policies_evaluation-logic_policy-eval-reqcontext.md)** AWS Memproses informasi yang dikumpulkan dalam permintaan untuk menentukan kebijakan mana yang berlaku untuk permintaan tersebut. 1. **[Bagaimana logika kode AWS penegakan mengevaluasi permintaan untuk mengizinkan atau menolak akses](reference_policies_evaluation-logic_policy-eval-denyallow.md)** AWS Mengevaluasi semua jenis kebijakan dan urutan kebijakan mempengaruhi bagaimana mereka dievaluasi. AWS kemudian memproses kebijakan terhadap konteks permintaan untuk menentukan apakah permintaan diizinkan atau ditolak. ## 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 gabungan dari izin dari kedua jenis. 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. ![\[Evaluasi kebijakan berbasis identitas dan kebijakan berbasis sumber daya\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/images/permissions_policies_effective.png) ## 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](access_policies_boundaries.md#access_policies_boundaries-eval-logic). ![\[Evaluasi kebijakan berbasis identitas dan batas izin.\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/images/permissions_boundary.png) ## Mengevaluasi kebijakan berbasis identitas dengan atau AWS Organizations SCPs RCPs Jika pengguna termasuk dalam akun yang merupakan anggota organisasi dan mengakses sumber daya yang tidak memiliki kebijakan berbasis sumber daya yang dikonfigurasi, izin yang dihasilkan adalah persimpangan kebijakan pengguna, kebijakan kontrol layanan (SCPs), dan kebijakan kontrol sumber daya (RCP). Ini berarti bahwa suatu tindakan harus diizinkan oleh ketiga jenis kebijakan. Penolakan eksplisit dalam kebijakan berbasis identitas, SCP, atau RCP mengesampingkan izin. ![\[Evaluasi kebijakan berbasis identitas dan atau SCPs RCPs\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/images/permissions_scp-idp.png) Anda dapat mempelajari [apakah akun Anda adalah anggota organisasi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_details.html#orgs_view_account) di AWS Organizations. Anggota organisasi mungkin terpengaruh oleh SCP atau RCP. Untuk melihat data ini menggunakan AWS CLI perintah atau operasi AWS API, Anda harus memiliki izin untuk `organizations:DescribeOrganization` tindakan untuk AWS Organizations entitas Anda. Anda harus memiliki izin tambahan untuk melakukan operasi di AWS Organizations konsol. Untuk mengetahui apakah SCP atau RCP menolak akses ke permintaan tertentu, atau untuk mengubah izin efektif Anda, hubungi administrator Anda. AWS Organizations # Memproses konteks permintaan *Ketika AWS mengevaluasi dan mengotorisasi permintaan, itu mengumpulkan informasi permintaan ke dalam konteks permintaan.* Konteks permintaan berisi informasi apa pun yang dapat digunakan dalam evaluasi kebijakan. + **Principal** — Pengguna, peran, atau prinsipal pengguna federasi yang mengirim permintaan. Informasi tentang prinsipal mencakup kebijakan yang terkait dengan prinsipal tersebut + **Tindakan** — Satu atau lebih tindakan yang ingin dilakukan kepala sekolah. + **Sumber Daya** — Satu atau lebih objek AWS sumber daya di mana tindakan atau operasi dilakukan. + **Data sumber daya** – Data terkait sumber daya yang diminta. Ini dapat mencakup informasi seperti nama tabel DynamoDB atau tag pada instans Amazon EC2. + **Data lingkungan** – Informasi tentang alamat IP, agen pengguna, status yang diaktifkan SSL, atau waktu hari. Informasi ini dibandingkan dengan kebijakan yang berlaku untuk menentukan apakah akan mengizinkan atau menolak permintaan. Anda dapat mengatur informasi properti ini menggunakan model **Principal**, **Action**, **Resource**, and **Condition** (PARC) untuk lebih memahami bagaimana AWS kebijakan dievaluasi. ## Memahami model PARC Model PARC mewakili konteks permintaan berdasarkan empat elemen JSON dalam bahasa kebijakan: + [Principal](reference_policies_elements_principal.md)Entitas yang membuat permintaan. Prinsipal mewakili pengguna manusia atau beban kerja terprogram yang dapat diautentikasi dan kemudian diberi wewenang untuk melakukan tindakan di. Akun AWS + [Action](reference_policies_elements_action.md)Operasi yang sedang dilakukan. Seringkali tindakan akan dipetakan ke tindakan API. + [Resource](reference_policies_elements_resource.md)— AWS Sumber daya di mana tindakan sedang dilakukan. + [Condition](reference_policies_elements_condition.md)— Kendala tambahan yang harus dipenuhi agar permintaan diizinkan. Berikut ini menunjukkan contoh bagaimana model PARC dapat mewakili konteks permintaan: ``` Principal: AIDA123456789EXAMPLE Action: s3:CreateBucket Resource: arn:aws:s3:::amzn-s3-demo-bucket1 Context: - aws:UserId=AIDA123456789EXAMPLE:BobsSession - aws:PrincipalAccount=123456789012 - aws:PrincipalOrgId=o-example - aws:PrincipalARN=arn:aws:iam::AIDA123456789EXAMPLE:role/HR - aws:MultiFactorAuthPresent=true - aws:CurrentTime=... - aws:EpochTime=... - aws:SourceIp=... - aws:PrincipalTag/dept=123 - aws:PrincipalTag/project=blue - aws:RequestTag/dept=123 ``` ## Pentingnya konteks permintaan Memahami konteks permintaan dan bagaimana berinteraksi dengan evaluasi kebijakan sangat penting untuk: + Memecahkan masalah akses + Merancang kebijakan yang efektif dan aman + Memahami cakupan penuh izin yang diberikan oleh kebijakan + Memprediksi hasil evaluasi kebijakan dalam skenario yang berbeda Dengan memvisualisasikan konteks permintaan menggunakan model PARC, Anda dapat lebih mudah memahami cara AWS membuat keputusan otorisasi dan merancang kebijakan Anda secara lebih efektif. ## Cara AWS menggunakan konteks permintaan Saat mengevaluasi kebijakan, AWS membandingkan informasi dalam konteks permintaan dengan informasi yang ditentukan dalam semua kebijakan yang berlaku. Ini termasuk kebijakan berbasis identitas, kebijakan berbasis sumber daya, batas izin IAM, Organizations, Organizations, dan kebijakan sesi. SCPs RCPs Untuk setiap jenis kebijakan, AWS gunakan konteks permintaan untuk memeriksa: + Apakah kebijakan berlaku untuk permintaan berdasarkan prinsipal. + Apakah tindakan yang diminta diizinkan pada sumber daya yang ditentukan. + Apakah kondisi yang ditentukan dalam kebijakan dipenuhi oleh konteks permintaan. Cara AWS mengevaluasi kebijakan tergantung pada jenis kebijakan yang berlaku untuk konteks permintaan. Jenis kebijakan ini tersedia untuk digunakan dalam satu Akun AWS. Untuk informasi selengkapnya tentang tipe kebijakan ini, lihat [Kebijakan dan izin di AWS Identity and Access Management](access_policies.md). Untuk mempelajari cara AWS mengevaluasi kebijakan untuk akses lintas akun, lihat. [Logika evaluasi kebijakan lintas akun](reference_policies_evaluation-logic-cross-account.md) + **AWS Organizations kebijakan kontrol sumber daya (RCPs)** - AWS Organizations RCPs tentukan izin maksimum yang tersedia untuk sumber daya dalam akun di organisasi atau unit organisasi (OU). RCPs berlaku untuk sumber daya di akun anggota dan memengaruhi izin efektif untuk kepala sekolah, termasuk Pengguna root akun AWS, terlepas dari apakah prinsipal tersebut milik organisasi Anda. RCPs tidak berlaku untuk sumber daya di akun manajemen organisasi dan panggilan yang dilakukan oleh peran terkait layanan. Jika RCP hadir, izin yang diberikan oleh kebijakan berbasis identitas dan berbasis sumber daya ke sumber daya di akun anggota Anda hanya efektif jika RCP mengizinkan tindakan tersebut. + **AWS Organizations kebijakan kontrol layanan (SCPs)** - AWS Organizations SCPs tentukan izin maksimum yang tersedia untuk prinsipal dalam akun di organisasi atau unit organisasi (OU). SCPs berlaku untuk kepala sekolah di akun anggota, termasuk masing-masing. Pengguna root akun AWS Jika SCP hadir, izin yang diberikan oleh kebijakan berbasis identitas dan berbasis sumber daya kepada kepala sekolah di akun anggota Anda hanya efektif jika SCP mengizinkan tindakan tersebut. Satu-satunya pengecualian adalah prinsip dalam akun manajemen organisasi dan peran terkait layanan. + Kebijakan berbasis **sumber daya — Kebijakan berbasis** sumber daya memberikan izin untuk prinsipal yang ditentukan dalam kebijakan. Izin menentukan apa yang dapat dilakukan oleh prinsipal dengan sumber daya yang memiliki kebijakan tersebut. + **Batas izin — Batas** izin adalah fitur yang menetapkan izin maksimum yang dapat diberikan oleh kebijakan berbasis identitas kepada entitas IAM (pengguna atau peran). Saat Anda menetapkan batas izin untuk entitas, entitas hanya dapat melakukan tindakan yang diizinkan oleh 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 informasi selengkapnya, lihat [Bagaimana logika kode AWS penegakan mengevaluasi permintaan untuk mengizinkan atau menolak akses](reference_policies_evaluation-logic_policy-eval-denyallow.md). + **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` + **Kebijakan sesi** — Kebijakan sesi adalah kebijakan yang Anda berikan sebagai parameter saat Anda membuat sesi sementara secara terprogram untuk peran atau sesi 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` Untuk informasi selengkapnya, lihat [Kebijakan sesi](access_policies.md#policies_session). Ingat, penolakan secara tegas dalam salah satu kebijakan ini membatalkan izin. **catatan** **AWS Organizations Kebijakan deklaratif** memungkinkan Anda untuk mendeklarasikan dan menerapkan konfigurasi yang Anda inginkan secara terpusat pada skala tertentu Layanan AWS di seluruh organisasi. Karena kebijakan deklaratif diterapkan secara langsung di tingkat layanan, kebijakan tersebut tidak berdampak langsung pada permintaan evaluasi kebijakan dan tidak disertakan dengan konteks permintaan. Untuk informasi selengkapnya, lihat [Kebijakan deklaratif](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) di Panduan AWS Organizations Pengguna. ## Contoh evaluasi kebijakan menggunakan model PARC Untuk mengilustrasikan bagaimana konteks permintaan berinteraksi dengan evaluasi kebijakan, mari pertimbangkan contoh kebijakan: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:CreateBucket", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1", "Condition": { "StringEquals": { "aws:PrincipalTag/dept": "123" } } } ] } ``` ------ Dalam contoh ini, kebijakan akan mengizinkan `CreateBucket` tindakan hanya jika konteks permintaan menyertakan `aws:PrincipalTag/dept` nilai “123" dan sumber daya cocok dengan nama `amzn-s3-demo-bucket1` bucket. Tabel berikut menunjukkan cara AWS menggunakan konteks permintaan untuk mengevaluasi kebijakan ini dan membuat keputusan otorisasi. | Kebijakan | Konteks permintaan | Hasil evaluasi | | --- | --- | --- | | 
"StringEquals": {
    "aws:PrincipalTag/dept": "123"
}
| 
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:  
    - aws:PrincipalTag/dept=123
| **Pertandingan** | | 
"StringEquals": {
    "aws:PrincipalTag/dept": "123"
}
| 
Principal: AIDA123456789EXAMPLE
Action: s3:DeleteBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:  
    - aws:PrincipalTag/dept=123
| **Tidak cocok** | | 
"StringEquals": {
    "aws:PrincipalTag/dept": "123"
}
| 
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:  
    - aws:PrincipalTag/dept=321
| **Tidak cocok** | | 
"StringEquals": {
    "aws:PrincipalTag/dept": "123"
}
| 
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
Tidak `aws:PrincipalTag` dalam permintaan. | **Tidak cocok** | # Bagaimana logika kode AWS penegakan mengevaluasi permintaan untuk mengizinkan atau menolak akses Kode AWS penegakan memutuskan apakah permintaan yang dikirim AWS harus diizinkan atau ditolak. AWS mengevaluasi semua kebijakan yang berlaku untuk konteks permintaan. Berikut ini adalah ringkasan logika evaluasi AWS kebijakan. + Secara default, semua permintaan ditolak secara implisit dengan pengecualian Pengguna root akun AWS, yang memiliki akses penuh. + Permintaan harus diizinkan secara eksplisit oleh kebijakan atau serangkaian kebijakan yang mengikuti logika evaluasi di bawah ini agar diizinkan. + Penolakan eksplisit mengesampingkan izin eksplisit. Evaluasi kebijakan dapat berbeda tergantung pada apakah permintaan tersebut berada dalam satu akun atau permintaan lintas akun. Untuk detail tentang bagaimana keputusan evaluasi kebijakan dibuat untuk peran IAM atau pengguna dalam satu akun, lihat[Evaluasi kebijakan untuk permintaan dalam satu akun](reference_policies_evaluation-logic_policy-eval-basics.md). Untuk detail tentang bagaimana keputusan evaluasi kebijakan dibuat untuk permintaan lintas akun, lihat[Logika evaluasi kebijakan lintas akun](reference_policies_evaluation-logic-cross-account.md). + **Evaluasi penolakan** – Secara default, semua permintaan ditolak. Ini disebut [penolakan implisit](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md). Kode AWS penegakan mengevaluasi semua kebijakan dalam akun yang berlaku untuk permintaan. Ini termasuk AWS Organizations SCPs dan RCPs, 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](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md). Jika kode penegakan menemukan bahkan satu penolakan eksplisit yang berlaku, kode penegakan mengembalikan keputusan akhir **Deny**. Jika tidak ada penolakan eksplisit, evaluasi kode penegakan hukum berlanjut. + **AWS Organizations RCPs**Kode penegakan mengevaluasi kebijakan pengendalian AWS Organizations sumber daya (RCPs) yang berlaku untuk permintaan. RCPs berlaku untuk sumber daya akun tempat RCPs dilampirkan. Jika kode penegakan hukum tidak menemukan `Allow` pernyataan yang berlaku di dalam RCPs, kode penegakan mengembalikan keputusan akhir **Deny**. Perhatikan bahwa kebijakan AWS terkelola yang `RCPFullAWSAccess` disebut secara otomatis dibuat dan dilampirkan ke setiap entitas di organisasi Anda termasuk root, setiap OU, dan Akun AWS kapan RCPs diaktifkan. `RCPFullAWSAccess`tidak bisa dilepaskan, jadi akan selalu ada `Allow` pernyataan. Jika tidak ada RCP, atau jika RCP mengizinkan tindakan yang diminta, evaluasi kode penegakan berlanjut. + **AWS Organizations SCPs**— Kode penegakan mengevaluasi kebijakan kontrol AWS Organizations layanan (SCPs) yang berlaku untuk permintaan. SCPs berlaku untuk kepala sekolah akun tempat dilampirkan. SCPs Jika kode penegakan hukum tidak menemukan `Allow` pernyataan yang berlaku di dalam SCPs, kode penegakan mengembalikan keputusan akhir **Deny**. Jika tidak ada SCP, atau jika SCP mengizinkan tindakan yang diminta, evaluasi kode penegakan berlanjut. + **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 akhir`Allow`, bahkan jika ada penolakan implisit dalam kebijakan berbasis identitas, batas izin, atau kebijakan sesi. `Allow` Untuk sebagian besar sumber daya, Anda hanya perlu eksplisit `Allow` untuk prinsipal baik dalam kebijakan berbasis identitas atau kebijakan berbasis sumber daya untuk memberikan akses. [Kebijakan kepercayaan peran IAM dan kebijakan](access_policies-cross-account-resource-access.md#access_policies-cross-account-delegating-resource-based-policies) [kunci KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) [adalah pengecualian untuk logika ini, karena mereka harus secara eksplisit mengizinkan akses untuk prinsipal.](reference_policies_elements_principal.md) Kebijakan berbasis sumber daya untuk layanan selain IAM dan AWS KMS mungkin juga memerlukan `Allow` pernyataan eksplisit dalam akun yang sama untuk memberikan akses. Untuk informasi selengkapnya, lihat dokumentasi untuk layanan spesifik yang sedang Anda kerjakan. Untuk permintaan evaluasi kebijakan akun tunggal, logika kebijakan berbasis sumber daya berbeda dari jenis kebijakan lainnya jika prinsipal yang ditentukan adalah pengguna IAM, peran IAM, atau prinsipal sesi. [Prinsipal sesi termasuk [sesi peran IAM](reference_policies_elements_principal.md#principal-role-session) atau prinsip pengguna federasi AWS STS .](reference_policies_elements_principal.md#sts-session-principals) 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. + **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 (\$1) di elemen Principal, kecuali kebijakan berbasis identitas berisi penolakan eksplisit. Untuk informasi selengkapnya, lihat [Kepala peran IAM](reference_policies_elements_principal.md#principal-roles). **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](reference_policies_elements_principal.md#principal-role-session). **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 ``` + **AWS STS federated user principal** — Sesi pengguna federasi adalah sesi yang dibuat dengan menelepon. [`GetFederationToken`](id_credentials_temp_request.md#api_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** ``` arn:aws:sts::111122223333:federated-user/exampleuser ``` + **Kebijakan berbasis identitas — Kode penegakan memeriksa kebijakan berbasis** identitas untuk kepala sekolah. 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 penegakan mengembalikan keputusan akhir Deny.** Jika ada pernyataan dalam kebijakan berbasis identitas yang berlaku yang memungkinkan tindakan yang diminta, evaluasi kode berlanjut. + **Batas izin IAM — Kode penegakan hukum 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 penegakan mengembalikan keputusan akhir **Deny**. Jika tidak ada batas izin, atau jika batas izin memungkinkan tindakan yang diminta, evaluasi kode berlanjut. + **Kebijakan sesi** — Kode penegakan memeriksa apakah prinsipal adalah kepala sesi. Prinsipal sesi termasuk sesi peran IAM atau sesi pengguna federasi AWS STS . Jika kepala sekolah bukan kepala sesi, kode penegakan mengembalikan keputusan akhir **Izinkan**. Untuk kepala sekolah sesi, kode penegakan memeriksa apakah kebijakan sesi disahkan dalam permintaan. Anda dapat meneruskan kebijakan sesi saat menggunakan AWS API AWS CLI atau untuk mendapatkan kredensi sementara untuk peran atau prinsipal pengguna AWS STS gabungan. Jika Anda tidak lulus kebijakan sesi, kebijakan sesi default akan dibuat dan kode penegakan akan mengembalikan keputusan akhir **Izinkan**. + Jika kebijakan sesi hadir dan tidak mengizinkan tindakan yang diminta, maka permintaan tersebut ditolak secara implisit. Kode penegakan mengembalikan keputusan akhir **Deny**. + Kode penegakan memeriksa apakah kepala sekolah adalah sesi peran. Jika kepala sekolah adalah sesi peran, maka permintaan tersebut **Diizinkan**. **Jika tidak, permintaan secara implisit ditolak dan kode penegakan mengembalikan keputusan akhir Deny.** + Jika kebijakan sesi hadir dan memungkinkan tindakan yang diminta, maka kode penegakan mengembalikan keputusan akhir **Izinkan**. # Evaluasi kebijakan untuk permintaan dalam satu akun ## Evaluasi kebijakan untuk peran IAM Diagram alir berikut memberikan rincian tentang bagaimana keputusan evaluasi kebijakan dibuat untuk peran IAM dalam satu akun. ![\[Diagram alur evaluasi untuk peran IAM dalam satu akun\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/images/PolicyEvaluationSingleAccountRole.png) ## Evaluasi kebijakan untuk pengguna IAM Diagram alir berikut memberikan rincian tentang bagaimana keputusan evaluasi kebijakan dibuat untuk pengguna IAM dalam satu akun. ![\[Diagram alur evaluasi untuk pengguna IAM dalam satu akun\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/images/PolicyevaluationSingleAccountUser.png) ## 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 `amzn-s3-demo-bucket-carlossalazar-logs`. Juga asumsikan bahwa kebijakan berikut ini diberlakukan pada pengguna IAM `carlossalazar`. ------ #### [ JSON ] **** ``` { "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:::amzn-s3-demo-bucket-carlossalazar/*", "arn:aws:s3:::amzn-s3-demo-bucket-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 `amzn-s3-demo-bucket-carlossalazar`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/carlossalazar" }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*", "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar" ] } ] } ``` ------ Kebijakan ini menetapkan bahwa hanya pengguna `carlossalazar` yang dapat mengakses bucket `amzn-s3-demo-bucket-carlossalazar`. Ketika Carlos membuat permintaannya untuk menyimpan file ke `amzn-s3-demo-bucket-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. ![\[Bagan alir evaluasi\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/images/EffectivePermissionsShort.png) 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 `amzn-s3-demo-bucket-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. 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. # 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 pengguna IAM-nya, prinsip pengguna AWS STS federasi, peran IAM, atau sesi peran yang dianggap. Anda juga dapat menentukan AWS layanan sebagai kepala sekolah. Untuk informasi selengkapnya, lihat [Cara menentukan kepala sekolah](reference_policies_elements_principal.md#Principal_specifying). Kebijakan berbasis identitas prinsipal harus mengizinkan akses yang diminta ke sumber daya dalam layanan kepercayaan. Anda dapat melakukan ini dengan menentukan ARN sumber daya. Di IAM, Anda dapat memberlakukan kebijakan berbasis sumber daya ke peran IAM agar prinsipal di akun lain dapat 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](access_policies-cross-account-resource-access.md). **penting** Layanan lain dapat memengaruhi logika evaluasi kebijakan. Misalnya, AWS Organizations mendukung [kebijakan kontrol layanan dan kebijakan](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) [kontrol sumber daya](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) yang dapat diterapkan pada prinsipal dan sumber daya dalam satu atau beberapa akun. AWS Resource Access Manager mendukung [fragmen kebijakan](https://docs.aws.amazon.com/ram/latest/userguide/permissions.html) yang mengontrol tindakan mana yang diizinkan dilakukan oleh prinsipal pada sumber daya yang dibagikan dengannya. ## 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](reference_policies_evaluation-logic_policy-eval-denyallow.md). Permintaan hanya diperbolehkan jika kedua evaluasi menghasilkan keputusan `Allow`. ![\[Evaluasi lintas akun\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/images/policy_cross-account-eval-simple.png) 1. Jika prinsipal di satu akun mengajukan permintaan untuk mengakses sumber daya di akun lain, ini adalah permintaan lintas akun. 1. Prinsipal mengajukan permohonan ada di akun tepercaya (`AccountA`). Saat AWS mengevaluasi akun ini, AWS memeriksa kebijakan berbasis identitas dan kebijakan apa pun yang dapat membatasi kebijakan berbasis identitas. Untuk informasi selengkapnya, lihat [Mengevaluasi kebijakan berbasis identitas dengan batas izin](reference_policies_evaluation-logic.md#policy-eval-basics-id-bound). 1. Sumber daya yang diminta ada di akun kepercayaan (`AccountB`). Saat AWS mengevaluasi akun ini, AWS memeriksa kebijakan berbasis sumber daya yang dilampirkan ke sumber daya yang diminta dan setiap kebijakan yang dapat membatasi kebijakan berbasis sumber daya. Untuk informasi selengkapnya, lihat [Mengevaluasi kebijakan berbasis identitas dengan kebijakan berbasis sumber daya](reference_policies_evaluation-logic.md#policy-eval-basics-id-rdp). 1. AWS mengizinkan permintaan hanya jika kedua evaluasi kebijakan akun mengizinkan permintaan tersebut. Diagram alir berikut memberikan ilustrasi yang lebih rinci tentang bagaimana keputusan evaluasi kebijakan dibuat untuk permintaan lintas akun. Sekali lagi, AWS izinkan permintaan hanya jika kedua evaluasi kebijakan akun mengizinkan permintaan tersebut. ![\[Evaluasi kebijakan lintas akun terperinci\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/images/PolicyEvaluationCrossAccount.png) ## 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 peran IAM 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 ini melekat pada peran `Demo` IAM. ------ #### [ JSON ] **** ``` { "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. ------ #### [ JSON ] **** ``` { "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 akun`111111111111`, 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](reference_policies_evaluation-logic_policy-eval-denyallow.md). Karena permintaan tersebut secara tegas ditolak di dalam salah satu akun, keputusan akhir adalah menolak permintaan tersebut. ![\[Permintaan ke amzn-s3- bucket demo-bucket-production-logs\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/images/policy_cross-account-eval-example.png) 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 akun`222222222222`. 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. ![\[Permintaan untuk bucket Produksi\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/images/policy_cross-account-eval-example-correct.png) # 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. `AllowGetList`Pernyataan **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**. `DenyReports`Pernyataan 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, seperti`iam:GenerateCredentialReport`, permintaan terkait laporan masih ditolak karena penolakan eksplisit ini. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowGetList", "Effect": "Allow", "Action": [ "iam:Get*", "iam:List*" ], "Resource": "*" }, { "Sid": "DenyReports", "Effect": "Deny", "Action": "iam:*Report", "Resource": "*" } ] } ``` ------