2022年12月20日開催「nakanoshima.dev #33 - LT Night!」での発表資料です。

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

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

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

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

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

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
ファイル
…
解析
⚫ 基本的な流れ

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

15. Amazon Inspector v2
【例】CSVレポート

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では決してありません