Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Amazon Inspector v2で脆弱性管理を始めてみた
Ähnlich wie Amazon Inspector v2で脆弱性管理を始めてみた (20)
Mehr von cluclu_land
Amazon Inspector v2で脆弱性管理を始めてみた
- 1. Amazon Inspector v2で 脆弱性管理を始めてみた 2022年12月20日 chocopurin nakanoshima.dev #33 - LT Night !
- 2. 自己紹介 ⚫ 名前：chocopurin ⚫ 職業：とある企業の一般社員 ⚫ 主なお仕事歴 ○ 某SIer サーバ構築, 認証ツール開発, システム開発ルールの策定 コンテナの研究, Webアプリ脆弱性診断 ○ 現職 ITインフラの構築/維持管理, セキュア開発基盤の整備, 永遠のAWS見習い ⚫ 直近の出没歴 AWSエバンジェリストシリーズ, 総関西サイバーセキュリティLT大会 Security-JAWS, OWASP Kansai, レトロゲーム勉強会 etc
- 5. システムとLT内容の範囲 だいたい この辺 【出典】 新人エンジニアのためのインフラ入門 ーBFT道場 Think IT支部 第1回 ITインフラの全体像を理解しよう
- 7. 自社サービスの現状と課題 ⚫ サポート切れのインフラソフトウェアを利用し続けているサー バがあり、メンテナンス性が欠如している ○ OS（Linuxディストリビュージョンとバージョン） ○ ミドルウェア ○ ライブラリ ⚫ 過去の経緯から、特にEC2には作りっぱなしで運用担当のアサ インが宙ぶらりんのサーバがいる セキュリティに限らず各種不具合の是正がしづらく、対応未実施に よるリスクの受容もしくは余計な追加作業を余儀なくされる。 また、その状態であることに気づきにくい。
- 8. 改善案 ⚫ サーバを下記仕様で管理し、Q毎に全社のセキュリティ管理部署 によるチェックを受ける 管理項目 管理対象 管理方法 ● 運用開始日 ● 機器の保守サポート期間 ● 稼働しているOS/MWのバージョン ● 不特定多数のネットワークからの インバウンド通信が可能か否か （プロトコル不問） EC2 ● AWS CLIによる台 数増減確認 ● スキャンツールに よるOS/MWの 状況把握 (本件の対象) オンプレ 機器一覧（運用中） その他 アンケート調査 （運用中）
- 9. スキャンツール選定の背景：要件整理 ⚫ ツールに求める機能 ○ スキャン結果と脆弱性への対応状況を一覧で見ることができる ○ 取得した結果を外部ファイル化して加工できる ○ 管理対象の動作に影響を与えない ◼ 管理対象を攻撃しない（プラットフォーム脆弱性診断のようなことをしない） ◼ 解析やレポーティング作業が管理対象に負荷を与えない ⚫ ツール候補 ○ Amazon Inspector v2：EC2とECRに対応 ◼ 選定開始当初はInspector v2に脆弱性管理機能があることを知らず、土俵にも 上がってこなかった ○ 某社ツールいくつか：オンプレからクラウドのサーバまで幅広く対応
- 10. スキャンツール選定の背景：ツールの比較 ⚫ 料金体系 ○ 契約形態：月額利用料 or 年間契約 ○ 課金単位：台数ないしスキャン回数 ⚫ 自社の運用状況 ○ オンプレサーバに新たに管理の仕組みを入れるメリットが見込めない ◼ オンプレサーバでは、インフラ管理部署による既存の機器一覧の運用が回っている ◼ サービスのフルAWS化により、オンプレサーバはシュリンクする ○ AWS契約の範疇内で決着すると諸々ラク ⚫ TechJoy（技術的に面白いか） ○ 解析方法 ○ トリアージ方法 etc どのツールも概ねこのパターンの いずれかで、半ば価格勝負
- 11. スキャンツール選定の背景：ツールの比較 ⚫ 料金体系 ○ 契約形態：月額利用料 or 年間契約 ○ 課金単位：台数ないしスキャン回数 ⚫ 自社の運用状況 ○ オンプレサーバに新たに管理の仕組みを入れるメリットが見込めない ◼ オンプレサーバでは、インフラ管理部署による既存の機器一覧の運用が回っている ◼ サービスのフルAWS化により、オンプレサーバはシュリンクする ○ AWS契約の範疇内で決着すると諸々ラク ⚫ TechJoy（技術的に面白いか） ○ 解析方法 ○ トリアージ方法 etc どのツールも概ねこのパターンの いずれかで、半ば価格勝負 技術的には某ツールを採用したかったが、 他の要素でAmazon Inspector v2が優位すぎた
- 12. Amazon Inspector v2 ⚫ ざっくり動作の流れ※1 1. 管理対象に導入されたSystems Manager（SSM）Agentが、サーバ内 の情報を吸い上げて、それをAmazon Inspectorに投げる 2. Amazon Inspectorは投げられた情報を、各種脆弱性情報や稼働してい るネットワーク環境の状況などを踏まえて診断する 3. （必要に応じて）診断結果はCSVやJSON形式でエクスポートできる ⚫ 必要なもの※2 ○ 管理対象へのSSM Agentの導入 ◼ Amazon Linux 2ならデフォルトで導入済み ◼ 個別導入の場合もyumなどのパッケージ管理コマンド一発で入る ○ 管理対象へのAmazonSSMManagedInstanceCoreポリシーを含んだ ロールのアタッチ ※1※2：細かい部分は公式ドキュメントや先駆者のやってみた記事を見れば何とかなる
- 13. Amazon Inspector v2 Amazon Inspector SSM Agent Amazon EC2 Instances Amazon ECS Container KMS key Amazon S3 Backet ブラウザ閲覧 サーバ情報 SSM Agent サーバ情報 Inspector利用者 CSV or JSON ファイル … 解析 ⚫ 基本的な流れ
- 16. Amazon Inspector v2による脆弱性管理 Amazon Inspector SSM Agent Amazon EC2 Instances Amazon ECS Container KMS key Amazon S3 Backet ブラウザ閲覧 サーバ情報 CSV or JSON ファイル … SSM Agent サーバ情報 インフラ管理者 全社セキュリティ 管理者 CSV or JSON ファイル … 解析 経営層
- 17. Inspector導入における課題と対策 サーバ種別 問題点 対処方法 既存 大半がオンプレのVMをポーティングした 非Amazon Linuxである NW構成を見ながら優先度をつけて導入する （お客さまに近いものを優先する） OSバージョンが古すぎてSSM Agentの システム要件を満たさない そもそも廃止かリプレースするべしの旨で合意形成 できるように仕向ける 新規 運用担当アサインやパッチ適用などの運用 ルールが不十分である 最低限のサーバ運用要件を再整備したうえで、全社の PJルールにする 新規サーバにSSM Agentと AmazonSSMManagedInstanceCoreポリシーがデ フォルトで導入される仕組みを整える ・Amazon Linuxをベースにする ・(非Amazon Linuxの場合)構築スクリプト パッチ適用の自動化（OSもしくはInspectorの機能） ⚫ 課題：SSM Agent未導入のサーバが存在する (今後も増える可能性がある) ⚫ 対策：地道にルールと仕組みの両輪で縛る
- 18. まとめ ⚫ サーバスキャンツール導入時に発生する事項をまとめた ⚫ これまで手付かずだったEC2の脆弱性管理を実現できるめどが ついたことで、自社の課題解決に一歩近づいた ⚫ 今回の仕組みを継続運用する方法の整備が次の課題である ○ 既存の仕組みとの整合性の調整 【例】脆弱性のトリアージ ◼ CVSSやAWS独自指標の考え方 ◼ 優先度付けルール ○ Amazon LinuxのEOL問題（2024年6月） ⚫ 本日のLT内容は情報セキュリティ全体およびITシステム全体の ほんの一部分を扱ったにすぎず、今回の内容だけで自社のセ キュリティは万事OKでは決してありません