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 prinsip 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. AWS KMS key

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

Cara menentukan prinsipal

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 berhubungan dengan izin, bukan otentikasi, 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. Bila Anda menentukan lebih dari satu prinsipal dalam elemen, Anda memberikan izin untuk setiap prinsipal. Ini logis OR dan tidak logisAND, karena Anda mengotentikasi sebagai satu kepala sekolah pada satu waktu. Jika Anda menyertakan lebih dari satu nilai, gunakan tanda kurung persegi ([dan]) dan batasi koma setiap entri untuk array. Kebijakan contoh berikut menentukan izin untuk akun 123456789012 atau akun 555555555555.

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

Akun AWS utama

Anda dapat menentukan Akun AWS pengidentifikasi dalam Principal elemen kebijakan berbasis sumber daya atau dalam kunci kondisi yang mendukung prinsipal. Ini mendelegasikan otoritas 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 bentuk 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" }

ARN akun 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 prinsipal 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"
}

Prinsip peran IAM

Anda dapat menentukan ARN utama peran IAM 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 AWS atau pengguna dari penyedia identitas eksternal (IdP). Ketika kepala sekolah atau identitas mengambil peran, mereka menerima kredentif keamanan sementara dengan izin peran yang diasumsikan. Ketika mereka menggunakan kredentif 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, lihatLogika 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 prinsip peran sebagai prinsipal dalam kebijakan berbasis sumber daya atau membuat kebijakan izin luas yang menggunakan kunci kondisi. aws:PrincipalArn Bila Anda menggunakan kunci ini, prinsip sesi peran diberikan izin berdasarkan ARN peran yang diasumsikan, dan bukan ARN sesi yang dihasilkan. Karena AWS tidak mengubah ARN kunci kondisi menjadi ID, izin yang diberikan ke peran ARN tetap ada jika Anda menghapus peran dan kemudian membuat peran baru dengan nama yang sama. Identity-based jenis kebijakan, 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.

Prinsip sesi peran

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

Format yang Anda gunakan untuk prinsip sesi peran tergantung pada AWS STS operasi yang digunakan untuk mengambil peran.

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

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

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

Prinsipal federasi OIDC

Prinsip federasi OIDC adalah prinsip yang digunakan saat memanggil AWS STS AssumeRoleWithWebIdentity API dengan token web JSON (JWT) dari IDP yang sesuai dengan OIDC, juga dikenal sebagai OpenID Provider (OP), untuk meminta kredenSIAL sementara. AWS Prinsipal federasi OIDC dapat mewakili IDP OIDC di AWS akun Anda, atau 4 penyedia identitas bawaan:,,, Login with Amazon GoogleFacebook, dan Amazon Cognito. https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html

Pengguna, beban kerja, atau sistem yang telah mengeluarkan JWT dari IDP OIDC mereka dapat memanggil AssumeRoleWithWebIdentity menggunakan JWT untuk meminta kredenSIAL 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 S kenario umum dan Meminta kredenSIAL melalui penyedia OIDC.

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

"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 Anda, misalnya GitHub, Anda menentukan ARN penyedia dalam kebijakan kepercayaan peran Anda. Konfigurasi ini memungkinkan Anda 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, ARN sesi peran OIDC dalam Principal elemen kebijakan kepercayaan peran menggunakan format berikut:

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

Lihat Meng onfigurasi OpenID Connect di Amazon Web Services untuk informasi selengkapnya.

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

Prinsipal federasi SAML

Prinsip federasi SAML adalah prinsip yang digunakan saat memanggil AWS STS AssumeRoleWithSAML API untuk meminta AWS kredenSIAL sementara menggunakan pernyataan SAML. Anda dapat menggunakan penyedia identitas SAML (IDP) untuk masuk, dan kemudian mengambil peran IAM menggunakan operasi ini. Mirip denganAssumeRoleWithWebIdentity, AssumeRoleWithSAML tidak memerlukan AWS kredenSIAL untuk otentikasi. Sebagai gantinya, pengguna pertama-tama mengotentikasi dengan penyedia identitas SAML mereka, kemudian melakukan panggilan AssumeRoleWithSAML API menggunakan pernyataan SAML mereka, atau diarahkan ke AWS Sign-In/SAML halaman untuk masuk ke. Konsol Manajemen AWS Untuk informasi selengkapnya tentang prinsipal mana yang dapat mengambil peran menggunakan operasi ini, lihatBandingkan AWS STS kredensialnya.

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

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

Prinsip 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”. Kepala sekolah harus selalu memberi nama pengguna tertentu.

Kepala Pusat Identitas IAM

Di Pusat Identitas IAM, prinsipal dalam kebijakan berbasis sumber daya harus didefinisikan sebagai prinsipal. Akun AWS Untuk menentukan akses, referensi peran ARN dari izin yang ditetapkan dalam blok kondisi. Untuk detailnya, lihat Referensi kumpulan izin di kebijakan sumber daya, Amazon EKS, dan AWS KMS di Panduan Pengguna Pusat Identitas IAM.

AWS STS prinsipal pengguna federasi

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

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

Di AWS, pengguna IAM atau pengguna Pengguna root akun AWS dapat mengotentikasi menggunakan kunci akses jangka panjang. Untuk informasi selengkapnya tentang prinsipal mana yang dapat berfederasi menggunakan operasi ini, lihat. Bandingkan AWS STS kredensialnya

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

Untuk menentukan sesi pengguna federasi ARN 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. Prinsi p layanan adalah pengidentifikasi untuk layanan.

Peran IAM yang dapat diasumsikan oleh AWS layanan disebut peran .iam-term-service-role layanan. Peran layanan harus menyertakan kebijakan kepercayaan. Kebijakan kepercayaan adalah kebijakan berbasis sumber daya yang melekat pada peran yang menentukan kepala sekolah 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 membukaAWS layanan yang bekerja dengan IAM, memeriksa apakah layanan memiliki Ya di kolom Service-linked peran, dan membuka tautan Ya untuk melihat dokumentasi peran terkait layanan untuk layanan tersebut. Temukan bagian Service-Linked Izin Peran untuk layanan tersebut untuk 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 prinsipal layanan di Wilayah opt-in

Anda dapat meluncurkan sumber daya di beberapa Wil AWS ayah dan beberapa Wilayah yang harus Anda ikuti. Untuk daftar lengkap Wilayah yang harus Anda ikuti, lihat M engelola AWS Wilayah di Referensi Umum AWS panduan.

Ketika AWS layanan di Wilayah opt-in 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 AWS layanan di Wilayah opt-in 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 opt-in. ap-east-1 Anda ingin mengonfigurasi notifikasi bucket S3 untuk menerbitkan 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-regional dari prinsip layanan S3,s3.amazonaws.com, dalam kebijakan akses topik, sns:Publish permintaan dari bucket ke topik akan gagal. Contoh berikut menentukan prinsip layanan S3 non-regional dalam elemen Principal kebijakan kebijakan kebijakan akses topik SNS.

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

Karena bucket terletak di Wilayah opt-in 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 saat layanan di Wil AWS ayah 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 prinsip layanan S3 regional dalam elemen Principal kebijakan kebijakan kebijakan akses topik SNS.

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

Kebijakan sumber daya atau daftar izin berbasis prinsipal layanan untuk permintaan Lintas wilayah dari Wilayah pilihan 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. Resource-based kebijakanizin 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 diperlukan izin lain. Untuk kepala sekolah di akun lain, mereka juga harus memiliki izin berbasis identitas di akun mereka yang memungkinkan mereka mengakses sumber daya Anda. Ini disebut akses https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html lintas akun.

Untuk pengguna anonim, elemen-elemen berikut 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 alih-alih secara eksplisit AWS Elemen kebijakan JSON: NotPrincipal 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: