Vuls構成デザインパターン

この記事は、[Vuls Advent Calendar 2016](http://qiita.com/advent-calendar/2016/vuls)の2日目の記事です。

# はじめに
Vulsでシステムをスキャンする場合、対象となるシステムの特性に合わせた構成を考える必要があります。その中からいくつかデザインパターンとして考えてみました。

尚、こうすれば多分出来るであろうという妄想を含んでいます。追々やろうとは思っていますが、現時点で全部きちんと検証したわけではありません。また高セキュリティ環境では導入が難しいと思われるものもあるのでご容赦を。

# 1．ローカルサーバをスキャン

Vulsをインストールしたサーバ自身をスキャンする場合です。
~~尚、Vulsは現時点ではローカルに対してスキャンする場合もSSHで接続する必要があります。~~([~~issues #210~~](https://github.com/future-architect/vuls/issues/210)) 

- 2017/1/25 追記

**ローカルスキャンモードが追加されローカルに対してはSSH接続が不要になりました。**
[#291 Add local scan mode(Scan without SSH when target server is localhost)](https://github.com/future-architect/vuls/commit/bef29be50f870d4214a83a612d28595d21318da8)


[README.ja.mdより抜粋：Example: Scan via shell instead of SSH.](
https://github.com/future-architect/vuls/blob/master/README.ja.md#example-scan-via-shell-instead-of-ssh)
> ローカルホストのスキャンする場合、SSHではなく直接コマンドの発行が可能。
> config.tomlのhostにlocalhost または 127.0.0.1かつ、portにlocalを設定する必要がある。


# 2. リモートサーバをスキャン
Vulsはエージェントレスのため、スキャンしたいサーバにSSH接続するだけでチェックが行えます。そのためペネトレーションツールとは異なり、疑似攻撃を行うわけではないため**システムに影響を与えることなく安全にスキャンできます**。

![image](https://qiita-image-store.s3.amazonaws.com/0/54952/66c87117-390e-b9f4-6d0f-a7d4eb898072.png)

# 3. dockerコンテナをスキャン
dockerコンテナ内のスキャンを行う場合、「docker exec」コマンドを介してチェックします。そのためdockerコンテナ内にSSHデーモンは必要ありません。Vulsをインストールしたサーバ以外にリモートのサーバであっても同様にスキャン可能です。
また設定で「[全ての起動中のDockerコンテナをスキャン](https://github.com/future-architect/vuls/blob/master/README.ja.md#usage-scan-docker-containers)」とすることができ、オーケストレーションにより**コンテナの数が変動してもVulsの設定を都度変更することなく運用することができます**。

![image](https://qiita-image-store.s3.amazonaws.com/0/54952/f8e6e496-e1a6-4864-a672-8f701b30f882.png)


# 4.　複数のVulsサーバによる運用
複数のシステムを運用していて、それぞれが別々のネットワークに分離されているような環境の場合、個々のVulsサーバでスキャン時に出力されたJSONファイルを**一箇所に集めることで、横断的に分析**することができます。ネットワーク的にデータ転送ができるのであればSCPで、直接通信が難しいのであればMailや媒体を使った運用も考えられるでしょう。

<img width="80%" alt="image" src="https://qiita-image-store.s3.amazonaws.com/0/54952/1256d868-cb23-1a60-f107-83c8c5d4f178.png">

VulsRepoではresultsフォルダの下を参照していますが、フォルダの階層をそのままGUI上に再現します。そのためシステム毎にフォルダを作成しておき、そこに各システムから集めたJSONファイルを置くことで複数システムを横断して集計・分析することができます。

<img width="40%" alt="image" src="https://qiita-image-store.s3.amazonaws.com/0/54952/b98eb2fd-c237-bc9c-d15d-b11f695387e8.png">



# 5．インターネットから隔離された環境での運用
Vulsはスキャン時にyumやaptコマンドにより最新版パッケージのchangelogまたはupdateinfoの**情報を取得するためインターネットへのアクセス経路が必要**です。システムの構成またはポリシー上、外部へ直接アクセスできる経路がない場合は、システム内にローカルリポジトリサーバを構築しパブリックなリポジトリサーバのデータをミラーし、**システム内の各サーバはローカルリポジトリを参照する**ことでスキャンすることが出来るようになります。
このときローカルリポジトリサーバだけ外部へアクセス出来るようにするか、それすらも許されない場合はシステムの外で更新パッケージを取得しポータブルHDDなどの媒体経由でローカルリポジトリのデータをアップデートする運用方法が考えられます。

- 2016/12/12 実際に検証しました
    - [インターネット上のリポジトリへ直接アクセス出来ない環境でVulsを使ってスキャンする方法](http://qiita.com/usiusi360/items/b34d27c33192ef07caf0)

<img width="80%" alt="image" src="https://qiita-image-store.s3.amazonaws.com/0/54952/4a1deff2-29de-d5e3-7f1d-0fff28aa4819.png">


# 6.　外部ツールによる可視化
Vulsでチェックする対象が数百、数千台ともなると出力されるログも大量になります。また長期間に渡って分析したり、Vuls以外の構成情報とジョインして表示したい場合も出てくるでしょう。場合によってはレポート形式で出力したものを第３者に提出する必要がある場合もあります。
そういった場合は大量のデータの分析・ドリルダウンするのに適したBI系ツールを使ってダッシュボードを作ったり、静的なレポートを出力できるツールを使うと良いのではないかと思います。

その際、Vulsが出力したJSONデータをCSV形式に変換することで、様々なツールで取り込みやすくなります。Vuls Advent Calendar 3日目では、JSONデータからCSV形式に変換する具体的な方法と、出力されたデータを使ってEXCELでレポートを作成してみたいと思います。

- 2016/12/12 実施事例をリンクしました
    - [VulsのログをCSVにしてExcelで可視化する](http://qiita.com/usiusi360/items/b5f19346f3276a963eef)
    - [VulsのログをElasticSearchに取り込んで可視化する](http://qiita.com/usiusi360/items/28e40f7044db73c407bc)

<img width="80%" alt="image" src="https://qiita-image-store.s3.amazonaws.com/0/54952/24ff6dcc-99f7-8d16-c6cc-08c44dd002f3.png">

- Excelのピボットテーブルで集計した例
<img width="80%" alt="image" src="https://qiita-image-store.s3.amazonaws.com/0/54952/bbf639b6-33fb-6385-7630-79bc058f9a07.png">


- Amazon QuickSightで作ったダッシュボードの例
<img width="80%" alt="image" src="https://qiita-image-store.s3.amazonaws.com/0/54952/50af77d0-6352-bc72-6d68-8d4b947eb496.png">

# さいごに
システムの構成によってはVuls導入の時にネックになりそうな事例について、回避方針を記載してみました。Vulsが内部で使っているコマンドや外部との連携動作についてはREADME.mdに記載されています。それを元にうまく自システムに当てはめて運用していけるように工夫をしていけたらと思います。