この記事の前提
- セキュリティ対策はインフラDivが実施している。
- Linux で動く Web サービスを開発・運用している
あいさつ
こんにちは、インフラの市橋です。最近引っ越しました。
都会に引っ越してから徒歩に慣れた & リモートワーク主体で全然出勤しないので、
思い切って駅から遠い物件にしてみました。ほぼ同じ広さかつ築年数が若くなったのに1万円ほど家賃下がって最高です。
さて、今回はソフトウェアエンジニアリングにおける永遠の課題、セキュリティ対策を進めるための施策として、
脆弱性スキャンツールである Vuls の実行環境を (ほぼ) ワンコマンドでつくれるツールを作成したので紹介します。
Vuls についての説明
Vuls は Linux/Unix OS のパッケージマネージャによってインストールされたソフトウェアの脆弱性を診断するツールです。
ssh で検査対象にログインし、インストールされているソフトウェアのバージョン一覧を取得し、 CVE などの脆弱性データベースと照合し脆弱性の有無を判断します。
作ったもの
AWS アカウントに、 docker ベースの Vuls 実行環境をもつ EC2 サーバーを建てるツールを packer & terraform で作成しました。
特徴
とにかく Vuls 実行環境を各サービス用の AWS アカウントに、余計なリソースなしでササッと作成できることを目指しました。
また、結果がわかりやすいことも重要なため、 VulsRepo による結果の確認にも対応しています。
実装はとても単純で、 EC2 インスタンスが作成され、ユーザーデータで Docker, Vuls, VulsRepo の導入を行うだけです。
脆弱性データベースも sqlite3 形式のファイルとして EC2 インスタンス内にダウンロードします。
そのため、IGW, NAT, 踏み台, ALB などもユーザーが作成することになりますが、大抵のサービスの AWS アカウントには既にこれらがあるため、
一部の設定変更だけで済むはずという思惑です。
工夫
pakcer で予め脆弱性データベースダウンロード済みの AMI を作成
脆弱性データベースのダウンロードには、検査対象とする OS の量にもよりますが1時間以上かかるため、
あらかじめ AMI 化しておくことでセットアップを早めています。
利用者の利便性という面もありますが、ツール開発時の検証高速化という側面もありました。
セキュリティグループの自動生成、指定の両方に対応
Vuls は ssh によってサーバーにログインしスキャンを行います。
EC2 インスタンスへの ssh アクセスはセキュリティグループによって制限されているのが通常の運用ですが、
Vuls サーバーを建てるたびに新しいセキュリティグループが出来上がるのでは、そのたびに設定変更が必要になってしまいます。
そのため、予め Vuls 実行サーバー用セキュリティグループを作成してそこからの ssh を許可しておく運用を想定し、
Vuls サーバーへ割り当てるセキュリティグループの指定に対応しました。
それはそれとして、指定された IP からの接続を許可するようなセキュリティグループの自動生成も対応しました。
VulsRepo のログは CloudWatch Logs に流す
VulsRepo のログ管理の手間を発生させたくなかったので CloudWatch Logs に流すようにしました。
インフラ管理のコンポーネントに依存しなくても動かせる設計
これはどういうことかというと、
- 脆弱性 DB は自分たちで管理
- 現状 Vuls を動かす EC2 インスタンスに sqlite ファイルをダウンロード
- mysql などの RDBMS に脆弱性 DB のデータを挿入し、リモートで取得することもできるが、その環境をインフラから提供しない
- 結果も自分たちで管理
- 結果の集積も Vuls を動かす EC2 インスタンス内に行う
- Vuls は Server Mode にてスキャン結果の集約を行えるが、その環境をインフラから提供しない
ということです。
依存しないというのは前向きな表現で、 今回の施策がうまくいくかもわからないのに作ってもしょうがないからつくってない というのが実態です。
Vuls によるセキュリティスキャンが様々な場所で行われるなら、脆弱性 DB をインフラ管理にする、というのは考えています。
一方で、スキャン結果の集約を行うかは微妙なところです。サービスの脆弱性情報を、社内とはいえ関係ないエンジニアが見られる状況はあまり良くないためです。
モチベーション
以前から社内サーバーのセキュリティ対策状況を可視化したいという思惑はあり、過去に可視化するシステムを構築する取り組みも行われていましたが、現状は人に依存した状態であり、自動的に可視化する仕組みができていませんでした
この度、以下の2つの理由から、改めてセキュリティ対策状況の可視化に取り組むことになりました。
一つはクラウド移行に伴い、セキュリティ対策を各サービスごとに意識する必要性が高まったことです。
弊社は現在、オンプレから AWS へ絶賛移行中です。 AWS アカウントは各サービスごとに割り当てられることになっています。
すると、オンプレではネットワークの入り口に設置されていた防御システムがなくなり、その代わりとなるセキュリティ対策を各サービスの AWS アカウントごとに行う必要があります。
そのため、今までよりもサービス側エンジニアがセキュリティを気にしなければならないシチュエーションが増えると思われます。
もう一つに、 DX Criteria の測定を社内のいくつかのサービスで実施したことがあります。
セキュリティ対策を行っているかどうかは、セキュリティシフトのスコアとして現れることになります。
具体的な項目は以下です。
OSSのライブラリやミドルウェアを使用する際、それらの脆弱性情報を自動的モニタリング・警告・パッチ適用するための仕組みまたはサービス等を利用しているか。
上記の項目を満たすには、今回の紹介したような仕組みが必要だと考えました。
各サービスで数値を引き上げるための施策を打ちたい状況が増えると思われます。
以上のように、セキュリティを意識するようなイベントがいくつか起きているため、改善しようという意思のあるチームが手軽に行えるセキュリティ対策があれば、
弊社サービスのセキュリティが高まるだろうと考えました。
そして対策を行う上でまずは現状把握がなされている必要があるだろうと考え、まずは脆弱性診断を行うツールの利用法を検証しまとめる活動をはじめました。
その中で、いわゆる Web 脆弱性診断は OWASP ZAP のような OSS を CI/CD パイプラインで動かす (こちらはワンコマンドで可能) か、
それで不足ならば Vaddy のような SaaS を契約するのがいいだろうという結論に至りました。
しかし、サーバー内の脆弱性診断は以上のツールでは行えません。上記のようなツールにより脆弱性が検知されなければある程度安全ですが、ツールによって診断されていない脆弱性にも対処するならば、
ミドルウェアやライブラリの脆弱性対策も行うべきです。
それを行うツールとして日本語情報源もあり使いやすそうな Vuls を選定し、その実行環境を提供することにしました。
今後の展望のようなもの
とにかく実戦経験を積む
現状は啓蒙の段階です。
とりあえずツールとしては形になったため、一旦インフラ部署が所持している AWS アカウントに実行環境を作成し、各サービスのスキャンをインフラ主導で行っています。
次の段階として、実際にいずれかのサービスの AWS アカウントにて Vuls 実行環境を作成し、定期的にスキャンする体制を整えてもらおうと思っています。
そしてそこでの感触がよければ更に横展開……といったように進められればよいなと思っています。
実戦経験が積めたら
脆弱性データベース管理をインフラ側でも行うことを考えています。この管理を各サービスでやる必要性は特に無いためです。
現状、インフラ側としても役に立たないかもしれない脆弱性データベース管理を行いたくない、という力学が働いているため、役に立つのだからサービス側の負荷を減らそう、という流れにもっていきたいです。
最後に
セキュリティシフトレフトを手軽に実現できる状況を今後作り出していきたいです。
