2012年12月20日木曜日

セキュリティグループの方針を三つのパターンに分けてみた

スズキです。

今までの経験からセキュリティグループ(VPC)の設計方針の典型例を
以下の三つにまとめてみました。
  • VPC内のリソースは、すべてお互いに通信可能。
    • 運用は一番楽です。

  • PublicやPrivateなサブネット内は、すべてお互いに通信可能。
    • オンプレに多いパターンなのでオンプレからの移行によく使います。

  • VPC内の必要な通信経路のみ許可。
    • セキュリティ要件が高い場合は必然的にこうしてます。
ちなみに、VPC内やPublic/Privateセグメント内で、すべてのリソース(EC2/ELB/RDS)が
お互いに通信できるようにするには、下記のように自分自信(セキュリティグループ)に対して
すべての許可をするようにしておけばOKです。


該当リソース(EC2/ELB/RDS)に、このセキュリティグループをつけると、
お互いに、すべての通信ができるようになります。

VPC内のリソースは、すべてお互いに通信可能。


下記のようにVPC内のすべてのリソース(EC2/ELB/RDS)に上記のセキュリティグループ
("op-vpc"として作成)をつけます。


あとは、「VPC外」との通信のみ考えるだけとなります。

PublicやPrivateなサブネット内は、すべてお互いに通信可能。


下記のようにPublic/Privateサブネット毎のリソース(EC2/ELB/RDS)に上記の
セキュリティグループ("op-public/op-protected/op-private"として作成)をつけます。


あとは、「VPC外」と「サブネット間(というかセキュリティレベル間)」の通信のみ
考えるだけとなります。

VPC内の必要な通信経路のみ許可。


下記のようにリソース毎に必要なセキュリティグループ(fn-...)をつけます。


あとは、がんばるだけです。

"SUZ-LAB Formation"にも反映


suz-lab_operational-firewall.json


社内でCloudFormationで作成されるセキュリティグループ名の評判が悪い...
--------
http://www.suz-lab.com

0 コメント: