#JTF2021 #JTF2021 AWS セキュリティは「論理」に訊け！ Automated Reasoning の理論と実践 チェシャ猫 (@y_taka_23) July Tech Festa 2021 (18th Jul. 2021)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#JTF2021 #JTF2021 まとめ 4 Recap the session

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

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