プリンシパルを指定する方法 AWS アカウントプリンシパル IAM ロールプリンシパルロールセッションプリンシパル IAM ユーザープリンシパル Identity Center のプリンシパルフェデレーティッドユーザーセッションプリンシパル AWS サービスプリンシパルオプトインリージョンの AWS サービスプリンシパルすべてのプリンシパル詳細情報

AWS JSON ポリシーの要素: Principal

リソースベースの JSON ポリシーの Principal 要素を使用して、リソースへのアクセスを許可または拒否するプリンシパルを指定します。

リソースベースポリシーの Principal 要素を使用する必要があります。IAM など、いくつかのサービスが、リソースベースのポリシーをサポートしています。IAM リソースベースのポリシーのタイプは、ロールの信頼ポリシーです。IAM ロールでは、ロールの信頼ポリシー内の Principal 要素を使用して、だれがこのロールを引き受けることができるかを指定します。クロスアカウントアクセスとして、信頼されたアカウントの 12 桁の ID を指定する必要があります｡信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「IAM Access Analyzer とは」を参照してください。

注記

ロールを作成した後、アカウントを「*」に変更すると、誰もがそのロールを引き受けることができます。これを行う場合は、アクセスを特定の IP アドレスのみに制限する Condition 要素など、他の方法でロールへのアクセスを制限することを強くお勧めします。誰でもロールにアクセスできる状態のままにしないでください。

サポートベースのポリシーをサポートする他のサービスの例としては、Amazon S3 や AWS KMS key が挙げられます。

Principal エレメントを ID ベースのポリシーで使用することはできません。ID ベースのポリシーは、IAM の ID (ユーザー、グループ、ロール) にアタッチするアクセス許可ポリシーです。これらの場合、プリンシパルは、ポリシーがアタッチされた ID によって暗示されます。

プリンシパルを指定する方法

リソースベースのポリシーにある 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 を指定できます。


"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 でこれらのセッション認証情報を使用して操作を実行すると、これらはロールセッションプリンシパルになります。

IAM ロールは、IAM に存在する ID です。ロールは、AWS のプリンシパルなどの認証済みの ID か、外部 ID プロバイダーからのユーザーを信頼します。プリンシパルまたは ID がロールを引き受けると、一時的なセキュリティ認証情報を受け取ります。その後、これらの認証情報をロールセッションプリンシパルとして使用して、AWS で操作を実行できます。

リソースベースのポリシーでロールプリンシパルを指定すると、ロールのアクセス許可を制限するポリシータイプによって、プリンシパルの有効なアクセス許可が制限されます。これには、セッションポリシーとアクセス許可の境界が含まれます。ロールセッションの有効なアクセス許可の評価方法については、「ポリシーの評価論理」を参照してください。

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 に変換されます。

または、ロールプリンシパルをリソースベースのポリシーのプリンシパルとして指定するか、幅広くアクセスを許可するポリシーを作成して aws:PrincipalArn 条件キーを使用します。このキーを使用すると、ロールセッションプリンシパルには、セッションの結果として得られる ARN ではなく、引き受けたロールの ARN に基づくアクセス許可が付与されます。なぜなら、AWS は条件キー ARN を ID に変換せず、ロールを削除してから同じ名前で新しくロールを作成すると、ロール ARN に付与されたアクセス許可は保持されるからです。アクセス許可の境界やセッションポリシーなどの ID ベースのポリシータイプは、アイデンティティベースのポリシーに明示的な拒否が含まれていない限り、Principal 要素で、ワイルドカード (*) を含む aws:PrincipalArn 条件キーを使用して付与されたアクセス許可を制限することはありません。

ロールセッションプリンシパル

リソースベースのポリシーにある Principal 要素か、プリンシパルをサポートする条件キーで、ロールセッションを指定できます。プリンシパルまたは ID がロールを引き受けると、引き受けたロールのアクセス許可を持った、一時的なセキュリティ認証情報を受け取ります。AWS でこれらのセッション認証情報を使用して操作を実行すると、これらはロールセッションプリンシパルになります。

ロールセッションプリンシパルに使用する形式は、ロールの引き受けに使用する AWS STS のオペレーションによります。

さらに管理者は、ロールセッションの発行方法を制御するプロセスを設計できます。例えば、ユーザーがワンクリックするだけで、予測可能なセッション名を作成するソリューションを提供できます。これを管理者が行う場合、ポリシーまたは条件キーで、ロールセッションプリンシパルを使用できます。それ以外の場合は、ロール ARN を aws:PrincipalArn 条件キーのプリンシパルとして指定することができます。ロールをどのようにプリンシパルとして指定するかによって、セッション完了後の有効なアクセス許可が変わります。詳細については、「IAM ロールプリンシパル」を参照してください。

引き受けたロールのセッションプリンシパル

引き受けたロールのセッションプリンシパルは、AWS STS AssumeRole オペレーションの結果として得られるセッションプリンシパルです。このオペレーションを使用してロールを引き受けることができるプリンシパルについては、「AWS STS 認証情報を比較する」を参照してください。

Principal 要素で引き受けたロールの ARN を指定する場合は、次の形式を使用します。


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

Principal 要素で引き受けたロールセッションを指定する場合、ワイルドカード (*) を使用して「すべてのセッション」を意味することはできません。プリンシパルは常に特定のセッションに名前を付ける必要があります。

OIDC セッションプリンシパル

「OIDC セッションプリンシパル」は、AWS STS AssumeRoleWithWebIdentity オペレーションの結果として得られるセッションプリンシパルです。外部の OIDC プロバイダー (IdP) を使用してサインインし、この操作を使用して IAM ロールを引き受けることができます。これは ID フェデレーションを利用して、ロールセッションを発行します。このオペレーションを使用してロールを引き受けることができるプリンシパルについては、「AWS STS 認証情報を比較する」を参照してください。

OIDC プロバイダーからロールを発行すると、OIDC プロバイダーに関する情報を含む特別なタイプのセッションプリンシパルが取得されます。

このプリンシパルタイプをポリシーで使用して、信頼済みの Web ID プロバイダーに基づき、アクセスを許可または拒否します。ロール信頼ポリシーの Principal 要素で OIDC ロールセッション ARN を指定する場合は、次の形式を使用します。


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


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


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


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

SAML セッションプリンシパル

SAML セッションプリンシパルは、AWS STS AssumeRoleWithSAML オペレーションの結果として得られるセッションプリンシパルです。外部の SAML ID プロバイダー (IdP) を使用してサインインし、この操作を使用して IAM ロールを引き受けることができます。これは ID フェデレーションを利用して、ロールセッションを発行します。このオペレーションを使用してロールを引き受けることができるプリンシパルについては、「AWS STS 認証情報を比較する」を参照してください。

SSAML ID プロバイダーからロールを発行すると、SAML ID プロバイダーの情報が含まれた、特別なタイプのセッションプリンシパルが取得されます。

このプリンシパルタイプをポリシーで使用して、信頼済みの SAML ID プロバイダーに基づき、アクセスを許可または拒否します。ロール信頼ポリシーの Principal 要素で SAML ID ロールセッション ARN を指定する場合は、次の形式を使用します。


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

IAM ユーザープリンシパル

リソースベースのポリシーの Principal 要素、またはプリンシパルをサポートする条件キーで、IAM ユーザーを指定できます。

注記

Principal 要素にある Amazon リソースネーム(ARN)のユーザー名の部分では、大文字と小文字を区別します。


"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 のアクセス許可セットの参照」を参照してください。

AWS STS フェデレーティッドユーザーセッションプリンシパル

リソースベースのポリシーにある Principal 要素か、プリンシパルをサポートする条件キーで、フェデレーティッドユーザーセッションを指定できます。

重要

AWS では、ルートユーザーアクセスが必要などの場合にのみ、AWS STS フェデレーティッドユーザーセッションを使用することをお勧めします。代わりに、ロールを使用してアクセス許可を委任してください。

AWS STS フェデレーティッドユーザーセッションプリンシパルは、AWS STS GetFederationToken オペレーションの結果として得られるセッションプリンシパルです。この場合は、IAM ロールを使用する代わりに一時的なアクセストークンを取得する方法として、AWS STS がID フェデレーションを使用しています。

AWS では、IAM ユーザーまたは AWS アカウントのルートユーザーは、長期的なアクセスキーを使用して認証を行うことができます。このオペレーションで、どのプリンシパルがフェデレーションを行えるかについては、「AWS STS 認証情報を比較する」を参照してください。

IAM フェデレーティッドユーザー — GetFederationToken オペレーションを使用して IAM ユーザーがフェデレーションを行った結果、IAM ユーザーのフェデレーティッドユーザーセッションプリンシパルができます。
フェデレーティッドルートユーザー — GetFederationToken オペレーションを使用してルートユーザーがフェデレーションを行った結果、ルートユーザーのフェデレーティッドユーザーセッションプリンシパルができます。

この操作を使用して、IAM ユーザーまたはルートユーザーが AWS STS から一時的な認証情報をリクエストした場合、一時的なフェデレーティッドユーザーセッションを開始します。このセッションの ARN は、フェデレーション元の ID に基づいています。

Principal 要素でフェデレーティッドユーザーセッション ARN を指定する場合は、次の形式を使用します。


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

AWS サービスプリンシパル

リソースベースのポリシーにある Principal 要素か、プリンシパルをサポートする条件キーで、AWS サービスを指定できます。サービスプリンシパルは、サービスの識別子です。

AWS のサービスが引き受けることのできる IAM ロールは、サービスロールと呼ばれます。サービスロールには信頼ポリシーを含める必要があります。信頼ポリシー は、どのプリンシパルがそのロールを果たすことができるかを定義するロールにアタッチされるリソースベースのポリシーです。一部のサービスロールには事前定義済みの信頼ポリシーがあります。ただし、状況によっては、信頼ポリシーでプリンシパルサービスを指定する必要があります。IAM ポリシーのサービスプリンシパルを "Service": "*" にすることはできません。

重要

サービスプリンシパルの識別子にはサービス名が含まれ、通常は次の形式になります。

service-name.amazonaws.com

サービスプリンシパルはサービスによって定義されます。一部のサービスのサービスプリンシパルを検索するには IAM と連携する AWS のサービスを開き、サービスの [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 リージョンの管理」を参照してください。

オプトインリージョンの 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 リソースはグローバルであるため、どのリージョンでも同じロールを使用することができます。

すべてのプリンシパル

ワイルドカード (*) を使用して Principal リソースベースのポリシーの要素またはプリンシパルをサポートする条件キーにあるすべてのプリンシパルを指定できます。リソースベースのポリシー許可のアクセス権および条件キーはポリシーステートメントの条件を制限するために使用されます。

重要

パブリックまたは匿名アクセスを許可する意図がない限り、Allow の影響を伴うリソースベースのポリシーの Principal 要素にワイルドカード (*) を使用しないことを強くお勧めします。それ以外の場合は、Principal 要素で目的のプリンシパル、サービス、または AWS アカウントを指定して、Condition 要素でさらにアクセスを制限します。これは、他のプリンシパルがアカウントのプリンシパルになることを許可することから、特にIAM ロールの信頼ポリシーに当てはまります。

リソースベースポリシーでは、Allow 効果でワイルドカード (*) を使用することで、匿名ユーザー (パブリックアクセス) を含むすべてのユーザーへのアクセスが許可されます。アカウント内の IAM ユーザーおよびロールプリンシパルの場合、他のアクセス権は必要ありません。他のアカウントのプリンシパルの場合、アカウント内にリソースへのアクセスを許可する ID ベースのアクセス許可がある必要があります。これはクロスアカウントアクセスと呼ばれます。

匿名ユーザーの場合、次の要素は同等です。


"Principal": "*"


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

ワイルドカードとして使用して、プリンシパルの名前または ARN の一部に一致させることはできません。

次の例は、Condition 要素で指定されたものを除いたすべてのプリンシパルを明確に拒否する Deny とともに NotPrincipal を指定するの代わりに使用できるリソースベースのポリシーを示しています。


{
  "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 ユーザーガイド」にあるバケットポリシーの例
「Amazon Simple Notification Service 開発者ガイド」にある Amazon SNS のポリシーの例
「Amazon Simple Queue Service 開発者ガイド」にある Amazon SQS ポリシーの例
「AWS Key Management Service 開発者ガイド」にある主要ポリシー
「AWS 全般のリファレンス」の「アカウント ID」
OIDC フェデレーション

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

Effect

NotPrincipal