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

AWS Elemen kebijakan JSON: Principal

Gunakan Principal elemen dalam kebijakan JSON berbasis sumber daya untuk menentukan prinsipal yang diizinkan atau ditolak akses ke sumber daya.

Anda harus menggunakan Principal elemen dalam kebijakan berbasis sumber daya. Beberapa layanan mendukung kebijakan berbasis sumber daya, termasuk IAM. Jenis kebijakan berbasis sumber daya IAM adalah kebijakan kepercayaan peran. Dalam peran IAM, gunakan Principal elemen dalam kebijakan kepercayaan peran untuk menentukan siapa yang dapat mengambil peran tersebut. Untuk akses akun silang, Anda harus menentukan pengidentifikasi 12-digit dari akun tepercaya. Untuk mempelajari apakah prinsipal dalam akun di luar zona kepercayaan (organisasi atau akun terpercaya) memiliki akses untuk mengasumsikan peran Anda, lihat Apa yang dimaksud dengan Penganalisis Akses IAM?.

Contoh sumber daya lain yang mendukung kebijakan berbasis sumber daya termasuk bucket Amazon S3 atau file. AWS KMS key

Anda tidak dapat menggunakan Principal elemen dalam kebijakan berbasis identitas. Kebijakan berbasis identitas adalah kebijakan izin yang Anda lampirkan ke identitas IAM (pengguna, grup, atau peran). Dalam kasus tersebut, kepala sekolah secara implisit adalah identitas di mana kebijakan dilampirkan.

Cara menentukan kepala sekolah

Anda menentukan prinsipal dalam Principal elemen kebijakan berbasis sumber daya atau dalam kunci kondisi yang mendukung prinsipal.

Anda dapat menyebutkan salah satu prinsip dasar berikut dalam kebijakan:

Anda tidak dapat mengidentifikasi grup pengguna sebagai prinsipal dalam kebijakan (seperti kebijakan berbasis sumber daya) karena grup terkait dengan izin, bukan autentikasi, dan prinsipal adalah entitas IAM yang diautentikasi.

Anda dapat menentukan lebih dari satu prinsipal untuk masing-masing tipe prinsipal dalam bagian berikut menggunakan array. Susunan dapat mengambil satu atau beberapa nilai. Saat Anda menentukan lebih dari satu prinsipal dalam suatu elemen, Anda memberikan izin kepada setiap prinsipal. Ini logis OR dan bukan logisAND, karena Anda mengautentikasi sebagai satu prinsipal pada satu waktu. Jika Anda menyertakan lebih dari satu nilai, gunakan tanda kurung siku ([dan]) dan comma-delimit setiap entri untuk array. Contoh kebijakan berikut mendefinisikan izin untuk akun 123456789012 atau akun 555555555555.

"Principal" : { 
"AWS": [ 
  "123456789012",
  "555555555555" 
  ]
}

Akun AWS kepala sekolah

Anda dapat menentukan Akun AWS pengidentifikasi dalam Principal elemen kebijakan berbasis sumber daya atau dalam kunci kondisi yang mendukung prinsipal. Ini mendelegasikan wewenang ke akun. Ketika Anda mengizinkan akses ke akun yang berbeda, administrator di akun tersebut kemudian harus memberikan akses ke identitas (pengguna atau peran IAM) di akun tersebut. Ketika Anda menentukan Akun AWS, Anda dapat menggunakan akun ARN (arn:aws:iam: ::rootaccount-ID), atau formulir singkat yang terdiri dari awalan diikuti oleh ID akun. "AWS":

Misalnya, memberikan ID akun 123456789012, Anda dapat menggunakan dari metode berikut untuk menyebutkan akun tersebut di elemen Principal:

"Principal": { "AWS": "arn:aws:iam::123456789012:root" }

"Principal": { "AWS": "123456789012" }

Akun ARN dan ID akun yang dipersingkat berperilaku dengan cara yang sama. Keduanya mendelegasikan izin ke akun. Menggunakan akun ARN dalam Principal elemen tidak membatasi izin hanya untuk pengguna root akun.

Beberapa AWS layanan mendukung opsi tambahan untuk menentukan pokok akun. Misalnya, Amazon S3 memungkinkan Anda menentukan ID pengguna canonik menggunakan format berikut:

"Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" }

Anda juga dapat menentukan lebih dari satu Akun AWS, (atau ID pengguna kanonik) sebagai prinsipal menggunakan array. Misalnya, Anda dapat menentukan prinsipal dalam kebijakan bucket menggunakan ketiga metode tersebut.

"Principal": { 
  "AWS": [
    "arn:aws:iam::123456789012:root",
    "999999999999"
  ],
  "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be"
}

Kepala peran IAM

Anda dapat menentukan prinsipal peran IAM ARNs dalam Principal elemen kebijakan berbasis sumber daya atau dalam kunci kondisi yang mendukung prinsipal. Peran IAM adalah identitas. Di IAM, identitas adalah sumber daya yang dapat Anda tetapkan izin. Peran mempercayai identitas lain yang diautentikasi untuk mengambil peran itu. Ini termasuk prinsipal di AWS atau pengguna dari penyedia identitas eksternal (iDP). Ketika prinsipal atau identitas mengambil peran, mereka menerima kredensil keamanan sementara dengan izin peran yang diasumsikan. Ketika mereka menggunakan kredensi sesi tersebut untuk melakukan operasi AWS, mereka menjadi kepala sesi peran.

Saat Anda menentukan prinsipal peran dalam kebijakan berbasis sumber daya, izin efektif untuk prinsipal dibatasi oleh jenis kebijakan apa pun yang membatasi izin untuk peran tersebut. Ini termasuk kebijakan sesi dan batas izin. Untuk informasi selengkapnya tentang bagaimana izin efektif untuk sesi peran dievaluasi, lihat. Logika evaluasi kebijakan

Untuk menentukan peran ARN dalam Principal elemen, gunakan format berikut:

"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" }

Atau, Anda dapat menentukan prinsipal peran sebagai prinsipal dalam kebijakan berbasis sumber daya atau membuat kebijakan izin luas yang menggunakan kunci kondisi. aws:PrincipalArn Saat Anda menggunakan kunci ini, prinsipal sesi peran diberikan izin berdasarkan ARN peran yang diasumsikan, dan bukan ARN dari sesi yang dihasilkan. Karena AWS tidak mengonversi kunci kondisi ARNs menjadi IDs, izin yang diberikan ke ARN peran tetap ada jika Anda menghapus peran dan kemudian membuat peran baru dengan nama yang sama. Jenis kebijakan berbasis identitas, seperti batas izin atau kebijakan sesi, tidak membatasi izin yang diberikan menggunakan kunci aws:PrincipalArn kondisi dengan wildcard (*) di Principal elemen, kecuali kebijakan berbasis identitas berisi penolakan eksplisit.

Kepala sesi peran

Anda dapat menentukan sesi peran dalam Principal elemen kebijakan berbasis sumber daya atau dalam kunci kondisi yang mendukung prinsipal. Ketika prinsipal atau identitas mengambil peran, mereka menerima kredensil keamanan sementara dengan izin peran yang diasumsikan. Ketika mereka menggunakan kredensi sesi tersebut untuk melakukan operasi AWS, mereka menjadi kepala sesi peran.

Format yang Anda gunakan untuk prinsipal sesi peran bergantung pada AWS STS operasi yang digunakan untuk mengambil peran.

Selain itu, administrator dapat merancang proses untuk mengontrol bagaimana sesi peran dikeluarkan. Misalnya, mereka dapat memberikan solusi satu-klik untuk penggunanya yang membuat nama sesi yang dapat diprediksi. Jika administrator melakukan ini, Anda dapat menggunakan prinsip sesi peran dalam kebijakan atau kunci kondisi. Jika tidak, Anda dapat menentukan peran ARN sebagai prinsipal dalam kunci aws:PrincipalArn kondisi. Cara Anda menentukan peran sebagai prinsipal dapat mengubah izin efektif untuk sesi yang dihasilkan. Untuk informasi selengkapnya, lihat Kepala peran IAM.

Prinsip sesi peran yang diasumsikan

Prinsip sesi peran yang diasumsikan adalah prinsip sesi yang dihasilkan dari penggunaan operasi. AWS STS AssumeRole Untuk informasi lebih lanjut tentang prinsipal mana yang dapat mengambil peran menggunakan operasi ini, lihat. Bandingkan AWS STS kredensialnya

Untuk menentukan ARN sesi peran yang diasumsikan dalam elemen, gunakan format Principal berikut:

"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }

Saat Anda menentukan sesi peran yang diasumsikan dalam Principal elemen, Anda tidak dapat menggunakan wildcard “*” yang berarti semua sesi. Prinsipal harus selalu menamai sesi tertentu.

Kepala sekolah federasi OIDC

Prinsipal federasi OIDC adalah prinsipal yang digunakan saat memanggil AWS STS AssumeRoleWithWebIdentity API dengan token web JSON (JWT) dari IDP yang sesuai dengan OIDC, juga dikenal sebagai Penyedia OpenID (OP), untuk meminta kredensyal sementara. AWS Prinsipal federasi OIDC dapat mewakili IDP OIDC di AWS akun Anda, atau 4 penyedia identitas bawaan:Login with Amazon,,, dan Amazon Cognito. GoogleFacebook

Pengguna, beban kerja, atau sistem yang telah mengeluarkan JWT dari IDP OIDC mereka dapat menelepon AssumeRoleWithWebIdentity menggunakan JWT untuk meminta kredensyal AWS keamanan sementara untuk peran IAM yang dikonfigurasi untuk mempercayai IDP OIDC yang mengeluarkan JWT. JWT dapat berupa token id, token akses, atau token JWT yang dikirimkan dengan metode lain selama memenuhi persyaratan yang tercantum oleh. AWS STS Untuk informasi selengkapnya, lihat Skenario umum dan Meminta kredensional melalui penyedia OIDC.

Gunakan tipe utama ini dalam kebijakan kepercayaan peran Anda untuk mengizinkan atau menolak izin untuk menelepon AssumeRoleWIthWebIdentity menggunakan IDP OIDC yang ada di Anda Akun AWS, atau salah satu dari empat bawaan. IDPs Untuk menentukan ARN utama federasi OIDC dalam Principal elemen kebijakan kepercayaan peran, gunakan salah satu dari empat format berikut untuk OIDC bawaan: IDPs

"Principal": { "Federated": "cognito-identity.amazonaws.com" }

"Principal": { "Federated": "www.amazon.com" }

"Principal": { "Federated": "graph.facebook.com" }

"Principal": { "Federated": "accounts.google.com" }

Saat menggunakan penyedia OIDC yang Anda tambahkan ke akun, misalnya GitHub, Anda menentukan ARN penyedia dalam kebijakan kepercayaan peran Anda. Konfigurasi ini memungkinkan Anda untuk menulis kebijakan IAM yang mengontrol akses khusus untuk pengguna yang diautentikasi melalui penyedia identitas kustom Anda.

"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/full-OIDC-identity-provider-URL" }

Misalnya, jika GitHub penyedia identitas web tepercaya, sesi peran OIDC ARN dalam Principal elemen kebijakan kepercayaan peran menggunakan format berikut:

"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/tokens.actions.githubusercontent.com" }

Lihat Mengonfigurasi OpenID Connect di Amazon Web Services untuk informasi selengkapnya.

Prinsipal federasi OIDC tidak didukung dalam jenis kebijakan selain kebijakan kepercayaan peran.

Kepala sekolah federasi SALL

Prinsipal federasi SAMP adalah prinsipal yang digunakan saat memanggil AWS STS AssumeRoleWithSAML API untuk meminta AWS kredensyal sementara menggunakan pernyataan SAMP. Anda dapat menggunakan penyedia identitas SAMP (IDP) untuk masuk, dan kemudian mengambil peran IAM menggunakan operasi ini. Mirip denganAssumeRoleWithWebIdentity, AssumeRoleWithSAML tidak memerlukan AWS kredensil untuk otentikasi. Sebagai gantinya, pengguna pertama-tama mengautentikasi dengan penyedia identitas SAMP mereka, lalu melakukan panggilan AssumeRoleWithSAML API menggunakan pernyataan SAMP mereka, atau diarahkan ke halaman Masuk/SAMP untuk AWS masuk ke halaman. AWS Management Console Untuk informasi lebih lanjut tentang prinsipal mana yang dapat mengambil peran menggunakan operasi ini, lihat. Bandingkan AWS STS kredensialnya

Gunakan tipe utama ini dalam kebijakan kepercayaan peran Anda untuk mengizinkan atau menolak izin berdasarkan penyedia identitas SAMP tepercaya. Untuk menentukan ARN sesi peran identitas SAMP dalam Principal elemen kebijakan kepercayaan peran, gunakan format berikut:

"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" }

Prinsipal pengguna IAM

Anda dapat menentukan pengguna IAM dalam Principal elemen kebijakan berbasis sumber daya atau dalam kunci kondisi yang mendukung prinsipal.

"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:user/user-name" }

"Principal": {
  "AWS": [
    "arn:aws:iam::AWS-account-ID:user/user-name-1", 
    "arn:aws:iam::AWS-account-ID:user/user-name-2"
  ]
}

Saat Anda menentukan pengguna di elemen Principal, Anda tidak dapat menggunakan wildcard (*) yang berarti “semua pengguna”. Prinsipal harus selalu memberi nama pengguna tertentu.

Kepala Pusat Identitas IAM

Dalam IAM Identity Center, prinsipal dalam kebijakan berbasis sumber daya harus didefinisikan sebagai prinsipal. Akun AWS Untuk menentukan akses, rujuk peran ARN dari izin yang ditetapkan di blok kondisi. Untuk detailnya, lihat Mereferensikan set izin dalam kebijakan sumber daya, Amazon EKS, dan AWS KMS di Panduan Pengguna Pusat Identitas IAM.

AWS STS prinsip pengguna federasi

Anda dapat menentukan sesi pengguna federasi dalam Principal elemen kebijakan berbasis sumber daya atau dalam kunci kondisi yang mendukung prinsipal.

Prinsipal pengguna AWS STS federasi dibuat melalui GetFederationToken operasi yang disebut dengan kredensil IAM berumur panjang. Izin pengguna federasi adalah persimpangan dari prinsipal yang dipanggil GetFederationToken dan kebijakan sesi diteruskan sebagai parameter ke API. GetFederationToken

Di AWS, pengguna IAM atau Pengguna root akun AWS dapat mengautentikasi menggunakan kunci akses jangka panjang. Untuk informasi lebih lanjut tentang kepala sekolah mana yang dapat berfederasi menggunakan operasi ini, lihat. Bandingkan AWS STS kredensialnya

Ketika pengguna IAM atau pengguna root meminta kredensyal sementara dari AWS STS menggunakan operasi ini, mereka memulai sesi pengguna federasi sementara. ARN sesi ini didasarkan pada identitas asli yang difederasi.

Untuk menentukan ARN sesi pengguna federasi dalam Principal elemen, gunakan format berikut:

"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:federated-user/user-name" }

AWS prinsipal layanan

Anda dapat menentukan AWS layanan dalam Principal elemen kebijakan berbasis sumber daya atau dalam kunci kondisi yang mendukung prinsipal. Prinsipal layanan adalah pengidentifikasi untuk suatu layanan.

Peran IAM yang dapat diasumsikan oleh AWS layanan disebut peran layanan. Peran layanan harus menyertakan kebijakan kepercayaan. Kebijakan kepercayaan adalah kebijakan berbasis sumber daya yang melekat pada peran yang menentukan prinsip mana yang dapat mengambil peran tersebut. Beberapa peran layanan telah menetapkan kebijakan kepercayaan. Namun, dalam beberapa kasus, Anda harus menentukan prinsip utama layanan dalam kebijakan kepercayaan. Prinsip layanan dalam kebijakan IAM tidak bisa"Service": "*".

Prinsipal layanan ditentukan oleh layanan. Anda dapat menemukan prinsipal layanan untuk beberapa layanan dengan membuka AWS layanan yang bekerja dengan IAM, memeriksa apakah layanan memiliki Ya di kolom Peran yang dikaitkan dengan layanan, dan membuka tautan Ya untuk melihat dokumentasi peran yang dikaitkan dengan layanan untuk layanan tersebut. Temukan bagian Izin Peran Ditautkan Layanan untuk layanan tersebut dapat melihat prinsipal layanan.

Contoh berikut menunjukkan kebijakan yang dapat dilampirkan pada peran layanan. Kebijakan tersebut memungkinkan dua layanan, Amazon ECS dan Elastic Load Balancing, untuk mengambil peran tersebut. Layanan kemudian dapat melakukan tugas yang diberikan oleh kebijakan izin yang ditetapkan untuk peran tersebut (tidak ditampilkan). Untuk menetapkan beberapa prinsipal layanan, Anda tidak menentukan dua elemen Service; Anda hanya dapat memiliki satu. Sebagai gantinya, Anda menggunakan serangkaian dari beberapa prinsipal layanan sebagai nilai elemen Service tunggal.

"Principal": {
    "Service": [
        "ecs.amazonaws.com",
        "elasticloadbalancing.amazonaws.com"
   ]
}

AWS prinsip layanan di Wilayah keikutsertaan

Anda dapat meluncurkan sumber daya di beberapa AWS Wilayah dan beberapa Wilayah yang harus Anda pilih. Untuk daftar lengkap Wilayah yang harus Anda pilih, lihat Mengelola AWS Wilayah di Referensi Umum AWSpanduan.

Ketika suatu AWS layanan di Wilayah keikutsertaan membuat permintaan dalam Wilayah yang sama, format nama utama layanan diidentifikasi sebagai versi non-regional dari nama utama layanan mereka:

service-name.amazonaws.com

Ketika suatu AWS layanan di Wilayah keikutsertaan membuat permintaan lintas wilayah ke Wilayah lain, format nama utama layanan diidentifikasi sebagai versi regional dari nama utama layanan mereka:

service-name.{region}.amazonaws.com

Misalnya, Anda memiliki topik Amazon SNS yang terletak di Wilayah ap-southeast-1 dan bucket Amazon S3 yang terletak di Wilayah keikutsertaan. ap-east-1 Anda ingin mengonfigurasi notifikasi bucket S3 untuk mempublikasikan pesan ke topik SNS. Untuk mengizinkan layanan S3 memposting pesan ke topik SNS, Anda harus memberikan sns:Publish izin utama layanan S3 melalui kebijakan akses berbasis sumber daya dari topik tersebut.

Jika Anda menentukan versi non-regionalisasi dari prinsipal layanan S3s3.amazonaws.com, dalam kebijakan akses topik, sns:Publish permintaan dari bucket ke topik akan gagal. Contoh berikut menentukan prinsip layanan S3 non-regionalisasi dalam elemen Principal kebijakan kebijakan akses topik SNS.

"Principal": { "Service": "s3.amazonaws.com" }

Karena bucket terletak di Wilayah keikutsertaan dan permintaan dibuat di luar Wilayah yang sama, prinsipal layanan S3 muncul sebagai nama utama layanan regional,. s3.ap-east-1.amazonaws.com Anda harus menggunakan nama utama layanan regional ketika AWS layanan di Wilayah opt-in mengajukan permintaan ke Wilayah lain. Setelah Anda menentukan nama utama layanan regional, jika bucket membuat sns:Publish permintaan ke topik SNS yang terletak di Wilayah lain, permintaan akan berhasil. Contoh berikut menentukan prinsipal layanan S3 regional dalam elemen Principal kebijakan kebijakan akses topik SNS.

"Principal": { "Service": "s3.ap-east-1.amazonaws.com" }

Kebijakan sumber daya atau daftar izin berbasis prinsip layanan untuk permintaan Lintas wilayah dari Wilayah keikutsertaan ke Wilayah lain hanya akan berhasil jika Anda menentukan nama utama layanan regional.

Semua kepala sekolah

Anda dapat menggunakan wildcard (*) untuk menentukan semua prinsipal dalam Principal elemen kebijakan berbasis sumber daya atau dalam kunci kondisi yang mendukung prinsipal. Kebijakan berbasis sumber dayaizin pemberian dan kunci kondisi digunakan untuk membatasi kondisi pernyataan kebijakan.

Untuk kebijakan berbasis sumber daya, menggunakan wildcard (*) dengan Allow efek memberikan akses ke semua pengguna, termasuk pengguna anonim (akses publik). Untuk pengguna IAM dan kepala peran dalam akun Anda, tidak ada izin lain yang diperlukan. Untuk prinsipal di akun lain, mereka juga harus memiliki izin berbasis identitas di akun mereka yang memungkinkan mereka mengakses sumber daya Anda. Ini disebut akses lintas akun.

Untuk pengguna anonim, elemen berikut ini setara:

"Principal": "*"

"Principal" : { "AWS" : "*" }

Anda tidak dapat menggunakan wildcard untuk mencocokkan sebagian nama pengguna utama atau ARN.

Contoh berikut menunjukkan kebijakan berbasis sumber daya yang dapat digunakan sebagai pengganti AWS Elemen kebijakan JSON: NotPrincipal untuk secara eksplisit menolak semua prinsipal kecuali yang ditentukan dalam elemen. Condition Kebijakan ini harus ditambahkan ke bucket Amazon S3.

JSON

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "UsePrincipalArnInsteadOfNotPrincipalWithDeny",
      "Effect": "Deny",
      "Action": "s3:*",
      "Principal": "*",
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket/*",
        "arn:aws:s3:::amzn-s3-demo-bucket"
      ],
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": "arn:aws:iam::444455556666:user/user-name"
        }
      }
    }
  ]
}

Informasi selengkapnya

Untuk informasi selengkapnya, lihat berikut ini: