AWS JSON ポリシーの要素: Principal - AWS Identity and Access Management

AWS JSON ポリシーの要素: Principal

ポリシーの Principal 要素を使用して、リソースへのアクセスを許可または拒否するプリンシパルを指定します。Principal エレメントを IAM アイデンティティベースのポリシーで使用することはできません。これは、IAM ロール用の信頼ポリシーおよびリソースベースのポリシーで使用することができます。リソースベースのポリシーは、リソースに直接埋め込むポリシーです。たとえば、Amazon S3 バケットあるいは AWS KMS カスタマーマスターキー (CMK) にポリシーを埋め込むことができます。

ポリシーでは、次のいずれかのプリンシパルを指定できます。

  • AWS アカウントと ルートユーザー

  • IAM ユーザー

  • フェデレーティッドユーザー(ウェブ ID または SAML フェデレーションを使用)

  • IAM ロール

  • ロールを引き受けるセッション

  • AWS サービス

  • 匿名ユーザー(非推奨)

Principal エレメントは次のように使用します。

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

    注記

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

  • リソースベースのポリシーでは、Principal エレメントを使用して、リソースへのアクセスが許可されるアカウントまたはユーザーを指定します。

IAM ユーザーおよびグループにアタッチするポリシーで Principal 要素は使用しないでください。同様に、IAM ロールのアクセス許可ポリシー内ではプリンシパルを指定しないでください。このような場合、プリンシパルは、暗黙的に、ポリシーがアタッチされたユーザーとなるか (IAM ユーザーの場合)、ロールを引き受けるユーザーとなります (ロールアクセスポリシーの場合)。ポリシーが IAM グループにアタッチされている場合、そのグループ内のリクエスト元 IAM ユーザーがプリンシパルです。

プリンシパルの指定

プリンシパルを指定するには、次のセクションに示されているように、Amazon リソースネーム (ARN) またはその他のプリンシパル ID を使用します。IAM グループやインスタンスプロファイルをプリンシパルとして指定することはできません。

次のセクションでは、配列を使用して、プリンシパルタイプごとに複数のプリンシパルを指定できます。配列では 1 つまたは複数の値を使用できます。複数の値が含まれている場合、配列は次の例のように、角括弧([])で囲まれ、カンマで区切られます。

"Principal" : { "AWS": [ "arn:aws:iam::123456789012:root", "arn:aws:iam::555555555555:root" ] }

AWS アカウント

AWS アカウント ID をポリシーでプリンシパルとして使用する場合、そのアカウントに権限を委任します。アカウント内のすべての ID は、明示的にアクセスを許可するための適切な IAM アクセス許可がアタッチされていれば、リソースにアクセスできます。そのアカウントには、IAM ユーザーおよびロールが含まれます。AWS アカウントを指定するときは、アカウント ARN (arn:aws:iam::AWS-account-ID:root)、または AWS: プレフィックスの後に ID を付けた短縮形を使用できます。

たとえば、割り当てられた アカウント ID (123456789012) から、次のいずれかのメソッドを使用して、Principal 要素でそのアカウントを指定できます。

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

また、配列を使用して、前述のメソッドの任意の組み合わせで、プリンシパルとして複数の AWS アカウント (または正規ユーザー ID) を指定することもできます。

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

一部の AWS サービスでは、アカウントプリンシパルを指定するための追加オプションがサポートされています。たとえば、Amazon S3 では、以下の形式を使用して正規ユーザー ID を指定できます。

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

個別の IAM ユーザー

次の例に示されているように、個別の IAM ユーザー(または一連のユーザー)をプリンシパルとして指定することができます。要素で複数のプリンシパルを指定する場合は、各プリンシパルにアクセス許可を付与します。これは論理 OR であり論理 AND ではありません。一度に 1 つのプリンシパルとして認証されるためです。

注記

Principal エレメントでは、ユーザー名の大文字と小文字が区別されます。

"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/UserName2" ] }

Principal エレメント内でユーザーを指定する際に、"すべてのユーザー" の意味でワイルドカード (*) を使用することはできません。プリンシパルには、常に特定のユーザー(または複数の特定ユーザー)を指定する必要があります。

重要

ロールの信頼ポリシーの Principal 要素に、特定の IAM ユーザーを指し示す ARN が含まれている場合、その ARN はポリシーを保存するときにユーザーの一意のプリンシパル ID に変換されます。これにより、ユーザーを削除して再作成することにより、誰かがそのユーザーの特権をエスカレートするリスクを緩和できます。通常、この ID はコンソールには表示されません。これは、信頼ポリシーが表示されるときに、ユーザーの ARN への逆変換が行われるためです。ただし、ユーザーを削除すると、関係が壊れます。ユーザーを再作成しても、ポリシーが適用されることはありません。これは、新しいユーザーには、信頼ポリシーに保存されている ID と一致しない新しいプリンシパル ID が付与されるためです。この場合、プリンシパル ID はコンソールに表示されます。これは、AWS が有効な ARN に ID をマッピングできなくなるためです。その結果、信頼ポリシーの Principal エレメントで参照されているユーザーを削除して再作成する場合は、ロールを編集して、正しくなくなったプリンシパル ID を正しい ARN に置き換える必要があります。ポリシーを保存するときに、ARN は再びユーザーの新しいプリンシパル ID に変換されます。

フェデレーティッドウェブ ID ユーザー

"Principal": { "Federated": "cognito-identity.amazonaws.com" }
"Principal": { "Federated": "www.amazon.com" }
"Principal": { "Federated": "graph.facebook.com" }
"Principal": { "Federated": "accounts.google.com" }

フェデレーティッド SAML ユーザー

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

IAM ロール

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

ロールの Principal 要素に、特定の IAM ロールを指し示す ARN が含まれている場合、その ARN はポリシーを保存するときにロールの一意のプリンシパル ID に変換されます。これにより、ロールを削除して再作成することにより、誰かがそのユーザーの特権をエスカレートするリスクを緩和できます。通常、この ID はコンソールには表示されません。これは、信頼ポリシーが表示されるときに、ロールの ARN への逆変換が行われるためです。ただし、ロールを削除すると、関係が壊れます。ロールを再作成した場合でも、ポリシーは適用されません。これは、新しいロールは信頼ポリシーに保存されている ID と一致しない新しいプリンシパル ID を持っているためです。この場合、プリンシパル ID はコンソールに表示されます。これは、AWS が有効な ARN に ID をマッピングできなくなるためです。その結果、信頼ポリシーの Principal エレメントで参照されているロールを削除して再作成する場合は、ロールを編集して正しくなくなったプリンシパル ID を正しい ARN に置き換える必要があります。ポリシーを保存するときに、ARN は再びロールの新しいプリンシパル ID に変換されます。

特定のロールを引き受けたセッション

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

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

AWS サービス

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

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

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 エレメントの値として複数のサービスのプリンシパルのアレイを使用します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "ecs.amazonaws.com", "elasticloadbalancing.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] }

匿名ユーザー (パブリックアクセス)

Amazon S3 バケットポリシーなどのリソースベースのポリシーの場合、プリンシパル要素のワイルドカード (*) は、すべてのユーザーまたはパブリックアクセスを指定します。次の要素は同等です。

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

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

ポリシー内で Principal 要素を使用してアクセスを制限する場合を除き、ロールの信頼ポリシーの Condition 要素にワイルドカードを使用しないことを強くお勧めします。そうしないと、パーティション内のすべてのアカウントの IAM ユーザーがロールにアクセスできてしまいます。

詳細情報

詳細については、以下を参照してください。