「PHPに深刻な脆弱性」というニュースを見たとき、自社で使っているか、誰へ確認すればよいか分かるでしょうか。会社のWebサイトを外注していても、その中で動くソフトウェアの名前まで日常的に意識する機会は多くありません。
今回は、機器の把握、管理ルール、その遵守状況の点検を扱います。脆弱性とは、攻撃に悪用されるおそれがある弱点のことです。利用しているものが分かれば、注意喚起を自社の確認作業へつなげやすくなります。
図1 PHPを利用する構成の一例 すべてのCMSがPHPを使うわけではない
| 評価基準番号 | この回で行うこと |
| 3-1-1-1 | PC・シンクライアントの製造元、OS、台数の把握 |
| 3-1-1-2 | サーバ・仮想サーバ・ハイパーバイザの製造元、OS、台数の把握 |
| 3-1-1-3 | 導入・設置・接続・パッチ適用を含む管理ルールの策定 |
| 3-1-1-4 | 管理ルールの遵守状況を年1回以上点検 |
PHPの注意喚起と財務省の停止と再開
2026年10月22日、IPAはPHPの脆弱性「PHP2shell」の対策情報を公開しました。対象はCVE-2026-109618とCVE-2026-109619です。CVE番号は、個々の脆弱性を区別するための番号です。IPAは、PHPを利用する製品やサービスについて、開発者・提供元の情報を確認するよう案内しています。
図2 財務省の公式発表に基づく経過 安全対策のための停止と再開
財務省は10月21日、管理下のWebサーバ等の緊急点検と修正プログラムの適用に伴い、一部コンテンツやサービスを一時停止したと公表しました。22日には対策と安全性の確認を経て順次再開し、26日には機能面の調整も完了して、すべてのコンテンツを再開したと発表しています。
これは、安全対策のための停止・再開の事例です。攻撃被害の発生を公表したものとして扱うことはできません。また、10月29日に確認したIPAの10月27日更新情報では、国内の攻撃被害事例は把握していないとされています。
この事例から自社の備えを考えると、どのシステムに何を使い、誰へ問い合わせればよいかを把握しておく意味が見えてきます。台帳だけで弱点が直るわけではありませんが、対象を探すための手掛かりになります。財務省の資産管理が不足していたと推測するものでもありません。
3-1-1-1 パソコンの製造元とOSと台数を把握する
一つ目の基準は、パソコンとシンクライアントについて、製造元、OS、台数を把握する仕組みを整えることです。適合基準では、その仕組みによって実際に把握していることも確認します。空の台帳を作るだけでは完了しません。
OSは、Windowsなど、機器を動かす基本ソフトウェアです。シンクライアントは、主な処理をサーバ側で行い、手元の端末の機能を絞って使う仕組みや端末を指します。一般的なパソコンとは別の構成でも、対象を確認します。
| 管理する情報 | 架空の1台分の記入例 |
| 製造元 | A社 |
| OS | Windows 11 |
| 台数 | 1台 |
| 管理番号 | PC-001 |
| 種類と用途 | ノートPC／営業資料の作成 |
| 使用者と管理者 | 使用者［氏名］／管理担当［氏名・連絡先］ |
| OSの版と確認日 | 設定画面で確認した版［値］／確認日［年月日］ |
| 利用場所と所有形態 | 在宅勤務を含む／会社支給 |
最初の三行が、この基準で明記された把握項目です。それ以降は、機器の識別や影響確認のための追加例です。一台ごとに管理番号を付ける方法なら、同じ機器の二重登録を避け、台数を集計しやすくなります。既存の管理ツールで把握できる場合は、その情報を使えます。
私物の業務用パソコンも確認する
役員や従業員が私物の端末を業務に使うBYODでも、業務利用する端末は適用範囲に含めます。例えば、私物PCで顧客資料を編集している場合に、会社が買ったパソコンではないという理由で把握から外さないようにします。
業務に必要な端末情報をどのように申告・確認するかを決め、私的なファイルの内容まで集めない方法を検討します。在宅勤務や端末の所有形態に応じた適用範囲の詳細は、第2回も参照してください。
利用者の記憶と実機の情報を照合する
「たしかWindowsだった」という申告だけで終わらせず、端末の設定画面や管理ツールの情報を使って確認します。入替え時は旧端末と新端末を区別し、予備機なども実際の管理・利用状況に合わせて整理します。
3-1-1-2 サーバと仮想の構成を把握する
二つ目の基準は、サーバ、仮想サーバ、ハイパーバイザの製造元、OS、台数を把握する仕組みと、実際の把握です。サーバは他の機器へサービスを提供するコンピュータです。仮想サーバは、ソフトウェアで作ったサーバ環境を指します。
図3 物理サーバと仮想サーバの架空例 稼働構成は製品によって異なる
ハイパーバイザは、コンピュータを仮想化するためのソフトウェアです。図3では、物理サーバが1台でも、仮想サーバは2台動いています。機器の箱の数だけを数えると、仮想環境の存在や管理対象を見落とします。
管理番号等で物理機器、仮想サーバ、ハイパーバイザを結び付け、それぞれの製造元、OS、台数が分かるようにします。製品や構成によって記録方法は異なるため、管理画面や保守資料から確認し、外注している場合は保守会社へ説明を求めます。
対象外条件はサーバの基準に限って確認する
3-1-1-2の対象外条件は、公式ガイドで「自社オンプレミスサーバを開発、保有していない場合」とされています。この条件を、パソコンの把握や管理ルール、遵守状況の点検まで不要になる条件と読み替えないようにします。
クラウドを使う場合も、利用者である自社が管理する部分と、提供事業者が管理する部分を整理します。例えば、自社でOS等を管理する仮想環境と、完成した業務サービスを利用する形では、確認できる情報や行う作業が異なります。
適用範囲と個別の対象外条件を照らし合わせて判断し、必要に応じて★3確認責任者へ説明できる資料を用意します。「クラウドだからすべて対象外」とまとめず、外部情報サービスの管理は11月11日の3-1-3にもつなげて確認します。
製品名と版と問い合わせ先を結び付ける
機器の基本情報が集まったら、脆弱性の影響確認に使える情報を追加すると実務に役立ちます。公式解説書も、ソフトウェア名やバージョン、設置場所、使用者、管理者、サポート窓口等を、基準の明記項目以外も含めた管理例として示しています。
図4 資産の情報を影響確認に使う手順例 記録だけで対策完了とはしない
Webサイトの名前だけでは分からないこと
記事やページを管理する仕組みはCMSと呼ばれます。PHPで動くCMSを使っているなら、CMSの製品名と版に加え、PHPの版、利用しているサーバやサービス、保守先を関連付けておくと確認を始めやすくなります。図1はそのような構成の一例です。
例えば「会社紹介サイト／CMS［製品・版］／PHP［確認した版］／保守先［会社・窓口］／確認日［年月日］」と記録します。PHPが含まれる製品やサービスでは、版の番号だけで結論を出さず、提供元が公表する影響条件や対応状況も確認します。
外注している場合の問い合わせ例
「当社サイトで使用しているPHPの有無とバージョン、今回の注意喚起への該当状況を確認してください。対象の場合は、対応方法と予定、当社側で必要な作業を教えてください」と依頼します。これは問い合わせの文例です。
不明なものは調査中として、確認先と期限を残します。返答がない段階で「影響なし」にしないことが大切です。同じ考え方は、ブラウザ、文書作成ソフト、サーバ製品等の注意喚起にも使えます。具体的な更新手続は11月23日の4-4-4で扱います。
3-1-1-3 導入から更新までの管理ルールを定める
三つ目の基準は、情報機器、OS、ソフトウェアの管理ルールです。導入、設置、ネットワーク接続、セキュリティパッチ適用の四つを含めます。セキュリティパッチとは、弱点を修正するために提供される修正プログラムです。
| 必ず含める内容 | 社内ルールとして具体化する例 |
| 導入 | 誰が申請・確認し、利用を認めるか。導入時に必要情報を登録する |
| 設置 | 設置・利用する場所と管理担当を定め、変更時の連絡方法を決める |
| ネットワーク接続 | 社内や業務用の接続先へつなぐ前に、誰が条件を確認するかを決める |
| パッチ適用 | 更新情報の確認、適用の判断・実施、結果の確認、適用できない場合の対応を決める |
左欄が基準で求められる内容、右欄が実務上の具体例です。承認の方法や担当者の人数は、自社の規模や利用形態に合わせて設計します。公式用語の「定める」は、文書化し、その内容に基づいて運用する意味です。
導入時に更新を続けられるか確認する
公式解説書は、提供元の信頼性、サポート方針や期限を導入時に考慮する例を示しています。安く導入できても、修正が提供されるか、誰が更新するか分からないままでは、後の対応に困ります。選ぶ段階で保守の条件を確認します。
機器の設置と接続を別々に確認する
「パソコンを購入してよい」という承認だけで、どこで使い、どの接続先を利用してよいかまで決まるとは限りません。例えば、在宅勤務での利用場所、社内システムへの接続方法、利用を始める前の確認担当を、業務に沿って決めます。
更新できないときの相談先も決める
更新すると業務アプリが動かなくなるおそれがある場合や、保守会社の作業が必要な場合は、そのまま止めず、誰へ相談して対応を決めるかをルールにします。必要に応じた利用制限や代替方法を検討し、判断と実施結果を残せるようにします。
この回では管理ルールに必要な内容を確認します。一律の更新期限をここで追加するものではありません。更新の条件や具体的な手続は、関連する4-4-4等の基準と合わせて整理します。
3-1-1-4 管理ルールが守られているか点検する
四つ目の基準は、3-1-1-3で定めた管理ルールの遵守状況を、年1回以上点検することです。自己評価では、従業員へのチェックシート等、点検を実施した記録を確認します。
図5 年1回以上の遵守状況点検 不備への対応方法や記録欄は実務例
| 点検するルール | 遵守状況を確かめる例 |
| 導入 | 新しく使い始めた機器やソフトについて、決めた確認・申請が行われているか |
| 設置 | 許可した場所で利用され、変更時の連絡が行われているか |
| ネットワーク接続 | 決めた接続条件を満たして利用されているか |
| パッチ適用 | 更新の実施や結果確認、適用できない場合の報告が行われているか |
台帳に書かれた台数が正しいかを確かめる作業と、管理ルールを守っているかを確かめる作業では、見る内容が異なります。台帳の確認日だけを更新しても、四つの管理ルールの遵守状況を点検したことにはなりません。
点検結果の記録例
実施日［年月日］／対象［部門・機器・利用者等］／確認したルール［文書名・版］／方法［申請記録・設定画面・利用者確認等］／結果［適合・不備と内容］／対応［担当・期限・完了確認］。
例えば「更新を適用できない端末の報告が1件未実施」と分かれば、報告漏れへの対応を記録します。確認していない項目を一括で「問題なし」にせず、対象と方法が説明できる記録にしましょう。
自己評価に使う資料をそろえる
今回の四基準は、把握の仕組み、実際の機器情報、管理ルール、遵守状況の点検記録をつなげて確認します。有料の特定ツールを買うこと自体が条件ではなく、台帳や既存の管理機能など、自社で続けられる方法を選びます。
| 評価基準番号 | 公式ガイドに沿って確認するもの |
| 3-1-1-1 | PC・シンクライアントの製造元、OS、台数を把握する仕組みと実際の情報 |
| 3-1-1-2 | サーバ・仮想サーバ・ハイパーバイザの製造元、OS、台数を把握する仕組みと実際の情報 |
| 3-1-1-3 | 四つの内容を含む管理ルールと、その文書名 |
| 3-1-1-4 | 管理ルールの遵守状況を年1回以上点検した記録 |
対象外条件を他の番号へ広げない
3-1-1-1、3-1-1-3、3-1-1-4には、公式ガイド上、対象外となる条件はありません。3-1-1-2には前述のサーバに関する条件があります。判断は番号ごとに行い、クラウド中心の会社でも、業務で使うPCやソフトの管理を確認します。
台帳と点検記録を仕事につなげる
機器を導入・入替えしたときに利用情報を更新する運用にすると、注意喚起が出た際に探す対象を絞りやすくなります。誰が台帳を直し、不明点を誰へ問い合わせるかも決めておきます。これは把握を維持するための実務上の工夫です。
本日の五つの確認
□ PC・シンクライアントの製造元、OS、台数を把握した。
□ サーバ等の必要情報を把握し、対象外の場合は条件を確認した。
□ 導入・設置・接続・パッチ適用を含む管理ルールを定めた。
□ 管理ルールの遵守状況を年1回以上点検し、記録している。
□ 製品や版が不明な場合の確認先を、業務に結び付けた。
最後の確認は実務上の追加です。今日は、自社のWebサイトか業務PCを一つ選び、使っている製品と版、管理担当を実際の資料から確認してみてください。
次回は ネットワークと機器の把握
11月10日は、3-1-2「ネットワークに関する情報の把握」です。ネットワークの所在地と用途、機器の製造元やモデル、保守先を確認する方法を扱います。
連載の関連項目とご相談
第1回は連載目次、第2回は適用範囲、第8回は事故時の共有先との分担です。更新手続は11月23日の4-4-4で扱います。
ライトハウスコンサルタントでは、★3を見据えた現状確認や、規程・台帳・記録の準備を支援しています。利用している機器やソフトの情報と、実際の管理方法を整理します。
