サイトセキュリティリスク評価の進め方 | 大阪府堺市・東京のWEBサイト制作会社

経営者・情報システム責任者が行うリスク評価は、技術の点検ではなく「事業の損失を減らすための意思決定」です。リスク評価とはサイトで起こり得る事故を洗い出し、影響と起こりやすさを整理して、対策の優先順位と運用方針を決める作業です。

サイトセキュリティのリスク評価を経営で行う意味

守るべき対象はサイトの目的と信用

コーポレートサイトは、問い合わせ・採用・資料請求などの入口であり、止まる、改ざんされる、情報が漏れると、売上機会だけでなく信用にも直結します。

経営判断に必要なのは3つの翻訳

専門部署でない経営層でも判断できるよう、リスクを次の3要素に翻訳します。

影響度：発生した場合の損害の大きさ（機会損失、信用低下、復旧工数など）
発生可能性：起こりやすさ（弱点の放置、運用のばらつきなどで変動）
検知と復旧の速度：早く気づき、早く戻せるか

期待損失＝影響度と発生可能性を組み合わせて、平均的に見込まれる損失を見積もる考え方と定義します。金額が出せない場合でも、影響を段階（大・中・小）で置き、優先順位の合意に使えます。

ここでいう影響度は、金額だけに限定しません。停止による商談機会の減少、採用応募の取りこぼし、顧客への説明コストなど、事業運営の負担も含めて評価します。

評価は「運用の設計図」まで落とすと価値が出る

評価だけを作っても、監視がない、更新が遅れる、復旧手順が曖昧のままでは、同じ事故が繰り返されます。監視＝サイトやサーバーの状態を継続的に見張り、異常兆候を検知する運用と定義します。
本記事では、評価の結果を「更新管理」「監視」「バックアップ」「復旧支援」に接続するところまでを、経営目線で整理します。

評価範囲を決める：資産・情報・委託先の棚卸し

範囲が曖昧だと、抜け漏れと責任の空白が生まれる

サイトはトップページだけではありません。フォーム、CMS（コンテンツ管理システム＝Webサイトのページや記事を管理・更新する仕組み）、機能追加のプラグイン（CMSに機能を追加する拡張機能）、解析タグ、外部システム連携など、事故の入口は広がっています。
まずは「何を守るか」を決めます。資産＝事業価値があり、失うと損害につながるシステム・データ・設定一式と定義します。

棚卸しの観点は3つ

どの資産があるか（ドメイン、サーバー、CMS、外部サービス）
どんな情報を扱うか（顧客情報、採用応募、問い合わせ内容、メールアドレスなど）
誰が触れるか（社内担当、外部ベンダー、複数委託先）

対象	具体例	主なリスク	責任部門
ドメイン	管理会社・設定情報	乗っ取り、改ざん誘導	情報システム
サーバー	クラウド/レンタル、管理画面	不正侵入、停止	情報システム・委託先
CMS	管理画面、編集権限	不正ログイン、改ざん	Web担当
プラグイン	フォーム、各種連携	脆弱性悪用	Web担当・委託先
フォーム	問い合わせ、採用	個人情報漏えい	事業部
メール送信	送信設定、認証	なりすまし、未達	情報システム
解析タグ	計測タグ、広告タグ	不正混入	マーケティング
外部連携	予約、顧客管理	データ流出、停止	事業部
バックアップ	世代、保管先	復元不能	情報システム・委託先
監視	稼働監視、改ざん検知	発見遅延	情報システム・委託先

委託先を含めて「誰が何に責任を持つか」を先に固定する

外部ベンダーが複数いる場合、障害時に「どこまでが保守範囲か」が曖昧になりやすい状態です。ここでいう責任分界＝社内と委託先の担当範囲、連絡先、判断権限を切り分けたものと定義します。
棚卸しの段階で、管理者アカウントの所在、緊急連絡先、契約範囲（監視の有無、復旧対応の有無、更新の頻度）まで把握しておくと、後工程の優先順位付けが現実に即したものになります。

リスクを見える化する：脅威と弱点の洗い出し

脅威は「起きる事象」で整理する

脅威＝サイトに損害を与える可能性のある攻撃や事故のシナリオと定義します。Webサイトで多い脅威は、たとえば次の通りです。

改ざん：ページやファイルが不正に書き換えられる
不正ログイン：管理画面が乗っ取られ、設定やコンテンツが変更される
情報漏えい：フォームや管理画面から個人情報が流出する
マルウェア配布：利用者に害のあるコードを配る踏み台にされる
サービス停止：障害や攻撃で閲覧・送信ができなくなる

マルウェア＝利用者や端末に害を与える悪意あるソフトウェアの総称と定義します。

弱点は「起きる原因」で整理する

弱点＝脅威が現実になる入口となる欠陥や運用上の隙と定義します。代表例は、更新の遅れ、不要な権限の放置、パスワード管理の甘さ、バックアップの未検証、担当者依存の手順などです。
脆弱性＝攻撃者に悪用される欠陥と定義します。脆弱性はゼロにできませんが、放置期間と露出範囲を小さくする運用で、発生可能性は下げられます。

見える化の成果物はリスク登録簿

リスク登録簿＝リスク項目を一覧で管理し、優先順位と対応状況を追える台帳と定義します。最低限、次の項目を揃えると経営判断に使えます。

リスク名（脅威×対象）
影響度（事業への影響の説明）
発生可能性（現状の弱点と根拠）
現在の対策と不足
次のアクション（誰が、いつまでに）

優先順位付け：影響度と発生可能性で決める

影響度は「事業の言葉」に置き換える

影響度を上げる要因は、個人情報を扱うフォーム、採用応募の受付、見込み顧客の獲得など、サイトが事業プロセスに直結していることです。影響の説明は、金額が出せない場合でも、次の観点で整理できます。

停止：問い合わせ・応募が止まり、機会損失が生まれる
改ざん：信用が毀損し、説明と復旧に工数が発生する
漏えい：連絡・再発防止・関係者対応の負担が増える

発生可能性は「運用の現実」で決まる

発生可能性は、技術よりも運用のばらつきに影響されます。更新の担当者が固定、緊急時の連絡が一本化されていない、委託先の作業報告がないといった状態では、弱点の放置期間が伸びます。
逆に、更新管理が定例化され、監視で異常に早く気づける体制なら、同じ脅威でも損害は小さくなります。

優先順位が決まると「次の一手」がブレなくなる

優先順位は、対策の順番だけでなく、どこまでを外部委託するか、どの指標を報告するかにもつながります。

対策の選択肢と期待効果：どこまでやるかの基準

リスク評価の次は「上位リスクに対して、何を入れると損害が減るか」を決めます。対策は大きく、予防・検知・復旧の3層で考えると、経営判断に落とし込みやすくなります。予防＝事故が起きる確率を下げる施策、検知＝事故を早く見つける施策、復旧＝起きた後に早く元に戻す施策と定義します。

効果を説明するなら「確率」と「損害」のどちらを下げるか

同じ対策でも、効き方が違います。経営報告では、次の4つのどれを狙う投資かを言い換えると合意が取りやすくなります。

発生可能性を下げる：不正ログインや侵入の確率を下げる
影響度を下げる：侵入されても漏えい範囲や停止範囲を小さくする
検知を早める：被害拡大前に気づく
復旧を早める：停止時間と説明コストを減らす

「予防だけ」や「復旧だけ」に偏ると、想定外の事故で詰まりやすいので、上位リスクほど3層を組み合わせるのが現実的です。

まず押さえるべきは「事故を小さくする」設計

中小〜中堅規模のWeb運用では、攻撃をゼロにするより、被害が広がる前に止めて戻す設計が現実的です。特に個人情報を扱う企業サイトでは、次の4点が基礎になります。

更新管理：CMSやプラグインの更新を計画的に適用し、放置期間を短くする
権限管理：管理画面の権限を必要最小限にし、退職・異動の棚卸しを定例化する
監視：稼働監視と改ざん兆候の検知で、発見の遅れを減らす
バックアップと復旧手順：復元できる設計と、手順の確認で停止時間を短くする

権限管理の中で多要素認証（MFA）＝パスワードに加えて別の要素で本人確認する仕組みと定義します。MFAは不正ログインの発生可能性を下げ、運用が属人化していても効果が出やすい領域です。

「更新管理」は技術より運用の仕組みが重要

更新作業そのものより、更新できない状態がリスクになります。たとえば制作時のカスタマイズが大きいと、更新で表示崩れが起きやすく、結果として更新が止まりがちです。ここで変更管理＝更新や改修の手順・承認・記録を揃えて安全に反映する運用と定義します。
変更管理の最小セットは、(1)事前バックアップ、(2)影響範囲の確認、(3)更新後チェック、(4)不具合時の戻し方、の4つです。不具合時の戻し方をロールバック＝更新前の状態へ戻す手順と定義します。

「どこまでやるか」を決める判断軸

経営としては、対策の深さを一律に上げるより、サイトの役割と情報の重みで線引きすると納得感が出ます。判断軸の例は次の通りです。

取り扱う情報：問い合わせだけか、採用応募・顧客データまで扱うか
停止許容：RTO（目標復旧時間）をどの程度に置くか
変更頻度：更新が多いほど、更新管理と検知の重要度が上がる
外部連携：連携が多いほど、責任分界と復旧設計の難易度が上がる
運用体制：兼務で回すなら、自動化と定例化の比重を上げる

追加で検討されやすい対策群

上位リスクが「改ざん」「不正ログイン」「停止」に偏っている場合、次の対策が候補に入ります。

WAF：Web Application Firewall＝不正なリクエストを検知・遮断する仕組み
CDN：Content Delivery Network＝コンテンツを分散配信し、負荷と停止リスクを下げる仕組み
改ざん検知：ファイルやページの差分を監視し、異常を知らせる仕組み
ログ監視：アクセスや管理操作の記録から不審な動きを検知する運用
脆弱性診断：Webサイトの欠陥を点検し、優先度付きで改修につなげる取り組み

DDoS攻撃＝大量のアクセスでサービスを使えない状態にする攻撃と定義します。DDoSが懸念される場合は、CDNや上流の防御も含めて設計します。

よくある落とし穴：バックアップがあっても戻せない

バックアップがあっても、復元手順が曖昧だったり、必要な範囲（ファイル、データベース、設定）が揃っていなかったりすると、停止時間が伸びます。復元テスト＝バックアップから実際に復元できるか確認する作業と定義します。復元テストは、経営が求めるRTOを満たせるかどうかの検証でもあります。

費用と投資判断：TCOで比較し、段階導入する

対策の費用は、導入費だけでなく継続運用の人件費・委託費が効いてきます。TCO＝導入後の運用費も含めた総コストと定義します。経営判断では、次の3つを分けて見積もると比較がしやすくなります。

平時コスト：更新管理、監視、バックアップ運用、レポートなど
有事コスト：調査、復旧、再発防止、社内外の説明対応
機会損失：停止や信用低下による問い合わせ・応募の減少

「スポット対応」より「定例運用」が効く場面

スポット対応だけで回していると、事故のたびに委託先の手配・状況共有・暫定対応が発生し、復旧が遅れやすくなります。さらに、担当者が交代すると履歴が引き継がれず、同じ論点を繰り返しがちです。
一方で保守運用を組むと、更新・監視・復旧の前提が揃い、MTTR（平均復旧時間）を短くする方向に投資ができます。事故が起きる前から「誰が何を見るか」が決まっていること自体が、発生可能性と影響度の両方を下げます。

対策カテゴリ	期待効果	運用負荷	予算の考え方
更新管理（CMS/プラグイン）	脆弱性の放置期間を短縮	定例作業が必要	月次の定例枠で平準化
権限管理・MFA	不正ログインの確率低減	棚卸しが必要	初期整備＋四半期見直し
監視（稼働/改ざん兆候）	発見遅延を低減	通知設計が必要	監視範囲で変動
バックアップ＋復旧手順	停止時間と損害を抑制	復元確認が必要	設計費＋定期テスト
WAF/CDN	攻撃影響の低減、負荷分散	設定と運用の調整	月額＋初期設定
脆弱性診断	欠陥の優先度整理	改修の工数が発生	年次・リニューアル時に実施

対策オプションの比較表

見積り比較で見るべきポイント

金額だけで比べると、重要な抜けが起きます。比較では次の観点を揃えます。

対象範囲：ドメイン、サーバー、CMS、フォーム、メール送信、外部連携まで含むか
対応時間：平日日中のみか、時間外の一次対応があるか
復旧の範囲：原因調査、暫定復旧、恒久対応まで含むか
報告の粒度：月次で更新状況、検知状況、課題が出るか

段階導入で「守りの穴」を先に塞ぐ

投資は、上位リスクに効く順に段階化すると進めやすくなります。たとえば次のように進めると、兼務体制でも回しやすい構成になります。

フェーズ1：棚卸し、MFA、更新管理の定例化、バックアップの復元確認
フェーズ2：監視の整備（稼働・改ざん兆候・通知先）、復旧手順書の整備
フェーズ3：WAF/CDNやログ監視の拡張、診断と改善サイクルの定着

この順番にする理由は、フェーズ1と2で「起きやすさ」と「戻しやすさ」を同時に改善し、経営として許容しにくい停止や漏えいのリスクを先に下げられるためです。

体制と運用フロー：更新管理・監視・復旧の役割分担

セキュリティ運用は、売上・問い合わせ・採用といった目的を守るための問題解決です。

兼務でも回すための最小役割

専任が置きにくい規模では、人数より「責任の置き方」を決めます。

事業オーナー：RTO/RPOの目安、予算、優先順位を承認する
運用責任者：資産台帳、権限、委託契約、連絡網を統括する
更新担当：変更依頼の取りまとめ、更新後の確認を行う
技術実務（社内または委託先）：更新適用、監視、バックアップ、復旧を実行する

「運用責任者」は作業者ではなく、止めない仕組みの責任者です。ここが曖昧だと更新・復旧が属人化します。

定例フローと緊急フローを分けて設計する

運用が崩れる原因は、緊急対応が平時の更新や点検を押し流すことです。あらかじめ2つの流れを分けます。

定例フロー：更新管理、アカウント棚卸し、バックアップ確認、月次レポート
緊急フロー：異常検知→一次対応→復旧→原因整理→再発防止

一次対応＝被害拡大を止め、状況を把握して次の判断につなげる初動と定義します。

インシデント時の初動を「判断ごと」標準化する

インシデント＝セキュリティ事故や障害など、通常運用を逸脱する出来事と定義します。初動は手順より判断ポイントをそろえると、経験差が出にくくなります。

影響範囲：閲覧のみか、フォーム送信や管理画面まで影響するか
一時措置：公開停止、管理画面の遮断、パスワード変更などの判断
記録：時刻、現象、対応内容を残す（説明と原因整理の土台）
連絡：社内の意思決定者と委託先へ共有し、窓口を一本化する
復旧：ロールバックや復元で、RTO内に戻す道筋を選ぶ

外部委託とベンダー管理：SLAと報告の設計

外部委託は“作業”ではなく“運用の継続性”を買う

外部委託の価値は、更新・監視・復旧を定例化し、担当者が変わっても品質を保てる点にあります。委託先が複数ある場合は、緊急時の窓口と責任分界が分散しやすいため、統制の設計が欠かせません。

SLAで合意すべき項目

SLA＝対応時間、復旧目標、報告内容などのサービス水準を定める合意事項と定義します。合意しておきたい代表項目は次の通りです。

対応時間帯：時間外の一次対応の有無
着手目標：重大度（高・中・低）ごとの着手までの目安
復旧範囲：暫定復旧と恒久対応の切り分け、RTO/RPOとの整合
更新管理：頻度、影響確認、ロールバック方針、作業報告
監視：監視対象、通知先、上位連絡の条件
バックアップ：取得範囲、世代、保管、復元テスト頻度
成果物：月次レポート、作業ログ、インシデント報告書

月次レポートを“経営の材料”にする

月次レポートは、作業記録ではなく次月の投資判断の材料です。最低限、次の4点が並ぶと意思決定が速くなります。

今月のリスク変化：高リスク項目の増減と理由
実施内容：更新適用、設定変更、復元テストの状況
監視状況：重大アラート件数、一次対応までの時間、再発の有無
次月計画：残課題と対応順、追加予算が必要な項目

タスク	社内責任	委託先責任	成果物
資産台帳・契約管理	運用責任者	補助（情報提供）	台帳、契約一覧
権限・MFA管理	運用責任者	設定支援	権限一覧、変更履歴
更新管理（CMS等）	更新担当	更新適用・検証	更新報告、差分記録
監視（稼働/改ざん兆候）	運用責任者	監視設定・一次対応	アラート履歴
バックアップ運用	運用責任者	設計・取得・保管	取得ログ、世代一覧
復元テスト	運用責任者	実施・手順更新	テスト結果、手順書
緊急対応（障害/事故）	事業オーナーが判断	調査・復旧	インシデント報告書
月次レポート	運用責任者がレビュー	作成	月次報告書

運用体制と委託先管理の役割分担表

KPIと定例レビュー：リスクを継続的に下げる運用

KPIは「予防・検知・復旧」を分けて置く

KPI（重要業績評価指標）は、運用を継続するための合意ツールです。3層で分けて指標化すると、改善点が見えやすくなります。

予防：更新の遅れ（日数）、管理者アカウント棚卸し、MFA適用率
検知：重大アラートの一次対応までの時間、誤検知の割合
復旧：MTTR、RTO達成率、復元テストの実施と改善消化

重大な更新ほど対応を早める方針を置くと、運用の優先順位がブレにくくなります。

定例レビューの型を作ると属人化が減る

月次レビューは、確認項目を固定すると効果が出ます。

リスク登録簿の上位項目：未対応の理由と次の一手
KPI：目標未達の要因（体制、契約範囲、手順不足など）
次月計画：更新予定、復元テスト予定、改善タスク
体制課題：窓口一本化、手順書更新、委託範囲の見直し

四半期に一度、資産棚卸しと権限棚卸しをセットで実施すると、抜け漏れの増殖を抑えられます。

まとめ

サイトセキュリティのリスク評価（経営）は、優先順位と運用（更新管理・監視・バックアップ・復旧）に接続して初めて投資価値が出ます。
兼務体制になりやすい企業ほど「定例と緊急の分離」「SLAと月次レポートによる統制」「予防・検知・復旧のKPI化」が、属人化と対応遅延の抑制に効きます。

保守運用やセキュリティ運用の相談を行う場合、次の情報を整理しておくと、現状把握と提案の精度が上がります。

対象サイトの目的（問い合わせ、採用、資料請求など）と停止許容（RTO/RPOの目安）
ドメイン・サーバー・CMS・外部連携の一覧（分かる範囲で）
管理者アカウントの管理状況（MFAの有無、権限棚卸し状況）
バックアップの取得範囲と復元確認の実施状況
直近の障害や改ざん等の履歴（あれば）