分断を前提に設計し、一つの故障や侵害を全体に波及させない。その考え方は、情報システムだけでなく、企業の承認や内部統制にも当てはまります。
便利さは何を省略したのか
デジタル化によって企業の業務は速くなりました。かつて課長、部長、役員、経営者という段階的な承認を必要とした判断も、権限の委譲と情報システムによって短時間で実行できます。しかし、承認の中には誤りや不正を発見する機会もありました。
承認の多さが正確さを保証するわけではありません。形式的な稟議によって判断が遅れ、責任が曖昧になることもあります。問うべきは、何を速くしたかだけでなく、速くするために何を取り除いたかということです。
Active Directoryは何のためにあるのか
株式会社には、株主総会、取締役会、代表取締役など、会社の意思決定と業務執行を担う仕組みがあります。会社の形態によって機関構成は異なりますが、重要な判断を誰が行い、誰が監督し、どのような承認を必要とするかが、法律や社内規程によって定められています。
では、企業の重要な情報資産を管理する情報システムには、これに相当する仕組みが存在するのでしょうか。
Windowsを中心とする企業ネットワークで広く利用されているのが、Active Directory（AD）です。Active Directoryという名称は、情報を検索・管理するディレクトリサービスを表しています。Directoryは住所録や名簿に相当し、利用者、コンピューター、グループなどの情報を管理します。Active Directoryは単なる静的な名簿ではなく、認証やアクセス制御、管理設定と連動する仕組みです。
例えば、社員が会社のPCにログインする際、その社員が誰であるかを確認し、所属するグループや与えられた権限に応じて、利用できる情報資産や機能を制御します。入退社や異動に伴うアカウント管理、パスワードの変更、端末設定の統一なども、集中して行うことができます。
ドメインコントローラーは、何を管理しているのでしょうか
Active Directoryの中心となるのが、ドメインコントローラー（Domain Controller）です。ドメインコントローラーは、利用者やコンピューターの認証情報、グループ構成などを管理し、ネットワーク上の認証とアクセス制御に必要な情報を提供します。
ただし、ドメインコントローラーは、企業の経営者のように判断を行う存在ではありません。あらかじめ設定された情報と規則に基づいて処理を実行するシステムです。
では、その規則を決めるのは誰でしょうか。誰が社員のアカウントを作成し、誰がパスワードを再設定し、誰が機密情報へのアクセスを許可するのでしょうか。そして、それらの操作が正当であると、誰が承認するのでしょうか。
ここで区別すべきなのが、情報システムを操作する権限と、その操作を承認する権限です。
| 権限の種類 | 具体的な内容 | 本来確認すべきこと |
|---|---|---|
| アカウント管理 | 利用者IDの作成、変更、無効化、認証情報の再設定 | 誰の依頼で、誰が承認したか |
| アクセス権限の管理 | 共有フォルダーや業務システムを利用できる範囲の変更 | 情報資産の責任者が許可したか |
| システム管理 | 端末設定、管理ポリシー、サーバー構成の変更 | 変更の必要性と影響範囲を確認したか |
| 特権管理 | ドメイン全体に影響する管理権限の使用や委譲 | 誰が使用を認め、誰が操作を監査するか |
| 情報資産の管理責任 | 情報の利用目的、保存期間、外部提供、廃止などの判断 | 誰が情報の責任者で、どの規程に基づくか |
ADには、管理権限をグループや組織単位に分け、必要な範囲だけを委譲する機能があります。しかし、それだけで情報資産の所有者や利用目的、変更の承認手続きまで決まるわけではありません。これらは企業が別途定め、情報システムの設定と運用に反映する必要があります。
技術的な管理者と、情報資産の責任者は同じではありません
会社の経理担当者が会計システムを操作できるからといって、すべての支払を自分で承認できるわけではありません。支払の申請、承認、実行、記録を分けるのは、不正や誤りを防ぐためです。
情報システムでも、同じ考え方が必要です。管理者は業務上、社員のパスワードを再設定し、アクセス権限を変更する能力を持つ場合があります。しかし、その操作能力があることと、任意の情報資産へのアクセスを許可する経営上の権限があることは同じではありません。
さらに、ドメイン全体に影響する強い特権を持つ管理者は、設定によっては自分自身や別のアカウントに追加の権限を与えられます。十分な分離や監査がなければ、権限を使用する者が、権限を変更する能力も持つことになります。
これは株式会社に例えれば、重要な業務を執行する者が、承認規則まで自由に変更できる状態に近いものです。組織としての承認と、システム上の操作可能性が分離されていないことが問題になります。
管理者の権限は、侵入者にとっても価値があります
ADを利用すれば、多数の端末や利用者を効率的に管理できます。しかし、管理できる範囲が広いほど、その特権アカウントが侵害された場合の影響も大きくなります。
ランサムウェア攻撃でADや特権認証情報が狙われる理由の一つは、個々のPCに対して別々に権限を取得するよりも、共通管理基盤を通じて広い範囲へ到達できる場合があるためです。
Microsoftも、特権管理について、認証基盤、業務用サーバー、利用者端末を異なる管理階層に分ける考え方を示しています。高い権限を持つ認証情報が、信頼性の低い端末や通常業務の環境へ露出しないようにするためです。 Microsoft Learn「Active Directoryの特権管理と階層モデル」 で、その設計思想が説明されています。
ADの存在自体が問題なのではありません。問うべきは、一つの管理者権限を取得した者が、誰の承認も必要とせず、どこまで情報資産を操作できるのかということです。
会社の重要な財産については、決裁規程や職務分離によって管理する一方、情報資産については、管理者アカウントが許可する操作をそのまま実行できる構造になっていないでしょうか。
情報資産を管理する技術は存在しています。しかし、その情報資産を誰が統治し、誰が権限の使用を承認し、誰が監督するのかという仕組みは、企業自身が設計しなければなりません。
リモートワークが接続した情報資産
コロナ禍を契機にリモートワークが普及しました。その方法の一つであるRDPは、画面操作だけでなく、設定によって接続元PCのドライブやクリップボードを接続先へ提供できます。
ある企業が、共通管理基盤の下に複数の仮想Windowsを置き、社員がRDPで接続する仕組みを採用したとします。共通特権が侵害されれば、複数の仮想環境へ不正に到達する危険があります。さらに、ドライブ共有を許可したRDPセッションに侵入者がアクセスできれば、接続元PCのファイルにもアクセス経路が生じます。ファイルへのアクセスと、接続元PCでのマルウェア実行は別の問題です。
更新という不便を先送りする
Webサイトや業務システムは、さまざまなソフトウェアを組み合わせて動いています。その代表例がPHPとNode.jsです。
PHPは、Webサーバー上で動作するプログラミング言語です。問い合わせフォームや会員管理、データベースとの連携など、多くのWebサービスで利用されています。一方、Node.jsは、JavaScriptをサーバー側でも実行するための環境で、WebアプリケーションやAPI、リアルタイム通信などに利用されています。
PHPもNode.jsも、以前からバージョン更新とサポート期限が設けられています。更新には互換性試験、依存関係の確認、保守時間の確保、必要に応じたサービス停止や切り戻しが必要です。これは日常の運用にとって不便です。
しかし、更新を先送りしても、保守の必要性がなくなるわけではありません。重大な脆弱性が公表されたとき、更新可能な環境が整備されていなければ、十分な検証時間を確保できないまま、サービスを停止するか、危険を承知で稼働を続けるかという判断を迫られます。
この問題は、ソフトウェアの更新だけではありません。情報システムの構成を把握し、不要な機能や管理対象を見直し、必要な保守を継続できる規模に維持することも重要です。こうした管理対象の適正化については、 「兵庫県のWebサイト459件は本当に必要か」 でも取り上げています。
また、重大な脆弱性が発覚したときの停止判断と、その判断に至るまでの管理体制は分けて考える必要があります。 「経営者自身が、情報システムを監査する」 では、緊急停止の合理性だけでなく、経営者による監査と意思決定の重要性を論じています。
サイバー攻撃を受けてから対策を講じるだけでは、被害を防げない場合があります。一方、攻撃を検知し、侵入を遮断する技術や制度が発展しても、それを実際に運用する組織の管理能力が伴わなければなりません。能動的サイバー防御と情報システムの統治については、 「記号が現実を代理する社会が崩れるとき｜能動的サイバー防御とは何か」 で考察しています。
問題は、更新しなかったことだけではありません。更新に必要な予算、検証環境、人員、停止時間を誰が確保し、更新しないことによる危険を誰が許容していたのかという、経営上の判断です。
更新を先送りしても、保守の必要性が消えるわけではありません。重大な脆弱性が公表されてから初めて更新方法や停止可否を検討するなら、平時に分散できた作業を緊急時に集中させることになります。すべてを即時更新することが正解ではありません。更新を見送る判断と期限、代替策を誰が承認していたかが問われます。
会計監査は内部統制を代行しない
企業が財務諸表の監査を外部の監査法人に依頼しても、日々の仕訳、支払承認、職務分離、資産管理などの内部統制を整備し運用する責任は企業に残ります。監査を受けることと、監査対象となる仕組みを運用することは別です。
情報システムも同じです。外部のセキュリティ会社が公開Webサイトを診断しても、ADの共通特権、RDPの共有設定、委託先の認証情報、解約済み資産まで検証されたとは限りません。経営者は診断の結果だけでなく、何が診断範囲に含まれ、何が対象外だったかを把握する必要があります。
制度が存在しても機能するとは限らない
アスクルは情報セキュリティ方針、ISMS推進体制、ISO/IEC 27001認証などを公表していました。一方、2025年12月12日の同社のランサムウェア調査報告では、委託先管理者アカウントの多要素認証未適用、被害環境のEDRや監視の不足、バックアップの暗号化などが明らかにされています。
ここから問えるのは、制度や認証の有無だけではありません。重要な例外を誰が把握し、どの危険を受け入れ、どの範囲まで監査が届いていたかです。公表資料から個人の過失や重過失を一律に認定することはできませんが、内部統制の実効性を問う根拠にはなります。
日米のPHP対応に現れた内部統制の違い
2026年10月、PHPの重大な脆弱性「PHP2Shell」（CVE-2026-109618、CVE-2026-109619）が公表されました。日本では企業や行政機関による予防的なWebサイトの停止が相次ぎました。一方、米国の大手IT事業者では、影響範囲を評価し、サービスを継続しながら対策を進める対応も見られました。日本経済新聞は、脆弱性が8月に発見されていた経緯とともに、この日米の対応差を報じています。日本経済新聞「PHP欠陥でサイト止めた日本、止めなかった米国」。
PHP2Shellは、PHP自体に存在する脆弱性であり、条件によっては認証を受けていない第三者による遠隔コード実行につながります。修正プログラムの適用は重要ですが、影響を受けるシステムを特定し、安全に更新し、正常なサービスへ復帰させるには、それ以前からの運用体制が必要です。
この違いは、新型コロナウイルス感染症（COVID-19）のパンデミック初期に、各国が直面した問題ともよく似ています。危険を遮断するために活動を止めるのか、感染や侵害が起こり得ることを前提として、必要な機能を維持するのか。いずれの場合も、危機が発生してから選択できる対策は、それ以前に整備していた仕組みに左右されます。
活動を止めて危険を遮断するか、活動を維持しながら対処するか
コロナ禍では、日本でも一斉休校や緊急事態宣言に伴う営業自粛が実施されました。米国や欧州でも都市封鎖や営業制限が行われており、単純に日本だけが活動を止めたわけではありません。各国は感染拡大の抑制と、経済活動や社会機能の維持という二つの課題に直面しました。
今回のPHP2Shellでも、似た判断が求められました。影響が不明なサービスをいったん停止することは、危険を遮断する合理的な方法です。しかし、停止によって顧客の業務、行政サービス、生活に必要な情報提供まで止まる場合があります。
重要なのは、停止するか否かという結果だけではありません。影響を受ける部分だけを切り離し、それ以外の機能を維持する選択肢があったのかという点です。
これは、分断を前提に設計するということで取り上げてきた、自律・分散・非同期の考え方にも通じます。全体が一つの管理基盤やサービスに依存していれば、一部分の危険が全体の停止につながります。反対に、機能を分離し、縮退運用や独立した代替手段を備えていれば、必要な機能を残せる可能性があります。
危機に対応するための基盤は、平時につくられる
コロナ禍の日本では、保健所への業務集中、FAXによる情報管理、検査や集計の遅れなど、平時には表面化しにくかった業務上の制約が明らかになりました。問題は担当者が努力しなかったことではありません。急激に増加した業務量に対して、情報収集、処理能力、権限分担、代替手段が十分に対応できなかったことです。
PHPの更新でも、同じ構造が現れます。稼働しているPHPのバージョン、依存するライブラリ、関連するWebサイトや業務システムを即座に把握できなければ、影響調査から始めなければなりません。検証環境がなければ、本番環境への変更に伴う不具合も評価しにくくなります。
そこで意味を持つのが、コンテナ技術やCI/CD（継続的インテグレーション・継続的デリバリー／デプロイ）です。コンテナはアプリケーションと必要な実行環境を一定の単位で管理する技術であり、CI/CDはソフトウェアの検証や配備を継続的に実施する仕組みです。これらを適切に運用すれば、修正済みの環境を事前に試験し、段階的に配備し、問題があれば切り戻すことができます。
ただし、コンテナやCI/CDを導入するだけで無停止更新が実現するわけではありません。データベースの互換性、セッション管理、依存先サービス、負荷分散、障害時の復旧手順まで設計する必要があります。これらの運用技術も、米国企業だけのものではありません。
危機が発生した瞬間に便利な技術が生まれるわけではありません。平時から更新、試験、切り戻しを繰り返すという不便を引き受けてきた企業ほど、有事に選べる手段が増えるのです。
情報を先に受け取れる組織と、公開後に対応する組織
コロナ禍では、ワクチンの研究開発、生産能力、調達契約、規制当局による承認手続きが、各国の接種開始時期や供給能力に影響しました。米国では「ワープ・スピード作戦」によって開発と生産への大規模な支援が行われました。一方、日本では海外製ワクチンの承認・調達・供給体制を整える過程に時間を要しました。
ソフトウェアの重大な脆弱性にも、公開前に関係者が協力して修正を進める「協調的な脆弱性開示」という仕組みがあります。開発元、研究者、ソフトウェア配布事業者、大規模サービス提供者などが、公開前から修正と配布を準備する場合があります。
PHP2Shellでも、修正プログラムの準備と配布に関係する事業者には、一般公開前から調整に参加していた組織がありました。しかし、個々の米国企業や日本企業が、いつ、どの情報を受け取ったかは同一ではありません。国籍だけで情報共有の内外を区別することはできません。
ここでも、危機の発生前から情報共有や更新の仕組みに参加できる体制を構築していたかが問われます。また、一般公開まで詳細な技術情報を受け取れない企業であっても、保守対象の把握、更新手順、サービス縮退、代替環境の準備は平時から進められます。
コロナ禍で得た教訓は、内部統制に組み込まれたのでしょうか
コロナ禍を経て、リモートワーク、非対面手続き、配送方法の多様化など、社会活動を維持するための仕組みが普及しました。しかし、業務を遠隔化し、情報システムへの依存を高めることと、その情報システムが停止しても業務を継続できることは同じではありません。
企業はリモートワークを実現するためにVPNやRDP、クラウドサービスを導入しました。その一方で、管理権限の集中、接続元PCとの情報共有、保守対象の増加など、新しい管理課題も生まれました。便利になった業務の背後で、以前より多くの機能が同じ認証基盤やネットワークに依存している場合があります。
危機に対応した経験が、そのまま次の危機への備えになるわけではありません。経験を手順、予算、権限、訓練、監査へ反映しなければ、一時的な対応で終わります。
2026年には、AIを利用した脆弱性の発見や攻撃の自動化も進んでいます。攻撃者が短時間で多数の対象を調査できる環境では、事業者側が毎回、手作業による影響調査と緊急決裁を繰り返す体制には限界があります。
必要なのは、侵害されないことだけを前提とする安全性ではありません。侵害や障害が起こり得ることを前提に、被害の到達範囲を制限し、必要な機能を維持し、安全に復旧する能力です。これはサイバーレジリエンスと呼ばれます。
ただし、サービスの継続を優先して、侵害された環境をそのまま稼働させ続けることが正しいわけではありません。制御できない危険がある場合には、停止も必要です。問われるのは、停止以外の選択肢を準備していたかどうかです。
コロナ禍でもPHP2Shellでも、危機の際に現れたのは技術的な問題だけではありません。平時の投資、情報共有、権限委譲、代替手段、継続的な訓練という内部統制の実態です。危機から学んだかどうかは、危機の後に何を制度として残したかによって評価されるべきです。
侵害には段階があり、救済にも段階がある
サイバー攻撃による被害は、突然発生したように見えることがあります。しかし、ランサムウェアなどの侵入型攻撃では、攻撃者が事前の調査から実際の被害発生まで、複数の段階を経ている場合があります。
公開されたシステムをスキャナーで調査し、利用可能な侵入口を探す。認証情報や脆弱性を悪用して侵入し、内部のネットワークや認証基盤を調べる。必要な権限を取得し、重要な情報を探索・収集する。その後、情報を外部へ持ち出したり、バックアップを妨害したり、データを暗号化したりする場合があります。
実際の順序や手法は攻撃によって異なり、すべての段階を経るとは限りません。しかし、重要なのは、被害が発生するまでの間に、防御や検知、遮断を行う機会が複数存在し得るという点です。
PHP脆弱性公表後、クラウド上から続く自動スキャン
2026年10月21日のPHP重大脆弱性の公表後、当社Webサーバーでは、設定ファイルや開発用APIなどを探索する自動スキャンが継続して確認されました。
10月22日には、Google Cloud上のIPアドレス 35.229.143.62 から、2,052件のHTTPリクエストが記録されました。要求先には、環境設定ファイル .env、GraphQL API、Next.js関連パスなどが含まれており、33種類のUser-Agentが使い分けられていました。
翌23日には、別のIPアドレス 35.198.57.29 から57秒間で216件、136.70.70.145 から約39秒間で244件のリクエストが発生しました。さらに24日にも、別のGoogle Cloud系IPアドレスから類似した探索が確認されました。
これらのアクセスでは、Googlebotを含む検索エンジンやAIクローラーの名称がUser-Agentとして使用されていました。しかし、User-Agentは送信者が任意に指定できるため、その名称だけで正規のクローラーと判断することはできません。
また、Google Cloud上のIPアドレスから送信されていることは、Google自身による調査を意味しません。クラウドサービスを利用する第三者の自動プログラムである可能性があります。
当社では、既知の機密ファイルや不要な管理用パスへのアクセスを遮断するとともに、Apacheアクセスログを継続的に解析しています。
今回の記録から分かるのは、脆弱性の有無にかかわらず、公開Webサーバーが継続的な自動探索の対象になっているということです。なお、今回確認された探索にはPHP固有ではない手法も多く、PHP脆弱性の公表を直接の契機として開始されたものとは断定できません。
攻撃者は必ずしも特殊な技術を用いる必要はありません。一般に利用できるスキャナーやHTTP通信を使い、公開されたシステムの設定不備や既知の弱点を探すことができます。
重要なのは、こうした探索が日常的に行われることを前提として、ソフトウェア更新、不要機能の非公開、アクセス制御、監視、障害時の代替運用を維持することです。
そして、探索の兆候が確認された際に、誰がアクセスログを評価し、誰が遮断を判断し、誰が必要な保守を実施するのか。その運用を継続するための人員、予算、権限を決めることが、経営者による内部統制の役割です。
なぜ、侵害の途中で止められなかったのでしょうか
公開サーバーへのスキャン、通常とは異なる認証試行、管理者権限の取得、不自然な内部通信、大量のファイルアクセス、バックアップへの操作などは、監視やアクセス制御によって発見・制限できる可能性があります。
しかし、監視の対象から外れているシステム、長期間使用されていない管理者アカウント、外部委託先に付与した特権、分離されていない管理ネットワークなどが存在すれば、防御機能が導入されていても重要な活動を把握できない場合があります。
また、異常を検知できても、その情報を誰が評価し、誰が通信の遮断やサービス停止を決定するのかが定められていなければ、対応は遅れます。監視していることと、侵害を止められることは同じではありません。
防御を設置したかどうかではなく、どの段階で何を検知し、誰の権限で何を止められるのか。 その一連の動作が機能することまでが、内部統制の対象です。
ここでも、一つ侵入されても、すべてへ届かない構造にするという設計思想が重要になります。最初の侵入を完全に防げなくても、管理権限やネットワークを分離し、被害の到達範囲を制限することは可能です。
被害発生後、調査はどこから始まるのでしょうか
一方、被害が発生した後、事業者は侵入経路、攻撃者が取得した権限、影響を受けたサーバー、情報流出の有無、バックアップの状態などを調査する必要があります。侵害が継続している場合には、封じ込めや証拠保全も並行して進めなければなりません。
これは安全な復旧や再発防止のために必要な工程です。しかし、利用者にとって重要なのは、自身の業務がいつ再開できるのか、失われた取引機会や費用はどうなるのか、どのような支援を受けられるのかという問題です。
事業者が侵入経路を特定できていなくても、利用者の受発注や配送、取引は既に停止している場合があります。事業者の調査が完了するまで、利用者の損失が発生し続けることもあります。
事業者にとっての被害実態の把握と、利用者にとっての被害実態の把握は、必ずしも同じ順序ではありません。 事業者が侵害の全容を調査している間にも、利用者の損失は具体的に発生しています。
サービスの復旧と、利用者の救済は同じではありません
アサヒグループ、アスクル、タイムズ関連サービス、GMO関連サービスなど、サイバー侵害の影響が公表された事案では、個々の被害範囲や発生原因は異なります。これらを同じ侵害構造や被害規模として評価することはできません。
しかし、共通して検討すべき問題があります。それは、事業者のサービスが復旧しても、利用者や取引先に発生した損失まで回復するとは限らないことです。
見舞金は、被害者への配慮や暫定的な支援として支払われる場合があります。一方、損害賠償では、実際の損失、原因との因果関係、契約内容、法的責任などの確認が必要になります。業務再開の支援、代替サービスの提供、費用負担、損害賠償は、それぞれ異なる役割を持ちます。
見舞金を支払うことと、損害を回復することは同じではありません。 また、サービスが復旧したことだけをもって、利用者への救済が完了したともいえません。
防御では省略された判断が、救済では必要になる
攻撃者は、取得した技術的権限の範囲で、企業の承認を受けることなく操作を実行できます。管理者アカウントが広範囲の操作を許可されていれば、その利便性は侵入者にも利用され得ます。
ところが、被害発生後の救済では、調査結果の確認、契約上の責任分界、法務審査、損害額の査定、経営者による決裁など、複数の判断が必要になります。
これらの手続き自体は、適切な責任認定のために必要です。しかし、被害を防ぐための承認や権限分離を省略していた一方で、被害者を救済する段階では厳格な承認を求めるのであれば、その非対称性は検証されるべきです。
本来、侵害を防ぐ仕組みと、被害を救済する仕組みは、危機が発生する前から設計できます。重要操作の権限分離、異常検知時の自動遮断、顧客への連絡手順、暫定的な業務代替、緊急支援のための予算と決裁権限などです。
侵害までの各段階で何を止められたのか。そして、侵害後の各段階で利用者をどれだけ早く支援できたのか。 この二つを同じ内部統制の問題として評価する必要があります。
攻撃者は特別な技術だけを使っているわけではありません
サイバー攻撃というと、攻撃者が特殊なプログラムを開発し、高度な技術でシステムを突破する姿を想像するかもしれません。しかし、実際の侵入型攻撃では、一般に利用できるツールや、システムに標準搭載された機能が悪用されることもあります。
Webサイトの公開状況を調べるスキャナー、Windowsの管理に使われるPowerShell、遠隔操作のためのRDP、組織の認証と権限を管理するActive Directory。これらは本来、正当な業務に必要な技術です。
既存の正規ツールや管理機能を悪用する手法は、Living off the Land（LOTL）と呼ばれています。攻撃者は新しい道具を持ち込まなくても、取得した権限によって、既に存在する機能を不正な目的に利用できる場合があります。
当社のApacheアクセスログにも、通常の閲覧とは異なるURLへの連続したアクセスや、管理画面、設定ファイル、既知の脆弱性を探すようなリクエストが記録されます。こうしたアクセスは、公開Webサイトに対する調査や探索が日常的に行われていることを示しています。ただし、アクセスログだけで攻撃者の特定や侵入の成功を判断できるわけではありません。
攻撃に使われる技術が特殊なのではなく、日常業務に必要な技術が、権限を取得した第三者にも利用できることが問題なのです。
だからこそ、セキュリティ対策を不正プログラムの検出だけに依存することはできません。正規の管理機能であっても、誰が、どの端末から、どの範囲に対して操作できるのかを制限し、その操作が正当なものかを確認する必要があります。
管理者にとって便利な機能は、管理者の権限を奪った侵入者にとっても便利です。権限分離や追加承認という不便をどこに残すかは、攻撃者が一度の侵入で到達できる範囲を左右します。
攻守の非対称性は、現代戦争にも現れています
この攻撃と防御の非対称性は、サイバー空間だけの問題ではありません。ウクライナ戦争では、比較的安価なドローンを大量に投入する攻撃に対して、高価な迎撃装備や継続的な警戒を必要とする構造が明らかになっています。攻撃側は対象を選び、時期や方法を変えながら攻撃できます。一方、防御側は多数の対象を継続的に守らなければなりません。
企業の情報システムでも同様です。攻撃者は公開された多数のシステムを調査し、侵入できる経路を探します。一方、管理者は日常業務を継続しながら、稼働するシステムや認証情報、管理権限を守る必要があります。
重要なのは、防御側が攻撃側と同じ費用や手間をかけて対抗することではありません。管理権限と情報資産を分離し、一つの侵害が全体へ波及しない構造を設計することです。
一度の侵入で全体を失わないこと。侵入者が次の領域へ進むたびに、新たな手間と制約に直面すること。その構造を平時から備えることが、防御側の非対称性を緩和します。
では、10月21日から何をすべきだったのでしょうか
2026年10月21日のPHP重大脆弱性の事前予告から、本稿公開日の25日まで、企業は何をすべきで、何をしないことが正しい判断だったのでしょうか。そして、これから何をすればよいのでしょうか。
21日に必要だったのは、PHPを利用するシステムの把握、外部公開範囲の確認、更新方法と停止条件の確認です。脆弱性の詳細が公表されていない段階で、安全とも危険とも一律に判断するのではなく、必要な対応を実施できるよう準備することが求められました。
修正版が公開された後は、影響を受ける環境を特定し、修正プログラムを適用することが基本です。直ちに更新できない場合には、アクセス制限などの暫定対策を講じ、それでも危険を十分に抑えられなければ、外部公開の遮断や一時停止を判断する必要があります。
一方、避けるべきだったのは、影響を確認せずにすべてのサービスを停止すること、更新せずに安全を宣言すること、そして修正プログラムを適用しただけで侵害の可能性まで否定することです。
当社のApacheログでは、この期間も継続的な自動探索が記録されています。ただし、探索があったことは侵入の成功を意味しません。スキャン件数の増減だけで安全性を判断せず、アクセス制御、ソフトウェアの状態、認証やシステムの記録を合わせて確認する必要があります。
10月25日、何をもって対応完了とするのでしょうか
Webサイトが表示され、サービスが再開したことだけでは、対応完了とはいえません。少なくとも、影響を受けるシステムの特定、必要な修正、動作確認、侵害の兆候に関する調査、未対応事項の記録が必要です。
また、調査によって侵害の証拠が確認されなかった場合も、侵害が絶対に存在しなかったことの証明にはなりません。確認した記録の範囲と、確認できなかった範囲を明確にすることが重要です。
さらに、今回の対応で停止したサービスや、更新できなかったシステムについては、なぜ停止や更新延期が必要になったのかを検証しなければなりません。技術的な問題だけでなく、管理対象の把握、保守契約、検証環境、決裁権限、代替運用に不足がなかったかを確認する必要があります。
次の脆弱性に、同じ対応を繰り返さないために
今後も、PHPに限らず、Webサーバー、JavaScriptの実行環境、通信ライブラリ、認証基盤などで、新しい脆弱性が公表されます。そのたびに管理対象を探し、担当者を集め、停止の可否を議論するのであれば、今回の経験は次の危機に引き継がれていません。
必要なのは、管理対象を常に把握できること、更新と切り戻しを試験できること、影響範囲を限定できること、そして危険が確認された際に、あらかじめ定めた権限で遮断や代替運用を開始できることです。
今回、停止したか、停止しなかったかが最終的な評価基準ではありません。なぜその判断を行い、どの根拠で安全を確認し、次に同じ状況が発生したとき、より少ない被害と停止で対応できるようになったのか。それが経営者に問われることです。
参考： IPA・2026年10月21日の事前注意喚起 ／ IPA・2026年10月22日の脆弱性対策情報
不便益はどこに配置すべきだったのか
問題はシステムの機能だけではなく、それを使う人が何を許可し、何を止められるかという判断です。すべての作業に承認を増やすことが安全性ではありません。通常の操作は迅速化し、顧客横断の権限付与、特権変更、更新延期といった重大な判断には独立した確認を設けます。異常検知時の遮断は、あらかじめ定めた権限で即時に実行できるようにします。コンテナやCI/CDは更新・検証・切り戻しの不便を平時の仕組みに組み込む手段です。また、特権の取得・使用・失効には明確な規則と記録、必要時の独立承認を設けます。
自律・分散・非同期という設計思想は、侵害の到達範囲を制限し、停止後に復旧できる構造を考えることでもあります。管理者の不便が侵入者の手間となるよう、必要な障壁を残します。情報セキュリティは技術で実装されますが、どの危険を許容するかは経営が決めます。
内部統制とは、事故の後で責任を確認するだけでなく、事故の前に必要な不便を配置する仕組みでもあります。
参考資料・出典
本稿では、企業が公表した情報セキュリティ方針と事故調査報告、 ソフトウェア開発元の保守情報、行政・公的機関の資料などを参照しています。 技術上の仕組みと実際の事故で確認された事実を区別し、 内部統制のあり方を考えるための資料です。
情報セキュリティと企業の内部統制
- アスクル株式会社「情報セキュリティへの取り組み」 ISO/IEC 27001に基づく管理体制、CISOの役割、 アクセス管理、24時間監視、継続的改善など、 同社が公表している情報セキュリティ方針を確認できます。
- アスクル株式会社「ランサムウェア攻撃の影響調査結果および 安全性強化に向けた取り組みのご報告」 （2025年12月12日） 侵入経路の調査、委託先管理者アカウントの多要素認証、 EDRや監視体制、バックアップと復旧について、 事故後に判明した事実と再発防止策を公表した資料です。
ソフトウェアの更新と保守
- PHP公式「Supported Versions」 PHPの各バージョンに設けられた保守期間と、 セキュリティ更新の提供方針を示す公式資料です。 継続的な更新が通常の運用管理に含まれることを確認できます。
- Node.js公式「Previous Releases」 Node.jsのリリース系列、長期サポート（LTS）、 サポート終了（EOL）などの情報です。 システムの保守計画と更新時期を検討するための資料です。
リモートアクセスと権限管理
- Microsoft Learn「RemoteDesktopServices Policy CSP」 Windowsのリモートデスクトップサービスに関する管理ポリシーです。 ドライブリダイレクトなどの機能を制限できることを確認できます。 RDPの利便性と接続元PCへのアクセス経路を考える際の技術資料です。
サイバーセキュリティの開示と日米の対応
- 米国証券取引委員会（SEC） 「Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure」 （2023年7月26日） 対象となる上場企業に対し、重大なサイバーインシデント、 リスク管理、経営上の監督体制などについて 開示を求める規則の公表資料です。
- 日本経済新聞 「PHP欠陥でサイト止めた日本、止めなかった米国 脆弱性は8月に発見」 （2026年10月） PHPの重大な脆弱性への対応について、 日本での予防的なサイト停止と、 米国の大手IT事業者によるサービス継続を比較した報道です。 対応前の準備や情報共有の違いを検討する際に参照しています。