AWS認定資格 WEB問題集＆徹底解説セキュリティ専門知識（SCS）

会員登録/ログイン

1. サービス概要

Amazon Verified Permissionsは、自社で開発するアプリケーションの「誰が・どのリソースに・何をしてよいか」というきめ細かな認可（Authorization）を、アプリケーションのコードから切り離して一元管理するフルマネージドサービスです。 2022年のre:Inventでプレビューとして発表され、2023年6月に一般提供（GA）となりました。

認可ルールはオープンソースのCedarポリシー言語で記述し、サービス内のポリシーストアに保存します。アプリケーションは処理の前に認可APIを呼び出し、返ってきたAllow / Denyに従うだけになります。 ユーザーの認証（サインイン）はAmazon CognitoやOIDC準拠のIdPが担い、Verified Permissionsは認可だけを判定します。 AWSリソースへのアクセスを制御するIAMとは対象が異なり、Verified Permissionsはアプリケーション内部のリソース（文書・案件・写真など）とその操作を守るためのサービスである点が最大のポイントです。

2. 主な特徴と機能

2.1 Cedarポリシー言語

Cedarは、認可ポリシーを人が読める形で書き、高速かつ安全に評価できるよう設計されたオープンソースの言語です。ポリシーはpermit（許可）またはforbid（禁止）の効果と、principal・action・resourceのスコープ、when / unlessの条件で構成されます。 評価はデフォルト拒否で、該当するpermitが1つも無ければDeny、forbidが1つでも該当すればpermitより優先してDenyになります。 グループ所属によるRBACと属性比較によるABACの両方を表現できます。

2.2 ポリシーストアとスキーマ

ポリシーストアはポリシーとポリシーテンプレートを格納するコンテナで、認可リクエストは必ずポリシーストアを指定して行います。ストアには、エンティティ型（ユーザー、文書など）・属性・アクションを定義するスキーマを持たせられます。 ポリシー検証を有効にすると、スキーマに存在しない型やアクション、型の合わない比較を含むポリシーは登録時に拒否されるため、誤記による「効かないポリシー」を防げます。 ストアはアプリケーションごと（マルチテナントではテナントごとも選択肢）に分けるのが基本です。

2.3 静的ポリシーとポリシーテンプレート

個別に書いて登録するのが静的ポリシーです。これに対しポリシーテンプレートは、?principalや?resourceをプレースホルダーとして持つ雛形で、値を埋めてテンプレートリンクポリシーを作成します。 テンプレート本体を変更すると、そこから作られた全リンクポリシーに変更が反映されるため、「文書の共有」「閲覧者ロールの付与」のように同じ形の権限を大量に払い出す場面に向きます。

2.4 IDソース（Amazon Cognito / OIDC）

ポリシーストアには、Amazon CognitoユーザープールまたはOIDC準拠のIdP（Okta、Microsoft Entra IDなど）をIDソースとして登録できます。 IDソースを登録すると、アプリケーションは受け取ったJWTをそのまま渡すだけで判定でき、Verified Permissionsがトークンを検証してクレームをCedarのエンティティに変換します。 IDトークンのクレームはプリンシパルの属性に、アクセストークンのクレームはコンテキストに対応付けられ、groups系のクレームはプリンシパルの所属グループとしてRBACに使えます。

2.5 認可API

• IsAuthorized: プリンシパル・アクション・リソース・コンテキストとエンティティ情報をアプリケーション側で組み立てて渡す。
• IsAuthorizedWithToken: IDソースのIDトークンまたはアクセストークンを渡し、プリンシパル情報をトークンから得る。
• BatchIsAuthorized / BatchIsAuthorizedWithToken: プリンシパルまたはリソースが共通の複数の判定（最大30件）をまとめて行い、画面表示時の一覧フィルタリングなどの呼び出し回数を減らす。

応答にはAllow / Denyと、判定を決めたポリシーのIDが含まれます。

3. アーキテクチャおよび技術要素

1. ユーザーはCognitoユーザープールや外部IdPで認証し、JWT（IDトークン / アクセストークン）を受け取る。
2. クライアントはトークンを付けてAPI（API Gateway＋Lambdaなど）を呼び出す。
3. API GatewayのLambdaオーソライザー、またはアプリケーション内のミドルウェアが、Verified PermissionsのIsAuthorizedWithToken（またはIsAuthorized）を呼び出す。ここがポリシー決定点（PDP）になる。
4. Verified Permissionsはポリシーストア内のCedarポリシーを評価し、Allow / Denyと決定ポリシーを返す。
5. アプリケーション（ポリシー実施点: PEP）は結果に従って処理を続行するか、403などのエラーを返す。
6. ポリシーの追加・変更はAPIやCloudFormation、CDKでポリシーストアに反映し、アプリケーションを再デプロイせずに認可ルールを変えられる。

API GatewayとCognito（またはOIDC）を組み合わせる場合は、APIリンク型ポリシーストアの作成ウィザードで、APIのリソース・メソッドからアクションを、IDソースのグループからプリンシパルを組み立て、Lambdaオーソライザーまで自動構成できます。

4. セキュリティと認証・認可

• 認証と認可の分離: 認証はCognito・OIDC IdP・IAM Identity Centerなどが担い、Verified Permissionsは「認証済みのプリンシパルが操作してよいか」だけを判定する。
• エンドユーザーにIAMプリンシパルは不要: 数万〜数百万のアプリユーザーごとにIAMユーザーやロールを作る設計は不要。Verified Permissionsを呼び出すアプリケーション側のIAMロールにverifiedpermissions:IsAuthorizedなどを許可する。
• IAMによる管理操作の制御: ポリシーストアやポリシーの作成・変更を行えるプリンシパルをIAMポリシーで限定し、認可ルールの改ざんを防ぐ。
• forbidによるガードレール: テナント越えのアクセスなど絶対に許してはならない操作はforbidポリシーで書く。どのpermitよりも優先されるため、個別ポリシーの誤りがあっても拒否が保たれる。
• 削除保護: ポリシーストアには削除保護を設定でき、コンソールから作成した場合は既定で有効になる（API / SDKで作成した場合は既定で無効）。
• 監査: ポリシーストアやポリシーへの操作はAWS CloudTrailで記録できる。

5. 料金形態

前払いや最低料金は無く、リクエスト数に応じた従量課金です。試験では金額そのものより「何に対して課金されるか」を押さえます。

• 単一の認可リクエスト: IsAuthorized / IsAuthorizedWithTokenの呼び出し回数で課金される。
• バッチ認可リクエスト: BatchIsAuthorized系は、中に含む判定件数ではなくAPI呼び出し1回を1リクエストとして数え、月間の量に応じた段階料金が適用される。
• ポリシー管理リクエスト: CreatePolicy・UpdatePolicy・GetPolicyなどの管理系API呼び出しも課金対象になる。
• コスト最適化: バッチAPIへの集約や、API Gatewayのオーソライザーキャッシュで呼び出し回数を抑える。

6. よくあるアーキテクチャ・設計パターン

• アプリ内コードの認可ロジックの外部化: Lambda関数内に散らばったif文による権限判定を、Cedarポリシーとして一元化し、監査部門が宣言的なポリシーとしてレビューできるようにする。
• API Gateway＋Cognito＋Lambdaオーソライザー: CognitoのグループでRBAC、カスタム属性でABACを行い、APIのメソッド単位・リソース単位に認可する。
• 文書共有・きめ細かな権限付与: 所有者が他者に「閲覧」「編集」を付与する機能を、ポリシーテンプレートとテンプレートリンクポリシーで実装する。
• マルチテナントSaaS: テナントごとのポリシーストア、または共有ポリシーストア＋テナント属性の条件で分離する。共有ストアの場合はprincipal.tenant != resource.tenantを拒否するforbidポリシーをガードレールとして置く。

7. 設定・デプロイ手順（ハンズオン例）

1. Verified Permissionsコンソールでポリシーストアを作成する（API Gateway＋Cognitoの場合はAPIリンク型のセットアップを選ぶと、スキーマとオーソライザーまで生成できる）。
2. スキーマでエンティティ型（User、Documentなど）・属性・アクション（ViewDocument、EditDocumentなど）を定義し、ポリシー検証を有効にする。
3. IDソースとしてCognitoユーザープールまたはOIDC IdPを登録し、トークンのクレームとプリンシパル属性・グループの対応を確認する。
4. 静的ポリシーで基本ルールを書き、繰り返し払い出す権限はポリシーテンプレートとして登録する。
5. コンソールのテストベンチで、期待どおりAllow / Denyになるか確認する。
6. アプリケーション（またはLambdaオーソライザー）からIsAuthorizedWithTokenを呼び出す処理を組み込み、実行ロールに必要なIAM権限を付与する。

8. 試験で問われやすいポイント