クラウドインテグレーション事業部 セキュリティセクションの日下です。
今回は、Amazon Inspector でEC2インスタンスのスキャンの実施にあたり
実施までの流れについて、簡単にではありますが記載していきます。
そもそもAmazon Inspectorとは?
まず、Amazon Inspectorについてですが、ざっくりいうとAWSが提供する脆弱性管理サービスのことで、
クラウド環境におけるセキュリティリスクを特定し、修正を支援してくれるサービスです。
EC2インスタンスやコンテナ(ECS、EKS)、Lambdaに対して、自動で脆弱性のスキャンを実行し
既知の脆弱性(CVE)やソフトウェアの不備を検出してくれます。
また、システム構成やパッチ適用状況の監視し、セキュリティ基準に沿っていない設定を特定したり
新しくリリースされた脆弱性を適用してくれたり
検出された脆弱性に優先順位を付け、修正箇所を教えてくれたりもします。
実施に至った経緯について
PCI DSS(クレジットカード情報を保護するための国際的なセキュリティ基準)の監査要件のひとつに
内部脆弱性を定期的に特定し、優先順位をつけて対処する必要があります。
元々監査対象のインスタンスに対して、Nexposeをインストールしたサーバからスキャンを行っていましたが
スキャン対象の登録の手間や脆弱性の管理を簡単にしたいという背景から
Amazon Inspectorでスキャンすることに切り替えました。
エージェントベーススキャンとエージェントレススキャンについて
Amazon InspectorのEC2インスタンススキャンには
エージェントベーススキャンとエージェントレススキャンの2種類あります。
詳しい内容はこちらになりますが、ざっくりとした比較表は以下です。
項目 | エージェントベーススキャン | エージェントレススキャン |
収集方法 |
|
|
スキャン頻度 |
|
|
要件 |
|
|
メリット |
|
|
つまり、エージェントベーススキャンは、
インスタンスにインストールされた SSMエージェント経由で
リアルタイム性が高いスキャンを実施することができます。
一方で、エージェントレススキャンは、
EBSスナップショット を作成し、その内容を分析することができることから
エージェントのインストール不要であり、導入自体が非常に簡単であることが特徴です。
事前準備
私の場合、インスタンスに対して直接スキャンを実施したいことからエージェントベーススキャンを実施したのですが
スキャンを実施するにあたって、事前に必要な設定は以下3つになります。
- SSMエージェントのインストールと有効化
- AmazonSSMManagedInstanceCore ポリシーの適用
- 除外タグの設定
1.SSMエージェントインストールと有効化
SSMエージェントインストールと有効化については、
AWSが公式で出しているコマンドを3つほど実行するだけで可能であり
エージェントを起動するだけで、Amazon Inspector のスキャン方法が自動でエージェントベースに切り替わります。
Linuxサーバの場合は、OSによってコマンドが異なりますが、
最終的に Active: active (running) と出力されれば、問題なくインストールと起動がされています。
※LinuxサーバのSSMエージェントのインストールについてはこちら
[root@ip-172-31-24-176 ~]# systemctl status amazon-ssm-agent
● amazon-ssm-agent.service – amazon-ssm-agent
Loaded: loaded (/etc/systemd/system/amazon-ssm-agent.service; enabled; preset: disabled)
Active: active (running) since Thu 2025-01-16 16:38:25 JST; 2 weeks 0 days ago
Main PID: 1043 (amazon-ssm-agen)
Tasks: 22 (limit: 4372)
Memory: 234.6M
CPU: 35min 49.047s
CGroup: /system.slice/amazon-ssm-agent.service
├─1043 /usr/bin/amazon-ssm-agent
└─1373 /usr/bin/ssm-agent-worker
Windowsサーバの場合も、AWSの公式ページに記載のコマンドを実行するか
記載されているリンクからSSM Agent の実行ファイルをダウンロードすればインストールできます。
また、PowerShellで Running AmazonSSMAgent Amazon SSM Agent と出力されれば
問題なくインストールと起動がされています。
※WindowsサーバのSSMエージェントのインストールについてはこちら
PS C:\Users\Administrator> Get-Service AmazonSSMAgent
Status Name DisplayName
—— —- ———–
Running AmazonSSMAgent Amazon SSM AgentPS C:\Users\Administrator>
2.AmazonSSMManagedInstanceCore ポリシーの適用
AmazonSSMManagedInstanceCore ポリシーは、SSM を利用して
EC2インスタンスを管理するために必要な基本的な権限を提供する マネージドポリシー です。
このポリシーには、インスタンス情報の取得や更新をはじめとする
Amazon Inspectorで EC2インスタンスをスキャンするにあたっての必要なアクセス許可がすべて含まれています。
AmazonSSMManagedInstanceCore ポリシーについてはこちら
SSMエージェントをインストールして Amazon Inspectorでスキャンを実行しても
このポリシーがなければ、「アンマネージドEC2インスタンス」としてスキャン対象外となります。
適用方法は、インスタンスにアタッチするロールを作成し、
そのロールの許可ポリシーとして、AmazonSSMManagedInstanceCore ポリシーアタッチします。
今回は、InspectorAccessRole_testロールにAmazonSSMManagedInstanceCore ポリシーをアタッチし
インスタンスにアタッチするように設定しました。
InspectorAccessRole_testロール
インスタンスへアタッチ
3.除外タグの設定
Amazon Inspectorのスキャンを対象外としたいインスタンスがある場合は、
インスタンスに対して、以下のタグをつけることでスキャン対象から除外することができます。
キー:InspectorEc2Exclusion
値:空白
inspectorのスキャン方法について
では実際にどうすればスキャンできるのかについてですが、
AWSサービスの検索一覧から「Amazon Inspector」を検索し
[使用を開始する]→[Inspector をアクティブ化]より有効化するだけでスキャンが完了します!
この時、EC2インスタンスやコンテナ(ECS、EKS)、Lambda全体に対してスキャンが実行されます。
また、Amazon Inspectorはリージョンごとにスキャンが実行され、リージョンごとにサポート対象が異なります。
対象リージョンとエンドポイントについてはこちら
スキャン結果について
実際のスキャン結果ですが、まずはインスタンス別で
Amazon Inspectorによって出された緊急度ごとに脆弱性の数を確認することができます。
また、脆弱性ごとの詳細情報も確認することができます。
詳細情報には、脆弱性の詳細だけでなく、
修正の可否、影響を受けるパッケージ、インストール済みバージョンと修正バージョンも表示されるので
「サーバにある脆弱性をどうしたら解消できるか?」まで理解することができます。
スキャン結果の修正について
実際に検出された脆弱性の解消と反映までの所要時間を確認してみました。
今回は上記の添付画像のLinuxサーバで検出された
カーネルのバージョン起因の脆弱性 (CVE-2024-38581 )の解消を行なっていきます。
スキャンした結果では、該当のインスタンスのカーネルが 5.14.0-427.20.1.el9_4.x86_64 に対して
修正されているバージョンは5.14.0-503.11.1.el9_5.x86_64 であることが書かれています。
そのため、まずは現行のバージョン確認を行います。
[ec2-user@ip-172-31-24-176 ~]$ uname -r
5.14.0-427.20.1.el9_4.x86_64
次にyumのアップデートと使用可能なカーネルのバージョンを確認します。
アップデート後には、新しいバージョン 5.14.0-503.21.1.el9_5 .x86_64 が使えるようになりました。
[ec2-user@ip-172-31-24-176 ~]$ sudo yum update -y
Updating Subscription Management repositories.
Unable to read consumer identity
This system is not registered with an entitlement server. You can use “rhc” or “subscription-manager” to register.Last metadata expiration check: 0:14:45 ago on Thu 16 Jan 2025 04:07:09 PM JST.
Dependencies resolved.
=======================================================[ec2-user@ip-172-31-24-176 ~]$ sudo yum list kernel
Installed Packages kernel.x86_64 5.14.0-427.20.1.el9_4 @System kernel.x86_64 5.14.0-503.21.1.el9_5 @rhel-9-baseos-rhui-rpms
最後に、再起動をしバージョンを再確認すると、新しいバージョンへ切り替わりました。
[ec2-user@ip-172-31-24-176 ~]$sudo reboot
[ec2-user@ip-172-31-24-176 ~]$ uname -r
5.14.0-503.21.1.el9_5.x86_64
すると、30分もしないうちに対象インスタンスの脆弱性がすべて解消されました!
リージョン全体で脆弱性を検索し、脆弱性の有無も確認することができます。
おそらく、他の脆弱性もカーネルのバージョン起因であったことからすべて解消されたと思われます。
また、所要時間については、Amazon Inspector がSSMインベントリが30分ごとに評価し
エージェントベースのトリガーのひとつである「新しいソフトウェアをインストール」に該当したので
AmazonInspectorへの反映に30分ほど要したと思われます。
このように、Amazon Inspectorでは、検出された脆弱性だけでなく
起因となっている箇所や解消方法まで詳細に表示されます。
また、エージェントベーススキャンでは
30分未満というかなりリアルタイムに近い時間で、インスタンス脆弱性を最新の状態へ反映することができます!
補足)エージェントベーススキャンへの切り替え方法について
Amazon Inspectorを有効化すると、デフォルトでは「ハイブリッドスキャンモード」という状態になっています。
ハイブリッドスキャンモードは、エージェントベースのスキャンとエージェントレススキャンの双方が含まれており
Amazon Inspectorを有効化した段階で、起動されているインスタンスに対してスキャンが実行されます。
前述の通り、エージェントベーススキャンでは、SSMエージェントのインストールが必要なことから
SSMエージェントがインストールされていないインスタンスには自動的にエージェントレススキャンが実行されます。
そこで、SSMエージェントのエージェントのみでスキャンしたい場合は、Amazon Inspectorの
[全般設定]→[EC2 scanning settings]→[Scan mode]から編集でモードを切り替えることができます!
最後に
ここまでご覧になっていただきありがとうございました。
今後もこのような技術ブログを挙げていけるよう頑張っていきます!!