はじめに
本記事はAWSで提供されているAmazon Inspectorについて記載しています。
Amazon Inspectorは、OSやソフトウェアの脆弱性管理に関するセキュリティ対策のソリューションです。
前々から存在は知っていたものの、実際に使ったことがなかったため、検証した結果についてまとめています。
これからAmazon Inspectorの導入検討を考えている方の参考になれば幸いです。
Amazon Inspector
Amazon Inspectorは、アプリケーションのセキュリティとコンプライアンスの向上を目的に開発されて、2016年にリリースされたサービスです。
リリース当時は、Amazon EC2だけでしたが、現在はAWS Lambdaもサポートされています。
特徴
主な機能は、ネットワーク接続性やパッケージの脆弱性を継続的にスキャンして、その結果をダッシュボードに可視化することができます。
また、影響を受けるリソースを特定し、脆弱性の評価や修復ガイダンスを提供します。
- ネットワーク接続性
- EC2インタンスに対して、外部から到達可能であるSSHやHTTPなど、よく使われるポートを検出し、評価します。
- パッケージの脆弱性
- CVEに基づき、OSやソフトウェアなどのパッケージについて、構成変更時に環境評価が可能です。
- CVEについては、ベンダーのセキュリティアドバイザリによってリリースされてから24時間以内に追加されます。WindowsのCVEは、マイクロソフトからリリースされてから48時間以内に追加されます。
Amazon Inspectorの詳細については、公式ドキュメントの「Amazon Inspector とは」から確認できます。
料金
Amazon Inspector の料金表から料金について確認できます。
基本的に以下の種別毎に発生したスキャンの量に基づいて決定されます。
- Amazon EC2 インスタンス
- Amazon ECR コンテナイメージ
- AWS Lambda 関数
15日間の無料トライアルが利用できます。
検証
ECインスタンスに対するネットワーク接続性とパッケージの脆弱性について、検証した結果を以下に記載しています。
アクティブ化
AWS マネジメントコンソールから、Amazon Inspectorを検索して表示後、「使用を開始する」を押します。
以下のような画面に遷移するため、「Inspectorをアクティブ化」を押します。
Inspectorがアクティブ化され次第、利用できるようになります。
ダッシュボード画面には、全体の検出結果が確認できます。
AWS Systems Manager
ネットワーク接続性はAmazon Inspectorを有効化するだけで試すことができますが、パッケージの脆弱性については、AWS Systems Manager（以下、Systems Manager）の機能を使用します。
利用する環境によって導入されていない場合は、必要に応じてSSM Agentのインストールが必要です。
詳細については公式ドキュメントの 「Working with SSM Agent」をご参照ください。
SSM Agentはインストールされているが、パッケージの脆弱性について評価できない場合、EC2インスタンスに対するSystems Managerの権限をご確認ください。
以下はSystems Managerの権限がないため、/var/log/amazon/ssm/amazon-ssm-agent.logのログファイルにエラーが出力されている例です。
2023-08-01 09:22:54 INFO [ssm-agent-worker] Entering SSM Agent hibernate - EC2RoleRequestError: no EC2 instance role found
caused by: EC2MetadataError: failed to make EC2Metadata request
status code: 404, request id:
caused by: <?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>404 - Not Found</title>
</head>
<body>
<h1>404 - Not Found</h1>
</body>
</html>
上記のようなエラーが出力されている場合は、AmazonSSMManagedInstanceCoreのポリシーを付与したIAMロールをEC2インスタンスにアタッチします。
類似のポリシーとしてAmazonSSMManagedEC2InstanceDefaultPolicyがありますが、一部アクションに差異があります。
基本的には、AmazonSSMManagedInstanceCoreのポリシーで大丈夫だと思います。
検証方法
Amazon Inspectorのスキャンは基本的に自動で行われるため、Amazon Inspectorのコンソール上にオンデマンドでスキャンを実行するためのボタンなどはありません。
以下にAmazon Inspectorのスキャンに関するポイントを記載します。
- ネットワーク接続性
- 24時間に1回、EC2インスタンスのネットワーク到達可能性のスキャンを実行
- パッケージの脆弱性
- 新しいEC2 インスタンスを起動したタイミング
- 既存の EC2 インスタンス（Linux のみ）に新しいソフトウェアをインストールする場合
- Amazon Inspectorが新しい共通脆弱性と危険性 (CVE) 項目をデータベースに追加し、そのCVEが影響している場合
2023年4月、Amazon Inspector で EC2 インスタンスのディープインスペクションのサポートを開始が公開されています。
従ってOSのパッケージに加えて、Python、Java、Node.jsパッケージなどのプログラミング言語に関するパッケージの脆弱性がスキャンできるようになりました。
ディープインスペクションという言葉が出てきますが、デフォルトで有効になっているため、特に設定は不要です。
本記事では、効率的に検証を行うために、ディープインスペクションに関するInvokeInspectorLinuxSsmPlugin-do-not-deleteを用いて検証を行います。
端的に言うと、プログラミング言語に関するパッケージの脆弱性スキャンは、を6時間ごとに行われるため、手動でディープインスペクションに関するInvokeInspectorLinuxSsmPlugin-do-not-deleteを実行して検証を行います。以下に実行手順を記載します。
AWS Systems ManagerからState Managerを開きます。
InvokeInspectorLinuxSsmPlugin-do-not-deleteにチェックを入れます。
「関連付けを今すぐ適用」のボタンを押す。
「関連付けを今すぐ適用」のボタンを押した後に、該当するEC2インスタンスの/var/log/amazon/ssm/amazon-ssm-agent.logのログファイルを見ると、スキャンが行われていること（State Managerによる関連付けの処理）が確認できます。
スキャンの仕組みや上記ディープインスペクションに関するInvokeInspectorLinuxSsmPlugin-do-not-deleteについては、公式ドキュメントの「アマゾンインスペクターで Amazon EC2 インスタンスをスキャンする」から確認できます。
ネットワーク接続性
ネットワーク接続性の検証を行うため、適当にEC2インスタンスを1台起動します。
本記事の例では、Webサービスとしてapacheを起動し、セキュリティグループの22番ポートと80番ポートが空いている状態です。
しばらくすると、脆弱性の画面に以下のような検出結果が表示されました。
試しに80番ポートに関する項目を押すと、以下のような検出結果が表示されます。
タイトルを押すと、詳細が確認できます。
検出されるポート番号や重要度の評価は、公式ドキュメントの「Amazon インスペクターによる調査結果の重大度レベル」から確認できます。
パッケージの脆弱性
検証として以下のAMIを使用しています。
No.1は古いAmazon Linux 2のイメージ、No.2は本記事執筆時点で最新のAmazon Linux 2023のイメージです。
| No. | AMI ID | AMI 名 |
|---|---|---|
| 1 | ami-02d36247c5bc58c23 | amzn2-ami-hvm-2.0.20211005.0-x86_64-gp2 |
| 2 | ami-08c84d37db8aafe00 | al2023-ami-2023.1.20230725.0-kernel-6.1-x86_64 |
それぞれSSM Agentは最初からインストールされているため、上記に記載した通りにEC2インスタンスに対するSystems Managerの権限を設定します。
OSの脆弱性
スキャンを実行すると、以下のようにカーネルに関する脆弱性が132件検出されました。
検出された脆弱性から任意の項目を選択して詳細が確認できます。
影響を受けるパッケージの情報を見ると、修正されたカーネルのバージョンが確認できます。
カーネルをアップグレード及びOS再起動後に再スキャンを実行すると、検出結果が削除されました。
脆弱性のあるパッケージ
以下の例では、脆弱性のあるパッケージをインストールした状態でスキャンを行いました。
脆弱性のあるパッケージは、pythonのAIフレームワークを利用しています。
検出された脆弱性から任意の項目を選択して詳細が確認できます。
影響を受けるパッケージの情報を見ると、修正されたパッケージのバージョンが確認できます。
パッケージをアップグレードして再スキャンを実行すると、検出結果が削除されました。
pythonのパッケージによっては、マルウェアが含まれている場合もあるため、検証を行う場合はくれぐれもご注意ください。
検証するパッケージを確認したい場合は、Snykの脆弱性DBが便利だと思います。
Export SBOMs
興味深いのがAmazon Inspectorは、SBOMに関する情報を出力することができます。
（※本記事執筆時点でWindowsのEC2インスタンスに関するSBOMのエクスポートはサポートされていないようです。）
2023年6月、AWS が Amazon Inspector のソフトウェア部品表のエクスポート機能を発表が公開されています。
SBOMは、Software Bill of Materialsの略称です。
ソフトウェア製品に含まれるコンポーネントやライブラリ、依存関係などの情報をリスト化した文書またはデータ（JSONやXMLなど）のことを指します。
SBOMの目的は、セキュリティの観点から法的コンプライアンスや脆弱性管理などリスク評価を行うことです。
従ってソフトウェアの構成要素を正確に識別し、その関係性や依存関係を明確にするために使用されます。
昨今では、ソフトウェアサプライチェーンの透明性を高める手段としても注目されています。
Export SBOMsを利用したい場合は、Export SBOMsの画面を開いてエクスポートします。
なお、Export SBOMsの機能を利用するためには、ファイルを出力するためのS3バケットやKMS keyが必要です。
経済産業省から「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」を策定しましたが公開されています。SBOMに関する基本的な情報を提供するとともに、SBOMを実際に導入するにあたって認識・実施すべきポイントが記載されています。
EC2 scanning settings
Amazon Inspector は、以下のデフォルトパスに合わせてカスタムパスをスキャンの設定が可能です。
- /usr/lib
- /usr/lib64
- /usr/local/lib
- /usr/local/lib64
カスタムパスを設定したい場合は、EC2 scanning settingsの画面を開き、「編集」のボタンを押します。
必要に応じてカスタムパスを設定します。
個々のアカウントでは最大5つのカスタムパスを定義できます。
組織の委任管理者の場合は、組織全体に適用されるパスを5つ追加で定義できるため、組織内のアカウントごとに合計で最大10のカスタムパスの設定が可能です。
Vnlnerability database search
Amazon Inspectorの脆弱性データベースからCVEに関する詳細を検索することができます。
脆弱性データベース画面の検索ボックスに、任意のCVE番号を入力して「Search」ボタンを押します。
CVEに関する詳細が確認できます。
評価
EC2を利用していて、以下のStrengths（強み）に示す条件が適合する場合、Amazon Inspectorは適しているのではないかというのが個人的な見解です。
Strengths
- 前提
- 組織内で脆弱性に対する考え方や、運用方法（CVEに対する評価基準など）が決まっている
- 定常的にEC2インスタンスを運用している
- 目的
- システム管理のサービスをAWSで統一及び管理したい
- 既に稼働している環境に対して、EC2インスタンスの脆弱性を評価したい
Weaknesses
Amazon Inspectorでは、以下のような脅威は検出できません。
- マルウェア感染
- C&Cサーバに対する不正な通信
- クラウドの設定評価（例：S3バケットをパブリックにしているなど）
AWSで統合管理を行うにせよ、ネットワーク接続性の機能は、Security Hubでカバーできる部分もあるため、既にSecurity Hubを導入していて、ネットワーク接続性のみを利用するなどのケースは、コスト的にもったいないと思いました。
脆弱性のあるパッケージについては、昨今のシフトレフトの考え方を踏まえてSnykなどの素晴らしいサービスがあります。
Synkについては、以前書いた「SnykではじめるDevSecOps」をご参照ください。
おわりに
SBOMをサポートしているのは面白いなと思いました。
SBOMについては、業界的にもこれから活発化してくると思われるため、そのあたりは良い試みだと思います。
まとめると、何事も目的と手段を混合することなく、組織の実態に合わせた最適な運用が理想です。