AWSのセキュリティグループを設定する機会があったのですが、その際にどういう単位でグループ分けを行うかで社内で2つに意見が分かれたので、備忘録として記載いたします。
結論は今のところ出ていないのですが、もし皆さんにコメントを頂くことができましたら、後ほどまとめさせて頂こうかと思っております。
はじめに
説明を分りやすくするため、下記のようなシステムにセキュリティグループを設定する場合を想定して話を進めます。
2台のWEBサーバのフロントにELBを、バックにMySQLを置いた構成となります。
Bastionサーバはインターネット側からのSSH接続をシステム内で唯一許可するサーバとなり、
他サーバへのSSH接続は、当サーバを経由してのみ可能とします。
ミドルウェア単位
ミドルウェアで単位にセキュリティグループを作成する考え方です。
上記システム例では、
セキュリティグループ名 | タイプ | ポート範囲 | ソース |
---|---|---|---|
ssh_private | SSH | 22 | 10.1.0.0/16 |
ssh_public | SSH | 22 | (接続元IP)/32 |
http_group | HTTP | 80 | ELB_group |
ELB_group | HTTPS | 443 | 0.0.0.0/0 |
MySQL_goup | MySQL | 3306 | 10.1.0.0/16 |
※(接続元IP) は、リモート接続する端末に設定されているIPとなります。
といったようにセキュリティグループを作成し、
各インスタンスには、
役割 | 適用グループ |
---|---|
WebServer01 | ssh_private / http_group |
WebServer02 | ssh_private / http_group |
踏み台サーバ | ssh_public |
DBサーバ | ssh_private / MySQL_group |
ELB | ELB_group |
といった具体で設定します。
個人的には、アウトバウンドの設定はどうなるんだろう? という疑問と、
1インスタンスにつき最大5(※)まで というセキュリティグループの制限が気になるところです。
ちなみにネットで検索すると、このようミドルウェア単位での設定で紹介されているサイトが多々あります。
社内でも、こちらが主流派(といっても 3 vs 1 ですが...) でした。
役割単位での設定例
各サービスの役割によってセキュリティグループを作成する考え方です。
セキュリティグループ名 | タイプ | ポート範囲 | ソース |
---|---|---|---|
web | SSH | 22 | bastion |
HTTP | 80 | elb | |
bastion | SSH | 22 | (接続元IP)/32 |
mysql | SSH | 22 | bastion |
MYSQL | 3306 | WEB / batsion | |
elb | HTTPS | 443 | 0.0.0.0/0 |
※(接続元IP) は、リモート接続する端末に設定されているIPとなります。
そして、各インスタンスに適用する場合は、
役割 | 適用グループ |
---|---|
WEBサーバ01 | web |
WEBサーバ02 | web |
踏み台サーバ | batsion |
DBサーバ | mysql |
ELB | elb |
という形とします。
こちらはポート番号とあわせて、「どこからの通信か」という所も明確に設定することとなるため、
サービス単位よりもセキュリティ的に厳しくなっています。アウトバウンドも役割毎で
設定ができることが多そうなので、サービスに適用するグループ数を抑えることができるメリットがありそうです。
まとめると
上記だけでは、「役割単位だよ」派の方が良さそうに思えますが、たぶん私が理解できていないメリット/デメリットがあるのでしょうか感覚的には、「役割単位」での設定をベースとして、それに当てはまらない物は個別に作成するハイブリッド運用になるのだろうなぁ とは思いますが、具体的にイメージができておりません。
もし、うちのプロジェクトはこうやっているよ や、こういう考え方もあるよ、 こういうメリットがあるよ などご意見を頂ければ思います。