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

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 に付与されたアクセス許可は保持されるからです。リソースベースポリシーの Principal 要素で、ワイルドカード (*) を含む aws:PrincipalArn 条件キーを使用して付与されたアクセス許可は、アクセス権限の境界やセッションポリシーなどの ID ベースのポリシータイプによって制限されることはありません。これらのポリシーのいずれかを明示的に拒否した場合、許可は無効になります。

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

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

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

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

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

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

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

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

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

ウェブ ID セッションプリンシパル

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

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

このプリンシパルタイプをポリシーで使用して、信頼済みの Web ID プロバイダーに基づき、アクセスを許可または拒否します。ロール信頼ポリシーの Principal 要素でウェブ ID ロールセッション 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 API オペレーションの比較」を参照してください。

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

このプリンシパルタイプをポリシーで使用して、信頼済みの SAML ID プロバイダーに基づき、アクセスを許可または拒否します。ロール信頼ポリシーの Principal 要素でウェブ 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 に変換します。

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

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

重要

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

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

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

  • 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 ロールは、サービスロールと呼ばれます。サービスロールには信頼ポリシーを含める必要があります。信頼ポリシー は、どのプリンシパルがそのロールを果たすことができるかを定義するロールにアタッチされるリソースベースのポリシーです。一部のサービスロールには事前定義済みの信頼ポリシーがあります。ただし、状況によっては、信頼ポリシーでプリンシパルサービスを指定する必要があります。

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

service-name.amazonaws.com

サービスプリンシパルはサービスによって定義されます。一部のサービスのサービスプリンシパルを検索するには AWSIAM と連携する{ut}サービス を開き、サービスの [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" ] }

すべてのプリンシパル

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

重要

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

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

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

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

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

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

{ "Version": "2012-10-17", "Statement": [ { "Sid": "UsePrincipalArnInsteadOfNotPrincipalWithDeny", "Effect": "Deny", "Action": "s3:*", "Principal": "*", "Resource": [ "arn:aws:s3:::BUCKETNAME/*", "arn:aws:s3:::BUCKETNAME" ], "Condition": { "ArnNotEquals": { "aws:PrincipalArn": "arn:aws:iam::444455556666:user/user-name" } } } ] }

詳細情報

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