機能別セキュリティグループ#
本構成は東日本／西日本リージョン1・2向けとなります。
要求事項#
- Webサーバやtomcat等を搭載したAPサーバ、PostgreSQL等を搭載したDBサーバ、Zabbix等を搭載した監視サーバなど、異なる機能をもつサーバがある場合に、セキュリティを高めるためそれぞれのサーバで必要なルールのみ適用したい
対応するデザインパターン概要#
FJcloud-Oでは、システムのセキュリティを高める機能として、セキュリティグループという機能が提供されています。
セキュリティグループでは、仮想サーバに接続されたポートに対してパケットフィルタリングを行うことができます。
セキュリティグループには、以下の特徴があります。
- 利用者が任意に複数作成することが可能
- 仮想サーバに接続されたポートに対して、複数のセキュリティグループを割り当てることが可能
そこで、機能や用途ごとにセキュリティグループを作成して必要なルールを記載し、各サーバに割り当てることで、各サーバに対して必要最小限のルールを適用できるようになります。
本パターンでは、セキュリティグループを Webサーバ/APサーバ/DBサーバ/監視サーバ別に分けた実装例を記載しています。
Warning
セキュリティグループは機能や用途別に適切に分割しないと、不要なアクセス制御ルールが増えて、性能が劣化する場合があります。
詳細は、セキュリティグループの設定のアンチパターンについて をご覧ください。
構造 (イメージ図)#
以下は、Webサーバ/APサーバ/DBサーバ/監視サーバを、階層のないネットワークにフラットに配備して、セキュリティグループでアクセス制御を行っているイメージ図です。
このように、フラットな構成でもアクセス制御をかけられるのが セキュリティグループ の機能の特徴です。
また、本資料の 実装サンプル のように 接続先 を セキュリティグループ にしておくことで、セキュリティの多重防御を意図して その他 に記載のようにネットワーク構成を階層化しても、同じ セキュリティグループ の設定を使うことができます。
実装サンプル#
1. セキュリティグループの設定内容#
以下の内容で設定します。
セキュリティグループの設定方法については、インターネット接続パターン に記載の手順を参照してください。
(1) セキュリティグループ "SG_Web"#
http (80/tcp) の受信をすべて許可／セキュリティグループ "SG_AP" の 9001/tcp への送信を許可
| ルール | 方向 | オープン ポート |
ポート | 接続先 | セキュリティグループ またはCIDR |
IPバージョン |
|---|---|---|---|---|---|---|
| カスタムTCPルール | 受信 | ポート | 80 | CIDR | 0.0.0.0/0 | IPv4 |
| カスタムTCPルール | 送信 | ポート | 9001 | セキュリティグループ | SG_AP | IPv4 |
(2) セキュリティグループ "SG_AP"#
セキュリティグループ "SG_Web" から http (9001/tcp) への受信を許可／セキュリティグループ "SG_DB" の 5432/tcp への送信を許可
| ルール | 方向 | オープン ポート |
ポート | 接続先 | セキュリティグループ または CIDR |
IPバージョン |
|---|---|---|---|---|---|---|
| カスタムTCPルール | 受信 | ポート | 9001 | セキュリティグループ | SG_Web | IPv4 |
| カスタムTCPルール | 送信 | ポート | 5432 | セキュリティグループ | SG_DB | IPv4 |
(3) セキュリティグループ "SG_DB"#
セキュリティグループ "SG_AP" から http (5432/tcp) への受信を許可
| ルール | 方向 | オープン ポート |
ポート | 接続先 | セキュリティグループ または CIDR |
IPバージョン |
|---|---|---|---|---|---|---|
| カスタムTCPルール | 受信 | ポート | 5432 | セキュリティグループ | SG_AP | IPv4 |
(4) セキュリティグループ "SG_ZBX_AG"#
セキュリティグループ "SG_ZBX_SV" から 10050/tcp への受信を許可／セキュリティグループ "SG_ZBX_SV" の 10051/tcp への送信を許可
| ルール | 方向 | オープン ポート |
ポート | 接続先 | セキュリティグループ または CIDR |
IPバージョン |
|---|---|---|---|---|---|---|
| カスタムTCPルール | 受信 | ポート | 10050 | セキュリティグループ | SG_ZBX_SV | IPv4 |
| カスタムTCPルール | 送信 | ポート | 10051 | セキュリティグループ | SG_ZBX_SV | IPv4 |
(5) セキュリティグループ "SG_ZBX_SV"#
セキュリティグループ "SG_ZBX_AG" の 10051/tcp からの受信を許可／セキュリティグループ "SG_ZBX_AG" の 10050/tcp への送信を許可
| ルール | 方向 | オープン ポート |
ポート | 接続先 | セキュリティグループ または CIDR |
IPバージョン |
|---|---|---|---|---|---|---|
| カスタムTCPルール | 受信 | ポート | 10051 | セキュリティグループ | SG_ZBX_AG | IPv4 |
| カスタムTCPルール | 送信 | ポート | 10050 | セキュリティグループ | SG_ZBX_AG | IPv4 |
メリット・効果#
本パターンを利用して、セキュリティグループを機能別・用途別に分けた場合のメリット・効果は以下の通りです。
- サーバごとに必要最小限のポートのみ開放することが可能
- ルールを管理しやすくなることで設定ミスを抑止可能
- 同じ用途のサーバは同じセキュリティグループを割り当てることでルール数を抑えることが可能
- 接続先が「セキュリティグループ」のルールについては、仮想サーバの増減やIPアドレス変更など、ネットワーク構成変更に伴うセキュリティグループの修正作業が不要
注意事項#
-
本パターンは2017年6月時点のFJcloud-O 東日本／西日本リージョン1・2で動作検証しています。
-
セキュリティグループはプロジェクトをまたぐことができません。
同じ機能・用途でも、プロジェクトが異なれば別々に作成する必要があります。 -
本パターンでは、ロードバランサーやWebサーバに必要な通信についてのみ記載しています。
実際の設定上は、仮想サーバの起動時に必要な情報を取得するための設定 (*1,*2) や、仮想サーバをメンテナンスする際に sshでログインするための設定 (*1) 等が必要になります。
*1 仮想サーバは、起動時に、169.254.169.254/32 の 80/tcp から情報を取得しますので、その設定が必要です。
*2 169.254.169.254/32に接続する設定等については、『インターネット接続パターン』 をご覧ください。
その他#
セキュリティグループの設定のアンチパターンについて#
監視用のセキュリティグループで、本パターンでは、監視サーバ用の "SG_ZBX_SV" と、監視エージェント用の "SG_ZBX_AG" とで２つ作成しています。
これを、以下の "SG_ZBX" のように１つにまとめることも考えられます。
- セキュリティグループ "SG_ZBX"
セキュリティグループ "SG_ZBX" 内で 10050/tcp,10051/tcp の送受信を許可
| ルール | 方向 | オープンポート | ポート | 接続先 | セキュリティグループ またはCIDR |
IPバージョン |
|---|---|---|---|---|---|---|
| カスタムTCPルール | 受信 | ポート | 10050 | セキュリティグループ | SG_ZBX | IPv4 |
| カスタムTCPルール | 送信 | ポート | 10050 | セキュリティグループ | SG_ZBX | IPv4 |
| カスタムTCPルール | 受信 | ポート | 10051 | セキュリティグループ | SG_ZBX | IPv4 |
| カスタムTCPルール | 送信 | ポート | 10051 | セキュリティグループ | SG_ZBX | IPv4 |
このセキュリティグループを、Webサーバ/APサーバ/DBサーバ/監視サーバに適用すると、FJcloud-O の内部では以下のルールが生成されます。
- セキュリティグループ "SG_ZBX" の適用事例
セキュリティグループ "SG_ZBX" をWebサーバ/APサーバ/DBサーバ/監視サーバに適用した際に、それぞれのサーバに対して送信許可と受信許可として実際に生成されるルールの概要
本来は、必要なルールは上記表の ● のルールのみですが、セキュリティグループを SG_ZBX と１つにまとめてしまうことで、上記表の × の箇所のルールのように、多数の無用なルールが生成されてしまいます。
こうした送受信を１つにまとめた設定方法は、無用のルールが追加されてしまうため、アクセス制御面で望ましくありません。
以下の図では、上記表の中の無用なルールから、例として、上記表の ※ のルールを構成図で太線の赤矢印で示しています。
このように、本来は送受信する必要がない経路にまでルールが生成されて、アクセスが許可されてしまうことになりますので、セキュリティ上で問題となりえます。
さらに、ルールが多数生成されてしまうことにより、性能面で影響が懸念されます。
セキュリティグループ "SG_ZBX" を適用するサーバを増やしていくと、ルール数はサーバとポートと送受信方向の組み合わせの数の累乗で増えていくため、非常に多くのルールが生成されてしまうこととなり、性能面で深刻な影響を与えることにもなりかねません。
そのため、セキュリティグループの設定では、本パターンの 実装サンプル のように、送信の設定と受信の設定を適切に分けて記載するようお願いいたします。