![[レポート]Amazon Verified Permissionsで認可ロジックを短期間で実装する #AWSreInforce #IAM306](https://images.ctfassets.net/ct0aopd36mqt/6vZd9zWZvlqOEDztYoZCro/7349aaad8d597f1c84ffd519d0968d43/eyecatch_awsreinforce2025_1200x630-crunch.png)
[レポート]Amazon Verified Permissionsで認可ロジックを短期間で実装する #AWSreInforce #IAM306
2025.06.19はじめに
こんにちは、コンサルティング部の神野です。
AWS re:Inforce 2025に参加し、Amazon Verified Permissionsに関するNew Launchセッションを受講してきました。
前日にリリースされたばかりの新機能について早速やってみたブログを書いていたのですが、
このセッションではその実装の背景や設計思想について深く学ぶことができました。
実際に手を動かしてみたい方は、AWS Blogsや下記ブログをご覧いただくと、より理解が深まると思います。
本記事では、セッションで学んだ内容のうち、
特にやってみたブログでは触れられなかった認可の課題やCedarの設計思想、
そしてExpress.js統合について詳しくレポートします。
セッション概要
タイトル: IAM306-NEW: Implement app authorization in minutes with Amazon Verified Permissions
日時: 2025年6月18日（水）16:00-17:00 EDT
場所: Pennsylvania CC | 400 Level | Terrace Ballroom I
レベル: 300 - Advanced
トラック: Identity and Access Management
概要:
Discover how Amazon Verified Permissions simplifies authorization for applications. Learn how Verified Permissions offers centralized policy management, simplifies auditing, and eliminates operational overhead for authorization at scale. This session introduces the verified-permissions-express-toolkit, an open-source package that helps organizations externalize authorization logic, improving security and reducing code complexity. We'll demonstrate implementing common authorization patterns, such as role-based and attribute-based access control. Join us to learn how to secure applications and APIs built on the Express.js framework in just five steps using Cedar policies and the new Express.js integration. Walk away with actionable knowledge to implement fine-grained permissions in your applications.
認可の課題と重要性
セッションは、開発者が新しいアプリケーションを開発する際の認可実装の課題から始まりました。
スピーカーのManuel氏は、シンプルなif-else文から始まる認可ロジックが、時間とともに複雑化していく様子を実際のコード例で示しました。
最初は「本の所有者だけがアクセスできる」というシンプルなルールから始まり、管理者の例外処理、MFA認証の確認、パブリックブックの処理など、次々と条件が追加されていきます。
この複雑化により、ビジネスロジックよりも認可ロジックの方が画面を占めるようになり、開発者の生産性が低下していくという問題を指摘していました。
確かに認可ロジックはどんどん要件が膨らんで複雑化する印象はあるので納得です。
さらに重要なのは、CWE（Common Weakness Enumeration）のトップ25の脆弱性のすべてが、
認可ルールの管理と適用に関連しているという事実です。OWASP Top 10でも、Broken Access Controlが第1位の脆弱性として挙げられています。
これらの課題を解決するために、より良い方法が必要とされていました。
認可の進化：認証と同じ道を辿る
興味深い視点として、認証（Authentication）の歴史が紹介されました。かつてはアプリケーション内でユーザーテーブルを管理し、パスワードのハッシュ化、セッション管理、パスワードリセットメールの送信などをすべて自前で実装していました。
しかし現在では、これらの機能は外部のアイデンティティプロバイダー（Amazon Cognitoなど）に委譲し、OpenID ConnectやSAMLなどの標準プロトコルで連携するのが一般的です。
「同じことを認可でもできないか？」という問いかけが、Amazon Verified Permissionsの開発につながったそうです。
Cedar言語の紹介
次にAmazon Verified Permissionsで使用するCedar（シーダーと発音していました）言語の紹介が行われました。
Cedarは、AWSが開発した認可専用の言語で、以下の4つの設計原則に基づいています。
- 表現力：IAMポリシーの表現力を持ちながら、アプリケーション認可に必要な機能を提供
- パフォーマンス：Rustで実装され、速度とスケーラビリティを重視
- 分析可能性：自動推論による最適化とセキュリティモデルの検証が可能
- 人間が読みやすい（Human Readable）：直感的で理解しやすい構文
Cedar言語は下記のように記載します。
このポリシーは「管理者グループに属し、アカウントがアクティブで、petcare部門のユーザーは、petsコレクションに対してcreateとreadアクションを実行できる」という意味です。Cedarを初めて見る人でも理解できる読みやすさが特徴です。
確かにパッと見で何を許可しているのか分かりやすいですね。
Amazon Verified Permissionsの仕組み
Amazon Verified Permissionsは、Cedarポリシー言語をベースとしたマネージドな認可サービスです。セッションでは、このサービスがどのように動作し、従来のアプローチとどう違うのかが詳しく説明されました。
上図は、Amazon Verified Permissionsの基本的な動作フローを示しています。アプリケーションやAPI Gatewayから認可リクエストが送られ、Amazon Verified Permissionsが中央でポリシー評価を行い、許可/拒否の判定を返すという仕組みです。右側のAWS Management Consoleからは、ポリシーの管理やテストが行えます。
Manuel氏の説明によると、このアプローチにより「fine-grained authorization」（きめ細かい認可）をアプリケーションに組み込むことができるとのことでした。
この図は「Hosted service for policy evaluation & management」というタイトルで、Amazon Verified Permissionsの中核的な価値を表しています。複数のアプリケーションからAPIを呼び出し、Policy Storeに格納されたポリシーに基づいて認可判定を行う構造です。
セッションで強調されていたのは、これがマネージドサービスであることの価値です。可用性やスケーラビリティはAWSが保証し、すべての認可判定はCloudTrailに自動的にログが記録されるため、監査やコンプライアンス要件にも対応できます。
Amazon Verified Permissionsの構成要素
Amazon Verified Permissionsの主要な構成要素は以下の通りです。
- Policy Store: Cedarポリシーを格納するコンテナ。Manuel氏は「コンテナ」という表現を使って、アプリケーションで使用するすべてのポリシーを一元管理する場所だと説明していました
- ポリシー: Cedarで記述された認可ルール
- スキーマ: エンティティとアクションの定義。これにより型安全性と検証が可能になります
- Identity Source: CognitoなどのIDプロバイダーとの連携設定
サンプルアーキテクチャ
Amazon Verifed Permissionsを使用する前のアーキテクチャ
Amazon Verifed Permissionsを使用するアーキテクチャ
セッションでは、Pet Storeアプリケーションを例に具体的なアーキテクチャが紹介されました。この図は従来のアプローチを示しており、ユーザーがAmazon Cognitoで認証を行い、Lambda AuthorizerでIDトークンを検証し、アプリケーション内で認可ロジックを実行する流れです。
Amazon Verified Permissionsを導入することで、この認可ロジックを外部化し、Policy Storeで一元管理できるようになります。アプリケーションはAPIを呼び出すだけで、リアルタイムでポリシーが反映される仕組みに変わります。
認可はAmazon Verifed Permissionsにお任せして、アプリケーションコードから独立するのは魅力の1つのように感じました。
今までの作りだと認可ロジックを修正→ビルド再→デプロイのようなプロセスを挟む形でしたが、Amazon Verifed Permissionsを使用することでリアルタイムでコンソールやAPIから権限を変更できるのは嬉しいですね。
Express.js統合の詳細
やってみたブログでは実装手順を中心に紹介しましたが、セッションではより技術的な詳細が説明されました。
新しい@verifiedpermissions/authorization-clients-jsパッケージにより、従来のカスタム統合と比較して最大90%のコード削減が可能になると謳っていました。これは以下の機能により実現されています。
-
OpenAPIスキーマからの自動生成
- APIの定義から自動的にCedarスキーマを生成
- エンドポイントとアクションの自動マッピング
-
Express.jsミドルウェアの提供
- わずか数行のコードで統合可能
- リクエストの自動解析と認可判定
-
トークンベースの認証との連携
- CognitoのIDトークンから自動的にプリンシパル情報を抽出
- グループ情報の自動マッピング
セッションでは、Pet Storeアプリケーションを使った詳細なデモが行われました。
特に印象的だったのは、ポリシーの変更がリアルタイムで反映される様子です。アプリケーションの再デプロイなしに、管理者がポリシーを更新するだけで、即座にアクセス制御が変更されることが実演されました。
まさにやってみたブログで書いたような内容をデモで行っていました。
まとめ
このセッションを通じて、認可の外部化が単なる技術的なトレンドではなく、セキュリティ、開発効率、運用の観点から必然的な進化であることを学びました。
特に印象的だったのは下記となります。
- 認証の歴史から学ぶアプローチ
- Cedarの設計思想の明確さ
- Express.js統合による実装の簡単さ
実務では、マイクロサービスアーキテクチャにおける認可の一元管理や、
複雑なアクセス制御要件を持つアプリケーションでの活用が期待できます。また、開発チームと運用チームの責任分界点を明確にできる点も大きなメリットだと感じました。
Amazon Verified PermissionsとExpress.jsの統合は、まだリリースされたばかりですが、今後他のフレームワークへの展開も期待されます。
今後も検証してブログを書いていければと思います！
本記事が少しでも参考になりましたら幸いです。
最後までご覧いただきありがとうございましたー！！
補足
分析ツールについて
書き起こしによると、セッションではCedar symbolic compilerやCedar analysis CLIといった分析ツールについても触れられていました。
これらのツールは下記特徴があります。
- ポリシーの数学的検証と最適化
- ポリシー変更の影響分析
- 冗長なポリシーや競合の検出
といった機能を提供し、ポリシーのリファクタリングおよび最小権限の原則の実現をサポートします。
AWS Blogsで紹介されているので、興味があればぜひご覧ください。
使いたい場合は下記レポジトリからご使用ください。
実際に私も使ってみて、ブログにしてみたいです！！
実装時の注意点
Express.jsツールキットはリリース直後のため、OpenAPIスキーマの修正やCedarスキーマ生成時の調整など、
一部手動での対応が必要な箇所があります。実際に試してみた詳細な実装手順については、以下のブログ記事で詳しく解説していますので、ご参照ください。
![[アップデート] Amazon Verified PermissionsのExpress.js統合ライブラリがリリース！ #AWSreInforce](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-a951551bb44e2ee0ebdc3f6ed498b0c7/c397779f512906cf878f2da7fd9e4cfc/amazon-verified-permissions)
