Webシステム・API への不正アクセスに対し、いますぐ企業が確認すべき5つのポイント

---

はじめに

Web/APIサービスを構成する主な接続関係

過去の記事でも、クラウド利用や働き方の多様化によってIT資産が社内ネットワークの内外へ広がり、アタックサーフェス^※5（攻撃対象領域）が拡大していることを取り上げました。WebやAPIだけでなく、VPN、ID、クラウド上のデータ、ネットワーク機器を含めて、境界が分散していることを前提に対策を考える必要があります。

• 参考記事

  “安全幻想”から脱却したセキュリティーの体制づくりが急務

---

特定製品や1つの脆弱性だけを追いかけない

確認観点

• 外部公開されている資産、サービス、API、管理画面を一覧化する
• 資産ごとに利用目的、管理責任者、公開の必要性を明確にする
• 一時利用の検証環境や旧サブドメイン、廃止予定システムも確認する
• 委託先・再委託先やクラウドで管理される公開面を確認する
• クラウドサービス・SaaS・VPNなど、利用中の外部サービスと、そこで使用しているアカウントを洗い出す（部署単位で契約・利用しているものを含む）
• BIツールや管理系システムなど、社内利用を前提としたシステムが、外部から到達できる状態になっていないかを確認する

---

攻撃の「入口」がWeb画面とは限らない

APIで確認したい技術項目

• すべてのAPIエンドポイントを把握し、不要・旧版を停止する
• サーバー側で認証・認可を実施し、クライアント側のロジックだけに依存しない
• 利用者、テナント、オブジェクト、機能単位で権限を検証する
• APIキー、トークン、秘密情報をアプリケーションへ固定的に埋め込まない
• レート制限、入力値検証、異常な列挙アクセスの検知を実施する
• APIエラーや拒否応答も含めてログを取得し、調査可能にする
• 外部のURLを取得・呼び出す機能は、通信先を必要なものに限定する

---

AI・自動化によって弱点探索の速度が変わる

---

PHPの重大脆弱性「PHP2Shell」への対応

2026年10月21日、PHPについて2つの脆弱性、CVE-2026-109618およびCVE-2026-109619（通称：PHP2Shell）が公表されました。独立行政法人情報処理推進機構（以下、IPA）によれば、前者はメモリー不足（OOM）のエラー処理、後者はリクエスト処理に関連し、悪用された場合には遠隔の第三者によって任意コードを実行される可能性があります。深刻度はCVSS^※10 v4.0で9.2と評価されています。対象には、PHP-FPM^※11やApacheのmod_php^※12など主要な動作方式が含まれます。特にmod_phpでは、認証されていないリクエストによって、アプリケーションコードが実行される前に本脆弱性を悪用できることが示されているため、「ログインが必要なサイトだから安全」とは言えません。

PHP2Shellの対象系列と修正版

• ※

  IPA「PHPの脆弱性対策について」およびJPCERT/CC「PHPにおける複数の脆弱性に関する注意喚起」を基にユニアデックスが作成

PHPは、独自開発したWebシステムだけでなく、各種ソフトウエア製品やLinuxディストリビューションが提供するパッケージの中でも利用されます。CMS（コンテンツ管理システム）やECなどのパッケージ製品、管理画面を備えた機器・アプライアンスの内部で動いている場合もあります。PHPを直接導入した記憶がないという理由だけで対象外と判断せず、利用製品・OS・コンテナイメージを含め、提供元の情報を確認する必要があります。また、OSや製品の提供元が修正を反映したパッケージを配布している場合は、バージョン番号が表と一致しなくても対処済みのことがあるため、提供元の情報で確認してください。

---

PHP対応はパッチを適用して終了ではない

脆弱性判明後に修正版へ更新しても、それ以前に攻撃されたかどうかは別の問題です。JPCERT/CCは、修正版の適用に加えて侵害有無の調査を求めています。調査は脆弱性の公表日以降に限らず、保存されている範囲でそれ以前のログも確認対象とすることの検討が必要です。

確認対象となる痕跡

JPCERT/CCは、以下のような痕跡の確認を挙げています。

• 不自然に長い、または異常な形式のPHPSESSID Cookie
• 不審なmultipart/form-data形式のHTTPリクエスト
• その前後のPHPメモリー上限関連エラー、HTTP 500エラー
• PHPワーカープロセスの予期しない異常終了や頻繁な再起動
• 不審なプロセス、外部通信、ファイル作成、権限変更

これらの痕跡が確認できない場合でも、攻撃を受けていないと断定できるとは限りません。単一の検知ルールに依存せず、Web、プロセス、ネットワーク、ファイル、認証など複数の観点を組み合わせます。ログは、サーバーの再起動や更新、保存期間の経過によって失われることがあるため、更新作業の前にログを保全することが重要です。また、公開されている不審な通信元の情報との照合だけに頼らず、アクセスの量、頻度、通常と異なる使われ方も確認します。

PHP重大脆弱性への対応フロー

• ※

  JPCERT/CC「PHPにおける複数の脆弱性に関する注意喚起」およびIPA「PHPの脆弱性対策について」を基にユニアデックスが作成

---

すぐにパッチを適用できない場合

---

ネットワークから見ると、重要なのは入口だけではない

IDも「新たな境界」として確認する

ネットワークを分離していても、正規のIDや管理者権限が奪われれば、許可された経路を使って別のシステムへ移動される可能性があります。サーバーに保存されたAPIキーやクラウドの認証情報が窃取され、別のシステムへの不正アクセスに使われる可能性もあります。過去の記事では、攻撃者が管理者権限を狙い、侵入地点から別のシステムやネットワークへ移動するラテラルムーブメント^※17のリスクを解説しました。特権アカウントの棚卸し、MFA^※18、不要な権限の削減、権限変更や通常と異なる認証の監視を、ネットワーク制御と組み合わせて確認することが重要です。APIキーやトークンは有効期限を設けて定期的に更新し、侵害の疑いがある場合は速やかに失効・再発行します。

• 参考記事

  最新の脆弱性管理に基づいた ID セキュリティー強化が急務　新たなセキュリティー境界としての ID

ネットワーク面の確認事項

• Web/アプリケーション/データベースなど役割の異なる層の通信を必要最小限にする
• 管理ネットワーク、バックアップ、監視基盤への経路を分離する
• サーバーからのOutbound通信を業務上必要な宛先・プロトコルへ制限する
• クラウドのSecurity Group^※19、Network ACL^※20、ルート、公開IPを確認する
• 異常時に対象ホスト・セグメント・IDを速やかに隔離できるようにする
• サーバーが保持するAPIキーや認証情報の有効期限と更新状況を確認し、疑いがある場合は失効・再発行できる手順を用意する
• 社内利用を前提としたシステムは、インターネットに公開しない、または接続元を限定し、実際に外部から到達できないことを確認する

---

Web/APIの異常をネットワークの動きとして見る

侵害確認に利用する主な情報

• ※

  JPCERT/CC「PHPにおける複数の脆弱性に関する注意喚起」を基にユニアデックスが作成

---

いま企業が確認すべき5つのポイント

① インターネットから見える攻撃面を把握する

管理台帳だけではなく、外部から到達可能なWeb、API、管理画面、VPN、クラウド、検証環境などを確認します。部署単位で契約・利用している外部サービスも含めて洗い出し、BIツールなど、本来は社内利用を想定しているシステムがインターネットから到達できる状態になっていないかも確認します。資産、公開状態、通信経路、利用目的、管理責任を関連付け、現在も公開が必要かを判断します。

② 脆弱性を「存在するか」ではなく「攻撃可能か」で考える

CVSSのスコアだけで判断するのではなく、外部からの到達性、実際の悪用状況、資産の重要度、保有するデータ、業務への影響を組み合わせて評価する必要があります。PHPのような重大脆弱性では、利用の有無、公開状態、更新の可否、侵害の有無を迅速に判断できる状態かを確認します。製品に組み込まれたPHPやサポート終了済みのバージョンも対象に含め、更新できない場合の公開判断、更新・移行の責任者と期限を明確にします。更新後も開発元から追加の案内が出ていないかを継続して確認します。

③ WebだけでなくAPIの認証・認可を確認する

APIごとに認証、利用者・テナント・オブジェクト単位の認可、秘密情報の管理、レート制限、不要エンドポイント、異常アクセスの監視を確認します。クライアント側の難読化や非公開URLだけに依存しません。ログイン後に使えるAPIや、外部のURLを呼び出す機能も攻撃対象になり得ます。

④ ログを保存するだけではなく侵害を判断できる状態にする

Web、認証、ネットワーク、エンドポイント、クラウドの情報を時系列で横断し、いつ、どこから、誰が、何を実行し、その後どこへ通信したかを追えるようにする必要があります。保持期間、時刻同期、分析責任者を平時から整理し、調査したい期間のログが残っているか、提供元でしか見られないログがないかも確認します。不審な通信元の情報との照合だけに頼らず、通常と異なる使われ方を確認できることが重要です。

⑤ 侵入を防ぐだけではなく、侵入されても広げない

• 参考記事

  ビジネスデータが狙われている？！サイバー攻撃の最新情報を学ぶ ～インフラデータ保護編～

• ※

  本稿の内容を基にユニアデックスが作成

---

5つの対策を「点」ではなくサイクルにする

5つのポイントは独立したチェック項目ではありません。これらを、次の6つのステップからなるセキュリティ対策の継続的な サイクルの中で組み合わせて 運用します。

• 1．把握：

  資産、API、公開面、外部サービス、通信経路、責任者を明らかにする

• 2．評価：

  脆弱性、脅威情報、悪用状況、到達可能性、業務影響から優先順位を決める

• 3．対策：

  パッチ、設定変更、認証・認可、アクセス制御、認証情報の更新を実施する

• 4．監視：

  Web、ネットワーク、ID、エンドポイント、クラウドの異常を確認する（ログが残っていることを含む）

• 5．検証：

  弱点の解消と更新の反映状況を確認し、利用可能なログや痕跡から侵害の有無を調査する

• 6．改善：

  環境・脅威・業務の変化に応じて見直す（サポート終了や新たな注意喚起を含む）

セキュリティ対策の継続的サイクル

新しいサーバー、クラウドサービス、ID、APIが追加されるたびにアタックサーフェスは変わります。ネットワーク構成や権限が変われば到達可能性も変化します。「一度安全を確認した」ことと「現在も安全である」ことは同じではありません。
このサイクルは、設定不備や過剰権限、既知の脆弱性を平時に見つけて是正するプロアクティブな対策と、攻撃・侵害の兆候を検知し、封じ込め、調査、復旧するリアクティブな対策の両輪で成り立ちます。どちらか一方ではなく、予防と対応を継続的につなぐことが重要です。 これらは情報システム部門だけで完結せず、経営層や事業責任者を含めて、平時から役割と判断基準を決めておく必要があります。

---

ネットワークとセキュリティを分けて考えない

Web、API、クラウド、サーバー、ID、ネットワークは、すべてがつながることでサービスを構成しています。そして攻撃者も、そのつながりを利用します。 一カ所の侵害から、認証情報や通信経路を使って別のシステムへ広がる可能性があります。また、担当部門や委託先が分かれていると、確認や判断の抜け・遅れが生じやすくなります。
ユニアデックスは、ネットワークとセキュリティの双方に向き合ってきた経験から、個々の対策だけではなく、それらが実際のシステムのつながりの中でどう機能しているかを見ることが重要だと考えています。

---

おわりに

相次ぐWebシステム・APIへの不正アクセス、A2B攻撃、PHP2Shellは、個別には異なる問題です。しかし、企業に突き付けられている基本的な問いには共通点があります。

• 自社に何が存在しているのか
• 何がインターネットから見えているのか
• どこまで通信できるのか
• どこに弱点が残っているのか
• 攻撃されたことに気づけるのか
• 侵害された場合、被害を限定できるのか
• 安全な状態へ戻し、再発防止につなげられるのか

個別のセキュリティ製品を導入すること、脆弱性へパッチを適用することは重要です。しかし、それだけでセキュリティ対策が完了するものではありません。

今回の一連の事案を一時的な緊急対応だけで終わらせず、自社のセキュリティ対策が実環境で期待通りに機能しているか、その実効性を改めて確認する機会にしていただきたいと考えています。

本稿は2026年10月26日時点で確認できる公開情報を基に作成しています。脆弱性情報や推奨対応は更新される可能性があるため、必ず各機関・開発元・製品提供元の最新情報をご確認ください。

専門用語の説明

• ※1

  API：ソフトウエアやサービス同士が機能やデータをやり取りするための接続仕様。Webやモバイルアプリの背後で利用される。

• ※2

  Webシェル：侵害したWebサーバーなどに設置され、Web経由でコマンド実行やファイル操作を行うために悪用されるプログラム。

• ※3

  A2B（App-to-Backend）攻撃：公開されているスマートフォンアプリなどを解析し、接続先やAPIに関する情報を手掛かりに、バックエンドシステムを狙う攻撃。

• ※4

  WAF：WebアプリケーションへのHTTP/HTTPS通信を検査し、攻撃と判断した通信の検知・遮断を行う仕組み。Web Application Firewallの略。

• ※5

  アタックサーフェス：攻撃者が侵入や不正操作の足掛かりとして狙い得る、外部公開資産、アカウント、API、設定、通信経路などの範囲。

• ※6

  SSRF：攻撃者がサーバーに不正な通信先を指定し、サーバー自身から内部・外部の別システムへリクエストを送らせる脆弱性。

• ※7

  RCE：脆弱性を悪用し、対象システム上で攻撃者が任意のコードや命令を実行できる状態。Remote Code Executionの略。

• ※8

  SQLインジェクション：入力値を通じて不正なSQL文を混入させ、データベースの参照、変更、削除などを試みる攻撃。

• ※9

  IDOR/BOLA：識別子やAPI要求を変更することで、本来権限のない他者のデータやオブジェクトへアクセスできてしまう認可不備。

• ※10

  CVSS：脆弱性の技術的な深刻度を共通尺度で評価する仕組み。

• ※11

  PHP-FPM：PHPの処理をFastCGI方式で実行・管理する仕組み。WebサーバーとPHP処理を分離して動作させる構成で利用される。

• ※12

  mod_php：Apache HTTP ServerのモジュールとしてPHPを実行する方式。

• ※13

  IPS：ネットワーク通信を監視し、攻撃と判断した通信を検知・遮断する仕組み。Intrusion Prevention Systemの略。

• ※14

  EDR：端末やサーバー上のプロセス、ファイル、通信などを継続的に監視し、不審な挙動の検知・調査・封じ込めを支援する仕組み。Endpoint Detection and Responseの略。

• ※15

  Inbound通信：外部ネットワークからサーバーや端末へ向かう通信。サーバーやポートの脆弱性を突いた侵入などさまざまな侵害に利用され得る。

• ※16

  Outbound通信：サーバーや端末から外部ネットワークへ向かう通信。侵害後の外部指令通信や情報持ち出しにも利用され得る。

• ※17

  ラテラルムーブメント：侵入したシステムを起点に、認証情報や通信経路を悪用して別の端末・サーバーへ横展開する動き。

• ※18

  MFA：パスワードに加え、端末、生体情報、ワンタイムコードなど複数の要素を組み合わせて本人確認する方式。Multi-Factor Authenticationの略。

• ※19

  Security Group：クラウド環境で、仮想サーバーなどへの通信を許可・制限するための仮想的なアクセス制御。

• ※20

  Network ACL：ネットワーク単位で通信の許可・拒否を制御するアクセス制御リスト。

参考情報

• JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」
• JPCERT/CC Eyes「連続不正アクセス事案の攻撃手法に関する調査」（2026年10月15日）
• JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」
• NICT「【注意喚起】相次ぐ情報漏えい、その原因の一つは『アプリ解析からのサーバ攻撃』」（2026年10月13日）
• NICT CYNEX「【注意喚起】相次ぐ情報漏えい、その原因の一つは『アプリ解析からのサーバ攻撃』」（2026年10月13日）
• NICT LETTICE「相次ぐ情報漏えい、その原因の一つは『アプリ解析からのサーバ攻撃』」詳細PDF（2026年10月13日）
• IPA「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」
• IPA「PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619：PHP2shell）」
• IPA「不正アクセス対策特設サイト」
• php.net「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日）