Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

332f89cc697355902a817506b6995f2b?s=128

y_taka_23

July 18, 2021
Tweet

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)