翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ロールベースアクセスコントロールの使用 Amazon Cognito ID プールは、認証されたユーザーに、 AWS リソースにアクセスするための権限が制限された一時的な認証情報のセットを割り当てます。各ユーザーの許可は、作成された [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)を介して制御されます。ユーザーの ID トークンのクレームに基づいて、各ユーザーのロールを選択するルールを定義できます。認証されたユーザー用のデフォルトのロールを定義できます。また、認証されていないゲストユーザーに対して、権限が制限された個別の IAM ロールを定義することもできます。 ## ロールマッピング用のロールの作成 各ロールに適切な信頼ポリシーを追加し、Amazon Cognito が ID プール内の認証されたユーザー限定でそのポリシーを引き受けるようにすることが重要です。このような信頼ポリシーの例を示します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Federated": "cognito-identity.amazonaws.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "cognito-identity.amazonaws.com:aud": "us-east-1:12345678-corner-cafe-123456790ab" }, "ForAnyValue:StringLike": { "cognito-identity.amazonaws.com:amr": "authenticated" } } } ] } ``` ------ このポリシーでは、`cognito-identity.amazonaws.com` のフェデレーティッドユーザー (OpenID Connect トークンの発行者) が、このロールを引き受けることができます。さらに、ポリシーでは、ID プールに一致させるためにトークンの `aud` が制限されます (この場合は ID プール ID)。最後に、このポリシーは、Amazon Cognito によって発行されたトークンの複数の値からなる `amr` クレームの配列メンバーの 1 つを指定します。`GetOpenIdToken` API アクションは `authenticated` 値を含みます。 ## pass-role 許可の付与 ユーザーが、ID プールでユーザーの既存のアクセス許可を超えるアクセス許可でロールを設定できるようにするには、`set-identity-pool-roles` API にロールを渡すための `iam:PassRole` アクセス許可をそのユーザーに付与します。例えば、ユーザーが Amazon S3 に書き込むことはできなくても、ID プールでユーザーが設定する IAM ロールが Amazon S3 への書き込み許可を付与するという場合、ユーザーは `iam:PassRole` 許可がそのロールに付与されている場合にのみ、このロールを設定できます。次のサンプルポリシー例は、`iam:PassRole` 権限を付与する方法を示しています。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Stmt1", "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ "arn:aws:iam::123456789012:role/myS3WriteAccessRole" ] } ] } ``` ------ このサンプルポリシーでは、`iam:PassRole` ロールに `myS3WriteAccessRole` アクセス権限を付与します。このロールは、それ自体の Amazon リソースネーム (ARN) を使用して指定します。また、このポリシーをユーザーにアタッチする必要があります。詳細については、「[管理ポリシーの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html)」を参照してください。 **注記** Lambda 関数はリソースベースのポリシーを使用し、このポリシーは Lambda 関数自体に直接アタッチされます。Lambda 関数を呼び出すルールを作成するときはロールを渡さないため、ルールを作成するユーザーに `iam:PassRole` 許可は必要ありません。Lambda 関数の認可に関する詳細については、「[アクセス許可の管理: Lambda 関数ポリシーを使用する](https://docs.aws.amazon.com/lambda/latest/dg/intro-permission-model.html#intro-permission-model-access-policy)」を参照してください。 ## ユーザーにロールを割り当てるためのトークンの使用 Amazon Cognito ユーザープール経由でログインするユーザーの場合、ユーザープールによって割り当てられた ID トークンにロールを渡すことができます。これらのロールは、ID トークンの以下のクレームに表示されます。 + `cognito:preferred_role` クレームはロール ARN です。 + `cognito:roles` クレームは、許可されたロール ARN のセットを含むカンマ区切りの文字列です。 クレームは以下のように設定されます。 + `cognito:preferred_role` クレームは、最高 (最も低い) `Precedence` 値のグループのロールに設定されます。許可されているロールが 1 つだけである場合、`cognito:preferred_role` はそのロールに設定されます。複数のロールがあり、いずれの単一のロールにも最良の優先順位がない場合、このクレームは設定されません。 + `cognito:roles` クレームは、少なくとも 1 つのロールがある場合に設定されます。 ロールの割り当てにトークンを使用するときに、ユーザーに割り当てることができる複数のロールがある場合は、Amazon Cognito ID プール (フェデレーティッド ID) が以下のようにロールを選択します。 + [GetCredentialsForIdentity](https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_GetCredentialsForIdentity.html) `CustomRoleArn` パラメータが設定されており、これが `cognito:roles` クレームのロールに一致する場合は、このパラメータを使用します。このパラメータが `cognito:roles` のロールと一致しない場合は、アクセスを拒否します。 + `cognito:preferred_role` クレームが設定されている場合は、それを使用します。 + `cognito:preferred_role` クレームが設定されておらず、`cognito:roles` クレームが設定されており、`GetCredentialsForIdentity` に対する呼び出しで `CustomRoleArn` が指定されていない場合、割り当てるロールの決定には、コンソールの **[ロールの解決]** 設定、または `AmbiguousRoleResolution` フィールド ([SetIdentityPoolRoles](https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_SetIdentityPoolRoles.html) API の `RoleMappings` パラメータ内) が使用されます。 ## ルールベースのマッピングを使用してユーザーにロールを割り当てる ルールは、IAM ロールに ID プロバイダートークンからのクレームをマップすることを許可します。 各ルールは、トークンクレーム (Amazon Cognito ユーザープールからの ID トークンのユーザー属性など)、一致タイプ、値、および IAM ロールを指定します。一致タイプは、`Equals`、`NotEqual`、`StartsWith`、または `Contains` となります。クレームに一致する値をユーザーが持っている場合、そのユーザーは、認証情報を取得するときにそのロールを引き受けることができます。例えば、`custom:dept` カスタム属性値が `Sales` のユーザーに特定の IAM ロールを割り当てるルールを作成できます。 **注記** ルールの設定で、カスタム属性は標準属性と区別するために、`custom:` プレフィックスを必要とします。 `CustomRoleArn` が順序を上書きするように指定されている場合を除き、ルールは順序に従って評価され、一致する最初のルールの IAM ロールが使用されます。Amazon Cognito ユーザープールでのユーザー属性の詳細については、「[ユーザー属性の操作](user-pool-settings-attributes.md)」を参照してください。 ID プール (フェデレーティッド ID) コンソールでは、認証プロバイダー用に複数のルールを設定できます。ルールは順序に従って適用されます。ルールをドラッグして、それらの順序を変更できます。一致する最初のルールが優先されます。一致タイプが `NotEqual` で、クレームが存在しない場合、ルールは評価されません。一致するルールがない場合は、**[ロールの解決]** 設定が **[デフォルトの認証されたロールを使用する]** または **[リクエストの拒否]** に適用されます。 API および CLI では、[SetIdentityPoolRoles](https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_SetIdentityPoolRoles.html) API の `RoleMappings` パラメータで指定されている [RoleMapping](https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_RoleMapping.html) タイプの `AmbiguousRoleResolution` フィールドに一致するルールがない場合に、割り当てられるロールを指定できます。 Amazon Cognito コンソールで ID プロバイダーにルールベースのマッピングを追加するには、IdP を追加または更新し、**[ロールの選択]** で **[ルールを使用してロールを選択する]** を選択します。そこから、プロバイダーのクレームを IAM ロールにマッピングするルールを追加できます。 [RoleMapping](https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_RoleMapping.html) タイプの `RulesConfiguration`フィールドを使用して、 AWS CLI または API で ID プロバイダーのルールベースのマッピングを設定できます。このフィールドは、[SetIdentityPoolRoles](https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_SetIdentityPoolRoles.html) API の `RoleMappings` パラメータで指定できます。 たとえば、次の AWS CLI コマンドは、OIDC IdP によって認証された Sacramento ロケーションの`arn:aws:iam::123456789012:role/Sacramento_team_S3_admin`ユーザーにロールを割り当てるルールを追加します`arn:aws:iam::123456789012:oidc-provider/myOIDCIdP`。 ``` aws cognito-identity set-identity-pool-roles --region us-east-1 --cli-input-json file://role-mapping.json ``` **`role-mapping.json` の内容**: ``` { "IdentityPoolId": "us-east-1:12345678-corner-cafe-123456790ab", "Roles": { "authenticated": "arn:aws:iam::123456789012:role/myS3WriteAccessRole", "unauthenticated": "arn:aws:iam::123456789012:role/myS3ReadAccessRole" }, "RoleMappings": { "arn:aws:iam::123456789012:oidc-provider/myOIDCIdP": { "Type": "Rules", "AmbiguousRoleResolution": "AuthenticatedRole", "RulesConfiguration": { "Rules": [ { "Claim": "locale", "MatchType": "Equals", "Value": "Sacramento", "RoleARN": "arn:aws:iam::123456789012:role/Sacramento_team_S3_admin" } ] } } } } ``` ID プールに対して設定された各ユーザープールまたはその他の認証プロバイダーの場合、最大 25 のルールを作成できます。この制限は調整できません。詳細については、「[Amazon Cognito のクォータ](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html)」を参照してください。 ## ルールベースのマッピングで使用するトークンクレーム **Amazon Cognito** Amazon Cognito ID トークンは JSON Web トークン (JWT) として表されます。トークンには、認証ユーザーの ID に関するクレームが含まれます。たとえば、`name`、`family_name`、`phone_number` などです。標準クレームに関する詳細については、「[OpenID Connect 仕様](http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)」を参照してください。標準クレームとは別に、以下のような Amazon Cognito に固有の追加のクレームがあります。 + `cognito:groups` + `cognito:roles` + `cognito:preferred_role` **Amazon** 以下のクレームとそのクレームに使用できる値を、Login with Amazon で使用できます。 + `iss`: www.amazon.com + `aud`: App Id + `sub`: Login with Amazon トークンからの `sub` **Facebook** 以下のクレームとそのクレームに使用できる値を、Facebook で使用できます。 + `iss`: graph.facebook.com + `aud`: App Id + `sub`: Facebook トークンからの `sub` **Google** Google トークンには、[OpenID Connect 仕様](http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)からの標準クレームが含まれます。OpenID トークンのクレームはすべて、ルールベースのマッピングに使用できます。Google トークンで使用できるクレームについては、Google の [OpenID Connect](https://developers.google.com/identity/protocols/OpenIDConnect) サイトを参照してください。 **Apple** Apple トークンには、[OpenID Connect specification](http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) からの標準クレームが含まれます。Apple トークンから入手できるクレームの詳細については、Apple のドキュメントの「[Apple でサインインを使用してユーザーを認証する](https://developer.apple.com/documentation/signinwithapple/authenticating-users-with-sign-in-with-apple)」を参照してください。`email` は Apple のトークンには必ずしも含まれているわけではありません。 **OpenID** Open ID トークンのクレームはすべて、ルールベースのマッピングに使用できます。標準クレームに関する詳細については、「[OpenID Connect 仕様](http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)」を参照してください。使用できる追加クレームについては、ご使用の OpenID プロバイダーのドキュメントを参照してください。 **SAML** クレームは受信した SAML アサーションから分析されます。SAML アサーションで利用可能なすべてのクレームは、ルールベースのマッピングで使用できます。 ## ロールベースのアクセスコントロールのベストプラクティス **重要** ロールにマッピングするクレームがエンドユーザーによって変更できる場合、いずれのエンドユーザーもロールを引き受け、それに応じてポリシーを設定できます。エンドユーザーによって直接設定できないクレームのみを、昇格されたアクセス権限のあるロールにマッピングします。Amazon Cognito ユーザープールで、各ユーザー属性にアプリごとの読み取りおよび書き込み許可を設定できます。 **重要** Amazon Cognito ユーザープールのグループにロールを設定する場合、これらのロールはユーザーの ID トークンを通じて渡されます。これらのロールを使用するには、ID プールの認証ロールの選択に対して [**トークンからロールを選択する**] を設定する必要があります。 トークンから正しいロールを判断できない場合のデフォルト動作を指定するには、コンソールの **[Role resolution]** (ロールの解決) 設定と、[SetIdentityPoolRoles](https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_SetIdentityPoolRoles.html) API の `RoleMappings` パラメータを使用できます。