share facebook facebook2 twitter menu hatena pocket slack

2013.02.01 FRI

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

鈴木 宏康

WRITTEN BY鈴木 宏康

今回は、今までの経験からセキュリティグループ(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

こちらの記事はなかの人(suz-lab)監修のもと掲載しています。
元記事は、こちら

鈴木 宏康

鈴木 宏康

愛知県生まれ。東京工業大学大学院修士課程修了。在学時より、ベンチャー企業でインターネットに関する業務に携わり、現在はクラウド(主にAmazon Web Services)上での開発・運用を軸とした事業の、業務の中心として活躍。