翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon Verified Permissions による承認

Amazon Verified Permissions は、構築するアプリケーションの認証サービスです。Amazon Cognito ユーザープールを ID ソースとして追加すると、アプリケーションはユーザープールアクセスまたはアイデンティティ (ID) トークンを Verified Permissions に渡して、許可または拒否を決定できます。Verified Permissions は、Cedar ポリシー言語で記述したポリシーに基づいてユーザーのプロパティとリクエストコンテキストを考慮します。リクエストコンテキストには、リクエストしたドキュメント、画像、その他のリソースの ID と、ユーザーがリソースに対して実行するアクションを含めることができます。

アプリは、 または BatchIsAuthorizedWithTokenAPIリクエストの検証済みアクセス許可にユーザーの ID IsAuthorizedWithTokenトークンまたはアクセストークンを提供できます。これらのAPIオペレーションは、ユーザーを として受け入れPrincipal、アクセスResourceする Actionの の承認決定を行います。追加のカスタムは、詳細なアクセス決定に貢献Contextできます。

アプリケーションがIsAuthorizedWithTokenAPIリクエストにトークンを提示すると、Verified Permissions は次の検証を実行します。

失効したトークンと削除されたユーザー

Verified Permissions は、ID ソースとユーザートークンの有効期限からの既知の情報のみを検証します。Verified Permissions では、トークンの失効やユーザーの存在は確認されません。ユーザーのトークンを取り消したり、ユーザープールからユーザープロファイルを削除したりした場合でも、Verified Permissions は有効期限が切れるまでトークンを有効と見なします。

ポリシーの評価

ユーザープールをポリシーストアの ID ソースとして設定します。Verified Permissions へのリクエストでユーザーのトークンを送信するようにアプリケーションを設定します。Verified Permissions はリクエストごとに、トークンのクレームをポリシーと比較します。Verified Permissions ポリシーは、 のIAMポリシーのようなものです AWS。プリンシパル、リソース、およびアクションを宣言します。Verified Permissions は、許可されたアクションと一致しAllow、明示的なDenyアクションと一致しない場合、 でリクエストに応答します。一致しない場合は、 で応答しますDeny。詳細については、「Amazon Verified Permissions ユーザーガイド」の「Amazon Verified Permissions のポリシー」を参照してください。

トークンをカスタマイズする

Verified Permissions に提示するユーザークレームを変更、追加、削除するには、 を使用してアクセストークンと ID トークンのコンテンツをカスタマイズしますトークン生成前の Lambda トリガー。プレトークンを生成するトリガーを使用すると、トークンでクレームを追加および変更できます。例えば、データベースで追加のユーザー属性をクエリし、それらを ID トークンにエンコードできます。

API Verified Permissions による認証

ID トークンまたはアクセストークンは、Verified Permissions RESTAPIsを使用してバックエンド Amazon API Gateway へのリクエストを承認できます。ユーザープールと にすぐにリンクするポリシーストアを作成できますAPI。Cognito とAPIゲートウェイでのセットアップの開始オプションでは、Verified Permissions はポリシーストアにユーザープール ID ソースを追加し、Lambda オーソライザーを に追加しますAPI。アプリケーションがユーザープールベアラトークンを に渡すとAPI、Lambda オーソライザーは Verified Permissions を呼び出します。オーソライザーはトークンをプリンシパルとして、リクエストパスとメソッドをアクションとして渡します。

次の図は、検証済みアクセス許可APIを持つAPIゲートウェイの承認フローを示しています。詳細については、「Amazon Verified Permissions ユーザーガイド」のAPI「リンクされたポリシーストア」を参照してください。

ユーザープールグループ に関する Verified Permissions 構造APIの承認。ID トークンとアクセストークンの両方にcognito:groupsクレームが含まれているため、ポリシーストアはさまざまなアプリケーションコンテキストAPIsで のロールベースのアクセスコントロール (RBAC) を管理できます。

ポリシーストア設定の選択

ポリシーストアで ID ソースを設定するときは、アクセストークンと ID トークンのどちらを処理するかを選択する必要があります。この決定は、ポリシーエンジンの動作方法にとって重要です。ID トークンにはユーザー属性が含まれます。アクセストークンには、ユーザーのアクセスコントロール情報 OAuthスコープ が含まれます。どちらのトークンタイプにもグループメンバー情報がありますが、通常は Verified Permissions ポリシーストアRBACを持つ のアクセストークンをお勧めします。アクセストークンは、承認決定に貢献できるスコープを持つグループメンバーシップに追加されます。アクセストークンのクレームは、認証リクエストのコンテキストになります。

ユーザープールを ID ソースとして設定する場合は、ユーザーエンティティタイプとグループエンティティタイプも設定する必要があります。エンティティタイプは、Verified Permissions ポリシーで参照できるプリンシパル、アクション、リソース識別子です。ポリシーストア内のエンティティはメンバーシップ関係を持つことができ、1 つのエンティティが親エンティティのメンバーになることができます。メンバーシップを使用すると、プリンシパルグループ、アクショングループ、リソースグループを参照できます。ユーザープールグループの場合、指定するユーザーエンティティタイプはグループエンティティタイプのメンバーである必要があります。リンクAPIされたポリシーストアをセットアップするか、Verified Permissions コンソールでガイド付きセットアップに従うと、ポリシーストアは自動的にこの親メンバーの関係を持ちます。

ID トークンは、属性ベースのアクセスコントロール () RBAC と組み合わせることができますABAC。リンクAPIされたポリシーストア を作成したら、ユーザー属性とグループメンバーシップを使用してポリシーを強化できます。ID トークンの属性クレームは、認証リクエストのプリンシパル属性になります。ポリシーは、プリンシパル属性に基づいて承認決定を行うことができます。

また、指定した許容可能なアプリケーションクライアントのリストに一致する audまたは client_idクレームでトークンを受け入れるようにポリシーストアを設定することもできます。

ロールベースのAPI承認のポリシー例

次のポリシー例は、 PetStore 例の検証済みアクセス許可ポリシーストアのセットアップによって作成されましたRESTAPI。

permit(
  principal in PetStore::UserGroup::"us-east-1_EXAMPLE|MyGroup",
  action in [ PetStore::Action::"get /pets", PetStore::Action::"get /pets/{petId}" ],
  resource
  );

Verified Permissions は、次の場合にアプリケーションから認証リクエストにAllow決定を返します。

Amazon Cognito ユーザーのポリシーの例。

ユーザープールは、リクエスト以外の条件で Verified Permissions への認証APIリクエストを生成することもできます。アプリケーション内のアクセスコントロールの決定は、ポリシーストアに送信できます。例えば、リクエストがネットワークを通過する前に、属性ベースのアクセスコントロールで Amazon DynamoDB または Amazon S3 セキュリティを補完し、クォータの使用を減らすことができます。

次の例では、Cedar ポリシー言語を使用して、1 つのユーザープールアプリケーションクライアントで認証する Finance ユーザーに example_image.png の読み取りと書き込みを許可しています。アプリケーションのユーザーである John は、アプリケーションクライアントから ID トークンを受け取り、認証URLを必要とする GETにリクエストで渡しますhttps://example.com/images/example_image.png。John の ID トークンには、ユーザープールアプリケーションのクライアント ID 1234567890example の aud クレームが含まれています。また、プレトークンを生成する Lambda 関数によって、John 用に新しいクレーム costCenter (値は Finance1234) が挿入されています。

permit (
   principal,
   actions in [ExampleCorp::Action::"readFile", "writeFile"],
   resource == ExampleCorp::Photo::"example_image.png"
)
when {
   principal.aud == "1234567890example" &&
   principal.custom.costCenter like "Finance*"
};

次のリクエスト本文の結果は Allow レスポンスになります。

{
   "accesstoken": "[John's ID token]",
   "action": {
      "actionId": "readFile",
      "actionType": "Action"
   },
   "resource": {
      "entityId": "example_image.png",
      "entityType": "Photo"
   }
}

Verified Permissions でプリンシパルを指定する場合は、次の形式を使用してください。

permit (
   principal == [Namespace]::[Entity]::"[user pool ID]"|"[user sub]",
   action,
   resource
);

以下は、us-east-1_Exampleサブ またはユーザー ID を持つ ID を持つユーザープール内のユーザーのプリンシパルの例です973db890-092c-49e4-a9d0-912a4c0a20c7。

principal == ExampleCorp::User::"us-east-1_Example|973db890-092c-49e4-a9d0-912a4c0a20c7",

Verified Permissions ポリシーでユーザーグループを指定する場合は、次の形式を使用します。

permit (
   principal in [Namespace]::[Group Entity]::"[Group name]",
   action,
   resource
);

以下に例を示します。

単一ドメイン内の属性ベースの

アプリケーションの Verified Permissions による認証と、 AWS 認証情報用の Amazon Cognito ID プールのアクセスコントロール機能の属性は、いずれも属性ベースのアクセスコントロール () の形式ですABAC。以下は、Verified Permissions と Amazon Cognito の機能の比較ですABAC。ではABAC、システムはエンティティの属性を調べ、定義した条件から承認を決定します。