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](access_policies_identity-vs-resource.md). 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?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). **catatan** Setelah membuat peran, Anda dapat mengubah akun menjadi “\$1” agar semua orang dapat mengambil peran tersebut. Jika Anda melakukannya, kami sangat menyarankan Anda untuk membatasi siapa yang dapat mengakses peran tersebut melalui cara lain, seperti elemen `Condition` yang membatasi akses ke alamat IP tertentu saja. Jangan biarkan peran Anda dapat diakses semua orang\$1 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. **Topics** + [ ## Cara menentukan kepala sekolah ](#Principal_specifying) + [ ## Akun AWS kepala sekolah ](#principal-accounts) + [ ## Kepala peran IAM ](#principal-roles) + [ ## Kepala sesi peran ](#principal-role-session) + [ ## Kepala sekolah federasi OIDC ](#principal-federated-web-identity) + [ ## Kepala sekolah federasi SALL ](#principal-saml) + [ ## Prinsip pengguna IAM ](#principal-users) + [ ## Kepala Pusat Identitas IAM ](#principal-identity-users) + [ ## AWS STS prinsip pengguna federasi ](#sts-session-principals) + [ ## AWS prinsip layanan ](#principal-services) + [ ## AWS prinsip layanan di Wilayah keikutsertaan ](#principal-services-in-opt-in-regions) + [ ## Semua kepala sekolah ](#principal-anonymous) + [ ## Informasi selengkapnya ](#Principal_more-info) ## 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: + Akun AWS dan pengguna root + Peran IAM + Sesi peran + Pengguna IAM: + Prinsipal pengguna federasi + AWS layanan + Semua kepala sekolah 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. Bila Anda menentukan lebih dari satu prinsipal dalam elemen, Anda memberikan izin untuk setiap prinsipal. Ini logis `OR` dan bukan logis`AND`, 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" ] } ``` **catatan** Anda tidak dapat menggunakan wildcard untuk mencocokkan sebagian nama pengguna utama atau ARN. ## 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: ::root*account-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. **catatan** Saat Anda menyimpan kebijakan berbasis sumber daya yang menyertakan ID akun yang dipersingkat, layanan dapat mengubahnya menjadi ARN utama. Ini tidak mengubah fungsionalitas kebijakan. Beberapa AWS layanan mendukung opsi tambahan untuk menentukan pokok akun. Misalnya, Amazon S3 memungkinkan Anda menentukan [ID pengguna canonik](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingCanonicalId) 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 prinsip 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](reference_policies_evaluation-logic.md) Untuk menentukan peran ARN dalam `Principal` elemen, gunakan format berikut: ``` "Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" } ``` **penting** Jika `Principal` elemen Anda dalam kebijakan kepercayaan peran berisi ARN yang menunjuk ke peran IAM tertentu, ARN tersebut akan berubah menjadi ID utama unik peran tersebut saat Anda menyimpan kebijakan tersebut. Hal ini membantu memitigasi risiko seseorang meningkatkan hak istimewa mereka dengan menghapus dan membuat ulang peran. Anda biasanya tidak melihat ID ini di konsol, karena IAM menggunakan transformasi terbalik kembali ke peran ARN saat kebijakan kepercayaan ditampilkan. Namun, jika Anda menghapus peran, maka Anda memutuskan hubungan. Kebijakan tidak lagi berlaku, bahkan jika Anda membuat ulang peran tersebut karena peran baru memiliki ID utama baru yang tidak cocok dengan ID yang disimpan dalam kebijakan kepercayaan. Ketika ini terjadi, ID utama muncul dalam kebijakan berbasis sumber daya karena tidak AWS dapat lagi memetakannya kembali ke ARN yang valid. Hasil akhirnya adalah jika Anda menghapus dan membuat ulang peran yang direferensikan dalam `Principal` elemen kebijakan kepercayaan, Anda harus mengedit peran dalam kebijakan untuk mengganti ID utama dengan ARN yang benar. ARN sekali lagi berubah menjadi ID utama peran saat Anda menyimpan kebijakan. Untuk informasi selengkapnya, lihat [Memahami AWS Penanganan peran IAM yang Dihapus di Kebijakan](https://repost.aws/articles/ARSqFcxvd7R9u-gcFD9nmA5g/understanding-aws-s-handling-of-deleted-iam-roles-in-policies). Atau, Anda dapat menentukan prinsipal peran sebagai prinsipal dalam kebijakan berbasis sumber daya atau [membuat kebijakan izin luas yang menggunakan](#principal-anonymous) 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 (\$1) 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. **penting** AWS merekomendasikan penggunaan [prinsip peran IAM dalam kebijakan Anda alih-alih prinsip](#principal-roles) sesi peran sedapat mungkin. Gunakan `Condition` pernyataan dan kunci kondisi untuk cakupan akses bawah lebih lanjut bila diperlukan. 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 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](#principal-roles). ## 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](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 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html#manage-oidc-provider-prerequisites) Untuk informasi selengkapnya, lihat [Skenario umum](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_federation_common_scenarios.html) dan [Meminta kredensional melalui](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerolewithwebidentity) 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](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) 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 dengan`AssumeRoleWithWebIdentity`, `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. Konsol Manajemen AWS Untuk informasi lebih lanjut tentang prinsipal mana yang dapat mengambil peran menggunakan operasi ini, lihat. [Bandingkan AWS STS kredensialnya](id_credentials_sts-comparison.md) 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" } ``` ## Prinsip pengguna IAM Anda dapat menentukan pengguna IAM dalam `Principal` elemen kebijakan berbasis sumber daya atau dalam kunci kondisi yang mendukung prinsipal. **catatan** Dalam sebuah `Principal` elemen, bagian nama pengguna dari [*Amazon Resource Name* (ARN) peka huruf besar/kecil](reference_identifiers.md#identifiers-arns). ``` "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. **penting** Jika `Principal` elemen Anda dalam kebijakan kepercayaan peran berisi ARN yang mengarah ke pengguna IAM tertentu, maka IAM mengubah ARN menjadi ID utama unik pengguna saat Anda menyimpan kebijakan. Hal ini membantu memitigasi risiko seseorang meningkatkan hak istimewa mereka dengan menghapus dan membuat ulang pengguna. Anda biasanya tidak melihat ID ini di konsol, karena juga ada transformasi balik kembali ke ARN pengguna ketika kebijakan kepercayaan ditampilkan. Namun, jika Anda menghapus pengguna, maka Anda memutuskan hubungan. Kebijakan tidak lagi berlaku, bahkan saat Anda membuat ulang pengguna. Itu karena pengguna baru memiliki ID utama baru yang tidak cocok dengan ID yang disimpan dalam kebijakan kepercayaan. Ketika ini terjadi, ID utama muncul dalam kebijakan berbasis sumber daya karena tidak AWS dapat lagi memetakannya kembali ke ARN yang valid. Hasilnya adalah jika Anda menghapus dan membuat ulang pengguna yang direferensikan dalam `Principal` elemen kebijakan kepercayaan, Anda harus mengedit peran untuk mengganti ID utama yang sekarang salah dengan ARN yang benar. IAM sekali lagi mengubah ARN menjadi ID utama pengguna yang baru saat Anda menyimpan kebijakan. ## 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](https://docs.aws.amazon.com/singlesignon/latest/userguide/referencingpermissionsets.html) 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. **penting** AWS merekomendasikan agar Anda membatasi penggunaan sesi pengguna AWS STS federasi. Sebagai gantinya, gunakan [peran IAM](IAM/latest/UserGuide/tutorial_cross-account-with-roles.html). 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](id_credentials_sts-comparison.md) + Pengguna **federasi IAM — Pengguna** IAM bergabung menggunakan `GetFederationToken` operasi yang menghasilkan sesi pengguna federasi untuk pengguna IAM tersebut. + **Pengguna root federasi** — Pengguna root federasi menggunakan `GetFederationToken` operasi yang menghasilkan sesi pengguna federasi untuk pengguna root tersebut. Ketika pengguna IAM atau pengguna root meminta kredensyal sementara dari AWS STS menggunakan operasi ini, mereka memulai sesi pengguna gabungan 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 prinsip 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](id_roles.md#iam-term-service-role)*. 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": "*"`. **penting** Pengidentifikasi untuk prinsipal layanan mencakup nama layanan, dan biasanya dalam format berikut: `service-name.amazonaws.com` Prinsipal layanan ditentukan oleh layanan. Anda dapat menemukan prinsipal layanan untuk beberapa layanan dengan membuka [AWS layanan yang bekerja dengan IAM](reference_aws-services-that-work-with-iam.md), 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](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) di *Referensi Umum AWS*panduan. 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 S3`s3.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. **catatan** Untuk kebijakan kepercayaan peran IAM, sebaiknya gunakan nama utama layanan non-regional. Sumber daya IAM bersifat global dan oleh karena itu peran yang sama dapat digunakan di Wilayah mana pun. ## Semua kepala sekolah Anda dapat menggunakan wildcard (\$1) untuk menentukan semua prinsipal dalam `Principal` elemen kebijakan berbasis sumber daya atau dalam kunci kondisi yang mendukung prinsipal. [Kebijakan berbasis sumber daya](access_policies.md#policies_resource-based)izin *pemberian* dan [kunci kondisi](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) digunakan untuk membatasi kondisi pernyataan kebijakan. **penting** Kami sangat menyarankan agar Anda tidak menggunakan wildcard (\$1) dalam `Principal` elemen kebijakan berbasis sumber daya dengan `Allow` efek kecuali Anda berniat untuk memberikan akses publik atau anonim. Jika tidak, tentukan prinsip, layanan, atau AWS akun yang dimaksudkan dalam `Principal` elemen dan kemudian batasi akses lebih lanjut dalam elemen. `Condition` Hal ini terutama berlaku untuk kebijakan kepercayaan peran IAM, karena mereka memungkinkan prinsipal lain untuk menjadi prinsipal di akun Anda. Untuk kebijakan berbasis sumber daya, menggunakan wildcard (\$1) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html). 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 alih-alih [AWS Elemen kebijakan JSON: NotPrincipal](reference_policies_elements_notprincipal.md) untuk secara eksplisit menolak semua prinsip kecuali yang ditentukan dalam elemen.* `Condition` Kebijakan ini harus [ditambahkan ke bucket Amazon S3](https://docs.aws.amazon.com//AmazonS3/latest/userguide/add-bucket-policy.html). ------ #### [ 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: + [Contoh kebijakan bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html) di *Panduan Pengguna Layanan Penyimpanan Sederhana Amazon* + [Contoh kebijakan untuk Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#ExamplePolicies_SNS) di Panduan Pengembang *Layanan Pemberitahuan Sederhana Amazon* + [Contoh kebijakan Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/SQSExamples.html) di Panduan Pengembang Layanan *Antrian Sederhana Amazon* + [Kebijakan utama](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) dalam *Panduan AWS Key Management Service Pengembang* + [Pengidentifikasi akun](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html) di *Referensi Umum AWS* + [Federasi OIDC](id_roles_providers_oidc.md)