君のセキュリティはデプロイするまでもなく間違っている #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)
   

   View Slide

2. この設定、デプロイして大丈夫…？
   

   View Slide

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
   

   View Slide

4. 本日の目次
   ● AWS 上のセキュリティ設定の検査
   ○ 既存ツールと IAM Access Analyzer の位置付け
   ● SAT ソルバと SMT ソルバ
   ○ 設定を検査するための要素技術の復習
   ● 検査エンジン Zelkova の論文解説
   ○ IAM Policy の意味論と SMT ソルバとの接続
   

   View Slide

5. いかにして設定を検査するか
   1.
   Test Security Configurations on AWS
   

   View Slide

6. セキュリティ系の設定のテスト
   ● AWS 上にデプロイする「前」に検査したい
   ○ 設定をミスった時の影響が大きい
   ○ 実際にアクセスできる時点で既に危険な状態
   ● CloudFormation をテストする既存ツール
   ○ AWS CLI の validate-template コマンド
   ○ CloudFormation Linter や CloudFormation Guard
   

   View Slide

7. 私見：CloudFormation の検査水準
   ● Level 1. 構文論的な検査
   ○ テンプレートとして文法的に正しいか
   ● Level 2. ヒューリスティックな検査
   ○ 個別項目がルールに合致するか（例：0.0.0.0/0 禁止）
   ● Level 3. 意味論的な検査
   ○ 設定が発揮する効果の「意味」まで考えて正しいか
   

   View Slide

8. デプロイ前の設定 デプロイ後の現物
   Lv 3. 意味論
   Lv 2. 個別項目
   Lv 1. 構文 （不要）
   

   View Slide

9. デプロイ前の設定 デプロイ後の現物
   Lv 3. 意味論
   Lv 2. 個別項目
   Lv 1. 構文
   CFn Linter / Guard
   validate-template （不要）
   AWS Config
   

   View Slide

10. デプロイ前の設定 デプロイ後の現物
    Lv 3. 意味論
    Lv 2. 個別項目
    Lv 1. 構文
    セキュリティ的には
    できれば検査したい
    CFn Linter / Guard
    validate-template （不要）
    AWS Config
    

    View Slide

11. ＼ IAM Access Analyzer ／
    

    View Slide

12. IAM Access Analyzer の概要
    ● 外部（信頼ゾーン外）からのアクセス許可を発見
    ○ 信頼ゾーン：AWS アカウントまたは Organization
    ○ 偽陽性（意図したもの）は個別にアーカイブで無効化
    ● 複数の AWS サービスに統合済み
    ○ 現在のサポートは S3、IAM Role、KMS、
    Lambda Layer、SQS、Secret Manager
    

    View Slide

13. IAM Access Analyzer の機能
    ● アクセスのプレビュー（本日のテーマ！）
    ○ デプロイ前に、設定のみから実際の効果を予測できる
    ● 定期的（約 30 分）なスキャン
    ○ AWS Config と異なりカスタムできないが手軽で無料
    ● Policy のバリデーション・個別項目ルールの検査
    ● CloudTrail のアクセス履歴から Policy を生成
    

    View Slide

14. デプロイ前の設定 デプロイ後の現物
    Lv 3. 意味論
    Lv 2. 個別項目
    Lv 1. 構文
    CFn Linter / Guard
    validate-template （不要）
    AWS Config
    Access Analyzer
    

    View Slide

15. Bucket Policy 編集画面で
    保存前にプレビューが可能
    

    View Slide

16. Allow:11.22.33.0/24
    Deny: 11.22.33.44/32
    なので、Allow の CIDR は
    Deny の CIDR からはみ出していて
    アクセスを許す余地がある
    

    View Slide

17. Allow と Deny の CIDR を
    入れ替えると Deny の方が広いため
    問題は検出されなくなる
    つまり、サブネットマスクの
    包含関係や複数 Statement の
    評価の「意味」を理解している
    

    View Slide

18. Section 1 のまとめ
    ● AWS のセキュリティ設定
    ○ 実際のデプロイより前に設定のみを検査したい
    ● 検査できる「間違い」にはレベル感がある
    ○ 単純：構文論 < ヒューリスティック < 意味論：複雑
    ● IAM Access Analyzer のプレビュー機能
    ○ デプロイ前に意味論的な検査が可能
    

    View Slide

19. いかにして結論を導出するか
    2.
    Solve Problems With a SAT/SMT Solver
    

    View Slide

20. 要素技術：SAT / SMT ソルバ
    

    View Slide

21. SAT ソルバ
    ● 命題論理の充足可能性（SATisfiability）を検査
    ○ 各変数に真 or 偽を割り当てて全体を真にできるか？
    ● 例 1：(p || q) && (p || !q) && (!p || !q)
    ○ 答：充足可能（p = True, q = False）
    ● 例 2：(p || q) && (p || !q) && (!p || !q) && (!p || q)
    ○ 答：充足不可能（どう割り当てても無理）
    

    View Slide

22. SMT ソルバ
    ● SAT ソルバは命題論理しか扱えない
    ○ 命題論理で書き直すと問題のサイズが爆発しがち
    ○ 元の問題の性質（例：不等号の推移性）が失われる
    ● 特定領域の理論ソルバを外部実装して組み合わせる
    ○ 整数の算術、文字列、ビット演算、など
    ○ && や || など論理部分は SAT ソルバが担当
    

    View Slide

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 の個数が合わない）
    

    View Slide

24. AWS における SMT ソルバの利用
    

    View Slide

25. Zelkova（本日のテーマ！）
    ● アクセス制御に関するクエリに答える
    ○ 例：S3 Object が外部アカウントから読み取り可能か？
    ○ 実際のアクセスは行わず、設定のみから推論
    ● 既成の汎用 SMT ソルバ Z3 をバックエンドに使用
    ○ Zelkova は IAM の「意味」を Z3 用に変換
    ○ 変換された問題を Z3 が解く
    

    View Slide

26. Tiros
    ● ネットワーク設定に関するクエリに答える
    ○ 例：EC2 インスタンス A から B に SSH 可能か？
    ○ 実際のパケットは送出せず、設定のみから推論
    ● SMT ソルバ MonoSAT をメインのバックエンドに使用
    ○ グラフに関する理論が実装されている
    ○ MonoSAT 以外にも Soufflé と Vampire を併用
    

    View Slide

27. AWS Dev Day Online 2021
    Tiros で登壇予定！
    

    View Slide

28. Section 2 のまとめ
    ● SMT ソルバによる充足可能性判定
    ○ 現実の問題に対して SAT ソルバのみだと力不足
    ○ 個別領域のソルバを別途用意して組み合わせる
    ● AWS でも SMT ソルバベースの機能を提供
    ○ Zelkova：アクセス制御に関する検査
    ○ Tiros：ネットワークに関する検査
    

    View Slide

29. いかにして意味を表現するか
    3.
    Encode the Semantics into Formulae for SMT Solver
    

    View Slide

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
    

    View Slide

31. Zelkova の論文概要
    ● 新規性：実際の IAM Policy 文法を直接検査できる
    ○ 既存研究は Policy 用の新規 DSL を提案するタイプ
    ● 評価：AWS における利用実績
    ○ Access Analyzer / Config / GuardDuty など
    ○ 1 日あたり数百万から数千万回のクエリ
    ○ 99 % のクエリは 160 ms 以内に応答
    

    View Slide

32. Zelkova の役割
    ● 検査のコア部分は既製品の SMT ソルバ Z3
    ● Zelkova は Policy の文法を Z3 用の入力にエンコードする
    Policy
    Z3
    Access Analyzer
    Zelkova
    

    View Slide

33. SMT ソルバ = 条件を満たす値の探索器
    

    View Slide

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) を許可
    

    View Slide

35. Zelkova の動作原理（2）
    ● X, Y：Policy が与えられたとき、以下の充足問題を考える
    A(X, p, a, r) && !A(Y, p, a, r)
    ● この論理式を充足する (p, a, r) が存在するとはつまり
    X は許可しているが、Y は許可していないアクセスが
    少なくとも 1 パターンは存在する
    ということである
    

    View Slide

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：ガードレールとして検査
    

    View Slide

37. 「A(X, p, a, r)：Policy X はアクセス (p, a, r) を許可」
    を SMT エンコードする問題に帰着
    

    View Slide

38. Policy の Statement への分解
    ● Allow Statement と Deny Statement に分けて
    Allow のどれかに合致 || Deny のどれにも合致しない
    Statement: [
    { Effect: Allow, ...},
    { Effect: Allow, ...},
    { Effect: Deny, ...},
    { Effect: Deny, ...},
    ]
    Deny 側に合致
    Policy に合致
    Allow 側に合致
    ||
    || !
    ||
    

    View Slide

39. Statement の個別項目への分解
    ● Principal / Action / Resource に対しては
    p, a, r がそれぞれ Statement 内の
    Principal / Action / Resource のどれかに合致
    ● Condition に対しては、各条件を SMT エンコードした上で
    p, a, r がそれぞれ Statement 内の Condition の
    すべてに合致
    

    View Slide

40. 「個別項目の条件 に p / a / r がそれぞれ合致する」
    を SMT エンコードする問題に帰着
    

    View Slide

41. SMT の理論ソルバの使い所
    ● 文字列の理論：ワイルドカード
    ○ prefixOf、surfixOf、contains を利用
    ● 正規表現の理論：大小文字の無視、ワイルドカードの一部
    ○ 特定の条件は文字列の理論だけでは書けない
    ● ビット演算の理論：CIDR の重複判定
    ○ CIDR をビットベクトルとしてエンコードする
    

    View Slide

42. ワイルドカードのエンコーディング
    ● SMT に内蔵された文字列専用の理論ソルバを使用
    Policy 上の表現
    Resource: foo*/bar*
    Resource: foo*/*bar
    SMT エンコーディング
    prefixOf(r, "foo") && contains(r, "/bar")
    prefixOf(r, "foo") && contains("/", r) &&
    surfixOf(r, "bar")
    

    View Slide

43. Case-Insensitive な条件の扱い
    ● SMT に内蔵された正規表現の理論ソルバを使用
    Policy 上の表現
    StringEqualsIgnoreCase:
    s3:prefix: UpLoad
    SMT エンコーディング
    matches(s3:prefix,
    /[uU][pP][lL][oO][aA][dD]/)
    

    View Slide

44. CIDR のエンコーディング
    ● SMT に内蔵されたビット演算専用の理論ソルバを使用
    Policy 上の表現
    aws:SourceIp:
    11.22.33.00/24
    SMT エンコーディング
    0x0B162100 =
    aws:SourceIp & 0xFFFFFF00
    

    View Slide

45. Zelkova の役割（再掲）
    ● 検査のコア部分は既製品の SMT ソルバ Z3
    ● Zelkova は Policy の文法を Z3 用の入力にエンコードする
    Policy
    Z3
    Access Analyzer
    Zelkova
    

    View Slide

46. Section 3 のまとめ
    ● 検査エンジン Zelkova
    ○ 独自 DSL ではなく IAM Policy をそのまま検査可能
    ● Policy を SMT ソルバ Z3 用にエンコード
    ○ 文字列、正規表現、ビット演算の理論ソルバを利用
    ● Z3 による less-of-equally-permissive 関係の判定
    ○ 検査したい Policy とガードレールとの強弱
    

    View Slide

47. 本日のまとめ
    4.
    Recapture the Session
    

    View Slide

48. 本日のまとめ
    ● Access Analyzer によるセキュリティ設定のテスト
    ○ デプロイ前に、設定の「意味」まで考えて検査したい
    ● SMT ソルバによる充足可能性判定
    ○ SAT ソルバ + 特定領域専用の理論ソルバ
    ● Zelkova によるエンコーディング
    ○ Policy を SMT ソルバ Z3 用の論理式に変換
    

    View Slide

49. Test Security by Logic!
    Presented By チェシャ猫 (@y_taka_23)
    

    View Slide