今回は、今までの経験からセキュリティグループ(VPC)の設計方針の典型例を以下の3つにまとめてみました。
- VPC内のリソースは、すべてお互いに通信可能
- 1番運用が楽
- PublicやPrivateなサブネット内は、すべてお互いに通信可能
- オンプレに多いパターンなのでオンプレからの移行によく利用
- VPC内の必要な通信経路のみ許可
- セキュリティ要件が高い場合は必然的にこちらになる
尚、VPC内やPublic/Privateセグメント内で、すべてのリソース(EC2/ELB/RDS)が
お互いに通信できるようにするには、下記のように自分自信(セキュリティグループ)に対して
すべての許可をするようにしておけば可能です。
該当リソース(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
