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

セキュリティグループ/ファイアーウォール併用パターン


要求事項

K5でセキュリティを高めるための基本の設定である セキュリティグループ と合わせて、
ファイアーウォールにより不正アクセスなど不要な通信を明示的に拒否することで、
K5で構成したシステムのセキュリティを高めたいといった要求事項に対応するパターンです。



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

K5で提供されるセキュリティを高めるための２つの機能

K5では、セキュリティを高める機能として セキュリティグループ と ファイアーウォールが用意されています。
セキュリティグループは、アクセス制御ルールをあらかじめグルーピングし、そのグループ名を使用することで、
IPアドレスを意識せずアクセス制御設定を行うことができる機能です。

セキュリティグループ活用パターン に記載したとおり、 仮想サーバやロードバランサーを作成する時に、
グルーピングしたアクセス制御設定（=セキュリティグループ）を指定するだけで、
仮想サーバやロードバランサーの作成と同時にアクセス制御ができるようになります。
オートスケールで増設される仮想サーバに自動的にセキュリティグループを設定するといった使い方も可能です。

これに対して K5が提供するファイアーウォールでは、 セキュリティグループにはない機能として、
アクセス元やアクセス先等を明示して拒否する機能があります。
不正アクセスやサービス不能攻撃などに対しIPアドレス・ポートを使用して明示的に拒否したい場合には、
ファイアーウォールを設定することで特定の通信を拒否できるようになります。

セキュリティグループとファイアーウォールの指定方法の違いと使い分け

K5のセキュリティグループとファイアーウォールのルール指定方法の違いを以下に記載します。

項目セキュリティグループファイアーウォール
設定する対象仮想サーバやロードバランサー、
仮想サーバに付けられたポート
(仮想サーバに付けられたポートといった文脈の場合は、
ポートは、OpenStack用語でいわゆるネットワークインターフェースを指す)
仮想ルータ
通信方向の指定セキュリティグループを適用するサーバ等に対する
受信(ingress)、送信(egress)		－
通信相手の指定通信相手のIP/CIDR、相手のセキュリティグループ名送信元IP/CIDR、送信先IP/CIDR
プロトコル、
ポート番号		セキュリティグループを適用するサーバ等が
オープンするポート番号		送信元ポート番号、送信先ポート番号
アクション許可のみ許可、拒否
判定どれか1つでもルールにマッチした通信は許可優先順位にしたがってルールを判定し、
最初にマッチしたルールで許可、拒否

※その他設定項目は機能説明書を参照してください

上記の違いにより、K5でセキュリティを高めるそれぞれの機能は、

  1. 仮想サーバやロードバランサーのアクセス制御など、まず基本としてセキュリティグループを使用
  2. 不正アクセスやサービス不能攻撃などで特定ポート・通信先を拒否する場合などにファイアーウォールを使用

という使い分けを推奨します。

推奨するセキュリティグループとファイアーウォールの併用パターン

そこで実装サンプルでは、使い分けの例として、セキュリティグループとファイアーウォールを併用した設定例を記載します。

  • 仮想ルータにファイアーウォールを設定
    • 特定のIPアドレスからの通信をすべて拒否
    • すべてのアクセス元からロードバランサーに対して http (80/tcp) のアクセスを許可
    • その他すべて拒否

  • ロードバランサー用のセキュリティグループ "SG_LB" で、
    すべてのアクセス元から http (80/tcp) の受信を許可／ロードバランサーからWebサーバへの送信を許可

  • Webサーバ用のセキュリティグループ "SG_Web" で、
    アクセス元 "SG_LB" からのhttp (81/tcp) の受信を許可

※本パターンでは、ロードバランサーやWebサーバに必要な通信についてのみ記載しています。
実際の設定上は、仮想サーバの起動時に必要な情報であるメタデータを取得するための設定等が必要になります。
メタデータ取得のための設定については、インターネット接続パターン をご覧ください。
※Webサーバで待ち受けするポート番号は、後述する アクセス制御の多重化 の観点で、
ロードバランサーが待ち受けするポート番号とは別のポート番号にすることを推奨します。



構造 (イメージ図)



実装サンプル


１．セキュリティグループとファイアーウォールの設定内容

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

  • セキュリティグループ "SG_LB"
    http (80/tcp) の受信をすべて許可／セキュリティグループ "SG_Web"の http (81/tcp) への送信を許可
ルール
方向
オープン
ポート		ポート接続先セキュリティグループ
または CIDR		IPバージョン
カスタムTCPルール受信ポート80CIDR0.0.0.0/0IPv4
カスタムTCPルール送信ポート81セキュリティ
グループ		SG_WebIPv4

  • セキュリティグループ "SG_Web"
    セキュリティグループ "SG_LB" から http (81/tcp) への受信を許可
ルール
方向
オープン
ポート		ポート接続先セキュリティグループ
または CIDR		IPバージョン
カスタムTCPルール受信ポート81セキュリティ
グループ		SG_LBIPv4



　(2) ファイアーウォール
　　以下の内容で設定します。
　　ロードバランサーや仮想サーバを配備した内部ネットワークのセグメントは "192.168.1.0/24" とします。

  • 設定内容
no名前プロトコルIP
種別
アクションSrc
アドレス		Src
ポート
Dest
アドレス		Dest
ポート
1http_ngtcp4denyxx.1.2.3/32nullnullnull
2http_oktcp4allownullnull192.168.1.0/2480
3all_ngnull4denynullnullnullnull
  1. 特定の通信を拒否
    例として、特定のIPアドレス "xx.1.2.3/32" からの通信をすべて拒否
    ※手順では、後からこのルールを追加する手順例を記載
  2. インターネットに公開するサーバとポートを許可
    すべてのアクセス元から、ロードバランサーが存在するセグメントに対して、http (80/tcp) のアクセスを許可
    ※インターネットに公開する (グローバルIPアドレスを付与された) 仮想サーバに対してアクセス制御する場合は、
    仮想サーバのプライベートIPアドレスを指定
  3. その他すべて拒否
    ※ファイアーウォールでは、ポリシー内で自動的に「DENY ALL」ルールが最後尾に追加されます。これにより、許可ルールの定義されないトラフィックはデフォルトで遮断されます（ホワイトリスト方式）。本パターンでは説明上 "all_ng" ルールを追加していますが、"all_ng" のルールの内容は明示的に指定しなくてもファイアーウォールに適用されます。

  • 設定内容について

K5の仮想ルータで NATで付与したグローバルIPアドレスへのアクセス制限は、グローバルIPアドレスに対する元のプライベートIPアドレスの方に対して設定します。
上記の 構造 (イメージ図) の例の場合、ロードバランサーをインターネットに公開しているため、ロードバランサーにグローバルIPアドレスが付与されていますが、ファイアーウォールでアクセス制御を行う場合は、ロードバランサーのプライベートIPアドレスを使用します。

なおロードバランサーのIPアドレスは、無停止保守により、配備されたセグメントの範囲内で変わることがあります。（その場合、ロードバランサーのグローバルIPアドレスも変わります。）
そのため、ロードバランサーに対してファイアーウォールでアクセス制御する場合は、上記表の "http_ok" で定義した Dest アドレスのように、ロードバランサーを配備した内部ネットワークのセグメント "192.168.1.0/24" への送信に対して設定するようにします。


  • アクセス制御の多重化について

ロードバランサーに対してファイアーウォールでアクセス制御を行う場合は、上記のとおり、
ロードバランサーを設置するセグメントに対してアクセス制御を行います。
また、ロードバランサーは、Webサーバと同一のセグメントに配置する必要があります。
そのため、ロードバランサーの待ち受けポート番号とWebサーバの待ち受けポート番号を同一にしている場合で、
ファイアーウォールでロードバランサーの待ち受けポート番号を許可と設定すると、
ファイアーウォール上ではWebサーバの待ち受けポート番号が許可された状態になってしまいます。
Webサーバの待ち受けポート番号はセキュリティグループでアクセス制御されていますが、
Webサーバの待ち受けポート番号をロードバランサーと別にしておくことで、より安全性の高い状態になります。
このように、アクセス制御を多重化するという観点で、Webサーバの待ち受けポート番号は、
ロードバランサーの待ち受けポート番号とは別のポート番号とすることを推奨します。



２．ファイアーウォールのルール設定手順

以下の作業フローで、まず基本的な設定をした後、特定通信を拒否するルールを追加する手順を記載します。

(1)
FWルールの作成
→
(2)
FWポリシーの作成
→
(3)
FWポリシーを適用
→
(4)
追加ルールを作成
→
(5)
FWルールを追加



　(1) ファイアーウォールルールの作成
　　　以下のAPIに、設定項目(json)を設定し、それぞれ実行してください。


　　(a) "http_ok" ルールの作成

  • 設定項目(json)
項目
設定値
内容
$NAME"http_ok"任意の名称
$AC"allow"アクセス許可(allow)/拒否(deny)
$DESTINATION_PORT"80"送信先ポート番号
$PROTOCOL"tcp"tcp/udp/icmp
$AVAILABILITY_ZONE"jp-east-1a"アベイラビリティゾーン名
  • 実行API

curl -X POST -s $NETWORK/v2.0/fw/firewall_rules -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"firewall_rule": { "name": "'$NAME'" ,"action": "'$AC'", "destination_port": "'$DESTINATION_PORT'", "protocol": "'$PROTOCOL'", "availability_zone": "'$AVAILABILITY_ZONE'" }}' | jq .

  • 確認API

curl -s $NETWORK/v2.0/fw/firewall_rules -X GET -H "X-Auth-Token: $OS_AUTH_TOKEN" | jq .



　　(b) "all_ng" ルールの作成

  • 設定項目(json)
項目
設定値
内容
$NAME"all_ng"任意の名称
$AC"deny"アクセス許可(allow)/拒否(deny)
$AVAILABILITY_ZONE"jp-east-1a"アベイラビリティゾーン名
  • 実行API

curl -X POST -s $NETWORK/v2.0/fw/firewall_rules -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"firewall_rule": { "name": "'$NAME'" ,"action": "'$AC'", "availability_zone": "'$AVAILABILITY_ZONE'" }}' | jq .

  • 確認API

curl -s $NETWORK/v2.0/fw/firewall_rules -X GET -H "X-Auth-Token: $OS_AUTH_TOKEN" | jq .



　(2) ファイアーウォールポリシーの作成
　　　作成したルールをもとに、ファイアーウォールポリシーを作成します。
　　　設定した順に優先順位がつけられます。

  • 設定項目(json)
項目
設定値
内容
$NAME"testfwp"任意の名称
$FWR1(生成されたID)(a)のルール作成時に生成されたID
$FWR2(生成されたID)(b)のルール作成時に生成されたID
$AVAILABILITY_ZONE"jp-east-1a"アベイラビリティゾーン名
  • 実行API

curl -X POST -s $NETWORK/v2.0/fw/firewall_policies -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"firewall_policy":{"firewall_rules": [ "'$FWR1'", "'$FWR2'" ], "name": "'$NAME'", "availability_zone": "'$AVAILABILITY_ZONE'"}}' | jq .

  • 確認API

curl -s $NETWORK/v2.0/fw/firewall_policies -X GET -H "X-Auth-Token: $OS_AUTH_TOKEN" | jq .



　(3) ファイアーウォールポリシーを仮想ルータに適用
　　　作成しファイアーウォールポリシーを仮想ルータに適用します。

  • 設定項目(json)
項目
設定値
内容
$NAME"testfw"任意の名称
$FWP(生成されたID)ファイアーウォールポリシー作成時に生成されたID
$ROUTER_ID(生成されたID)ファイアーウォールポリシーを割り当てる仮想ルータのID
$AVAILABILITY_ZONE"jp-east-1a"アベイラビリティゾーン名
  • 実行API

curl -X POST -s $NETWORK/v2.0/fw/firewalls -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"firewall": {"name": "'$NAME'","firewall_policy_id": "'$FWP'", "router_id": "'$ROUTER_ID'", "availability_zone": "'$AVAILABILITY_ZONE'"}}' | jq .

  • 確認API

curl -s $NETWORK/v2.0/fw/firewalls -X GET -H "X-Auth-Token: $OS_AUTH_TOKEN" | jq .



　(4) 追加するルールを作成
　　　特定IPアドレスからの接続を拒否する "http_ng" ルールを作成します。

  • 設定項目(json)
項目
設定値
内容
$NAME"http_ng"任意の名称
$AC"deny"アクセス許可(allow)/拒否(deny)
$SOURCE_IP"xx.1.2.3/32"送信元IPアドレス
$PROTOCOL"tcp"tcp/udp/icmp
$AVAILABILITY_ZONE"jp-east-1a"アベイラビリティゾーン名
  • 実行API

curl -X POST -s $NETWORK/v2.0/fw/firewall_rules -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"firewall_rule": { "name": "'$NAME'" ,"action": "'$AC'", "source_ip_address":"'$SOURCE_IP'" , "protocol": "'$PROTOCOL'", "availability_zone": "'$AVAILABILITY_ZONE'" }}' | jq .

  • 確認API

curl -s $NETWORK/v2.0/fw/firewall_rules -X GET -H "X-Auth-Token: $OS_AUTH_TOKEN" | jq .



　(5) "http_ng" ルールをファイアーウォールポリシーに挿入
　　　特定IPアドレスからの接続を拒否する "http_ng" ルールをファイアーウォールポリシーに挿入します。

  • 設定項目(json)
項目
設定値
内容
$FWP_ID(生成されたID)挿入対象のファイアーウォールポリシーのID
$FWR_ID(生成されたID)作成した "http_ng" ルールのID
$INSERT_AFTER(生成されたID)後ろに挿入したい場合のルールID
本例の場合、設定なし
$INSERT_BEFORE(生成されたID)前に挿入したい場合のルールID
本例の場合、"http_ok" ルールのIDを設定

※INSERT_AFTERまたはINSERT_BEFOREは片方のみ指定で構いません。
　どちらも空白の場合、最上位（一番上）に挿入されます。
　どちらも指定された場合、INSERT_BEFOREが有効になりますが、
　仕様が明確ではないため、確実に順序を指定したい場合、片方のみご指定ください。

  • 実行API

curl -X PUT -s $NETWORK/v2.0/fw/firewall_policies/$FWP_ID/insert_rule -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"firewall_rule_id": "'$FWR_ID'" ,"insert_after": "'$INSERT_AFTER'", "insert_before": "'$INSERT_BEFORE'" }' | jq .

  • 確認API

curl -s $NETWORK/v2.0/fw/firewall_policies/$FWP_ID -X GET -H "X-Auth-Token: $OS_AUTH_TOKEN" | jq .



メリット・効果

本パターンを利用して、セキュリティグループとファイアーウォールを併用した場合のメリット・効果は以下の通りです。

  • ファイアーウォールで不正アクセス元等の特定通信を拒否する設定が可能となり、
    セキュリティグループのみの状態からセキュリティをさらに高めることが可能



注意事項

  • 本パターンは2017年6月時点のK5(IaaS)で動作検証しています。

  • ロードバランサのIPアドレスは変更されることがあるため、セキュリティグループでアクセス制御することを推奨します。
    ファイアーウォールのみでアクセス制御することは推奨しません。

  • セキュリティグループやファイアーウォールのルールの変更時、既に張られているセッションはルールを変更後もセッションが残ります。
    • DoS攻撃などで特定IPアドレスからの通信を拒否したい場合も、セッションが残っている間は新たなルールが適用されません。
      通信が許可されている状態です。
    • ルール変更後に張られた新規セッションは正常に拒否されます。
    • ファイアーウォールのルール適用時の全セッション強制切断機能は提供済です。

  • ファイアーウォール/ファイアーウォールポリシー/ファイアーウォールルールのIDは、
    サンプル等から絶対にコピーペーストしないでください。
    • 自プロジェクト以外のポリシーのID、またはルールのIDが設定されると、
      作成されたファイアーウォールは異常な状態となります。
      その状態になった場合、利用者での削除ができなくなり、
      K5基盤の管理者による削除が必要になります。

  • 本パターンでは、ロードバランサーやWebサーバに必要な通信についてのみ記載しています。
    実際の設定上は、仮想サーバの起動時に必要な情報であるメタデータを取得するための設定等が必要になります。
    メタデータ取得のための設定については、インターネット接続パターン をご覧ください。



その他


ファイアーウォール機能、セキュリティグループ機能の機能配置イメージ

K5 で提供する OpenStack ベースのファイアーウォール機能 や セキュリティグループ機能 は、
物理環境での構成と比較すると、仮想環境では以下のような機能配置のイメージになります。



関連資料

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

(2017年6月検証)