Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Izin untuk kredensial keamanan sementara
Anda dapat menggunakan AWS Security Token Service (AWS STS) untuk membuat dan menyediakan kredenal keamanan sementara kepada pengguna tepercaya yang dapat mengontrol akses ke sumber daya Anda AWS . Untuk informasi lebih lanjut tentang AWS STS, lihat[Kredensial keamanan sementara di IAM](id_credentials_temp.md). Setelah AWS STS mengeluarkan kredensial keamanan sementara, kredensial tersebut berlaku selama periode kedaluwarsa dan tidak dapat dicabut. Namun, izin yang diberikan untuk kredensial keamanan sementara dievaluasi setiap kali sebuah permintaan dibuat ketika menggunakan kredensial tersebut, sehingga Anda dapat memperoleh dampak dari mencabut kredensial dengan mengubah hak akses mereka setelah diterbitkan.
Topik berikut menganggap Anda memiliki pengetahuan tentang AWS izin dan kebijakan. Untuk informasi lebih lanjut pada topik ini, lihat [Manajemen akses untuk AWS sumber daya](access.md).
**Topics**
+ [Izin untuk AssumeRole, AssumeRoleWith SALL, dan AssumeRoleWithWebIdentity](id_credentials_temp_control-access_assumerole.md)
+ [Memantau dan mengontrol tindakan yang diambil dengan peran yang diasumsikan](id_credentials_temp_control-access_monitor.md)
+ [Izin untuk GetFederationToken](id_credentials_temp_control-access_getfederationtoken.md)
+ [Izin untuk GetSessionToken](id_credentials_temp_control-access_getsessiontoken.md)
+ [Menonaktifkan izin untuk kredensial keamanan sementara](id_credentials_temp_control-access_disable-perms.md)
+ [Memberikan izin untuk membuat kredensial keamanan sementara](id_credentials_temp_control-access_enable-create.md)
+ [Memberikan izin untuk menggunakan sesi konsol yang disempurnakan identitas](id_credentials_temp_control-access_sts-setcontext.md)
# Izin untuk AssumeRole, AssumeRoleWith SALL, dan AssumeRoleWithWebIdentity
Kebijakan izin dari peran yang sedang diasumsikan menentukan izin untuk kredensial keamanan sementara yang dikembalikan oleh `AssumeRole`, `AssumeRoleWithSAML`, dan `AssumeRoleWithWebIdentity`. Anda menentukan izin ini saat membuat atau memperbarui peran.
Atau, Anda dapat meneruskan [kebijakan sesi](access_policies.md#policies_session) inline atau terkelola sebagai parameter Operasi API `AssumeRole`, `AssumeRoleWithSAML`, atau `AssumeRoleWithWebIdentity`. Kebijakan sesi membatasi izin untuk sesi kredensial sementara peran tersebut. Izin sesi yang dihasilkan adalah titik pertemuan antara kebijakan berbasis identitas peran dan kebijakan sesi. Anda dapat menggunakan kredensi sementara peran dalam panggilan AWS API berikutnya untuk mengakses sumber daya di akun yang memiliki peran tersebut. Anda tidak dapat menggunakan kebijakan sesi untuk memberikan lebih banyak izin daripada yang diizinkan oleh kebijakan berbasis identitas dari peran yang sedang diasumsikan. Untuk mempelajari lebih lanjut tentang bagaimana AWS menentukan izin yang efektif dari suatu peran, lihat [Logika evaluasi kebijakan](reference_policies_evaluation-logic.md).
![\[PermissionsWhenPassingRoles_Diagram\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/images/role_passed_policy_permissions.png)
Kebijakan yang dilampirkan pada kredensil yang membuat panggilan asli tidak `AssumeRole` dievaluasi oleh AWS saat membuat keputusan otorisasi “izinkan” atau “tolak”. Pengguna untuk sementara menyerahkan izin asli yang mendukung izin yang ditetapkan oleh peran yang diasumsikan. Dalam kasus operasi `AssumeRoleWithSAML` dan `AssumeRoleWithWebIdentity` API, tidak ada kebijakan untuk dievaluasi karena pemanggil API bukan AWS identitas.
## Contoh: Menetapkan izin menggunakan AssumeRole
Anda dapat menggunakan Operasi API `AssumeRole` dengan berbagai jenis kebijakan. Berikut adalah beberapa contoh.
### Kebijakan izin peran
Dalam contoh ini, Anda memanggil operasi API `AssumeRole` tanpa menetapkan kebijakan sesi pada opsional parameter `Policy`. Izin yang diberikan untuk kredensial sementara ditentukan oleh kebijakan izin dari peran yang diasumsikan. Contoh kebijakan izin berikut memberikan izin peran untuk mencantumkan semua objek yang terkandung dalam bucket S3 dengan nama `productionapp`. Hal ini juga memungkinkan peran untuk mendapatkan, menempatkan, dan menghapus objek dalam bucket itu.
**Example Contoh kebijakan izin peran**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::productionapp"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::productionapp/*"
}
]
}
```
### Kebijakan sesi diberikan sebagai parameter
Bayangkan Anda ingin mengizinkan pengguna untuk mengambil peran yang sama seperti dalam contoh sebelumnya. Tetapi dalam hal ini Anda ingin sesi peran hanya memiliki izin untuk mendapatkan dan memasukkan objek ke dalam bucket S3 `productionapp`. Anda tidak ingin mengizinkan mereka untuk menghapus objek. Salah satu cara untuk mencapainya adalah dengan membuat peran baru dan menentukan izin yang diinginkan dalam kebijakan izin peran tersebut. Cara lain untuk mencapai ini adalah dengan memanggil API `AssumeRole` dan menyertakan kebijakan sesi dalam opsional parameter `Policy` sebagai bagian dari operasi API. Izin sesi yang dihasilkan adalah titik pertemuan antara kebijakan berbasis identitas peran dan kebijakan sesi. Kebijakan sesi tidak dapat digunakan untuk memberikan lebih banyak izin daripada yang diizinkan oleh kebijakan berbasis identitas dari peran yang sedang diasumsikan. Untuk informasi lebih lanjut tentang izin sesi peran, lihat [Kebijakan sesi](access_policies.md#policies_session).
Setelah Anda menerima kredensial sementara sesi baru, Anda dapat memberikannya kepada pengguna yang Anda ingin untuk memiliki izin tersebut.
Misalnya, bayangkan kebijakan berikut ini diberikan sebagai parameter panggilan API. Orang yang menggunakan sesi memiliki izin untuk hanya melakukan tindakan berikut:
+ Mencantumkan semua objek ke dalam bucket `productionapp`.
+ Mendapatkan dan memasukkan objek ke dalam bucket `productionapp`.
Dalam kebijakan sesi berikut, izin `s3:DeleteObject` difilter dan sesi yang diasumsikan tidak diberikan izin `s3:DeleteObject`. Kebijakan menetapkan izin maksimum untuk sesi peran sehingga menggantikan kebijakan izin yang ada pada peran tersebut.
**Example Contoh kebijakan sesi melewati Panggilan API `AssumeRole`**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::productionapp"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::productionapp/*"
}
]
}
```
### Kebijakan berbasis sumber daya
Beberapa AWS sumber daya mendukung kebijakan berbasis sumber daya, dan kebijakan ini menyediakan mekanisme lain untuk menentukan izin yang memengaruhi kredensi keamanan sementara. Hanya beberapa sumber daya, seperti bucket Amazon S3, topik Amazon SNS, dan antrean Amazon SQS mendukung kebijakan berbasis sumber daya. Contoh berikut memperluas contoh sebelumnya, menggunakan bucket S3 bernama `productionapp`. Kebijakan berikut ini terlampir di bucket.
Ketika Anda melampirkan kebijakan berbasis sumber daya berikut ini ke bucket `productionapp`, *semua* pengguna tidak diberi izin untuk menghapus objek dari bucket. (Lihat elemen `Principal` dalam kebijakan.) Ini termasuk semua pengguna peran yang diasumsikan, meskipun kebijakan izin peran memberikan izin `DeleteObject`. Sebuah pernyataan `Deny` yang jelas selalu lebih diutamakan daripada pernyataan `Allow`.
**Example Contoh kebijakan bucket**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": {"AWS": "*"},
"Effect": "Deny",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::productionapp/*"
}
}
```
Untuk informasi selengkapnya tentang bagaimana beberapa jenis kebijakan digabungkan dan dievaluasi oleh AWS, lihat[Logika evaluasi kebijakan](reference_policies_evaluation-logic.md).
# Memantau dan mengontrol tindakan yang diambil dengan peran yang diasumsikan
[Peran IAM](id_roles.md) [adalah objek di IAM yang diberi izin.](access_policies.md) Saat Anda [mengambil peran tersebut](id_roles_manage-assume.md) menggunakan identitas IAM atau identitas dari luar AWS, Anda menerima sesi dengan izin yang ditetapkan ke peran tersebut.
Saat Anda melakukan tindakan AWS, informasi tentang sesi Anda dapat dicatat AWS CloudTrail untuk dipantau oleh administrator akun Anda. Administrator dapat mengkonfigurasi peran untuk meminta identitas untuk melewati string kustom yang mengidentifikasi orang atau aplikasi yang melakukan tindakan di AWS. Informasi identitas ini disimpan sebagai *identitas sumber* di AWS CloudTrail. Saat administrator meninjau aktivitas CloudTrail, mereka dapat melihat informasi identitas sumber untuk menentukan siapa atau tindakan apa yang dilakukan dengan sesi peran yang diasumsikan.
Setelah identitas sumber ditetapkan, identitas tersebut hadir dalam permintaan untuk AWS tindakan apa pun yang diambil selama sesi peran. Nilai yang ditetapkan tetap ada ketika peran digunakan untuk mengambil peran lain melalui AWS CLI atau AWS API, yang dikenal sebagai [rantai peran](id_roles.md#iam-term-role-chaining). Nilai yang ditetapkan tidak dapat diubah selama sesi peran. Administrator dapat mengonfigurasi izin terperinci berdasarkan keberadaan atau nilai identitas sumber untuk mengontrol AWS tindakan lebih lanjut yang diambil dengan peran bersama. Anda dapat memutuskan apakah atribut identitas sumber dapat digunakan, apakah itu diperlukan, dan apakah nilai dapat digunakan.
Cara Anda menggunakan identitas sumber berbeda dari nama sesi peran dan tanda sesi dalam cara yang penting. Nilai identitas sumber tidak dapat diubah setelah ditetapkan, dan tetap ada untuk tindakan tambahan yang diambil dengan sesi peran. Berikut cara menggunakan tanda sesi dan nama sesi peran:
+ **Tag sesi** — Anda dapat meneruskan tag sesi saat Anda mengambil peran atau menyatukan pengguna. Tanda sesi hadir ketika peran diasumsikan. Kemudian, Anda dapat menentukan kebijakan yang menggunakan kunci syarat tanda untuk memberikan izin kepada penanggung jawab Anda berdasarkan tanda mereka. Kemudian Anda dapat menggunakan CloudTrail untuk melihat permintaan yang dibuat untuk mengambil peran atau pengguna federasi. Untuk mempelajari lebih lanjut tentang tanda sesi, lihat [Lulus tag sesi di AWS STS](id_session-tags.md).
+ **Nama sesi peran** — Anda dapat menggunakan kunci `sts:RoleSessionName` kondisi dalam kebijakan kepercayaan peran untuk mengharuskan pengguna Anda memberikan nama sesi tertentu saat mereka mengambil peran. Nama sesi peran dapat digunakan untuk membedakan sesi peran ketika peran digunakan oleh penanggung jawab yang berbeda. Untuk mempelajari lebih lanjut tentang nama sesi peran, lihat [sts: RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname).
Kami menyarankan Anda menggunakan identitas sumber ketika Anda ingin mengontrol identitas yang mengasumsikan peran. Identitas sumber juga berguna untuk penambangan CloudTrail log untuk menentukan siapa yang menggunakan peran untuk melakukan tindakan.
**Topics**
+ [Menyiapkan untuk menggunakan identitas sumber](#id_credentials_temp_control-access_monitor-setup)
+ [Hal yang perlu diketahui tentang identitas sumber](#id_credentials_temp_control-access_monitor-know)
+ [Izin yang diperlukan untuk menetapkan identitas sumber](#id_credentials_temp_control-access_monitor-perms)
+ [Menentukan identitas sumber ketika mengasumsikan peran](#id_credentials_temp_control-access_monitor-specify-sourceid)
+ [Menggunakan identitas sumber dengan AssumeRole](#id_credentials_temp_control-access_monitor-assume-role)
+ [Menggunakan identitas sumber dengan AssumeRoleWith SAFL](#id_credentials_temp_control-access_monitor-assume-role-saml)
+ [Menggunakan identitas sumber dengan AssumeRoleWithWebIdentity](#id_credentials_temp_control-access_monitor-assume-role-web-id)
+ [Mengontrol akses menggunakan informasi identitas sumber](#id_credentials_temp_control-access_monitor-control-access)
+ [Melihat identitas sumber di CloudTrail](#id_credentials_temp_control-access_monitor-ct)
## Menyiapkan untuk menggunakan identitas sumber
Cara Anda mengatur untuk menggunakan identitas sumber tergantung metode yang digunakan ketika peran Anda diasumsikan. Misalnya, pengguna IAM Anda mungkin mengambil peran secara langsung menggunakan `AssumeRole` operasi. Jika Anda memiliki identitas perusahaan, juga dikenal sebagai identitas tenaga kerja, mereka dapat mengakses sumber daya Anda AWS menggunakan. `AssumeRoleWithSAML` Jika pengguna akhir mengakses aplikasi seluler atau web Anda, mereka mungkin melakukannya menggunakan `AssumeRoleWithWebIdentity`. Berikut ini adalah gambaran umum alur kerja tingkat tinggi untuk membantu Anda memahami bagaimana Anda dapat mengatur untuk memanfaatkan informasi identitas sumber di lingkungan yang ada.
1. **Konfigurasikan pengguna dan peran pengujian** — Menggunakan lingkungan praproduksi, konfigurasikan pengguna dan peran pengujian, serta konfigurasikan kebijakan mereka untuk memungkinkan pengaturan identitas sumber.
Jika Anda menggunakan penyedia identitas (IdP) untuk identitas federasi Anda, konfigurasikan IdP Anda untuk melewati atribut pengguna pilihan Anda untuk identitas sumber dalam pernyataan atau token.
1. **Asumsikan peran** — Uji asumsi peran dan meneruskan identitas sumber dengan pengguna dan peran yang Anda siapkan untuk pengujian.
1. **Tinjauan CloudTrail** — Tinjau informasi identitas sumber untuk peran pengujian Anda di CloudTrail log Anda.
1. **Latih pengguna Anda** — Setelah Anda menguji di lingkungan praproduksi, pastikan pengguna mengetahui cara meneruskan informasi identitas sumber, jika perlu. Tetapkan tenggat waktu untuk kapan Anda akan meminta pengguna Anda untuk memberikan identitas sumber di lingkungan produksi Anda.
1. **Konfigurasikan kebijakan produksi** — Konfigurasikan kebijakan Anda untuk lingkungan produksi, lalu tambahkan ke pengguna dan peran produksi Anda.
1. **Pantau aktivitas** — Pantau aktivitas peran produksi Anda menggunakan CloudTrail log.
## Hal yang perlu diketahui tentang identitas sumber
Ingatlah hal-hal berikut ini saat bekerja dengan identitas sumber.
+ Kebijakan kepercayaan untuk semua peran yang terhubung ke penyedia identitas (IdP) harus memiliki izin `sts:SetSourceIdentity`. Untuk peran yang tidak memiliki izin ini dalam kebijakan kepercayaan peran, operasi `AssumeRole*` akan gagal. Jika Anda tidak ingin memperbarui kebijakan kepercayaan peran untuk setiap peran, Anda dapat menggunakan instans IdP terpisah untuk meneruskan identitas sumber. Lalu tambahkan izin `sts:SetSourceIdentity` hanya untuk peran yang terhubung ke IdP yang terpisah.
+ Ketika identitas menetapkan identitas sumber, kunci `sts:SourceIdentity` terdapat dalam permintaan. Untuk tindakan selanjutnya yang diambil selama sesi peran, kunci `aws:SourceIdentity` terdapat dalam permintaan. AWS tidak mengontrol nilai identitas sumber di salah satu kunci `sts:SourceIdentity` atau `aws:SourceIdentity`. Jika Anda memilih untuk meminta identitas sumber, Anda harus memilih atribut yang Anda inginkan pengguna atau IdP untuk menyediakan. Untuk tujuan keamanan, Anda harus memastikan bahwa Anda dapat mengontrol bagaimana nilai-nilai tersebut disediakan.
+ Nilai identitas sumber harus antara 2 dan 64 karakter panjang, dapat berisi hanya karakter alfanumerik, garis bawah, dan karakter berikut:**., \$1 = @ -** (tanda hubung). Anda tidak dapat menggunakan nilai yang dimulai dengan teks **aws:**. Awalan ini dicadangkan untuk penggunaan AWS internal.
+ Informasi identitas sumber tidak ditangkap oleh CloudTrail ketika AWS layanan atau peran terkait layanan melakukan tindakan atas nama identitas federasi atau tenaga kerja.
**penting**
Anda tidak dapat beralih ke peran Konsol Manajemen AWS yang memerlukan identitas sumber untuk disetel saat peran diasumsikan. Untuk mengambil peran seperti itu, Anda dapat menggunakan AWS API AWS CLI atau untuk memanggil `AssumeRole` operasi dan menentukan parameter identitas sumber.
## Izin yang diperlukan untuk menetapkan identitas sumber
Selain tidakan yang sesuai dengan operasi API, Anda harus memiliki tindakan khusus izin berikut dalam kebijakan Anda:
```
sts:SetSourceIdentity
```
+ Untuk menentukan identitas sumber, prinsipal (pengguna dan peran IAM) harus memiliki izin untuk. `sts:SetSourceIdentity` Sebagai administrator, Anda dapat mengonfigurasi ini dalam kebijakan kepercayaan peran dan kebijakan izin penanggung jawab.
+ Ketika Anda mengambil peran dengan peran lain, disebut [perangkaian peran](id_roles.md#iam-term-role-chaining), izin untuk `sts:SetSourceIdentity` diperlukan dalam kebijakan perizinan penanggung jawab yang mengasumsikan peran dan dalam kebijakan kepercayaan peran pada peran target. Jika tidak, peran operasi asumsi akan gagal.
+ Saat menggunakan identitas sumber, kebijakan kepercayaan peran untuk semua peran yang terhubung ke IdP harus memiliki izin `sts:SetSourceIdentity`. Operasi `AssumeRole*` akan gagal untuk peran apa pun yang terhubung ke IdP tanpa izin ini. Jika Anda tidak ingin memperbarui kebijakan kepercayaan peran untuk setiap peran, Anda dapat menggunakan instans IdP terpisah untuk meneruskan identitas sumber dan menambahkan izin `sts:SetSourceIdentity` hanya untuk peran yang terhubung ke IdP yang terpisah.
+ Untuk menetapkan identitas sumber di batas akun, Anda harus menyertakan izin `sts:SetSourceIdentity` di dua tempat. Harus berada dalam kebijakan izin penanggung jawab di akun asal dan kebijakan kepercayaan peran dalam akun target. Anda mungkin perlu melakukannya, misalnya, ketika peran digunakan untuk mengambil peran di akun lain dengan [perangkaian peran](id_roles.md#iam-term-role-chaining).
Sebagai administrator akun, bayangkan Anda ingin mengizinkan pengguna IAM `DevUser` di akun Anda untuk mengasumsikan akun yang sama. `Developer_Role` Tetapi Anda ingin mengizinkan tindakan ini hanya jika pengguna telah mengatur identitas sumber ke nama pengguna IAM mereka. Anda dapat melampirkan kebijakan berikut ke pengguna IAM.
**Example Contoh kebijakan berbasis identitas yang dilampirkan DevUser**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123456789012:role/Developer_Role"
},
{
"Sid": "SetAwsUserNameAsSourceIdentity",
"Effect": "Allow",
"Action": "sts:SetSourceIdentity",
"Resource": "arn:aws:iam::123456789012:role/Developer_Role",
"Condition": {
"StringLike": {
"sts:SourceIdentity": "${aws:username}"
}
}
}
]
}
```
Untuk memberlakukan nilai identitas sumber yang dapat diterima, Anda dapat mengonfigurasi kebijakan kepercayaan peran berikut. Kebijakan ini memberikan `DevUser` izin pengguna IAM untuk mengambil peran dan menetapkan identitas sumber. Kunci syarat `sts:SourceIdentity` mendefinisikan nilai identitas sumber yang dapat diterima.
**Example Contoh kebijakan kepercayaan peran untuk identitas sumber**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowDevUserAssumeRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/DevUser"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {
"sts:SourceIdentity": "DevUser"
}
}
}
]
}
```
------
Menggunakan kredensil untuk pengguna IAM`DevUser`, pengguna mencoba untuk mengasumsikan `DeveloperRole` menggunakan permintaan berikut. AWS CLI
**Example Contoh AssumeRole permintaan CLI**
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Developer_Role \
--role-session-name Dev-project \
--source-identity DevUser \
```
Saat AWS mengevaluasi permintaan, konteks permintaan berisi `sts:SourceIdentity` dari. `DevUser`
## Menentukan identitas sumber ketika mengasumsikan peran
Anda dapat menentukan identitas sumber saat menggunakan salah satu operasi AWS STS `AssumeRole*` API untuk mendapatkan kredensil keamanan sementara untuk suatu peran. Operasi API yang Anda gunakan berbeda tergantung kasus penggunaan Anda. Misalnya, jika Anda menggunakan peran IAM untuk memberi pengguna IAM akses ke AWS sumber daya yang biasanya tidak dapat mereka akses, Anda dapat menggunakan operasi tersebut`AssumeRole`. Jika Anda menggunakan federasi identitas perusahaan untuk mengelola pengguna tenaga kerja Anda, Anda dapat menggunakan operasi `AssumeRoleWithSAML`. Jika Anda menggunakan federasi OIDC untuk mengizinkan pengguna akhir mengakses aplikasi seluler atau web Anda, Anda dapat menggunakan operasi tersebut`AssumeRoleWithWebIdentity`. Bagian berikut menjelaskan cara menggunakan identitas sumber dengan setiap operasi. Untuk mempelajari selengkapnya tentang skenario umum untuk kredensial sementara, lihat [Skenario umum untuk kredensial sementara](id_credentials_temp.md#sts-introduction).
## Menggunakan identitas sumber dengan AssumeRole
`AssumeRole`Operasi mengembalikan satu set kredensi sementara yang dapat Anda gunakan untuk mengakses AWS sumber daya. Anda dapat menggunakan kredensi pengguna atau peran IAM untuk menelepon. `AssumeRole` Untuk meneruskan identitas sumber saat mengambil peran, gunakan `-–source-identity` AWS CLI opsi atau parameter `SourceIdentity` AWS API. Contoh berikut menunjukkan cara menentukan identitas sumber menggunakan AWS CLI.
**Example Contoh AssumeRole permintaan CLI**
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/developer \
--role-session-name Audit \
--source-identity Admin \
```
## Menggunakan identitas sumber dengan AssumeRoleWith SAFL
Penanggung jawab yang memanggil operasi `AssumeRoleWithSAML` diautentikasi menggunakan federasi berbasis SAML. Operasi ini mengembalikan satu set kredensi sementara yang dapat Anda gunakan untuk mengakses AWS sumber daya. Untuk informasi selengkapnya tentang penggunaan federasi berbasis SAML untuk Konsol Manajemen AWS akses, lihat. [Mengaktifkan prinsip federasi SAMP 2.0 untuk mengakses Konsol Manajemen AWS](id_roles_providers_enable-console-saml.md) Untuk detail tentang AWS CLI atau akses AWS API, lihat[Federasi SAMP 2.0](id_roles_providers_saml.md). Untuk tutorial menyiapkan federasi SAFL untuk pengguna Active Directory Anda, lihat [AWS Otentikasi Federasi dengan Layanan Federasi Direktori Aktif (ADFS)](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/) di Blog Keamanan. AWS
Sebagai administrator, Anda dapat mengizinkan anggota direktori perusahaan Anda untuk bergabung AWS menggunakan AWS STS `AssumeRoleWithSAML` operasi. Untuk melakukannya, Anda harus menyelesaikan tugas berikut:
1. [Mengonfigurasi penyedia SAML di organisasi Anda](id_roles_providers_saml_3rd-party.md).
1. [Buat penyedia SAFL di IAM](id_roles_providers_create_saml.md).
1. [Konfigurasikan peran dan izinnya AWS untuk prinsipal federasi SALL Anda](id_roles_create_for-idp_saml.md).
1. [Selesaikan konfigurasi SAML IdP dan buat pernyataan untuk respons autentikasi SAML](id_roles_providers_create_saml_assertions.md)
Untuk mengatur atribut SAML untuk identitas sumber, termasuk elemen `Attribute` dengan atribut `Name` yang ditetapkan ke `https://aws.amazon.com/SAML/Attributes/SourceIdentity`. Gunakan elemen `AttributeValue` untuk menentukan nilai identitas sumber. Misalnya, anggap Anda ingin meneruskan atribut identitas berikut sebagai identitas sumber.
`SourceIdentity:DiegoRamirez`
Untuk meneruskan atribut ini, sertakan elemen berikut dalam pernyataan SAML Anda.
**Example Contoh snippet pernyataan SAML**
```
DiegoRamirez
```
## Menggunakan identitas sumber dengan AssumeRoleWithWebIdentity
Pemanggilan utama `AssumeRoleWithWebIdentity` operasi diautentikasi menggunakan federasi yang sesuai dengan OpenID Connect (OIDC). Operasi ini menghasilkan serangkaian kredensial sementara yang dapat Anda gunakan untuk mengakses sumber daya AWS . Untuk informasi selengkapnya tentang penggunaan federasi OIDC untuk Konsol Manajemen AWS akses, lihat. [Federasi OIDC](id_roles_providers_oidc.md)
Untuk meneruskan identitas sumber dari OpenID Connect (OIDC), Anda harus menyertakan identitas sumber dalam JSON Web Token (JWT). Sertakan identitas sumber dalam namespace `[https://aws.amazon.com/](https://aws.amazon.com/)source_identity` dalam token ketika Anda mengajukan permintaan `AssumeRoleWithWebIdentity`. Untuk mempelajari lebih lanjut tentang token dan klaim OIDC, lihat [Menggunakan Token dengan Kolam Pengguna](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html) di *Panduan Developer Amazon Cognito *.
Misalnya, JWT yang diterjemahkan berikut adalah token yang digunakan untuk memanggil `AssumeRoleWithWebIdentity` dengan sumber identitas `Admin`.
**Example Contoh Token Web JSON yang diterjemahkan**
```
{
"sub": "john",
"aud": "ac_oic_client",
"jti": "ZYUCeRMQVtqHypVPWAN3VB",
"iss": "https://xyz.com",
"iat": 1566583294,
"exp": 1566583354,
"auth_time": 1566583292,
"https://aws.amazon.com/source_identity":"Admin"
}
```
## Mengontrol akses menggunakan informasi identitas sumber
Ketika identitas sumber awalnya ditetapkan, SourceIdentity kunci [sts:](reference_policies_iam-condition-keys.md#ck_sourceidentity) ada dalam permintaan. Setelah identitas sumber disetel, SourceIdentity kunci [aws:](reference_policies_condition-keys.md#condition-keys-sourceidentity) hadir di semua permintaan berikutnya yang dibuat selama sesi peran. Sebagai administrator, Anda dapat menulis kebijakan yang memberikan otorisasi bersyarat untuk melakukan AWS tindakan berdasarkan keberadaan atau nilai atribut identitas sumber.
Bayangkan Anda ingin meminta pengembang Anda untuk menetapkan identitas sumber untuk mengambil peran penting yang memiliki izin untuk menulis ke AWS sumber daya penting produksi. Juga bayangkan bahwa Anda memberikan AWS akses ke identitas tenaga kerja Anda menggunakan. `AssumeRoleWithSAML` Anda hanya ingin developer senior Saanvi dan Diego memiliki akses ke peran, sehingga Anda membuat kebijakan kepercayaan berikut untuk peran tersebut.
**Example Contoh kebijakan kepercayaan peran untuk identitas sumber (SALL)**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SAMLProviderAssumeRoleWithSAML",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
},
"Action": [
"sts:AssumeRoleWithSAML"
],
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
},
{
"Sid": "SetSourceIdentitySrEngs",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
},
"Action": [
"sts:SetSourceIdentity"
],
"Condition": {
"StringLike": {
"sts:SourceIdentity": [
"Saanvi",
"Diego"
]
}
}
}
]
}
```
------
Kebijakan kepercayaan berisi syarat untuk `sts:SourceIdentity` itu membutuhkan identitas sumber Saanvi atau Diego untuk mengambil peran penting.
Atau, jika Anda menggunakan penyedia OIDC untuk federasi dan pengguna diautentikasi`AssumeRoleWithWebIdentity`, kebijakan kepercayaan peran Anda mungkin terlihat sebagai berikut.
**Example Contoh kebijakan kepercayaan peran untuk identitas sumber (penyedia OIDC)**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/server.example.com"
},
"Action": [
"sts:AssumeRoleWithWebIdentity",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {
"server.example.com:aud": "oidc-audience-id"
},
"StringLike": {
"sts:SourceIdentity": [
"Saanvi",
"Diego"
]
}
}
}
]
}
```
------
### Peran perangkauan dan persyaratan lintas akun
Bayangkan Anda ingin mengizinkan pengguna yang mengasumsikan `CriticalRole` untuk mengambil `CriticalRole_2` di akun lain. Kredensial sesi peran yang diperoleh untuk mengasumsikan `CriticalRole` digunakan untuk [merangkai peran](id_roles.md#iam-term-role-chaining) untuk peran kedua, `CriticalRole_2`, di akun yang berbeda. Peran sedang diasumsikan di batas akun. Oleh karena itu, izin `sts:SetSourceIdentity` harus diberikan dalam kedua kebijakan izin pada `CriticalRole` dan dalam kebijakan kepercayaan peran di `CriticalRole_2`.
**Example Contoh kebijakan izin pada CriticalRole**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRoleAndSetSourceIdentity",
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Resource": "arn:aws:iam::222222222222:role/CriticalRole_2"
}
]
}
```
------
Untuk mengamankan pengaturan sumber identitas di batas akun, kebijakan kepercayaan peran berikut hanya mempercayai peran utama untuk `CriticalRole` guna mengatur identitas sumber.
**Example Contoh kebijakan kepercayaan peran pada CriticalRole \$12**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/CriticalRole"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Condition": {
"StringLike": {
"aws:SourceIdentity": ["Saanvi","Diego"]
}
}
}
]
}
```
------
Pengguna membuat panggilan berikut menggunakan kredensil sesi peran yang diperoleh dari asumsi. CriticalRole Identitas sumber ditetapkan selama asumsi CriticalRole, sehingga tidak perlu diatur lagi secara eksplisit. Jika pengguna mencoba untuk mengatur identitas sumber yang berbeda dari nilai yang ditetapkan ketika diasumsikan `CriticalRole`, permintaan peran asumsi akan ditolak.
**Example Contoh AssumeRole permintaan CLI**
```
aws sts assume-role \
--role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \
--role-session-name Audit \
```
Ketika penanggung jawab panggilan mengasumsikan peran, identitas sumber dalam permintaan tetap dari sesi peran diasumsikan pertama. Oleh karena itu, kedua kunci `aws:SourceIdentity` dan `sts:SourceIdentity` terdapat dalam konteks permintaan.
## Melihat identitas sumber di CloudTrail
Anda dapat menggunakan CloudTrail untuk melihat permintaan yang dibuat untuk mengambil peran atau pengguna federasi. Anda juga dapat melihat peran atau permintaan pengguna untuk mengambil tindakan dalam AWS. File CloudTrail log mencakup informasi tentang identitas sumber yang ditetapkan untuk peran yang diasumsikan atau sesi pengguna federasi. Untuk informasi selengkapnya, lihat [Mencatat panggilan IAM dan AWS STS API dengan AWS CloudTrail](cloudtrail-integration.md)
Misalnya, asumsikan bahwa pengguna membuat AWS STS `AssumeRole` permintaan, dan menetapkan identitas sumber. Anda dapat menemukan `sourceIdentity` informasi di `requestParameters` kunci di CloudTrail log Anda.
**Example Contoh bagian RequestParameters dalam log AWS CloudTrail**
```
"eventVersion": "1.05",
"userIdentity": {
"type": "AWSAccount",
"principalId": "AIDAJ45Q7YFFAREXAMPLE",
"accountId": "111122223333"
},
"eventTime": "2020-04-02T18:20:53Z",
"eventSource": "sts.amazonaws.com",
"eventName": "AssumeRole",
"awsRegion": "us-east-1",
"sourceIPAddress": "203.0.113.64",
"userAgent": "aws-cli/1.16.96 Python/3.6.0 Windows/10 botocore/1.12.86",
"requestParameters": {
"roleArn": "arn:aws:iam::123456789012:role/DevRole",
"roleSessionName": "Dev1",
"sourceIdentity": "source-identity-value-set"
}
```
Jika pengguna menggunakan sesi peran yang diasumsikan untuk melakukan tindakan, informasi identitas sumber ada di `userIdentity` kunci di CloudTrail log.
**Example Contoh kunci UserIdentity dalam log AWS CloudTrail**
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAJ45Q7YFFAREXAMPLE:Dev1",
"arn": "arn:aws:sts::123456789012:assumed-role/DevRole/Dev1",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAJ45Q7YFFAREXAMPLE",
"arn": "arn:aws:iam::123456789012:role/DevRole",
"accountId": "123456789012",
"userName": "DevRole"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2021-02-21T23:46:28Z"
},
"sourceIdentity": "source-identity-value-present"
}
}
}
```
Untuk melihat contoh peristiwa AWS STS API di CloudTrail log, lihat[Contoh peristiwa API IAM di log CloudTrail](cloudtrail-integration.md#cloudtrail-integration_examples-iam-api). Untuk detail selengkapnya tentang informasi yang terkandung dalam file CloudTrail log, lihat [Referensi CloudTrail Acara](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) di *Panduan AWS CloudTrail Pengguna*.
# Izin untuk GetFederationToken
Operasi `GetFederationToken` dipanggil oleh pengguna IAM dan mengembalikan kredensial sementara untuk pengguna tersebut. Operasi ini *menggabungkan* pengguna. Izin yang ditetapkan untuk sesi pengguna AWS STS federasi didefinisikan di salah satu dari dua tempat:
+ Kebijakan sesi lewat sebagai sebuah parameter dari Panggilan API `GetFederationToken`. (Ini paling umum.)
+ Kebijakan berbasis sumber daya yang secara eksplisit menamai sesi pengguna AWS STS federasi dalam elemen kebijakan. `Principal` (Ini lebih jarang terjadi.)
Kebijakan sesi adalah kebijakan lanjutan yang Anda jalankan sebagai parameter saat Anda secara terprogram membuat sebuah sesi sementara. Saat Anda membuat sesi pengguna AWS STS gabungan dan meneruskan kebijakan sesi, izin sesi yang dihasilkan adalah persimpangan kebijakan berbasis identitas pengguna dan kebijakan sesi. Anda tidak dapat menggunakan kebijakan sesi untuk memberikan lebih banyak izin daripada yang diizinkan oleh kebijakan berbasis identitas dari pengguna yang sedang digabung.
Dalam kebanyakan kasus jika Anda tidak memberikan kebijakan dengan panggilan API `GetFederationToken`, kredensial keamanan sementara yang dihasilkan tidak memiliki izin. Namun, kebijakan berbasis sumber daya dapat memberikan izin tambahan untuk sesi tersebut. Anda dapat mengakses sumber daya dengan sebuah kebijakan berbasis sumber daya yang menentukan sesi Anda sebagai prinsipal yang diizinkan.
Gambar berikut ini menunjukkan gambaran visual tentang cara kebijakan berinteraksi untuk menentukan izin bagi kredensial keamanan sementara yang dikembalikan oleh panggilan ke `GetFederationToken`.
![\[Pengguna IAM Ilustrasi berikut menunjukkan tanda centang untuk menunjukkan bahwa izin sesi adalah persimpangan kebijakan berbasis identitas pengguna dan kebijakan sesi. Izin sesi juga dapat menjadi persimpangan kebijakan berbasis identitas pengguna dan kebijakan berbasis sumber daya.\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/images/getfederationtoken-permissions.diagram.png)
## Contoh: Menetapkan izin menggunakan GetFederationToken
Anda dapat menggunakan tindakan API `GetFederationToken` dengan berbagai jenis kebijakan. Berikut adalah beberapa contoh.
### Kebijakan yang terlampir pada pengguna IAM
Dalam contoh ini, Anda memiliki aplikasi klien berbasis browser yang mengandalkan dua layanan web backend. Satu layanan backend adalah server autentikasi Anda sendiri yang menggunakan identitas sistem Anda sendiri untuk mengautentikasi aplikasi klien. Layanan backend lainnya adalah layanan AWS yang menyediakan beberapa fungsionalitas aplikasi klien. Aplikasi klien diautentikasi oleh server Anda, dan server Anda membuat atau mengambil kebijakan izin yang sesuai. Server Anda kemudian memanggil API `GetFederationToken` untuk mendapatkan kredensial keamanan sementara, dan mengembalikan kredensial tersebut ke aplikasi klien. Aplikasi klien kemudian dapat membuat permintaan langsung ke AWS layanan dengan kredenal keamanan sementara. Arsitektur ini memungkinkan aplikasi klien untuk membuat AWS permintaan tanpa menyematkan AWS kredensi jangka panjang.
Server otentikasi Anda memanggil `GetFederationToken` API dengan kredensi keamanan jangka panjang dari pengguna IAM bernama. `token-app` Tetapi kredensi pengguna IAM jangka panjang tetap ada di server Anda dan tidak pernah didistribusikan ke klien. Contoh kebijakan berikut dilampirkan ke pengguna `token-app` IAM dan mendefinisikan kumpulan izin terluas yang diperlukan oleh pengguna AWS STS federasi (klien) Anda. Perhatikan bahwa `sts:GetFederationToken` izin diperlukan untuk layanan otentikasi Anda untuk mendapatkan kredenial keamanan sementara bagi pengguna federasi AWS STS .
**Example Contoh kebijakan terlampir ke pengguna IAM `token-app` yang memanggil `GetFederationToken`**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "dynamodb:ListTables",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sqs:ReceiveMessage",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sns:ListSubscriptions",
"Resource": "*"
}
]
}
```
Kebijakan sebelumnya memberikan beberapa izin kepada pengguna IAM. Namun, kebijakan ini saja tidak memberikan izin apa pun kepada pengguna AWS STS federasi. Jika pengguna IAM ini memanggil `GetFederationToken` dan tidak meneruskan kebijakan sebagai parameter panggilan API, pengguna AWS STS federasi yang dihasilkan tidak memiliki izin yang efektif.
### Kebijakan sesi diberikan sebagai parameter
Cara paling umum untuk memastikan bahwa pengguna AWS STS federasi diberi izin yang sesuai adalah dengan meneruskan kebijakan sesi dalam panggilan `GetFederationToken` API. Memperluas contoh sebelumnya, bayangkan yang `GetFederationToken` dipanggil dengan kredensi pengguna IAM. `token-app` Bayangkan sesi kebijakan berikut ini diberikan sebagai parameter panggilan API. Pengguna AWS STS federasi yang dihasilkan memiliki izin untuk mencantumkan konten bucket Amazon S3 yang diberi nama. `productionapp` Pengguna tidak dapat melakukan Amazon S3 `GetObject``PutObject`, dan `DeleteObject` tindakan pada item di bucket. `productionapp`
Pengguna gabungan diberi izin ini karena izin tersebut merupakan pertemuan antara kebijakan pengguna IAM dan kebijakan sesi yang Anda lewati.
Pengguna AWS STS federasi tidak dapat melakukan tindakan di Amazon SNS, Amazon SQS, Amazon DynamoDB, atau di bucket S3 apa pun kecuali. `productionapp` Tindakan ini ditolak meskipun izin tersebut diberikan kepada pengguna IAM yang terkait dengan panggilan tersebut`GetFederationToken`.
**Example Contoh kebijakan sesi lewat sebagai sebuah parameter dari Panggilan API `GetFederationToken`.**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::productionapp"]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": ["arn:aws:s3:::productionapp/*"]
}
]
}
```
### Kebijakan berbasis sumber daya
Beberapa AWS sumber daya mendukung kebijakan berbasis sumber daya, dan kebijakan ini menyediakan mekanisme lain untuk memberikan izin langsung kepada pengguna federasi. AWS STS Hanya beberapa AWS layanan yang mendukung kebijakan berbasis sumber daya. Misalnya, Amazon S3 memiliki bucket, Amazon SNS memiliki topik, dan Amazon SQS memiliki antrean yang dapat Anda lampirkan kebijakannya. Untuk daftar semua layanan yang mendukung kebijakan berbasis sumber daya, lihat [AWS layanan yang bekerja dengan IAM](reference_aws-services-that-work-with-iam.md) dan tinjau kolom “Kebijakan berbasis Sumber Daya” pada tabel. Anda dapat menggunakan kebijakan berbasis sumber daya untuk menetapkan izin langsung ke pengguna federasi. AWS STS Lakukan ini dengan menentukan Nama Sumber Daya Amazon (ARN) pengguna AWS STS federasi dalam `Principal` elemen kebijakan berbasis sumber daya. Contoh berikut menggambarkan hal ini dan memperluas contoh sebelumnya, menggunakan bucket S3 bernama `productionapp`.
Kebijakan berbasis sumber daya berikut ini terlampir di bucket. Kebijakan bucket ini memungkinkan pengguna AWS STS federasi bernama Carol untuk mengakses bucket. Ketika kebijakan contoh yang dijelaskan sebelumnya dilampirkan ke pengguna `token-app` IAM, pengguna AWS STS federasi bernama Carol memiliki izin untuk melakukan`s3:GetObject`,`s3:PutObject`, dan `s3:DeleteObject` tindakan pada bucket bernama. `productionapp` Hal ini berlaku bahkan ketika kebijakan sesi tidak diberikan sebagai parameter panggilan API `GetFederationToken`. Itu karena dalam kasus ini pengguna AWS STS federasi bernama Carol telah secara eksplisit diberikan izin oleh kebijakan berbasis sumber daya berikut.
***Ingat, pengguna AWS STS federasi diberikan izin hanya jika izin tersebut secara eksplisit diberikan kepada pengguna IAM dan pengguna federasi.*** AWS STS Mereka juga dapat diberikan (dalam akun) oleh kebijakan berbasis sumber daya yang secara eksplisit menyebutkan nama pengguna AWS STS federasi dalam `Principal` elemen kebijakan, seperti pada contoh berikut.
**Example Contoh kebijakan bucket yang mengijinkan akses ke pengguna gabungan**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": {
"AWS": "arn:aws:sts::111122223333:federated-user/Carol"
},
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::productionapp/*"
]
}
}
```
Untuk informasi selengkapnya tentang bagaimana kebijakan dievaluasi, lihat [Logika evaluasi kebijakan](reference_policies_evaluation-logic.md).
# Izin untuk GetSessionToken
Alasan utama untuk menghubungi operasi API `GetSessionToken` atau Perintah CLI `get-session-token` adalah ketika pengguna harus diautentikasi dengan autentikasi Autentikasi Multi-Faktor (MFA). Hal tersebut memungkinkan untuk menulis kebijakan yang mengizinkan tindakan tertentu hanya jika tindakan tersebut diminta oleh pengguna yang telah diautentikasi dengan MFA. Agar berhasil melewati pemeriksaan otorisasi MFA, pengguna harus melakukan panggilan pertama `GetSessionToken` dan menyertakan opsional parameter `SerialNumber` dan `TokenCode`. Jika pengguna berhasil mengautentikasi dengan sebuah perangkat MFA, kredensial dikembalikan oleh operasi API `GetSessionToken` mencakup konteks MFA. Konteks ini menunjukkan bahwa pengguna diautentikasi dengan MFA dan diotorisasi untuk operasi API yang memerlukan autentikasi MFA.
## Izin diperlukan untuk GetSessionToken
Tidak ada izin yang diperlukan bagi pengguna untuk mendapatkan token sesi. Tujuan dari operasi `GetSessionToken` adalah mengautentikasi pengguna menggunakan MFA. Anda tidak dapat menggunakan kebijakan untuk mengontrol operasi autentikasi.
Untuk memberikan izin untuk melakukan sebagian besar AWS operasi, Anda menambahkan tindakan dengan nama yang sama ke kebijakan. Misalnya, untuk membuat pengguna, Anda harus menggunakan operasi API `CreateUser`, perintah CLI `create-user`, atau Konsol Manajemen AWS. Untuk melakukan operasi ini, Anda harus memiliki kebijakan yang mengijinkan Anda untuk mengakses tindakan `CreateUser`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateUser",
"Resource": "*"
}
]
}
```
------
Anda dapat memasukkan tindakan `GetSessionToken` dalam kebijakan Anda, tetapi tidak itu berpengaruh pada kemampuan pengguna untuk melakukan operasi `GetSessionToken`.
## Izin yang diberikan oleh GetSessionToken
Jika `GetSessionToken` yang dipanggil dengan kredensial pengguna IAM, kredensial keamanan sementara memiliki izin yang sama dengan pengguna IAM. Demikian pula, jika `GetSessionToken` dipanggil dengan Pengguna root akun AWS kredenal, kredenal keamanan sementara memiliki izin pengguna root.
**catatan**
Kami menyarankan agar Anda tidak memanggil `GetSessionToken` dengan kredensial pengguna root. Sebaliknya, ikuti [praktik terbaik](best-practices-use-cases.md) kami dan membuat pengguna IAM dengan izin yang mereka butuhkan. Kemudian gunakan pengguna IAM ini untuk interaksi sehari-hari dengan AWS.
Kredensial sementara yang Anda dapatkan ketika Anda memanggil `GetSessionToken` memiliki kemampuan dan batasan sebagai berikut:
+ Anda dapat menggunakan kredensi untuk mengakses Konsol Manajemen AWS dengan meneruskan kredensialnya ke titik akhir masuk tunggal federasi di. `https://signin.aws.amazon.com/federation` Untuk informasi selengkapnya, lihat [Aktifkan akses broker identitas khusus ke AWS konsol](id_roles_providers_enable-console-custom-url.md).
+ Anda **tidak dapat** menggunakan kredensialnya untuk memanggil operasi IAM atau AWS STS API. Anda **dapat** menggunakannya untuk memanggil operasi API untuk AWS layanan lain.
Bandingkan operasi API ini serta batasan dan kemampuannya dengan operasi API lain yang membuat kredensial keamanan sementara di [Bandingkan AWS STS kredensialnya](id_credentials_sts-comparison.md)
Untuk informasi selengkapnya tentang akses API yang dilindungi MFA menggunakan `GetSessionToken`, lihat [Akses API aman dengan MFA](id_credentials_mfa_configure-api-require.md).
# Menonaktifkan izin untuk kredensial keamanan sementara
Kredensi keamanan sementara berlaku hingga kedaluwarsa. Kredensi ini berlaku untuk durasi yang ditentukan, dari 900 detik (15 menit) hingga maksimum 129.600 detik (36 jam). Durasi sesi default adalah 43.200 detik (12 jam). Anda dapat mencabut kredensil ini, tetapi Anda juga harus mengubah izin untuk pengguna IAM atau peran untuk menghentikan penggunaan kredensil yang disusupi untuk aktivitas akun berbahaya. Izin yang ditetapkan untuk kredensil keamanan sementara dievaluasi setiap kali digunakan untuk membuat permintaan. AWS Setelah Anda menghapus semua izin dari kredensi, AWS permintaan yang menggunakannya gagal.
Mungkin perlu beberapa menit agar pembaruan kebijakan diterapkan. Untuk sesi peran IAM, Anda dapat mencabut kredensil keamanan sementara peran tersebut untuk memaksa semua pengguna yang mengasumsikan peran tersebut untuk mengautentikasi ulang dan meminta kredensil baru. Untuk informasi selengkapnya, lihat [Mencabut kredenal keamanan sementara peran tersebut](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html).
Anda tidak dapat mengubah izin untuk file Pengguna root akun AWS. Demikian juga, Anda tidak dapat mengubah izin untuk kredensial keamanan sementara yang dibuat dengan memanggil `GetFederationToken` atau `GetSessionToken` saat masuk sebagai pengguna root. Karena alasan ini, kami menyarankan agar Anda tidak memanggil `GetFederationToken` atau `GetSessionToken` sebagai pengguna root.
Untuk prosedur tentang cara mengubah izin untuk pengguna IAM, lihat. [Mengubah izin untuk pengguna IAM](id_users_change-permissions.md)
Untuk prosedur tentang cara mengubah izin untuk peran IAM, lihat. [Memperbarui izin untuk peran](id_roles_update-role-permissions.md)
**penting**
Anda tidak dapat mengedit peran di IAM yang dibuat dari kumpulan izin Pusat Identitas IAM. Anda harus mencabut sesi set izin aktif untuk pengguna di Pusat Identitas IAM. Untuk informasi selengkapnya, lihat [Mencabut sesi peran IAM aktif yang dibuat oleh set izin](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions) di Panduan Pengguna Pusat *Identitas IAM*.
**Topics**
+ [Tolak akses ke semua sesi peran IAM yang terkait dengan peran](#deny-access-to-all-sessions)
+ [Tolak akses ke sesi peran IAM tertentu](#deny-access-to-specific-session)
+ [Tolak akses ke sesi kredensi keamanan sementara dengan kunci konteks kondisi](#deny-access-to-specific-session-condition-key)
+ [Tolak akses ke prinsipal tertentu dengan kebijakan berbasis sumber daya](#deny-access-with-resource-based)
## Tolak akses ke semua sesi peran IAM yang terkait dengan peran
Prosedur ini menolak izin untuk **semua** sesi peran IAM yang terkait dengan peran. Gunakan pendekatan ini ketika Anda khawatir tentang akses yang mencurigakan dengan:
+ Prinsipal dari akun lain menggunakan akses lintas akun
+ Identitas pengguna eksternal dengan izin untuk mengakses AWS sumber daya di akun Anda
+ Pengguna yang telah diautentikasi dalam aplikasi seluler atau web dengan penyedia OIDC
Untuk mengubah atau menghapus izin yang ditetapkan ke kredensil keamanan sementara yang diperoleh dengan memanggil`AssumeRole`,, atau,`AssumeRoleWithSAML`, atau `AssumeRoleWithWebIdentity``GetFederationToken`, atau`GetSessionToken`, Anda dapat mengedit atau menghapus kebijakan berbasis identitas yang menentukan izin untuk peran tersebut.
**penting**
Jika ada kebijakan berbasis sumber daya yang memungkinkan akses utama, Anda juga harus menambahkan penolakan eksplisit untuk sumber daya tersebut. Lihat [Tolak akses ke prinsipal tertentu dengan kebijakan berbasis sumber daya](#deny-access-with-resource-based) untuk detail.
**Untuk menolak akses ke **semua** sesi peran IAM yang terkait dengan peran**
1. Masuk ke Konsol Manajemen AWS dan buka konsol IAM.
1. Di panel navigasi, pilih **Peran..**
1. Pilih nama peran yang akan diedit. Anda dapat menggunakan kotak pencarian untuk memfilter daftar.
1. Pilih tab **Izin**.
1. Pilih kebijakan yang relevan untuk diedit. Sebelum Anda mengedit kebijakan terkelola pelanggan, tinjau tab **Entitas yang dilampirkan** untuk menghindari gangguan akses ke identitas lain yang mungkin memiliki kebijakan yang sama.
1. Pilih tab **JSON** dan perbarui kebijakan untuk menolak semua sumber daya dan tindakan.
**catatan**
Izin ini sama dengan yang ada di kebijakan AWS terkelola [AWSDenySemua](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html). Anda dapat melampirkan kebijakan AWS terkelola ini ke setiap pengguna IAM atau peran yang ingin Anda tolak semua aksesnya.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAll",
"Effect": "Deny",
"Action": [
"*"
],
"Resource": "*"
}
]
}
```
------
1. Di halaman **Tinjauan**, tinjau **Ringkasan** kebijakan lalu pilih **Simpan perubahan** untuk menyimpan pekerjaan Anda.
Saat memperbarui kebijakan, perubahan akan memengaruhi izin semua kredensil keamanan sementara yang terkait dengan peran tersebut, termasuk kredensil yang dikeluarkan sebelum Anda mengubah kebijakan izin peran.
Setelah memperbarui kebijakan, Anda dapat [mencabut kredensil keamanan sementara peran tersebut untuk segera mencabut semua izin atas kredenal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) yang dikeluarkan peran tersebut.
## Tolak akses ke sesi peran IAM tertentu
Saat Anda memperbarui peran IAM dengan kebijakan penolakan semua atau menghapus peran sepenuhnya, semua pengguna yang memiliki akses ke peran tersebut akan terganggu. Anda dapat menolak akses tanpa memengaruhi izin semua sesi lain yang terkait dengan peran tersebut.
Izin `Principal` dapat ditolak menggunakan [kunci konteks kondisi atau kebijakan berbasis](#deny-access-to-specific-session-condition-key) [sumber daya](#deny-access-with-resource-based).
**Tip**
Anda dapat menemukan pengguna ARNs federasi menggunakan AWS CloudTrail log. Untuk informasi selengkapnya, lihat [Cara Mudah Mengidentifikasi Pengguna Federasi Anda dengan Menggunakan AWS CloudTrail](https://aws.amazon.com/blogs/security/how-to-easily-identify-your-federated-users-by-using-aws-cloudtrail/).
## Tolak akses ke sesi kredensi keamanan sementara dengan kunci konteks kondisi
Anda dapat menggunakan kunci konteks kondisi dalam kebijakan berbasis identitas dalam situasi di mana Anda ingin menolak akses ke sesi kredensi keamanan sementara tertentu tanpa memengaruhi izin pengguna IAM atau peran yang membuat kredensialnya. Untuk peran IAM, setelah memperbarui kebijakan, Anda juga dapat [mencabut sesi kredensil keamanan sementara peran tersebut untuk segera mencabut semua kredensil](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) yang dikeluarkan.
Untuk informasi selengkapnya tentang kunci konteks kondisi, lihat[AWS kunci konteks kondisi global](reference_policies_condition-keys.md).
### aws: PrincipalArn
Anda dapat menggunakan kunci konteks kondisi [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) dalam kebijakan berbasis identitas untuk menolak akses ke prinsipal tertentu dengan Nama Sumber Daya Amazon (ARN) mereka. Anda melakukannya dengan menentukan ARN pengguna IAM, peran, AWS STS atau sesi pengguna gabungan yang terkait dengan kredensil keamanan sementara dalam elemen Kondisi kebijakan.
**Untuk menolak akses ke kepala sekolah tertentu oleh ARN mereka**
1. **Di panel navigasi konsol IAM, pilih **Pengguna** atau Peran.**
1. Pilih nama pengguna IAM atau peran yang akan diedit. Anda dapat menggunakan kotak pencarian untuk memfilter daftar.
1. Pilih tab **Izin**.
1. Pilih kebijakan yang relevan untuk diedit. Sebelum Anda mengedit kebijakan terkelola pelanggan, tinjau tab **Entitas yang dilampirkan** untuk menghindari gangguan akses ke identitas lain yang mungkin memiliki kebijakan yang sama.
1. Pilih tab **JSON** dan tambahkan pernyataan penolakan untuk ARN utama seperti yang ditunjukkan pada contoh berikut.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:role/ROLENAME",
"arn:aws:iam::222222222222:user/USERNAME",
"arn:aws:iam::222222222222:federated-user/USERNAME"
]
}
}
}
]
}
```
------
1. Di halaman **Tinjauan**, tinjau **Ringkasan** kebijakan lalu pilih **Simpan perubahan** untuk menyimpan pekerjaan Anda.
### aws: SourceIdentity
Anda dapat menggunakan kunci konteks kondisi [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) dalam kebijakan berbasis identitas untuk menolak akses ke identitas sumber tertentu yang terkait dengan sesi peran IAM. Ini berlaku selama sesi peran dikeluarkan dengan menyetel parameter `SourceIdentity` permintaan saat prinsipal mengambil peran menggunakan AWS STS `assume-role` perintah\$1 CLI apa pun, atau AWS STS `AssumeRole` operasi\$1 API. Anda melakukannya dengan menentukan identitas sumber yang terkait dengan kredensi keamanan sementara dalam `Condition` elemen kebijakan.
Tidak seperti kunci konteks [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname), setelah identitas sumber disetel, nilainya tidak dapat diubah. `aws:SourceIdentity`Kuncinya ada dalam konteks permintaan untuk semua tindakan yang diambil oleh peran. Identitas sumber tetap ada di sesi peran berikutnya saat Anda menggunakan kredenal sesi untuk mengambil peran lain. Mengasumsikan satu peran dari peran lain disebut [rantai peran](id_roles.md#iam-term-role-chaining).
Kebijakan berikut menunjukkan contoh bagaimana Anda dapat menolak akses ke sesi kredensi keamanan sementara menggunakan kunci `aws:SourceIdentity` konteks kondisi. Jika Anda menentukan identitas sumber yang terkait dengan sesi peran, itu akan menolak sesi peran dengan identitas sumber bernama tanpa memengaruhi izin peran yang membuat kredensil. Untuk contoh ini, identitas sumber yang ditetapkan oleh kepala sekolah saat sesi peran dikeluarkan adalah`nikki_wolf@example.com`. Setiap permintaan yang dibuat oleh sesi peran dengan identitas sumber `nikki_wolf@example.com` akan ditolak karena identitas sumber disertakan dalam kondisi kebijakan dan Efek kebijakan disetel ke`Deny`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"nikki_wolf@example.com",
""
]
}
}
}
]
}
```
------
### aws:userid
Anda dapat menggunakan kunci konteks kondisi [aws:userid](reference_policies_condition-keys.md#condition-keys-userid) dalam kebijakan berbasis identitas untuk menolak akses ke semua atau sesi kredensi keamanan sementara tertentu yang terkait dengan pengguna atau peran IAM. Anda melakukannya dengan menentukan pengenal unik (ID) pengguna IAM, peran, atau sesi pengguna AWS STS federasi yang terkait dengan kredensil keamanan sementara dalam elemen kebijakan. `Condition`
Kebijakan berikut menunjukkan contoh bagaimana Anda dapat menolak akses ke sesi kredensi keamanan sementara menggunakan kunci `aws:userid` konteks kondisi.
+ `AIDAXUSER1`mewakili ID unik untuk pengguna IAM. Menentukan ID unik pengguna IAM sebagai nilai untuk kunci konteks `aws:userid` akan menolak akses ke pengguna IAM. Ini termasuk sesi kredensi keamanan sementara yang dibuat dengan memanggil `GetSessionToken` API.
+ `AROAXROLE1:*`mewakili ID unik untuk semua sesi yang terkait dengan peran IAM. Menentukan ID unik peran IAM dan karakter wildcard (\$1) di bagian caller-specified-role-session -name sebagai nilai untuk kunci konteks `aws:userid` akan menolak semua sesi yang terkait dengan peran tersebut.
+ `AROAXROLE2:`mewakili ID unik untuk sesi peran yang diasumsikan. Di bagian caller-specified-role-session -name dari ID unik peran yang diasumsikan, Anda dapat menentukan nama sesi peran atau karakter wildcard jika operator kondisi digunakan. StringLike Jika Anda menentukan nama sesi peran, itu akan menolak sesi peran bernama tanpa memengaruhi izin peran yang membuat kredensialnya. Jika Anda menentukan karakter wildcard untuk nama sesi peran, itu akan menolak semua sesi yang terkait dengan peran tersebut.
**catatan**
Nama sesi peran yang ditentukan pemanggil, yang merupakan bagian dari pengenal unik untuk sesi peran yang diasumsikan, dapat berubah selama rantai peran. Role chaining terjadi ketika satu peran mengambil peran lain. Nama sesi peran disetel menggunakan parameter `RoleSessionName` permintaan saat prinsipal mengasumsikan peran menggunakan operasi AWS STS `AssumeRole` API.
+ `account-id:`mewakili ID unik untuk sesi pengguna AWS STS federasi. Pengguna IAM membuat sesi ini dengan memanggil `GetFederationToken` API. Menentukan ID unik untuk sesi pengguna AWS STS federasi menyangkal sesi federasi bernama tanpa memengaruhi izin pengguna IAM yang membuat kredensialnya.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:userId": [
"AIDAXUSER1",
"AROAXROLE1:*",
"AROAXROLE2:",
"123456789012:"
]
}
}
}
]
}
```
------
Untuk contoh spesifik dari nilai kunci utama, lihat[Nilai-nilai kunci utama](reference_policies_variables.md#principaltable). Untuk informasi tentang pengidentifikasi unik IAM dan cara mendapatkannya, lihat. [Pengidentifikasi unik](reference_identifiers.md#identifiers-unique-ids)
## Tolak akses ke prinsipal tertentu dengan kebijakan berbasis sumber daya
Untuk membatasi akses ke prinsipal tertentu dengan kebijakan berbasis sumber daya, Anda dapat menggunakan kunci [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) konteks kondisi atau dalam elemen. [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) `Condition` Kebijakan berbasis sumber daya adalah kebijakan izin yang dilampirkan pada sumber daya dan kontrol siapa yang dapat mengakses sumber daya dan tindakan apa yang dapat mereka lakukan terhadapnya.
Bila Anda menggunakan kunci `aws:PrincipalARN` konteks, tentukan ARN pengguna IAM, peran, atau sesi pengguna AWS STS federasi yang terkait dengan kredensil keamanan sementara dalam elemen Kondisi kebijakan. Contoh kebijakan berikut menunjukkan cara menggunakan kunci `aws:PrincipalARN` konteks dalam kebijakan berbasis sumber daya:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": "*",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:role/ROLENAME",
"arn:aws:iam::222222222222:user/USERNAME",
"arn:aws:sts::222222222222:federated-user/USERNAME"
]
}
}
}
}
```
------
Bila Anda menggunakan kunci `aws:SourceIdentity` konteks, tentukan nilai identitas sumber yang terkait dengan kredensil keamanan sementara peran dalam `Condition` elemen kebijakan. Ini berlaku selama sesi peran dikeluarkan dengan menyetel parameter `SourceIdentity` permintaan saat prinsipal mengambil peran menggunakan AWS STS `assume-role` perintah\$1 CLI apa pun, atau AWS STS `AssumeRole` operasi\$1 API. Contoh berikut menunjukkan cara menggunakan kunci `aws:SourceIdentity` konteks dalam kebijakan berbasis sumber daya:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": "*",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"nikki_wolf@example.com",
""
]
}
}
}
}
```
------
Jika Anda hanya memperbarui kebijakan berbasis identitas untuk prinsipal, mereka masih dapat melakukan tindakan yang diizinkan dalam kebijakan berbasis sumber daya, kecuali jika tindakan tersebut secara eksplisit ditolak dalam kebijakan berbasis identitas.
**Untuk menolak akses ke prinsipal tertentu dalam kebijakan berbasis sumber daya**
1. Lihat [AWS layanan yang bekerja dengan IAM](reference_aws-services-that-work-with-iam.md) untuk melihat apakah layanan mendukung kebijakan berbasis sumber daya.
1. Masuk ke Konsol Manajemen AWS dan buka konsol untuk layanan ini. Setiap layanan memiliki lokasi yang berbeda di konsol untuk melampirkan kebijakan.
1. Edit kebijakan berbasis sumber daya. Tambahkan pernyataan kebijakan penolakan untuk menentukan informasi identifikasi kredensi:
1. Dalam `Principal` elemen, masukkan wildcard (\$1). Kepala sekolah akan dibatasi dalam `Condition` elemen.
1. Dalam `Effect` elemen, masukkan “Deny.”
1. Masuk`Action`, masukkan namespace layanan dan nama tindakan yang akan ditolak. Untuk menolak semua tindakan, gunakan karakter wildcard (\$1). Sebagai contoh: `"s3:*"`.
1. Dalam `Resource` elemen, masukkan ARN dari sumber daya target. Sebagai contoh: `"arn:aws:s3:::amzn-s3-demo-bucket"`.
1. Dalam `Condition` elemen, tentukan kunci `aws:PrincipalARN` atau `aws:SourceIdentity` konteks.
Jika Anda menggunakan tombol `aws:PrincipalARN` konteks, masukkan ARN kepala sekolah untuk menolak akses.
Jika Anda menggunakan kunci `aws:SourceIdentity` konteks, masukkan nilai identitas sumber yang ditetapkan dalam sesi peran untuk menolak akses.
1. Simpan pekerjaan Anda.
# Memberikan izin untuk membuat kredensial keamanan sementara
Secara default, pengguna IAM tidak memiliki izin untuk membuat kredensil keamanan sementara untuk sesi dan peran pengguna AWS STS federasi. Anda harus menggunakan kebijakan untuk memberikan izin ini kepada pengguna Anda. Meskipun Anda dapat memberikan izin secara langsung kepada pengguna, kami sangat menyarankan agar Anda memberikan izin kepada grup. Ini menjadikan pengelolaan izin jauh lebih mudah. Saat seseorang tidak lagi perlu melakukan tugas yang terkait dengan izin, Anda cukup menghapusnya dari grup. Jika orang lain perlu melakukan tugas tersebut, tambahkan mereka ke grup untuk memberikan izin.
Untuk memberikan izin grup IAM untuk membuat kredensil keamanan sementara untuk sesi atau peran pengguna AWS STS gabungan, Anda melampirkan kebijakan yang memberikan salah satu atau kedua hak istimewa berikut:
+ Untuk kepala sekolah federasi OIDC dan SALL untuk mengakses peran IAM, berikan akses ke. AWS STS `AssumeRole`
+ Untuk pengguna AWS STS federasi yang tidak memerlukan peran, berikan akses ke AWS STS `GetFederationToken`.
Untuk informasi selengkapnya tentang perbedaan antara operasi API `AssumeRole` dan `GetFederationToken`, lihat [Minta kredensil keamanan sementara](id_credentials_temp_request.md).
Pengguna IAM juga dapat memanggil [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) untuk membuat kredensial keamanan sementara. Tidak ada izin yang diperlukan bagi pengguna untuk memanggil `GetSessionToken`. Tujuan dari operasi ini adalah mengautentikasi pengguna menggunakan MFA. Anda tidak dapat menggunakan kebijakan untuk mengontrol autentikasi. Ini artinya Anda tidak dapat mencegah pengguna IAM melakukan panggilan `GetSessionToken` untuk membuat kredensial sementara.
**Example Contoh kebijakan yang memberikan izin untuk mengambil peran**
Contoh kebijakan berikut memberikan izin `AssumeRole` untuk memanggil `UpdateApp` peran dalam Akun AWS `123123123123`. Saat `AssumeRole` digunakan, pengguna (atau aplikasi) yang membuat kredensial keamanan atas nama pengguna gabungan tidak dapat mengurangi izin apapun yang belum ditentukan dalam kebijakan izin peran.
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123123123123:role/UpdateAPP"
}]
}
```
**Example Contoh kebijakan yang memberikan izin untuk membuat kredensial keamanan sementara bagi pengguna gabungan.**
Contoh kebijakan berikut memberikan izin untuk mengakses `GetFederationToken`.
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
}]
}
```
**penting**
Saat Anda memberi izin kepada pengguna IAM untuk membuat kredensil keamanan sementara untuk pengguna AWS STS federasi`GetFederationToken`, ketahuilah bahwa ini memungkinkan pengguna tersebut untuk mendelegasikan izin mereka sendiri. Untuk informasi selengkapnya tentang mendelegasikan izin di seluruh pengguna IAM dan Akun AWS, lihat. [Contoh kebijakan untuk mendelegasikan akses](id_roles_create_policy-examples.md) Untuk informasi selengkapnya tentang mengatur izin pada kredensial keamanan sementara, lihat [Izin untuk kredensial keamanan sementara](id_credentials_temp_control-access.md).
**Example Contoh kebijakan yang memberikan izin terbatas kepada pengguna untuk membuat kredensial keamanan sementara bagi pengguna gabungan.**
Saat Anda mengizinkan pengguna IAM memanggil `GetFederationToken`, ini adalah penerapan terbaik untuk membatasi izin yang dapat dikeluarkan oleh pengguna IAM. *Misalnya, kebijakan berikut menunjukkan cara mengizinkan pengguna IAM membuat kredensil keamanan sementara hanya untuk pengguna AWS STS federasi yang namanya dimulai dengan Manajer.*
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": ["arn:aws:sts::123456789012:federated-user/Manager*"]
}]
}
```
# Memberikan izin untuk menggunakan sesi konsol yang disempurnakan identitas
Sesi konsol yang disempurnakan identitas memungkinkan AWS IAM Identity Center pengguna dan sesi IDs untuk disertakan dalam sesi AWS konsol pengguna saat mereka masuk. Misalnya, Amazon Q Developer Pro menggunakan sesi konsol yang disempurnakan identitas untuk mempersonalisasi pengalaman layanan. *Untuk informasi selengkapnya tentang sesi konsol yang disempurnakan identitas, lihat [Mengaktifkan sesi konsol yang disempurnakan identitas](https://docs.aws.amazon.com/singlesignon/latest/userguide/identity-enhanced-sessions.html) di Panduan Pengguna.AWS IAM Identity Center * Untuk informasi tentang penyiapan Pengembang Amazon Q, lihat [Menyiapkan Pengembang Amazon Q](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/setting-up.html) di *Panduan Pengguna Pengembang Amazon Q*.
Agar sesi konsol yang disempurnakan identitas tersedia bagi pengguna, Anda harus menggunakan kebijakan berbasis identitas untuk memberikan `sts:SetContext` izin kepada prinsipal IAM untuk sumber daya yang mewakili sesi konsol mereka sendiri.
**penting**
Secara default, pengguna tidak memiliki izin untuk menyetel konteks untuk sesi konsol yang disempurnakan identitas mereka. Untuk mengizinkan hal ini, Anda harus memberikan `sts:SetContext` izin kepada kepala IAM dalam kebijakan berbasis identitas seperti yang ditunjukkan pada contoh kebijakan di bawah ini.
Contoh kebijakan berbasis identitas berikut memberikan `sts:SetContext` izin kepada prinsipal IAM, memungkinkan prinsipal untuk mengatur konteks sesi konsol yang ditingkatkan identitas untuk sesi konsol mereka sendiri. AWS Sumber daya kebijakan,`arn:aws:sts::account-id:self`, mewakili AWS sesi pemanggil. Segmen `account-id` ARN dapat diganti dengan karakter `*` wildcard jika kebijakan izin yang sama diterapkan di beberapa akun, seperti saat kebijakan ini diterapkan menggunakan set izin Pusat Identitas IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:SetContext",
"Resource": "arn:aws:sts::111122223333:self"
}
]
}
```
------