広告アカウントの乗っ取り対策2段階認証やパスキーがあっても突破される理由と、被害を小さく抑える設定・体制・初動

経路1：ブラウザ拡張機能からCookieを抜かれる

翻訳、スクリーンショット、広告の表示確認、SEOチェックといった便利な拡張機能は、閲覧中のページを読み書きする権限を持っています。開発元がまともでも、自動更新で不正なコードが紛れ込んだり、拡張機能ごと別の会社に買い取られて悪意のある機能を足されたりする例は珍しくありません。Cookieを外部へ送られれば、攻撃者は自分のパソコンから「ログイン済みのあなた」として管理画面に入れます。このとき2段階認証は求められません。

経路2：外部ツールに渡した認証情報を盗まれる

レポートツール、自動入札ツール、入稿ツール、BIツールなどは、Google広告APIの認証トークン（リフレッシュトークン）を預かって動いています。トークンは一度発行すると、取り消すまで有効なまま残ります。端末やブラウザをどれだけ固めても、連携先のサーバーからトークンが漏れれば、別の入口から広告アカウントを操作されます。昔試して使わなくなったツールのトークンが、誰も覚えていないまま有効になっているのが一番危ない状態です。

経路3：AIエージェントに管理画面を操作させる

ブラウザを操作するAIエージェントや、AIを組み込んだ自動化ツールに管理画面を触らせると、AIは画面に表示された文章や読み込んだファイルの内容を「指示」として受け取ってしまうことがあります。悪意のある文言を仕込んだページやメールを読ませるだけで、AIが意図しない操作を実行する攻撃（プロンプトインジェクション）が知られています。加えて、導入時にAPIキーや管理者権限を広く渡しがちで、その設定ファイルや権限が攻撃の入口になります。AIツールの導入後にMCCを乗っ取られたという事例も、業界内で複数共有されています。

経路4：権限の広すぎるアカウントが1つでも奪われる

ここまでの3つは侵入の経路で、4つ目は被害を大きくする構造です。1つのMCCで全クライアントを管理し、運用担当者全員が管理者権限を持っている体制では、誰か1人のアカウントが奪われた時点で全案件が操作されます。入口が1つ破られたら全部終わる構造になっていないかを、侵入対策と同じ重さで見直します。

AIに管理画面を操作させない

AIで運用工数が減るのは確かです。ただ、ブラウザ操作型のAIに管理者としてログインした画面を渡すのは、セキュリティの面では最も大きな賭けになります。工数が減るなら大きなリスクを取ってもよい、と経営として判断できる場合だけ許可し、それ以外は次の線を引きます。

• AIにはレポートの集計や分析、広告文の案出しまでを任せ、管理画面への反映は人が行う
• AIからAPIを使う場合は、読み取り専用のアカウントで発行した認証情報だけを渡す
• AIツールの導入を外部に頼む場合も、どのアカウントで、どの権限の認証情報を、どこに保存したかを書面で受け取る
• APIキーやトークンを設定ファイルに平文で置かない。置いた場合は、そのパソコン自体を管理用に使わない

使っていない連携・API・スクリプトを削除する

Google広告の管理画面では、アカウントにアクセスできるユーザーとMCCのリンク、APIで接続しているアプリ、登録済みのスクリプト、自動ルールを確認できます。次の順で棚卸しします。

1. 「管理者」→「アクセスとセキュリティ」でユーザーと管理アカウントの一覧を出し、退職者・契約が終わった外部パートナー・見覚えのないメールアドレスを削除する
2. レポートツールや自動運用ツールなど外部サービスの一覧を作り、今も使っているものだけを残す。使っていないサービスは連携を解除し、サービス側のアカウントも閉じる
3. スクリプトと自動ルールを開き、作った人が分からないもの、目的が説明できないものを停止・削除する
4. Googleアカウントの「サードパーティ製のアプリとサービス」から、Google広告へのアクセスを許可したアプリを確認し、不要なものはアクセス権を取り消す

4つ目は見落とされやすい作業です。APIのリフレッシュトークンは、新しく発行するときの本人確認が厳しくなっても、過去に発行したものは取り消すまで有効なまま残ります。数年前に試したツールのトークンが今も使える状態なら、そこが入口になります。

管理者にはGoogleの高度な保護機能プログラムを適用する

高度な保護機能プログラム（Advanced Protection Program）は、Googleが提供している最も強いアカウント保護です。ログインにパスキーまたは物理セキュリティキーが必須になり、SMSやメールでのコード認証は使えなくなります。信頼できないアプリからのアクセスも制限され、アカウント復旧の審査も厳しくなります。管理者権限を持つ人は全員、このプログラムに登録しておきます。物理キーは紛失に備えて1人2本ずつ登録します。

会社のドメインのアカウントで管理する

個人のGmailで管理者になっていると、会社としてそのアカウントの認証方式を強制できず、退職時に権限を外し忘れても気づけません。Google Workspaceなど会社のドメインのアカウントを使い、2段階認証の強制とパスキーの必須化を組織の設定として管理します。

重要な操作に再認証を求める

ログインのときだけでなく、ユーザーの追加、権限の変更、MCCのリンク変更といった機密性の高い操作のたびに、パスキーやセキュリティキーでの再認証を求める設定をオンにします。セッションCookieを盗まれても、攻撃者はユーザー追加の段階で物理キーを持っていないため止まります。経路1への対策として、もっとも効果の大きい設定の一つです。

複数の管理者による承認（MPA）を有効にする

複数の関係者による承認（Multi-Party Approval）を有効にすると、ユーザーの追加・削除や権限の変更が、別の管理者の承認を得るまで反映されなくなります。管理者のアカウントが1つ奪われても、攻撃者は自分を追加したり、正規の管理者を外したりできません。承認できる管理者が少ないと、休暇中や退職時に設定変更が止まってしまうため、管理者は3人以上にして、全員が別々の端末と物理キーで認証できる状態にしておきます。

招待できるメールアドレスを自社ドメインに限定する

「許可されたドメイン」に自社のドメインを登録すると、それ以外のメールアドレスを広告アカウントに招待できなくなります。攻撃者が自分のGmailをユーザーとして追加する手口を、この設定だけで防げます。外部パートナーを招待する必要がある場合は、そのパートナーのドメインを個別に追加し、契約が終わったら外します。

権限は必要な分だけにする

日々の運用で管理者権限やMCCの管理権限が必要になる場面は、実はほとんどありません。入札調整、広告文の差し替え、レポート確認は「標準」権限で足ります。クライアント側の担当者や経理担当は「読み取り専用」か「請求のみ」にします。権限一覧を作り、管理者が4人も5人もいる状態なら、MPAに必要な人数を残して標準権限へ下げます。

MCCを分け、1つの入口から全案件に届かないようにする

代理店では、全クライアントのアカウントを1つのMCCにぶら下げていることがよくあります。この構成では、MCCの管理者が1人奪われただけで全案件の予算を書き換えられます。業種、担当チーム、契約形態などでMCCを分け、運用担当者はそれぞれ自分の担当MCCにだけアクセスできるようにします。

注意したいのは、MCCを分けても、それらをさらに上位のMCCでまとめていたり、同じ管理者アカウントが全MCCに入っていたりすると、分けた意味がなくなることです。外部ツールの連携も同じで、全MCCを1つのツールアカウントにつなぐのではなく、MCCごとに連携を分けます。

広告アカウントごとに上限つきのカードを割り当てる

乗っ取りの被害額を決めるのは、最終的には「支払いが通るかどうか」です。1枚の法人カードを全アカウントの支払いにまとめていると、そのカードの利用枠すべてが攻撃者の予算になります。UPSIDERなどの法人向けサービスでバーチャルカードを広告アカウントごとに発行し、月の利用上限を想定予算の1.2〜1.5倍程度に設定しておけば、乗っ取られても損害はその上限で止まります。カード側で利用通知を受け取れるようにしておくと、普段より大きな決済が通った時点で気づけます。

命名規則に反したキャンペーンを通知する

乗っ取った側は、自分のキャンペーンを新しく作るか、既存のキャンペーンの予算を引き上げて配信します。キャンペーン名の付け方を社内で決めておけば、規則から外れた名前のキャンペーンは「誰かが勝手に作ったもの」として見分けられます。Google広告のスクリプトで、命名規則違反と日予算の上限超えを1時間ごとに検査し、メールで知らせる仕組みを作っておきます。

このとき、見つけたキャンペーンを自動で停止する作りにはしません。停止させると攻撃者がスクリプトの存在に気づき、スクリプトを削除してから配信をやり直すためです。通知だけにして、人が確認して止めます。

// 命名規則と日予算の上限を検査し、外れていればメールで知らせる
// 例：検索広告は「SR_案件名_YYMMDD」、P-MAXは「PM_案件名_YYMMDD」
var NAME_RULE = /^(SR|PM|DG|SH)_[A-Za-z0-9-]+_\d{6}$/;
var MAX_DAILY_BUDGET = 50000;           // 通常の上限より少し上の金額
var MAIL_TO = 'ads-alert@your-company.co.jp';

function main() {
  var problems = [];
  var iterators = [
    AdsApp.campaigns().withCondition("campaign.status = ENABLED").get(),
    AdsApp.performanceMaxCampaigns().withCondition("campaign.status = ENABLED").get()
  ];
  iterators.forEach(function (it) {
    while (it.hasNext()) {
      var c = it.next();
      var name = c.getName();
      var budget = c.getBudget().getAmount();
      if (!NAME_RULE.test(name)) {
        problems.push('命名規則違反: ' + name);
      }
      if (budget > MAX_DAILY_BUDGET) {
        problems.push('日予算超過: ' + name + '（' + budget + '）');
      }
    }
  });
  if (problems.length > 0) {
    var acc = AdsApp.currentAccount();
    MailApp.sendEmail(MAIL_TO,
      '【要確認】' + acc.getName() + '（' + acc.getCustomerId() + '）',
      problems.join('\n'));
  }
}

スクリプトは「ツールとスクリプト」→「一括操作」→「スクリプト」から登録し、実行頻度を「1時間ごと」にします。MCCで運用している場合は、MCCレベルのスクリプトで配下のアカウントを順に検査する形にすると、アカウントごとに登録する手間が省けます。通知先は個人のアドレスではなく、複数人が受け取る自社ドメインのメーリングリストにしてください。

媒体側の通知を受け取れる状態にする

Google広告では、ユーザーの追加やお支払い情報の変更があると管理者にメールが届きます。この通知が個人の受信箱に埋もれていると意味がありません。通知メールの宛先とフィルタを見直し、ユーザー追加、権限変更、お支払い方法の変更、費用の急増に関する通知は、運用チーム全員が見るチャンネルに転送します。

発覚してから最初の1時間でやること

1. カードを止める。カード会社のアプリや管理画面から、該当する広告アカウントのカードを一時停止する。画面に入れなくても支払いが止まれば配信は止まる
2. 配信を止める。管理画面に入れる場合は、不審なキャンペーンだけでなく、全キャンペーンをいったん一時停止する
3. 不審なユーザーとリンクを外す。見覚えのないユーザー、管理アカウントのリンク、API連携を削除する。MPAが有効なら、別の管理者が承認する
4. 媒体に連絡する。担当者の緊急連絡先と、公式サポートの両方に、アカウントID・発覚時刻・不審な操作の内容を送る
5. 認証情報を入れ替える。関係者全員のパスワードを変え、Googleアカウントの「すべてのデバイスからログアウト」でセッションを失効させ、APIトークンを取り消す
6. 原因を調べる。変更履歴とアクセスログから、どのユーザー・どの経路で操作されたかを特定し、該当する端末を調べ終わるまで使わない

媒体への補填の相談

被害額の補填を媒体に相談するとき、代理店側の管理体制の話から入ると、自己責任として扱われて話が進みにくくなることがあります。乗っ取りで出稿された広告は、詐欺サイトや違法な商材であることがほとんどです。「規約に違反する広告が、なぜ審査を通って配信されたのか」という媒体側の審査の論点を、変更履歴と配信された広告の証拠とともに整理して伝えると、話が前に進みやすくなります。