Cedar入門

Transcript

1. 2026年08月08日（土） Cedar入門 認可を「言語」にする 赤神 青空
2. ▪認可はどこに書かれているか ある日の実装 「このドキュメント、この人は編集していいんだっけ？」 の答えが、APIハンドラのif文の中にしかない。 所有者チェック doc.owner == user.id がハンドラごとに手書き 共有リストの参照 編集者リストの照合が、別の場所にもう1つ 共有機能が育つたび、同じ判定がコードのあちこちに散らばっていく。 今ココ はじめに 2/29
3. ▪散らばせるか、集約するか 認可ロジックの置き場所 ✕ コードに埋め込む 判定がハンドラごとに重複する 「今どんなルールか」を一覧できない 変更のたびに全箇所を探して直す ◯ ポリシーとして外に出す ルールが1箇所に宣言的に集まる コードと独立に監査・変更できる さらに「正しさ」を機械検証できる この右側を実現する言語が、今日の主役のCedarです。 今ココ はじめに 3/29
4. ▪Cedarが引き受けるのは後者だけ 前提：認証と認可は別物 この2つの区別が、今日の話ぜんぶの土台になる。 01 02 03 あなたは誰か。 Cognito・OAuthの仕事 あなたに何が許されるか。 ここがCedarの守備範囲 「誰か」は変わらないが 「何が許されるか」は頻繁に変わる 認証（AuthN） 今ココ はじめに 認可（AuthZ） 分ける理由 4/29
5. 01 Cedarとは 生まれと現在地 今ココ Cedarとは 5/29
6. ▪AWS生まれ、いまはCNCFのOSS Cedar＝認可ポリシー言語 認可の判定だけのために設計されたドメイン特化言語。 AWSが開発しOSS化（Apache 2.0）、Rust製で判定はミリ秒オーダー 採用サービスの「中の言語」でもある Amazon Verified Permissions（AVP） Amazon Bedrock AgentCore のPolicy CNCF（Kubernetesなどを預かる中立財団）に加入 ＝AWSが手を引いても残る言語になった 設計目標は「表現力・速度・安全性・解析可能性」の4点 今ココ Cedarとは 6/29
7. ▪共有ダイアログの正体 あなたは毎日「ポリシー」を書いている 共有：「企画書.docx」 あ あおい（⾃分） オーナー デ デザインチーム 閲覧者 ひ ひかる 編集者 ⾒慣れたあの画⾯。実はこれが… permit (principal == User::"aoi", action, // ぜんぶ resource == Doc::"企画書"); permit (principal in Group::"design", action == Action::"viewDoc", resource == Doc::"企画書"); permit (principal == User::"hikaru", action in [viewDoc, editDoc], resource == Doc::"企画書"); …認可ポリシーの集合そのもの 共有設定の1行1行が、そのまま認可ポリシー1本1本に対応する 今ココ Cedarとは 7/29
8. ▪認可の問いを4要素に分解する PARCモデル Cedarのポリシーは、すべてこの4つの語彙で書かれる。 P A R C 誰が。 User::"hikaru" など 何をする。 Action::"editDoc" など 何に対して。 Doc::"企画書" など どんな状況で。 リンク共有経由・時刻など Principal 今ココ Cedarとは Action Resource Context 8/29
9. ▪アプリは「尋ねる」だけ 判定のしくみ 認可リクエスト P：誰が ポリシー集合 permit / forbid たち Allow User::"hikaru" A：何をする Action::"editDoc" 認可エンジン R：何に対して Doc::"企画書" C：どんな状況で Cedar 許可（permitに合致） { via: "リンク共有" } Deny 拒否（既定値‧forbid） PARCの4つ組を渡すと、ポリシー集合に照らして Allow / Deny が返る 今ココ Cedarとは 9/29
10. ▪permitの3点セット 最小のポリシー 「ひかるは、企画書を、閲覧してよい」をそのまま書く。 rust permit ( principal == User::"hikaru", action resource == Action::"viewDoc", == Document::"企画書" ); 今ココ Cedarとは 10/29
11. 02 書いてみる RBAC・ABAC・評価規則 今ココ 書いてみる 11/29
12. ▪認可の書き方の二大流派 RBAC と ABAC RBAC（役割ベース） 「役割」で許可を決める 例：編集者グループなら編集できる 分かりやすいが、例外が増えると 役割が無限に増殖する ABAC（属性ベース） 「属性」の条件式で決める 例：文書の所有者本人なら削除できる 役割を増やさず例外を表現できるが 条件が読み解きにくくなる Cedarはどちらも同じ文法で書けて、混ぜられる。これが強み。 今ココ 書いてみる 12/29
13. ▪in がメンバーシップを表す RBAC：グループで許可する 「デザインチームの全員が、企画書を閲覧・コメントできる」。 rust permit ( principal in Group::"design-team", action in [Action::"viewDoc", Action::"commentDoc"], resource == Document::"企画書" ); 今ココ 書いてみる 13/29
14. ▪when句が条件を受け持つ ABAC：属性で絞る 「所有者本人だけが、削除できる」。 役割を新設せず、属性の比較だけで例外を表す。 rust permit ( principal, action == Action::"deleteDoc", resource ) when { resource.owner == principal }; 今ココ 書いてみる 14/29
15. ▪この潔さがCedarの安全性の核 評価規則は2行で言える デフォルトは拒否。 そして forbid は permit に必ず勝つ。 書き忘れ＝拒否 permitを書かない限り、何も許可されない 例外は上書き不能 「アーカイブ済みは編集禁止」をforbid1本で保証できる 「うっかり許可」が構造的に起きにくいように言語が設計されている。 今ココ 書いてみる 15/29
16. ▪横断的な禁止事項を1本で forbidの使いどころ どれだけ共有されていても、この1本がアーカイブ済み文書の編集を止める。 rust forbid ( principal, action == Action::"editDoc", resource ) when { resource.archived == true }; 今ココ 書いてみる 16/29
17. ▪切り出した代償を、宣言で払い戻す スキーマ：型チェックを取り戻す 外に出したポリシーは、放っておくとただの文字列。 owner を ownerId と書き間違えても、誰も怒ってくれない。 rust entity User in [Group]; entity Document in [Folder] { owner: User, archived: Bool // ← 階層はここで宣言 // ← 属性の型もここで }; action editDoc appliesTo { principal: User, resource: Document }; この宣言があるから、次の階層ポリシーが書けて、後半の形式検証も動く 今ココ 書いてみる 17/29
18. ▪グループ階層で「まとめて」許可する × フォルダ Group::"design-team" Folder::"proposals" User::"aoi" Doc::"企画書" User::"hikaru" User::"sora" ほか計6⼈ principal in で全員を指す × 6⼈ × 3件 Doc::"⾒積書" Doc::"議事録" resource in で配下すべてを指す 18通りの許可が、この1本に畳み込まれる permit (principal in Group::"design-team", action == Action::"viewDoc", resource in Folder::"proposals"); 「フォルダごとチームに共有」も、in を2箇所使うだけで表せる 今ココ 書いてみる 18/29
19. ▪テンプレート＝動的な許可付与のしくみ 許可は、実行中に増えたり減ったりする ここまではあらかじめ書いておくルールの話だった。 でも共有ボタンは、ユーザーが押した瞬間に許可を1本増やしている。 穴あきポリシー（?principal / ?resource）を用意しておく 共有ボタン＝穴に値を差して、ポリシーを1本生成 共有解除＝生成したその1本を消す なぜ「テンプレート」という仕組みが要るのか 生成されるのは値だけ。ルールの形は開発者が握ったまま テンプレートを直せば、生成済みの全部に一括反映 認可ルールを、アプリの機能としてユーザーに開放できる 今ココ 書いてみる 19/29
20. ▪組み込みか、マネージドか どうやって使うか ライブラリとして組み込む Rust crate（各言語バインディングあり） アプリ内で完結、追加コストなし ポリシーの保管・配布は自前 AVPに任せる ポリシーストアをAWSが管理 完全従量課金（2025年に大幅値下げ） Cognitoトークン連携が組み込み どちらでもポリシーの書き方は同じ。移行も現実的。 今ココ 書いてみる 20/29
21. 03 正しさを証明する Cedarが「形式」と呼ばれる理由 今ココ 形式検証 21/29
22. ▪なぜ数学の出番なのか 認可のバグは、テストで見つけにくい テストは「試したケース」しか守れない。 認可で怖いのは試していない組み合わせのほう。 見つけにくい ポリシーが増えるほど、意図しない許可の隙間は組み合わ せの闇に沈む 形式検証なら すべての入力について成り立つ・成り立たないを数学的に 判定できる Cedarはこの検証が可能なように、言語自体が設計されている。 今ココ 形式検証 22/29
23. ▪誰が、何を検証するのか 検証は「2階建て」になっている ここから先、検証の対象が2つ出てくる。混ざりやすいので先に分けておく。 1F 2F 共通 認可エンジンにバグがないか。 AWSがすでにやってくれた 書いたルールが意図通りか。 あなたが自分でやる Lean（定理証明支援系）と SMTソルバ Cedar自身の正しさ 今ココ 形式検証 あなたのポリシーの正しさ 支えている道具は同じ 23/29
24. ▪検証駆動開発（VGD） 1F：Cedar自身はこう作られた 形式化 評価器・認可器の モデルをLeanで書く なぜ信用できるか 性質を証明 → 定理証明 forbid優先などを 数学的に保証 この体制で計25件のバグを発見・修正（証明で4件、テストで21 件）。レビューもテストもすり抜けたものたち。 今ココ 形式検証 実装と照合 → ランダム入力で 差分テスト Rust実装と突き合わせ つまり 「forbidが勝つ」は仕様書の約束ではなく、証明済みの定理。 24/29
25. ▪2Fへ では、自分の書いたポリシーは？ エンジンが正しくても、 書いたルールが意図通りかは別の問題。 例えば 「整理したつもりが、実は誰も削除できなくなっていた」 ここでも 同じ武器が使える。Cedarは解析できるように設計されて いる そのための道具が、次に出てくるSymCC。 今ココ 形式検証 25/29
26. ▪cedar-policy-symcc 2F：SymCCに「問い」を投げる ポリシー集合をSMT論理式に翻訳し、総当たりせずに全入力を調べる。聞けるのは6種類。 1本のポリシーについて聞く 「エラーで落ちることはない？」（never errors） 「誰も通れない／誰でも通れる？」（always denies / allows） 2つの集合を見比べて聞く 「同じ挙動？」（equivalent）・「含まれる？」（implies） 「絶対に重ならない？」（disjoint） 答えがNoなら、SMTソルバが「破れる具体例」をリクエストの形で返す 今ココ 形式検証 26/29
27. ▪リファクタリングの安全網 いちばん効くのは equivalent ポリシーを整理・書き換えたあと、 check_equivalent で「挙動が変わっていない」ことを証明できる。 これまで 書き換え後の挙動は、テストケースのぶんだけ祈る SymCC後 全入力で等価と証明、違えば反例が具体的に出る 認可の書き換えが、怖い作業から普通の作業になる。 今ココ 形式検証 27/29
28. ▪principalいま、認可の前提が変わりつつある が人間とは限らなくなった これまで principal は人間だった。 いまそこにAIエージェントが入ってくる。 何が困るか エージェントはユーザーの代理で動く。本人の全権限をそ のまま渡すわけにはいかない どう解くか ツール呼び出しそのものを action として認可の対象にする その認可基盤に Cedarが選ばれている（AgentCore、cedar-for-agents）。 今ココ おわりに 28/29
29. ▪今日はこれだけ まとめ 01 認可はコードから切り出せる if文の散らばりは、PARCの語彙でポリシーに集約できる。 02 デフォルト拒否・forbid優先 2行の評価規則が「うっかり許可」を構造的に防ぐ。 03 正しさは証明できる SymCCで等価性まで機械判定。しかも検証器自体がLeanで証明済み。 今ココ おわりに 29/29