1.目的
- セキュリティ関連サービスを一通り復習している。一度も触ったことの無かった Amazon Inspector について、チュートリアルレベルの確認を行い概要を理解する。
2.Amazon Inspector とは（自分の理解）
- EC2インスタンスに対する脆弱性評価を実施し、リスクを可視化するサービス。
- 分かりやすい解説は Developers.io記事：「AWS再入門ブログリレー Amazon Inspector編」 などにあるので、それを見ながら、自分の手で確認したことを記載する。
3.やったこと
- 評価対象とするインスタンスを作成する。
- Inspectorで以下を行う。
- 評価ターゲットの作成： ターゲット（評価対象インスタンス）を指定し、Agentをインストールする。
- 評価テンプレートの作成： ターゲット及び評価項目の選択を行う。
- 評価を実行し、結果を確認する。
- 評価結果に基づきOSの設定修正（脆弱性対応）を行い、再度評価を行い結果が変わることを確認する。
4.構成図
- 監査対象となるインスタンス(Amazon Linux 2)を1つ作成する。
- Systems Manager (Agentのインストールに使用)との通信のため、インスタンスにEIPを付与してインターネット通信可能とする。
5. 作業手順
5.1 事前準備
- 評価対象インスタンス(Amazon Linux 2)をパブリックサブネットに作成し、EIPを付与する。（標準のAMIからそのまま起動する。）
- Inspectorにおいて、評価対象インスタンスの指定はタグを用いて行うため、インスタンスに「Name:mksamba-inspector-target-instance」のタグを付与しておく。
- Inspectorの評価対象とするにはインスタンスにAgentをインストールする必要がある。Agentは今回はSystems Manager経由でインストールを行うため、インスタンスに対して、Systems Manager を用いるためのrole「AmazonSSMManagedInstanceCore」を付与しておく。
5.2 Inspector 評価ターゲットの作成
- 「評価ターゲット」の画面にて、評価対象とするインスタンスをタグにより指定し、「評価ターゲット」を作成する。
- 今回は先ほど作成したインスタンスだけが評価対象となるように、「Name:mksamba-inspector-target-instance」を指定する。
- 「Systems Manager - ノード管理 - Run Command」の画面で、評価対象インスタンスに対し、runコマンド(inspector agent のインストール)が実行されたことを確認する。
- 「評価ターゲット - Preview Target」の画面で、AgentのステータスがHealthyであることを確認する。
5.3 Inspector 評価テンプレートの作成
- 「評価テンプレート」の画面にて、「評価ターゲット」と「評価項目」の組み合わせをテンプレートとして作成する。
- 今回は以下のように設定した。
- 評価ターゲット： 前の手順で作成した評価ターゲットを指定
- ルールパッケージ： あらかじめ定義された4つのルールパッケージ（評価項目集）のどれを用いるのかを選択する。今回は4つのルールパッケージ全てを選択する。
- Assessment Schedule： 今回は1回のみ実行とするためチェックは外す。
- 「作成及び実行」を行い、評価テンプレートの作成及び初回評価実行を行う。
- なお、4つのルールパッケージの概要は以下の通り。
| ルールパッケージ | 内容 |
|---|---|
| CIS Operating System Security Configuration Benchmarks-1.0 | CIS (Center for Internet Security) ベンチマークは、システムを安全に構成するための構成基準およびベストプラクティス （Microsoft社によるCISの説明 を参照） |
| Network Reachability-1.1 | 外部ネットワーク(VPC外)からのネットワーク到達性 |
| Common Vulnerabilities and Exposures-1.1 | CVE(common vulnerabilities and exposures) に基づく評価 |
| Security Best Practices-1.0 | ssh経由のrootログイン可否などの、AWSが推奨するベストプラクティス |
5.4 結果の確認
- 「評価の実行」画面で、評価実行結果をダウンロードし、レポートとして見ることができる。
- 今回の結果は以下の通り。「CIS Operating System Security Configuration Benchmarks-1.0」で97件、「Common Vulnerabilities and Exposures-1.1」で4件、「Network Reachability-1.1」で1件、「Security Best Practices-1.0」で1件検出された。
| ルールパッケージ | 検出数 | 内容 |
|---|---|---|
| CIS Operating System Security Configuration Benchmarks-1.0 | 97 | 「/tmp を適切に設定しているか確認せよ」などの細かい指摘が多数。 |
| Network Reachability-1.1 | 1 | 「sshが空いてる」という想定内の指摘。SRCPortは絞ってあるので問題なし。 |
| Common Vulnerabilities and Exposures-1.1 | 4 | cloud-initに関して3件、chronyが1件。それぞれバージョンが古いとのこと。 |
| Security Best Practices-1.0 | 1 | rootログインが有効とのこと。 |
5.5 設定の修正と再評価
- 「Common Vulnerabilities and Exposures-1.1」で検出された脆弱性を試しに修正してみることにした。
- 検出された4件の内容（該当するCVE IDと対象のソフトウェア）は以下の通り。
| CVE ID | 対象のソフトウェア |
|---|---|
| CVE-2018-10896 | cloudinit-0:19.3-3.amzn2 |
| CVE-2020-14367 | chrony-0:3.2-1.amzn2.0.5 |
| CVE-2020-8631 | cloudinit-0:19.3-3.amzn2 |
| CVE-2020-8632 | cloudinit-0:19.3-3.amzn2 |
- 普通に yum update したところ、chronyもcloudinitも新しいバージョンに更新された。
[ec2-user@ip-172-16-0-41 ~]$ sudo yum update
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
amzn2-core | 3.7 kB 00:00
amzn2extra-docker | 3.0 kB 00:00
Resolving Dependencies
--> Running transaction check
---> Package chrony.x86_64 0:3.2-1.amzn2.0.5 will be updated
---> Package chrony.x86_64 0:3.5.1-1.amzn2.0.1 will be an update
--> Processing Dependency: libnettle.so.4()(64bit) for package: chrony-3.5.1-1.amzn2.0.1.x86_64
---> Package cloud-init.noarch 0:19.3-3.amzn2 will be updated
---> Package cloud-init.noarch 0:19.3-4.amzn2 will be an update
- yum update実施後、再度、同じ評価テンプレートを用いて評価したところ、上記については解消（検出されない）になった。
6.所感
- 概念としては、昔からある「ホスト型脆弱性スキャナ」という感じで、そんなに抵抗感なく理解することができた。
- 気軽に実行はできるが、出てきた脆弱性のチェック（本当に対処する必要があるのかの確認）は大変なので、使うにしてもルールパッケージの選択などに注意したいと感じた。