Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Tutorial IAM: Tentukan izin untuk mengakses AWS sumber daya berdasarkan tag Kontrol akses berbasis atribut (ABAC) adalah strategi otorisasi yang menentukan izin berdasarkan atribut. Dalam AWS, atribut ini disebut *tag*. Anda dapat melampirkan tag ke sumber daya IAM, termasuk entitas IAM (pengguna atau peran) dan sumber daya. AWS Kemudian, Anda dapat menentukan kebijakan yang menggunakan kunci syarat tanda untuk memberikan izin kepada penanggung jawab Anda berdasarkan tanda mereka. Saat Anda menggunakan tag untuk mengontrol akses ke AWS sumber daya, Anda memungkinkan tim dan sumber daya tumbuh dengan lebih sedikit perubahan pada AWS kebijakan. Kebijakan ABAC lebih fleksibel daripada AWS kebijakan tradisional, yang mengharuskan Anda untuk mencantumkan setiap sumber daya individu. Untuk informasi selengkapnya tentang ABAC dan manfaatnya dibandingkan kebijakan tradisional, lihat [Tentukan izin berdasarkan atribut dengan otorisasi ABAC](introduction_attribute-based-access-control.md). **catatan** Anda harus memberikan satu nilai untuk setiap tag sesi. AWS Security Token Service tidak mendukung tag sesi multi-nilai. **Topics** + [ ## Ikhtisar tutorial ](#tutorial_attribute-based-access-control-overview) + [ ## Prasyarat ](#tutorial_abac_prereqs) + [ ## Langkah 1: Buat pengguna uji ](#tutorial_abac_step1) + [ ## Langkah 2: Buat kebijakan ABAC ](#tutorial_abac_step2) + [ ## Langkah 3: Buat peran ](#tutorial_abac_step3) + [ ## Langkah 4: Uji pembuatan rahasia ](#tutorial_abac_step4) + [ ## Langkah 5: Uji menampilkan rahasia ](#tutorial_abac_step5) + [ ## Langkah 6: Uji skalabilitas ](#tutorial_abac_step6) + [ ## Langkah 7: Uji memperbarui dan menghapus rahasia ](#tutorial_abac_step7) + [ ## Ringkasan ](#tutorial-abac-summary) + [ ## Sumber daya terkait ](#tutorial_abac_related) + [ # Tutorial IAM: Menggunakan tanda sesi SAML untuk ABAC ](tutorial_abac-saml.md) ## Ikhtisar tutorial Tutorial ini menunjukkan cara membuat dan menguji sebuah kebijakan yang memungkinkan peran IAM dengan tag penanggung jawab untuk mengakses sumberdaya dengan tag yang sesuai. Saat prinsipal mengajukan permintaan ke AWS, izin mereka diberikan berdasarkan apakah tanda prinsipal dan tanda sumber daya cocok. Strategi ini memungkinkan individu untuk melihat atau mengedit hanya AWS sumber daya yang diperlukan untuk pekerjaan mereka. **Skenario** Asumsikan bahwa Anda adalah pengembang utama di perusahaan besar bernama Perusahaan Contoh, dan Anda adalah administrator IAM berpengalaman. Anda akrab dengan membuat dan mengelola pengguna, peran, dan kebijakan IAM. Anda ingin memastikan bahwa anggota teknisi pengembangan dan tim jaminan kualitas Anda dapat mengakses sumber daya yang mereka butuhkan. Anda juga memerlukan strategi yang dapat menskalakan pertumbuhan perusahaan Anda. Anda memilih untuk menggunakan tag AWS sumber daya dan tag utama peran IAM untuk menerapkan strategi ABAC untuk layanan yang mendukungnya, dimulai dengan. AWS Secrets Manager Untuk mempelajari layanan mana yang mendukung otorisasi berdasarkan tanda, lihat [AWS layanan yang bekerja dengan IAM](reference_aws-services-that-work-with-iam.md). Untuk mempelajari kunci kondisi penandaan yang dapat Anda gunakan dalam kebijakan dengan setiap tindakan dan sumber daya layanan, lihat [Tindakan, Sumber Daya, dan Kunci Kondisi untuk AWS Layanan](reference_policies_actions-resources-contextkeys.html). Anda dapat mengonfigurasi penyedia identitas web atau yang berbasis SAML untuk meneruskan [tanda sesi](id_session-tags.md) ke AWS. Ketika karyawan Anda bergabung AWS, atribut mereka diterapkan pada AWS prinsipal yang dihasilkan. Kemudian, Anda dapat menggunakan ABAC untuk mengizinkan atau menolak izin berdasarkan atribut tersebut. Untuk mempelajari cara menggunakan tanda sesi dengan identitas gabungan SAML yang berbeda dengan tutorial ini, lihat [Tutorial IAM: Menggunakan tanda sesi SAML untuk ABAC](tutorial_abac-saml.md). Anggota tim Insinyur dan Jaminan Kualitas Anda berada di proyek **Pegasus** atau proyek**Unicorn** Anda. Anda memilih proyek 3 karakter dan nilai tanda tim berikut: + `access-project` = `peg` untuk proyek **Pegasus** + `access-project` = `uni` untuk proyek **Unicorn** + `access-team` = `eng` untuk tim Insinyur + `access-team` = `qas` untuk tim Jaminan Kualitas Selain itu, Anda memilih untuk meminta tag alokasi `cost-center` biaya untuk mengaktifkan laporan AWS penagihan kustom. Untuk informasi selengkapnya, lihat [Penggunaan Tanda Alokasi Biaya](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) dalam *Panduan Pengguna AWS Manajemen Penagihan dan Biaya *. **Ringkasan keputusan penting** + Karyawan masuk dengan kredensial pengguna IAM dan kemudian mengambil peran IAM untuk tim dan proyek mereka. Jika perusahaan Anda memiliki sistem identitas tersendiri, Anda dapat mengatur federasi untuk memungkinkan karyawan mengambil peran tanpa pengguna IAM. Untuk informasi selengkapnya, lihat [Tutorial IAM: Menggunakan tanda sesi SAML untuk ABAC](tutorial_abac-saml.md). + Kebijakan yang sama terlampir pada semua peran. Tindakan diizinkan atau ditolak berdasarkan tanda. + Karyawan dapat membuat sumber daya baru, tetapi hanya jika mereka melampirkan tanda yang sama ke sumber daya yang diterapkan pada peran mereka. Hal ini memastikan bahwa karyawan dapat melihat sumber daya setelah mereka membuatnya. Administrator tidak lagi diwajibkan untuk memperbarui kebijakan dengan ARN dari sumber daya baru. + Karyawan dapat membaca sumber daya yang dimiliki oleh tim mereka, apa pun proyeknya. + Karyawan dapat memperbarui dan menghapus sumber daya yang dimiliki oleh tim dan proyek mereka sendiri. + Administrator IAM dapat menambahkan peran baru untuk proyek baru. Mereka dapat membuat dan menandai pengguna IAM baru untuk memungkinkan akses ke peran yang sesuai. Administrator tidak diwajibkan untuk mengedit kebijakan untuk mendukung proyek atau anggota tim baru. Di tutorial ini, Anda akan menandai setiap sumber daya, menandai peran proyek Anda, dan menambahkan kebijakan ke peran untuk memungkinkan perilaku yang dijelaskan sebelumnya. Kebijakan yang dihasilkan memungkinkan peran `Create`, `Read`, `Update`, dan `Delete` mengakses sumber daya yang ditandai dengan tanda proyek dan tanda tim yang sama. Kebijakan ini juga memungkinkan proyek silang `Read` untuk mengakses sumber daya yang ditandai dengan tim yang sama. ![\[Diagram menunjukkan dua proyek di mana peran terbatas untuk membaca hanya akses di luar proyek mereka sementara memiliki izin untuk membuat, membaca, memperbarui, dan menghapus sumber daya dalam proyek mereka sendiri.\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/images/tutorial-abac-cross-project.png) ## Prasyarat Untuk melakukan langkah-langkah di tutorial ini, Anda harus sudah memiliki hal-hal berikut: + Sebuah Akun AWS yang dapat Anda masuk sebagai pengguna dengan izin administratif. + ID akun 12 digit Anda, yang Anda gunakan untuk membuat peran di langkah 3. Untuk menemukan nomor ID AWS akun Anda menggunakan Konsol Manajemen AWS, pilih **Support** pada bilah navigasi di kanan atas, lalu pilih **Support Center**. Nomor akun (ID) muncul di panel navigasi di sebelah kiri. ![\[Dukungan Halaman tengah yang menampilkan nomor akun.\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/images/account-id-support-center.console.png) + Pengalaman membuat dan mengedit pengguna, peran, dan kebijakan IAM di. Konsol Manajemen AWS Namun, jika Anda memerlukan bantuan mengingat proses manajemen IAM, tutorial ini menyediakan tautan di mana Anda dapat melihat step-by-step instruksi. ## Langkah 1: Buat pengguna uji Untuk pengujian, buat empat pengguna IAM dengan izin untuk menerima peran dengan tag yang sama. Ini memudahkan untuk menambahkan lebih banyak pengguna ke tim Anda. Saat Anda menandai pengguna, mereka secara otomatis mendapatkan akses untuk mengambil peran yang tepat. Anda tidak perlu menambahkan pengguna ke kebijakan kepercayaan peran tersebut jika mereka hanya menangani satu proyek dan tim. 1. Buat kebijakan yang dikelola pelanggan berikut bernama `access-assume-role`. Untuk informasi selengkapnya tentang membuat kebijakan JSON, lihat [Membuat kebijakan IAM](access_policies_create-console.md#access_policies_create-start). **Kebijakan ABAC: Asumsikan peran ABAC apa pun, tetapi hanya ketika peran pengguna cocok dengan tanda peran** Kebijakan berikut memungkinkan pengguna mengambil peran apa pun di akun Anda dengan prefiks nama `access-`. Peran tersebut juga harus ditandai dengan tanda proyek, tim, dan pusat biaya yang sama dengan pengguna. Untuk menggunakan kebijakan ini, ganti *teks placeholder yang dicetak miring* dengan informasi akun Anda. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TutorialAssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/access-*", "Condition": { "StringEquals": { "iam:ResourceTag/access-project": "${aws:PrincipalTag/access-project}", "iam:ResourceTag/access-team": "${aws:PrincipalTag/access-team}", "iam:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}" } } } ] } ``` ------ Untuk menskalakan tutorial ini ke sejumlah besar pengguna, Anda dapat melampirkan kebijakan ke grup dan menambahkan setiap pengguna ke grup. Untuk informasi selengkapnya, lihat [Buat grup IAM](id_groups_create.md) dan [Mengedit pengguna dalam grup IAM](id_groups_manage_add-remove-users.md). 1. Buat pengguna IAM berikut, lampirkan kebijakan `access-assume-role` izin. Pastikan Anda memilih **Menyediakan akses pengguna ke Konsol Manajemen AWS**, dan kemudian menambahkan tag berikut. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## Langkah 2: Buat kebijakan ABAC Buat kebijakan berikut bernama **access-same-project-team**. Anda akan menambahkan kebijakan ini ke peran tersebut pada langkah berikutnya. Untuk informasi selengkapnya tentang membuat kebijakan JSON, lihat [Membuat kebijakan IAM](access_policies_create-console.md#access_policies_create-start). Untuk kebijakan tambahan yang dapat Anda sesuaikan untuk tutorial ini, lihat halaman berikut: + [Mengontrol akses untuk prinsipal IAM](access_iam-tags.md#access_iam-tags_control-principals) + [Amazon EC2: Memungkinkan memulai atau menghentikan instans EC2 yang telah ditandai pengguna, secara terprogram, dan di konsol](reference_policies_examples_ec2_tag-owner.md) + [EC2: Mulai atau hentikan instans berdasarkan pada pencocokan prinsipal dan tanda sumber daya](reference_policies_examples_ec2-start-stop-match-tags.md) + [EC2: Mulai atau hentikan instance berdasarkan tag](reference_policies_examples_ec2-start-stop-tags.md) + [IAM: Asumsikan peran yang memiliki tag tertentu](reference_policies_examples_iam-assume-tagged-role.md) **Kebijakan ABAC: Akses Sumber Daya Secrets Manager Hanya Saat Prinsipal dan Tag Sumber Daya Cocokkan** Kebijakan berikut memungkinkan penanggung jawab membuat, membaca, mengedit, dan menghapus sumber daya, tetapi hanya jika sumber daya tersebut ditandai dengan pasangan nilai kunci yang sama dengan penanggung jawab. Saat prinsipal membuat sumber daya, mereka harus menambahkan tanda `access-project`, `access-team`, dan `cost-center` dengan nilai yang cocok dengan tanda prinsipal. Kebijakan juga memungkinkan penambahan opsi tanda `Name` atau `OwnedBy`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllActionsSecretsManagerSameProjectSameTeam", "Effect": "Allow", "Action": "secretsmanager:*", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}", "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}", "aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}" }, "ForAllValues:StringEquals": { "aws:TagKeys": [ "access-project", "access-team", "cost-center", "Name", "OwnedBy" ] }, "StringEqualsIfExists": { "aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}", "aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}", "aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}" } } }, { "Sid": "AllResourcesSecretsManagerNoTags", "Effect": "Allow", "Action": [ "secretsmanager:GetRandomPassword", "secretsmanager:ListSecrets" ], "Resource": "*" }, { "Sid": "ReadSecretsManagerSameTeam", "Effect": "Allow", "Action": [ "secretsmanager:Describe*", "secretsmanager:Get*", "secretsmanager:List*" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}" } } }, { "Sid": "DenyUntagSecretsManagerReservedTags", "Effect": "Deny", "Action": "secretsmanager:UntagResource", "Resource": "*", "Condition": { "ForAnyValue:StringLike": { "aws:TagKeys": "access-*" } } }, { "Sid": "DenyPermissionsManagement", "Effect": "Deny", "Action": "secretsmanager:*Policy", "Resource": "*" } ] } ``` ------ **Apa yang dilakukan kebijakan ini?** + Pernyataan `AllActionsSecretsManagerSameProjectSameTeam` memungkinkan semua tindakan layanan ini pada semua sumber daya terkait, tetapi hanya jika tanda sumber daya cocok dengan tanda prinsipal. Dengan menambahkan `"Action": "secretsmanager:*"` ke kebijakan, akan menumbuhkan kebijakan seiring bertumbuhnya Secrets Manager. Jika Secrets Manager menambahkan operasi API baru, Anda tidak perlu menambahkan tindakan tersebut ke pernyataan. Pernyataan tersebut menerapkan ABAC menggunakan tiga blok kondisi. Permintaan hanya diperbolehkan jika ketiga blok dikembalikan dengan benar. + Blok kondisi pertama dari pernyataan ini dikembalikan dengan benar jika kunci tanda yang ditentukan ada pada sumber daya, dan nilainya cocok dengan tanda prinsipal. Blok ini mengembalikan kesalahan tanda yang tidak sesuai, atau tindakan yang tidak mendukung penandaan sumber daya. Untuk mempelajari tindakan mana yang tidak diizinkan oleh blok ini, lihat [Tindakan, Sumber Daya, dan Kunci Kondisi untuk AWS Secrets Manager](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html). Halaman tersebut menunjukkan bahwa tindakan yang dilakukan pada [tipe sumber daya **Rahasia**](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-resources-for-iam-policies) mendukung `secretsmanager:ResourceTag/tag-key` kunci kondisi. Beberapa [tindakan Secrets Manager](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-actions-as-permissions) tidak mendukung tipe sumber daya tersebut, termasuk `GetRandomPassword` dan `ListSecrets`. Anda harus membuat pernyataan tambahan untuk mengizinkan tindakan tersebut. + Blok kondisi kedua menjadi benar jika setiap kunci tanda yang diteruskan di permintaan disertakan dalam daftar yang ditentukan. Hal ini dilakukan menggunakan `ForAllValues` dengan operator kondisi `StringEquals`. Jika tidak ada kunci atau subset dari set kunci yang diteruskan, kondisi menjadi benar. Hal ini memungkinkan operasi `Get*` yang tidak memungkinkan tanda diteruskan di permintaan. Jika pemohon menyertakan kunci tanda yang tidak ada dalam daftar, kondisi menjadi salah. Setiap kunci tanda yang diteruskan di permintaan harus sesuai dengan anggota daftar ini. Untuk informasi selengkapnya, lihat [Tetapkan operator untuk kunci konteks multivaluasi](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys). + Blok kondisi ketiga menjadi benar jika permintaan mendukung tanda yang lolos, jika ketiga tanda hadir, dan jika sesuai dengan nilai tanda prinsipal. Blok ini juga menjadi benar jika permintaan tidak mendukung tanda yang diteruskan. Ini berkat [`...IfExists`](reference_policies_elements_condition_operators.md#Conditions_IfExists) di operator kondisi. Blok menjadi salah jika tidak ada tanda yang diteruskan selama tindakan yang mendukungnya, atau jika kunci dan nilai tanda tidak cocok. + Pernyataan `AllResourcesSecretsManagerNoTags` memungkinkan tindakan `GetRandomPassword` dan `ListSecrets` yang tidak diperbolehkan oleh pernyataan pertama. + Pernyataan `ReadSecretsManagerSameTeam` memungkinkan operasi hanya baca jika prinsipal ditandai dengan tanda access-team yang sama sebagai sumber daya. Hal ini diperbolehkan terlepas dari tanda proyek atau tanda pusat biaya. + Pernyataan `DenyUntagSecretsManagerReservedTags` menolak permintaan untuk menghapus tanda dengan kunci yang dimulai dengan "access-" dari Secrets Manager. Tanda ini digunakan untuk mengontrol akses ke sumber daya, sehingga menghapus tanda dapat menghapus izin. + Pernyataan `DenyPermissionsManagement` menolak akses untuk membuat, mengedit, atau menghapus kebijakan berbasis sumber daya Secrets Manager. Kebijakan ini dapat digunakan untuk mengubah izin rahasia. **penting** Kebijakan ini menggunakan strategi untuk memungkinkan semua tindakan untuk layanan, tetapi dengan tegas menolak tindakan yang melanggar izin. Menolak tindakan akan membatalkan kebijakan lain yang memungkinkan penanggung jawab melakukan tindakan tersebut. Ini dapat menimbulkan hasil yang tidak diinginkan. Sebagai praktik terbaik, gunakanlah penolakan eksplisit hanya jika tidak ada keadaan yang mengizinkan tindakan tersebut. Jika tidak, izinkan daftar tindakan individu, dan tindakan yang tidak diinginkan ditolak secara default. ## Langkah 3: Buat peran Buat peran IAM berikut dan lampirkan kebijakan **access-same-project-team** yang Anda buat pada langkah sebelumnya. Untuk informasi selengkapnya tentang cara membuat peran IAM, lihat [Buat peran untuk memberikan izin kepada pengguna IAM](id_roles_create_for-user.md). Jika Anda memilih untuk menggunakan federasi daripada pengguna dan peran IAM, lihat [Tutorial IAM: Menggunakan tanda sesi SAML untuk ABAC](tutorial_abac-saml.md). | Fungsi pekerjaan | Nama peran | Tanda peran | Deskripsi peran | | --- | --- | --- | --- | | Proyek Teknik Pegasus | access-peg-engineering | akses-proyek = `peg` tim akses = `eng` pusat biaya = `987654` | Memungkinkan insinyur membaca semua sumber daya teknik dan membuat serta mengelola sumber daya teknik Pegasus. | | Jaminan Kualitas Proyek Pegasus | access-peg-quality-assurance | akses-proyek = `peg` tim akses = `qas` pusat biaya = `987654` | Memungkinkan tim QA untuk membaca semua sumber daya QA dan membuat, serta mengelola semua sumber daya QA Pegasus. | | Proyek Teknik Unicorn | access-uni-engineering | akses-proyek = `uni` tim akses = `eng` pusat biaya = `123456` | Memungkinkan insinyur membaca semua sumber daya teknik dan membuat, serta mengelola sumber daya teknik Unicorn. | | Jaminan Kualitas Proyek Unicorn | access-uni-quality-assurance | akses-proyek = `uni` tim akses = `qas` pusat biaya = `123456` | Memungkinkan tim QA untuk membaca semua sumber daya QA dan membuat, serta mengelola semua sumber daya QA Unicorn. | ## Langkah 4: Uji pembuatan rahasia Kebijakan izin yang terlampir pada peran memungkinkan karyawan untuk membuat rahasia. Hal ini hanya diperbolehkan jika rahasia ditandai dengan proyek, tim, dan pusat biaya mereka. Konfirmasikan bahwa izin Anda bekerja sesuai harapan dengan masuk sebagai pengguna Anda, dengan asumsi peran yang benar, dan menguji aktivitas di Secrets Manager. **Untuk mencoba membuat rahasia dengan dan tanpa tag yang diperlukan** 1. Di jendela browser utama Anda, tetap masuk sebagai pengguna administrator sehingga Anda dapat meninjau pengguna, peran, dan kebijakan di IAM. Gunakan jendela penyamaran peramban atau peramban terpisah untuk pengujian Anda. Di sana, masuk sebagai pengguna `access-Arnav-peg-eng` IAM dan buka konsol Secrets Manager di [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/). 1. Upayakan untuk beralih ke peran `access-uni-engineering`. Operasi ini gagal karena nilai tanda `access-project` dan `cost-center` tidak cocok dengan pengguna `access-Arnav-peg-eng` dan peran `access-uni-engineering`. Untuk informasi selengkapnya tentang beralih peran di Konsol Manajemen AWS, lihat [Beralih dari pengguna ke peran IAM (konsol)](id_roles_use_switch-role-console.md) 1. Beralih ke peran `access-peg-engineering`. 1. Simpan rahasia baru menggunakan informasi berikut. Untuk mempelajari cara menyimpan rahasia, lihat [Membuat Rahasia Dasar](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) di *Panduan Pengguna AWS Secrets Manager *. **penting** Secrets Manager menampilkan peringatan bahwa Anda tidak memiliki izin untuk AWS layanan tambahan yang bekerja dengan Secrets Manager. Misalnya, untuk membuat kredensial basis data Amazon RDS, Anda harus memiliki izin untuk menjelaskan instans RDS, klaster RDS, dan klaster Amazon Redshift. Anda dapat mengabaikan peringatan ini karena Anda tidak menggunakan AWS layanan khusus ini dalam tutorial ini. 1. Di bagian **Pilih tipe rahasia**, pilih **Tipe rahasia lainnya**. Di dua kotak teks, masukkan `test-access-key` dan `test-access-secret`. 1. Masukkan `test-access-peg-eng` untuk bidang **Nama rahasia**. 1. Tambahkan kombinasi tanda yang berbeda dari tabel berikut dan lihat perilaku yang diharapkan. 1. Pilih **Toko** untuk mencoba membuat rahasia. Jika penyimpanan gagal, kembali ke laman konsol Secrets Manager sebelumnya dan gunakan set tag berikutnya dari tabel berikut. Set tag terakhir dizinkan dan akan berhasil membuat rahasia. Tabel berikut menunjukkan kombinasi tag ABAC untuk `test-access-peg-eng` peran tersebut. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) 1. Keluar dan ulangi tiga langkah pertama dalam prosedur ini untuk setiap peran dan nilai tanda berikut. Pada langkah keempat dalam prosedur ini, uji setiap set tanda yang hilang, tanda opsional, tanda yang tidak diizinkan, dan nilai tanda tidak valid yang Anda pilih. Kemudian gunakan tanda yang diperlukan untuk membuat rahasia dengan tanda dan nama berikut. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## Langkah 5: Uji menampilkan rahasia Kebijakan yang Anda lampirkan ke setiap peran memungkinkan karyawan melihat rahasia apa pun yang ditandai dengan nama tim mereka, apa pun proyek mereka. Konfirmasikan bahwa izin Anda bekerja sesuai harapan dengan menguji peran Anda di Secrets Manager. **Untuk uji melihat rahasia dengan dan tanpa tag yang diperlukan** 1. Masuk sebagai salah satu pengguna IAM berikut: + `access-Arnav-peg-eng` + `access-Mary-peg-qas` + `access-Saanvi-uni-eng` + `access-Carlos-uni-qas` 1. Beralih ke peran yang sesuai: + `access-peg-engineering` + `access-peg-quality-assurance` + `access-uni-engineering` + `access-uni-quality-assurance` Untuk informasi selengkapnya tentang beralih peran di Konsol Manajemen AWS, lihat[Beralih dari pengguna ke peran IAM (konsol)](id_roles_use_switch-role-console.md). 1. Di panel navigasi sebelah kiri, pilih ikon menu untuk memperluas menu lalu pilih **Rahasia**. 1. Anda akan melihat keempat rahasia di tabel, apa pun peran Anda saat ini. Ini diharapkan karena kebijakan bernama `access-same-project-team` memungkinkan tindakan `secretsmanager:ListSecrets` untuk semua sumber daya. 1. Pilih nama salah satu rahasia. 1. Pada halaman detail rahasia, tanda peran Anda menentukan apakah Anda dapat melihat isi halaman tersebut. Bandingkan nama peran Anda dengan nama rahasia Anda. Jika mereka memiliki nama tim yang sama, tanda `access-team` cocok. Jika tidak cocok, akses akan ditolak. Tabel berikut menunjukkan perilaku tampilan rahasia ABAC untuk setiap peran. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) 1. Dari breadcrumbs di bagian atas halaman, pilih **Rahasia** untuk kembali ke daftar rahasia. Ulangi langkah-langkah dalam prosedur ini menggunakan peran yang berbeda untuk menguji apakah Anda dapat melihat masing-masing rahasia. ## Langkah 6: Uji skalabilitas Alasan penting untuk menggunakan kontrol akses berbasis atribut (ABAC) daripada kontrol akses berbasis peran (RBAC) adalah skalabilitas. Saat perusahaan Anda menambahkan proyek, tim, atau orang baru AWS, Anda tidak perlu memperbarui kebijakan berbasis ABAC. Misalnya, anggaplah bahwa Example Corporation mendanai proyek baru dengan nama kode **Centaur**. Seorang insinyur bernama Saanvi Sarkar akan menjadi insinyur utama untuk **Centaur** sambil terus mengerjakan proyek **Unicorn**. Saanvi juga akan meninjau pekerjaan untuk proyek **Peg**. Ada juga beberapa insinyur yang baru direkrut, termasuk Nikhil Jayashankar, yang hanya akan mengerjakan proyek **Centaur**. **Untuk menambahkan proyek baru ke AWS** 1. Masuk sebagai pengguna administrator IAM dan buka konsol IAM di. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 1. Di panel navigasi di sebelah kiri, pilih **Peran dan tambahkan peran** IAM bernama. `access-cen-engineering` Lampirkan kebijakan **access-same-project-team** izin ke peran dan tambahkan tag peran berikut: + `access-project` = `cen` + `access-team` = `eng` + `cost-center` = `101010` 1. Pada panel navigasi di sebelah kiri, pilih **Pengguna**. 1. Tambahkan pengguna baru bernama`access-Nikhil-cen-eng`, lampirkan kebijakan bernama`access-assume-role`, dan tambahkan tag pengguna berikut. + `access-project` = `cen` + `access-team` = `eng` + `cost-center` = `101010` 1. Gunakan prosedur di [Langkah 4: Uji pembuatan rahasia](#tutorial_abac_step4) dan [Langkah 5: Uji menampilkan rahasia](#tutorial_abac_step5). Di jendela peramban lain, uji apakah Nikhil hanya dapat membuat rahasia teknik **Centaur**, dan apakah dia dapat melihat semua rahasia teknik. 1. Di jendela browser utama tempat Anda masuk sebagai administrator, pilih pengguna`access-Saanvi-uni-eng`. 1. Pada tab **Izin**, hapus kebijakan **access-assume-role**izin. 1. Tambahkan kebijakan inline berikut bernama `access-assume-specific-roles`. Untuk informasi selengkapnya tentang menambahkan kebijakan inline ke pengguna, lihat [Untuk menyematkan kebijakan inline bagi pengguna atau peran (konsole)](access_policies_manage-attach-detach.md#embed-inline-policy-console). **Kebijakan ABAC: Asumsikan hanya peran tertentu** **Kebijakan ini memungkinkan Saanvi untuk mengambil peran teknik untuk proyek **Pegasus** dan Centaur.** Perlu untuk membuat kebijakan kustom ini karena IAM tidak mendukung tag multinilai. Anda tidak dapat menandai pengguna Saanvi dengan `access-project` = `peg` dan `access-project` = `cen`. Selain itu, model AWS otorisasi tidak dapat mencocokkan kedua nilai. Untuk informasi selengkapnya, lihat [Aturan untuk menandai di IAM dan AWS STS](id_tags.md#id_tags_rules). Sebagai gantinya, Anda harus menentukan secara manual dua peran yang dapat dia tanggung. Untuk menggunakan kebijakan ini, ganti *teks placeholder yang dicetak miring* dengan informasi akun Anda. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TutorialAssumeSpecificRoles", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::111122223333:role/access-peg-engineering", "arn:aws:iam::111122223333:role/access-cen-engineering" ] } ] } ``` ------ 1. Gunakan prosedur di [Langkah 4: Uji pembuatan rahasia](#tutorial_abac_step4) dan [Langkah 5: Uji menampilkan rahasia](#tutorial_abac_step5). Pada jendela peramban lain, konfirmasikan bahwa Saanvi dapat mengambil kedua peran tersebut. Periksa bahwa dia dapat membuat rahasia hanya untuk proyek, tim, dan pusat biaya miliknya, bergantung pada tanda peran. Konfirmasi juga bahwa dia dapat melihat perincian tentang rahasia apa pun yang dimiliki oleh tim teknik, termasuk rahasia yang baru saja dia buat. ## Langkah 7: Uji memperbarui dan menghapus rahasia Kebijakan `access-same-project-team` yang terlampir pada peran memungkinkan karyawan memperbarui dan menghapus rahasia yang ditandai dengan proyek, tim, dan pusat biaya mereka. Konfirmasikan bahwa izin Anda bekerja sesuai harapan dengan menguji peran Anda di Secrets Manager. **Untuk menguji pembaruan dan penghapusan rahasia dengan dan tanpa tag yang diperlukan** 1. Masuk sebagai salah satu pengguna IAM berikut: + `access-Arnav-peg-eng` + `access-Mary-peg-qas` + `access-Saanvi-uni-eng` + `access-Carlos-uni-qas` + `access-Nikhil-cen-eng` 1. Beralih ke peran yang sesuai: + `access-peg-engineering` + `access-peg-quality-assurance` + `access-uni-engineering` + `access-peg-quality-assurance` + `access-cen-engineering` Untuk informasi selengkapnya tentang beralih peran di Konsol Manajemen AWS, lihat[Beralih dari pengguna ke peran IAM (konsol)](id_roles_use_switch-role-console.md). 1. Untuk setiap peran, coba perbarui deskripsi rahasia, lalu coba hapus rahasia berikut. Untuk informasi selengkapnya, lihat, lihat [Memodifikasi Rahasia](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_update-secret.html) dan [Menghapus dan Memulihkan Rahasia](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-restore-secret.html) di *Panduan Pengguna AWS Secrets Manager *. Tabel berikut menunjukkan perilaku pembaruan dan penghapusan rahasia ABAC untuk setiap peran. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## Ringkasan Anda telah berhasil menyelesaikan semua langkah yang diperlukan untuk menggunakan tanda untuk kontrol akses berbasis atribut (ABAC). Anda telah mempelajari cara mendefinisikan strategi penandaan. Anda menerapkan strategi tersebut ke penanggung jawab dan sumber daya Anda. Anda membuat dan menerapkan kebijakan yang menegakkan strategi untuk Secrets Manager. Anda juga mempelajari bahwa ABAC menskalakan dengan mudah ketika Anda menambahkan proyek dan anggota tim baru. Akibatnya, Anda dapat masuk ke konsol IAM dengan peran pengujian Anda dan mengalami cara menggunakan tag untuk ABAC in. AWS **catatan** Anda menambahkan kebijakan yang memungkinkan tindakan hanya berdasarkan kondisi tertentu. Jika Anda menerapkan kebijakan yang berbeda kepada pengguna atau peran Anda yang memiliki izin lebih luas, maka tindakan tersebut mungkin tidak akan dibatasi untuk memerlukan penandaan. Misalnya, jika Anda memberi pengguna izin administratif penuh menggunakan kebijakan `AdministratorAccess` AWS terkelola, kebijakan ini tidak membatasi akses tersebut. Untuk informasi selengkapnya tentang bagaimana izin ditentukan saat beberapa kebijakan dilibatkan, lihat [Bagaimana logika kode AWS penegakan mengevaluasi permintaan untuk mengizinkan atau menolak akses](reference_policies_evaluation-logic_policy-eval-denyallow.md). ## Sumber daya terkait Untuk informasi terkait, lihat sumber daya berikut: + [Tentukan izin berdasarkan atribut dengan otorisasi ABAC](introduction_attribute-based-access-control.md) + [AWS kunci konteks kondisi global](reference_policies_condition-keys.md) + [Buat peran untuk memberikan izin kepada pengguna IAM](id_roles_create_for-user.md) + [Tag untuk AWS Identity and Access Management sumber daya](id_tags.md) + [Mengontrol akses ke AWS sumber daya menggunakan tag](access_tags.md) + [Beralih dari pengguna ke peran IAM (konsol)](id_roles_use_switch-role-console.md) + [Tutorial IAM: Menggunakan tanda sesi SAML untuk ABAC](tutorial_abac-saml.md) Untuk mempelajari cara memantau tag di akun Anda, lihat [Memantau perubahan tag pada AWS sumber daya dengan alur kerja tanpa server dan Acara Amazon](https://aws.amazon.com/blogs/mt/monitor-tag-changes-on-aws-resources-with-serverless-workflows-and-amazon-cloudwatch-events/). CloudWatch # Tutorial IAM: Menggunakan tanda sesi SAML untuk ABAC Kontrol akses berbasis atribut (ABAC) adalah strategi otorisasi yang mendefinisikan izin berdasarkan atribut. Dalam AWS, atribut ini disebut tag. Anda dapat melampirkan tag ke sumber daya IAM, termasuk entitas IAM (pengguna atau peran), dan ke AWS sumber daya. Ketika entitas digunakan untuk membuat permintaan AWS, mereka menjadi prinsipal dan prinsipal tersebut menyertakan tag. Anda juga dapat meneruskan [tanda sesi](id_session-tags.md) saat Anda mengasumsikan peran atau menggabungkan pengguna. Anda dapat menentukan kebijakan yang menggunakan kunci tanda kondisi untuk memberikan izin kepada prinsipal Anda berdasarkan tanda mereka. Saat Anda menggunakan tanda untuk mengontrol akses ke sumber daya AWS , Anda memungkinkan tim dan sumber daya Anda tumbuh dengan lebih sedikit perubahan ke kebijakan AWS . Kebijakan ABAC lebih fleksibel daripada AWS kebijakan tradisional, yang mengharuskan Anda untuk mencantumkan setiap sumber daya individu. Untuk informasi selengkapnya tentang ABAC dan manfaatnya dibandingkan kebijakan tradisional, lihat [Tentukan izin berdasarkan atribut dengan otorisasi ABAC](introduction_attribute-based-access-control.md). Jika perusahaan Anda menggunakan penyedia identitas (IdP) berbasis SAML untuk mengelola identitas pengguna perusahaan, Anda dapat menggunakan atribut SAML untuk kontrol akses yang lebih mendetail di AWS. Atribut dapat mencakup pengidentifikasi pusat biaya, alamat surel pengguna, klasifikasi departemen, dan penugasan proyek. Saat Anda meneruskan atribut tersebut sebagai tanda sesi, Anda dapat mengontrol akses ke AWS berdasarkan tanda sesi ini. Untuk menyelesaikan [Tutorial ABAC](tutorial_attribute-based-access-control.md) dengan meneruskan atribut SAML ke penanggung jawab sesi Anda, selesaikan tugas di [Tutorial IAM: Tentukan izin untuk mengakses AWS sumber daya berdasarkan tag](tutorial_attribute-based-access-control.md), dengan perubahan yang disertakan di topik ini. ## Prasyarat Untuk melakukan langkah-langkah menggunakan tanda sesi SAML untuk ABAC, Anda harus sudah memiliki hal-hal berikut: + Akses ke IdP berbasis SAML tempat Anda dapat membuat uji pengguna dengan atribut khusus. + Kemampuan untuk masuk sebagai pengguna dengan izin administratif. + Pengalaman membuat dan mengedit pengguna, peran, dan kebijakan IAM di. Konsol Manajemen AWS Namun, jika Anda memerlukan bantuan mengingat proses manajemen IAM, tutorial ABAC menyediakan tautan di mana Anda dapat melihat step-by-step instruksi. + Pengalaman menyiapkan IDP berbasis SAMP di IAM. Untuk melihat perincian lebih lanjut dan tautan ke dokumentasi IAM terperinci, lihat [Melewati tag sesi menggunakan AssumeRoleWith SALL](id_session-tags.md#id_session-tags_adding-assume-role-saml). ## Langkah 1: Buat pengguna uji Lewati petunjuk di [Langkah 1: Buat pengguna uji](tutorial_attribute-based-access-control.md#tutorial_abac_step1). Karena identitas Anda ditentukan di penyedia, Anda tidak perlu menambahkan pengguna IAM untuk karyawan Anda. ## Langkah 2: Buat kebijakan ABAC Ikuti petunjuk di [Langkah 2: Buat kebijakan ABAC](tutorial_attribute-based-access-control.md#tutorial_abac_step2) untuk membuat kebijakan pengelolaan khusus di IAM. ## Langkah 3: Buat dan konfigurasi peran SAML Bila Anda menggunakan tutorial ABAC untuk SAMP, Anda harus melakukan langkah-langkah tambahan untuk membuat peran, mengkonfigurasi SAMP iDP, dan mengaktifkan akses. Konsol Manajemen AWS Untuk informasi selengkapnya, lihat [Langkah 3: Buat peran](tutorial_attribute-based-access-control.md#tutorial_abac_step3). ### Langkah 3A: Buat peran SAML. Buat peran tunggal yang memercayai penyedia identitas SAML Anda dan pengguna `test-session-tags` yang Anda buat pada langkah 1. Tutorial ABAC menggunakan peran yang berbeda dengan tanda peran yang berbeda. Karena Anda meneruskan tanda sesi dari IdP SAML Anda, Anda hanya perlu satu peran. Untuk mempelajari cara membuat peran berbasis SAML, lihat [Buat peran untuk federasi SAMP 2.0 (konsol)](id_roles_create_for-idp_saml.md). Beri nama peran `access-session-tags`. Lampirkan kebijakan izin `access-same-project-team` ke peran tersebut. Edit kebijakan kepercayaan peran untuk menggunakan kebijakan berikut. Untuk petunjuk terperinci tentang cara mengedit hubungan kepercayaan dari suatu peran, lihat [Memperbarui kebijakan kepercayaan peran](id_roles_update-role-trust-policy.md). Kebijakan kepercayaan peran berikut memungkinkan penyedia identitas SAML Anda dan pengguna `test-session-tags` untuk mengambil peran tersebut. Saat mereka mengambil peran tersebut, mereka harus meneruskan tiga tanda sesi khusus. Diperlukan tindakan `sts:TagSession` untuk memungkinkan penerusan tanda sesi. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowSamlIdentityAssumeRole", "Effect": "Allow", "Action": [ "sts:AssumeRoleWithSAML", "sts:TagSession" ], "Principal": {"Federated":"arn:aws:iam::123456789012:saml-provider/ExampleCorpProvider"}, "Condition": { "StringLike": { "aws:RequestTag/cost-center": "*", "aws:RequestTag/access-project": "*", "aws:RequestTag/access-team": [ "eng", "qas" ] }, "StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"} } } ] } ``` ------ `AllowSamlIdentityAssumeRole`Pernyataan tersebut memungkinkan anggota tim Engineering and Quality Assurance untuk mengambil peran ini ketika mereka bergabung AWS dari Example Corporation IDP. Penyedia `ExampleCorpProvider` SALL didefinisikan dalam IAM. Administrator telah mengatur pernyataan SAML untuk meneruskan tiga tanda sesi yang diperlukan. Pernyataan ini dapat meneruskan tanda tambahan, tetapi ketiga tanda ini harus ada. Atribut identitas dapat memiliki nilai apa pun untuk tanda `cost-center` dan `access-project`. Tetapi, nilai atribut `access-team` harus cocok dengan `eng` atau `qas` untuk menunjukkan bahwa identitas ada pada tim Engineering atau Jaminan Kualitas. ### Langkah 3B: Mengonfigurasi IdP SAML Konfigurasikan IdP SAML Anda untuk meneruskan atribut `cost-center`, `access-project`, dan `access-team` sebagai tanda sesi. Untuk informasi selengkapnya, lihat [Melewati tag sesi menggunakan AssumeRoleWith SALL](id_session-tags.md#id_session-tags_adding-assume-role-saml). Untuk meneruskan atribut ini sebagai tanda sesi, sertakan elemen berikut dalam pernyataan SAML Anda. ``` 987654 peg eng ``` ### Langkah 3C: Aktifkan akses konsol Aktifkan akses konsol untuk pengguna SAML gabungan Anda. Untuk informasi selengkapnya, lihat [Mengaktifkan prinsip federasi SAMP 2.0 untuk mengakses Konsol Manajemen AWS](id_roles_providers_enable-console-saml.md). ## Langkah 4: Uji pembuatan rahasia Federasi ke dalam Konsol Manajemen AWS menggunakan `access-session-tags` peran. Untuk informasi selengkapnya, lihat [Mengaktifkan prinsip federasi SAMP 2.0 untuk mengakses Konsol Manajemen AWS](id_roles_providers_enable-console-saml.md). Kemudian ikuti petunjuk di [Langkah 4: Uji pembuatan rahasia](tutorial_attribute-based-access-control.md#tutorial_abac_step4) untuk membuat rahasia. Gunakan identitas SAML yang berbeda dengan atribut untuk mencocokkan tanda yang ditunjukkan dalam tutorial ABAC. Untuk informasi selengkapnya, lihat [Langkah 4: Uji pembuatan rahasia](tutorial_attribute-based-access-control.md#tutorial_abac_step4). ## Langkah 5: Uji menampilkan rahasia Ikuti petunjuk di [Langkah 5: Uji menampilkan rahasia](tutorial_attribute-based-access-control.md#tutorial_abac_step5) untuk melihat rahasia yang Anda buat di langkah sebelumnya. Gunakan identitas SAML yang berbeda dengan atribut untuk mencocokkan tanda yang ditunjukkan dalam tutorial ABAC. ## Langkah 6: Uji skalabilitas Ikuti petunjuk di [Langkah 6: Uji skalabilitas](tutorial_attribute-based-access-control.md#tutorial_abac_step6) untuk menguji skalabilitas. Lakukan ini dengan menambahkan identitas baru di IdP berbasis SAML Anda dengan atribut berikut ini: + `cost-center = 101010` + `access-project = cen` + `access-team = eng` ## Langkah 7: Uji memperbarui dan menghapus rahasia Ikuti petunjuk di [Langkah 7: Uji memperbarui dan menghapus rahasia](tutorial_attribute-based-access-control.md#tutorial_abac_step7) untuk memperbarui dan menghapus rahasia. Gunakan identitas SAML yang berbeda dengan atribut untuk mencocokkan tanda yang ditunjukkan dalam tutorial ABAC. **penting** Hapus semua rahasia yang Anda buat untuk menghindari biaya tagihan. Untuk detail tentang harga di Secrets Manager, lihat [AWS Secrets Manager Harga](https://aws.amazon.com/secrets-manager/pricing/). ## Ringkasan Anda telah berhasil menyelesaikan semua langkah yang diperlukan untuk menggunakan tanda sesi SAML dan tanda sumber daya untuk manajemen izin. **catatan** Anda menambahkan kebijakan yang memungkinkan tindakan hanya berdasarkan kondisi tertentu. Jika Anda menerapkan kebijakan yang berbeda kepada pengguna atau peran Anda yang memiliki izin lebih luas, maka tindakan tersebut mungkin tidak akan dibatasi untuk memerlukan penandaan. Misalnya, jika Anda memberi pengguna izin administratif penuh menggunakan kebijakan `AdministratorAccess` AWS terkelola, kebijakan ini tidak membatasi akses tersebut. Untuk informasi selengkapnya tentang bagaimana izin ditentukan saat beberapa kebijakan dilibatkan, lihat [Bagaimana logika kode AWS penegakan mengevaluasi permintaan untuk mengizinkan atau menolak akses](reference_policies_evaluation-logic_policy-eval-denyallow.md).