AWS のポリシー言語 Cedar を活用した高速かつスケーラブルな認可技術の探求 #phperkaigi / PHPerKaigi 2025

PHPerKaigi 2025 で使用したスライドです。

Web アプリケーションのセキュリティ設計において、特定のユーザーに対してどの操作を許可するかという認可の設計は欠かせない要素です。近年では、マイクロサービスやゼロトラストの考え方が普及し、サーバー間の認可を含むより複雑な機能が求められています。

このような複雑な認可を効果的に管理する方法の一つとして、認可ロジックをアプリケーションから分離し、外部化して再利用可能なポリシー言語で定義する手法があります。AWS IAM はこのようなポリシー言語の一例ですが、AWS に限定されない一般用途にも Open Policy Agent (OPA) が広く知られています。

本セッションでは、認可の課題に対する新たなキラーソリューションとして、Cedar を紹介します。Cedar は AWS によって開発されたポリシー言語で、Amazon Verified Permissions としてマネージドサービスが提供されているほか、AWS 以外の環境でも使用可能な OSS としても公開されています。

OPA と比較した Cedar の顕著な特徴は、大量のルールを定義した場合のパフォーマンスにあります。このパフォーマンスは、一度評価された条件を部分的にキャッシュし再利用する仕組みにより実現されており、そのキャッシュ戦略の正当性は数学的に厳密に証明されています。このように、Cedarは高度な理論が実際のプロダクトに価値を提供する興味深い事例といえるでしょう。

Cedar は 2024 年に論文が発表されたばかりであり、理論的な詳細に関する日本語情報はほとんど存在しません。そのため、本セッションでは参加者が認可エンジンの内部機構と特性を深く理解し、実際のアプリケーションのセキュリティ設計に役立てられることを目指して、Cedar に対して応用と理論の両面から Deep Dive します。

プロポーザル：https://fortee.jp/phperkaigi-2025/proposal/f1d9f83e-790a-41be-a0e9-3a8a47cc164f

Transcript

1. AWS のポリシー言語 Cedar を 活用した高速かつスケーラブルな 認可技術の探求 #phperkaigi チェシャ猫 (@y_taka_23) PHPerKaigi 2025 22nd Mar. 2025
2. バックエンド書いてる人？
3. セキュリティとか CCoE 系の人？
4. 計算機科学の理論面が好きな人？
5. 目次 • ポリシー言語入門 ◦ そもそもポリシー言語とはどのようなものか • Cedar によるポリシー記述 ◦ どのような機能があり、どのように使えるのか • 理論面から見た Cedar ◦ 安全性の保証にはどのような理論が利用されているか
6. Cedar: A New Language for Expressive, Fast, Safe, and Analyzable Authorization J. W. Cutler et al. (OOPSLA 2024) https://doi.org/10.1145/3649835
7. ポリシー言語入門 1. Hello, Policy Languages!
8. マイクロサービスに対する認可 • アプリ開発チームの苦労 ◦ 似たような判定を各チームが各言語で実装 ◦ 実装は別なのに、概念として一貫していないと動かない • セキュリティ / CCoE チームの苦労 ◦ セキュリティ統制的に共通のガードレールを敷きたい ◦ 実装は別なので、ルールに対する合致を監査できない
9. 本日の主役「P ? P」
10. PDP と PEP • Policy Decision Point (PDP) ◦ ポリシー言語に基づきアクセス要求を評価 ◦ 許可（Allow）または拒否（Deny）を判断 • Policy Enforcement Point (PEP) ◦ PDP に判断を仰いで実際のアクセス制御を行う ◦ Web アプリでは API Gateway やバックエンド実装
11. ポリシー言語、見たことあるはず
12. AWS Identity and Access Management (IAM) https://aws.amazon.com/jp/iam
13. ポリシー言語としての IAM • IAM も PDP の一種とみなせる ◦ PEP は各種 AWS サービス、操作対象は AWS リソース ◦ Principal / Action / Resource / Condition で指定 • 複数チームがポリシーを定義しても最終結果は安全側 ◦ Deny が一つでもあれば Allow より優先 ◦ ポリシーの順番や重複で結果が変わらない
14. { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["ec2:TerminateInstances"], "Resource": ["*"], "Condition": { "IpAddress": { "aws:SourceIp": ["192.0.2.0/24"] } } } ] }
15. { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["ec2:TerminateInstances"], "Resource": ["*"], "Condition": { "IpAddress": { "aws:SourceIp": ["192.0.2.0/24"] } } } ] } AWS 特化
16. これをアプリ内部の認可にも使いたい
17. Cedar Policy Language https://github.com/cedar-policy
18. Cedar が目指す立ち位置 • 表現力が高い ◦ RBAC と ABAC を組み合わせて設計できる • パフォーマンスが高い ◦ 高速で、ポリシー数に対して速度が劣化しづらい • ポリシーの意味が理解しやすい ◦ 人間にとってはもちろん、自動解析の基礎も整っている
19. Amazon Verified Permissions • AWS マネージド版の Cedar エンジン ◦ PDP は単一障害点なので管理したくない ◦ PHP 含め各言語の SDK でアクセス可 • Amazon Cognito とも連携可能 ◦ 認証：Cognito User Pool ◦ 認可：Verified Permissions https://aws.amazon.com/jp/verified-permissions/
20. API Gateway を PEP とするパターン DynamoDB Authorizer API Gateway Verified Permissions Cognito User Application Allow / Deny User Pool 連携
21. バックエンドを PEP とするパターン DynamoDB Authorizer API Gateway Verified Permissions Cognito User Application Allow / Deny User Pool 連携 Entity 情報
22. その他の OSS ポリシー言語 • Open Policy Agent (OPA) ◦ おそらく最も有名で広く使われている ◦ Prolog ベースの Rego 言語による記述 • OpenFGA ◦ Google の認可基盤 Zanzibar がベース ◦ エンティティ間のグラフ構造による記述 https://github.com/open-policy-agent https://github.com/openfga
23. Section 1 のまとめ • PDP と PEP の分離 ◦ 認可処理を直接アプリに密結合したくない ◦ アプリとは分離して専用のポリシー言語で記述 • OSS ポリシー言語 Cedar ◦ マネージド版が Verified Permissions として利用可 ◦ 表現力 / パフォーマンス / 解析可能性
24. Cedar によるポリシー記述 2. Defining Policies in Cedar
25. 例：写真共有アプリの認可 • ユーザの写真に対する操作を許可または禁止したい ◦ ユーザが所属するグループに対して許可 ◦ 写真が所属するアルバムに対して許可 ◦ 写真の所有者はデフォルトで許可 • ユーザは他のユーザに写真を共有できる ◦ 共有された側は、その写真に限って閲覧許可
26. Any photo01.jpg photo02.jpg album01 team01 alice bob Request = ( alice, viewPhoto, photo01.jpg ) owner
27. Cedar によるポリシー記述 • 効果は permit（許可）/ forbid（拒否） ◦ 複数該当する場合は forbid が優先される • エンティティの三つ組を基本としてルールを記述 ◦ Principal：alice が（操作主体） ◦ Action：写真を閲覧する（操作内容） ◦ Resource：photo01.png を（操作対象）
28. permit ( principal == PhotoApp::User::"alice", action == PhotoApp::Action::"viewPhoto", resource == PhotoApp::Photo::"photo01.jpg" ); forbid ( principal == PhotoApp::User::"bob", action == PhotoApp::Action::"viewPhoto", resource == PhotoApp::Photo::"photo02.jpg" ); 基本となるポリシー
29. permit ( principal == PhotoApp::User::"alice", action == PhotoApp::Action::"viewPhoto", resource == PhotoApp::Photo::"photo01.jpg" ); forbid ( principal == PhotoApp::User::"bob", action == PhotoApp::Action::"viewPhoto", resource == PhotoApp::Photo::"photo02.jpg" ); 基本となるポリシー alice は photo01.jpg を閲覧できる
30. permit ( principal == PhotoApp::User::"alice", action == PhotoApp::Action::"viewPhoto", resource == PhotoApp::Photo::"photo01.jpg" ); forbid ( principal == PhotoApp::User::"bob", action == PhotoApp::Action::"viewPhoto", resource == PhotoApp::Photo::"photo02.jpg" ); 基本となるポリシー bob は photo02.jpg を閲覧できない
31. Cedar による RBAC • Role-Based Access Control (RBAC) ◦ Principal の所属関係に依存した判定 • Cedar では Principal に加え Resource もグループ化できる ◦ Principal：グループ team01 のメンバが ◦ Action：写真を閲覧する ◦ Resource：アルバム album01 内の写真を
32. permit ( principal in PhotoApp::UserGroup::"team01", action == PhotoApp::Action::"viewPhoto", resource in PhotoApp::Album::"album01" ); RBAC によるポリシー
33. permit ( principal in PhotoApp::UserGroup::"team01", action == PhotoApp::Action::"viewPhoto", resource in PhotoApp::Album::"album01" ); RBAC によるポリシー team01 に含まれる任意の principal album01 に含まれる任意の resource
34. Cedar による ABAC • Attribute-Based Access Control (ABAC) ◦ エンティティの持つ属性に依存した判定 • Cedar では自由に属性が定義できる ◦ Principal：誰でも ◦ Action：写真を閲覧する ◦ Resource：自分が所有する（owner）写真を
35. permit ( principal, action == PhotoApp::Action::"viewPhoto", resource ) when { resource has owner && resource.owner == principal }; ABAC によるポリシー
36. permit ( principal, action == PhotoApp::Action::"viewPhoto", resource ) when { resource has owner && resource.owner == principal }; ABAC によるポリシー 指定がない = ワイルドカード
37. permit ( principal, action == PhotoApp::Action::"viewPhoto", resource ) when { resource has owner && resource.owner == principal }; ABAC によるポリシー 属性 owner による指定
38. 動的なポリシー生成 • アプリの機能として動的にポリシーを生成したい ◦ 例：写真をシェアした相手に閲覧権限を付与 • テンプレートからの生成が可能、変更時も追従してくれる ◦ Principal：ユーザ〇〇が ◦ Action：写真を閲覧する ◦ Resource：写真〇〇を
39. permit ( principal == ?principal, action == PhotoApp::Action::"viewPhoto", resource == ?resource ); ポリシーテンプレート
40. permit ( principal == ?principal, action == PhotoApp::Action::"viewPhoto", resource == ?resource ); ポリシーテンプレート API を叩いて動的に ポリシーをインスタンス化
41. セキュリティ系は記述ミスが怖い
42. Schema によるバリデーション • 記述言語としての汎用性はエラーの温床 ◦ エンティティ名も属性名もユーザ定義 ◦ Undefined 属性を参照すると意図しない結果を招く • Cedar は組み込みのバリデーション機能をサポート ◦ ポリシー自体とは別に Schema を定義できる ◦ 違反したポリシーは登録時に弾かれる
43. "Photo": { "shape": { "type": "Record", "attributes": { "owner": { "type": "Entity", "name": "User", "required": true } } }, "memberOfTypes": ["Album"] }
44. 内部の動作はどうなっているのか？
45. ポリシー判定の流れ 1. リクエストとエンティティを受け取る 2. ポリシー全体の内、そのリクエストとエンティティに対し 該当するものを全てリストアップする 3. リストアップされたものを permit と forbid に分ける 4. permit 組が空集合でなく、forbid 組が空集合なら Allow 5. それ以外なら Deny
46. 全部のポリシーを判定していると遅い
47. Slice 処理の流れ 1. 予め Principal + Resource をキーとしてポリシーを保持 2. リクエストが来たら、その Principal と Resource から 遡れる祖先要素をそれぞれ求める 3. Principle と Resource たちの全ての組合せを求める 4. ポリシーの中で最終結果に影響するのは、 ここで求めた組合せをキーとするポリシーのみ
48. Any photo01.jpg photo02.jpg album01 team01 alice bob Request = ( alice, viewPhoto, photo01.jpg ) owner
49. Any photo01.jpg photo02.jpg album01 team01 alice bob Request = ( alice, viewPhoto, photo01.jpg ) owner alice の祖先 photo01.png の祖先
50. Principal Resource Any Any Any album01 Any photo01.jpg team01 Any team01 album01 team01 photo01.jpg alice Any alice album01 alice photo01.jpg Slice の絞り込み Key Principal Resource Effect Any photo02.png permit team01 album01 permit alice album01 permit bob album01 permit alice photo02.jpg permit bob photo02.jpg permit alice photo02.jpg forbid team01 photo01.jpg forbid bob photo01.png forbid 定義されている全 Policy
51. Principal Resource Any Any Any album01 Any photo01.jpg team01 Any team01 album01 team01 photo01.jpg alice Any alice album01 alice photo01.jpg Slice の絞り込み Key Principal Resource Effect Any photo02.png permit team01 album01 permit alice album01 permit bob album01 permit alice photo02.jpg permit bob photo02.jpg permit alice photo02.jpg forbid team01 photo01.jpg forbid bob photo01.png forbid Slice で絞り込まれた Policy
52. Principal Resource Any Any Any album01 Any photo01.jpg team01 Any team01 album01 team01 photo01.jpg alice Any alice album01 alice photo01.jpg Slice の絞り込み Key Principal Resource Effect Any photo02.png permit team01 album01 permit alice album01 permit bob album01 permit alice photo02.jpg permit bob photo02.jpg permit alice photo02.jpg forbid team01 photo01.jpg forbid bob photo01.png forbid forbid に該当するので結果は拒否
53. パフォーマンスの比較 • Cedar > OpenFAG >> Rego • 特に Rego に比べ、Cedar はエンティティ数で速度劣化しない https://doi.org/10.1145/3649835
54. Slice による最適化 • テンプレートからのポリシー生成を行う場合に強い ◦ 生成で増えた分のポリシーは Slice で効果的に振り落とせる https://doi.org/10.1145/3649835
55. Section 2 のまとめ • Cedar によるポリシー記述 ◦ Principal / Action / Resource で条件を指定 ◦ RBAC / ABAC / 動的なポリシー生成 • パフォーマンス上の特性 ◦ OpenFGA や Rego より高速でスケールに強い ◦ テンプレートポリシーに対して Slice が有効
56. 理論から見た Cedar 3. Theoretical Aspects of Cedar
57. 言語仕様と信頼性 • 自然言語で書かれた仕様書による定義 ◦ C++ / Java / PHP など大多数の言語が採用 ◦ 曖昧性や矛盾の発見は人間の観察力頼み • 形式的意味論による定義 ◦ 言語の動作について厳密な数学的ルールを提供 ◦ アルゴリズムにより自動化された確実な検査が可能
58. Cedar の形式的意味論 • ポリシーの評価規則 ◦ Alloy / Deny を判定する上で、対象のリクエストが ポリシーの条件に合致するかどうかを定義 • ポリシーの型付け規則（今日は省略） ◦ Schema によるバリデーションの実体は型検査 ◦ capability と呼ばれる付帯条件付きの型付けを定義
59. どんな風に「意味」を記述するのか？
60. https://doi.org/10.1145/3649835
61. なるほどわからん
62. 【書き換え規則】 エンティティが μ、リクエストが σ であるとき 式 e を式 e’ に書き換えてよい
63. e = resource in PhotoApp::Album::"album01" σ = [ principal => PhotoApp::User::"alice", action => PhotoApp::Action::"viewPhoto", resource => PhotoApp::Photo::"photo01.jpg" ] μ = [ PhotoApp::Photo::"photo01.jpg" => [ owner => PhotoApp::User::"alice", predecessors => { PhotoApp::Album::"album01" } ] ]
64. e = resource in PhotoApp::Album::"album01" σ = [ principal => PhotoApp::User::"alice", action => PhotoApp::Action::"viewPhoto", resource => PhotoApp::Photo::"photo01.jpg" ] μ = [ PhotoApp::Photo::"photo01.jpg" => [ owner => PhotoApp::User::"alice", predecessors => { PhotoApp::Album::"album01" } ] ] 祖先要素を保持
65. e = resource in PhotoApp::Album::"album01" σ = [ principal => PhotoApp::User::"alice", action => PhotoApp::Action::"viewPhoto", resource => PhotoApp::Photo::"photo01.jpg" ] μ = [ PhotoApp::Photo::"photo01.jpg" => [ owner => PhotoApp::User::"alice", predecessors => { PhotoApp::Album::"album01" } ] ] 書き換えたい式
66. σ = [ principal => PhotoApp::User::"alice", action => PhotoApp::Action::"viewPhoto", resource => PhotoApp::Photo::"photo01.jpg" ] x = principal / action / resource に対して リクエストの x が v であるとき、 目的の式内の x を v で書き換えてよい e'= PhotoApp::Photo::"photo01.jpg" in PhotoApp::Album::"album01" e = resource in PhotoApp::Album::"album01"
67. σ = [ principal => PhotoApp::User::"alice", action => PhotoApp::Action::"viewPhoto", resource => PhotoApp::Photo::"photo01.jpg" ] x = principal / action / resource に対して リクエストの x が v であるとき、 目的の式内の x を v で書き換えてよい e'= PhotoApp::Photo::"photo01.jpg" in PhotoApp::Album::"album01" e = resource in PhotoApp::Album::"album01" 前提条件
68. σ = [ principal => PhotoApp::User::"alice", action => PhotoApp::Action::"viewPhoto", resource => PhotoApp::Photo::"photo01.jpg" ] x = principal / action / resource に対して リクエストの x が v であるとき、 目的の式内の x を v で書き換えてよい e'= PhotoApp::Photo::"photo01.jpg" in PhotoApp::Album::"album01" e = resource in PhotoApp::Album::"album01" 可能な書き換え
69. σ = [ principal => PhotoApp::User::"alice", action => PhotoApp::Action::"viewPhoto", resource => PhotoApp::Photo::"photo01.jpg" ] x = principal / action / resource に対して リクエストの x が v であるとき、 目的の式内の x を v で書き換えてよい e'= PhotoApp::Photo::"photo01.jpg" in PhotoApp::Album::"album01" e = resource in PhotoApp::Album::"album01" x v
70. μ = [ PhotoApp::Photo::"photo01.jpg" => [ owner => PhotoApp::User::"alice", predecessors => { PhotoApp::Album::"album01" } ] ] エンティティ E1::s1 の先祖に E2::s2 が含まれるとき、 in 式は true に書き換えてよい e'= true e = PhotoApp::Photo::"photo01.jpg" in PhotoApp::Album::"album01"
71. μ = [ PhotoApp::Photo::"photo01.jpg" => [ owner => PhotoApp::User::"alice", predecessors => { PhotoApp::Album::"album01" } ] ] エンティティ E1::s1 の先祖に E2::s2 が含まれるとき、 in 式は true に書き換えてよい e'= true e = PhotoApp::Photo::"photo01.jpg" in PhotoApp::Album::"album01" h1 E1::s1 E2::s2
72. 人間、どこかで間違える
73. Lean Theorem Prover https://github.com/leanprover
74. Lean による意味論の検証 • 定理証明支援系と呼ばれるツールの一種 ◦ いわば「証明付きの関数型言語」 • 型に乗せられる情報量が非常に多い ◦ 数学的な命題を型で表現し、コンパイル時にチェック ◦ 命題 P の証明を受け取って、別の命題 Q の証明を返す といった「関数」が定義できる
75. 例：forbid がひとつでもあれば拒否 theorem forbid_trumps_permit (request : Request) (entities : Entities) (policies : Policies) : (∃ (policy : Policy), policy ∈ policies ∧ policy.effect = .forbid ∧ satisfied policy request entities ) → (isAuthorized request entities policies).decision = .deny
76. 証明されている Cedar の性質 • forbid が一つでもあれば他に permit があっても拒否 • 許可されるのは permit が一つでもある場合のみ • ポリシーの重複や順序は結果に影響しない • Slice によるポリシーの絞り込みは結果に影響しない • バリデーションを通ったポリシーは評価時にエラーが起きない
77. Section 3 のまとめ • 言語の意味論は厳密に定義できる ◦ 各規則は式の書き換えルールを与えている • 論文中では Cedar の意味論が与えられている ◦ ポリシーの評価 / 型付けによるバリデーション • Cedar の意味論は Lean を用いて検証されている ◦ コンパイルが通っていれば証明として正しい
78. まとめ 4. Today’s Recap
79. 本日のまとめ • マイクロサービスでのポリシー言語の役割 ◦ 認可（PDP）をアプリ（PEP）から分離 • Cedar / Amazon Verified Permissions の機能 ◦ RBAC / ABAC / テンプレート / バリデーション • 安全性が理論的に保証されている ◦ 形式的意味論 / 定理証明支援系 Lean による証明
80. Implement Your Policies! Presented by チェシャ猫（@y_taka_23）