Save 37% off PRO during our Black Friday Sale! »

ネットワークはなぜつながらないのか 〜インフラの意味論的検査を目指して〜 #AWSDevDay / AWS Dev Day Online Japan 2021

332f89cc697355902a817506b6995f2b?s=47 y_taka_23
September 30, 2021

ネットワークはなぜつながらないのか 〜インフラの意味論的検査を目指して〜 #AWSDevDay / AWS Dev Day Online Japan 2021

AWS Dev Day Online Japan 2021 で使用したスライドです。

許可しているはずのインスタンス間でなぜか通信が通らない、逆に意図しないアクセスが許可されていた、そしてこの種のデバッグはかなり辛い…! そんなときは、通信経路を自動でチェックしてくれる VPC Reachability Analyzer の出番です。この機能が面白いのは、チェックの際に実際に通信を行う必要がなく、いわば設定項目の「意味」を理解した上で結果を「推論」してくれる点。本講演では、背景となる数学的な理論や論文にも踏み込みつつ、AWS ネットワークの意味論を用いた検査技術を解説します。

イベント概要:https://aws.amazon.com/jp/about-aws/events/2021/devday/
ブログ記事:https://ccvanishing.hateblo.jp/entry/2021/09/30/213008
録画:https://www.youtube.com/watch?v=7C_GwGbb1gQ

332f89cc697355902a817506b6995f2b?s=128

y_taka_23

September 30, 2021
Tweet

Transcript

  1. ネットワークは なぜつながらないのか 〜インフラの意味論的検査を目指して〜 チェシャ猫 (@y_taka_23) ProofCafe AWS Dev Day Online

    Japan (30th Sep. 2021) Breakout Session G-4 (#AWSDevDay)
  2. 自己紹介 • 講演者:チェシャ猫 (@y_taka_23) ◦ 主に CloudNative 界隈で活動中 ◦ 感想は

    #AWSDevDay でツイートしてね! • Amazon Web Service (AWS) の関係者ではありません ◦ 本日の内容は論文その他の公開情報から構成したものです ◦ 最新の内部実装と一致していることを保証しません
  3. Reachability Analysis for AWS-Based Networks Backes J. et al. 2019

    https://d1.awsstatic.com/whitepapers/Security/Rea chability_Analysis_for_AWS-based_Networks.pdf
  4. 本日のコンテンツ • VPC Reachability Analyzer の概要 ◦ 自動でネットワークの到達可能性が検査できる • SAT

    ソルバと SMT ソルバ ◦ Reachability Analyzer の要素技術 • SMT ソルバによるネットワークのエンコーディング ◦ VPC の到達可能性をどうやって表現するのか
  5. VPC Reachability Analyzer Debug Your Network Configurations Automatically Section 1

  6. VPC Security group 1 Security group 2 Private subnet Y

    Private subnet X Instance A Instance B Instance C Ingress: 172.0.0.0/16:TCP22 Egress: 0.0.0.0/0:ALL Ingress: (no rules) Egress: 0.0.0.0/0:ALL SSH-able Non SSH-able 172.0.0.0/16
  7. ネットワークのトラブルシュート • 実際に通信してみて疎通を確認 ◦ ping、traceroute、telnet、nc や E2E テストなど ◦ 疎通できない箇所はわかっても修正方法はわからない

    • 実際の通信は行わず、設定状況を確認 ◦ マネジメントコンソールを眺めてアタリをつける ◦ 各種設定の「意味」を知っている必要がある
  8. つらい

  9. VPC Reachability Analyzer • ネットワークの到達性を全自動で検査 ◦ 送信元、送信先、ポート番号、プロトコルでパスを定義 ◦ 人間がセグメント毎に原因究明しなくて済む •

    実際にパケットの送出はせず、設定のみから検査 ◦ 設定が実際に発揮する効果の「意味」を理解している ◦ 修正すべき箇所も含めて (Blocked Path) 判定できる
  10. None
  11. None
  12. 到達可能な場合 ルートを回答 到達不可能な場合 原因となっているコンポーネントを回答

  13. 私見:インフラの自動検査水準 • Level 1:構文論的な検査 ◦ テンプレートが文法的に正しいか • Level 2:ルールベースの検査 ◦

    個別項目がルールに合致するか(例:0.0.0.0/0 は禁止) • Level 3:意味論的な検査 ◦ 設定が発揮する効果の「意味」まで考えて正しいか
  14. Section 1 のまとめ • VPC ネットワークのトラブルシュートの難しさ ◦ 設定項目の「意味」を人間が判断しつつ調べる必要性 • インフラの検査には「レベル感」がある

    ◦ 単純:構文論 < ルールベース < 意味論:複雑 • VPC Reachability Analyzer による到達可能性判定 ◦ 実際の通信テストではなく設定の「意味」ベースの検査
  15. SAT ソルバと SMT ソルバ Core Engines for Automated Reasoning Section

    2
  16. SAT ソルバ • 命題論理の充足可能性(SATisfiability)を検査 ◦ 各変数に真 or 偽を割り当てて全体を真にできるか • 例

    1:(P ∨ Q) ∧ (P ∨ ¬Q) ∧ (¬P ∨ ¬Q) ◦ 答:充足可能(P = True, Q = False が唯一解) • 例 2:(P ∨ Q) ∧ (P ∨ ¬Q) ∧ (¬P ∨ ¬Q) ∧ (¬P ∨ Q) ◦ 答:充足不可能(どう割り当てても全体は偽)
  17. SMT ソルバ • SAT ソルバは命題論理しか扱えない ◦ 命題論理に直接翻訳すると問題のサイズが爆発しがち ◦ 問題のドメイン知識(例:不等式の推移性)が使えない •

    特定ドメインの理論ソルバを別途実装して組み合わせる ◦ 整数の算術、文字列、ビットベクトル、など ◦ ∧ や ∨ など論理演算部分は SAT ソルバが担当する
  18. SMT ソルバ • 例 1(整数の算術) ◦ 問:(x < y +

    2) ∧ (x = 2z + 10) ∧ (y + z >= 10) ◦ 答:充足可能(例えば x = 12, y = 11, z = 1) • 例 2(文字列) ◦ 問:str ++ "b" = "a" ++ str ◦ 答:充足不可能(先頭の a の個数が合わない)
  19. どうやって組み合わせるのか?

  20. ((x > 0) ∨ (y - 2z ≧ 0)) ∧

    (¬(x > 0) ∨ (y = z)) ∧ (¬(x > 0) ∨ (z ≧ x)) もともと解きたい問題
  21. ((x > 0) ∨ (y - 2z ≧ 0)) ∧

    (¬(x > 0) ∨ (y = z)) ∧ (¬(x > 0) ∨ (z ≧ x)) (P ∨ Q) ∧ (¬P ∨ R) ∧ (¬P ∨ S) Boolean Abstraction P: x > 0 Q: y - 2z ≧ 0 R: y = z S: z ≧ x もともと解きたい問題 SAT ソルバで解く問題
  22. ((x > 0) ∨ (y - 2z ≧ 0)) ∧

    (¬(x > 0) ∨ (y = z)) ∧ (¬(x > 0) ∨ (z ≧ x)) (P ∨ Q) ∧ (¬P ∨ R) ∧ (¬P ∨ S) Boolean Abstraction P: x > 0 Q: y - 2z ≧ 0 R: y = z S: z ≧ x もともと解きたい問題 SAT ソルバで解く問題 P: True, Q: True R: True, S: True 真偽割り当ての可能性 充足可能
  23. ((x > 0) ∨ (y - 2z ≧ 0)) ∧

    (¬(x > 0) ∨ (y = z)) ∧ (¬(x > 0) ∨ (z ≧ x)) (P ∨ Q) ∧ (¬P ∨ R) ∧ (¬P ∨ S) Boolean Abstraction P: x > 0 Q: y - 2z ≧ 0 R: y = z S: z ≧ x もともと解きたい問題 SAT ソルバで解く問題 P: True, Q: True R: True, S: True 真偽割り当ての可能性 充足可能 理論ソルバで解く問題 Refinement x > 0, y - 2z ≧ 0, y = z, z ≧ x
  24. ((x > 0) ∨ (y - 2z ≧ 0)) ∧

    (¬(x > 0) ∨ (y = z)) ∧ (¬(x > 0) ∨ (z ≧ x)) (P ∨ Q) ∧ (¬P ∨ R) ∧ (¬P ∨ S) ∧ ¬(P ∧ Q ∧ R ∧ S) Boolean Abstraction P: x > 0 Q: y - 2z ≧ 0 R: y = z S: z ≧ x もともと解きたい問題 SAT ソルバで解く問題 理論ソルバで解く問題 x > 0, y - 2z ≧ 0, y = z, z ≧ x 充足不可能なので ¬(P ∧ Q ∧ R ∧ S) を SAT が学習
  25. ((x > 0) ∨ (y - 2z ≧ 0)) ∧

    (¬(x > 0) ∨ (y = z)) ∧ (¬(x > 0) ∨ (z ≧ x)) Boolean Abstraction P: x > 0 Q: y - 2z ≧ 0 R: y = z S: z ≧ x もともと解きたい問題 SAT ソルバで解く問題 P: False, Q: True R: True, S: True 真偽割り当ての可能性 充足可能 (P ∨ Q) ∧ (¬P ∨ R) ∧ (¬P ∨ S) ∧ ¬(P ∧ Q ∧ R ∧ S)
  26. ((x > 0) ∨ (y - 2z ≧ 0)) ∧

    (¬(x > 0) ∨ (y = z)) ∧ (¬(x > 0) ∨ (z ≧ x)) Boolean Abstraction P: x > 0 Q: y - 2z ≧ 0 R: y = z S: z ≧ x もともと解きたい問題 SAT ソルバで解く問題 P: False, Q: True R: True, S: True 真偽割り当ての可能性 充足可能 理論ソルバで解く問題 Refinement x ≦ 0, y - 2z ≧ 0, y = z, z ≧ x (P ∨ Q) ∧ (¬P ∨ R) ∧ (¬P ∨ S) ∧ ¬(P ∧ Q ∧ R ∧ S)
  27. ((x > 0) ∨ (y - 2z ≧ 0)) ∧

    (¬(x > 0) ∨ (y = z)) ∧ (¬(x > 0) ∨ (z ≧ x)) Boolean Abstraction P: x > 0 Q: y - 2z ≧ 0 R: y = z S: z ≧ x もともと解きたい問題 SAT ソルバで解く問題 P: False, Q: True R: True, S: True 真偽割り当ての可能性 充足可能 理論ソルバで解く問題 Refinement x ≦ 0, y - 2z ≧ 0, y = z, z ≧ x (P ∨ Q) ∧ (¬P ∨ R) ∧ (¬P ∨ S) ∧ ¬(P ∧ Q ∧ R ∧ S) x = 0 y = 0 z = 0 充足可能
  28. Lazy SMT (Online Integration) • 現在主流の手法は両ソルバが「オンライン」で連携 ◦ SAT ソルバの動作の途中でも理論ソルバを呼ぶ •

    制約伝搬(Theory Propagation) ◦ 理論ソルバの知識も使って SAT 側の論理式を単純化 • 矛盾からの節学習 (Conflict-Driven Clause Learning) ◦ 充足不可能だった原因をより狭く特定し SAT 側に追加
  29. AWS のどこで使われているのか?

  30. Tiros(本日のテーマ!) • ネットワーク設定に関するクエリに答える ◦ 例:EC2 インスタンス A から B に

    SSH 可能か? ◦ 実際のパケットは送出せず、設定のみから推論 • いくつかのサービスのバックエンドとして稼働中 ◦ VPC Reachability Analyzer、Amazon Inspector ◦ 一部のユーザには API を直接提供している
  31. Zelkova • アクセス制御に関するクエリに答える ◦ 例:S3 Object が外部アカウントから読み取り可能か? ◦ 実際のアクセスは行わず、設定のみから推論 •

    セキュリティ系のサービスに統合されている ◦ IAM Access Analyzer、AWS Config、Macie など ◦ 内部的には Lambda Function として稼働
  32. 参考:CI/CD Conference 2021 での Zelkova 解説スライド https://speakerdeck.com/ytaka23/cicd-conference-2021

  33. Section 2 のまとめ • SMT ソルバによる充足可能性判定 ◦ 現実の問題に対して SAT は表現力が足りない

    ◦ 個別ドメイン専用の理論ソルバを組み合わせる • AWS でも SMT ソルバベースの検査機能を提供 ◦ Tiros:ネットワークに関する検査 ◦ Zelkova:アクセス制御に関する検査
  34. ネットワークの意味論と検査 Interpret the Network Semantics for Effective Solvers Section 3

  35. Reachability Analysis for AWS-Based Networks Backes J. et al. 2019

    https://d1.awsstatic.com/whitepapers/Security/Rea chability_Analysis_for_AWS-based_Networks.pdf
  36. 3 種類のバックエンド候補 • Soufflé (https://souffle-lang.github.io) ◦ Datalog 言語(Prolog の亜種)の処理系 •

    MonoSAT (https://github.com/sambayless/monosat) ◦ グラフに関する理論を実装した SMT ソルバ • Vampire (https://vprover.github.io) ◦ 一階述語論理の自動定理証明器
  37. 各バックエンドのベンチマーク • Vampire は遅すぎて論外 • ほとんどのケースでは Soufflé より MonoSAT が速い

    • 10 万インスタンスで 数 100 秒から 1,000 秒 • MonoSAT は複数経路に弱い (Backes J. et al. 2019, Fig. 4)
  38. MonoSAT • グラフに関連する理論が実装された SMT ソルバ ◦ ユーザは「繋がる可能性があるエッジ」を入力 ◦ MonoSAT は「実際に繋げるエッジ」を解として返す

    ◦ 到達可能性の他にも最小スパニング木なども可能 • ビットベクトルの理論も実装している ◦ グラフの辺に重みが定義できるようになっている
  39. g = Graph() n1 = g.addNode() n2 = g.addNode() n3

    = g.addNode() e1 = g.addEdge(n1, n2) e2 = g.addEdge(n2, n3) e3 = g.addEdge(n1, n3) Assert(Not(And(e1, e2, e3))) Assert(Or(e1, e3)) Assert(g.reaches(n1, n3)) => e1: False, e2: False, e3: True n1 n2 n3 e1 e2 e3 • e1, e2, e3 の 3 辺のうち 少なくとも 1 辺は通行不能 • e1, e3 の 2 辺のうち 少なくとも 1 辺は通行可能 • n1 から n3 へは到達可能
  40. g = Graph() n1 = g.addNode() n2 = g.addNode() n3

    = g.addNode() e1 = g.addEdge(n1, n2) e2 = g.addEdge(n2, n3) e3 = g.addEdge(n1, n3) Assert(Not(And(e1, e2, e3))) Assert(Or(e1, e3)) Assert(g.reaches(n1, n3)) => e1: False, e2: False, e3: True n1 n2 n3 e1 e2 e3 • e1, e2, e3 の 3 辺のうち 少なくとも 1 辺は通行不能 • e1, e3 の 2 辺のうち 少なくとも 1 辺は通行可能 • n1 から n3 へは到達可能
  41. g = Graph() n1 = g.addNode() n2 = g.addNode() n3

    = g.addNode() e1 = g.addEdge(n1, n2) e2 = g.addEdge(n2, n3) e3 = g.addEdge(n1, n3) Assert(Not(And(e1, e2, e3))) Assert(Or(e1, e3)) Assert(g.reaches(n1, n3)) => e1: False, e2: False, e3: True n1 n2 n3 e1 e2 e3 • e1, e2, e3 の 3 辺のうち 少なくとも 1 辺は通行不能 • e1, e3 の 2 辺のうち 少なくとも 1 辺は通行可能 • n1 から n3 へは到達可能
  42. g = Graph() n1 = g.addNode() n2 = g.addNode() n3

    = g.addNode() e1 = g.addEdge(n1, n2) e2 = g.addEdge(n2, n3) e3 = g.addEdge(n1, n3) Assert(Not(And(e1, e2, e3))) Assert(Or(e1, e3)) Assert(g.reaches(n1, n3)) => e1: False, e2: False, e3: True n1 n2 n3 e1 e2 e3 • e1, e2, e3 の 3 辺のうち 少なくとも 1 辺は通行不能 • e1, e3 の 2 辺のうち 少なくとも 1 辺は通行可能 • n1 から n3 へは到達可能
  43. g = Graph() n1 = g.addNode() n2 = g.addNode() n3

    = g.addNode() e1 = g.addEdge(n1, n2) e2 = g.addEdge(n2, n3) e3 = g.addEdge(n1, n3) Assert(Not(And(e1, e2, e3))) Assert(Or(e1, e3)) Assert(g.reaches(n1, n3)) => e1: False, e2: False, e3: True n1 n2 n3 e1 e2 e3 • e1, e2, e3 の 3 辺のうち 少なくとも 1 辺は通行不能 • e1, e3 の 2 辺のうち 少なくとも 1 辺は通行可能 • n1 から n3 へは到達可能
  44. MonoSAT をどうやって使うのか?

  45. VPC ネットワークのエンコーディング • VPC のネットワークをグラフで表現する ◦ ノード:ネットワークコンポーネント ◦ エッジ:所属もしくはアタッチされている関係 •

    CIDR 等に条件がある部分をビットベクトルで表現 ◦ SecurityGroup や RouteTable など ◦ クエリと条件が合わない場合はエッジを繋がない
  46. VPC Security group 1 Security group 2 Private subnet Y

    Private subnet X Instance A Instance B Instance C Ingress: 172.0.0.0/16:TCP22 Egress: 0.0.0.0/0:ALL Ingress: (no rules) Egress: 0.0.0.0/0:ALL SSH-able Non SSH-able 172.0.0.0/16
  47. Instance A ENI A Security group 1 Subnet X Instance

    B ENI B Security group 2 VPC Instance C ENI C Subnet Y
  48. Instance A ENI A Security group 1 Subnet X Instance

    B ENI B Security group 2 VPC Instance C ENI C Subnet Y
  49. Query protocol: TCP srcAdr: 172.0.1.1 dstAdr: 172.0.2.1 port: 22 e1

    e2 e3 e4 Ingress: 172.0.0.0/16:TCP22
  50. Query protocol: TCP srcAdr: 172.0.1.1 dstAdr: 172.0.2.1 port: 22 e1

    e2 e3 e4 Assert( Implies( Or(srcAdr & 0xFFFF0000 != 0xAC000000, protocol != TCP, port != 22) , And(Not(e1), Not(e2)))) Ingress: 172.0.0.0/16:TCP22
  51. Instance A ENI A Security group 1 Subnet X Instance

    B ENI B Security group 2 VPC Instance C ENI C Subnet Y
  52. Instance A ENI A Security group 1 Subnet X Instance

    B ENI B Security group 2 VPC Instance C ENI C Subnet Y Security group 2
  53. なぜグラフ理論を採用したのか?

  54. SAT Modulo Monotonic Theories Bayless S. et al. 2015 https://ojs.aaai.org/index.php/AAAI/article/view/9755

  55. Boolean Monotonic Theory • 定義:Boolean Monotonic な理論 ◦ 変数が Boolean

    値のみを取り、各述語の各変数が False のとき成立するなら True に変えても成立する • 例:グラフの到達可能性 ◦ 新しくエッジを繋いでも(= False から True に変更) もとの状態で到達可能であればやはり到達可能
  56. Monotonicity による探索効率化 • 制約伝播の効率性 ◦ 未割り当て変数を仮に True として理論ソルバに投げる ◦ 充足不可能なら割り当て済みの範囲で既に矛盾がある

    • 学習の効率性 ◦ 論理式の組み合わせではなく個々の式が検査可能 ◦ 矛盾している式がピンポイントに学習できる
  57. Section 3 のまとめ • VPC ネットワークの SMT エンコーディング ◦ MonoSat

    はグラフに関する理論ソルバを持つ ◦ コンポーネントをノードで、接続をエッジで表現 ◦ 疎通に条件が要る部分はビットベクトルで表現 • Monotonicity による探索の効率化 ◦ 各変数の割り当てが False で成立すれば True でも成立
  58. 本日のまとめ Recap Section 4

  59. 本日のまとめ • VPC Reachability Analyzer の機能 ◦ 実際の通信ではなく設定の「意味」ベースの検査 • SMT

    ソルバ の仕組み ◦ SAT ソルバと個別ドメイン専用の理論ソルバが連携 • MonoSAT による VPC ネットワークの意味論的検査 ◦ グラフによる表現、Monotonicity による効率化
  60. Test Networks by Logic! Presented by チェシャ猫 (@y_taka_23)