3000台のサーバーを毎日vulsでスキャンしてRedmineでチケット管理した話

Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved.
3000台のサーバーを
毎日vulsでスキャンして
Redmineでチケット管理した話
2017/10/19
NTTレゾナント株式会社
渡邉理恵

• 自己紹介
• なまえ：渡邉理恵
• 会社：NTTレゾナント株式会社
ソリューション事業部サービス基盤部門
• 業務：Openstackを使ったプライベートクラウド基盤の機能追加や運用
• レゾナントの紹介
• 自社サービス150くらい
• 個人向け・法人向け
はじめに
災害時安否情報まとめて検索
ヘルスケア
個人向け
法人向け

我々の管理体制
サービス担当サービス担当
NTTレゾナント
約150サービス
社内基盤提供
サービス担当
(アプリ開発)
…
ソリューション事業部
サービス基盤部門
• プライベートクラウドの上に約150のサービス
• サービス担当チームとプライベートクラウド基盤の提供チームに分かれている
全社に対し、
・3000台規模のプライベートクラウド基盤
・監視システム
・脆弱性通知システム
などを提供

導入の目的
全社の脆弱性対応状況を把握して
速やかに対応を促せるようにしたい！

クラウド基盤
導入した環境について
• 前提
• スキャン対象一覧
• サーバの一覧がopenstackで管理されている
• すべてsshログイン可能
• 通知先一覧
• すでにある（各種の連絡先登録済み）
サービス毎の連絡先サーバ一覧
vulsを導入すれば、脆弱性管理できそう
スキャン

導入に向けた課題
• サーバ数が多い… → スキャンの並列化
• 3000台のスキャンには1日以上かかった
• 各サービスに通知する仕組み必要 → イベント管理
• 毎日、スキャン結果を生で渡してもそのうち見なくなる
• 対応状況を管理できる仕組みがほしい → チケット化
• 対応ステータスやサービスとのやり取りを管理したい

実現に向けたポイント１：並列化
• 毎日3000台以上スキャン
• 各サーバにvulsを入れるのは困難…
• まとめてスキャンするにも数が多くて、日が暮れる
200台
スキャンサーバを並列化
して時間短縮×１５
スキャン
1台で2日 → 15台で3～４時間
並列スキャン機能はあるが、デ
バッグログが混ざるので、一並列
でスキャンした

実現に向けたポイント２：イベント管理（差分通知）
• サービス担当者に通知して対応を促す仕組み
• 最低限の必要な情報のみ通知をイベント管理
• 新しく脆弱性が見つかったとき
• 脆弱性対応が完了したとき
CVE-2017-1111
CVE-2017-1112
CVE-2017-1113
CVE-2017-1114
CVE-2017-1115
CVE-2017-1111
CVE-2017-1112
CVE-2017-1113
CVE-2017-1114
CVE-2017-1115
CVE-2017-1116
前日の結果当日の結果
スキャン結果の差分のみ
通知する
比較
がんばってparseする。
jsonだからなんとかなる。
スキャン結果のjsonファイル

実現に向けたポイント３：チケット化
• 全社の対応状況を一覧化
• Redmineを使ってチケット化して管理する
脆弱性検知
（差分情報）
全体の進捗管理はチケットで実施
必要な情報だけチケット化する。
API叩く。

vulsと周辺システム
• Vulsスキャン結果を集計し、redmineと連携させる機能を実装
サービス担当者
クラウド基盤
結果データベース
メール通知
15並列でスキャン
イベント管理（差分通知）
チケット化

導入後の状況
• 課題
• Redmineでのイベント管理だけだと、ある時点での対応状況が管理しづらい
チケットだとサーバ毎の対応状況がわかりづらい。
タイトル：CVE-2017-xxx
対応ステータス
…(略)…
サーバ一覧：
test-server1 test-server2

で、どのサーバに
何すればいいの？
脆弱性対応する人↓

導入後の状況
見やすい！
vulsrepoを導入

まとめ
• 大規模環境で自動的に脆弱性管理を行なうための工夫
• 並列スキャンして時間短縮
• イベント管理（差分通知）
• チケット管理して全体を把握
• vulsrepoを使って可視化すると対応が捗る

Tips（おまけ）
• Vulsスキャン自動化のポイント「リポジトリ」
• 各サーバのyum参照先リポジトリ設定
• 設定が間違っているとtimeout待ちなどでめっちゃ時間がかかる（普通数分なのに1時間
くらいかかる）
• リポジトリURLの先が切り替わると、キャッシュで一時的にスキャン失敗することがあ
る
• Yumリポジトリ側の設定
• Changelogの保管数が少なすぎると、取得できるChangelogの上限値を超えてしまい、古い脆弱性
の情報が取得できなくなる
• 細かいけど、運用で困ったところ
• 依存関係が解決できないパッケージがあると、脆弱性検知数がゼロになる？
• うちはスキャン失敗として扱った（ yum check update パッケージ名のところでError:
があったら失敗扱いにした）
• 独自でリポジトリを作ったり、自作rpmを入れているとハマる可能性あり

今の悩みと今後の目標（おまけ）
• スキャン用のサーバをコンテナ化したい
• yumで管理されていないフレームワークも管理したい
• システム構成を踏まえて、対応緊急度のトリアージを整理したい
• やらなくていいサーバをどう分けるか？フロント？バックエンド？？

3000台のサーバーを毎日vulsでスキャンしてRedmineでチケット管理した話

More Related Content

What's hot

Viewers also liked

Similar to 3000台のサーバーを毎日vulsでスキャンしてRedmineでチケット管理した話

Recently uploaded

3000台のサーバーを毎日vulsでスキャンしてRedmineでチケット管理した話