# AWS JSON ポリシーの要素: Principal
リソースベースの JSON ポリシーの `Principal` 要素を使用して、リソースへのアクセスを許可または拒否するプリンシパルを指定します。
[リソースベースポリシー](access_policies_identity-vs-resource.md) の `Principal` 要素を使用する必要があります。IAM など、いくつかのサービスが、リソースベースのポリシーをサポートしています。IAM リソースベースのポリシーのタイプは、ロールの信頼ポリシーです。IAM ロールでは、ロールの信頼ポリシー内の `Principal` 要素を使用して、だれがこのロールを引き受けることができるかを指定します。クロスアカウントアクセスとして、信頼されたアカウントの 12 桁の ID を指定する必要があります｡ 信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「[IAM Access Analyzer とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)」を参照してください。
**注記**
ロールを作成した後、アカウントを「\$1」に変更すると、誰もがそのロールを引き受けることができます。これを行う場合は、アクセスを特定の IP アドレスのみに制限する `Condition` 要素など、他の方法でロールへのアクセスを制限することを強くお勧めします。誰でもロールにアクセスできる状態のままにしないでください。
サポートベースのポリシーをサポートする他のサービスの例としては、Amazon S3 バケットや AWS KMS key が挙げられます。
`Principal` エレメントを ID ベースのポリシーで使用することはできません。ID ベースのポリシーは、IAM の ID (ユーザー、グループ、ロール) にアタッチするアクセス許可ポリシーです。これらの場合、プリンシパルは、ポリシーがアタッチされた ID によって暗示されます。
**Topics**
+ [プリンシパルを指定する方法](#Principal_specifying)
+ [AWS アカウント プリンシパル](#principal-accounts)
+ [IAM ロールプリンシパル](#principal-roles)
+ [ロールセッションプリンシパル](#principal-role-session)
+ [OIDC フェデレーテッドプリンシパル](#principal-federated-web-identity)
+ [SAML フェデレーテッドプリンシパル](#principal-saml)
+ [IAM ユーザープリンシパル](#principal-users)
+ [IAM Identity Center のプリンシパル](#principal-identity-users)
+ [AWS STS フェデレーションユーザープリンシパル](#sts-session-principals)
+ [AWS サービスプリンシパル](#principal-services)
+ [オプトインリージョンの AWS サービスプリンシパル](#principal-services-in-opt-in-regions)
+ [すべてのプリンシパル](#principal-anonymous)
+ [詳細情報](#Principal_more-info)
## プリンシパルを指定する方法
リソースベースのポリシーにある `Principal` 要素か、プリンシパルをサポートする条件キーでプリンシパルを指定します。
ポリシーでは、次のいずれかのプリンシパルを指定できます。
+ AWS アカウント およびルートユーザー
+ IAM ロール
+ ロールセッション
+ IAM ユーザー
+ フェデレーションユーザープリンシパル
+ AWS のサービス
+ すべてのプリンシパル
ユーザーグループをポリシー (リソースベースのポリシーなど) のプリンシパルとして識別することはできません。これは、グループは 認証ではなくアクセス権限に関連しており、プリンシパルは認証済みの IAM エンティティであるためです。
配列を使用して、以降のセクションの各プリンシパル型に対して複数のプリンシパルを指定できます。配列では 1 つまたは複数の値を使用できます。要素で複数のプリンシパルを指定する場合は、各プリンシパルにアクセス許可を付与します。これは論理 `OR` であり論理 `AND` ではありません。一度に 1 つのプリンシパルを認証するためです。複数の値を含める場合は、角括弧 (`[` と `]`) を使用し、配列の各エントリをカンマで区切ります。次のポリシーの例では、123456789012 アカウントまたは 555555555555 アカウントのアクセス許可を定義します。
```
"Principal" : {
"AWS": [
"123456789012",
"555555555555"
]
}
```
**注記**
ワイルドカードとして使用して、プリンシパルの名前または ARN の一部に一致させることはできません。
## AWS アカウント プリンシパル
リソースベースのポリシーにある `Principal` 要素か、プリンシパルをサポートする条件キーで、AWS アカウント の識別子を指定できます。これにより、権限がアカウントに委譲されます。別のアカウントへのアクセスを許可する場合、そのアカウントの管理者が、そのアカウントの ID (IAM ユーザーまたはロール) へのアクセス許可を付与する必要があります。AWS アカウント を指定するときは、アカウント ARN (aarn:aws:iam::*account-ID*:root、または `"AWS":` プレフィックスの後に ID を付けた短縮形を使用できます。
例えば、割り当てられた アカウント ID (`123456789012`) から、次のいずれかのメソッドを使用して、`Principal` 要素でそのアカウントを指定できます。
```
"Principal": { "AWS": "arn:aws:iam::123456789012:root" }
```
```
"Principal": { "AWS": "123456789012" }
```
アカウント ARN と短縮アカウント ID は、同じように動作します。どちらも、アカウントにアクセス許可を委譲します。`Principal` 要素で アカウント ARN を使用しても、アカウントのルートユーザーだけはアクセス許可を制限しません。
**注記**
短縮アカウント ID を含むリソースベースのポリシーを保存すると、それをサービスがプリンシパル ARN に変換することがあります。これはポリシーの機能は変更しません。
一部の AWS サービスでは、アカウントプリンシパルを指定するための追加オプションがサポートされています。例えば、Amazon S3 では、次の形式を使用して[正規ユーザー ID](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingCanonicalId) を指定できます。
```
"Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" }
```
配列を使用すると、プリンシパルとして AWS アカウント (または正規ユーザー ID) を 1 つ以上指定できます。例えば、3 つのメソッドすべてを使用して、バケットポリシーでプリンシパルを指定できます。
```
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:root",
"999999999999"
],
"CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be"
}
```
## IAM ロールプリンシパル
リソースベースのポリシーにある `Principal` 要素か、プリンシパルをサポートする条件キーで、IAM ロールプリンシパル ARNを指定できます。IAM ロールは ID です。IAM では、ID はアクセス許可を割り当てることができるリソースです。ロールは、別の認証済みの ID を信頼して、そのロールを引き受けます。これには、AWS のプリンシパルか、外部 ID プロバイダー (IdP) からのユーザーが含まれます。プリンシパルまたは ID がロールを引き受けると、引き受けたロールのアクセス許可を持った、一時的なセキュリティ認証情報を受け取ります。AWS でこれらのセッション認証情報を使用して操作を実行すると、これらは*ロールセッションプリンシパル*になります。
リソースベースのポリシーでロールプリンシパルを指定すると、ロールのアクセス許可を制限するポリシータイプによって、プリンシパルの有効なアクセス許可が制限されます。これには、セッションポリシーとアクセス許可の境界が含まれます。ロールセッションの有効なアクセス許可の評価方法については、「[ポリシーの評価論理](reference_policies_evaluation-logic.md)」を参照してください。
`Principal` 要素でロール ARN を指定する場合は、次の形式を使用します。
```
"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" }
```
**重要**
ロール信頼ポリシーの `Principal` 要素に、特定の IAM ロールを指し示す ARN が含まれている場合、その ARN はポリシーを保存するときにロールの一意のプリンシパル ID に変換されます。これにより、ロールを削除して再作成することにより、誰かがそのユーザーの特権をエスカレートするリスクを緩和できます。通常、この ID はコンソールには表示されません。これは、信頼ポリシーが表示されるときに、IAM が ロール ARN への逆変換を行うためです。ただし、ロールを削除すると、関係が壊れます。ロールを再作成した場合でも、ポリシーは適用されません。これは、新しいロールは信頼ポリシーに保存されている ID と一致しない新しいプリンシパル ID を持っているためです。この場合、プリンシパル ID はリソースベースポリシーに表示されます。これは AWS が有効な ARN に戻って ID をマッピングできなくなるためです。その結果、信頼ポリシーの `Principal` 要素で参照されているロールを削除して再作成する場合は、ポリシーのロールを編集してプリンシパル ID を正しい ARN に置き換える必要があります。ポリシーを保存するときに、ARN は再びロールの新しいプリンシパル ID に変換されます。詳細については、[「Understanding AWS's Handling of Deleted IAM roles in Policies」](https://repost.aws/articles/ARSqFcxvd7R9u-gcFD9nmA5g/understanding-aws-s-handling-of-deleted-iam-roles-in-policies)を参照してください。
または、ロールプリンシパルをリソースベースのポリシーのプリンシパルとして指定するか、[幅広くアクセスを許可するポリシーを作成](#principal-anonymous)して `aws:PrincipalArn` 条件キーを使用します。このキーを使用すると、ロールセッションプリンシパルには、セッションの結果として得られる ARN ではなく、引き受けたロールの ARN に基づくアクセス許可が付与されます。なぜなら、AWS は条件キー ARN を ID に変換せず、ロールを削除してから同じ名前で新しくロールを作成すると、ロール ARN に付与されたアクセス許可は保持されるからです。アクセス許可の境界やセッションポリシーなどの ID ベースのポリシータイプは、アイデンティティベースのポリシーに明示的な拒否が含まれていない限り、`Principal` 要素で、ワイルドカード (\$1) を含む `aws:PrincipalArn` 条件キーを使用して付与されたアクセス許可を制限することはありません。
## ロールセッションプリンシパル
リソースベースのポリシーにある `Principal` 要素か、プリンシパルをサポートする条件キーで、ロールセッションを指定できます。プリンシパルまたは ID がロールを引き受けると、引き受けたロールのアクセス許可を持った、一時的なセキュリティ認証情報を受け取ります。AWS でこれらのセッション認証情報を使用して操作を実行すると、これらは*ロールセッションプリンシパル*になります。
ロールセッションプリンシパルに使用する形式は、ロールの引き受けに使用する AWS STS のオペレーションによります。
**重要**
AWS では、可能な限りロールセッションプリンシパルの代わりに[ IAM ロールプリンシパル](#principal-roles)をポリシーで使用することをお勧めします。`Condition` ステートメントと条件キーを使用して、必要に応じてアクセス範囲をさらに絞り込みます。
`Principal` 要素のロールセッションプリンシパル ARN を指定する場合は、次の形式を使用します。
```
"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }
```
さらに管理者は、ロールセッションの発行方法を制御するプロセスを設計できます。例えば、ユーザーがワンクリックするだけで、予測可能なセッション名を作成するソリューションを提供できます。これを管理者が行う場合、ポリシーまたは条件キーで、ロールセッションプリンシパルを使用できます。それ以外の場合は、ロール ARN を `aws:PrincipalArn` 条件キーのプリンシパルとして指定することができます。ロールをどのようにプリンシパルとして指定するかによって、セッション完了後の有効なアクセス許可が変わります。詳細については、「[IAM ロールプリンシパル](#principal-roles)」を参照してください。
## OIDC フェデレーテッドプリンシパル
OIDC フェデレーテッドプリンシパルは、OpenID プロバイダー (OP) とも呼ばれる OIDC 準拠 IDP から JSON ウェブトークン (JWT) を使用して AWS STS `AssumeRoleWithWebIdentity` API を呼び出し、一時的な AWS 認証情報をリクエストするときに使用されるプリンシパルです。OIDC フェデレーテッドプリンシパルは、AWS アカウントの OIDC IDP、または 4 つの組み込み ID プロバイダー (Login with Amazon、Google、Facebook、[Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html)) を表すことができます。
OIDC IDP から JWT が発行されたユーザー、ワークロード、またはシステムは、JWT を使用して `AssumeRoleWithWebIdentity` を呼び出し、JWT を発行した OIDC IDP を信頼するように設定された IAM ロールの一時的な AWS セキュリティ認証情報をリクエストできます。JWT は、ID トークン、アクセストークン、またはその他の方法で配信される JWT トークン ([AWS STS による要件](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html#manage-oidc-provider-prerequisites)を満たしている場合) です。詳細については、「[一般的なシナリオ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_federation_common_scenarios.html)」と「[OIDC プロバイダーを通じた認証情報のリクエスト](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerolewithwebidentity)」を参照してください。
このプリンシパルタイプをロール信頼ポリシーで使用し、AWS アカウントに存在する OIDC IDP、または 4 つの組み込み IDP のいずれかを使用して `AssumeRoleWIthWebIdentity` を呼び出すアクセス許可を許可または拒否します。ロール信頼ポリシーの `Principal` 要素で OIDC フェデレーテッドプリンシパル ARN を指定するには、組み込みの OIDC IDP に対して次の 4 つの形式のいずれかを使用します。
```
"Principal": { "Federated": "cognito-identity.amazonaws.com" }
```
```
"Principal": { "Federated": "www.amazon.com" }
```
```
"Principal": { "Federated": "graph.facebook.com" }
```
```
"Principal": { "Federated": "accounts.google.com" }
```
アカウントに追加する OIDC プロバイダー (GitHub など) を使用する場合は、ロールの信頼ポリシーでプロバイダーの ARN を指定します。この設定により、カスタム ID プロバイダーを介して認証されたユーザーのアクセスを制御する IAM ポリシーを作成できます。
```
"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/full-OIDC-identity-provider-URL" }
```
例えば、GitHub が信頼されたウェブ ID プロバイダーである場合、ロール信頼ポリシーの `Principal` 要素の OIDC ロールセッション ARN は次の形式を使用します。
```
"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/tokens.actions.githubusercontent.com" }
```
詳細については、「[Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)」を参照してください。
OIDC フェデレーテッドプリンシパルは、ロール信頼ポリシー以外のポリシータイプではサポートされていません。
## SAML フェデレーテッドプリンシパル
*SAML フェデレーテッドプリンシパル*は、SAML アサーションを使用して AWS STS `AssumeRoleWithSAML` API を呼び出して一時的な AWS 認証情報をリクエストするときに使用されるプリンシパルです。SAML ID プロバイダー (IDP) を使用してサインインし、この操作を使用して IAM ロールを引き受けることができます。`AssumeRoleWithWebIdentity` と同様に、 `AssumeRoleWithSAML` は認証に AWS 認証情報を必要としません。代わりに、ユーザーはまず SAML ID プロバイダーで認証し、次に SAML アサーションを使用して `AssumeRoleWithSAML` API コールを行うか、AWS マネジメントコンソールにサインインする AWS サインイン/SAML ページにリダイレクトされます。このオペレーションを使用してロールを引き受けることができるプリンシパルについては、「[AWS STS 認証情報を比較する](id_credentials_sts-comparison.md)」を参照してください。
このプリンシパルタイプをロール信頼ポリシーで使用して、信頼済みの SAML ID プロバイダーに基づき、アクセス許可を許可または拒否します。ロール信頼ポリシーの `Principal` 要素で SAML ID ロールセッション ARN を指定する場合は、次の形式を使用します。
```
"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" }
```
## IAM ユーザープリンシパル
リソースベースのポリシーの `Principal` 要素、またはプリンシパルをサポートする条件キーで、IAM ユーザーを指定できます。
**注記**
`Principal` 要素にある [*Amazon リソースネーム*(ARN)](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"
]
}
```
`Principal` 要素内でユーザーを指定する際に、"すべてのユーザー" の意味でワイルドカード (`*`) を使用することはできません。プリンシパルには、常に複数の特定ユーザーを指定する必要があります。
**重要**
ロールの信頼ポリシーの `Principal` 要素に、特定の IAM ユーザーを指し示す ARN が含まれている場合、その ARN をポリシーに保存するときに、IAM がユーザーの一意のプリンシパル ID に変換されます。これにより、ユーザーを削除して再作成することにより、誰かがそのユーザーの特権をエスカレートするリスクを緩和できます。通常、この ID はコンソールには表示されません。これは、信頼ポリシーが表示されるときに、ユーザーの ARN への逆変換が行われるためです。ただし、ユーザーを削除すると、関係が壊れます。ユーザーを再作成しても、ポリシーが適用されることはありません。これは、新しいユーザーには、信頼ポリシーに保存されている ID と一致しない新しいプリンシパル ID が付与されるためです。この場合、プリンシパル ID はリソースベースポリシーに表示されます。これは AWS が有効な ARN に戻って ID をマッピングできなくなるためです。その結果、信頼ポリシーの `Principal` 要素で参照されているユーザーを削除して再作成する場合は、ロールを編集して、正しくなくなったプリンシパル ID を正しい ARN に置き換える必要があります。ポリシーを保存するときに、IAM が再び、ARN をユーザーの新しいプリンシパル ID に変換します。
## IAM Identity Center のプリンシパル
IAM Identity Center では、リソースベースのポリシーのプリンシパルが AWS アカウント プリンシパルとして定義されている必要があります。アクセスを指定するには、条件ブロック内のアクセス許可セットのロール ARN を参照してください。詳細については、*「IAM Identity Center ユーザーガイド*」の「[リソースポリシー、Amazon EKS、および AWS KMS のアクセス許可セットの参照](https://docs.aws.amazon.com/singlesignon/latest/userguide/referencingpermissionsets.html)」を参照してください。
## AWS STS フェデレーションユーザープリンシパル
リソースベースのポリシーにある `Principal` 要素か、プリンシパルをサポートする条件キーで、*フェデレーションユーザーセッション*を指定できます。
**重要**
AWS では、AWS STS フェデレーションユーザーセッションの使用を制限することをお勧めします。代わりに、[IAM ロール](IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)を使用します。
AWS STS フェデレーションユーザープリンシパルは、長期的な IAM 認証情報を使用して呼び出される `GetFederationToken` オペレーションによって作成されます。フェデレーションユーザーのアクセス許可は、`GetFederationToken` を呼び出したプリンシパルとパラメータとして `GetFederationToken` API に渡されるセッションポリシーの交差です。
AWS では、IAM ユーザーまたは AWS アカウントのルートユーザー は、長期的なアクセスキーを使用して認証を行うことができます。このオペレーションで、どのプリンシパルがフェデレーションを行えるかについては、「[AWS STS 認証情報を比較する](id_credentials_sts-comparison.md)」を参照してください。
+ **IAM フェデレーションユーザー** – `GetFederationToken` オペレーションを使用して IAM ユーザーがフェデレーションを行った結果、IAM ユーザーのフェデレーションユーザーのセッションができます。
+ **フェデレーションルートユーザー** – `GetFederationToken` オペレーションを使用してルートユーザーがフェデレーションを行った結果、IAM ユーザーのフェデレーションユーザーのセッションができます。
この操作を使用して、IAM ユーザーまたはルートユーザーが AWS STS から一時的な認証情報をリクエストした場合、一時的なフェデレーションユーザーセッションを開始します。このセッションの ARN は、フェデレーション元の ID に基づいています。
`Principal` 要素でフェデレーションユーザーセッション ARN を指定する場合は、次の形式を使用します。
```
"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:federated-user/user-name" }
```
## AWS サービスプリンシパル
リソースベースのポリシーにある `Principal` 要素か、プリンシパルをサポートする条件キーで、AWS サービスを指定できます。*サービスプリンシパル*は、サービスの識別子です。
AWS のサービスが引き受けることのできる IAM ロールは、*[サービスロール](id_roles.md#iam-term-service-role)*と呼ばれます。サービスロールには信頼ポリシーを含める必要があります。*信頼ポリシー* は、どのプリンシパルがそのロールを果たすことができるかを定義するロールにアタッチされるリソースベースのポリシーです。一部のサービスロールには事前定義済みの信頼ポリシーがあります。ただし、状況によっては、信頼ポリシーでプリンシパルサービスを指定する必要があります。IAM ポリシーのサービスプリンシパルを `"Service": "*"` にすることはできません。
**重要**
サービスプリンシパルの識別子にはサービス名が含まれ、通常は次の形式になります。
`service-name.amazonaws.com`
サービスプリンシパルはサービスによって定義されます。一部のサービスのサービスプリンシパルを検索するには [IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md) を開き、サービスの **[Service-linked role]** (サービスにリンクされたロール) 列が **[Yes]** (はい) になっているかどうかを確認し、**[Yes]** (はい) リンクを開いてそのサービスのサービスにリンクされたロールのドキュメントを表示します。**サービスプリンシパル**を表示するには、そのサービスの [Service-Linked Role Permissions] (サービスにリンクされたロールのアクセス許可) のセクションを探します。
次の例では、サービスロールにアタッチできるポリシーを示します。ポリシーは、Amazon ECS および Elastic Load Balancing の 2 つのサービスを有効にして、ロールを引き受けます。これらのサービスは、ロールに割り当てられた権限ポリシー (表示されていない) によって付与されたタスクを実行できます。複数のサービスプリンシパルを指定する場合に、2 つの `Service` 要素は指定できません。1 つのみ指定できます。代わりに、1 つの `Service` 要素の値として複数のサービスのプリンシパルのアレイを使用します。
```
"Principal": {
"Service": [
"ecs.amazonaws.com",
"elasticloadbalancing.amazonaws.com"
]
}
```
## オプトインリージョンの AWS サービスプリンシパル
リソースは複数の AWS リージョンで起動できますが、一部のリージョンはオプトインする必要があります。オプトインする必要があるリージョンの一覧については、「*AWS 全般のリファレンス* ガイド」の「[AWS リージョンの管理](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html)」を参照してください。
オプトインリージョンの AWS サービスが同じリージョン内でリクエストを行うと、サービスプリンシパル名の形式は、サービスプリンシパル名がリージョン化されないバージョンとして識別されます。
`service-name.amazonaws.com`
オプトインリージョンの AWS サービスが別のリージョンにクロスリージョンリクエストを行うと、サービスプリンシパル名の形式は、サービスプリンシパル名のリージョン化バージョンとして識別されます。
`service-name.{region}.amazonaws.com`
例えば、Amazon SNS トピックが `ap-southeast-1` リージョンにあり、Amazon S3 バケットがオプトインリージョン `ap-east-1` にあるとします。メッセージを SNS トピックに公開するように、S3 バケット通知を設定する必要があります。S3 サービスが SNS トピックにメッセージを投稿できるようにするには、トピックのリソースベースのアクセスポリシーを使用して S3 サービスのプリンシパル `sns:Publish` 権限を付与する必要があります。
トピックアクセスポリシーで S3 サービスプリンシパルのリージョン化されないバージョンである `s3.amazonaws.com` を指定すると、バケットからトピックへの `sns:Publish` リクエストは失敗します。次の例では、SNS トピックアクセスポリシーの `Principal` ポリシー要素に、リージョン化されない S3 サービスプリンシパルを指定しています。
```
"Principal": { "Service": "s3.amazonaws.com" }
```
バケットはオプトインリージョンにあり、リクエストは同じリージョン外で行われるため、S3 サービスプリンシパルはリージョン化されたサービスプリンシパル名 `s3.ap-east-1.amazonaws.com` として表示されます。オプトインリージョンの AWS サービスが別のリージョンにリクエストを行う場合は、リージョン化されたサービスプリンシパル名を使用する必要があります。リージョン化されたサービスプリンシパル名を指定した後に、バケットが別のリージョンにある SNS トピックに `sns:Publish` リクエストを行うと、リクエストは成功します。次の例では、SNS トピックアクセスポリシーの `Principal` ポリシー要素に、リージョン化された S3 サービスプリンシパルを指定しています。
```
"Principal": { "Service": "s3.ap-east-1.amazonaws.com" }
```
オプトインリージョンから別のリージョンへのクロスリージョンリクエストに対するリソースポリシーまたはサービスプリンシパルベースの許可リストは、リージョン化されたサービスプリンシパル名を指定した場合にのみ成功します。
**注記**
IAM ロールの信頼ポリシーには、リージョン化されないサービスプリンシパル名を使用することをお勧めします。IAM リソースはグローバルであるため、どのリージョンでも同じロールを使用することができます。
## すべてのプリンシパル
ワイルドカード (\$1) を使用して `Principal` リソースベースのポリシーの要素またはプリンシパルをサポートする条件キーにあるすべてのプリンシパルを指定できます。*[リソースベースのポリシー](access_policies.md#policies_resource-based)*許可のアクセス権および[条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)はポリシーステートメントの条件を制限するために使用されます。
**重要**
パブリックまたは匿名アクセスを許可する意図がない限り、`Allow` の影響を伴うリソースベースのポリシーの `Principal` 要素にワイルドカード (\$1) を使用しないことを強くお勧めします。それ以外の場合は、`Principal` 要素で目的のプリンシパル、サービス、または AWS アカウントを指定して、`Condition` 要素でさらにアクセスを制限します。これは、他のプリンシパルがアカウントのプリンシパルになることを許可することから、特にIAM ロールの信頼ポリシーに当てはまります。
リソースベースポリシーでは、`Allow` 効果でワイルドカード (\$1) を使用することで、匿名ユーザー (パブリックアクセス) を含むすべてのユーザーへのアクセスが許可されます。アカウント内の IAM ユーザーおよびロールプリンシパルの場合、他のアクセス権は必要ありません。他のアカウントのプリンシパルの場合、アカウント内にリソースへのアクセスを許可する ID ベースのアクセス許可がある必要があります。これは[クロスアカウントアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)と呼ばれます。
匿名ユーザーの場合、次の要素は同等です。
```
"Principal": "*"
```
```
"Principal" : { "AWS" : "*" }
```
ワイルドカードとして使用して、プリンシパルの名前または ARN の一部に一致させることはできません。
次の例は、`Condition` 要素で指定されたものを*除いた*すべてのプリンシパルを明確に拒否する [AWS JSON ポリシーの要素: NotPrincipal](reference_policies_elements_notprincipal.md) の代わりに使用できるリソースベースのポリシーを示しています。このポリシーは [ 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"
}
}
}
]
}
```
------
## 詳細情報
詳細については次を参照してください:
+ 「*Amazon Simple Storage Service ユーザーガイド*」にある[バケットポリシーの例](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html)
+ [Amazon Simple Notification Service 開発者ガイド](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#ExamplePolicies_SNS)の「*Amazon SNS のポリシーの例*」
+ 「*Amazon Simple Queue Service 開発者ガイド*」にある [Amazon SQS ポリシーの例](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/SQSExamples.html)
+ 「*AWS Key Management Service 開発者ガイド*」にある[主要ポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)
+ 「*AWS 全般のリファレンス*」 の「[アカウント ID](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html)」
+ [OIDC フェデレーション](id_roles_providers_oidc.md)