AWS セキュリティは「論理」に訊け！ Automated Reasoning の理論と実践 #JTF2021 / July Tech Festa 2021

July Tech Festa 2021 で使用したスライドです。

S3 オブジェクトを不必要に公開してしまったり、遮断されるべきネットワークが繋がってしまったりといった、セキュリティの設定ミスは是非とも避けたいものです。では、多数の設定項目が複雑に相互作用する状況で、最終的な設定の「正しさ」はどうしたら保証できるでしょうか？

この問題に対して有効な手法の一つが Automated Reasoning です。Automated Reasoning を活用することで、AWS 上の設定項目を数学的に解析し、実際のアクセスを行うことなくアクセスが可能かどうかを「推論」することが可能になります。本セッションでは、この Automated Reazoning をエンドユーザの立場から活用する方法に加え、背景にある数学的な理論も含めて、セキュリティの「正しさ」を保証する仕組みの内幕を解説します。

イベント概要：https://techfesta.connpass.com/event/213069/
ブログ記事：https://ccvanishing.hateblo.jp/entry/2021/07/18/211619
録画：https://www.youtube.com/watch?v=ChEvLlhF9SA

Transcript

1. #JTF2021 #JTF2021 AWS セキュリティは「論理」に訊け！ Automated Reasoning の理論と実践 チェシャ猫 (@y_taka_23) July Tech Festa 2021 (18th Jul. 2021)
2. #JTF2021 #JTF2021 本日の目次 • AWS 上のセキュリティ設定の検査 ◦ 既存ツールと IAM Access Analyzer の違い • SAT ソルバと SMT ソルバ ◦ 設定をテストするための要素技術 • 検査エンジン Zelkova ◦ IAM Access Analyzer の意味論と SMT ソルバとの接続
3. #JTF2021 #JTF2021 いかにして設定を検査するか 1 Test security configurations on AWS
4. #JTF2021 #JTF2021 セキュリティ系の設定のテスト • 実際に AWS にデプロイする前にテストしたい ◦ 設定にミスがあった時の影響が大きい ◦ 実際のアクセスベースのテストで失敗した場合、すでに危険な状態 • CloudFormation をテストする既存のツール ◦ aws cloudformation validate-template コマンド ◦ CloudFormation Linter (cnf-lint) ◦ CloudFormation Guard (cfn-guard)
5. #JTF2021 #JTF2021 私見：CloudFormation の検査水準 • Level 1：構文論的な検査 ◦ CloudFormation のテンプレートとして文法的に正しいか • Level 2：ヒューリスティックな検査 ◦ 個別項目がルールに沿っているかどうか（例：0.0.0.0/0 は禁止） • Level 3：意味論的な検査 ◦ 設定によって実際に発揮される効果の「意味」に踏み込んだ検査
6. #JTF2021 #JTF2021 設定の「意味」とは何か？
7. #JTF2021 #JTF2021 IAM Access Analyzer • 過剰なアクセス権限を自動で検出してくれる ◦ 外部（他の AWS アカウントなど）からのアクセス許可を発見 ◦ 現状の対応サービスは S3、IAM Role、KMS、Lambda Layer、 SQS、Secret Manager • 実際の適用前に検出が可能 ◦ 定期的なチェックも実行される（約 30 分ごと） ◦ Config Rule と違って即時性・カスタムルールはないが、無料で簡単
8. #JTF2021 #JTF2021 Allow:11.22.33.0/24 Deny: 11.22.33.44/32 なので、Allow の CIDR は Deny の CIDR からはみ出していて アクセスを許す余地がある
9. #JTF2021 #JTF2021 Allow と Deny の CIDR を 入れ替えると Deny の方が広いため 問題は検出されなくなる つまり、サブネットマスクの 包含関係や複数 Statement の 評価の「意味」を理解している
10. #JTF2021 #JTF2021 Section 1 のまとめ • AWS セキュリティの設定 ◦ 実際にデプロイを行う前に、設定そのものを検査したい • 検査できるレベルの違い ◦ 構文 < ヒューリスティック < 意味論 • IAM Access Analyzer ◦ Policy 適用時の実際の影響を考えた、意味論的な検査が可能
11. #JTF2021 Automated Reasoning 自動化された推論
12. #JTF2021 #JTF2021 いかにして問題を解くか？ 2 Solve problems with a SAT/SMT solver
13. #JTF2021 #JTF2021 要素技術：SAT/SMT ソルバ
14. #JTF2021 #JTF2021 SAT ソルバ • 命題論理式の充足可能性 (SATisfiability) を判定 ◦ 各変数に真偽をうまく割り当てて、全体を成立させられるか？ • 例 1：(p || q) && (p || !q) && (!p || !q) ◦ 答：充足可能（p = true、q = false のとき全体が true） • 例 2：(p || q) && (p || !q) && (!p || !q) && (!p || q) ◦ 答：充足不可能（どの組み合わせでも全体が true にならない）
15. #JTF2021 #JTF2021 SMT ソルバ (Satisfiability Modulo Theory) • SAT ソルバは命題論理しか扱えない ◦ 仮に命題論理で記述可能であっても、問題のサイズが爆発しがち ◦ 元の問題の性質が利用できない（例：a < b かつ b < c なら a < c） • 特定領域の理論に関する推論を別途実装 ◦ 中身を考えない関数 (EUF)、整数・有理数の算術、文字列操作、 正規表現、ビット演算、配列の添字アクセス、量化子、など ◦ !、&&、|| など論理演算部分については SAT ソルバが担当する
16. #JTF2021 #JTF2021 SMT ソルバ • 例 1 (整数の算術)： ◦ 問：x < y + 2 && x = 2 * z + 10 && y + z >= 10 ◦ 答：充足可能（x = 12、y = 11、z = 1） • 例 2 (文字列操作)： ◦ 問：str ++ "b" == "a" ++ str ◦ 答：充足不可能（先頭にある a の個数を考えるとわかる）
17. #JTF2021 #JTF2021 AWS における SMT ソルバの利用
18. #JTF2021 #JTF2021 Zelkova: AWS x SMT ソルバその 1 • アクセス制御に関するクエリに答える ◦ 例：S3オブジェクトが他の AWS アカウントから読み取り可能か？ ◦ 実際のアクセスは行わず、設定のみから推論 • バックエンドの SMT ソルバは Z3 ◦ 正規表現周りに AWS 独自の最適化入り（Z3Automata） • Access Analyzer、Config、IoT Device Defender、 Macie、Trusted Advisor、GuardDuty に統合
19. #JTF2021 #JTF2021 Tiros: AWS x SMT ソルバその 2 • ネットワーク設定に関するクエリに答える ◦ 例：EC2 インスタンス A から B に SSH 接続可能か？ ◦ 実際のパケットは送出せず、設定のみから推論 • バックエンドの SMT ソルバは MonoSAT ◦ グラフに関する理論が実装されている • VPC Reachability Analyzer、Inspector に統合
20. #JTF2021 #JTF2021 Section 2 のまとめ • SMT ソルバによる充足可能性判定 ◦ 問題によっては SAT ソルバ（命題論理）のみだと力不足 ◦ 特定の理論に関するソルバを個別に実装して組み合わせる • AWS でも SMT ソルバベースの検査器を開発・利用 ◦ Zelkova：リソースへのアクセス権限の検査 ◦ Tiros：ネットワーク設定の検査
21. #JTF2021 #JTF2021 いかにしてポリシを表現するか？ 3 Encode policies into the SMT format
22. #JTF2021 #JTF2021 Semantic-based Automated Reasoning for AWS Access Policies using SMT J. Backes et al. (2018)
23. #JTF2021 #JTF2021 Zelkova の論文概要 • 新規性：従来の IAM Policy 文法を検査できる ◦ 先行研究は「検査可能な Policy 用の DSL を提案する」系 • AWS における利用実態 ◦ 前述の通り、複数のセキュリティ系 AWS サービスと連携 ◦ Lambda Function として稼働、JSON API を提供 ◦ 1 日あたり数百万から数千万回のクエリ ◦ 99 % のクエリは 160 ms 以内に応答（JSON パース込み）
24. #JTF2021 #JTF2021 IAM Policy を SMT ソルバ向けに変換したい
25. #JTF2021 #JTF2021 Zelkova による Policy のエンコード (1) • リクエスト (p, a, r) が許可されることを論理式で表現 ◦ OR{S ∈ Allow Statements: (p, a, r) が S に合致} && ! OR{S ∈ Deny Statements: (p, a, r) が S に合致} • 各 S に対する合致をさらに論理式で表現 ◦ OR{v ∈ S の Principals: p = v} && OR{v ∈ S の Actions: a = v} && OR{v ∈ S の Resources: r = v} && AND{(op, key, V) ∈ S の Conditions: OR{v ∈ V: op(key, v)}}
26. #JTF2021 #JTF2021 Zelkova による Policy のエンコード (2) • ワイルドカードは文字列操作や正規表現に変換 ◦ IAM Policy：Resource: foo*/*bar ◦ SMT：prefixOf("foo", r) && contains(r, "/") && surfixOf(r, "bar") ◦ 3 個以上の * や、大小文字の混合の場合には正規表現が必要 • CIDR はビット演算に変換 ◦ IAM Policy：11.22.33.00/24 ◦ SMT：0x0B162100 == (ipV4 & 0xFFFFFF00)
27. #JTF2021 #JTF2021 Zelkova による Policy の検査 • Zelkova は Policy の強弱関係を判定する ◦ Policy X と Policy Y に対して (p, a, r) が X で許可される => (p, a, r) が Y で許可される が常に成り立てば、X は Y より「厳しい」Policy である ◦ less-or-equally-permissive 関係と呼ばれる • 実用上は検査対象を X、ガードレールを Y とする ◦ 反例とはすなわち、Y が不許可なのに X が許可してしまう例
28. #JTF2021 #JTF2021 Section 3 のまとめ • 検査エンジン Zelkova ◦ 独自 DSL ではなく、従来の IAM Policy を高速で検査可能 • Policy を SMT ソルバに与えられる形式に変換 ◦ ワイルドカード：文字列、正規表現 ◦ CIDR：ビット列の演算 • SMT ソルバ Z3 による検査 ◦ 反例の探索により、ガードレールより「厳しい」ことを確認
29. #JTF2021 #JTF2021 まとめ 4 Recap the session
30. #JTF2021 #JTF2021 本日のまとめ • セキュリティ系設定の検査 ◦ デプロイ前に、設定の「意味」まで考えて検査したい • SMT ソルバによる充足可能性の判定 ◦ 整数の計算や文字列の性質など、特定のドメインの理論を実装 ◦ 解きたい問題が SMT ソルバ用にエンコードできれば自動で解ける • 検査エンジン Zelkova ◦ IAM Policy の「意味」を SMT ソルバ用にエンコード
31. #JTF2021 #JTF2021 Make the Security Provable! Presented by チェシャ猫 (@y_taka_23)