Blog

アドテクスタジオのAWSにおけるセキュリティグループ整理術とScout2


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

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

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

 

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

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

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

 

[よくある問題]

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

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

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

など

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

 

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

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

 

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

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

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

 

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

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

 

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

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

 

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

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

 

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

 

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

パターン サンプル
顧客拠点からのアクセス許可 $(顧客名)-$(日付) 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社様への要望が見つかりました。
「セキュリティグループのポリシー項目ごとにコメント欄を実装してくれると嬉しいです。」

Author

アバター
hajime

関連記事