SecurityGroup設定のポイント
AWSのインフラ設計にあたって、セキュリティグループの設計は結構重要だと思うのですが、あまり意識して設計されていないケースも見受けられます。
メンテナンス性が考慮されていないと、後々かなり変更しづらくなりますし、誤って設定してしまい障害を発生させてしまうことも起こりえます。
そこで今回は一般的なWebシステム構成をベースにSecurityGroupの設定のポイントを紹介したいと思います。
環境
以下のようなWebシステムを前提に考えてみます。
※赤枠がアタッチするセキュリティグループになります。
基本的な設定ポイント
サービスのRole（役割）ごとにSecurityGroupを作成する
内部通信の許可はSourceにSecurityGroupを定義する（IPで定義しない。VPNやDXなどで外部と接続するようなケースはこの限りではないです）
管理用通信（ssh、監視）などは扱うグループ（開発者、インフラなど）ごとにSecurityGroupを分けて管理する。ただし、デフォルトで付与できるSGは5つまでなので分けすぎにも気をつけてください
具体的な設定内容は以下に記載します。
以下は全てInBound通信の設定となります。
サービスの役割ごとに応じたセキュリティグループ
ELB、Webサーバ、RDSがあるためそれぞれにセキュリティグループを作成します
ELB-SG(sg-elbsg)
| Type | Protocol | Port Range | Source | Description |
|---|---|---|---|---|
| HTTP | TCP | 80 | 0.0.0.0/0 | webアクセス用 |
| HTTPS | TCP | 443 | 0.0.0.0/0 | webアクセス用 |
管理用通信（ssh、監視）のセキュリティグループ
開発者とインフラ担当という想定で2つのセキュリティグループを作成しました。
ここは関係者に応じて作ってください。
DEV-SG(sg-devsg)
| Type | Protocol | Port Range | Source | Description |
|---|---|---|---|---|
| SSH | TCP | 22 | xxx.xxx.xxx.xxx/32 | |
| SSH | TCP | 22 | xxx.xxx.xxx.xxx/32 |
INFRA-SG(sg-infrasg)
| Type | Protocol | Port Range | Source | Description |
|---|---|---|---|---|
| SSH | TCP | 22 | xxx.xxx.xxx.xxx/32 | |
| Custom TCP Rule | TCP | 1234 | xxx.xxx.xxx.xxx/32 | 監視用 |
セキュリティグループについては送信元をIPではなくSGを指定することができます。
そうすることで通信経路が分かりやすくなるので、メンテナンス性も向上します。
また、例えばDBへの通信をWebサーバのIPで許可していたりすると、何かしらでIPが変更されたもしくはオートスケールでサーバが増えた際に、接続できなくなるトラブルも発生します。
こうしたことからもできるだけIPやCIDRで設定しない方向で設計してもらえればと思います。
また、OutBoundの通信の制限については、所属している組織のセキュリティポリシーにもよるかと思いますが、セキュアになる反面、トラブル時に原因が分かりにくくなる場合もあるのでその点を注意して使用するかどうかを判断してもらえればと思います。
