はじめに
2026年10月21日、PHPに「PHP2Shell」と呼ばれる重大な脆弱性が公表されました。影響を受けるバージョンのPHPを利用していて、脆弱な機能に外部からアクセスできる状態だった場合、ログインしていない第三者がサーバー上でプログラムを実行するおそれがあります。
脆弱性への対応では、修正版を適用することが大切です。それと同じくらい重要なのが、自社のどこでPHPが使われているかを、すぐに確認できる状態にしておくことです。
10月23日に開催されたAWSセキュリティセミナー「フロンティアAI時代のサイバー攻撃に備える」では、AIによる脆弱性の発見、公開Webシステムへの攻撃、AWSの責任共有モデル、脆弱性管理、インシデント対応などが紹介されました。
特に印象に残ったのは、攻撃を完全に防ぐことだけを目標にするのではなく、脆弱性に早く気づき、優先順位を付けて修正し、万が一侵入された場合の被害を小さくすることが重要だという点です。
この記事について
セミナーの内容をもとに、初心者にもわかりやすいように整理しています。サービスの提供状況や仕様は変更される場合があるため、実際に導入する際はAWSの公式情報も確認してください。
忙しい方向け：この記事の要点
- AIによって、脆弱性の発見や攻撃が速くなる可能性があります。防御側も、検知・調査・修正のスピードを上げる必要があります。
- 脆弱性への対応は、危険度だけでなく、悪用状況やインターネットからの到達しやすさ、システムの重要度を見て優先順位を付けます。
- AWSを利用していても、利用者側の責任は残ります。データ、アプリケーション、アクセス権、ネットワーク設定などを確認しましょう。
- WAFは攻撃通信を抑えるのに役立ちますが、アプリケーションの認証・認可の不備を自動で修正するものではありません。
- 侵入を完全には防げないことを前提に、ログ監視、権限の最小化、バックアップ、復元テスト、対応手順を整えます。
- マネージドサービスや自動化を活用すると、運用の負担を減らし、アプリケーションの改善に時間を使いやすくなります。
どんな人に向いているか
- AWS上でWebサービスやAPIを運用している方
- 脆弱性への対応やパッチ適用の優先順位に悩んでいる方
- AWSの「責任共有モデル」を知りたい方
- セキュリティ対策をこれから整えたい開発者・インフラ担当者
- AIを開発やセキュリティ運用に使う際の注意点を知りたい方
- インシデント対応やバックアップ・復旧の手順を見直したい方
用語整理
| 用語 | 簡単な説明 |
|---|---|
| 脆弱性 | ソフトウェアや設定にある、攻撃に悪用される可能性のある弱点です。 |
| パッチ | 脆弱性や不具合を修正するために提供される更新プログラムです。 |
| CVE | 公開された脆弱性に付けられる識別番号です。例：CVE-2026-109618
|
| CVSS | 脆弱性の深刻度を評価するための指標です。ただし、点数だけで対応順を決めるのは十分ではありません。 |
| PoC(概念実証) | 脆弱性が実際に悪用できることを示すためのコードや手順です。 |
| API | システム同士が情報をやり取りするための窓口です。画面に表示されないAPIもあります。 |
| WAF | WebサイトやAPIへの通信を検査し、不審な通信を遮断・制限する仕組みです。 |
| マネージドサービス | サーバーやデータベースなどの運用の一部を、サービス提供者が担うサービスです。 |
セミナーの前提：AIは攻撃側にも防御側にも使われる
AIは、脆弱性の調査やログ分析を効率化するのに役立ちます。一方で、攻撃者がシステムの探索や攻撃を自動化するために利用する可能性もあります。
セミナーでは、AIによって攻撃が速く、大規模になり、より見つけにくい脆弱性も狙われる可能性があると説明されました。
ただし、すべての攻撃でAIが使われているわけではありません。個別の攻撃事例でAIの利用が確認されたかどうかと、AIによって攻撃能力が高まる可能性は、分けて考える必要があります。
1. 公開Webシステムでは、画面に見えない部分も狙われる
公開Webシステムとは、インターネットからアクセスできるWebサイトやAPIなどのことです。攻撃者は、既知の脆弱性を探すだけではありません。
たとえば、次のような部分が攻撃対象になる可能性があります。
- Webサイトから利用できるAPI
- 画面には表示されない管理用API
- 設定ファイルやバックアップファイル
- APIキーや認証情報
- Webサーバーから接続できる別のサーバー
APIは、画面上にボタンがあるかどうかに関係なく、直接呼び出せる場合があります。そのため、画面上では操作できない機能でも、API経由で実行できないかを確認することが大切です。
公開Webシステムについて、まず次の点を確認しましょう。
- 公開しているWebサイト、API、管理機能を一覧にする
- 誰が、どの機能やデータを使えるか確認する
- 設定ファイルやバックアップファイルが公開されていないか確認する
- Webサーバーから接続できるサーバーやサービスを把握する
- APIキーや認証情報の権限を必要最小限にする
- 不審なアクセスを後から調査できるよう、ログを保存する
2. 脆弱性が公開されてから攻撃されるまでの時間が短い
セミナーでは、脆弱性が公開された翌日までに悪用が確認された件数が、近年増えていると紹介されました。
資料によると、CISA KEVに掲載された脆弱性のうち、「ネットワーク経由で攻撃できる」「ユーザーの操作が不要」という条件に当てはまるものは、2021年の24件から2026年は10月21日時点で78件でした。資料では、2026年の件数を年間換算すると約95件になると推計しています。
CISA KEVとは
実際に悪用されたことが確認されている脆弱性をまとめた、米国のCISAが公開するカタログです。
セミナーでは、PHP2Shell（CVE-2026-109618 / CVE-2026-109619）について、修正パッチの公開前から悪用の試みが観測され、パッチ公開後まもなくPoCが登場した経緯も紹介されました。
このような状況では、脆弱性情報を知ってから自社のシステムを調べ始めると、対応が間に合わないことがあります。日頃から、次の情報をすぐに確認できるようにしておきましょう。
- どのシステムで、どの製品やバージョンを使っているか
- そのシステムにインターネットからアクセスできるか
- システムがどのようなデータを扱っているか
- 誰が、どの手順でパッチ適用や緩和策を行うか
「自社に何があるか」が分かっていることは、素早い対応の前提です。
3. AIによって脆弱性の発見と対応が変わる
セミナーでは、Anthropicの「Project Glasswing」が、AIを使った脆弱性調査の例として紹介されました。
資料では、Glasswingのパートナーによる検証済みの脆弱性が12万9,000件超、AnthropicによるOSS（オープンソースソフトウェア）の調査で5,500件、うちHighまたはCriticalに分類されたものが3万3,000件超と説明されていました。対象期間が異なる数値も含まれているため、数字を比較するときは集計条件に注意が必要です。
また、資料ではNVDのCVE新規公開数について、2025年通年で48,152件、2026年は10月20日時点で10月分が10,161件と紹介されました。これはCVEの公開数であり、AIが発見した脆弱性の数を示すものではありません。
AIモデルの公開が攻撃・防御に与える影響
セミナーでは、最上位のオープンウェイトモデルのサイバー能力が、6〜7か月前のクローズドなフロンティアAIモデルに相当するとの分析も紹介されました。これは、専門的なAIの能力が、より多くの人に利用されるようになる可能性を示しています。
AIによって攻撃が速くなった場合、脆弱性を見つけるだけでなく、修正パッチを適用する側も速く動く必要があります。
| これまでの考え方 | これから意識したい考え方 |
|---|---|
| 定期的にパッチを適用する | パッチ適用を日常的な運用にする |
| 侵入を防ぐことを中心に考える | 侵入の可能性を考え、被害を小さくする |
| 人が中心となってレビューする | 自動化やAIも使い、検知・対応を速める |
AIが攻撃に使われる可能性を考えることは重要ですが、AIだけが脅威というわけではありません。従来からある脆弱性や設定ミスへの対策も、引き続き必要です。
4. AWSと利用者が分担するセキュリティ対策
AWSの責任共有モデルでは、AWSと利用者がそれぞれ異なる範囲のセキュリティを担当します。
-
AWS：クラウドそのもののセキュリティ
- データセンター
- 物理サーバーやネットワーク
- クラウド基盤など
-
利用者：クラウド上に構築したシステムのセキュリティ
- データ
- アプリケーション
- IDとアクセス権限
- ネットワーク設定
- サービスによってはOSやミドルウェア
AWSを利用すれば、セキュリティ対策がすべて完了するわけではありません。どこまでAWSが管理し、どこから利用者が管理するのかは、利用するサービスによって異なります。
5. AWS Nitro Systemによる基盤側のセキュリティ
責任共有モデルに関連して、セミナーではAWS Nitro Systemによる技術的な統制も紹介されました。
セミナーで説明されたNitro Systemの特徴は、次のとおりです。
- AWSの運用者は、インフラ運用に必要な限定されたAPIを使う
- ハイパーバイザーに、シェルや対話型のログイン経路がない
- ゲストOSのメモリやディスクへアクセスするAPIを用意していない
ハイパーバイザー
1台の物理サーバー上で、複数の仮想サーバーを動かすための基盤ソフトウェアです。API
システムを操作したり、システム同士で情報をやり取りしたりするための窓口です。
セミナーでは、AWSが運用ルールだけに頼るのではなく、データへ到達する経路自体を技術的に制限する考え方が説明されました。
こうした基盤の仕組みは重要ですが、利用者側のアプリケーションやアクセス権限の管理が不要になるわけではありません。
6. 脆弱性管理は、リスクの高いものから対応する
脆弱性が大量に見つかるようになると、すべてに同じ優先度で対応するのは難しくなります。自社の環境にとって、どの脆弱性が危険なのかを考えて対応順を決めましょう。
確認したい観点は次のとおりです。
- その脆弱性が実際に悪用されているか
- インターネットから対象システムにアクセスできるか
- システムが扱うデータや業務はどれほど重要か
- 修正パッチが提供されているか
- パッチ適用までに実施できる緩和策があるか
CVSSの点数は参考になりますが、点数だけで対応順を決めるのではなく、自社のシステムがどのような状態にあるかも合わせて確認します。
脆弱性管理の対象は3つのレイヤー
セミナーでは、脆弱性管理の対象を大きく3つに分けて説明していました。
| レイヤー | 例 | 主な対応 |
|---|---|---|
| OS | Linux、Windowsなど | 提供元の情報を確認し、パッチを適用する |
| ミドルウェア | Webサーバー、データベース、OSSライブラリなど | バージョンを確認し、更新や設定変更を行う |
| アプリケーション | 自社開発のWebサービスやAPI | コードや設計を確認し、問題を修正して再テストする |
カスタムアプリケーションの脆弱性は、利用者や開発担当者が発見・修正する必要があります。 OSやミドルウェアのパッチを適用しても、アプリケーションの認証・認可の不備が自動で直るわけではありません。
Amazon Inspectorの活用
セミナーでは、Amazon Inspectorが脆弱性の検出や優先順位付けに役立つサービスとして紹介されました。
資料で説明されていた主な特徴は、次のとおりです。
- 新しいCVE情報と、システムの構成情報を照合する
- CVSSだけでなく、ネットワークからの到達性や悪用可能性も考慮する
- SBOMなどを使って、影響するソフトウェアの範囲を把握する
SBOM（ソフトウェア部品表）
アプリケーションに含まれるソフトウェアやライブラリを一覧にしたものです。どの部品を使っているかが分かると、脆弱性が見つかったときに影響範囲を調べやすくなります。
検出結果を並べるだけではなく、「どの資産に、どれほどのリスクがあるのか」を把握して、修正につなげることが大切です。
管理するサーバーを減らす
サーバーレス、コンテナ、マネージドデータベースなどを適切に使うと、OSやミドルウェアの運用負荷を減らせる場合があります。
ただし、マネージドサービスを使っても、データの保護、IAMの設定、アプリケーションの脆弱性対応など、利用者側の責任は残ります。「AWSに任せられる作業」と「自社で対応する作業」をサービスごとに確認しましょう。
IAM（Identity and Access Management）
AWSのユーザーやサービスに、どの操作を許可するかを管理する仕組みです。必要な人やシステムに、必要な範囲だけ権限を与えることが基本です。
7. WAFによる緩和とアプリケーションの修正を組み合わせる
AWS WAFなどのWAFは、WebサイトやAPIへの通信を検査し、攻撃パターンに合う通信や大量のリクエストを制限するために使います。脆弱性を修正するまでの間、攻撃を緩和する方法としても役立ちます。
しかし、WAFだけでアプリケーションの権限チェックの不備を修正することはできません。
| 問題の例 | WAFでできること | アプリケーション側で必要なこと |
|---|---|---|
| 攻撃パターンに合う通信 | ルールに基づいて検査・遮断する | 脆弱性の修正や入力値の検証を行う |
| 悪性の送信元や大量リクエスト | 不審な通信やリクエスト数を制限する | 利用者や機能ごとに適切な利用制限を設ける |
| IDOR/BOLAなどの認可不備 | IPやアクセス頻度による補助的な制限を行う | 利用者が対象データを操作できる権限を持つか確認する |
IDOR/BOLA
利用者がURLやAPIのIDを書き換えることで、権限のない他人のデータを見たり操作したりできてしまう問題です。各リクエストで「この利用者が、このデータを操作してよいか」をアプリケーション側で確認する必要があります。
WAFのルールを変更するときは、テスト環境や「Countモード」などを使い、正常な通信まで誤って止めないか確認してから適用しましょう。
8. AIを使ってアプリケーションの脆弱性を見つける
セミナーでは、AIを使った設計レビューやコードレビュー、ペネトレーションテストも紹介されました。
ペネトレーションテストとは、許可された範囲でシステムに攻撃を試み、問題がないか確認するテストです。設計書やAPI仕様書、ソースコードを調べることで、画面からは見つけにくいAPIや認証・認可の問題を発見できる場合があります。
AWS Security Agentについては、次のような活用例が紹介されました。
- 設計書を確認し、設計上のセキュリティリスクを探す
- コードやプルリクエストをレビューする
- APIやURLのパスを調べる
- 認証・認可の不備がないかを調査する
- 見つけた問題をサンドボックスで再現する
- 修正案や確認手順をレポートする
サンドボックス
本番環境とは分けて用意する、テスト用の隔離された環境です。安全に動作確認や検証を行うために使います。
セミナー資料では、AWS Security Agentを含むAWS Continuumの脆弱性管理の流れとして、次の4段階が紹介されていました。
-
Discovery — 発見
脆弱性や攻撃経路を見つけます。 -
Prioritization — 優先順位付け
システムや業務への影響を考えて、対応の順番を決めます。 -
Validation — 検証
テスト環境などで、本当に問題があるかを確認します。 -
Mitigation & Remediation — 緩和・修復
防御策やコード修正を行い、問題が解消したか確認します。
AIの検出結果を確認せず、本番環境へそのまま適用するのは避けましょう。まずは人が確認する運用から始め、結果を確認しながら自動化の範囲を広げる方法が現実的です。
9. 侵入後に備える：ログ、インシデント対応、バックアップ
攻撃を完全に防ぐことが難しい以上、侵入や不審な活動を早く見つけ、調査・封じ込め・復旧できるようにしておく必要があります。
セミナーでは、Amazon GuardDutyによる不審な活動の検知や、AWSのインシデント対応支援が紹介されました。サービスを利用するだけでなく、次のような準備も重要です。
- 調査に必要なログを保存する
- 緊急時の連絡先を決めておく
- 誰が、何を、どの順番で行うかを手順書にまとめる
- 不審なアクセスを見つけたときの報告先を決める
バックアップは「取る」だけでなく「戻せる」ことが大切
バックアップを取るかどうか、どのように設定するか、復元できるかを確認することは、利用者側の責任です。バックアップがあっても、攻撃者に削除されたり、復元に失敗したりすれば、十分な備えにはなりません。
- 本番環境からバックアップを分離する
- 保持期間中の削除を防ぐ仕組みを使う
- バックアップの取得と保持を自動化する
- 定期的に復元テストを行う
- 必要に応じて、バックアップにマルウェアが含まれていないか確認する
論理エアギャップ
本番環境とバックアップを論理的に分離し、本番環境が攻撃されてもバックアップへの被害が広がりにくくする考え方です。
バックアップは、取得できていることを確認するだけでなく、実際に復元できることを定期的に試すことが重要です。
まとめ：発見から復旧までを速くする
今回のセミナーで特に印象に残ったのは、AI時代のセキュリティでは、脆弱性の「件数」だけでなく、発見から対応までにかかる時間が重要になるという点です。
まずは次のことから始めてみましょう。
-
自社のシステムとデータを把握する
公開Web、API、管理機能、OS、ミドルウェア、ライブラリを一覧にします。 -
リスクの高い脆弱性から対応する
悪用状況、インターネットからの到達性、システムの重要度を確認します。 -
パッチ適用を日常業務にする
脆弱性の検出から、テスト、適用、確認までの流れを整えます。 -
入口の防御とアプリケーションの修正を組み合わせる
WAFなどで通信を緩和しながら、認証・認可やコードの問題も直します。 -
侵入後の被害を小さくし、復旧できるようにする
ログ、アクセス権限、バックアップ、復元テストを継続します。
AIは攻撃を速める可能性がある一方、脆弱性の発見やログ分析など、防御側の助けにもなります。AWSの機能を活用しながらも、自社の責任範囲を把握し、発見から修正、復旧までの時間を短くしていきたいです。
参考文献
セミナーの詳細については、以下のAWS公式ブログをご覧ください。