クリニックのGoogleビジネスプロフィール乗っ取り対策｜2段階認証と権限点検

関連ページ

• 管理者追加と権限管理
• オーナー権限リクエスト
• Googleによる更新
• プロフィールID確認

クリニックのGBPで起きやすい権限事故

Googleビジネスプロフィールは、医院名、診療時間、電話、ウェブサイト、口コミ返信など患者の来院判断に直結する情報を変更できます。共有パスワード、退職者の権限、偽サポート、外部業者の主オーナー化は、単なるSNS事故より大きな業務影響を生む可能性があります。

管理者権限を渡す判断基準

編集者・管理者で足りない業務もあります。サイト設定、ユーザー管理、プラグイン、構造化データなどPDCA全体を担当する者には、WordPress管理者やGBPオーナー相当の権限が必要になる場合があります。重要なのは「管理者は常に危険」ではなく、業務範囲、本人確認、責任、期限、監査をそろえて付与することです。

• 何を変更するためにその権限が必要か
• より低い役割では完了できないか
• 付与開始日と見直し日を決めたか
• 医院側の主オーナー・管理者が別に残るか
• 操作記録と緊急停止方法があるか
• 契約終了・退職時の削除担当が決まっているか

自動運用用のアカウントを作る場合も、個人の普段使いアカウントと混同せず、利用目的、保護方法、復旧責任者を決めます。秘密情報を記事、公開台帳、Git、ログへ書きません。

初期設定の手順

偽サポート・フィッシングの見分け方

「プロフィールが停止される」「確認コードを教えて」「このリンクから今すぐログイン」と急がせる連絡は、その場で従いません。送信者表示だけで正規と判断せず、メール内リンクを使わずにGoogleの公式管理画面を直接開き、同じ通知があるか確認します。

• パスワード、2段階認証コード、復旧コードを求めていないか
• 不自然なドメインや短縮URLではないか
• 料金を払えば停止解除・順位上昇を保証していないか
• 遠隔操作ソフトの導入を急がせていないか
• 医院名・住所・対象プロフィールが正確か

不正アクセスが疑われる場合

1. 安全な端末からGoogleアカウントのセキュリティ状態を確認する
2. 不審なセッション、端末、アプリ連携を確認する
3. パスワードと2段階認証、復旧情報を見直す
4. GBPのオーナー・管理者一覧を確認する
5. 医院名、住所、電話、URL、診療時間、口コミ返信の変更を記録する
6. 院内責任者と必要な専門家へ共有する

WordPressとGBPの権限を分けて管理する

WordPress管理者とGoogleビジネスプロフィールのオーナーは別の権限です。片方を渡したから自動的にもう片方へ入れるわけではありません。作業に必要なシステムだけへ個別に付与し、アカウントと責任を台帳で区別します。

日常のWordPress記事公開をブラウザで行うなら、ログインセッションと管理者権限を使えます。REST APIやGitHubを挟む必要はありません。一方、ブラウザセッションは永続保証ではないため、再ログイン手順と権限責任者は残します。秘密情報を通常の本文やログへ保存しません。

退職・契約終了の手順

• 最終作業日を待たず、終了日時を決める
• GBP、WordPress、予約、解析、メール等を一覧化する
• 担当者の個別権限を削除する
• 共有物や復旧手段を医院側へ戻す
• 重要情報の変更履歴を確認する
• 公開側の医院情報を最終確認する

削除後は、医院側の管理者が必要な操作を行えるかをテストします。業者のアカウントを残したまま「使わない約束」にせず、不要な権限は実際に削除します。

28日・56日・90日の点検

28日後は管理者一覧、2段階認証、復旧手段を確認します。56日後は外部業者・一時担当者の必要性、連携アプリ、WordPress管理者を棚卸しします。90日後は不正時の連絡網と復旧演習を行い、主担当不在でも医院が管理を継続できるかを確認します。

アカウント安全管理のFAQ

外部業者へ管理者権限を渡してもよいですか？

業務上必要ならあり得ます。目的、期間、本人確認、操作範囲、監査、削除手順を決め、医院側の主オーナーを残します。

同じパスワードをスタッフ全員で使えますか？

操作追跡と退職対応が難しくなります。個別アカウントを招待し、役割で管理します。

確認コードを制作会社へ送ってよいですか？

ログインや復旧のコードは共有しません。正式な権限付与機能を使います。

APIを使わない運用でも安全対策は必要ですか？

必要です。ブラウザログインでも、権限、2段階認証、復旧、セッション、退職者削除を管理します。

秘密情報を扱う院内ルール

どうしてもパスワードやアプリケーションパスワードを保管する必要がある場合、一般のチャット、メール本文、記事下書き、スプレッドシート、GitHubへ平文で貼りません。医院が承認したパスワード管理手段を使い、閲覧できる担当者と復旧方法を限定します。

秘密情報をチャットで一度送ったから永続的に全実行へ引き継がれるとは限りません。会話履歴と実行環境の秘密保管は別です。定期運用では、ブラウザの認証セッションが有効かを開始前に確認し、失効時の再ログイン手順を用意します。

月次権限監査のチェックリスト

• 医院側の主オーナーが残っている
• 管理者全員の氏名・所属・目的が説明できる
• 退職者、旧業者、終了プロジェクトの権限がない
• WordPress管理者とGBP管理者を別に確認した
• 不明な端末・セッション・アプリ連携がない
• 重要項目に意図しない変更がない
• 復旧責任者が現在も在籍し連絡可能である

監査結果には確認日、確認者、削除した権限、保留理由、次回確認日を残します。秘密そのものは台帳へ書きません。必要な権限を残す場合も「業者だから」ではなく、具体的な作業と終了条件を記録します。

復旧テストを本番事故前に行う

主担当が不在でも、医院側の別管理者がGBPとWordPressの管理画面を開き、公開情報を確認できるかを安全にテストします。パスワードを変更するなど破壊的な操作は行わず、ログイン経路、2段階認証、復旧責任者、サポート窓口を確認します。

テストで入れないことが分かった場合、事故が起きる前に所有権・管理者・復旧手段を整理します。外部業者しか入れない状態は、日常運用が動いていても事業継続上のリスクです。