1. khayama

    Posted

    khayama
Changes in title
+IBM Cloud Security Groups について、まとめてみた
Changes in tags
Changes in body
Source | HTML | Preview
@@ -0,0 +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")