Google AnalyticsのSafe Browsing通知はWebmaster Toolsで問題箇所を確認して対処する

Google AnalyticsにSafe Browsingの通知が表示されたら、アクセス数の変化を調べる前に、Webmaster Toolsで問題の種類と検出されたURLを確認してください。Analyticsの通知は、サイトの問題を発見する入口です。修復場所を特定する画面や、安全になったことを確定する機能ではありません。

担当者は、通知を閉じるだけで済ませず、サイト所有者、サーバー管理者、制作担当者へ同じ内容を渡します。利用者へ危険が及ぶ可能性があるため、通常の解析レポートより対応を優先します。

Analyticsの通知とSecurity Issuesは役割が違う

GoogleのSafe BrowsingとGoogle Analyticsに関する説明では、Safe Browsingで問題が見つかったサイトについて、Google Analyticsの通知欄にも自動で知らせる仕組みが案内されています。

一方、問題の調査にはWebmaster Toolsを使います。Security Issuesの公式説明では、問題の種類、分かる場合のURL例、最後に検出した日を確認できます。コード断片が示される場合もあります。

二つの画面は、次のように分けます。

Analyticsの閲覧権限を持つ人が、サーバーを直せるとは限りません。通知を受ける人と、修復できる人を先に対応表へ入れておきます。

最初に対象サイトと検出例をそろえる

複数のサイトやプロパティを管理している場合は、どのサイトへの通知かを確定します。似たドメイン、wwwの有無、HTTPとHTTPSを思い込みでまとめないでください。

次に、Security Issuesで次の情報を記録します。

• 問題の種類
• 表示されたURL例
• 最後に検出された日
• 表示されたコード断片

URL例は、被害の全件一覧とは限りません。一件だけ直して終えるのではなく、同じ仕組みで生成されたページ、共通テンプレート、プラグイン、サーバー設定にも範囲を広げます。

表示上の異常と侵入原因を分けて直す

改ざんされた文字列やリンクを消す作業と、侵入を許した原因を閉じる作業は別です。見える異常だけを削除しても、同じ入口が残れば再び変更されるおそれがあります。

Googleは、サイトを修復した後だけでなく、セキュリティ上の穴を閉じてから審査を依頼するよう案内しています。CMS本体、追加機能、テーマ、管理用アカウント、サーバー設定のうち、どこが変更されたかを確認します。

制作会社へ修復を依頼する場合は、作業範囲を「警告を消す」だけにしないでください。検出例の確認、影響範囲の調査、改ざん箇所の除去、原因への対策、審査依頼、再発確認を分けます。

修復前の状態を残してから変更する

変更を始める前に、復旧用のデータと調査用の記録を分けて残します。安全な時点のバックアップがある場合も、現在の状態を上書きせずに保存します。現在のファイルや記録は、どこを変更されたかを調べる材料になるためです。

ただし、危険なサイトをそのまま公開し続ける理由にはなりません。利用者への影響を抑える措置と、調査用記録の確保を並行できるよう、サーバー管理者と手順を決めます。

復旧作業の前後では、次を混同しないでください。

1. 調査用に現在の状態を保存する
2. 利用者への危険を抑える
3. 改ざん箇所を除去する
4. 侵入原因へ対処する
5. 動作を確認して審査を依頼する

審査依頼は修復完了の代わりではない

Security Issuesから審査を依頼できても、依頼した時点でサイトが安全になったわけではありません。修復と原因除去を終えた後に、Googleへ再確認を求める工程です。

アクセス解析担当者は、通知を発見して関係者へ渡した日時を記録します。サイト所有者は、利用者への案内と復旧判断を持ちます。サーバー管理者と制作者は、調査した場所、変更したファイル、更新したソフトウェア、残った不確実性を返します。肩書ではなく、実際に確認できる範囲で責任を分けてください。

最初の一手は、Analyticsの通知文を保存し、対象サイトを確定して、Webmaster ToolsのSecurity Issuesを開くことです。表示された問題の種類とURL例を、修復を担当する人へそのまま渡してください。