はじめまして！技術開発部セキュリティグループの花塚です。
LIFULL Creators Blogにセキュリティグループが登場するのは初めてですね。
セキュリティグループでは、脆弱性診断や脆弱性の調査、セキュリティツールの開発など、幅広い業務を行っています。
今回は、脆弱性可視化基盤を開発した話を紹介したいと思います！ 主に開発の経緯から、技術的な構成、そして、これからのことについて、まとめています
セキュリティに関わる人にとって、少しでも参考になれば嬉しいです。
目次
目的と経緯
まずは、どんな目的と経緯から脆弱性可視化を実施することになったのかについて紹介します。
脆弱性情報をスムーズにエンジニアに届けたい
LIFULLでは、基本的にプロダクトにおける脆弱性対応は各部署に任せています。
そのため、どんな脆弱性がどのプロダクトに存在しているかが分かる仕組みはなく、セキュリティグループは日々脆弱性情報を監視し、エンジニアに対して注意喚起をするといったことしかできていませんでした。
もし、脆弱性情報を手に入れた時に、対応が必要なプロダクトがすぐに分かる仕組みがあれば、短時間で各部署に脆弱性対応を依頼することができますよね。
また攻撃コードが出回った時なども、よりスムーズに注意喚起できます。
「セキュリティグループが収集した脆弱性情報をスムーズにプロダクトの開発者達に届ける仕組みを作りたい」
そう思ったのが脆弱性可視化基盤を開発するきっかけの1つでした。
組織全体で継続的に脆弱性対応をしていく風土をつくりたい
継続的な脆弱性対応は、プロダクトを開発している企業の課題の１つです。
脆弱性対応の理想は、プロダクトを開発しているエンジニア自身が、脆弱性を定期的に確認し、対応することだと考えています。
しかし、多くの業務を抱える中で、脆弱性対応のために時間をあまり割くことができないのが現実だと思います。
時間の捻出以外にも「プロダクトにおける脆弱性をどのように確認するのか、優先して対応すべき脆弱性はどれか」などと、悩みは多いと思います。
脆弱性可視化基盤には、これらの課題や悩みを解決し、脆弱性対応に対するハードルを下げることで、継続的に脆弱性対応を促進していく意図があります。
脆弱性可視化基盤を支える技術
ここでは、脆弱性可視化基盤を支える技術について触れていきます。
機能
脆弱性可視化基盤の機能は、大きく2つあります。
脆弱性スキャン
以下を対象に脆弱性スキャンを行います。
- EC2インスタンス
- GitHubリポジトリ
- Docker Image
それぞれの仕組みについては、後半に詳しく説明します。
ダッシュボード
脆弱性スキャンの結果は、１つのダッシュボード上で閲覧することができます。
以下の条件で脆弱性の検索が可能です。
- CVE ID
- 攻撃コードの有無
- 脆弱性のSeverity
- GitHubリポジトリ名
- AWSアカウントID
- EC2インスタンスID
- Docker Image名
- Namespace
また、ダッシュボードにはMetabaseを使用しています。
MetabaseはUIがわかりやすく、とても使いやすいですよね。
閲覧を制限したいので、ダッシュボードは認証をかけています。
認証という面でもMetabaseは、あらかじめ機能(ldap認証など)を用意してくれるので便利です。
全体の構成図
省略しているものが多少ありますが、脆弱性可視化基盤の大まかな構成は以下のようになります。
これらの構成は、各脆弱性スキャンのパートから成り立っています。
脆弱性スキャンの仕組み
ここからは、主要機能である脆弱性スキャンの仕組みについて説明していきます。
EC2インスタンス
EC2インスタンスの脆弱性スキャンは、AWS Systems Manager(以下SSM) & AWS Athena (以下Athena) & Vulsの組み合わせで実現しています。
LIFULLには多数のサービスが存在するので、AWSアカウントの数も100強ほど存在します。対象アカウントは多数あるので、手動で設定する必要がある場合は、なるべく時間をかけないことが設計時の要件でした。
EC2インスタンスの脆弱性スキャンではAmazon Inspectorなども考えていましたが、各インスタンスにエージェントをインストールする必要があり、AWSアカウントの数を考えると時間がかかりすぎると断念しました。
SSMを選んだ理由は、エージェントをインストールする必要がある点はAmazon Inspectorと同じですが、エージェントがプリインストールされているAMIが複数存在しており導入がしやすかったのが決め手です。
これらの構成で脆弱性スキャンをするためにはいくつかのステップがあります。
まずは、インベントリのリソースデータの同期です。
SSMには、マネージドインスタンスのインベントリ情報を定期的に収集してくれる機能があります。
可視化対象の各アカウントに、この設定をしてもらうことで、インベントリ情報を１アカウントのS3に集約することができます。
この設定でS3に集約したインベントリ情報は、Athenaを用いることで検索することができます。各インスタンスが、どのようなミドルウェアを使用しているか知りたいときに便利ですよね。
Assume RoleとSSMのSDKを組み合わせて、インベントリ情報を取得するアプローチもありますが、１つのアカウントに権限が一時的とはいえ集中するのは避けたかったのでSSMで集約した情報をAthenaで検索する形を採用しています。
さて、集約したインベントリ情報ですが、これらを整形しVuls Serverへと投げれば脆弱性スキャンが可能になります。
Vulsは、localスキャンやsshを用いたスキャンなど以外にもServerモードが実装されており、こちらを採用しています。
最終的に、AthenaのSDKを用いたプログラム上からインベントリ情報を取得し、整形した後Vuls Serverへ投げるまでが脆弱性スキャンの大まかな流れになります。
GitHub
GitHubではGitHub Security Alertを使用しています。基本的に全リポジトリのSecurity AlertをONにし、APIを用いて取得しています。
こちらは特に変わったアプローチをとっているわけではないです。強いて言えばSecurity Alertで検知した脆弱性をExploitDBと突合して攻撃コードを検出しています。
Docker Image
Docker Imageはコンテナの脆弱性スキャナーであるTrivyを使用していますが、そのまま使っているのではなくPrometheus Exporterとして実装したkube-trivy-exporterを使用しています。
以前のエントリで紹介されていましたが、現在LIFULLの(ほぼ)すべてのサービスがKubernetesで動いています。
詳細については以下を参照ください。
Kubernetesで動いているアプリケーションの監視にはPrometheusを使用しているので、Prometheus Exporterとして実装しています。
kube-trivy-exporterは社内のKubernatesに関わるエンジニアにコンテナの脆弱性について相談したところ開発してくれました。
kube-trivy-exporterは定期的にクラスタ内をフルスキャンしオンメモリ上に結果を保存しています。最終的に結果はPrometheus Serverに集約されるので、好きなタイミングで取得しに行けばいいというわけです。
今後Kubernetesに移行するサービスは、自動的に脆弱性を見ることができるようになるので今後の活躍にも期待できますね。
工夫した点
オートスケールされたインスタンスの扱い
S3に集約されたインベントリ情報の中には、オートスケールされたインスタンスの情報も存在します。 同じAutoScaingGroupのインスタンスをスキャンすると脆弱性が重複してしまったり、無駄にスキャン回数が増えるので、同じ「aws:autoscaling:groupName」の値を持つインスタンスを１つだけ選抜しています。
Athenaのチューニング
Athenaを使用する場合は、料金や実行速度に注意が必要です。 読み込んだバイト数で料金がかかるため、なるべく読み込むサイズを減らしていかねばなりません。
インベントリのリソースデータの同期の設定で作成したAthenaのDatabaseはAWSアカウントIDなどでパーティションされていますので、それらをうまく使うことでより高速に、より低コストでクエリを実行することができます。 Athenaのベストプラクティスがありますので、興味のある方は以下を参照してください。
他にも工夫している点はありますが、長くなるので割愛させてください。
VulsなどのOSSを使用しているので、そもそも大したコストはかかりませんが、クエリのチューニングやスキャン回数を減らすことで、脆弱性スキャンがかなり低コストで実現可能となっています。
これからのこと
改めて脆弱性が可視化されたことで、いろいろとやることが見えてきました。
残存する脆弱性の対応方針・検証など、やることはさまざまです。
また、Webアプリケーションのようなミドルウェア以外のレイヤーの脆弱性スキャンも徐々に対応を進めていきたいと思います。
既にLIFULLでは、AppScanで動的スキャンを実施(手動脆弱性診断もやります)していますが、そのような脆弱性スキャナーをデプロイパイプラインの一部とする仕組みは確立されていません。
脆弱性の検知を早め、よりセキュアな状態でプロダクトが世の中にリリースされるように目指していきます。
最後になりますが、これからもLIFULLのセキュリティグループでは、セキュリティに関わる誰かのために活動をアウプットしていきますので、よろしくお願いします！
また、LIFULLではメンバーを募集しております！ カジュアル面談もありますのでご興味ある方は是非ご参加ください！
