Security Groups 概要

一言で言うと、「仮想サーバーに対する通信をIPベースでフィルタリングするサービス」

仮想サーバーで適用できるサービス（ベアメタルには使えません！）
イン/アウト両方の通信に対して適用可能
パブリック/プライベート両方の通信に対して適用可能
Security Groups の費用は、なんと無償！

以下のガイドを参照していきます。

Getting started with security groups

Security Group 詳細

単一もしくは複数の仮想サーバーのパブリックまたはプライベートNICに対して、Security Group を割り当てることが可能
IBM Cloudから提供されるデフォルトの Security Group または自作の Security Group を割り当てることが可能
Security Group を割り当てると、明示的にルールとして許可しない限り、割当先に関するイン/アウトの通信は拒否される
- つまり、deny all で allow rule をひとつひとつ追加してい形式
ステートフル。つまり、許可されたルールに関する戻りのパケットは暗黙的に許可される。
イン方向の通信はソースIPの範囲を制限可能。アウト方向の通信はデスティネーションIPの範囲を制限可能。
イン/アウト方向の通信の制限範囲として、他のSecurity Group を指定することも可能
- 例えば踏み台のSecurity Groupからしかアクセスさせないなどが可能
それぞれの Security Group に対して、任意のインとアウトのルールを設定可能。それぞれのルールには IPv4 と IPv6 の指定が可能。
通信プロトコルとしては、TCP、UDP、ICMP を指定してフィルタリングが可能

IBM Cloud から提供されるデフォルトルール

試しにこれらを使ってみたり、カスタマイズしたりすることから始めるのがよいでしょう。

allow_ssh
- TCP22番ポートへのイン方向の通信を許可します（ソースIPは0.0.0.0/0）
allow_http
- TCP80番ポートへのイン方向の通信を許可します（ソースIPは0.0.0.0/0）
allow_https
- TCP443番ポートへのイン方向の通信を許可します（ソースIPは0.0.0.0/0）
allow_outbound
- すべてのプロトコル/ポートへのアウト方向の通信を許可します（デスティネーションIPは0.0.0.0/0）
allow_all
- すべてのプロトコル/ポートへのイン方向の通信を許可します（ソースIPは0.0.0.0/0）

適用例

これらのルールを使うと例えば以下のようなことが可能。

アプリ開発者はWeb層にhttpsでのみアクセス
アプリ層にはWeb層からのみアクセスを許可
データベース層にはアプリ層からのみアクセスを許可

ガイドライン

Security Group を使うときは、以下の考慮すべきガイドラインがあります。

ルール

ルールが存在しない Security Group は、インとアウトのすべての通信をブロックするので注意が必要
少なくとも1つは通したいインとアウトのルールを定義してから適用するようにしましょう
ルールは、ホワイトリスト型として解釈する機能しか提供しない
Security Group の管理権限をもったユーザーのみが Security Group の作成、更新、および削除が可能
Security Group に関する変更は、その場で適用され、いつでも修正可能
Security Group 内のルールの順序は関係ない。優先されるのは、常に最も制限の少ないルールになる。
- たとえばソースIPが絞られたルールがあっても、ソースIP指定のない同様のルールがあれば、それが優先される。
- Security Group は、OSファイアウォールに上書きされるわけではないので、OSファイアウォールでより強固な内容が設定されていれば、そちらに従う。
Security Group 内の仮想サーバーが IBM Cloud 内部のサービス（パッチ、ストレージ、モニタリングなど）にアクセスする必要がある場合は、その定義が必要。
- 参照先 What IP ranges do I allow through the firewall?
- 参照先 Accessing Block Storage on Linux | IBM

インターフェース

Security Group は、パブリック/プライベート両方のインターフェースに対して適用可能
インターフェースに対して、複数の Security Group を割り当てることが可能
Security Group に割り当てられていない状態から、Security Group に割り当てるときに、初回のみ再起動が必要
- パブリックもプライベートも一度に割り当てれば、再起動は1回でよい
- 再起動後は、Security Group に関する変更は自動的に適用される
- オーダー時に割り当てることも可能

アクセス

アカウント内のすべてのユーザーは、アクセス可能な仮想サーバーについてはそのセキュリティグループの読み取り、接続、および切断を行うことができる
Security Group の管理権限を持つユーザーのみ、Security Group の作成、更新、および削除ができます
Security Group をベアメタルに割り当てることはできない

消去

仮想サーバーに割り当て済みの Security Group は削除できない
Security Group 内の1ルールの参照先として使用されている Security Group は削除できない

パフォーマンス上の制限

以下のように、いくつかのパフォーマンス上の制限があるので、要注意。

対象リソース	制限
1つのインターフェースに対する Security Group の数	5
1つのアカウントに対する Security Group の数	500
1つの Security Group に対するルールの数	50
1つの Security Group に対するリモートルールの数	5
1つの Security Group に対するインターフェースの数	100

※リモートルールとは、ルール内でソースあるいはデスティネーションとして Security Group が指定されているルールのこと

いつから使える？

8月頃からベータ版が提供されていましたが、11月にGAとなっている機能です。

How do I get access to the security groups beta for virtual servers on Bluemix? - dWAnswers

どこで使える？

2017/11/26 現在、利用可能なデータセンターは以下です。

$ slcli call-api SoftLayer_Network_SecurityGroup getSupportedDataCenters
:.........:..............:.......:..........:
:    id   :   longName   :  name : statusId :
:.........:..............:.......:..........:
:  142775 :  Houston 2   : hou02 :    2     :
:  224092 : Singapore 1  : sng01 :    2     :
:  352494 : Hong Kong 2  : hkg02 :    2     :
:  358694 :   London 2   : lon02 :    2     :
:  449604 :   Tokyo 2    : tok02 :    2     : # 東京でも使えます
:  449612 :   Sydney 1   : syd01 :    2     :
:  449610 :  Montreal 1  : mon01 :    2     :
:  449600 :   Mexico 1   : mex01 :    2     :
:  449596 : Melbourne 1  : mel01 :    2     :
:  448994 :  Toronto 1   : tor01 :    2     :
:  449500 :   Paris 1    : par01 :    2     :
:  449506 : Frankfurt 2  : fra02 :    2     :
:  814994 : Amsterdam 3  : ams03 :    2     :
:  37473  : Washington 1 : wdc01 :    2     :
:  154820 :   Dallas 6   : dal06 :    2     :
:  138124 :   Dallas 5   : dal05 :    2     :
:  815394 :   Milan 1    : mil01 :    2     :
:  983497 : Sao Paulo 1  : sao01 :    2     :
: 1004997 :  Chennai 1   : che01 :    2     :
: 1854895 :  Dallas 13   : dal13 :    2     :
: 1854795 :  Dallas 12   : dal12 :    2     :
: 1541257 :    Oslo 1    : osl01 :    2     :
: 2017603 : Washington 7 : wdc07 :    2     :
: 2013295 :   Sydney 4   : syd04 :    2     :
: 2017395 :   London 4   : lon04 :    2     :
: 2178495 :  San Jose 4  : sjc04 :    2     :
: 2017695 : Washington 6 : wdc06 :    2     :
:.........:..............:.......:..........:

実際の管理画面

ルールに設定できる内容

Direction
- Inbound
- Outbound
IP Type
- IPv4
- IPv6
Protocol
- TCP
- UDP
- ICMP
- All
- All TCP
- All UDP
- All ICMP
Destination / Source Type
- CIDR Block
- Security Group

詳細なログはみられる？

一般的なファイアウォールの Deny / Allow に関する詳細なログは、みられません！

ユーザー権限は？

「Manage Security Group」が追加。この権限をもったユーザーのみが Security Group の作成、更新、および削除が可能。
ただし、他のすべてのユーザーは、アクセス可能な仮想サーバーについてはその Security Groups の読み取り、接続、および切断を行うことが可能

権限ありユーザー

Security Group の作成、更新、および削除を含む全ての操作が可能

権限なしユーザー

Security Groups の読み取り、接続、および切断を行うことのみが可能
- Create Group や Security Group に対する Action のボタンがありませんね

変更が適用されるのはどれくらい？

Security Group 自体への割り当て、解除は仮想サーバーの再起動が必要。
ルールの追加、更新、削除はすぐに適用される！
- 実際にやってみたところ、数秒で適用された。
Security Group に割り当てられていない状態から、Security Group に割り当てるときに、初回のみ再起動が必要
- ただし、初回のみなので、それ以降は再起動不要で、すぐに変更が反映される

Security Group を適用して注文する方法は？

注文直前の（ホスト名などを入力する）画面で、デプロイ時の割り当てが可能。
たとえば、以下のようにパブリック側にアウトバウンドだけ許可するルールを定めたSecurity Groupに割り当てれば、いきなりインターネットに晒される危険はなくなります！
（ただし、デフォルトで注文すると Security Group は適用されません = Security Group なしの今まで通りの構成も可能。）

セカンダリIPが付いている場合はどうなる？

問題なく使える。
項目として、プライマリIP、セカンダリIPを意識するところはなし。

同じ Security Group にいる仮想サーバー間は通信できる？

ルールで許可されていない限り、通信できません。
ここはある意味、今までのファイアウォールと違いますね。
この状態を維持すれば、同じ Security Group にいても、不正な通信が横に拡がっていくことは防げます。
通信させたい場合は、明示的に以下のようなルールを追加しましょう。
たとえば、Outbound はすべてに対して許可し、Inbound は同じ Security Group からの通信は許可する。

ARPは通る？

はい、Security Groups では、ARPはフィルタリングされません。
対象は、あくまでTCP、UDP、ICMPでみることができるIPヘッダがあるパケットに限る。
ARP通信もフィルタリングしたい場合は、VLAN単位で分ける必要がある。

使ってみた感想

非常におすすめの機能なのでどんどん使いましょう！！！！！

データセンターごとにファイアウォールを立てる必要がないので安いし楽
- 仮想サーバーのみで高いセキュリティ要件がない場合は、Security Groups で十分。AWS に近づいているイメージ。
- クラウドらしく、スケーラビリティがある。1つの物理アプライアンスにしばられる必要がない
同一ポリシーで仮想的なグループをつくることができるので、上手く Security Groups を活用すれば、物理ネットワーク構成を意識することが少なく、ベーシックなルールであれば世界中のインスタンスに適用して管理できる
- ただし、サブネット単位でルールを切る場面が出てくるのでそこは配慮が必要（Global Group と Local Group をつくるなど）
初回以外は変更が即時反映されるので権限を与えるユーザーには注意が必要
- 操作ミスで簡単にノーガードになってしまうので、OSファイアウォールによる多層防御は必須
他のFirewallサービスコンポーネントとも併用が可能
- ただし、複雑になってしまうので本当に併用するかは要検討

【参考】APIからの操作

以下をご参照ください。

Softlayer_network_securitygroup - https://softlayer.github.io/

SoftLayer_Network_SecurityGroup | SoftLayer Development Network

IBM Cloud Security Groups について、まとめてみた