01
なぜ、一つの対策では守りきれない？
「Webサイトのどこにリスクが潜んでいる？」では、Webサイトにある6つの入口と、攻撃と被害の関係を3つの段階（侵入・悪用のきっかけ／被害が及ぶ範囲／被害の発見と復旧）に分けて見てきました。このページでは、それぞれにどう備えるのかを見ていきます。
「ウイルス対策ソフトを入れている」「通信はHTTPSで暗号化している」「バックアップを取っている」。どれも大切な対策ですが、それぞれが守れる範囲には限りがあります。
ウイルス対策ソフト
- 守れること
- パソコンやサーバーの上で、不正なプログラムを見つけて止める。
- 守れないこと
- CMSの弱点の修正や、盗まれたパスワードによるログインは、役割の外です。
HTTPS（通信の暗号化）
- 守れること
- 閲覧者とWebサイトの間の通信を、盗み見や書き換えから守る。
- 守れないこと
- サーバーの中に保存された情報や、CMSの弱点は守れません。
バックアップ
- 守れること
- 書き換えられたり、壊されたりしたデータを元に戻す。
- 守れないこと
- 外部に持ち出された情報は、元に戻しても取り消せません。
そこで、役割の違う対策を重ねて備えます。この考え方を多層防御と呼びます。一つの対策がすり抜けられても、別の対策で被害を食い止めたり、小さくしたりできるようにするためです。
-
役割1
入口を守る
「リスクはどこに潜む？」の段階1（侵入・悪用のきっかけ）に備える
限界
まだ知られていない弱点や、正規の手順を装った攻撃を、完全には防げない。
-
役割2
被害を広げない
「リスクはどこに潜む？」の段階2（被害が及ぶ範囲）に備える
限界
入口を防ぐものではない。強い権限そのものを奪われると、効果は小さくなる。
-
役割3
早く気づく
「リスクはどこに潜む？」の段階3（被害の発見と復旧）に備える
限界
気づくための仕組みで、攻撃そのものを止めるとは限らない。記録や通知を誰も確認しなければ働かない。
-
役割4
元に戻し、対応する
「リスクはどこに潜む？」の段階3（被害の発見と復旧）に備える
限界
持ち出された情報は取り戻せない。試していない手順は、いざというときに機能しないおそれがある。
4つの役割は、攻撃者が順番に通り抜ける「関門」ではありません。たとえば、正規の管理者のIDとパスワードが盗まれれば、攻撃者は弱点を探さずにログインできてしまいます。そのとき被害の大きさを左右するのは、権限の絞り込みや監視といった、別の役割の対策です。
同じ「Webサイトへの攻撃」でも、頼りになる対策は違う
役割が違うと、どんな違いが生まれるのでしょうか。よくある2つの例で比べてみます。
例A
管理者のパスワードが盗まれた
ほかのサービスで漏れたパスワードを、管理画面でも使い回していた場合
- 1入口
主な守り多要素認証：パスワードだけではログインできないようにする。ただし、もう一つの要素も盗まれたり、偽のログイン画面で入力させられたりすると、方式によっては突破されることがある。
関係しにくいソフトの更新：ソフトの弱点を突く攻撃ではないため、この場面では守りにならない。
- 2拡大
被害を限る最小限の権限：ログインされても、操作はそのアカウントに許された範囲に限られる。盗まれたのが強い権限のアカウントなら、効果は小さい。
- 3発見
気づく手がかりログと通知：ふだんと違う時間や場所からのログインを記録・通知する設定があり、誰かが確認していれば、気づける可能性がある。
- 4復旧
復旧の手段バックアップ：書き換えより前の時点のバックアップがあり、戻せることを確かめてあれば、ページを元に戻せる。
持ち出された情報は、元に戻しても取り消せません。
例B
CMSのプラグインの弱点を突かれた
修正版が提供されていたのに、更新していなかった場合
- 1入口
主な守りソフトの更新：修正版を適用していれば、この弱点はふさがれていた。ただし、ほかの弱点や設定の不備が残っていれば、別の経路で攻撃されることはある。
働かない場合がある多要素認証：ログインを必要としない弱点を突かれた場合、ログインの守りは関係しない。
- 2拡大
被害を限る保存データと接続の見直し：サーバーに個人情報をためていなければ、持ち出される情報は少なくなる。他のシステムとのつながりが限られていれば、被害は広がりにくい。
- 3発見
気づく手がかり改ざんの検知：ファイルの書き換えを検出する仕組みがあれば、改ざんや見覚えのないファイルに気づける可能性がある。
- 4復旧
復旧の手段バックアップ：被害を受ける前の時点に戻せる可能性がある。ただし、弱点を直さずに戻すと、同じ攻撃を受けるおそれがある。
持ち出された情報は、元に戻しても取り消せません。
例Aで最初の守りになるのは多要素認証で、例Bでは更新です。どんな攻撃を受けるかを前もって選ぶことはできないため、役割の違う対策をそろえておくことが大切になります。
詳しく：根拠と前提条件
IPA「安全なウェブサイトの作り方」は、脆弱性への対策を、原因そのものをなくす「根本的解決」と、攻撃による影響を軽減する「保険的対策」に分けています。保険的対策は「攻撃される可能性を低減する」「脆弱性を突かれる可能性を低減する」「被害範囲を最小化する」「被害が生じた場合に、早期に知る」の各段階で影響を軽減するもので、両方を併せて採用することが有効な場合があるとしています。
総務省「地方公共団体における情報セキュリティポリシーに関するガイドライン（令和8年3月版）」の対策基準の例文は、標的型攻撃について、侵入を低減する対策（入口対策）に加えて、侵入した攻撃の早期検知と対処、侵入範囲の拡大の困難化、外部との不正通信の検知と対処（内部対策・出口対策）を求めています。
このページの「4つの役割」は、これらを参考にした説明のための整理で、特定の資料の分類そのものではありません。「多層防御」は一般に使われる用語で、上の2つの資料に同じ語は見当たりません。英語の defense in depth は、OWASPの資料（CSPのチートシート）で、CSPを追加の防御層として位置づける考え方として使われています。
例Aの多要素認証について、OWASP Top 10:2025 の「認証の不備」（A07）は、他で漏れた認証情報の使い回しや総当たりを防ぐ手段として多要素認証を挙げています。方式による強さの違いは、対策2の「詳しく」欄を参照してください。例Bの「保存データの見直し」について、同じく「暗号化の不備」（A04）は、機微なデータを必要以上に保存しないよう勧め、「保持していないデータは盗まれない（Data that is not retained cannot be stolen.）」と述べています。
参照：IPA「安全なウェブサイトの作り方」「はじめに」（PDF p.6）・2.1（PDF p.50）・2.3（PDF p.53）／総務省ガイドライン 第2編 対策基準（例文）「不正アクセス対策」(７)（PDF p.85）／OWASP Top 10:2025 A04・A07／OWASP Cheat Sheet Series「Content Security Policy」
02
8つの対策
8つの対策を、何をする → 防ぐ・抑える被害 → なぜ効くのか → できないこと → 誰が担うかの順に説明します。番号の横の札は、図1の役割です。立場ごとの具体的な確認手順は、問題に気づいたときの行動で扱っています。
OS・CMS・プラグインの更新と、脆弱性への対処
1入口を守る- 何をする
- OS、Webサーバーソフト、CMS本体、プラグインなどの脆弱性（作りの不備による、悪用され得る弱点）の情報を集め続け、修正版への更新（パッチの適用）を行います。すぐに更新できない場合は、影響を抑える回避策をとります。そのために、どのソフトのどのバージョンを使っているかを把握しておきます。開発元のサポートが終わったソフトは修正版が出ないため、使い続けないようにします。
- 防ぐ・抑える被害
- すでに知られている弱点を突いた侵入と、その結果としての改ざん、情報の持ち出し、サイトの停止。
- なぜ効くのか
- 修正版を適用すると、その弱点はふさがれ、同じ弱点を突く攻撃は通用しにくくなります。脆弱性は日々新たに見つかるため、続けることで効果を保てます。
- できないこと
- ほかの弱点や設定の不備は、別に対処が必要です。まだ見つかっていない弱点や、修正版が出る前の弱点は防げず、盗まれたパスワードによるログインにも効きません。更新で表示や他の機能が変わることもあります（04）。
- 誰が担うか
- 実施はサーバーの管理者・保守会社（OS・サーバーソフト）やCMSの管理者・保守会社（CMS・プラグイン）。権限のない担当者は、誰がどの頻度で更新しているかを確認できます。
「リスクはどこに潜む？」の関連する入口：1 公開Webサーバー／2 CMS
詳しく：専門的な根拠
- 総務省ガイドライン（令和8年3月版）第2編 対策基準（例文）「セキュリティホールに関する情報の収集・共有及びソフトウェアの更新等」：セキュリティホールに関する情報を収集し、緊急度に応じてソフトウェア更新等の対策を実施する（PDF p.85–86）
- 同「不正プログラム対策」：開発元のサポートが終了したソフトウェアを利用しない（PDF p.83）。同「開発・保守用のソフトウェアの更新等」：更新やパッチの適用の際に、他の情報システムとの整合性を確認する（PDF p.82）
- IPA「安全なウェブサイトの作り方」2.1 1)：OSやソフトウェアの脆弱性を突いた攻撃を受けると、サーバへのアクセスに認証をかけていても不正侵入される場合がある。脆弱性情報を継続的に入手し、ソフトウェアの更新や問題の回避を行う（PDF p.50）
- OWASP Top 10:2025 A03「ソフトウェアサプライチェーンの不備」の予防策：使っている部品とバージョンの継続的な把握、脆弱性情報の監視、使っていない部品の削除。保守されなくなった部品は置き換えを検討し、すぐに修正できない場合は「仮想パッチ」を検討する。すべてのシステムへ一斉に更新を適用せず、段階的に展開する
総務省ガイドラインの第2編は、各自治体が情報セキュリティポリシーを作るための「例文」です。実際の規程の内容は、自治体ごとに異なります。
強固な認証と多要素認証
1入口を守る- 何をする
- 管理画面やサーバーにログインするときの本人確認を強くします。推測されにくく使い回さないパスワードにする、初期設定のIDやパスワードを残さない、ログインの試行回数を制限する、そしてパスワードに加えてスマートフォンのアプリなど別の手段でも確認する多要素認証を使う、などです。
- 防ぐ・抑える被害
- パスワードの推測や総当たり、他で漏れたパスワードの使い回しによる不正なログインと、その結果としての改ざんや勝手なアカウントの追加。
- なぜ効くのか
- 多要素認証では、パスワードが漏れただけでは、もう一つの要素がないためログインできません。OWASPは、漏れた認証情報の使い回しや総当たりを防ぐ手段として、多要素認証を挙げています。
- できないこと
- 多要素認証にも方式による強さの違いがあります。SMSや音声電話でコードを受け取る方式は、米国NISTの指針で利用に制限のある方式とされています。また、コードを手で入力する方式は、偽のログイン画面に入力させて中継する手口（フィッシング）を防げないとされています。ログインを必要としない弱点を突く攻撃は防げず、ログイン後の操作には権限や監視で備えます。試行回数の制限は、設定によっては正規の担当者まで締め出すことがあります。
- 誰が担うか
- 設定はCMSの管理者・保守会社（サーバーへのログインはサーバーの管理者・保守会社）。権限のない担当者は、多要素認証の有無と方式、委託先のアカウントも同じ対策か、を確認できます。
「リスクはどこに潜む？」の関連する入口：3 管理画面／6 アカウント
詳しく：専門的な根拠
- OWASP Top 10:2025 A07「認証の不備」の予防策：可能な限り多要素認証を実装・強制し、自動化された「クレデンシャルスタッフィング」（他で漏れたIDとパスワードの組み合わせを試す攻撃）、総当たり、盗まれた認証情報の再利用を防ぐ。初期設定の認証情報（特に管理者）を残さない。ログイン失敗の回数制限や遅延は、サービス妨害の状態を作らないよう注意して行う
- NIST SP 800-63B（800-63-4 版）：コードを手で入力する方式（ワンタイムパスワードや、別の経路で送られるコードの入力）は、入力した値が特定のログインに結び付かないため、偽の確認者による中継を防げず「フィッシング耐性がある」とはみなされない（Sec. 3.2.5）。電話網（SMS・音声）で別の経路の認証を行う方式は「制限付きの認証手段（restricted authenticator）」とされ、利用する組織にはリスクの評価と、制限のない代わりの手段の提供が求められる（Sec. 3.2.9、Sec. 3.1.3.3）。フィッシング耐性を持つ方式の例として、WebAuthn（FIDO2）などが挙げられている
- OWASP Cheat Sheet Series「Multifactor Authentication」：SMSや電話はSIMスワップ等の攻撃を受けやすく、フィッシングにも弱い。プッシュ通知を繰り返し送って承認させる手口（MFA疲労）への対策が必要。フィッシングに強い方式（FIDO2/WebAuthn）を推奨
- IPA「安全なウェブサイトの作り方」2.1 2)3)：ウェブサーバのリモート操作をパスワード認証のみで行うと総当たり攻撃等で突破される可能性があり、公開鍵認証等の利用を検討する（PDF p.50）。2.5「パスワードに関する対策」（PDF p.57–59）
- 総務省ガイドライン 対策基準（例文）「特権を付与されたIDの管理等」：特権IDを初期設定以外のものに変更する、入力回数制限等のセキュリティ機能を強化する（PDF p.77）。「ログイン時の表示等」：ログイン試行回数の制限等（PDF p.78）
NIST SP 800-63B は米国連邦政府のシステム向けの指針で、自治体のWebサイトに直接適用される基準ではありません。方式の強さの違いを説明するための根拠として参照しています。
必要最小限の権限とアカウント管理
2被害を広げない- 何をする
- 一人ひとりのアカウントに、仕事に必要な操作だけを許可します（最小権限）。管理者の権限を持つ人を絞り、異動・退職・契約終了のときにはアカウントを削除します。使われていないアカウントや不要な権限がないかを定期的に点検し、共有アカウントはできるだけ避けます。
- 防ぐ・抑える被害
- アカウントが乗っ取られたときの被害の広がり。放置されたアカウントの悪用。誰が操作したのか追えなくなること。
- なぜ効くのか
- 乗っ取られたアカウントでできる操作は、原則としてそのアカウントに許された範囲に限られます。ページの作成だけを許したアカウントなら、設定の変更やアカウントの追加はできません。アカウントを一人ずつ分けていれば、記録から誰の操作かをたどれます。
- できないこと
- 侵入そのものは防げません。管理者の権限を持つアカウントが奪われた場合や、ほかの弱点を突いて権限を広げられた場合は、効果が小さくなります。権限を絞りすぎると業務に支障が出ることがあるため、運用のルールと合わせて決めます。
- 誰が担うか
- 付与・削除はCMSの管理者、情報システム担当（サーバーのアカウントは保守会社）。権限のない担当者は、アカウントと権限を誰がどの頻度で見直しているかを確認できます。
「リスクはどこに潜む？」の関連する入口：6 アカウント／3 管理画面
詳しく：専門的な根拠
- 総務省ガイドライン 対策基準（例文）「アクセス制御」：権限のない職員等がアクセスできないよう必要最小限の範囲で設定する。異動・出向・退職に伴う利用者IDの取扱いを定め、利用されていないIDの点検、不要なアクセス権限の定期確認を行う。特権IDを利用する者を必要最小限にする（PDF p.76–77）
- OWASP Top 10:2025 A01「アクセス制御の不備」：最小権限の原則の違反、および権限の昇格（ログインした利用者に想定以上の権限、たとえば管理者の権限を得られてしまうこと）を、アクセス制御の不備の例として挙げる
- IPA「安全なウェブサイトの作り方」2.1 4)：用途が明確でないユーザアカウントは不正利用される可能性があり、停止または削除する（PDF p.50）
公開設定・通信の保護・不要な機能の整理
1入口を守る- 何をする
- 公開するつもりのないファイル（作業用のデータやバックアップなど）を公開用の場所に置かない、使っていない機能やサービスを止める、エラーのときに内部の情報を表示しない、といった設定の見直しです。あわせて、通信をHTTPSで暗号化し、ブラウザに安全な動作を指示する設定（HTTPセキュリティヘッダー）を整えます。
- 防ぐ・抑える被害
- 意図しない情報の公開、攻撃の手がかりを与えること、通信の盗み見や書き換え。
- なぜ効くのか
- 使っていない機能は管理が行き届かず、弱点が放置されやすくなります。止めた機能は攻撃の入口として使われなくなり、攻撃される場所そのものが減ります。
- できないこと
- HTTPSが守るのは通信の途中で、サーバー内の情報やCMSの弱点は守れません。HTTPセキュリティヘッダーも追加の守りの一つで、すべての脆弱性を防げるわけではありません。外部の診断サービスで確認できるのは、外から見える設定の一部です。
- 誰が担うか
- 設定はサーバーの管理者・保守会社。アドレスが「https://」で始まるか、ブラウザに警告が出ないかは、権限のない担当者でも確認できます。
「リスクはどこに潜む？」の関連する入口：1 公開Webサーバー／4 フォーム／5 設定
詳しく：専門的な根拠
- 総務省ガイドライン 対策基準（例文）「外部ネットワークとの接続制限等」：ウェブサーバ等をインターネットに公開する場合、必要な機能のみを利用する、ウェブサーバからの不用意な情報漏えいを防止する、全ての情報に対する暗号化及び電子証明書による認証の対策を講じる（最後の項目は【推奨事項】）（PDF p.72）。同「不正アクセス対策」：使用されていないポートの閉鎖、不要なサービスの削除又は停止（PDF p.84）
- IPA「安全なウェブサイトの作り方」2.1 4)5)：不要なサービスやアカウントの停止・削除、公開を想定していないファイルをウェブ公開用のディレクトリ以下に置かない（PDF p.50–51）。2.3：重要な情報を取り扱うページでは通信経路を暗号化する（PDF p.53–54）
- OWASP Top 10:2025 A02「セキュリティ設定の不備」の予防策：不要な機能・部品を含まない最小限の構成、セキュリティヘッダーなどによるクライアントへの指示、詳しすぎるエラーメッセージを抑える仕組み。A04「暗号化の不備」：通信中のデータをTLS 1.2以上で暗号化し、HTTPSはHSTSで強制する
- OWASP Cheat Sheet Series「Content Security Policy」：CSPはXSS対策の唯一の手段として頼るべきではなく、適切な開発を行ったうえで追加の防御層として使う
CSPやHSTSを導入するときの影響は、04 対策にも副作用があるで説明しています。「外部の診断サービスで確認できるのは外から見える設定の一部」は、このプロジェクトの説明上の整理で、個別の出典は示していません。
保存データ・接続先・システム分離の見直し
2被害を広げない- 何をする
- Webサーバーに、住民の個人情報などを必要以上にためないようにします。たとえば、フォームで受け付けた内容の保存場所と保存期間を決め、不要になったものは消します。Webサーバーから他のシステムへの接続や管理用の接続経路を必要なものに限り、外部の人が使うシステムを他のシステムから分けます。
- 防ぐ・抑える被害
- Webサーバーが侵害されたときに持ち出される情報の量と、被害が他のシステムへ広がること。
- なぜ効くのか
- 被害の大きさは、「そこに何が置かれていて、どこへつながっているか」で変わります。OWASPは「保持していないデータは盗まれない」と表現しています。つながりを限っておけば、Webサーバーを足がかりに広がる経路も限られます。
- できないこと
- 侵入そのものは防げません。分けていても、正規の連携の仕組みや共通のアカウントが悪用されれば、影響が及ぶことがあります。システムの構成は、Webサイトの担当者だけでは変えられません。
- 誰が担うか
- 構成の調査や変更は情報システム担当と保守会社が、組織の承認を得て行います。権限のない担当者は、フォームのデータの保存先と期間、Webサーバーのつながる先を確認できます。
「リスクはどこに潜む？」の関連する説明：影響の範囲は、構成と権限で変わる／4 フォーム
詳しく：専門的な根拠
- OWASP Top 10:2025 A04「暗号化の不備」の予防策：機微なデータを必要以上に保存せず、できるだけ早く破棄する（"Data that is not retained cannot be stolen."）。A02「セキュリティ設定の不備」：構成要素の間を分離する設計
- 総務省ガイドライン 対策基準（例文）「外部の者が利用できるシステムの分離等」：外部の者が利用できるシステムについて、必要に応じ他のネットワーク及び情報システムと物理的に分離する等の措置を講じる。「外部ネットワークとの接続制限等」：ウェブサーバ等の公開時に、ファイアウォール等を外部ネットワークとの境界に設置する（PDF p.72）
- 同ガイドラインの「三層の構え」：マイナンバー利用事務系を原則として他の領域と通信できないようにするなど、情報システム全体を分けて対策する考え方（PDF p.47、p.60、p.137）
庁内の情報システム全体の分離は、Webサイトの担当者が直接変更するものではありません。このプロジェクトでは、Webサーバーとのつながりを「確認する観点」として扱います。
バックアップと復旧テスト
4元に戻し、対応する- 何をする
- Webサイトのデータや設定、システムの複製（バックアップ）を定期的に取り、元のシステムから切り離した場所に、複数の時点の分（世代）を保管します。そして、実際に元に戻せるかを定期的に試し、戻す手順を決めておきます。
- 防ぐ・抑える被害
- 改ざん、データの破壊、ランサムウェアによる暗号化、障害などによる、サービスの長い停止。
- なぜ効くのか
- 被害そのものを防ぐのではなく、壊されても元に戻す手段を残しておく対策です。複数の時点の分を残すのは、侵入に気づくのが遅れても、被害を受ける前の状態まで戻れるようにするためです。
- できないこと
- 持ち出された情報は取り消せません。元のシステムと同じネットワーク上のバックアップは、一緒に暗号化されるおそれがあり、侵入後に取ったバックアップには不正なプログラムが残っている可能性があります。復旧を試したことがなければ、手順どおりに戻せるかはわかりません。
- 誰が担うか
- 実施は保守会社・ホスティング事業者、情報システム担当。権限のない担当者は、何をどこに何世代保管しているか、最後に復旧を試したのはいつかを確認できます。
詳しく：専門的な根拠
- 総務省ガイドライン 対策基準（例文）「バックアップの実施」：業務システムのデータベースやファイルサーバ等の情報について、必要に応じて定期的にバックアップを実施する（PDF p.70）
- 同 第3編（解説）：標的型攻撃によって取得したバックアップが暗号化されるケースがあるため、世代管理、保存場所や媒体も考慮する。マルウェアが潜伏した状態で取得したバックアップを復元すると、マルウェアも復元される可能性がある。論理的に切り離されたネットワークや物理的な媒体への保存を検討する（PDF p.205、印刷ページ ⅲ-105）
- 同 第3編（解説）：ランサムウェアへの備えとして、オフラインの媒体等への保管を検討する。バックアップから復旧可能なことや復旧手順を定期的に確認しておく。感染前の復旧ポイントの特定や、マルウェアが残っていないかの確認を復旧手順に含める（PDF p.254–255、印刷ページ ⅲ-154〜155）
監視・ログ・異常の早期発見
3早く気づく- 何をする
- ログイン、設定の変更、ページの書き換えなどの記録（ログ）を残し、定期的に確認・分析します。ログインの失敗が続く、ふだんと違う時間に管理者がログインする、ページが書き換えられる、といった異常を検知して担当者に知らせる仕組みを整えます。記録の時刻が正確であることも大切です。
- 防ぐ・抑える被害
- 被害に気づかないまま時間がたち、被害が広がること。原因や影響の範囲がわからなくなること。
- なぜ効くのか
- 早く気づけば、それだけ早く止めたり、住民へ知らせたりできます。記録が残っていれば、何が起きたのか、どこまで影響があったのかを調べられます。
- できないこと
- 監視は気づくための仕組みで、攻撃そのものを止めるとは限りません。検知の仕組みが見逃す異常もあります。記録や通知を誰も確認しなければ役に立たず、通知が多すぎると重要な通知が埋もれることがあります。
- 誰が担うか
- 仕組みを整え運用するのは保守会社・ホスティング事業者、情報システム担当。権限のない担当者は、何を記録し、誰が確認し、異常時に誰へ連絡が来るのかを確認できます。
「リスクはどこに潜む？」の関連する入口：3 管理画面／6 アカウント
詳しく：専門的な根拠
- 総務省ガイドライン 対策基準（例文）「ログの取得等」：各種ログを取得して一定の期間保存し、定期的に点検又は分析して不正侵入・不正操作等の有無を確認する（PDF p.71）。「不正アクセス対策」：ウェブページの改ざんを防止するために、データの書換えを検出し、責任者へ通報するよう設定する（PDF p.84）。「情報システムの監視」：常時監視、重要なログを取得するサーバの正確な時刻設定と時刻同期（PDF p.86–87）
- OWASP Top 10:2025 A09「セキュリティログとアラートの不備」の予防策：ログインやアクセス制御の失敗を記録し、後から調べられる期間保存する。不審な動きにはアラートを出し、検知と対応の手順を整える
- IPA「安全なウェブサイトの作り方」「はじめに」：保険的対策の段階の一つとして「被害が生じた場合に、早期に知る」を挙げる（PDF p.6）
「検知の仕組みが見逃す異常もある」「通知が多すぎると重要な通知が埋もれる」は一般的な説明で、このページでは個別の出典を示していません。
インシデント発生時の連絡・対応体制
4元に戻し、対応する- 何をする
- 改ざんや不正アクセスなどのインシデント（情報セキュリティ上の事故や、その疑い）に気づいたとき、誰に、どの順番で連絡し、誰が何を判断するのかを、あらかじめ決めておきます。保守会社やホスティング事業者の緊急連絡先と、どこまで対応してもらえるのかも、契約で確かめておきます。
- 防ぐ・抑える被害
- 初動の遅れや混乱による被害の拡大。原因を調べるための記録が失われること。
- なぜ効くのか
- 事故が起きてから連絡先や判断する人を探していると、対応が遅れます。総務省のガイドラインの例文は、連絡、証拠の保全、被害拡大の防止、復旧、再発防止を迅速に行うために、緊急時の対応計画を定めておくこととしています。
- できないこと
- 体制だけでは攻撃を防げません。連絡先や担当者が古いままでは機能しないため、組織の変化に合わせた見直しが必要です。
- 誰が担うか
- 計画や体制を定めるのは組織（情報セキュリティの責任者や、組織内の対応チームなど）。Webサイトの担当者は、自分の組織の手順と連絡先、保守会社の緊急連絡先と対応範囲を知っておくことが最初の備えです。異常に気づいたら、ご自身で操作せず、定められた手順に沿って連絡してください。
詳しく：専門的な根拠
- 総務省ガイドライン 対策基準（例文）「侵害時の対応等」：連絡、証拠保全、被害拡大の防止、復旧、再発防止等の措置を迅速かつ適正に実施するために緊急時対応計画を定める。計画には関係者の連絡先、報告すべき事項、対応措置、再発防止措置の策定を含め、状況や組織体制の変化に応じて見直す（PDF p.88）
- 同「不正アクセス対策」：監視、通知、外部連絡窓口及び適正な対応を実施できる体制並びに連絡網を構築する（PDF p.84）。攻撃を受け、犯罪の可能性がある場合は攻撃の記録を保存し、警察等と連携する（PDF p.85）。「不正プログラム対策」：外部の専門家の支援を受けられるようにしておく（PDF p.84）
- 同 第3編（解説）：ランサムウェアの事前・事後対策について、システムを導入した事業者及び保守を行う事業者との役割分担を明確に定め、保守契約を行うことが重要（PDF p.255）
- OWASP Top 10:2025 A09 の予防策：インシデント対応・復旧計画を確立または採用する（例：NIST SP 800-61r2 以降）
03
Webサイトの対策と、組織全体の対策
Webサイトを守る対策は、自治体全体の情報セキュリティ対策の一部です。どこまでがWebサイトの対策で、どこからが組織全体の対策なのかを整理しておくと、誰に何を確認すればよいかが見えやすくなります。
公開Webサイトと、その管理環境の対策
このプロジェクトが扱う中心
- Webサーバー・CMS・プラグインの更新
- 管理画面の認証と、Webサイトのアカウント・権限
- 公開設定・通信の暗号化・不要な機能の整理
- フォームで受け付けたデータの扱い
- Webサイトのバックアップ、ログ、改ざんの検知
両方にまたがるもの
契約・権限・承認によって、個別に扱いが決まる
- Webサイトの管理に使う端末
- Webサイトの保守を担う委託先の環境
- Webサーバーと他のシステムとのつながり
- インシデント発生時の連絡体制
庁内・端末・組織全体の対策
各自治体の情報セキュリティの体制で行うもの（このプロジェクトの直接の対象外）
- 三層の構えなど、庁内ネットワークの分離
- 住民基本台帳やマイナンバーに関わる基幹システムの保護
- 職員のパソコン全般のウイルス対策や更新
- メールの運用、情報セキュリティポリシー、職員の教育
Webサイトの対策でできること
- Webサイトを入口とした侵入や改ざんを防ぎやすくする
- Webサーバーが侵害されたときの被害を、Webサイトの範囲で小さくする
- Webサイトの異常に早く気づき、元に戻す
Webサイトの対策だけではできないこと
- 庁内のシステムや基幹システムの安全を保証する
- 職員のパソコンやメールを経由する被害を防ぐ
- 組織全体の事故対応の体制を代わりに担う
「リスクはどこに潜む？」で見たとおり、Webサーバーへの侵入が、庁内のシステムや基幹システムへの侵入に必ずつながるわけではありません（「リスクはどこに潜む？」 02）。一方で、Webサイトの対策だけで、庁内のシステムまで守れるわけでもありません。
ウイルス対策ソフトも組織全体の対策の一つで、総務省のガイドラインの例文でも、サーバやパソコン等に導入することとされています。ただし、CMSの更新や管理画面の認証の代わりにはなりません。役割が違うためです。
このプロジェクトが扱う範囲について：図の「両方にまたがるもの」を含め、実際に調査や変更を行う範囲は、システムの構成、契約の内容、管理権限、自治体の承認によって決まります。扱う領域に含まれることと、Re:meがその領域を無条件に調査・変更できることは別です。また、住民基本台帳やマイナンバーに関わる基幹システムを直接点検したり保護したりすることは行いません。
詳しく：根拠と前提条件
総務省ガイドライン（令和8年3月版）は、自治体の情報システムを「マイナンバー利用事務系」「LGWAN接続系」「インターネット接続系」に分けて対策する考え方（三層の構え）を示しており、ホームページ管理システム等はインターネット接続系に含まれると定義しています（PDF p.45、p.47、p.137）。この分け方がどのように実装・運用されているかは、自治体ごとに異なります。
同ガイドラインの対策基準（例文）「不正プログラム対策」では、サーバ及びパソコン等の端末に不正プログラム対策ソフトウェアを常駐させ、パターンファイルとソフトウェアを常に最新の状態に保つこととしています（PDF p.83）。
04
対策にも副作用がある
セキュリティの対策は、追加すれば必ず良くなるとは限りません。設定や仕組みを変えると、これまで使えていた機能や日々の作業に影響することがあります。IPAの「安全なウェブサイトの作り方」も、対策によっては本来の機能を制限するものがあり、副作用の影響も考慮する必要があると述べています。
- 対策の例CMS本体やプラグインの更新起こり得る影響表示が崩れる。他のプラグインやフォームが動かなくなる。
- 対策の例ログインの試行回数の制限起こり得る影響入力を間違えた正規の担当者まで締め出される。
- 対策の例多要素認証の導入・方式の変更起こり得る影響共有アカウントの使い方や、委託先の作業手順を見直す必要が出る。
- 対策の例管理画面に接続できる場所の制限起こり得る影響庁外や保守会社からの作業ができなくなる。
- 対策の例CSP（ページが読み込んでよい場所を指定するHTTPセキュリティヘッダー）の追加起こり得る影響許可していない場所からの読み込み（外部の地図・動画・SNSの埋め込み、解析ツールなど）や、ページ内に直接書かれたスクリプトが止まり、表示や機能が失われることがある。強制せずに違反の報告だけを受けるモード（Report-Only）で、影響を先に確かめる方法がある。
- 対策の例HSTS（HTTPSでの接続をブラウザに強制させる設定）起こり得る影響閲覧者のブラウザは、指定された期間、そのサイトにHTTPSでしか接続しなくなる（サブドメインも対象にする指定をすると、サブドメインも含む）。証明書の期限切れなどHTTPSに問題が起きると、閲覧者は警告を無視して進むこともできず、サイトを開けなくなる。設定をやめても、各ブラウザに残った設定は、取りやめの指示を受け取るか、期間が切れるまで残る。
- 対策の例WAF（攻撃を検査して遮断する仕組み）の導入起こり得る影響正当な通信まで遮断されることがある（誤検知）。
だから、変更の前に確かめることがある
副作用があるからといって、対策をしないほうがよいわけではありません。大切なのは、影響を確かめ、元に戻せる準備をしてから変更することです。
- 権限と契約を確かめる誰が変更してよいのか。保守契約の範囲か。
- 影響を洗い出すどの機能や業務に影響し得るか。
- 本番とは別の環境で試す検証用の環境や、報告だけのモードで確かめる。
- 承認を得て、戻し方を用意するバックアップと、元に戻す手順。
- 実施後に確かめ、記録する動作の確認と、何をいつ誰が変えたかの記録。
立場ごとの具体的な進め方と確認事項は、問題に気づいたときの行動と制作会社・保守会社との役割分担で説明しています。
確認・対策を進めるときの注意
- 許可なく診断ツールでWebサイトを調べたり、攻撃を試したりしないでください。自分の組織のサイトであっても、サイトの停止や、契約・規程への違反につながることがあります。
- 本番のWebサイトの設定を、承認や事前の確認なしに変更しないでください。
- 不正アクセスなどの疑いがあるときは、ご自身で操作せず、組織で定められた手順に沿って連絡してください。
詳しく：根拠と前提条件
- IPA「安全なウェブサイトの作り方」「はじめに」：保険的対策は、対策の内容によっては本来の機能を制限することになるものもあるので、副作用の影響も考慮する必要がある（PDF p.6）。2.6：WAFの偽陽性（正常な通信を悪質と判定）では正当な通信が遮断され、ウェブサイトの可用性が損なわれる（PDF p.63–64）
- CSP：OWASP Cheat Sheet Series「Content Security Policy」は、CSPの読み込み元の指定（fetch directives）がブラウザに信頼してよい読み込み元を伝えること、script-src 等が有効なときはページ内に直接書かれたスクリプトが既定で無効になることを説明し、Report-Only で強制しないポリシーを配信できるとしています。W3C「Content Security Policy Level 3」（2026年9月16日付 Working Draft）3.2 は、Content-Security-Policy-Report-Only を、ポリシーを強制せずに監視して効果を試すためのヘッダーと定義しています
- HSTS：RFC 6797 は、ブラウザが HSTS の対象のホストへの http の参照を https に変換すること、安全な接続でエラーや警告が起きた場合は接続を打ち切ること（2.2、8.4）、利用者に先へ進む選択肢を示さないこと（12.1「No User Recourse」）、max-age の秒数の間その設定を保持し、max-age=0 を受け取ると対象から外すこと（6.1.1）、includeSubDomains がサブドメインにも適用されること（6.1.2）を定めています。OWASP Cheat Sheet Series「HTTP Strict Transport Security」は、includeSubDomains を付けると HTTP でしか提供できないページにアクセスできなくなること、最初は短い max-age で試す例、preload の指定が恒久的な影響を持ち得ることを説明しています
- OWASP Top 10:2025 A07：ログイン失敗の回数制限や遅延は、サービス妨害の状態を作らないよう注意する。A03：すべてのシステムへ一斉に更新を適用せず、段階的に展開する
- 総務省ガイドライン 対策基準（例文）：開発・保守・テスト環境と運用環境の分離【推奨事項】、既存のシステムに接続する前の十分な試験、擬似環境による操作確認（PDF p.79–80）。作業内容の記録と、2名以上での作業・相互確認（PDF p.71）。更新やパッチ適用の際の整合性の確認（PDF p.82）
CMSの更新による表示崩れなどの具体例、多要素認証の導入・接続場所の制限による影響の例は一般的な説明で、このページでは個別の出典を示していません。実際の影響は、Webサイトの構成や使っている外部サービスによって異なります。
05
誰が何をする？
8つの対策は、一人の担当者がすべてを行うものではありません。立場によって、確認できること・実施できることが異なります。ご自身の立場でできることから始め、それ以外は適切な人に確認することが、安全への近道です。
| 対策 | Web担当者 （管理権限なし） |
CMSの管理者 | 情報システム担当 | 保守会社・ ホスティング事業者 |
|---|---|---|---|---|
| 1 更新 | 担当者と頻度を確認 | CMSの更新状況を確認し、保守会社と調整 | 方針の決定、サポート期限の管理 | 更新の実施と動作確認 |
| 2 認証 | 多要素認証の有無と方式を確認 | 管理画面の認証設定、利用者への周知 | 認証の方針を決める | サーバーへのログインの認証を設定 |
| 3 権限 | 見直しの頻度を確認 | アカウントの付与・削除・棚卸し | 異動・退職との連携、方針 | サーバーのアカウント管理 |
| 4 公開設定・通信 | https・警告の有無を目で見て確認 | CMSの公開設定を確認 | 方針の決定と変更の承認 | サーバー設定・証明書・ヘッダーの設定と検証 |
| 5 データ・接続 | フォームのデータの保存先を確認 | 受付データの扱いを確認 | 構成の把握と、変更の判断 | 構成の調査と変更 |
| 6 バックアップ | 保管と復旧テストの状況を確認 | 権限の範囲で、取得状況を確認 | 要件（戻すまでの時間など）を決める | 取得・保管・復旧テスト |
| 7 監視・ログ | 異常時の連絡先を確認 | 管理画面の操作履歴を確認 | 監視の方針、ログの確認 | 監視の運用と通知 |
| 8 連絡・対応 | 手順と連絡先を把握し、異常に気づいたら連絡 | 状況を記録し、手順に沿って連絡 | 組織としての対応と判断 | 契約に沿った調査と復旧 |
「わからない」「確認できなかった」という結果は、「危険」でも「問題なし」でもありません。権限のある人に確認すべき項目として扱ってください。具体的な確認の手順と、保守会社への質問の例は、問題に気づいたときの行動で扱っています。
06
用語の説明
- 多層防御
- 役割の違う対策を重ねて備える考え方。一つの対策がすり抜けられても、別の対策で被害を抑えられるようにする。
- 脆弱性（ぜいじゃくせい）
- ソフトウェアの作りの不備などによる、悪用され得る弱点。
- パッチ
- 脆弱性や不具合を修正するために、開発元が提供する修正用のプログラム。
- 多要素認証
- パスワードに加えて、スマートフォンのアプリなど別の手段でも本人確認する仕組み。方式によって強さが異なる。
- フィッシング
- 本物に見せかけた偽のサイトなどで、IDやパスワード、確認コードを入力させて盗む手口。
- 最小権限
- アカウントごとに、仕事に必要な操作だけを許可する考え方。
- HTTPS
- 閲覧者とWebサイトの間の通信を暗号化する仕組み。アドレスが「https://」で始まる。
- HTTPセキュリティヘッダー
- Webサーバーからブラウザへ、安全な動作を指示するための設定。CSPやHSTSなどがある。
- CSP
- Content Security Policyの略。ページが読み込んでよい場所や、実行してよいスクリプトをブラウザに指示する設定。
- HSTS
- HTTP Strict Transport Securityの略。一定の期間、そのサイトへ常にHTTPSで接続するようブラウザに指示する設定。
- WAF
- Web Application Firewallの略。Webサイトとのやり取りを検査し、攻撃とみられる通信を遮断する仕組み。
- バックアップの世代
- 複数の時点のバックアップを残しておくこと。気づくのが遅れても、被害の前の状態に戻せるようにする。
- ログ
- 誰が、いつ、何をしたかなどを記録したもの。不審な操作に気づいたり、原因を調べたりするために使う。
- インシデント
- 情報セキュリティ上の事故や、その疑いのある出来事。
07
参考資料
いずれも2026年10月22日に、公開元のページまたは本文PDFで名称・版・該当箇所を確認しました。PDFのページ番号は、PDFビューア上の通し番号です。
-
地方公共団体における情報セキュリティポリシーに関するガイドライン（令和8年3月版）
このページでの用途：第2編 対策基準（例文）のバックアップ、ログ、ウェブサーバの公開、アクセス制御、特権ID、テスト・変更管理、不正プログラム対策、不正アクセス対策、セキュリティホール対策、監視、緊急時対応計画。第3編（解説）のバックアップの世代管理・保存場所、ランサムウェアへの備え。三層の構え
https://www.soumu.go.jp/main_content/001064404.pdf（本文PDF）
掲載ページ：https://www.soumu.go.jp/denshijiti/index_00004.html（総務省「自治体のサイバーセキュリティ対策」）
第2編は、各自治体が情報セキュリティポリシーを作るための例文です。実際の規程の内容は自治体ごとに異なります。
-
安全なウェブサイトの作り方
このページでの用途：「はじめに」（根本的解決と保険的対策、副作用）、2.1 ウェブサーバに関する対策、2.3 ネットワーク盗聴への対策、2.5 パスワードに関する対策、2.6 WAFによるウェブアプリケーションの保護
https://www.ipa.go.jp/security/vuln/websecurity/about.html
改訂第7版の内容は発行から年数が経っています。最新の動向は、下記のOWASPなどの資料と併せて確認してください。
-
OWASP Top 10:2025
このページでの用途：各分類の予防策（A01 アクセス制御の不備、A02 セキュリティ設定の不備、A03 ソフトウェアサプライチェーンの不備、A04 暗号化の不備、A07 認証の不備、A09 セキュリティログとアラートの不備）
https://owasp.org/Top10/2025/（日本語：https://owasp.org/Top10/2025/ja/）
予防策の内容は、英語版の各分類ページで確認しました。
-
OWASP Cheat Sheet Series（Multifactor Authentication／Content Security Policy／HTTP Strict Transport Security）
このページでの用途：多要素認証の方式ごとの弱点、CSPの役割と影響・Report-Only、HSTSの設定上の注意
https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html
https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html
チートシートは随時更新される文書です。内容は確認日時点のものです。
-
NIST Special Publication 800-63B（Digital Identity Guidelines 800-63-4 版）
このページでの用途：フィッシング耐性（Sec. 3.2.5）、制限付きの認証手段としての電話網（SMS・音声）（Sec. 3.2.9、3.1.3.3）
https://pages.nist.gov/800-63-4/sp800-63b.html
米国連邦政府のシステム向けの指針で、自治体のWebサイトに直接適用される基準ではありません。
-
RFC 6797 HTTP Strict Transport Security (HSTS)／Content Security Policy Level 3
このページでの用途：HSTSの効果・期間・サブドメイン・エラー時の扱い（RFC 6797 2.2、6.1.1、6.1.2、8.4、12.1）、CSPの Report-Only（CSP3 3.2）
https://www.rfc-editor.org/rfc/rfc6797
CSP Level 3 は策定中の文書（Working Draft）です。
サイト全体の入口は、トップページへ。