Webサーバーのセキュリティ対策は、新しい製品を足す作業ではありません。公開したまま放置された経路を1つずつ塞ぎ、それが塞がったままであることを確認し続ける運用です。IPAが2026年1月29日に公表した「情報セキュリティ10大脅威 2026」でも、組織向けの4位に「システムの脆弱性を悪用した攻撃」が入り、6年連続9回目の選出となりました。攻撃側は新しい手口を探すより、更新されていないサーバーを探しています。
この記事では、設計や実装ではなく「動いているサーバーを守り続ける」運用フェーズに範囲を絞ります。抜けを洗い出す基準、適用対象の把握と検証の切り分け、増え続ける脆弱性のどれから直すかの判断、直せない期間の抑え方、そして対策が実際に効いているかの確認方法までを順に扱う構成です。設計段階から作り込む観点はWebサイトのセキュリティ構築の記事、実装コード側の観点はセキュアコーディングの10原則の記事で扱っています。
まとめ
- 抜けの洗い出しはIPA「安全なウェブサイトの運用管理に向けての20ヶ条」を土台にします。運用フェーズの守備範囲は、ウェブサーバの6項目（第9〜14条）とネットワークの4項目（第15〜18条）です。
- 公開される脆弱性を全部同じ速さで直すことはできません。米国CISAが2026年6月10日付で発出したBOD 26-04では、公開状況・KEV収載・攻撃の自動化可否・技術的影響という4変数から緊急度を決めます。
- CVSSスコアの高い順に並べるだけの運用は、根拠として弱くなっています。同じBOD 26-04がBOD 19-02を失効させ、連邦民間機関に対するCVSS利用の要件そのものが外れました。
- すぐ適用できない期間はWAFやIPSでの緩和が現実解ですが、恒久対策ではありません。緩和を入れた時点で適用期限を切ります。
- バージョン情報の隠蔽は対策になりません。Apache公式ドキュメントが「security through obscurity は神話であり、誤った安心感につながる」と明記しています。
- ランサム被害を前提にするなら、バックアップの復元テストまでを運用に含めます。20ヶ条はログの取得と確認までしか問うていません。
Webサーバーが実際に破られる経路
対策を決める前に、何が起きているかを数字で押さえます。IPA「情報セキュリティ10大脅威 2026」の組織向け上位は次のとおりです。
| 順位 | 脅威 | 選出 |
|---|---|---|
| 1位 | ランサム攻撃による被害 | 11年連続11回目 |
| 2位 | サプライチェーンや委託先を狙った攻撃 | 8年連続8回目 |
| 3位 | AIの利用をめぐるサイバーリスク | 初選出 |
| 4位 | システムの脆弱性を悪用した攻撃 | 6年連続9回目 |
| 5位 | 機密情報を狙った標的型攻撃 | 11年連続11回目 |
Webサーバーの運用担当が直接手を下せるのは4位です。ここで、1位のランサム攻撃の侵入口を実測データで確認しておく価値があります。警察庁「令和７年におけるサイバー空間をめぐる脅威の情勢等について」の統計データでは、感染経路が判明した92件の内訳はVPN機器61件、リモートデスクトップ19件、不審メールやその添付ファイル2件、その他10件でした。侵入口の8割強はインターネットに公開された接続機器であり、公開Webサーバーだけを固めても足りません。
同じ統計にはもう1つ、パッチ運用の限界を示す数字があります。侵入経路とされる機器のセキュリティパッチ適用状況が判明した71件のうち、最新のパッチを適用済みだったものが31件、未適用のパッチが残っていたものが40件でした。つまり侵入された機器の4割強は、パッチを当てていたにもかかわらず破られています。パッチ適用は必要条件であって十分条件ではなく、後述するアカウント管理とパスワード（第11条・第12条）が同じ重みで効いてくる理由がここにあります。
破られた結果として運用側で扱いが分かれるのは、コンテンツの改ざん、情報漏えい、そして自社サーバーが他社への攻撃の踏み台にされる加害側への転落です。とくに3つめは自社の被害額に現れないため、自組織の監視では検知されず外部からの連絡で発覚するケースがあります。ログの保管と定期確認が防御そのものと同じ重みを持つ理由が、ここにあります。
IPA20ヶ条で洗うサーバー運用の10項目
IPAは「安全なウェブサイトの運用管理に向けての20ヶ条 〜セキュリティ対策のチェックポイント〜」で、確認項目を20個の質問形式にまとめています。ウェブアプリケーション8項目、ウェブサーバ6項目、ネットワーク4項目、その他2項目の4分類です。IPAのページでは各項目が「（1）」から「（20）」と番号で並んでおり、本記事ではこれを第1条から第20条と表記します。このうち運用フェーズで担当するのが、ウェブサーバとネットワークの計10項目です。
ウェブサーバの6項目（第9〜14条）
- 第9条 OSやサーバソフトウェア、ミドルウェアをバージョンアップしていますか？
- 第10条 不要なサービスやアプリケーションがありませんか？
- 第11条 不要なアカウントが登録されていませんか？
- 第12条 推測されやすい単純なパスワードを使用していませんか？
- 第13条 ファイル、ディレクトリへの適切なアクセス制御をしていますか？
- 第14条 ウェブサーバのログを保管し、定期的に確認していますか？
第11条についてIPAは、開発工程やテスト環境で使用したアカウントが残っているケースを名指しで挙げています。前節の警察庁データが示すとおり、パッチを当てていても破られる機器が4割強ある以上、この項目は「余力があれば」の位置づけにはできません。第14条が例として挙げるログは、システムログ・アプリケーションログ・アクセスログ・データベース操作ログなどで、原文は「など」と書いており列挙は閉じていません。取得するだけでなく定期的に確認することまでが条件になっています。
ネットワークの4項目（第15〜18条）
- 第15条 ルータなどを使用してネットワークの境界で不要な通信を遮断していますか？
- 第16条 ファイアウォールを使用して、適切に通信をフィルタリングしていますか？
- 第17条 ウェブサーバ（または、ウェブアプリケーション）への不正な通信を検知または、遮断していますか？
- 第18条 ネットワーク機器のログを保管し、定期的に確認していますか？
第15条は外部から内部への通信だけを見る条文ではありません。IPAは内部から内部、内部から外部の通信についても不要と判断されるものは遮断する必要があると書いています。侵入後の横展開と外部への持ち出しを想定した書き方で、境界ルータの設定を外向きだけ確認して終える運用は、第15条を満たしていません。
20ヶ条を2019年版のまま使う場合の補い方
この20ヶ条は最終更新日が2019年3月6日です。骨格としては今も有効ですが、2026年の脅威像との差は正直に埋める必要があります。10大脅威2026の2位はサプライチェーンや委託先を狙った攻撃であるのに対し、20ヶ条でサプライチェーンに触れるのは第19条のクラウドサービス利用時の責任範囲の把握にとどまります。
ここはOWASP Top 10:2025で補うのが妥当です。2025年版では Security Misconfiguration が2021年版の5位からA02へ繰り上がり、Software Supply Chain Failures がA03に入りました。OWASPはA03を「A06:2021-Vulnerable and Outdated Componentsの拡張」と説明しており、依存パッケージのバージョン管理はそのままこのカテゴリへ引き継がれています。20ヶ条のチェックを一巡したあとに「使っている外部パッケージとその供給元を把握しているか」「設定のデフォルト値を本番のまま使っていないか」の2問を足すだけでも、2019年版との差はかなり埋まります。
セキュリティパッチ適用の前提｜対象資産の把握と検証範囲の切り分け
第9条のバージョンアップは、20ヶ条の中で最も頻度が高く、最も後回しにされる項目です。IPA自身がこの条文に「ソフトウェアをバージョンアップした場合、今まで動作していたウェブアプリケーションが正常に動作しなくなる場合があるため、事前の検証の必要がある」という注記を付けています。つまり検証工数が確保できていない組織では、この条文は構造的に守られません。
適用対象の棚卸し｜マイナーバージョンまで記録する粒度
何が動いているかを把握していないサーバーには、パッチを当てる判断ができません。OSとWebサーバーソフトウェアだけでなく、言語ランタイム、フレームワーク、CMS、そしてそれらが引く外部パッケージまでが対象です。IPAも第4条で、自組織のウェブサイトがどのようなソフトウェアで作られているかを把握したうえで脆弱性対策をとる必要がある、と順序を明示しています。
記録の粒度は、バージョン番号まで残すことが最低ラインになります。「Node.jsを使っている」では判断できず、「Node.js 22.x系のどのマイナーか」まで無いと、公開された脆弱性が自社に該当するかを機械的に照合できません。実際の照合手順はNode.jsの脆弱性と対応バージョンの確認手順をまとめた記事が具体例になります。
検証対象の絞り込み｜アプリから直接呼ばれるかで分ける
検証環境を本番と同じ構成で常時維持できる組織は多くありません。現実的には、影響範囲の広いミドルウェア更新だけを検証対象に絞り、それ以外は適用後の監視で拾う二段構えになります。判断の分かれ目は、更新対象がアプリケーションから直接呼ばれるかどうかです。言語ランタイムやデータベースクライアントの更新は挙動が変わりやすいため検証必須、OSのカーネルやライブラリの更新は検証を薄くして適用を優先する。この切り分けなら、検証工数を増やさずに適用速度を上げられます。
パッチ適用の優先順位づけ｜CVSS単独運用からの切り替え
公開される脆弱性の件数に対して、検証と適用にかけられる工数は常に不足します。したがって実務上の問題は「パッチを当てるべきか」ではなく「どれを今日当て、どれを来月に回すか」になります。
CVSSスコア順に並べる運用の限界
長らく標準とされてきたのが、CVSS基本値の高い順に潰す運用です。CISA自身、BOD 19-02「Vulnerability Remediation Requirements for Internet-Accessible Systems」（2019年4月29日）で、インターネットに公開された資産のcritical/high脆弱性に修正期限を課していました。この前提は崩れています。CISAは2026年のBOD 26-04でBOD 19-02を失効させ、実装ガイダンスに「BOD 19-02の失効により、連邦民間行政機関は脆弱性の優先順位づけにCVSSを使用することを要求されなくなった」と明記しました。
理由は単純で、CVSSは「もし悪用されたらどれだけ深刻か」を測る指標であり、「実際に悪用されるか」を測る指標ではないためです。スコア9.8でも攻撃コードが存在しない脆弱性と、スコア7.5でも今まさに自動化された攻撃が飛んできている脆弱性なら、後者から塞ぐほうが実害を減らせます。CVSSを捨てる必要はありませんが、単独の優先順位づけの軸として使うのはやめる、というのが妥当な判断でしょう。
KEVカタログとEPSSの役割分担
CVSSの穴を埋めるのが、悪用の実態を扱う2つのデータです。
| 指標 | 提供元 | 測っているもの | 形式 |
|---|---|---|---|
| CVSS | FIRST | 悪用された場合の深刻度 | 0.0〜10.0のスコア |
| KEVカタログ | CISA | 悪用が確認された事実 | 収載か非収載かの二値 |
| EPSS | FIRST | 今後30日以内に悪用される確率 | 0〜1の確率とパーセンタイル |
KEVカタログは、実際に悪用が確認された脆弱性を収載する一覧です。CISAは新たな該当脆弱性を24時間以内にカタログへ反映することを目標としています。ただし追加調査や証拠不足、緩和策が未提供、CVE未採番といった要因で遅れることがある、とも書かれています。KEVに載るのを待ってから動く運用は、その分だけ取りこぼしを生みます。
運用上の注意点がもう2つあり、いずれもCISA自身がFAQで明示しています。ひとつは、公開された実証コード（POC）の存在が収載の要件ではないことです。もうひとつは、古いCVEが追加されたとしても、それが現在進行形で悪用されていることを必ずしも意味しないことです。KEV収載を「今すぐ攻撃されている」と一律に読むと、過剰な緊急対応で工数を失います。
EPSSは、公開済みCVEが今後30日以内に実環境で悪用される確率を推定するモデルで、全CVEに対して0〜1の確率とパーセンタイルを毎日公開しています。KEVが「すでに起きた事実」を扱うのに対し、EPSSは「これから起きる見込み」を扱います。したがって両者は代替関係ではありません。KEV収載は無条件で最優先、KEV非収載のものはEPSSの高い順に並べる、という二段構えが役割分担として自然でしょう。
BOD 26-04の4変数の民間転用｜Asset Exposureで公開資産を分ける
CISAは2026年6月10日、BOD 19-02とBOD 22-01の両方を同時に失効させたうえで、BOD 26-04「Prioritizing Security Updates Based on Risk」を発出しました。この指令は修正の緊急度を、次の4つの変数から決めます。
- Asset Exposure（その資産がインターネットから到達可能か）
- KEV Status（そのCVE IDがKEVカタログに収載されているか）
- Exploit Automation（攻撃に必要な全手順を自動化できるか）
- Technical Impact（悪用後に攻撃者が資産の一部を掌握するか、全体を掌握するか）
この4変数はSSVC（Stakeholder-Specific Vulnerability Categorization）に基づいています。民間企業がそのまま従う義務はありませんが、判断軸としてはそのまま流用が効きます。とくに1つめのAsset Exposureは、社内の資産台帳が整っていなくても外部スキャンで機械的に判定できるため、最初に導入しやすい変数です。同じ脆弱性でも、インターネットに公開されたWebサーバー上のものと社内からしか到達できないサーバー上のものでは、当てる順番を分けて構いません。この切り分けを持たない組織では、公開資産の緊急パッチが内部資産の中優先パッチに埋もれます。
もうひとつ運用に効くのが、CISAが実装ガイダンスで示した期限の読み方です。BODの期限は「修正が適用されるまでの最大の猶予」であり、そのリスクに対する許容度を表すもので、許容度がより低い機関は期限を短く設定してよい、と説明されています。社内SLAを作るときも、この「上限であって目標値ではない」という定義をそのまま採用するのが安全です。
すぐに当てられないときの緩和策
ベンダーの修正が出ていない、あるいは出ていても業務影響で当日適用できない、という状況は必ず発生します。IPAは第17条の解説で、ウェブアプリケーションを速やかに修正できない場合に、修正されるまでの間の影響を低減する対策として、IDSやIPSおよびWAFの導入は有効な手段の一つである、と位置づけています。
注意したいのは「有効な手段の一つ」「修正されるまでの間」という限定です。WAFは修正の代替ではありません。実務で起きやすいのは次のパターンです。緊急でWAFのシグネチャを入れて攻撃を止め、対応チケットを閉じ、恒久対策の適用予定日を誰も決めないまま数か月が経過します。そしてWAFのルール更新やチューニングで例外を1つ入れた瞬間に、塞いだはずの経路が開きます。
緩和策を入れるなら、同じチケットの中に恒久対策の適用期限を書き込み、緩和策の解除条件までを一緒に決めてください。緩和と恒久対策をセットで設計した具体例としては、CVE-2026-31431の影響範囲とパッチ・緩和策を整理した記事が参考になります。緩和策の選択肢はWAFだけではなく、該当機能の一時停止、管理画面のアクセス元IP制限、該当ポートの閉塞も含みます。攻撃経路そのものを消せるなら、そちらのほうが確実です。
外形確認とバージョン露出の扱い
設定したつもりと、実際に効いていることは別です。運用フェーズの対策は、外から見た状態を定期的に確認するところまでが1セットになります。
Serverヘッダ設定の効果と限界
Webサーバーのセキュリティ対策として広く紹介されているのが、Serverレスポンスヘッダからバージョン情報を隠す設定です。Apache HTTP Serverでは ServerTokens ディレクティブが該当し、公式ドキュメントによると構文は ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full、既定値は ServerTokens Full です。Prod を指定すると、送出されるヘッダは Server: Apache だけになります。nginxでは server_tokens が対応し、構文は on|off|build|string、既定値は server_tokens on です。
# Apache httpd.conf（既定は ServerTokens Full）
# ただし Prod は Apache公式が非推奨とする「minimal未満」に該当する
ServerTokens Prod
ServerSignature Off # 既定値と同じ（Apache公式 Default: ServerSignature Off）
# nginx nginx.conf（既定は server_tokens on）
http {
server_tokens off;
}この設定をセキュリティ対策として数えるべきではありません。Apacheの公式ドキュメントは同じServerTokensの解説の中で、Serverヘッダを無効化することはサーバーの安全性向上には何の効果もなく、「security through obscurity（隠蔽による安全）」という考え方は神話であり、誤った安心感につながる、と明記しています。加えて、minimalより情報を減らす設定は相互運用上の問題のデバッグを難しくするため推奨しない、とも書かれています。上のサンプルにあるProdは、この「minimal未満」に当たります。公式ドキュメントに沿うなら、隠すとしてもServerTokens Minimalまでにとどめるのが筋です。
よく併記されるServerSignature Offに至っては、Apache公式ドキュメントが既定値をServerSignature Offと定めており、書いても状態は変わりません。対策一覧に並ぶ「隠蔽」項目の実態は、この程度の重みです。設定すること自体は害が小さいので入れて構いませんが、バージョンを隠す工数があるなら、そのバージョンを上げてください。
設定が生きているかの外部確認
確認は外から実際に叩いて行います。ヘッダの実出力と、通信が暗号化されているか（第7条）は、リリースのたびに機械的に確認できます。
# レスポンスヘッダの実出力を確認する
curl -sI https://example.com/ | grep -iE 'server|strict-transport-security'
# HTTPでのアクセスがHTTPSへ転送されるか確認する
curl -sI http://example.com/ | grep -iE 'HTTP/|location'この2本をリリース手順やcronに組み込んでおくと、設定ファイルの巻き戻りやリバースプロキシの入れ替えで暗号化やヘッダが外れたときに気づけます。設定ファイルをレビューするだけでは、途中の経路で書き換わるケースを検出できません。
外形的な確認で拾えるのは表層だけです。アプリケーション側の入力処理や認証まわりの欠陥は、別途の脆弱性診断が必要になります。診断で優先的に見るべき項目はWebアプリケーション脆弱性診断の重要項目をまとめた記事で整理しています。
よくある質問
セキュリティパッチとは何を指しますか？
ソフトウェアに見つかった脆弱性を修正するために、開発元が提供する修正プログラムを指します。IPAの20ヶ条では第9条が該当し、OSやサーバソフトウェア、ミドルウェアについて、修正プログラムが公表された際は適用して脆弱性を解消することが求められています。機能追加を含むバージョンアップと同じ配布形態で提供されることも多く、実務では両者を分けて管理できないケースがほとんどです。
セキュリティパッチを適用しないとどうなりますか？
公開された脆弱性の情報は攻撃側も同時に入手するため、未適用のまま公開サーバーを運用すると、悪用可能な状態が外部から特定できる形で残ります。IPA「情報セキュリティ10大脅威 2026」では「システムの脆弱性を悪用した攻撃」が組織向け4位に入り、6年連続9回目の選出となりました。結果として起きるのは改ざん、情報漏えい、そして自社サーバーの踏み台化です。
セキュリティパッチが公開されたら、すぐ全部当てるべきですか？
全件を同じ速度で当てる運用は工数的に成立しないため、本文の「パッチ適用の優先順位づけ」で挙げた4変数で順序をつけます。ただし第9条の注記どおり、バージョンアップで既存のウェブアプリケーションが動作しなくなる場合があるため、影響の大きい更新には事前検証を挟むのが前提です。順序づけと検証工数の確保はセットで、どちらかが欠けると適用が止まります。
パッチ管理とパッチマネジメントに違いはありますか？
指す内容は同じで、日本語表記と英語由来のカタカナ表記の違いです。いずれも、対象資産とバージョンの把握、脆弱性情報の収集、適用可否と優先度の判断、検証、適用、適用結果の確認までの一連の運用プロセスを指します。単発のパッチ適用作業だけを指す語ではないため、「パッチ管理ツールを入れた」イコールでプロセスが回っている、とは言えません。
Webサーバーのバージョン情報は隠すべきですか？
隠しても構いませんが、対策一覧のチェック項目として数えないでください。Apache公式ドキュメントがServerヘッダの無効化に安全性向上の効果はないと明記している点は本文で触れたとおりです。実務上の判断は、隠す設定を入れるかどうかではなく、そのバージョンを上げる工数を確保できているかどうかで決まります。
