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

by y_taka_23

Slide 1

Slide 1 text

君のセキュリティはデプロイするまでもなく間違っている。 #CICD2021 #CICD2021_B チェシャ猫 (@y_taka_23) CI/CD Conference 2021 (3rd Sep. 2021)

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

いかにして設定を検査するか 1. Test Security Conﬁgurations on AWS

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

＼ IAM Access Analyzer ／

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

要素技術：SAT / SMT ソルバ

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

SMT ソルバ ● 例 1（整数の算術） ○ 問：x < y + 2 && x = 2 * z + 10 && y + z >= 10 ○ 答：充足可能（x = 12, y = 11, z = 1） ● 例 2（文字列） ○ 問：str ++ "b" = "a" ++ str ○ 答：充足不可能（先頭の a の個数が合わない）

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

Zelkova の動作原理（3） ● 逆に、先ほどの式が充足不可能、すなわち A(X, p, a, r) => A(Y, p, a, r) が常に成り立つとき、X は Y より「厳しい」ことになる ● この X と Y の関係を less-or-equally-permissive と呼ぶ ○ 直訳するなら「X は Y より非寛容」 ○ 実際には X：検査対象、Y：ガードレールとして検査

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

本日のまとめ 4. Recapture the Session

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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