【AWS Dogwood入門】使い分けと、採用するときの注意

Transcript

1. 2026年8月 使い分けと、採用するときの注意 AWS Dogwood 入門⑦（全7回）── 証明できる境界線 赤神 青空
2. ▪最終回。どこまでをポリシーに寄せるか 前回までのおさらい 最後はどこまでをポリシーに寄せるかを考えます。 Cedarで足りる場面と、temporalが要る場面 証明できる範囲と、実行時にしか分からない範囲 採用するときに、自分で用意する必要があるもの 今ココ おさらい 2/18
3. ▪Cedar を先に書き、必要になってから 判断の順番 temporal を足す はい 素の Cedar で書く 静的解析が効く‧安い‧速い 誰がどのツールをどの引数で呼べるか はい そのルールは 1回の呼び出しだけを ⾒れば判断できるか いいえ temporal 節を⾜す 既存のCedarは書き換えず、必要な1本にだけ 履歴の正しさが前提条件になる点に注意 前提‧順序‧回数‧累計‧ 鮮度のどれかに 関わるか アプリ側のロジックで持つ いいえ 認可の問題ではなく業務ロジックの問題 何でもポリシーに寄せると評価コストだけ増える 迷ったら Cedar を先に書く。temporal は「Cedarでは原理的に書けない」と分かってから⾜すもの 何でもポリシーに寄せると、評価コストだけが増えていく 今ココ 使い分け 3/18
4. ▪左の性質が出てきたら、右を選ぶ 使い分けの早見表 静的 前提 流量 鮮度 業務 1回で判断できる 承認・順序が要る 回数・総額の上限 取得からの経過時間 認可の話ではない 今ココ 使い分け Cedar。解析が効いて安い temporal（formerly） temporal（count / sum） temporal（短い窓の formerly） アプリ側のロジックで持つ 4/18
5. ▪同じポリシーセットに、性質の違う2領域が同居する 証明できる境界線 同じポリシーセットの中に、性質の違う2つの領域が同居する when { ... } の領域 when temporal { ... } の領域 ‧状態を持たない。同じ⼊⼒なら常に同じ答え ‧評価順にも過去にも依存しない ‧⾃動推論ツールで「何を許すか」を証明できる ‧評価コストが履歴の⻑さに依存しない ‧状態を持つ。イベント履歴の追跡が要る ‧評価時間が履歴の⻑さに依存しうる ‧⾃動推論による解析は、いまのところ効かない ‧履歴が正しいことが、そのまま前提条件になる ＝ 素の Cedar ＝ Dogwood が⾜した部分 デプロイ前に、机上で境界を確認できる 「この権限は絶対に漏れない」を定理として書ける 実際に動かさないと分からない これが runtime verification（実⾏時検証）と呼ばれる所以 Cedar を拡張せず新⾔語にしたのは、この差を混ぜないため この差を混ぜないために、Cedar の拡張ではなく新言語になった 今ココ 使い分け 5/18
6. ▪静的解析が効かない、が何を指しているのか 証明できないのは何か ✕ 証明できないもの 個々の時相ポリシーが何を許すか 実行前に境界を確定すること Cedarの自動推論はここに届かない ◯ 証明されうるもの 判定を下すモニタ側の正しさ MFOTLの監視器には検証実装の前例 Isabelle/HOL で形式化された例がある 静的解析が効かないことと、何も検証されていないことは、別の話です。 今ココ 使い分け 6/18
7. ▪静的に守れるものは、静的に守っておく 意図的に分けて書く 証明できるものを、証明できないものと同じ扱いにしない。 Cedar で書く 絶対に漏らせない権限境界そのもの temporal で書く 実行してみないと分からない量と順 序 その結果 事故ったときに疑う場所が絞り込め る これは設計方針の話で、言語の使い方の話ではありません。 今ココ 使い分け 7/18
8. ▪過大評価しないための線引き 見ているのは順序だけ ポリシーが照合しているのはIDと呼び出しの順序で、データの流れではありません。 情報フローを追跡しているわけではない 読んだ中身がどこへ渡ったかは見ていない 別の変数に移し替えられたら追えない 塞いだのは1本の経路だけ 送信手段が他にもあるなら、それらも対象に含める ツールが増えるたびに、経路の棚卸しが要る 順序で守れる範囲を正しく見積もることが前提になる 今ココ 使い分け 8/18
9. 採用するときの注意 オープンソース版を触る前に知っておくこと 今ココ 採用時の注意 9/18
10. ▪AWS 自身がそう明記している 参照実装は本番用ではない 同梱のインタプリタは言語を試すためのもので、認可エンジンではありません。 パーサ・バリデータ・参照インタプリタが入っている 手元の IDE やコーディングエージェントで挙動を確かめる用途 マネージドが要るなら AgentCore Policy 側を使う コンパイラと状態追跡が組み込まれている エージェントのコードの外側なので回避されない そのマネージド側を実機で動かした報告も出ている 言語としては参照実装のものがそのまま通ったとのこと eventResource が必須になるなど、差分はある 今ココ 採用時の注意 10/18
11. ▪リポジトリが挙げている前提条件を3つにまとめると 自前でやるなら 01 履歴が信用できること 信頼できるタイムスタンプ、イベントの認証、名前の一貫性。 02 履歴が消えないこと トレースの永続化と、認可判定そのもののログ記録。 03 履歴が混ざらないこと テナント間の分離と、機微情報を含む前提での保持期間設計。 認可の根拠が履歴になった以上、履歴の品質が認可の品質になる 今ココ 採用時の注意 11/18
12. これから足されるもの 予告されている3方向 今ココ これから 12/18
13. ▪ただし、いまの時刻を見るだけなら回避策がある 絶対時刻は未対応 時間の指定は直近1時間のような相対指定だけで、0時リセットは書けません。 書けないもの 毎日0時に戻る日次クォータ 営業終了まで、のような実際の時刻を基準にした区切り いま取れる代案 現在時刻だけを見る判定は通常のCedar条件で書ける context.system.now を素の when 節で使う 絶対時刻の演算子は、予告されている追加のひとつ 今ココ これから 13/18
14. ▪いまは「起きてはいけないこと」しか書けない safety の次は liveness safety（いま実装済み） liveness（これから） 「起きてはいけないこと」を⽌める 「必ず起きるべきこと」を担保する 承認なしに売るな∕上限を超えるな 承認したなら実⾏まで∕開けたなら閉じろ 過去のイベント列だけを⾒れば判定できる 未来を⾒る演算⼦が要る。MFOTL には概念としてある 過去を⾒る 未来を⾒る いまの1回のツール呼び出し ほかに予告されているもの：絶対時刻の窓（⽇次クォータ）∕マルチエージェントのオーケストレーション 「誰が誰に引き継いでよいか」「どのエージェントがロックを持つか」まで射程に⼊れている 未来を見る演算子は MFOTL 側には既にある 今ココ これから 14/18
15. ▪数字で見ると温度感が掴みやすい いまの立ち位置 2026/8 公開 Apache 2.0・AgentCoreにも搭載 今ココ これから 4 標準マクロ count/distinct/sum/bind 24h 遡れる上限 AgentCore の軌跡が残る時間 15/18
16. ▪開き方も段階的にやるつもりらしいです コミュニティの状態 いまは直接のコントリビューションは受け付けていない段階になっています。 言語設計と今後の方向性へのフィードバックは歓迎とのこと Cedar コミュニティには先に共有して意見を取り込み済み 順番として想定されているのは 反応を集める → 安定してから貢献を開く そのあとガバナンスを一緒に作る 今ココ これから 16/18
17. ▪3つだけ持ち帰ってもらえれば十分です まとめ 01 乗り換えではなく、足し算 妥当なCedarは妥当なDogwood。必要な1本にだけ temporal を足す。 02 数えるなら request を数える 同時に何本も飛ぶのが前提。着金した分だけ数えると上限を超える。 03 証明できる範囲は分けて守る 時相条件に自動推論は効かない。だから混ぜずに書き分ける。 今ココ おわりに 17/18
18. ▪一次情報から順に並べています 参考にしたもの AWS OSS Blog AWS ML Blog GitHub The New Stack Zenn Zenn 続編 ACM 今ココ おわりに Introducing Dogwood: runtime verification Securing AI agents with temporal policies dogwood-policy/dogwood（Apache 2.0・ガイド同梱） 外部からの評価と、採用時の注意点の整理 AWS の新ポリシー言語 Dogwood を試す（exwzd） Dogwood を Amazon Bedrock AgentCore で動かす Monitoring Metric First-order Temporal Props. 18/18