こんにちは、チェシャ猫です。
先日開催された PHPerKaigi 2025 で、AWS によって開発されたポリシー言語 Cedar およびそのマネージドサービス版である Amazon Verified Permissions について登壇してきました。公募 CFP 枠です。
学習リソース
もし、今回のトークを聞いて Cedar や Verified Permissions に興味を持った方がいたら、まずは公式で提供されているワークショップを触ってみることをお勧めします。ワークショップは以下の二種類があります。
前者は Cedar 自体の基本的な記法のみ扱うもので、Cedar の Playground を利用します。後者は AWS Lambda で作られたサンプルアプリと Verified Permissions を実際に AWS 上に構築して行うワークショップで、Cognito との連携やバッチリクエストによる最適化などを含む、より詳細な内容が学べます。若干の課金が必要にはなりますが、アプリケーションまで含めて動かせる後者のワークショップの方がお勧めです。
さらに、Cedar の設計の理論面についてより深く学びたい人は、元論文にもチャレンジしてみましょう。論文中では、今回のトークの中で紹介した式評価の意味論の他、バリデーションを支える型付けの健全性や、SMT エンコーディングも論じられています。
質問への回答
大変ありがたいことに、質疑応答や Ask The Speaker でいくつか質問を頂きました。ここにまとめておきます。
デフォルトが forbid であり、かつ forbid が permit に優先するということは、permit を指定した上でその中でピンポイントに forbid を指定するのか？
基本的にはその通りで、forbid が指定されるとそれを覆して許可することはできないため、forbid の範囲が広すぎると後から困ることになります。しかし、統一ポリシーを定義したいセキュリティチームの立場から見ると、これは逆に、forbid に指定した操作は個別のアプリチーム側では覆せないため確実な統制が可能になるという面もあります。
特に Cedar の場合、テンプレートからポリシーを動的に生成する用途が想定されています。つまりアプリチームがポリシーを作成できることは前提として織り込むべきであり、したがって「統制として確実に塞ぎたいところ」についてはセキュリティチーム側で予め forbid しておく、というのが基本的な考え方です。
有効期限付きの一時的な権限を表現する方法はあるか？
今回のスライドには含めませんでしたが、リクエストごとに変化するような条件を付与するための仕組みとして、Context が用意されています。
実際の使い方はアプリケーションの要件によりますが、例えば Resource に expires_at のような属性を持たせておき、リクエスト時の Context に現在時刻を載せて、ポリシーの when の中で比較することが可能です。
認証を Cognito 以外で行なっている場合、Verified Permissions を使用することはできるか？
はい、可能です。Verified Permissions は OpenID Connect (OICD) の ID プロバイダであれば Cognito に限らず連携することができます。また、トークンに含まれる claim は Cedar の属性としてマッピングされるため、ポリシーの中で参照することも可能です。
