FUJITSU Cloud Service K5
IaaS 設計・構築ガイド（デザインパターン・実装サンプル集）

要求事項

Webサーバやtomcat等を搭載したAPサーバ、PostgreSQL等を搭載したDBサーバ、Zabbix等を搭載した監視サーバなど、
異なる機能をもつサーバがある場合に、セキュリティを高めるためそれぞれのサーバで必要なルールのみ適用したい、
といった要求事項に対応するパターンです。

対応するK5デザインパターン概要

K5では、システムのセキュリティを高める機能として、セキュリティグループという機能が提供されています。
セキュリティグループでは、仮想サーバに接続されたポートに対してパケットフィルタリングを行うことができます。

セキュリティグループには、以下の特徴があります。

• 利用者が任意に複数作成することが可能
• 仮想サーバに接続されたポートに対して、複数のセキュリティグループを割り当てることが可能

そこで、機能や用途ごとにセキュリティグループを作成して必要なルールを記載し、各サーバに割り当てることで、
各サーバに対して必要最小限のルールを適用できるようになります。

以下では、セキュリティグループを Webサーバ/APサーバ/DBサーバ/監視サーバ別に分けた実装例を記載しています。

構造 (イメージ図)

以下は、Webサーバ/APサーバ/DBサーバ/監視サーバを、階層のないネットワークにフラットに配備して、
セキュリティグループでアクセス制御を行っているイメージ図です。

このように、フラットな構成でもアクセス制御をかけられるのが セキュリティグループ の機能の特徴です。

また、本資料の 実装サンプル のように 接続先 を セキュリティグループ にしておくことで、
セキュリティの多重防御を意図して その他 に記載のようにネットワーク構成を階層化しても、
同じ セキュリティグループ の設定を使うことができます。

実装サンプル

１．セキュリティグループの設定内容

　　以下の内容で設定します。
　　セキュリティグループの設定方法については、インターネット接続パターン に記載の手順を参照してください。

• セキュリティグループ "SG_Web"
  http (80/tcp) の受信をすべて許可／
  セキュリティグループ "SG_AP" の 9001/tcp への送信を許可

• セキュリティグループ "SG_AP"
  セキュリティグループ "SG_Web" から http (9001/tcp) への受信を許可／
  セキュリティグループ "SG_DB" の 5432/tcp への送信を許可

• セキュリティグループ "SG_DB"
  セキュリティグループ "SG_AP" から http (5432/tcp) への受信を許可

• セキュリティグループ "SG_ZBX_AG"
  セキュリティグループ "SG_ZBX_SV" から 10050/tcp への受信を許可／
  セキュリティグループ "SG_ZBX_SV" の 10051/tcp への送信を許可

• セキュリティグループ "SG_ZBX_SV"
  セキュリティグループ "SG_ZBX_AG" の 10051/tcp からの受信を許可／
  セキュリティグループ "SG_ZBX_AG" の 10050/tcp への送信を許可

メリット・効果

本パターンを利用して、セキュリティグループを機能別・用途別に分けた場合のメリット・効果は以下の通りです。

• サーバごとに必要最小限のポートのみ開放することが可能
• ルールを管理しやすくなることで設定ミスを抑止可能
• 同じ用途のサーバは同じセキュリティグループを割り当てることでルール数を抑えることが可能

注意事項

• 本パターンは2017年6月時点のK5(IaaS)で動作検証しています。
  
  
• セキュリティグループはプロジェクトをまたぐことができません。
  同じ機能・用途でも、プロジェクトが異なれば別々に作成する必要があります。
  
  
• 本パターンでは、ロードバランサーやWebサーバに必要な通信についてのみ記載しています。
  実際の設定上は、仮想サーバの起動時に必要な情報を取得するための設定 (※1,※2) や、
  仮想サーバをメンテナンスする際に sshでログインするための設定 (※2) 等が必要になります。

その他

ネットワーク構成を変更した場合について

　　ネットワーク構成を、フラットな構造の 構造 (イメージ図) から、以下のように 2階層のネットワークに変更しても、
　　本資料の 実装サンプル のように 接続先 を セキュリティグループ にしてあるルールについては、
　　セキュリティグループの設定は同じ設定が使用可能です。

※ 2階層のネットワーク構成については、『2階層ネットワーク構成』 をご参照ください。

■ルータ 1つで 2階層ネットワーク構成に変更した例	■ルータ 2つで 2階層ネットワーク構成に変更した例

セキュリティグループの設定のアンチパターンについて

　　監視用のセキュリティグループで、本パターンでは、監視サーバ用の "SG_ZBX_SV" と、
　　監視エージェント用の "SG_ZBX_AG" とで２つ作成しています。
　　これを、以下の "SG_ZBX" のように１つにまとめることも考えられます。

• セキュリティグループ "SG_ZBX"
  セキュリティグループ "SG_ZBX" 内で 10050/tcp,10051/tcp の送受信を許可

　　このセキュリティグループを、Webサーバ/APサーバ/DBサーバ/監視サーバに適用すると、K5 の内部では以下のルールが生成されます。

• セキュリティグループ "SG_ZBX" の適用事例
  セキュリティグループ "SG_ZBX" をWebサーバ/APサーバ/DBサーバ/監視サーバに適用した際に、
  それぞれのサーバに対して送信許可と受信許可として実際に生成されるルールの概要

　　本来は、必要なルールは上記表の ● のルールのみですが、セキュリティグループを SG_ZBX と１つにまとめてしまうことで、
　　上記表の × の箇所のルールのように、多数の無用なルールが生成されてしまいます。

　　こうした送受信を１つにまとめた設定方法は、無用のルールが追加されてしまうため、アクセス制御面で望ましくありません。

　　以下の図では、上記表の中の無用なルールから、例として、上記表の ※ のルールを構成図で太線の赤矢印で示しています。
　　このように、本来は送受信する必要がない経路にまでルールが生成されて、アクセスが許可されてしまうことになりますので、
　　セキュリティ上で問題となりえます。

　　さらに、ルールが多数生成されてしまうことにより、性能面で影響が懸念されます。

　　セキュリティグループ "SG_ZBX" を適用するサーバを増やしていくと、ルール数はサーバとポートと送受信方向の組み合わせの数の
　　累乗で増えていくため、非常に多くのルールが生成されてしまうこととなり、性能面で深刻な影響を与えることにもなりかねません。

　　そのため、セキュリティグループの設定では、本パターンの 実装サンプル のように、送信の設定と受信の設定を適切に分けて記載するよう
　　お願いいたします。

関連資料

• FUJITSU Cloud Service K5 マニュアル
  http://jp.fujitsu.com/solutions/cloud/k5/document/
  
  • サービスご紹介資料
  • IaaS 機能説明書
  • IaaS サービスポータルユーザーズガイド
  • IaaS APIユーザーズガイド
  • IaaS APIリファレンスマニュアル
  • IaaS HEATテンプレート解説書