Slide 1
Slide 1 text
AWSと定理証明
ポリシー言語 Cedar 開発の舞台裏
#fp_matsuri #fp_matsuri_a
チェシャ猫 (@y_taka_23)
関数型まつり 2025 (15th June 2025)
Slide 2
Slide 2 text
本日お話ししたいこと
● AWS で実際に使用されている定理証明
○ 世界でも有数の複雑な巨大 Web システム
○ さらに認可というクリティカルな分野
● どんな仕様が定理証明で保証されているのか
○ 教科書的な練習問題ではあまり実感できない
○ 実際の「使いどころ」を実感していただきたい
Slide 3
Slide 3 text
形式手法 in
クソデカ・リアルワールド Web システム
Slide 4
Slide 4 text
組織横断的な認可処理の課題
● アプリ開発チームの苦労
○ 似たような判定を各チームで再発明
○ 実装は別だが概念としては一貫している必要性
● セキュリティ / CCoE チームの苦労
○ セキュリティ統制的にガードレールを敷きたい
○ 実装は別なので統一したチェックが困難
Slide 5
Slide 5 text
PDP と PEP
● Policy Decision Point（PDP）
○ ポリシー言語に基づきアクセス要求を評価
○ 許可（Allow）または拒否（Deny）を判定
● Policy Enforcement Point（PEP）
○ PDP に判断を仰いで実際のアクセス制御を行う
○ Web アプリでは API Gateway やバックエンド実装
Slide 6
Slide 6 text
Cedar Policy Language
https://github.com/cedar-policy
Slide 7
Slide 7 text
Cedar: A new language for expressive,
fast, safe, and analyzable authorization
J. W. Cutler et al. (OOPSLA 2024)
How we built Cedar:
A verification-guided approach
C. Disselkoen et al. (FSE 2024)
https://doi.org/10.1145/3649835
https://doi.org/10.1145/3663529.3663854
Slide 8
Slide 8 text
例：写真共有アプリの認可
● ユーザの写真に対する操作を許可 / 禁止したい
● 所属関係による条件
○ ユーザが所属するグループに対して許可
○ 写真が所属するアルバムに対して許可
● 所属関係によらないアドホックな条件
○ 写真の所有者はデフォルトで許可
Slide 9
Slide 9 text
Cedar によるポリシー記述
● 効果は permit（許可）または forbid（禁止）
○ 複数該当する場合は forbid が優先
● 三つ組を基本としてルールを記述
○ Principal：alice が（操作の主体）
○ Action：写真を閲覧する（操作の内容）
○ Resource：photo01.jpg を（操作の対象）
Slide 10
Slide 10 text
ポリシーの基本形
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"
);
Slide 11
Slide 11 text
Amazon Verified Permissions
● AWS マネージド版の Cedar エンジン
○ PDP は単一障害点なので管理したくない
○ 各種言語の AWS SDK でアクセス可能
● Amazon Cognito とも連携可能
○ 認証：Cognito User Pool
○ 認可：AWS Verified Permissions
https://aws.amazon.com/jp/verified-permissions/
Slide 12
Slide 12 text
Lean Theorem Prover
https://github.com/leanprover
Slide 13
Slide 13 text
Lean による証明
● 定理証明支援系と呼ばれるツールの一種
○ いわば「証明付きの関数型言語」
● 型に乗せられる情報量が非常に多い
○ 数学的な命題を型で表し、コンパイル時に検査
○ 命題 P の証明を受け取って、それを使用して
別の命題 Q の証明を返すといった関数が定義できる
Slide 14
Slide 14 text
Cedar での Lean 利用規模
● Lean で 7,387 行、そのうち証明が 5,714 行（約 77 %）
● 他の定理証明プロジェクトと比較してコンパクト
○ CompCert：Coq 約 42,000 行
○ seL4：Isabelle 約 200,000 行
● 証明により発見された仕様バグ 4 件、実装バグ 21 件
● 現在進行形で新しい証明が追加されている
https://doi.org/10.1145/3663529.3663854
Slide 15
Slide 15 text
Cedar の設計方針
● 表現力：典型的なポリシー設計のユースケースをカバー
● 安全性：認可処理の正確性、ポリシー定義ミスの防止
● 応答速度：ポリシー数に対して速度劣化しづらい
● 解析可能性：人間だけでなく機械にとっても解釈しやすい
Slide 16
Slide 16 text
表現力
1.
Expressivity
Slide 17
Slide 17 text
RBAC と ABAC
● Role-Based Access Control (RBAC)
○ Principal の所属関係に基づく認可
○ Cedar では Resource もグループ化可能
● Attribute-Based Access Control (ABAC)
○ エンティティの属性（フィールド）に基づく認可
○ Cedar ではユーザが自由に属性を定義できる
Slide 18
Slide 18 text
RBAC 的なポリシー
permit (
principal in PhotoApp::UserGroup::"team01",
action == PhotoApp::Action::"viewPhoto",
resource in PhotoApp::Album::"album01"
);
Slide 19
Slide 19 text
ABAC 的なポリシー
permit (
principal,
action == PhotoApp::Action::"viewPhoto",
resource
)
when {
resource has owner &&
resource.owner == principal
};
Slide 20
Slide 20 text
どうやって判定結果を与えるのか？
Slide 21
Slide 21 text
【ポリシーの Small-step 操作的意味論】
エンティティが μ、リクエストが σ であるとき
式 e を式 e’ に書き換えてよい
Slide 22
Slide 22 text
Fig 6. https://doi.org/10.1145/3649835
Slide 23
Slide 23 text
評価規則の正しさを保証する上で
Slide 24
Slide 24 text
Lean Theorem Prover
https://github.com/leanprover
Slide 25
Slide 25 text
Lean で証明されている基本性質
● 判定手続きは無限ループにならず必ず停止する
● forbid は permit に優先し、両方あれば拒否が勝つ
● 許可されるならば明示的な permit が最低一つ存在
● 明示的な permit が存在しない場合、拒否される
● ポリシーの重複や順序は判定結果に影響を与えない
Slide 26
Slide 26 text
定理：拒否は許可に優先する
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
:= by
...
Slide 27
Slide 27 text
安全性
2.
Safety
Slide 28
Slide 28 text
スキーマによるバリデーション
● 記述言語としての汎用性はエラーの温床
○ エンティティ名も属性名もユーザ定義
○ Undefined 属性を参照すると予期せぬ結果を招く
● Cedar は組み込みのバリデーション機能をサポート
○ ポリシーとは別に JSON Schema を定義できる
○ 違反したポリシーは登録時に弾かれる
Slide 29
Slide 29 text
"Photo": {
"shape": {
"type": "Record",
"attributes": {
"owner": {
"type": "Entity",
"name": "User",
"required": true
}
}
},
"memberOfTypes": ["Album"]
}
Slide 30
Slide 30 text
バリデーションの正体は型検査
Slide 31
Slide 31 text
【ポリシーの型付け規則】
ケイパビリティが α の下で、
エンティティとリクエストの組が Γ であるとき、
式 e には型 τ とケイパビリティ ε が付く
Slide 32
Slide 32 text
ケイパビリティ？
Slide 33
Slide 33 text
Fig 7.(a) https://doi.org/10.1145/3649835
Slide 34
Slide 34 text
Fig 7.(a) https://doi.org/10.1145/3649835
ケイパビリティ {e.f} =
式が true に評価されるために
存在しなければならないフィールド
Slide 35
Slide 35 text
型システムの正しさを保証する上で
Slide 36
Slide 36 text
Lean Theorem Prover
https://github.com/leanprover
Slide 37
Slide 37 text
定理：型検査の健全性
theorem typecheck_is_sound
(policy : Policy) (env : Environment) (t : CedarType)
(request : Request) (entities : Entities) :
RequestAndEntitiesMatchEnvironment env request entities →
typecheck policy env = .ok t →
(∃ (b : Bool), EvaluatesTo policy.toExpr request entities b)
:= by
...
Slide 38
Slide 38 text
応答速度
3.
Latency
Slide 39
Slide 39 text
Slice によるパフォーマンス改善
● Policy Slice
○ リクエストに対して無関係なポリシーを除外
○ 判定に関わる (Principal, Resource) の組をキーに
● Level-based Entity Slice
○ ポリシーに対して無関係なエンティティを除外
○ フィールドを辿る必要がある深さを予め調べておく
Slide 40
Slide 40 text
他 OSS とのパフォーマンス比較
● Rego < OpenFAG << Cedar
● 特に Cedar はエンティティ数に対して速度劣化しづらい
Fig 14. https://doi.org/10.1145/3649835
Slide 41
Slide 41 text
最適化の正しさを保証する上で
Slide 42
Slide 42 text
Lean Theorem Prover
https://github.com/leanprover
Slide 43
Slide 43 text
定理：Policy Slice は認可判断を保つ
theorem isAuthorized_eq_for_sound_policy_slice
(req : Request) (entities : Entities)
(slice policies : Policies) :
IsSoundPolicySlice req entities slice policies →
isAuthorized req entities slice
= isAuthorized req entities policies
:= by
...
Slide 44
Slide 44 text
解析可能性
4.
Analyzability
Slide 45
Slide 45 text
Symbolic Compiler (ongoing)
● Allow / Deny とは別に、ポリシー自体の性質を検査
○ 例：ポリシー P1 と P2 はお互い等価か？
○ 例：ポリシー P1 はデッドコードか？
● SMT ソルバを利用して検査
○ ポリシーを SMT エンコーディング
○ 「P1 と P2 の結果が異なる」が SAT なら非等価
Slide 46
Slide 46 text
【SMT による表示的意味論】
エンティティを SMT 化したものが M、
リクエストを SMT 化したものが Γ のとき、
式 e は SMT 式 ê にエンコーディングされる
Slide 47
Slide 47 text
Fig 10. https://doi.org/10.1145/3649835
Slide 48
Slide 48 text
エンコードの正しさを保証する上で
Slide 49
Slide 49 text
Lean Theorem Prover
https://github.com/leanprover
Slide 50
Slide 50 text
Lean で証明されている性質
● 型検査を通ったポリシーは SMT エンコード可能
● φ :=「ê1 と ê2 の true / false が一致」と表すと、
以下の 2 条件は同値
○ エンティティ階層が有限 DAG かつ not φ が UNSAT
○ 任意の妥当なエンティティとリクエストに対して、
e1 と e2 の Allow / Deny 判定は常に一致
Slide 51
Slide 51 text
定理：SMT エンコードの健全性
theorem compile_is_sound {x : Expr} {env : Env}
{εnv : SymEnv} {t : Term.Outcome εnv} :
εnv.WellFormedFor x →
env.WellFormedFor x →
env ∈ᵢ εnv →
compile x εnv = .ok t →
∃ (o : Outcome Value),
o ∈ₒ t ∧
evaluate x env.request env.entities ∼ o
:= by
...
Slide 52
Slide 52 text
実システムを開発・運用する上で
Slide 53
Slide 53 text
Rust
https://github.com/rust-lang/rust
Slide 54
Slide 54 text
Lean じゃない！
Slide 55
Slide 55 text
Verification–Guided Development
● 実プロダクトとしての Cedar は Rust 製
○ Lean だけではエコシステムが貧弱
○ Rust だけでは検証のためのオーバヘッドが大きい
● Lean 7,387 行に対して Rust は 67,542 行もある
● Differential Random Test (DRT)
○ 両者に同じランダム入力を与え、結果を比較
Slide 56
Slide 56 text
DRT による CI フロー
リクエスト
+
エンティティ
+
ポリシー
証明済み実装
プロダクト実装
cargo-fuzz
Allow / Deny
Allow / Deny
一致？
Fail リリース
Pass
Slide 57
Slide 57 text
本日のまとめ
● Cedar は意味論が与えられたポリシー言語
○ 評価 / 型付け / SMT エンコーディング
○ 各種の性質は Lean で証明されている
● Lean と Rust との橋渡し
○ Cedar 自体の実装は Rust 製
○ Differential Random Testing で両者を比較
Slide 58
Slide 58 text
Implement Your Policies!
Presented By チェシャ猫 (@y_taka_23)