こんにちは。アドテクスタジオでセキュリティエンジニアをしている岡崎です。

　前回は、「AWS Management ConsoleへのSSO」について、紹介させていただきました。

　今回は、「アドテクスタジオのAWSにおけるセキュリティグループの整理の仕方」と「Scout2を使った可視化」をしてみたことについて、紹介させていただきます。

 

　今まで、ネットワークのセキュリティ設定「ファイアウォール」などはネットワークエンジニアが行っていました。しかし、AWSなどのパブリッククラウドを利用し始めてからは開発エンジニアがファイアウォール（AWSのセキュリティグループ）設定をする機会が増えており、今までファイアウォールの設定を経験をしていない開発エンジニアとっては設定に困ると思います。

　そんな中、見様見真似でセキュリティグループの設定をすると、、、あとあと、
「あれ、これはなんの設定？」
「このソースIPは、どこの顧客・パートナーのだろう？」
など、どんどんセキュリティグループやポリシーが増えていき、、、
　何が何だか分からなくなることありませんか。

セキュリティグループの設定が次第に煩雑になり、困ってませんか？

 

[よくある問題]

・似たようなポリシーが複数ある
例：　port22　を　特定IPで許可
　　　port全部を　特定IPで許可

・どこのソースIPか、なんのためのポート許可か分からなくなってしまう
例：　port 22を特定IPで許可したが、この特定IPは提携先のA社の？

・セキュリティグループのアタッチ状態がぐちゃぐちゃ
例：　このセキュリティグループを整理しようにも、このポリシーを削除したら、あっちのインスタンスに影響出ないかな、、、

など

よって、設定を変更するのが怖くなる。
その為、インスタンスによっては通常閉じておくべきポートが空いており、攻撃されることがあります。

 

アドテクスタジオ内では下記のようなセキュリティグループのパターンを活用しています。
[セキュリティグループの４つのパターン]

１、VPCの「default」のセキュリティグループの設定する
２、環境（本番・テスト・開発）ごとにセキュリティグループを設定する
３、ロール（インスタンスの役割）ごとにセキュリティグループを設定する
４、ミドルウェア（Apache httpd, MySQL, Node.jsなど）ごとにセキュリティグループを設定する
＊セキュリティの強度は、１ー＞２ー＞３ー＞４の順に高くなってます。
＊この中では、４が一番セキュリティ強度は高いですが、設定は煩雑になりがちです。

 

[４つのパターンの詳細]

パターン１：VPCの「default」のセキュリティグループの設定する
＊defaultはVPCを作成すると必ず作成される為、有効活用します。
主に会社の固定IPやデータセンターのIPなど、どのインスタンスに対しても共通で許可設定をします。

セキュリティグループ名	内容
default	会社の拠点IPなどの接続許可設定

 

パターン２：環境（本番・テスト・開発）ごとにセキュリティグループを設定する
・パターン１に加えて、本番・テスト・開発などの環境ごとにセキュリティグループを分ける考え方です。

セキュリティグループ名	内容
prod	本番環境に必要な許可設定
default	会社の拠点IPなどの接続許可設定

 

パターン３：ロール（インスタンスの役割）ごとにセキュリティグループを設定する
・パターン２に加えて、加えてフロント側・バックエンド側やシステム（バッチ処理系など）ごと、機能（メールサーバなど）ごとにセキュリティグループを分ける考え方です。

セキュリティグループ名	内容
frontend	フロント側に必要な許可設定
prod	本番環境に必要な許可設定
default	会社の拠点IPなどの接続許可設定

 

パターン４：ミドルウェア（Apache httpd, MySQL, Node.jsなど）ごとにセキュリティグループを設定する
・パターン３に加えて、ロールよりさらに細かいミドルウェアごとにセキュリティグループを分ける考え方です。

セキュリティグループ名	内容
mysql	MySQLに必要な許可設定
backend	フロント側に必要な許可設定
dev	開発環境に必要な許可設定
default	会社の拠点IPなどの接続許可設定

 

アドテクスタジオでは、このようにセキュリティの強度により４つに分けて、適切なパターンを利用していただいてます。

 

[上記以外のセキュリティグループ設定]

	パターン	サンプル
顧客拠点からのアクセス許可	$(顧客名)-$(日付)	from_partnerA-20170815
緊急対応の為一時的な許可	temp-$(接続元)-$(社員番号または氏名)-$(日付)	temp-from_mobile-userA-20170401

 

[Tagの活用]

セキュリティグループ名は初回にしか設定できない為、検索利便性向上のために既存のものにはTagを活用しましょう。

タグ名	内容	サンプル
Env	開発、テスト、ステージング、本番などの環境	prod test
Role	どのような役割なのか	frontweb mysql
Owner	作成した方の社員番号または氏名	userA
CreateDate	作成日	20170815

 

どうぞ、セキュリティグループを整理するときは、ぜひ参考にしてください。

 

[Scout2を使った可視化]

既存のセキュリティグループを整理するには、可視化するオープンソース「Scout2」というものもあります。弊社でもScout2を活用し、不要なセキュリティグループ・ポリシーを洗い出しに利用してます。

 

Scout2ホームページ：
https://nccgroup.github.io/Scout2/
https://github.com/nccgroup/Scout2

Scout2 のインストール方法

＊実行するには、対象のAWSのReadOnlyロールが必要になります。

＊Scout2ホームページの画像を参照

 

[利用しているセキュリグループの確認方法]

「Compute > EC2 > Security group」 の　各セキュリティグループ項目の「Usage」にて、どのインスタンスにアタッチされているか、または利用されていないかがわかります。

 

[その他のセキュリティグループ可視化ツール]

有料になりますが、以下のも見やすかったです。
・http://cloudcheckr.com/
・https://www.hava.io/
試用期間もあるので、ぜひお試しください。

 

まとめ

実際にScout2を利用し、不要なセキュリティグループの洗い出しを行って見ましたところ、かなりの量のセキュリティグループが利用されておらず、残っていることがわかりました。
その後、不要なものに関しては削除し、スッキリいたしました。
Scout2はインストールも簡単ですので、ぜひご活用ください。

今回セキュリティグループに関してまとめていく中で、AWS社様への要望が見つかりました。
「セキュリティグループのポリシー項目ごとにコメント欄を実装してくれると嬉しいです。」