はじめに
AWSを利用していると、「利用しているAWSサービスやソフトウェアに脆弱性が見つかった場合、どこで情報を確認すればよいのか」と疑問に思うことがあります。
特にインフラエンジニアとしてAWS環境を運用する場合、脆弱性情報を確認して終わりではありません。
「自分たちの環境は影響を受けるのか」
「対応が必要なのか」
「どのサーバーをアップデートすればよいのか」
「今後同じような問題が発生したときにどう対応するのか」
まで考える必要があります。
AWSでは、AWSのサービスやソフトウェアなどに関するセキュリティ情報を「セキュリティ速報」として公開しています。
この記事では、AWSの脆弱性情報を確認する方法から、実際の脆弱性事例としてAWS Systems Manager Agent（SSM Agent）の問題を取り上げ、インフラエンジニアがどのように対応を考えればよいのかを解説します。
AWSの脆弱性情報はどこで確認できる？
AWSでは、AWSやAmazonのサービス、ソフトウェア、製品などに影響するセキュリティ脆弱性について調査し、必要な情報を「セキュリティ速報」として公開しています。
AWSのセキュリティ速報は、以下のページから確認できます。
AWS セキュリティ速報：
https://aws.amazon.com/jp/security/security-bulletins/
ページには最新のセキュリティ速報が一覧表示されており、速報のID、公開日、CVE番号、対象となるサービスやソフトウェアなどを確認できます。
セキュリティ速報には、大きく分けて「注意を必要とする重要な速報」と「周知啓発のために共有される情報速報」があります。
インフラエンジニアとして重要なのは、単に新しい速報を読むことではありません。
自分たちが管理しているAWS環境に関係する情報なのかを判断することが重要です。
例えばEC2を利用している環境であれば、EC2そのものだけでなく、EC2上で動作しているOSやミドルウェア、SSM Agentなどのソフトウェアも確認対象になります。
つまり、AWSの脆弱性対応では、
「AWSサービスに脆弱性があるか」
だけではなく、
「AWS環境で利用しているソフトウェアに脆弱性があるか」
という視点も必要です。
AWSのセキュリティ速報はRSSでも取得できる
AWSのセキュリティ速報は、Webページを定期的に確認するだけでなく、RSSフィードでも提供されています。
これは実務で非常に重要なポイントです。
脆弱性情報を人が毎日Webサイトへアクセスして確認する運用にすると、確認漏れが発生する可能性があります。
そこで、RSSを利用してセキュリティ速報を取得し、情報収集の仕組みに組み込む方法があります。
例えば、次のような運用が考えられます。
- AWSのセキュリティ速報をRSSで取得する
- 新しい速報が公開されたことを検知する
- 担当者へ通知する
- 自社環境への影響を確認する
- 対応が必要であれば作業計画を作成する
- アップデートや設定変更を実施する
- 対応後にバージョンや設定を確認する
重要なのは、「脆弱性情報を取得すること」と「脆弱性へ対応すること」を分けて考えることです。
RSSを導入しただけでは、脆弱性対策が完了したことにはなりません。
RSSはあくまで情報収集を効率化するための仕組みです。
実際の対応では、その情報が自分たちの環境に関係するのかを確認する必要があります。
AWSの脆弱性情報を確認するときのポイント
AWSのセキュリティ速報を確認するときは、タイトルだけを見て判断しないことが重要です。
実務では、少なくとも次の項目を確認します。
| 確認項目 | 確認する内容 |
|---|---|
| 対象サービス・ソフトウェア | 自分たちの環境で利用しているか |
| 影響を受けるバージョン | 利用中のバージョンが該当するか |
| CVE番号 | 脆弱性を特定するための番号 |
| 影響 | どのような問題が発生する可能性があるか |
| 対応方法 | アップデートや設定変更など何が必要か |
| 回避策 | すぐにアップデートできない場合の対処方法 |
| 公開日 | いつ公開された情報なのか |
特に重要なのが「影響を受けるバージョン」です。
例えば「SSM Agentに脆弱性がある」という情報だけでは、自分たちの環境が影響を受けるのか判断できません。
「現在利用しているSSM Agentのバージョンが影響対象に含まれているか」を確認する必要があります。
また、対応方法が「アップデート」なのか「設定変更」なのか「特定機能の利用停止」なのかによって、実際の作業内容も変わります。
そのため、セキュリティ速報を確認するときは、タイトルだけではなく本文まで確認することが重要です。
SSM Agentの脆弱性を例に対応を考える
AWSの脆弱性情報を具体的にイメージするため、2026年9月に公開されたSSM Agentの脆弱性を例にします。
2026年9月10日、AWSは「2026-107-AWS」として、SSM AgentのSession Managerポート転送機能に関する脆弱性を公開しました。
CVE-2026-89049 – AWS Systems Manager Agent のセッションマネージャーポート転送機能におけるサーバー側リクエストの偽造：
https://aws.amazon.com/jp/security/security-bulletins/2026-107-aws/
CVE番号は「CVE-2026-89049」です。
この問題は、Session Managerのリモートホストへのポート転送機能におけるサーバーサイドリクエストフォージェリ（SSRF）の脆弱性です。
SSM Agentは、EC2インスタンスなどのマネージドノード上で動作し、AWS Systems Managerからのリクエストを処理するエージェントです。
Session Managerを利用したサーバーへの接続やポートフォワーディングなど、Systems Managerのさまざまな機能に関係しています。
今回の脆弱性では、リモートホストへのポートフォワーディング機能におけるアドレス表現の検証に問題があり、条件を満たした認証済みユーザーが、アクセスを制限するためのリストを回避してリンクローカルエンドポイントへアクセスできる可能性がありました。
さらに、管理対象インスタンスに割り当てられた一時的なIAMロールの認証情報を取得され、そのIAMロールの権限を利用される可能性があります。
このように、単純に「SSM Agentのバグ」という話ではありません。
EC2上で動作するSSM Agentを起点として、IAM権限にまで影響する可能性があるため、インフラエンジニアとしても確認しておきたい情報です。
SSM Agentの脆弱性にはどう対応するのか
今回の脆弱性では、SSM Agentのバージョン3.3.4851.0未満が影響を受けます。
AWSは、SSM Agent 3.3.4851.0で問題を修正しており、最新バージョンへのアップデートを推奨しています。
つまり、実際の環境で最初に確認すべきことは、
「管理対象ノードのSSM Agentが影響を受けるバージョンなのか」
という点です。
例えば、次のような流れで確認します。
AWSセキュリティ速報を確認
↓
SSM Agentが対象だと判明
↓
利用中のSSM Agentのバージョンを確認
↓
影響を受けるバージョンか判断
↓
該当する場合はアップデート
↓
アップデート後のバージョンを確認
↓
必要に応じて関連する設定・権限も確認
ここで注意したいのが、「アップデートすれば終わり」と考えないことです。
例えば、100台のEC2インスタンスを管理している環境で、今回のような脆弱性が発見されたとします。
そのときに、
「100台のうち何台がSSM Agentを利用しているのか」
「それぞれのバージョンは何なのか」
「アップデートが完了したことをどう確認するのか」
まで考える必要があります。
特に台数が増えるほど、手動確認には限界があります。
そのため、脆弱性対応をきっかけとして、そもそもSSM Agentを最新状態に維持できる運用になっているかを見直すことが重要です。
SSM Agentは自動更新を検討する
今回のような脆弱性への対応を考えると、SSM Agentを自動更新する仕組みを導入することも重要です。
AWS Systems Managerでは、SSM Agentの更新を自動化する機能が提供されています。
SSM Agent への更新の自動化：
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/ssm-agent-automatic-updates.html#ssm-agent-automatic-updates-console
AWSのドキュメントでは、すべてのLinuxおよびWindowsのマネージドノードについて、SSM Agentを自動更新する設定が案内されています。
自動更新を有効にすると、Systems Managerが2週間ごとに新しいSSM Agentのバージョンを確認し、新しいバージョンがあればAWS-UpdateSSMAgentドキュメントを利用して更新します。
AWSも、マネージドノードで常に最新バージョンのSSM Agentを実行できるよう、この自動更新を推奨しています。
設定はSystems ManagerのFleet Managerから行えます。
大まかな操作は次のとおりです。
Systems Manager
↓
Fleet Manager
↓
設定
↓
SSM Agentを自動更新
また、State Managerを利用してSSM Agentを自動更新する方法もあります。
State Managerでは、SSM Agentを自動的にダウンロード・インストールする関連付けを作成できます。
さらに、ワークロードへの影響を考慮してメンテナンスウィンドウを設定し、指定した時間帯に更新を実施する方法もあります。
そのため、環境の要件に応じて、
・常に最新バージョンへ更新する
・特定のバージョンへ更新する
・メンテナンス時間帯に更新する
・対象インスタンスを限定する
といった運用を検討できます。
重要なのは、「脆弱性が発生したら手動でアップデートする」という運用から、「脆弱性が発生することを前提として、ソフトウェアを継続的に最新化する」という運用へ変えていくことです。
AWSの脆弱性情報を実務でどう扱うか
実際の現場では、AWSのセキュリティ速報を確認しただけで作業を開始するのではなく、影響調査から始めます。
例えば次のような確認表を作成しておくと管理しやすくなります。
| 項目 | 確認内容 |
|---|---|
| 脆弱性情報 | CVE番号、AWS速報ID |
| 公開日 | 脆弱性情報が公開された日 |
| 対象 | サービス、ソフトウェア |
| 影響バージョン | 対象となるバージョン |
| 利用状況 | 自社環境で利用しているか |
| 利用バージョン | 現在利用しているバージョン |
| 影響有無 | 自社環境が対象か |
| 対応方法 | アップデート、設定変更など |
| 対応期限 | いつまでに対応するか |
| 対応結果 | 対応済みか |
| 証跡 | バージョン確認結果など |
例えば今回のSSM Agentの脆弱性であれば、
「EC2を利用しているから対応する」
という判断では不十分です。
まずSSM Agentを利用しているマネージドノードを確認し、そのうえでバージョンを確認します。
対象バージョンであればアップデートを実施し、アップデート後にバージョンを再確認します。
さらに、今回の脆弱性ではSession Managerのリモートホストへのポートフォワーディング機能が関係しているため、該当機能を利用しているか、関連するIAM権限がどのようになっているかも確認対象になります。
このように、
「脆弱性情報を読む」
→「自社環境への影響を調べる」
→「対応方法を決める」
→「対応する」
→「対応結果を確認する」
という一連の流れで考えることが重要です。
初心者がAWSの脆弱性対応で注意するポイント
AWSの脆弱性対応では、いくつか注意しておきたいポイントがあります。
1つ目は、「脆弱性情報を確認すること」と「自社環境が影響を受けること」を混同しないことです。
AWSから脆弱性情報が公開されたからといって、必ずしも自社環境が影響を受けるとは限りません。
対象サービスを利用しているか、対象バージョンを使用しているか、対象となる機能を利用しているかなどを確認する必要があります。
2つ目は、バージョン管理です。
「最新バージョンにしているつもり」という状態ではなく、実際にどのバージョンが動作しているのかを確認できる状態にしておくことが重要です。
3つ目は、アップデート後の確認です。
アップデート作業を実施しただけではなく、実際にバージョンが更新されたことを確認します。
また、アップデートによって業務システムへ影響が出ないかも考慮します。
特に本番環境では、いきなり全サーバーを更新するのではなく、検証環境や一部のサーバーで動作を確認してから本番環境へ展開する方法も検討します。
4つ目は、手動対応だけに依存しないことです。
今回のようなSSM Agentの脆弱性が発生するたびに、すべてのサーバーを手動で確認してアップデートする運用では、台数が増えたときに対応が難しくなります。
AWS Systems Managerの自動更新やState Manager、メンテナンスウィンドウなどを利用して、継続的にソフトウェアを最新化できる仕組みを検討することが重要です。
最後に、対応履歴を残すことも重要です。
「いつ、どの脆弱性に対して、どのサーバーを、どのバージョンへ更新したのか」を記録しておけば、後から監査や障害調査を行う際にも役立ちます。
まとめ
AWSを利用するインフラエンジニアにとって、AWSの脆弱性情報を定期的に確認することは重要な運用業務の一つです。
AWSではセキュリティ速報を公開しており、Webサイトから最新の脆弱性情報を確認できます。また、RSSフィードも提供されているため、情報収集を自動化することも可能です。
ただし、重要なのは脆弱性情報を読むことだけではありません。
実務では、
「どのサービス・ソフトウェアが対象なのか」
「自社環境で利用しているのか」
「利用中のバージョンは影響を受けるのか」
「どのような対応が必要なのか」
「対応後に問題なく更新されたことを確認できるか」
まで確認する必要があります。
今回紹介したSSM Agentの脆弱性も、単に対象バージョンをアップデートするだけではなく、今後同様の問題が発生した場合に備えて、SSM Agentを継続的に最新化できる仕組みを検討するきっかけになります。
脆弱性対応は「問題が発生したら手動で対応する」という考え方だけではなく、「問題が発生することを前提として、早期に検知し、影響範囲を把握し、効率的に対応できる運用を作る」という視点が重要です。
AWS環境を運用する際は、セキュリティ速報の確認を定期的な運用に組み込み、必要に応じてRSSによる通知やSSM Agentの自動更新なども活用していきましょう。
コメント