AWS Verified Permissions

AWS Verified Permissions は、アプリケーションの認可（オーソリゼーション）をマネージドサービスとして提供するサービスです。「このユーザーはこのリソースに対してこの操作をしてよいか」という判定ロジックをアプリ本体から切り離し、Cedar というポリシー言語で記述・集中管理できます。

解決する課題

アプリケーションに認可ロジックを自前で実装すると、権限チェックのコードが各所に散らばり、ルールの追加や変更のたびにアプリの改修とデプロイが必要になります。誰がどのリソースに何をできるのかが分散し、監査や見直しも難しくなりがちです。

Verified Permissions はこうした認可の判定を外部のポリシーストアに委ね、次のような課題を解決します。

• 認可ロジックがコードに埋め込まれて散在し、変更のたびにアプリのデプロイが必要になる状況を避ける
• 「誰が何にアクセスできるか」を一箇所のポリシーとして可視化し、レビューや監査をしやすくする
• ロールベースと属性ベースの権限モデルを、宣言的なポリシーとして統一的に表現する
• きめ細かい（ファイングレインな）認可を、アプリごとに作り込むのではなく共通基盤として提供する

なお Verified Permissions は「認可」を担うサービスであり、「このユーザーは本人か」を確かめる「認証」そのものは扱いません。認証は Amazon Cognito などに任せ、その認証結果を入力として認可判定を行う、という分担になります。

主要概念と用語

• ポリシーストア: ポリシーやスキーマをまとめて保持する論理的な入れ物。アプリ単位で作るのが基本で、認可リクエストはこのポリシーストアに対して行う。
• Cedar: Verified Permissions が採用するオープンソースの認可ポリシー言語。許可（permit）と拒否（forbid）を宣言的に記述する。
• ポリシー: 認可ルールの単位。主体・操作・リソース・条件を Cedar で表現する。個別に書く静的ポリシーと、テンプレートから生成するポリシーがある。
• ポリシーテンプレート: 主体やリソースをプレースホルダにした再利用可能なポリシーの雛形。テンプレートリンクポリシーとして実体化する。
• スキーマ: アプリで扱う主体・リソースの種類や属性、操作（アクション）を定義したもの。ポリシーの妥当性検証に使われる。
• 主体（プリンシパル）: 操作を行う側。ユーザーやロールなどを指す。
• アクション: 主体がリソースに対して行う操作。読み取りや更新などを表す。
• リソース: 操作の対象となるオブジェクト。ドキュメントやフォルダなどアプリ固有の対象を指す。
• 認可リクエスト: 主体・アクション・リソース・コンテキストを与えて許可か拒否かを問い合わせる呼び出し。判定結果として Allow か Deny が返る。

仕様・制限・クォータ

• 認可判定は単一リクエストの IsAuthorized と、複数を一括で問い合わせる BatchIsAuthorized などの API で行う。Cognito のトークンを直接渡して判定する API も用意されている。
• 判定は明示的に許可するポリシーが存在し、かつ拒否するポリシーが1つも存在しない場合にのみ Allow となる。拒否（forbid）は許可より優先される。
• ポリシーストアやポリシー、テンプレートの数、リクエストレートなどにはアカウント・リージョン単位のクォータがある。一部は引き上げ申請が可能だが、固定のものもある。
• スキーマによる検証を有効にすると、定義されていない属性やアクションを参照するポリシーを作成時点で弾ける。
• ポリシーストアはリージョン単位のリソースとして作成する。

内部の仕組み

アプリケーションは認可が必要なタイミングで、主体・アクション・リソース・コンテキストをまとめて Verified Permissions に問い合わせます。サービスはポリシーストア内の Cedar ポリシーを評価し、Allow か Deny の判定を返します。アプリはその結果に従って処理を続行するか拒否します。

Cedar の評価は宣言的で順序に依存しません。まず許可ポリシー（permit）のいずれかにマッチするかを見て、加えて拒否ポリシー（forbid）にマッチしないかを確認します。許可が1つでもあり、拒否が1つもない場合にだけ最終結果が Allow となります。該当する許可がない、あるいは拒否が1つでも該当すれば結果は Deny です。この「拒否が最優先」という評価モデルにより、安全側に倒れた判定がしやすくなっています。

スキーマを定義しておくと、ポリシーがそのスキーマに整合しているかを作成時に検証でき、属性名の誤りや存在しないアクションの参照といった間違いを早期に発見できます。Cognito と統合する場合は、ユーザープールが発行したトークンに含まれるクレームを主体や属性として取り込み、ABAC 的な判定に利用できます。

設計パターン / ベストプラクティス

• ポリシーストアはアプリケーション単位で分け、複数アプリの認可ルールを混在させない。
• 共通の権限パターンはポリシーテンプレートにまとめ、主体やリソースをプレースホルダ化して再利用する。
• スキーマを定義して検証を有効にし、属性やアクションのタイプミスをポリシー作成時点で検出する。
• ロールベースで足りる部分は RBAC で表現し、リソース属性やコンテキストに依存する判定は ABAC として書き分ける。
• 認可判定はアプリ起動時にまとめて行うのではなく、操作の直前にその都度問い合わせて最新のポリシーを反映させる。
• Cognito を認証に使う場合は、トークンのクレームを主体属性へマッピングし、認証と認可の責務を明確に分離する。

運用・監視

• CloudTrail でポリシーの作成・更新・削除といった管理操作を記録し、認可ルールの変更を追跡する。
• ポリシーの変更はアプリのデプロイから切り離せるため、認可ルールの修正をコードリリースと独立して運用できる。
• スキーマ検証を活用し、ポリシー変更時に整合性を自動チェックする運用を組み込む。
• 認可結果は判定理由（どのポリシーが効いたか）とともに取得できるため、想定外の拒否や許可のトラブルシュートに役立てる。

コスト

Verified Permissions の料金は、おおむね認可リクエストの件数に応じた従量課金が基本です。ポリシーストアを保持していること自体よりも、IsAuthorized などの認可判定をどれだけ呼び出すかが費用に影響します。バッチ API でまとめて判定すると、リクエストの組み立てや往復を効率化できる場合があります。

正確な料金体系や無料枠の有無は変動するため、設計時には公式の料金ページで最新の内容を確認してください。アプリの操作ごとに認可問い合わせを行う設計では、判定回数が利用パターンに比例して増える点を見込んでおくとよいでしょう。

セキュリティ

• 認可ロジックを一箇所に集約することで、権限チェックの抜け漏れや不整合を減らせる。
• Cedar の拒否優先モデルにより、明示的に許可していない操作は既定で拒否され、安全側に倒しやすい。
• スキーマによる検証で、誤ったポリシーがそのまま本番に入り込むリスクを下げられる。
• ポリシーの変更操作は CloudTrail で監査でき、誰がいつ認可ルールを変えたかを追跡できる。
• 認証は Cognito などに委ね、信頼できるトークンのクレームだけを認可判定の入力として扱う。

関連サービス・比較

認証認可という観点では Amazon Cognito と混同されがちですが、両者は担う役割が異なります。Cognito が「誰であるか」を確立する認証を担うのに対し、Verified Permissions は「何をしてよいか」という認可を担い、両者を組み合わせて使えます。

実際のアプリでは Cognito でユーザーを認証し、その結果を Verified Permissions に渡してきめ細かい認可を行う、という組み合わせが基本形になります。

ハンズオン / CLI例

CLI で検証なしのポリシーストアを作成し、そこへ静的な Cedar ポリシーを登録する例です。

# ポリシーストアを作成し、ストア ID を取得する
aws verifiedpermissions create-policy-store \
  --validation-settings mode=OFF \
  --query 'policyStoreId' \
  --output text

# 取得したストア ID に対して静的な許可ポリシーを作成する
aws verifiedpermissions create-policy \
  --policy-store-id <POLICY_STORE_ID> \
  --definition '{
    "static": {
      "description": "allow read for everyone",
      "statement": "permit(principal, action == Action::\"read\", resource);"
    }
  }'