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


# Security Groups 概要

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

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

![Kobito.nonCrV.png](https://qiita-image-store.s3.amazonaws.com/0/101361/01fda2c3-340a-a56d-0e2e-4f2576cebf2c.png "Kobito.nonCrV.png")


以下のガイドを参照していきます。
><a href="https://console.bluemix.net/docs/infrastructure/security-groups/sg_index.html#getting-started-with-security-groups" >Getting started with security groups</a>

#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層からのみアクセスを許可
- データベース層にはアプリ層からのみアクセスを許可

![Kobito.9SwSy6.png](https://qiita-image-store.s3.amazonaws.com/0/101361/c2b8fbff-ac1c-dffe-e678-4652d9114849.png "Kobito.9SwSy6.png")

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

##ルール

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

## インターフェース

- 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となっている機能です。

><a href="https://developer.ibm.com/answers/questions/395444/how-do-i-get-access-to-the-security-groups-beta-fo/" >How do I get access to the security groups beta for virtual servers on Bluemix? - dWAnswers</a>

# どこで使える？

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

```python:
$ 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     :
:.........:..............:.......:..........:

```

#実際の管理画面
![Kobito.cKDyO5.png](https://qiita-image-store.s3.amazonaws.com/0/101361/e1934497-cd15-6bad-c47e-42b481c14b81.png "Kobito.cKDyO5.png")

##ルールに設定できる内容
- 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

<img src="https://qiita-image-store.s3.amazonaws.com/0/101361/0e91d1c3-aaa3-602e-32a1-f7a62b9f4514.png" width="47%"><img src="https://qiita-image-store.s3.amazonaws.com/0/101361/4fbb4a9f-50b2-2f15-7cbb-a7291d420424.png" width="53%">
![Kobito.Mzfh3Y.png](https://qiita-image-store.s3.amazonaws.com/0/101361/13d0d156-cabb-280c-fc35-8280e5b9eeeb.png "Kobito.Mzfh3Y.png")


# 詳細なログはみられる？

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


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

![Kobito.CXlWXl.png](https://qiita-image-store.s3.amazonaws.com/0/101361/ac50ece4-053c-db75-f8a2-5b190d177bdc.png "Kobito.CXlWXl.png")

##権限ありユーザー
- Security Group の作成、更新、および削除を含む全ての操作が可能

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

![Kobito.skKsm9.png](https://qiita-image-store.s3.amazonaws.com/0/101361/efabebcf-6a10-37bf-1eca-3f0787cdbf0d.png "Kobito.skKsm9.png")


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

![Kobito.KLSpzS.png](https://qiita-image-store.s3.amazonaws.com/0/101361/9346701f-4b99-5d6b-d8cd-5f266e353fe8.png "Kobito.KLSpzS.png")
![Kobito.ReRAoz.png](https://qiita-image-store.s3.amazonaws.com/0/101361/61b83db8-4101-3fa8-1eee-da784252b412.png "Kobito.ReRAoz.png")
![Kobito.a0p4xI.png](https://qiita-image-store.s3.amazonaws.com/0/101361/1435f9e8-d8eb-cd89-1162-01ec83facf31.png "Kobito.a0p4xI.png")


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

![image.png](https://qiita-image-store.s3.amazonaws.com/0/101361/234b3ce2-4d1b-f465-6f5f-9fd74e5988f3.png)
![Kobito.zLVhOL.png](https://qiita-image-store.s3.amazonaws.com/0/101361/6a826ab2-a792-fa6e-dd3c-ca22bce307bb.png "Kobito.zLVhOL.png")

#セカンダリIPが付いている場合はどうなる？
**問題なく使える。**
項目として、プライマリIP、セカンダリIPを意識するところはなし。

#同じ Security Group にいる仮想サーバー間は通信できる？
**ルールで許可されていない限り、通信できません。**
ここはある意味、今までのファイアウォールと違いますね。
この状態を維持すれば、同じ Security Group にいても、不正な通信が横に拡がっていくことは防げます。
**通信させたい場合は、明示的に以下のようなルールを追加しましょう。**
たとえば、Outbound はすべてに対して許可し、Inbound は同じ Security Group からの通信は許可する。
![Kobito.AESLto.png](https://qiita-image-store.s3.amazonaws.com/0/101361/e8759eb1-5050-8d3a-1bbd-fae1e239d7a2.png "Kobito.AESLto.png")


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

# 使ってみた感想
非常におすすめの機能なのでどんどん使いましょう！！！！！

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

#【参考】APIからの操作
以下をご参照ください。

<a href="https://softlayer.github.io/classes/softlayer_network_securitygroup/" >Softlayer_network_securitygroup - https://softlayer.github.io/</a>

<a href="https://sldn.softlayer.com/reference/services/SoftLayer_Network_SecurityGroup" >SoftLayer_Network_SecurityGroup | SoftLayer Development Network</a>

#【参考】他のFirewallとの機能比較
![Kobito.7m0wDr.png](https://qiita-image-store.s3.amazonaws.com/0/101361/21f7fc7b-0f02-b416-f3ba-d7c336717323.png "Kobito.7m0wDr.png")