1. khayama

    No comment

    khayama
Changes in body
Source | HTML | Preview
@@ -1,253 +1,253 @@
# 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に割り当てれば、いきなりインターネットに晒される危険はなくなります!**
![Kobito.Jhx4ES.png](https://qiita-image-store.s3.amazonaws.com/0/101361/87eaf0a3-a6e1-5832-eec5-aa54e73b0213.png "Kobito.Jhx4ES.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つの物理アプライアンスにしばられる必要がない
- 同一ポリシーで仮想的なグループをつくることができるので、VLANを意識することが少なく、ベーシックなルールであれば世界中のインスタンスに適用して管理できる
- ただし、サブネット単位でルールを切っていくのでそこは配慮が必要(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")