1.
形式手法で捗る！
インフラ構成の設計と検証
チェシャ猫 (@y_taka_23)
JAWS-UG Night in AWS Summit Tokyo 2016 (2016/06/03)

2.
打倒、AWS 構成の秘伝のタレ化

3.
AWS 構成検証、例えば
● awspec
○ serverspec の拡張
○ テスト対象となる実際のリソースが必要
● IAM Policy Simulator
○ AWS 提供、IAM のアクセス権限を検証
○ 実際には操作・課金せず確認できる

4.
IAM 以外のサービスも
現物を使わずに検証したい

5.
形式手法という手がありますよ？

6.
形式手法って何だ？
● システムを厳密に定義・記述
● 仕様の正しさを数学的に保証
● テストと比較すると
○ テストケースの漏れが生じない
○ 一般的には学習・検証コストが高い

7.
学習・検証コストが高い…

8.
そこで Alloy Analyzer を使おう！

9.
Alloy Analyzer のいいところ
● 形式手法の一種、モデル検査器
○ 関係論理を用いてシステムのモデルを定義
○ モデルが満たすべき条件を記述
○ モデルを自動で全探索して、条件を検査
● 軽量 (lightweight) 形式手法を標榜
● 発見した例を可視化

10.
例えば EC2 インスタンス間の疎通
(https://gist.github.com/y-taka-23/89a98fdb2ba48710a39c)

11.
Alloy による単純なモデリング
sig Instance {
priIPs : some IP,
secGrps : set SecurityGroup,
}
sig SecurityGroup {
inRules : set InboundRules,
outRules : set OutboundRules,
}

12.
Alloy による単純なモデリング
sig Instance {
priIPs : some IP,
secGrps : set SecurityGroup,
}
sig SecurityGroup {
inRules : set InboundRules,
outRules : set OutboundRules,
}
各インスタンスに対して
1 個以上の IP アドレスが存在

13.
Alloy による単純なモデリング
sig Instance {
priIPs : some IP,
secGrps : set SecurityGroup,
}
sig SecurityGroup {
inRules : set InboundRules,
outRules : set OutboundRules,
}
各インスタンスに対して
0 個以上のセキュリティグループが存在

14.
もう少しモデルを作り込む
● セキュリティグループのルール内容
○ プロトコル (TCP, UDP, ICMP のいずれか)
○ ポート番号 (ICMP ならば存在しない)
○ CIDR と IP アドレスとの包含関係
● インスタンス間で通信可能な条件
○ インスタンスの IP アドレスと
ルールの IP アドレスとの包含関係

15.
条件を満たす例を全探索

16.
発見された具体例たち

17.
発見された具体例たち

18.
発見された具体例たち

19.
もっと実用的な検証を！
● 通信の到達可能性 / 不可能性
● 冗長なセキュリティグループの発見
● 複数 AWS サービス間の連携
● 設定変更時の安全な作業フロー

20.
まとめ
● インフラ設計に形式手法の力を
● Alloy Analyzer でお手軽検証
● アイデア次第で応用いろいろ

21.
Have a Nice Infrastructure!
Presented by
チェシャ猫 (@y_taka_23)