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)
   

   View Slide

2. #JTF2021
   #JTF2021
   本日の目次
   ● AWS 上のセキュリティ設定の検査
   ○ 既存ツールと IAM Access Analyzer の違い
   ● SAT ソルバと SMT ソルバ
   ○ 設定をテストするための要素技術
   ● 検査エンジン Zelkova
   ○ IAM Access Analyzer の意味論と SMT ソルバとの接続
   

   View Slide

3. #JTF2021
   #JTF2021
   いかにして設定を検査するか
   1
   Test security configurations on AWS
   

   View Slide

4. #JTF2021
   #JTF2021
   セキュリティ系の設定のテスト
   ● 実際に AWS にデプロイする前にテストしたい
   ○ 設定にミスがあった時の影響が大きい
   ○ 実際のアクセスベースのテストで失敗した場合、すでに危険な状態
   ● CloudFormation をテストする既存のツール
   ○ aws cloudformation validate-template コマンド
   ○ CloudFormation Linter (cnf-lint)
   ○ CloudFormation Guard (cfn-guard)
   

   View Slide

5. #JTF2021
   #JTF2021
   私見：CloudFormation の検査水準
   ● Level 1：構文論的な検査
   ○ CloudFormation のテンプレートとして文法的に正しいか
   ● Level 2：ヒューリスティックな検査
   ○ 個別項目がルールに沿っているかどうか（例：0.0.0.0/0 は禁止）
   ● Level 3：意味論的な検査
   ○ 設定によって実際に発揮される効果の「意味」に踏み込んだ検査
   

   View Slide

6. #JTF2021
   #JTF2021
   設定の「意味」とは何か？
   

   View Slide

7. #JTF2021
   #JTF2021
   IAM Access Analyzer
   ● 過剰なアクセス権限を自動で検出してくれる
   ○ 外部（他の AWS アカウントなど）からのアクセス許可を発見
   ○ 現状の対応サービスは S3、IAM Role、KMS、Lambda Layer、
   SQS、Secret Manager
   ● 実際の適用前に検出が可能
   ○ 定期的なチェックも実行される（約 30 分ごと）
   ○ Config Rule と違って即時性・カスタムルールはないが、無料で簡単
   

   View Slide

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

   View Slide

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

   View Slide

10. #JTF2021
    #JTF2021
    Section 1 のまとめ
    ● AWS セキュリティの設定
    ○ 実際にデプロイを行う前に、設定そのものを検査したい
    ● 検査できるレベルの違い
    ○ 構文 < ヒューリスティック < 意味論
    ● IAM Access Analyzer
    ○ Policy 適用時の実際の影響を考えた、意味論的な検査が可能
    

    View Slide

11. #JTF2021
    Automated Reasoning
    自動化された推論
    

    View Slide

12. #JTF2021
    #JTF2021
    いかにして問題を解くか？
    2
    Solve problems with a SAT/SMT solver
    

    View Slide

13. #JTF2021
    #JTF2021
    要素技術：SAT/SMT ソルバ
    

    View Slide

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 にならない）
    

    View Slide

15. #JTF2021
    #JTF2021
    SMT ソルバ (Satisfiability Modulo Theory)
    ● SAT ソルバは命題論理しか扱えない
    ○ 仮に命題論理で記述可能であっても、問題のサイズが爆発しがち
    ○ 元の問題の性質が利用できない（例：a < b かつ b < c なら a < c）
    ● 特定領域の理論に関する推論を別途実装
    ○ 中身を考えない関数 (EUF)、整数・有理数の算術、文字列操作、
    正規表現、ビット演算、配列の添字アクセス、量化子、など
    ○ !、&&、|| など論理演算部分については SAT ソルバが担当する
    

    View Slide

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 の個数を考えるとわかる）
    

    View Slide

17. #JTF2021
    #JTF2021
    AWS における SMT ソルバの利用
    

    View Slide

18. #JTF2021
    #JTF2021
    Zelkova: AWS x SMT ソルバその 1
    ● アクセス制御に関するクエリに答える
    ○ 例：S3オブジェクトが他の AWS アカウントから読み取り可能か？
    ○ 実際のアクセスは行わず、設定のみから推論
    ● バックエンドの SMT ソルバは Z3
    ○ 正規表現周りに AWS 独自の最適化入り（Z3Automata）
    ● Access Analyzer、Config、IoT Device Defender、
    Macie、Trusted Advisor、GuardDuty に統合
    

    View Slide

19. #JTF2021
    #JTF2021
    Tiros: AWS x SMT ソルバその 2
    ● ネットワーク設定に関するクエリに答える
    ○ 例：EC2 インスタンス A から B に SSH 接続可能か？
    ○ 実際のパケットは送出せず、設定のみから推論
    ● バックエンドの SMT ソルバは MonoSAT
    ○ グラフに関する理論が実装されている
    ● VPC Reachability Analyzer、Inspector に統合
    

    View Slide

20. #JTF2021
    #JTF2021
    Section 2 のまとめ
    ● SMT ソルバによる充足可能性判定
    ○ 問題によっては SAT ソルバ（命題論理）のみだと力不足
    ○ 特定の理論に関するソルバを個別に実装して組み合わせる
    ● AWS でも SMT ソルバベースの検査器を開発・利用
    ○ Zelkova：リソースへのアクセス権限の検査
    ○ Tiros：ネットワーク設定の検査
    

    View Slide

21. #JTF2021
    #JTF2021
    いかにしてポリシを表現するか？
    3
    Encode policies into the SMT format
    

    View Slide

22. #JTF2021
    #JTF2021
    Semantic-based Automated Reasoning for
    AWS Access Policies using SMT
    J. Backes et al. (2018)
    

    View Slide

23. #JTF2021
    #JTF2021
    Zelkova の論文概要
    ● 新規性：従来の IAM Policy 文法を検査できる
    ○ 先行研究は「検査可能な Policy 用の DSL を提案する」系
    ● AWS における利用実態
    ○ 前述の通り、複数のセキュリティ系 AWS サービスと連携
    ○ Lambda Function として稼働、JSON API を提供
    ○ 1 日あたり数百万から数千万回のクエリ
    ○ 99 % のクエリは 160 ms 以内に応答（JSON パース込み）
    

    View Slide

24. #JTF2021
    #JTF2021
    IAM Policy を SMT ソルバ向けに変換したい
    

    View Slide

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)}}
    

    View Slide

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)
    

    View Slide

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 が許可してしまう例
    

    View Slide

28. #JTF2021
    #JTF2021
    Section 3 のまとめ
    ● 検査エンジン Zelkova
    ○ 独自 DSL ではなく、従来の IAM Policy を高速で検査可能
    ● Policy を SMT ソルバに与えられる形式に変換
    ○ ワイルドカード：文字列、正規表現
    ○ CIDR：ビット列の演算
    ● SMT ソルバ Z3 による検査
    ○ 反例の探索により、ガードレールより「厳しい」ことを確認
    

    View Slide

29. #JTF2021
    #JTF2021
    まとめ
    4
    Recap the session
    

    View Slide

30. #JTF2021
    #JTF2021
    本日のまとめ
    ● セキュリティ系設定の検査
    ○ デプロイ前に、設定の「意味」まで考えて検査したい
    ● SMT ソルバによる充足可能性の判定
    ○ 整数の計算や文字列の性質など、特定のドメインの理論を実装
    ○ 解きたい問題が SMT ソルバ用にエンコードできれば自動で解ける
    ● 検査エンジン Zelkova
    ○ IAM Policy の「意味」を SMT ソルバ用にエンコード
    

    View Slide

31. #JTF2021
    #JTF2021
    Make the Security Provable!
    Presented by チェシャ猫 (@y_taka_23)
    

    View Slide