Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

2,102 views

Published on

第三回 vuls祭りの発表資料です。

Published in: Engineering

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

  1. 1. Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved. 3000台のサーバーを 毎日vulsでスキャンして Redmineでチケット管理した話 2017/10/19 NTTレゾナント株式会社 渡邉 理恵
  2. 2. Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved. • 自己紹介 • なまえ:渡邉 理恵 • 会社:NTTレゾナント株式会社 ソリューション事業部サービス基盤部門 • 業務:Openstackを使ったプライベートクラウド基盤の機能追加や運用 • レゾナントの紹介 • 自社サービス150くらい • 個人向け・法人向け はじめに 災害時 安否情報まとめて検索 ヘルスケア 個人向け 法人向け
  3. 3. Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved. 我々の管理体制 サービス担当 サービス担当 NTTレゾナント サービス担当 サービス担当 サービス担当 サービス担当 サービス担当 サービス担当 約150サービス 社内基盤提供 サービス担当 (アプリ開発) … ソリューション事業部 サービス基盤部門 • プライベートクラウドの上に約150のサービス • サービス担当チームとプライベートクラウド基盤の提供チームに分かれている 全社に対し、 ・3000台規模のプライベートクラウド基盤 ・監視システム ・脆弱性通知システム などを提供
  4. 4. Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved. 導入の目的 全社の脆弱性対応状況を把握して 速やかに対応を促せるようにしたい!
  5. 5. Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved. クラウド基盤 導入した環境について • 前提 • スキャン対象一覧 • サーバの一覧がopenstackで管理されている • すべてsshログイン可能 • 通知先一覧 • すでにある(各種の連絡先登録済み) サービス毎の連絡先サーバ一覧 vulsを導入すれば、脆弱性管理できそう スキャン
  6. 6. Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved. 導入に向けた課題 • サーバ数が多い… → スキャンの並列化 • 3000台のスキャンには1日以上かかった • 各サービスに通知する仕組み必要 → イベント管理 • 毎日、スキャン結果を生で渡してもそのうち見なくなる • 対応状況を管理できる仕組みがほしい → チケット化 • 対応ステータスやサービスとのやり取りを管理したい
  7. 7. Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved. 実現に向けたポイント1:並列化 • 毎日3000台以上スキャン • 各サーバにvulsを入れるのは困難… • まとめてスキャンするにも数が多くて、日が暮れる 200台 スキャンサーバを並列化 して時間短縮×15 スキャン 1台で2日 → 15台で3~4時間 並列スキャン機能はあるが、デ バッグログが混ざるので、一並列 でスキャンした
  8. 8. Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved. 実現に向けたポイント2:イベント管理(差分通知) • サービス担当者に通知して対応を促す仕組み • 最低限の必要な情報のみ通知をイベント管理 • 新しく脆弱性が見つかったとき • 脆弱性対応が完了したとき 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ファイル
  9. 9. Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved. 実現に向けたポイント3:チケット化 • 全社の対応状況を一覧化 • Redmineを使ってチケット化して管理する 脆弱性検知 (差分情報) 全体の進捗管理はチケットで実施 必要な情報だけチケット化する。 API叩く。
  10. 10. Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved. vulsと周辺システム • Vulsスキャン結果を集計し、redmineと連携させる機能を実装 サービス担当者 クラウド基盤 結果データベース メール通知 15並列でスキャン イベント管理(差分通知) チケット化
  11. 11. Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved. 導入後の状況 • 課題 • Redmineでのイベント管理だけだと、ある時点での対応状況が管理しづらい チケットだとサーバ毎の対応状況がわかりづらい。 タイトル:CVE-2017-xxx 対応ステータス …(略)… サーバ一覧: test-server1 test-server2
  12. 12. Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved. で、どのサーバに 何すればいいの? 脆弱性対応する人↓
  13. 13. Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved. 導入後の状況 見やすい! vulsrepoを導入
  14. 14. Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved. まとめ • 大規模環境で自動的に脆弱性管理を行なうための工夫 • 並列スキャンして時間短縮 • イベント管理(差分通知) • チケット管理して全体を把握 • vulsrepoを使って可視化すると対応が捗る
  15. 15. Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved. Tips(おまけ) • Vulsスキャン自動化のポイント「リポジトリ」 • 各サーバのyum参照先リポジトリ設定 • 設定が間違っているとtimeout待ちなどでめっちゃ時間がかかる(普通数分なのに1時間 くらいかかる) • リポジトリURLの先が切り替わると、キャッシュで一時的にスキャン失敗することがあ る • Yumリポジトリ側の設定 • Changelogの保管数が少なすぎると、取得できるChangelogの上限値を超えてしまい、古い脆弱性 の情報が取得できなくなる • 細かいけど、運用で困ったところ • 依存関係が解決できないパッケージがあると、脆弱性検知数がゼロになる? • うちはスキャン失敗として扱った( yum check update パッケージ名のところでError: があったら失敗扱いにした) • 独自でリポジトリを作ったり、自作rpmを入れているとハマる可能性あり
  16. 16. Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved. 今の悩みと今後の目標(おまけ) • スキャン用のサーバをコンテナ化したい • yumで管理されていないフレームワークも管理したい • システム構成を踏まえて、対応緊急度のトリアージを整理したい • やらなくていいサーバをどう分けるか?フロント?バックエンド??

×