君のセキュリティはデプロイするまでもなく間違っている #CICD2021 / CICD Conference 2021

CI/CD Conference 2021 で使用したスライドです。

S3 オブジェクトを不必要に公開してしまったり、あるいは遮断されるべきネットワークが繋がってしまったりといったセキュリティ上の設定ミスは、可能な限り避けたいものです。

このようなインフラ層に対するテストを従来の CI/CD の一部として組み込む場合、「個別の設定項目が条件を満たすことを確認する」または「実際にデプロイした環境に対してアクセスしてみる」といった形でテストを行うことが一般的でしょう。

しかしセキュリティ設定には、「複数の設定項目が絡み合った結果、最終的なアクセス可否が定まる」かつ「実際にデプロイする前に影響範囲を知りたい」といった要求があり、上にあげたテストの形式とはあまり相性が良くないのが事実です。

この問題に対して有効な手法の一つが Automated Reasoning です。Automated Reasoning では、設定項目を数学的に解析することで、実際のデプロイやアクセスを行うことなく、アクセスが可能かどうかだけを「推論」させることができます。

本セッションでは、我々エンドユーザが実際に Automated Reasoning を活用できる例として AWS の Access Analyzer を取り上げ、背景にある数学的な理論や関連論文も含めて解説したいと思います。

イベント概要：https://event.cloudnativedays.jp/cicd2021/talks/1171
ブログ記事：https://ccvanishing.hateblo.jp/entry/2021/09/04/055934

Transcript

1. 君のセキュリティは デプロイするまでもなく 間違っている。 #CICD2021 #CICD2021_B チェシャ猫 (@y_taka_23) CI/CD Conference 2021 (3rd Sep. 2021)
2. この設定、デプロイして大丈夫…？
3. Semantic-based Automated Reasoning for AWS Access Policies using SMT J. Backes et al. (2018) https://d1.awsstatic.com/Security/pdfs/Semantic_Based_Auto mated_Reasoning_for_AWS_Access_Policies_Using_SMT.pdf
4. 本日の目次 • AWS 上のセキュリティ設定の検査 ◦ 既存ツールと IAM Access Analyzer の位置付け • SAT ソルバと SMT ソルバ ◦ 設定を検査するための要素技術の復習 • 検査エンジン Zelkova の論文解説 ◦ IAM Policy の意味論と SMT ソルバとの接続
5. いかにして設定を検査するか 1. Test Security Configurations on AWS
6. セキュリティ系の設定のテスト • AWS 上にデプロイする「前」に検査したい ◦ 設定をミスった時の影響が大きい ◦ 実際にアクセスできる時点で既に危険な状態 • CloudFormation をテストする既存ツール ◦ AWS CLI の validate-template コマンド ◦ CloudFormation Linter や CloudFormation Guard
7. 私見：CloudFormation の検査水準 • Level 1. 構文論的な検査 ◦ テンプレートとして文法的に正しいか • Level 2. ヒューリスティックな検査 ◦ 個別項目がルールに合致するか（例：0.0.0.0/0 禁止） • Level 3. 意味論的な検査 ◦ 設定が発揮する効果の「意味」まで考えて正しいか
8. デプロイ前の設定 デプロイ後の現物 Lv 3. 意味論 Lv 2. 個別項目 Lv 1. 構文 （不要）
9. デプロイ前の設定 デプロイ後の現物 Lv 3. 意味論 Lv 2. 個別項目 Lv 1. 構文 CFn Linter / Guard validate-template （不要） AWS Config
10. デプロイ前の設定 デプロイ後の現物 Lv 3. 意味論 Lv 2. 個別項目 Lv 1. 構文 セキュリティ的には できれば検査したい CFn Linter / Guard validate-template （不要） AWS Config
11. ＼ IAM Access Analyzer ／
12. IAM Access Analyzer の概要 • 外部（信頼ゾーン外）からのアクセス許可を発見 ◦ 信頼ゾーン：AWS アカウントまたは Organization ◦ 偽陽性（意図したもの）は個別にアーカイブで無効化 • 複数の AWS サービスに統合済み ◦ 現在のサポートは S3、IAM Role、KMS、 Lambda Layer、SQS、Secret Manager
13. IAM Access Analyzer の機能 • アクセスのプレビュー（本日のテーマ！） ◦ デプロイ前に、設定のみから実際の効果を予測できる • 定期的（約 30 分）なスキャン ◦ AWS Config と異なりカスタムできないが手軽で無料 • Policy のバリデーション・個別項目ルールの検査 • CloudTrail のアクセス履歴から Policy を生成
14. デプロイ前の設定 デプロイ後の現物 Lv 3. 意味論 Lv 2. 個別項目 Lv 1. 構文 CFn Linter / Guard validate-template （不要） AWS Config Access Analyzer
15. Bucket Policy 編集画面で 保存前にプレビューが可能
16. Allow:11.22.33.0/24 Deny: 11.22.33.44/32 なので、Allow の CIDR は Deny の CIDR からはみ出していて アクセスを許す余地がある
17. Allow と Deny の CIDR を 入れ替えると Deny の方が広いため 問題は検出されなくなる つまり、サブネットマスクの 包含関係や複数 Statement の 評価の「意味」を理解している
18. Section 1 のまとめ • AWS のセキュリティ設定 ◦ 実際のデプロイより前に設定のみを検査したい • 検査できる「間違い」にはレベル感がある ◦ 単純：構文論 < ヒューリスティック < 意味論：複雑 • IAM Access Analyzer のプレビュー機能 ◦ デプロイ前に意味論的な検査が可能
19. いかにして結論を導出するか 2. Solve Problems With a SAT/SMT Solver
20. 要素技術：SAT / SMT ソルバ
21. SAT ソルバ • 命題論理の充足可能性（SATisfiability）を検査 ◦ 各変数に真 or 偽を割り当てて全体を真にできるか？ • 例 1：(p || q) && (p || !q) && (!p || !q) ◦ 答：充足可能（p = True, q = False） • 例 2：(p || q) && (p || !q) && (!p || !q) && (!p || q) ◦ 答：充足不可能（どう割り当てても無理）
22. SMT ソルバ • SAT ソルバは命題論理しか扱えない ◦ 命題論理で書き直すと問題のサイズが爆発しがち ◦ 元の問題の性質（例：不等号の推移性）が失われる • 特定領域の理論ソルバを外部実装して組み合わせる ◦ 整数の算術、文字列、ビット演算、など ◦ && や || など論理部分は SAT ソルバが担当
23. SMT ソルバ • 例 1（整数の算術） ◦ 問：x < y + 2 && x = 2 * z + 10 && y + z >= 10 ◦ 答：充足可能（x = 12, y = 11, z = 1） • 例 2（文字列） ◦ 問：str ++ "b" = "a" ++ str ◦ 答：充足不可能（先頭の a の個数が合わない）
24. AWS における SMT ソルバの利用
25. Zelkova（本日のテーマ！） • アクセス制御に関するクエリに答える ◦ 例：S3 Object が外部アカウントから読み取り可能か？ ◦ 実際のアクセスは行わず、設定のみから推論 • 既成の汎用 SMT ソルバ Z3 をバックエンドに使用 ◦ Zelkova は IAM の「意味」を Z3 用に変換 ◦ 変換された問題を Z3 が解く
26. Tiros • ネットワーク設定に関するクエリに答える ◦ 例：EC2 インスタンス A から B に SSH 可能か？ ◦ 実際のパケットは送出せず、設定のみから推論 • SMT ソルバ MonoSAT をメインのバックエンドに使用 ◦ グラフに関する理論が実装されている ◦ MonoSAT 以外にも Soufflé と Vampire を併用
27. AWS Dev Day Online 2021 Tiros で登壇予定！
28. Section 2 のまとめ • SMT ソルバによる充足可能性判定 ◦ 現実の問題に対して SAT ソルバのみだと力不足 ◦ 個別領域のソルバを別途用意して組み合わせる • AWS でも SMT ソルバベースの機能を提供 ◦ Zelkova：アクセス制御に関する検査 ◦ Tiros：ネットワークに関する検査
29. いかにして意味を表現するか 3. Encode the Semantics into Formulae for SMT Solver
30. Semantic-based Automated Reasoning for AWS Access Policies using SMT J. Backes et al. (2018) https://d1.awsstatic.com/Security/pdfs/Semantic_Based_Auto mated_Reasoning_for_AWS_Access_Policies_Using_SMT.pdf
31. Zelkova の論文概要 • 新規性：実際の IAM Policy 文法を直接検査できる ◦ 既存研究は Policy 用の新規 DSL を提案するタイプ • 評価：AWS における利用実績 ◦ Access Analyzer / Config / GuardDuty など ◦ 1 日あたり数百万から数千万回のクエリ ◦ 99 % のクエリは 160 ms 以内に応答
32. Zelkova の役割 • 検査のコア部分は既製品の SMT ソルバ Z3 • Zelkova は Policy の文法を Z3 用の入力にエンコードする Policy Z3 Access Analyzer Zelkova
33. SMT ソルバ = 条件を満たす値の探索器
34. Zelkova の動作原理（1） • X：Policy が与えられたとき、 ◦ p：Principal（アクセスの主体、IAM User など） ◦ a：Action（動作の内容、s3:GetObject など） ◦ r：Resource（アクセスの客体、S3 Object など） に対して以下の条件が SMT エンコード可能だと仮定する A(X, p, a, r)：X はアクセス (p, a, r) を許可
35. Zelkova の動作原理（2） • X, Y：Policy が与えられたとき、以下の充足問題を考える A(X, p, a, r) && !A(Y, p, a, r) • この論理式を充足する (p, a, r) が存在するとはつまり X は許可しているが、Y は許可していないアクセスが 少なくとも 1 パターンは存在する ということである
36. Zelkova の動作原理（3） • 逆に、先ほどの式が充足不可能、すなわち A(X, p, a, r) => A(Y, p, a, r) が常に成り立つとき、X は Y より「厳しい」ことになる • この X と Y の関係を less-or-equally-permissive と呼ぶ ◦ 直訳するなら「X は Y より非寛容」 ◦ 実際には X：検査対象、Y：ガードレールとして検査
37. 「A(X, p, a, r)：Policy X はアクセス (p, a, r) を許可」 を SMT エンコードする問題に帰着
38. Policy の Statement への分解 • Allow Statement と Deny Statement に分けて Allow のどれかに合致 || Deny のどれにも合致しない Statement: [ { Effect: Allow, ...}, { Effect: Allow, ...}, { Effect: Deny, ...}, { Effect: Deny, ...}, ] Deny 側に合致 Policy に合致 Allow 側に合致 || || ! ||
39. Statement の個別項目への分解 • Principal / Action / Resource に対しては p, a, r がそれぞれ Statement 内の Principal / Action / Resource のどれかに合致 • Condition に対しては、各条件を SMT エンコードした上で p, a, r がそれぞれ Statement 内の Condition の すべてに合致
40. 「個別項目の条件 に p / a / r がそれぞれ合致する」 を SMT エンコードする問題に帰着
41. SMT の理論ソルバの使い所 • 文字列の理論：ワイルドカード ◦ prefixOf、surfixOf、contains を利用 • 正規表現の理論：大小文字の無視、ワイルドカードの一部 ◦ 特定の条件は文字列の理論だけでは書けない • ビット演算の理論：CIDR の重複判定 ◦ CIDR をビットベクトルとしてエンコードする
42. ワイルドカードのエンコーディング • SMT に内蔵された文字列専用の理論ソルバを使用 Policy 上の表現 Resource: foo*/bar* Resource: foo*/*bar SMT エンコーディング prefixOf(r, "foo") && contains(r, "/bar") prefixOf(r, "foo") && contains("/", r) && surfixOf(r, "bar")
43. Case-Insensitive な条件の扱い • SMT に内蔵された正規表現の理論ソルバを使用 Policy 上の表現 StringEqualsIgnoreCase: s3:prefix: UpLoad SMT エンコーディング matches(s3:prefix, /[uU][pP][lL][oO][aA][dD]/)
44. CIDR のエンコーディング • SMT に内蔵されたビット演算専用の理論ソルバを使用 Policy 上の表現 aws:SourceIp: 11.22.33.00/24 SMT エンコーディング 0x0B162100 = aws:SourceIp & 0xFFFFFF00
45. Zelkova の役割（再掲） • 検査のコア部分は既製品の SMT ソルバ Z3 • Zelkova は Policy の文法を Z3 用の入力にエンコードする Policy Z3 Access Analyzer Zelkova
46. Section 3 のまとめ • 検査エンジン Zelkova ◦ 独自 DSL ではなく IAM Policy をそのまま検査可能 • Policy を SMT ソルバ Z3 用にエンコード ◦ 文字列、正規表現、ビット演算の理論ソルバを利用 • Z3 による less-of-equally-permissive 関係の判定 ◦ 検査したい Policy とガードレールとの強弱
47. 本日のまとめ 4. Recapture the Session
48. 本日のまとめ • Access Analyzer によるセキュリティ設定のテスト ◦ デプロイ前に、設定の「意味」まで考えて検査したい • SMT ソルバによる充足可能性判定 ◦ SAT ソルバ + 特定領域専用の理論ソルバ • Zelkova によるエンコーディング ◦ Policy を SMT ソルバ Z3 用の論理式に変換
49. Test Security by Logic! Presented By チェシャ猫 (@y_taka_23)