なぜ今「Webサイトの情報セキュリティ」と「ガバナンス」が経営課題なのか

事故対応は「技術」だけでなく「統制」の問題になりやすい

Webサイトは会社の窓口であると同時に、顧客問い合わせや採用応募などの個人情報が集まる業務システムになっています。インシデント＝情報漏えい、改ざん、不正アクセスなど、情報資産に影響が出る事故や事象が起きると、売上機会の損失だけでなく、信用低下、対応工数の増加、再発防止投資まで連鎖します。

脆弱性＝攻撃者に悪用され得る弱点です。ここで重要なのは、被害の大きさが「脆弱性の有無」だけで決まらず、意思決定と運用の仕組みで増幅する点です。例えば「誰が公開停止を決めるか」「外部委託先に連絡がつかない夜間はどうするか」「復旧に必要な情報がどこにあるか」が曖昧だと、初動が遅れて影響範囲が広がります。ガバナンス＝ルール・権限・責任を明確にしてWebサイト運用を組織として統制する仕組みを整える目的は、まさにこの遅延を減らすことです。

経営者・情報システム責任者が押さえるべき論点は次の3つです。

• リスク：何が起きると事業に痛いか（個人情報、採用、決済、ブランドなど）
• 継続性：止まったときに何時間で戻せるか（ダウンタイム＝サイトが利用できない時間）
• 説明責任：社内外へ説明できる体制か（責任分界点＝社内と外部のどこまでが誰の責任かの境界）

従業員10〜500名で起きやすい「属人化」の典型

この規模では、担当者の兼務や入れ替わりが起きやすい一方、運用手順が文書化されないままサイトが成長しがちです。よくあるリスクの芽は次の通りです。

• 管理画面のIDが共有され、退職者の権限が残る
• 更新依頼がチャットや口頭だけで流れ、承認・記録が残らない
• 外部委託先に「全部お任せ」になり、現状把握ができない
• バックアップはあるが、戻す練習をしておらず復旧に時間がかかる

みやあじよでは、制作や運用を「問題解決」と捉え、最終成果を問い合わせや採用などの目的達成に置いて設計します。この考え方は、セキュリティを単なるコストではなく「事業の機会損失を減らす運用品質」として扱う上で相性が良いです。

まず決めるべき統制範囲：守るべき情報・資産・公開領域の棚卸し

「守る対象」を先に言語化すると、投資の順番が決まる

最初にやるべきは、脅威の網羅的な議論ではなく、自社サイトで扱う対象の棚卸しです。情報資産＝企業が守るべきデータやシステムを洗い出し、「影響が大きい順」に並べます。ここが曖昧だと、更新管理だけを頑張っても、いちばん守りたいフォームや管理画面が手薄になる、といったズレが起きます。

棚卸しは、次の観点で進めると整理しやすくなります。

• どこに個人情報が入るか（問い合わせ、資料請求、採用、会員登録）
• どこが改ざんされると痛いか（トップ、商品/サービス、採用、PDF）
• どこが止まると業務が止まるか（予約、申込み、決済、採用受付）
• どこに強い権限があるか（CMS、サーバ、DNS、メール送信）

CMS＝Webサイトのページや記事を編集・管理する仕組みです。DNS＝ドメイン名と接続先を対応づける仕組みです。

守る対象の整理サンプル

対象	起こり得る影響	優先度	必要な統制
問い合わせフォーム	個人情報の漏えい、迷惑送信、機会損失	高	権限管理、ログ、監視、バックアップ
採用エントリー	応募者情報の漏えい、採用活動の停滞	高	更新管理、WAF、復旧手順
CMS管理画面	乗っ取りによる改ざん、マルウェア配布	最優先	多要素認証、個別ID、権限最小化
公開コンテンツ	改ざんによる信用低下、検索評価の毀損	中	改ざん検知、差分確認、復旧
サーバ/DNS	全停止、メール不達、復旧長期化	最優先	バックアップ設計、手順書、連絡網

マルウェア＝端末やサーバに悪影響を与える悪意のあるプログラムです。ログ＝操作や通信の記録です。多要素認証＝パスワードに加えて別の要素（アプリ確認など）で本人確認する方式です。WAF＝Webアプリケーションへの攻撃を検知・遮断する仕組みです。

優先度の考え方は「影響×露出」で十分スタートできる

細かい点数付けを最初からやると止まります。まずは「影響（止まったときの損失）」と「露出（外部から触れられる範囲）」の2軸で、最優先と高を決めます。最優先に入った領域から、監視・バックアップ・復旧の整備、権限の見直しを当てていくと、短期間でも事故の拡大を抑えやすくなります。

ガバナンス設計の要点：役割分担、権限、承認、変更管理の作り方

役割分担はRACIで「決める人」と「やる人」を分ける

RACI＝業務の役割をResponsible（実行）、Accountable（最終責任）、Consulted（相談先）、Informed（報告先）で整理する方法です。Web担当者・情シス・外部委託先が関わる領域は、口約束だと破綻しやすいため、最低限ここだけは明文化します。

• 変更の承認（誰がGOを出すか）
• 緊急時の判断（公開停止、復旧、対外連絡）
• 権限付与と剥奪（追加・退職・委託変更時）
• バックアップと復旧（頻度、保管、訓練）

承認と変更管理がないと「安全に速く直す」が両立しない

変更管理＝サイトの変更内容を記録し、承認・反映・検証までを一連で管理することです。属人化した現場では「急ぎだから口頭で反映」「差し戻しの経緯が残らない」が積み重なり、結果的にミスが増えます。特に脆弱性対応や障害復旧はスピードが大切ですが、だからこそ“短いルール”でよいので型を作ります。

実務では、以下の4点が揃うだけでも運用の再現性が上がります。

• 変更履歴：何を、いつ、誰が、なぜ変えたか
• 反映手順：本番反映の前後にやる確認項目
• 差し戻し：戻す手順と判断基準（復旧目標時間の目安）
• 連絡経路：緊急連絡網と一次対応の担当

権限管理の最小単位を「個人」にする

属人化対策は、担当者に負担をかけるのではなく、仕組みで起きにくくすることが近道です。まずは、共有IDをやめ、個人ごとに権限を付与し、最小権限＝業務に必要な範囲に権限を絞る考え方で運用します。操作ログが追える状態にしておくと、トラブル時の原因切り分けも速くなります。

保守運用の基本セット：監視・更新管理・バックアップ・復旧を切れ目なく回す

「守る」は4つの運用で成立する

Webサイトの情報セキュリティは、単発の対策導入だけでは維持できません。経営判断として押さえるべきは、日々の運用が回る前提を作り、事故の芽を早期に見つけ、被害を最小化し、早く戻すことです。運用も制作と同様に、目的達成のための問題解決として設計すると、投資判断と改善がブレにくくなります。
実務は次の4要素に整理できます。

• 監視：サイトの稼働と異常を検知し、一次対応につなげる
• 更新管理：CMSやサーバ等の更新を計画的に行い、脆弱性を放置しない
• バックアップ：復旧に必要なデータを欠損なく残し、世代管理する
• 復旧：手順と権限を整え、復旧目標に沿って戻す

監視は「気づく仕組み」と「動ける体制」がセット

死活監視＝サイトが表示できるかを定期的に確認する監視です。加えて、改ざん検知＝ページやファイルの変化を検知する仕組み、エラーログ監視＝障害の兆候となる記録を監視する運用があると、早期発見に寄与します。重要なのは、通知が来たときに誰が何をするかが決まっていることです。通知先、一次切り分け、公開停止や復旧の判断経路までが運用設計に含まれます。

更新管理は「計画更新」と「緊急更新」を分ける

パッチ＝不具合や脆弱性を修正する更新プログラムです。更新を怖がって止めると、リスクが積み上がります。一方で、闇雲に更新すると表示崩れや機能停止が起きます。そこで、定例の計画更新（例：月次）と、緊急更新（重大な脆弱性対応）を分け、事前検証と反映手順を型化します。検証環境＝本番と近い状態で変更を試す環境を用意すると、更新の失敗率を下げられます。

バックアップは「取っている」より「戻せる」が重要

RPO＝どの時点までのデータ復元を目標にするかの指標、RTO＝どれくらいの時間で復旧するかの指標です。バックアップ設計では、対象（サイトデータ、DB、設定）、頻度、保管場所、保存世代、復旧手順を決めます。DB＝フォーム送信内容などを保存するデータベースです。さらに、復元テスト＝実際に戻して動作確認する訓練を定期的に行うと、いざという時の復旧速度が大きく変わります。

復旧は「技術」より「段取り」で差が出る

復旧で詰まりやすいのは、必要情報が散在していることです。管理画面やサーバ、DNSなどの権限、契約情報、連絡網、直近の変更履歴が揃っていないと、作業以前に時間が溶けます。復旧支援の実務は、復旧手順書の整備、権限の整理、バックアップからの復元、原因の切り分け、再発防止の反映までを一気通貫で設計することです。

外部委託のベンダー管理：契約で決めること、運用で見ること、任せ方のコツ

「任せる」には、決めておくべき境界がある

SLA＝サービス品質（受付時間、初動時間、復旧目標など）を合意する指標です。SOW＝作業範囲と成果物を明文化した文書です。外部委託では、技術力だけでなく、責任分界点と連絡設計が品質を左右します。最低限、次の項目を契約と運用ルールに落とします。

• 監視範囲と通知ルール（何を検知し、誰に、どの手段で通知するか）
• 障害時の優先度と初動（重大度の定義、一次対応、報告フォーマット）
• 更新管理のサイクル（定例更新の頻度、緊急時の扱い、検証の有無）
• バックアップと復元テスト（頻度、世代、保管、復元確認の実施）
• 権限管理（個人ID、最小権限、多要素認証、ログ保全）

パスワードマネージャー＝IDやパスワードを安全に保管し共有する仕組みです。共有IDを避け、委託先も個人単位で権限付与し、作業ログが追える状態にします。

名義と情報の所有権を自社に残す

委託先任せで起きやすいのが、いざ乗り換えや緊急対応が必要になったときに「重要情報が取り出せない」状態です。ガバナンスの観点では、少なくとも次は自社で把握できる形に揃えます。

• ドメイン、DNS、サーバの契約名義とログイン情報
• 監視ツールやバックアップの設定情報と復旧手順書
• CMSの管理者権限の所在（誰が最上位か）
• ソースコードや素材データの保管場所と引き継ぎルール

月次の定例報告で「ブラックボックス化」を防ぐ

運用を委託しても、社内が何も分からない状態はガバナンスとして危険です。定例報告は、作業の棚卸しではなく、リスクと改善の見える化が目的です。アラート＝異常を知らせる通知です。例として、当月の更新内容、監視アラートの件数と内訳、障害の有無、バックアップ結果、改善提案の5点が揃うと、経営判断の材料になります。

費用と投資判断：内製/委託の比較、見積の見方、優先順位の付け方

判断軸は「TCO」と「止まった時の損失」

TCO＝導入後の運用費も含めた総コストです。内製は柔軟ですが、担当者の学習・引き継ぎ・夜間対応などの見えにくい負担が発生しやすいです。外部委託は対応の再現性を作りやすい一方、契約範囲外の作業が積み上がると割高になります。投資判断では、最優先領域（個人情報・管理権限・サーバ/DNS）に対して、監視→復旧→更新管理の順で「止まった時の損失」を減らす設計にすると、説明が通りやすくなります。

内製と外部委託の比較（意思決定のたたき台）

観点	内製の特徴	外部委託の特徴	判断の目安
初動と復旧	担当者次第で速度が変動	体制・手順の標準化がしやすい	夜間/休日の対応要件がある場合は委託が有利
更新管理	柔軟だが検証が後回しになりがち	定例サイクルを作りやすい	更新が止まりやすい組織は委託で仕組み化
ガバナンス	責任者の力量に依存	責任分界とレポートで可視化しやすい	監査・説明責任が重い場合は委託が有利
コスト	人件費と教育・引継ぎが増えやすい	固定費化できるが範囲外が出る	要件をSOWで明確化し、追加条件を管理

見積を見る際は、監視（検知と通知）、更新（定例と緊急）、バックアップ（保管と復元テスト）、復旧（初動と原因調査）の4要素が抜けていないかを確認し、範囲外作業の扱い（単価、上限、承認フロー）まで含めて比較すると、後からの想定外を減らせます。加えて、委託先が「手順書を整備し、復旧訓練まで支援するか」は費用差が出やすいポイントです。復旧を急ぐ局面ほど段取りの価値が表れます。

成果の測り方：経営が納得するKPI設計

KPIは「守りの運用」を意思決定できる言葉に変える

KPI＝重要業績評価指標で、達成度を測るための指標です。
Webサイトの保守運用では、作業量（更新した回数など）だけを追うと、経営が判断に使いにくくなります。経営者・情報システム責任者が納得しやすいのは、次の4系統で「状態」を示すKPIです。

• 稼働：止まらない、止まっても早く戻る
• 品質：変更で壊さない、壊してもすぐ戻せる
• リスク：危ない状態を放置しない
• 業務負荷：属人化せず、緊急対応を増やさない

ポイントは、KPIを「監視・更新管理・バックアップ・復旧」の運用セットと紐づけることです。これにより、外部委託の評価や、投資優先順位の説明が一気に通りやすくなります。

運用品質KPIサンプル

領域	KPI例	測定方法	改善アクション例
監視	検知〜一次対応までの時間	アラート発生時刻と対応開始の記録	通知先の整理、当番体制、一次手順の短縮
更新管理	定例更新の実施率	月次の更新計画と実績の差分	検証環境の整備、反映手順の標準化
バックアップ	バックアップ成功率と保管世代の維持	実行ログ、保管先の世代確認	対象漏れの見直し、監視連携、保管ルール修正
復旧	復元テストの実施頻度	復元テストの実施記録と結果	復旧手順書の更新、権限整備、連絡網更新

一次対応＝最初に状況確認と影響抑止を行う初動対応です。
復元テスト＝バックアップから実際に戻して動作確認する訓練です。

KPIは「報告」ではなく「改善の合意」に使う

KPIは並べるだけでは意味がありません。月次で見直し、次月の改善を1〜3個に絞って合意することで、運用が回り始めます。特に外部委託では、定例報告の場で以下が揃うと、ガバナンスが機能しやすくなります。

• 今月のリスク増減（未更新や権限の課題など）
• 事故や兆候の有無（検知、一次対応、再発防止）
• 来月の改善提案（費用が増える場合は理由と効果）

導入ステップ：90日で属人化しない運用に移行する進め方

0〜30日：現状の可視化と最低限の安全網を作る

最初の1か月は「増やす」より「揃える」が重要です。まずは止血と見える化を優先します。

• 守る対象の棚卸し（個人情報、CMS、サーバ、DNS）
• 権限の整理（共有IDの解消、個人単位、最小権限）
• バックアップの対象・頻度・保管・世代の確認
• 監視の最低限導入（死活と主要フォームなど）
• 緊急連絡網と一次対応手順の作成

最小権限＝業務に必要な範囲に権限を絞る考え方です。

31〜60日：更新管理と変更管理を定例化する

2か月目は「事故の芽を増やさない」ための型を作ります。

• 定例更新（計画更新）のサイクル運用を開始
• 変更管理（誰が、いつ、何を変えたか）を記録する
• 外部委託の責任分界点とSLAを整理し、運用ルールに落とす
• 月次レポートの雛形を作り、KPIで会話する

変更管理＝サイトの変更内容を記録し、承認・反映・検証までを一連で管理することです。

61〜90日：復旧力を固め、改善サイクルにする

3か月目は「戻せる確証」を作ります。ここが固まると、経営判断が楽になります。

• 復元テストの実施と手順の修正
• 障害・改ざんを想定した机上訓練（連絡〜判断〜復旧の流れ確認）
• KPIを基に、次の90日での改善バックログを合意
• ベンダー切替や担当交代に備えた引き継ぎ台帳の整備

机上訓練＝実際にシステムを止めずに、想定シナリオで手順と判断を確認する訓練です。
バックログ＝今後対応すべき作業や改善を一覧化したリストです。

相談時に整理できると進行が速いもの

問い合わせや社内稟議につながるよう、状況整理の材料は最小限で構いません。例えば次が揃うと、責任分界と優先順位が決めやすくなります。

• サーバ、DNS、CMS、フォームの構成情報（分かる範囲で）
• 現在の保守契約の範囲（監視、更新、バックアップ、復旧のどこまでか）
• 管理権限の所在（誰が管理者か、委託先か）
• 直近の障害・改修履歴（分かる範囲で）

みやあじよでは、制作も運用も「問題解決」と捉え、成果を「売上・問い合わせ・採用」といった事業目的に接続して設計します。保守運用・セキュリティ対策・監視・バックアップ設計・復旧支援も、体制とKPIまで含めて“続く仕組み”として整えることが相談の中心になります。

まとめ

• Webサイトの情報セキュリティは、技術導入だけでなくガバナンス（ルール・権限・責任の統制）で被害の拡大を抑えます
• 最初に「守る対象」を棚卸しし、影響の大きい領域から優先順位を付けると投資判断がブレません
• 運用品質は、監視・更新管理・バックアップ・復旧の4点セットで作ります
• 外部委託は、責任分界点と定例報告を整えることでブラックボックス化を防げます
• KPIは稼働・品質・リスク・業務負荷の4系統で設計すると、経営が意思決定に使えます
• 90日を目安に、可視化→定例化→復旧力の順で固めると属人化しにくい運用に移行しやすくなります