サイトセキュリティリスク評価の進め方のアイキャッチ

NOTES

サイトセキュリティリスク評価の進め方

サイトセキュリティのリスク評価を経営目線で可視化し、個人情報を扱う企業の投資判断・体制・委託先管理の要点を整理。専任不在でも回る方法として、監視、バックアップ、復旧、更新管理の進め方を解説。

チップス

自社サイトの安全性が気になっても、サーバー、CMS、フォーム、権限、委託先のどこから確認すべきか迷います。診断ツールより先に、サイトを構成する対象と管理者を棚卸ししてください。対象ごとに事故シナリオを書き、影響度と起こりやすさを高・中・低で評価します。上位3件には担当者と7日以内の確認期限を置きます。判断材料がない項目は安全と決めつけず、保守会社への確認事項としてリスク台帳に残します。

この記事で扱うのは、専任担当者がいない中小企業向けの「60分で行う初回評価」です。技術的な脆弱性を網羅するのではなく、確認順と判断する人を決めます。IPAの中小企業向けガイドラインも、情報資産の洗い出し、リスクの算定、対策の決定という流れを示しています。情報処理推進機構+2情報処理推進機構+2

制作前に確認する要点は次のとおりです。

  • 対象と管理者を先に棚卸しする
  • 事故シナリオを対象ごとに書く
  • 影響度と起こりやすさを3段階で評価する
  • 上位3件に担当者と期限を置く

60分で作るサイトセキュリティのリスク台帳

対象の棚卸しから事故シナリオ、影響度、起こりやすさ、優先順位、担当と期限までを左から右へ示す評価フローを整理した図
初回評価の5工程と最終成果物のつながりを一目で理解できるようにするために、対象の棚卸しから事故シナリオ、影響度、起こりやすさ、優先順位、担当と期限までを左から右へ示す評価フローを整理しています。

完成させるのは、構成要素、事故、評価、優先順位、担当者、期限をまとめた1枚のリスク台帳です。社内と保守会社が同じ対象を見て動ける状態を目指します。

60分は、次の配分が目安です。

  1. 10分|対象と管理者を棚卸しする

ドメイン、サーバー、CMS、フォーム、外部連携、解析タグ、バックアップを書き出し、契約名義と管理者を記入してください。 2. 15分|対象ごとの事故シナリオを書く

停止、改ざん、不正ログイン、情報漏えい、復旧不能を、自社の問い合わせ、採用、顧客対応、信用への影響に置き換えます。 3. 10分|影響度を高・中・低で決める

売上機会、顧客対応、信用、許容できる復旧時間を基準に仮判定してください。 4. 10分|起こりやすさを高・中・低で決める

更新状況、権限、多要素認証、監視、バックアップ、委託先との責任分界を根拠にします。 5. 15分|上位3件の担当者と期限を決める

7日以内に何を確認するか、誰が回答を集めるか、何が分かれば完了かを記入する工程です。

事実がそろわない項目は「不明」または「保守会社へ確認」と記録します。影響が大きいのに情報がない項目は、上位3件の候補に残します。

脆弱性診断ツールは評価材料の一つです。契約名義、退職者の権限、フォーム停止の事業影響、復元可否までは決まらないため、ツールの実行とリスク評価の完了は分けて考えます。

工程1 サイトを構成する対象と管理者を棚卸しする

棚卸しでは「ホームページ」という一つの箱ではなく、止まる場所や管理権限が異なる単位に分けます。最低限、次の対象を確認してください。

  • ドメインとDNS:契約会社、契約名義、更新方法、登録メールアドレス
  • サーバー:利用サービス、管理画面へ入れる人、契約更新者、障害時の連絡先
  • CMS:WordPressなどの更新システム、管理者アカウント、プラグインやテーマ
  • フォーム:送信先、確認メール、保存される情報、外部フォームサービス
  • 外部連携:予約、決済、メール配信、地図、SNSなどの連携先
  • 解析タグ:アクセス解析、広告タグ、タグ管理ツールの管理者
  • バックアップ:対象、取得頻度、保管場所、保存期間、復元を担当する人

「管理者」も一人とは限りません。契約を更新できる人、管理画面へ入れる人、日常運用を担当する人、事故時に判断する人を分けて記入します。制作会社が操作できても、社内の誰も契約名義や連絡先を知らないなら、その状態自体を台帳に残します。

この段階で細かな設定まで調べる必要はありません。サービス名、管理画面、担当者、委託先が分かれば確認先を特定できます。契約者や管理者が不明な対象は後回しにしません。

工程2 対象ごとの事故シナリオを書く

「何となく危険」では判断できません。次の一文に当てはめ、事業への影響まで書きます。

「対象」で「どのような事故が起き」、その結果「どの業務や相手に、どのような影響が出るか」

たとえば、CMSであれば「管理者アカウントへ不正ログインされ、トップページが改ざんされる。その結果、閲覧者を不正なページへ誘導し、会社の信用を損なう」と書けます。フォームなら「送信エラーが発生しているのに気づかず、問い合わせや応募を受け取れない」となります。

バックアップは「取得している」だけで終えず、「正常な時点へ戻せず公開停止が長引く」と記録してください。ドメインなら更新不能、解析タグなら退職者や旧委託先の権限残存を事故に置き換えます。

一つの行には、一つの対象と一つの事故を記入します。停止、改ざん、不正ログイン、情報漏えい、復旧不能を、自社の売上機会、顧客対応、採用、信用へ翻訳してください。

IPAは、ウェブサイトの運営形態によって自社と外部サービスの担当範囲が異なり、ウェブアプリケーション、サーバー、ネットワークなど対象ごとの対策が欠けると安全性を確保できないとしています。サイト全体を一括で「保守済み」と見るのではなく、構成要素ごとに事故を考える理由はここにあります。情報処理推進機構+1

工程3 影響度を3段階で決める

影響度は技術的な難しさではなく、事故後の事業影響で決めます。次の四つを確認します。

  • 問い合わせ、販売、予約、採用などの機会が止まるか
  • 顧客や応募者への連絡、説明、謝罪が必要になるか
  • 個人情報や公開情報の扱いによって信用を損なうか
  • 復旧にかかる時間が、自社の許容範囲を超えるか

は、個人情報、サイト全体の停止、会社名での不正公開、復旧不能など、顧客や信用への影響が大きい場合です。は影響が一部に限られ、代替手段はあるものの業務の遅れが出る状態、は範囲が限定され、短時間で戻せる根拠がある場合です。

迷ったときは、四つの観点のうち最も重いものに合わせます。売上への影響が小さくても、個人情報の漏えいや会社名を使った改ざんが想定されるなら、影響度を低くしません。IPAの第4.0版も、顧客や個人への大きな影響、法的責任、事業への深刻な影響が考えられる場合は、重要度を高く扱う考え方を示しています。情報処理推進機構+1

高・中・低は仮判定です。判断理由を台帳へ残し、フォームの保存内容や復元時間が分かった時点で更新します。

工程4 起こりやすさを3段階で決める

起こりやすさは、攻撃件数を予測するものではありません。現在の管理状態に、事故を防ぐ根拠がどれだけあるかを見ます。確認するのは、CMSやプラグインの更新、管理者権限の人数、多要素認証、異常を見つける監視、バックアップと復元確認、委託先との担当範囲です。

多要素認証とは、パスワードに加えて確認コードなどを使う認証方法です。未対応のサービスでは、使い回さないパスワード、不要アカウントの停止、接続元制限などを確認します。

本記事では、IPAが示す3段階の重要度と被害発生可能性の考え方を、サイトの初回評価で使いやすい「影響度」と「起こりやすさ」に置き換えます。数値は精密な発生確率ではなく、確認順をそろえるための共通言語です。情報処理推進機構+1

影響度と起こりやすさの3段階判定表
段階影響度の目安起こりやすさの目安次の判断
顧客・個人・信用・主要業務への影響が大きく、復旧の見通しも立ちにくい未更新、共有権限、認証不足など、事故につながる管理状態が確認できる担当者を置き、7日以内に事実確認と対応判断を行う
一部業務に影響し、代替手段はあるが、対応の遅れや機会損失が出る対策は一部確認できるが、重要項目が不明、または委託先の役割が曖昧7日以内に不足情報を集め、再評価する
影響範囲が限定され、重要情報を扱わず、復旧方法も確認済み必要な対策の実施記録があり、管理者と確認日も分かる台帳に根拠を残し、定期見直しの対象にする

この表で決めるのは、「低と見なせる証拠があるか」です。設定画面、管理者一覧、更新履歴、監視通知、バックアップ履歴、復元記録、保守報告などを確認できなければ、安易に低へ下げません。

保守会社から「対応しています」と回答を受けた場合も、対象と確認日を聞きます。バックアップならファイルとデータベースのどこまで含むかを確かめ、事故シナリオに対する根拠がそろったかで評価します。

工程5 上位3件の担当者と期限を決める

優先順位は、影響度と起こりやすさの組み合わせで並べます。最初は「高×高」を最上位とし、続く確認対象は「高×中」「中×高」です。同じ組み合わせが複数ある場合は、顧客情報に関わるもの、外部から改ざんが見えるもの、復元手段が確認できないものを先に置きます。

高を3点、中を2点、低を1点として掛け合わせても構いませんが、点数は並べ替えの補助です。同点なら事故シナリオを読み直して決めます。

上位3件には、次の三つを必ず記入します。

  • 担当者:回答を集め、社内で判断を完了させる人
  • 確認期限:原則として初回評価から7日以内
  • 完了条件:どの資料や画面を確認し、何が分かれば完了か

委託先が作業する場合も、担当者欄を「保守会社」だけにしません。社内側に、依頼内容を決め、回答を受け取り、対応を承認する人を置きます。

7日以内に求めるのは改修完了ではなく、「更新対象と実施者」「不要な管理者」「バックアップ範囲と復元実績」などの事実確認と対応方針です。改修が必要なら別の期限と予算を置きます。

そのまま使えるリスク台帳の記入例

影響度と起こりやすさの高・中・低を組み合わせ、優先確認、期限を決める、記録して見直すの3領域へ分ける判断図を整理した図
影響度と起こりやすさから上位3件を選ぶ関係を視覚的に理解できるようにするために、影響度と起こりやすさの高・中・低を組み合わせ、優先確認、期限を決める、記録して見直すの3領域へ分ける判断図を整理しています。

以下は、一般的な企業サイトを想定した記入例です。実際には、自社が利用しているサービス名、管理画面、担当者名へ書き換えてください。

サイトセキュリティのリスク台帳
対象・事故シナリオ影響度・起こりやすさ優先順位担当者・期限
CMS|共有管理者が不正利用され、ページを改ざんされる高・高。共有ID、認証方法、最終更新日が不明1Web担当者|7日以内に管理者一覧と認証設定を確認
バックアップ|改ざん後に正常な状態へ戻せず、公開停止が長引く高・中。自動取得の説明はあるが復元記録がない2情報システム責任者|7日以内に対象範囲と復元実績を確認
フォーム|送信停止に気づかず、問い合わせや応募を受け取れない高・中。稼働監視と定期送信テストが未確認3営業責任者|7日以内にテスト送信と通知先を確認
解析タグ|旧委託先の権限が残り、設定を変更される中・中。管理者一覧を最近確認していない4Web担当者|次回月次確認で不要権限を整理
ドメイン|更新手続きができず、サイトが表示されなくなる高・低。自動更新、決済手段、契約名義を確認済み継続監視総務担当者|更新前に登録メールを再確認

この表では、上位3件だけに7日以内の具体的な確認を置いています。四件目以降も消さず、確認時期と根拠を残すことで、次回の見直し時に再評価できます。

自社版では、「共有IDで多要素認証が未確認」「復元記録がない」のように評価理由を一言添えます。この一言が、保守会社への具体的な質問です。

自社だけで分からない項目を保守会社へ確認する

保守会社には「安全ですか」と広く尋ねず、リスク台帳の対象と事故シナリオを添えます。資料、画面、対象範囲、確認日まで指定すると再評価しやすくなるでしょう。

確認事項は、次のチェックリストへまとめられます。

  • 管理権限:ドメイン、サーバー、CMSの契約名義と管理者は誰か。不要なアカウントは残っていないか
  • 更新状況:CMS、プラグイン、テーマ、サーバー側ソフトウェアの更新対象、最終実施日、実施者は誰か
  • バックアップ範囲:ファイル、データベース、フォーム情報のどこまでを、どの頻度と保存期間で取得しているか
  • 復元確認:最後に復元できることを確かめたのはいつか。復元を開始する条件と担当者は誰か
  • 監視:サイト停止、フォーム送信失敗、不正ログイン、改ざんなど、何をどの方法で検知しているか
  • 緊急連絡先:事故時の連絡手段、受付時間、初動担当、社内が提供すべき情報は何か
  • 保守範囲:契約内で行う作業、対象外の作業、報告内容、自社側が行う作業は何か

IPAは、外部委託時には委託先の責任と実施する対策を契約で明確にし、外部サービスの利用条件も確認するよう示しています。回答が「契約外」であれば、その項目を消すのではなく、自社で対応するか、別の支援先へ依頼するかを決める材料にします。情報処理推進機構+1

保守範囲、責任分界、報告内容、対応時間を契約へ落とし込む段階では、WordPressの保守契約とSLAの決め方も確認してください。本記事のリスク台帳があれば、「何を守ってほしいか」「事故時にどこまで対応してほしいか」を具体化しやすくなります。

回答待ちには、依頼日、回答者、期限、受け取る証拠を記録します。不明は直ちに脆弱性を意味しませんが、判断材料の欠落を放置しないことが初回評価の目的です。

まとめ

サイトセキュリティの初回評価では、対策製品を先に選ぶのではなく、対象と管理者を棚卸しし、対象ごとの事故シナリオを作ります。影響度と起こりやすさを3段階で仮判定したら、上位3件に社内担当者、7日以内の確認期限、完了条件を置いてください。

今日決めるのは、最初に確かめる3件と判断を完了させる人です。不明点を台帳に残して保守会社へ渡せば、確認範囲と責任分界を具体的に相談できます。

参考資料