Amazon Inspector v2で脆弱性管理を始めてみた

nakanoshima.dev #33 - LT Night ! Amazon Inspector v2で 脆弱性管理を始めてみた 2022年12月20日 chocopurin

自己紹介 ⚫ ⚫ ⚫ 名前：chocopurin 職業：とある企業の一般社員 主なお仕事歴 ○ 某SIer サーバ構築, 認証ツール開発, システム開発ルールの策定 コンテナの研究, Webアプリ脆弱性診断 ○ 現職 ITインフラの構築/維持管理, セキュア開発基盤の整備, 永遠のAWS見習い ⚫ 直近の出没歴 AWSエバンジェリストシリーズ, 総関西サイバーセキュリティLT大会 Security-JAWS, OWASP Kansai, レトロゲーム勉強会 etc

はじめに 本日のLT内容は、表現の都合上、フィクションとノンフィクション が入り混じっています。予めご了承ください。

情報セキュリティの全体像とLT内容の範囲 だいたいこの辺 【出典】日本CISO協会 情報セキュリティにおける4つの領域と関係性

• https://cisojapan.org/four-areas/

システムとLT内容の範囲 だいたい この辺 【出典】 新人エンジニアのためのインフラ入門 ーBFT道場 Think IT支部 第1回 ITインフラの全体像を理解しよう

• https://thinkit.co.jp/article/11526

自社サービスの提供形態の変遷と本件の対象 オンプレDC サーバ群（約200台） サービス利用者 オンプレDC サーバ群 (約160台) 本件の対象 サービス利用者 EC2群 (約60台) サーバレス 中心 サービス利用者

自社サービスの現状と課題 ⚫ サポート切れのインフラソフトウェアを利用し続けているサー バがあり、メンテナンス性が欠如している ○ OS（Linuxディストリビュージョンとバージョン） ○ ミドルウェア ○ ライブラリ ⚫ 過去の経緯から、特にEC2には作りっぱなしで運用担当のアサ インが宙ぶらりんのサーバがいる セキュリティに限らず各種不具合の是正がしづらく、対応未実施に よるリスクの受容もしくは余計な追加作業を余儀なくされる。 また、その状態であることに気づきにくい。

改善案 ⚫ サーバを下記仕様で管理し、Q毎に全社のセキュリティ管理部署 によるチェックを受ける 管理項目 ● ● ● ● 運用開始日 機器の保守サポート期間 稼働しているOS/MWのバージョン 不特定多数のネットワークからの インバウンド通信が可能か否か （プロトコル不問） 管理対象 EC2 管理方法 ● ● AWS CLIによる台 数増減確認 スキャンツールに よるOS/MWの 状況把握 (本件の対象) オンプレ 機器一覧（運用中） その他 アンケート調査 （運用中）

スキャンツール選定の背景：要件整理 ⚫ ツールに求める機能 ○ スキャン結果と脆弱性への対応状況を一覧で見ることができる ○ 取得した結果を外部ファイル化して加工できる ○ 管理対象の動作に影響を与えない ◼ 管理対象を攻撃しない（プラットフォーム脆弱性診断のようなことをしない） ◼ 解析やレポーティング作業が管理対象に負荷を与えない ⚫ ツール候補 ○ Amazon Inspector v2：EC2とECRに対応 ◼ 選定開始当初はInspector v2に脆弱性管理機能があることを知らず、土俵にも 上がってこなかった ○ 某社ツールいくつか：オンプレからクラウドのサーバまで幅広く対応

スキャンツール選定の背景：ツールの比較 ⚫ 料金体系 ○ 契約形態：月額利用料 or 年間契約 ○ 課金単位：台数ないしスキャン回数 ⚫ どのツールも概ねこのパターンの いずれかで、半ば価格勝負 自社の運用状況 ○ オンプレサーバに新たに管理の仕組みを入れるメリットが見込めない ◼ オンプレサーバでは、インフラ管理部署による既存の機器一覧の運用が回っている ◼ サービスのフルAWS化により、オンプレサーバはシュリンクする ○ AWS契約の範疇内で決着すると諸々ラク ⚫ TechJoy（技術的に面白いか） ○ 解析方法 ○ トリアージ方法 etc

スキャンツール選定の背景：ツールの比較 ⚫ 料金体系 ○ 契約形態：月額利用料 or 年間契約 ○ 課金単位：台数ないしスキャン回数 ⚫ どのツールも概ねこのパターンの いずれかで、半ば価格勝負 自社の運用状況 ○ オンプレサーバに新たに管理の仕組みを入れるメリットが見込めない ◼ オンプレサーバでは、インフラ管理部署による既存の機器一覧の運用が回っている ◼ サービスのフルAWS化により、オンプレサーバはシュリンクする 技術的には某ツールを採用したかったが、 他の要素でAmazon Inspector v2が優位すぎた ○ AWS契約の範疇内で決着すると諸々ラク ⚫ TechJoy（技術的に面白いか） ○ 解析方法 ○ トリアージ方法 etc

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：細かい部分は公式ドキュメントや先駆者のやってみた記事を見れば何とかなる

Amazon Inspector v2 ⚫ 基本的な流れ Amazon EC2 ブラウザ閲覧 Amazon Inspector サーバ情報 SSM Agent Inspector利用者 Amazon S3 KMS key … 解析 サーバ情報 Instances Amazon ECS CSV or JSON ファイル Backet Container SSM Agent

Amazon Inspector v2 【例】2022年11月2日公開のOpenSSL（libssl3） 結果をS3経由でCSVや JSONに出力可能 脆弱性やインスタンス毎にソートや フィルタしてトリアージができる

Amazon Inspector v2 【例】CSVレポート

Amazon Inspector v2による脆弱性管理 Amazon EC2 ブラウザ閲覧 インフラ管理者 Amazon Inspector サーバ情報 SSM Agent 経営層 全社セキュリティ 管理者 … Amazon S3 KMS key … CSV or JSON ファイル 解析 サーバ情報 Instances Amazon ECS CSV or JSON ファイル Backet Container SSM Agent

Inspector導入における課題と対策 ⚫ ⚫ 課題：SSM Agent未導入のサーバが存在する (今後も増える可能性がある) 対策：地道にルールと仕組みの両輪で縛る サーバ種別 問題点 既存 大半がオンプレのVMをポーティングした 非Amazon Linuxである OSバージョンが古すぎてSSM Agentの システム要件を満たさない 新規 運用担当アサインやパッチ適用などの運用 ルールが不十分である 対処方法 NW構成を見ながら優先度をつけて導入する （お客さまに近いものを優先する） そもそも廃止かリプレースするべしの旨で合意形成 できるように仕向ける 最低限のサーバ運用要件を再整備したうえで、全社の PJルールにする 新規サーバにSSM Agentと AmazonSSMManagedInstanceCoreポリシーがデ フォルトで導入される仕組みを整える ・Amazon Linuxをベースにする ・(非Amazon Linuxの場合)構築スクリプト パッチ適用の自動化（OSもしくはInspectorの機能）

まとめ ⚫ ⚫ ⚫ サーバスキャンツール導入時に発生する事項をまとめた これまで手付かずだったEC2の脆弱性管理を実現できるめどが ついたことで、自社の課題解決に一歩近づいた 今回の仕組みを継続運用する方法の整備が次の課題である ○ 既存の仕組みとの整合性の調整 【例】脆弱性のトリアージ ◼ CVSSやAWS独自指標の考え方 ◼ 優先度付けルール ○ Amazon LinuxのEOL問題（2024年6月） ⚫ 本日のLT内容は情報セキュリティ全体およびITシステム全体の ほんの一部分を扱ったにすぎず、今回の内容だけで自社のセ キュリティは万事OKでは決してありません