Google Workspace で SaaS OAuth 不正を検知・遮断する設計

Google Workspace の Admin SDK Reports API は、SaaS への OAuth 認可イベントをドメイン全体で数時間以内に記録します（公式ドキュメントでは OAuth トークンログの反映に "a few hours" のラグがあると明示されています）。本記事では、CAA (Context-Aware Access) だけでは検知できない「OAuth 認可後の不正」を監査ログから発見し、インシデントとして対処するフロー設計を整理します。

この記事を読んだほうが良い人

• SaaS を複数導入している 100 名規模の企業情シス担当者
• CAA を運用中で、「ログイン制御はできているが、OAuth 認可後の監視が手薄」と感じている方
• Admin SDK Reports API を使った監査ログ分析を検討している方
• 不正アクセスの検知フローを整備し、インシデント対応の自動化を進めたい方

SaaS OAuth不正アクセス検知の前提：CAAが守る範囲とその外側

CAA は、Google Workspace サービスへのサインイン（認証フェーズ）にコンテキスト条件を課す仕組みです。デバイス管理状態・IP アドレス・OS バージョンなどを評価し、条件を満たさない場合はサインイン時点でアクセスを遮断できます。

ただし、CAA が介入するのはサインイン時点に限られます。ユーザーが一度 OAuth 認可を済ませたサードパーティ SaaS は、発行されたアクセストークンやリフレッシュトークンを使って API を呼び続けられます。CAA は既発行トークンのリアルタイム監視をしません。

つまり、「入口で確認したが、中に入ったあとは追跡していない」という状態です。これは CAA の欠陥ではなく設計上の役割分担ですが、この空白地帯を狙った攻撃が実際に存在します。侵害されてから気づくまでに数週間〜数か月かかるケースも多く、被害が拡大しやすい領域です。情シス側で監視レイヤーを別途持つ必要があるのはこの理由です。

CAA をすり抜けた後の OAuth 攻撃パターン

認可後フェーズでよく見られる手口を整理すると、以下の3パターンに分類できます。

攻撃パターン	概要	CAA で防げるか
Authorization Code インターセプト	OAuth フロー途中で認可コードを横取りしてトークンを不正取得する	防げない
スコープ昇格（Scope Creep）	最初は限定スコープで認可を取り、アプリ更新で広いスコープを後から要求する	防げない
リフレッシュトークン長期保持	一度発行されたリフレッシュトークンをパスワード変更後も使い続ける	防げない

3 パターンに共通するのは「認可フロー自体または認可済みトークンへの介入」という点です。スコープ昇格は特に発見が遅れやすく、社員がほとんど意識せずに画面上で「許可」をクリックしたことで被害が拡大します。サインイン制御だけを強化しても防ぎきれないため、別の監視レイヤーが必要になります。

Admin SDK Reports API で取得できる OAuth 監査イベント

Admin SDK Reports API の token アプリケーションにアクセスすると、ドメイン全体の OAuth 認可・取り消しイベントを取得できます。公式リファレンスには authorize / revoke / activity / deny / request の全 5 種類のトークンイベントが掲載されています。本記事では、異常検知に特に関連する代表的な 3 種を取り上げます（残り 2 種は deny（認可拒否）と request（アクセス要求）です）。

イベント名	内容
authorize	ユーザーがサードパーティアプリに OAuth 認可を付与したとき
revoke	認可が取り消されたとき（ユーザー操作または管理者操作）
activity	発行済みトークンを使って API コールが行われたとき

各イベントには、操作を行ったユーザーのメールアドレス、認可先アプリの名称、付与されたスコープの一覧、タイムスタンプが記録されます。これによって「誰が、いつ、どのアプリに、どの権限を渡したか」がドメイン全体で把握できます。

revoke イベントは、ユーザー自身がアプリ接続を解除したときだけでなく、管理者が強制取り消しを行ったときにも発生します。インシデント対応の完了確認として「当該ユーザーの全アプリに対して revoke が実行されたか」をチェックする使い方もできます。

これらのログから、以下のシグナルを「疑わしいパターン」として定義します。

シグナル	なぜ疑わしいか
1時間以内に同一ユーザーから複数回 authorize が発生	アカウント乗っ取り後に攻撃者が複数アプリに素早く認可を付与している可能性がある
深夜・早朝（0〜5時台）の authorize	通常業務外の時間帯の認可は要確認。海外からのアクセスとセットの場合は特に注意
Gmail フルアクセス・Drive 全ファイル管理など広範スコープへの新規認可	攻撃準備として高権限スコープを取得しておく手口と一致する
長期間アクティビティがなかったアプリが突然 activity を開始	スリーパー攻撃（事前に認可を取得しておき後から利用）のパターンと一致する

なお、いずれのシグナルも単独では誤検知が多くなります。複数のシグナルが重なった場合に確度が上がると考えるのが基本設計です。

検知・通知・遮断のフロー設計

Admin SDK、アラート通知、CAA を組み合わせた全体フローを示します。

[Admin SDK Reports API（token アプリ）]
          ↓  GAS タイマートリガーで定期取得
[疑わしいシグナル判定ロジック]
          ↓  条件一致
    ┌─────┴──────────────────────┐
[Slack / メールにアラート送信]   [遮断グループにユーザー追加]
    ↓                                ↓
[担当者が確認・判断]          [CAA ポリシーがアクセスを制限]
    ↓                                ↓
[誤検知なら手動で解除]        [インシデント対応を並行実施]

管理コンソールのアラートセンターでも一部の管理イベントについて標準の通知設定が可能です。ただし、OAuth 認可のカスタムしきい値や複合条件による検知には対応していないため、本記事で示す Admin SDK ベースの独自実装が有効です。

フローの核心は「判断をどこで分岐させるか」です。確度が高いシグナルは自動遮断グループへの追加まで進め、確度が低いシグナルはアラート通知だけに留めます。担当者が不在の夜間・休日でも攻撃者に時間を与えないようにするには、高確度シグナルの自動遮断パスを事前に用意しておく必要があります。

CAA のセキュリティ設定で「このグループに属するユーザーはアクセス制限」というポリシーを事前に設定しておくと、GAS からグループメンバーシップを変更するだけで動的に遮断できます。遮断グループの CAA ポリシーへの組み込みは、自動対応の下地として必ず先に用意しておく必要があります。

GAS による OAuth authorize イベントの定期チェック例

GAS から Admin SDK Reports API を呼び出すには、スクリプトのサービス設定で「Admin SDK Advanced Service」を有効にする必要があります。また、スクリプトに紐づく GCP プロジェクトで Admin Reports API が有効化されていることと、実行アカウントがスーパー管理者権限または Reports API の読み取り権限を持つロールに属していることが前提です。

以下のコードは「1時間以内に3件以上の authorize が同一ユーザーから発生した場合にアラートを送る」ロジックの骨格を示します。THRESHOLD や通知先・遮断グループの追加処理は実環境に合わせて変更してください。

// GAS タイマートリガー（1時間ごと）で実行する関数
function checkOAuthAuthorizeAnomalies() {
  const endTime = new Date();
  const startTime = new Date(endTime.getTime() - 3600 * 1000); // 過去1時間

  // Reports API から authorize イベントを取得
  const result = AdminReports.Activities.list('all', 'token', {
    eventName: 'authorize',
    startTime: startTime.toISOString(),
    endTime: endTime.toISOString(),
    maxResults: 500
  });

  if (!result.items || result.items.length === 0) return;

  // ユーザーごとの authorize 件数を集計
  const userCounts = {};
  result.items.forEach(item => {
    const actor = item.actor && item.actor.email;
    if (actor) userCounts[actor] = (userCounts[actor] || 0) + 1;
  });

  // 閾値（1時間に3件以上）を超えたユーザーに通知
  const THRESHOLD = 3;
  Object.entries(userCounts).forEach(([user, count]) => {
    if (count >= THRESHOLD) {
      // notifySlack() は別途定義する Slack Webhook 送信関数
      notifySlack(`[OAuth 異常検知] ${user} が過去1時間に ${count} 件の OAuth 認可を付与しました`);
      // 自動遮断する場合はここで遮断グループへの追加処理を呼ぶ
    }
  });
}

THRESHOLD の値（ここでは3件）は、自社の運用実態に合わせて調整が必要です。最初は高めに設定して誤検知を減らし、自社のベースラインを把握してから絞り込む進め方が安全です。なお、maxResults: 500 に設定していますが、大規模ドメインでは1時間のイベント数が 500 件を超える可能性もあります。その場合は nextPageToken を使ったページネーション処理を追加してください。

運用ポリシーの設計判断：自動遮断かアラートのみか

ログ監視の仕組みを入れても、「何が起きたら何をするか」の運用ポリシーが決まっていなければ動きません。以下の判断軸で整理します。

自動遮断を適用する条件（高確度シグナルの組み合わせ）

単一シグナルではなく、複数が重なった場合に限定するのが基本です。例としては次のような組み合わせが考えられます。

• 深夜帯の authorize かつ広範スコープ（Gmail フルアクセス・Drive 全ファイル管理等）
• 1時間以内に5件以上の authorize（しきい値は組織規模に合わせて調整）
• 過去に認可実績のない未知のクライアント ID への認可

アラート通知のみに留める条件（中確度シグナル）

単一シグナルの場合は担当者の判断を挟みます。

• 深夜帯の authorize（スコープが業務範囲内の場合）
• 普段と異なる時間帯に activity が急増しているが、アプリ自体は既知の場合

ログ保存のみとする条件（低確度シグナル）

誤検知が多くなる条件はまず蓄積・分析フェーズに留め、ベースラインを積んでから判断基準を固めます。

自動遮断を実施する場合は、遮断後 24 時間以内に担当者が確認・解除を判断する SLA を設けます。「自動で止めて、後から確認する」という運用にすることで、攻撃者の行動時間を短縮しつつ、誤検知による業務影響を許容範囲に収めます。誤検知が発生したときの解除手順も、事前に文書化しておく必要があります。

また、事後検知だけでなく、四半期に一度「現在ドメイン内で認可済みの全アプリ一覧」を管理コンソールの「監査と調査」から確認する棚卸しを運用に組み込むことを推奨します。長期間使われていないアプリや、過剰なスコープを持つアプリへの認可を管理者側から取り消すことで、リスクの蓄積を防げます。

制約と注意点

この設計には実務上の限界があります。把握しておかないと過信につながります。

• ログのカバー範囲: OAuth 認可イベントは GWS ドメインの認可に限られます。SaaS 側（Slack、Notion、Salesforce など）で何が操作されたかは GWS のログには映りません。侵害後に SaaS 内でどの操作が行われたかは、各 SaaS 固有の監査ログで確認する必要があります
• ログ保持期間: Admin SDK Reports API で取得できるイベントの保持期間は最大 6 ヶ月（180 日）です。長期的な調査が必要なインシデントでは、ログを定期的に外部ストレージ（BigQuery や GCS など）にエクスポートしておく設計が必要です
• CAA 遮断のスコープ: CAA で遮断できるのは Google Workspace サービスへのアクセスです。SaaS 側にすでに保存・コピーされたデータや、SaaS から外部への流出は GWS 側では止められません
• 誤検知と業務影響: 自動遮断は担当者不在時の対応を可能にしますが、正当な操作（海外出張中の深夜作業など）を誤って遮断するリスクがあります。遮断グループへの追加ロジックは慎重に設計し、かつ解除を素早く行える体制を整えます

Google Workspace で OAuth 監視を始める具体的な順序

取り組みを段階的に進める場合、以下の順序が現実的です。

まず今週中に実施できるのは、管理コンソールの「監査と調査」から OAuth ログイベントを手動で開き、自社ドメインの現状を確認することです。どのアプリに、どのスコープで、誰が認可しているかを可視化するだけでも、リスクの全体像がつかめます。現時点で広範スコープを持つ未確認アプリが見つかった場合は、手動で認可を取り消すことも選択肢です。

次の 1〜2 週間の準備として、「遮断グループの作成」と「CAA ポリシーへの組み込み」があります。この下地がないと、後から GAS で自動遮断を実装しても動きません。グループに CAA ポリシーを紐づけておくことで、メンバー追加だけで即座に効力が発生する状態を作ります。

GAS スクリプトの実装とタイマートリガー設定はその次のステップです。最初はアラート通知のみで運用して誤検知率を確認し、精度が確認できてから自動遮断に格上げするのが安全な順序です。

CAA は有効な入口管理ですが、「入口が固ければ中は見なくていい」という考え方は通用しません。100 名規模の SaaS 環境では、OAuth 認可後のフェーズも監視サイクルに組み込むことが、セキュリティ成熟度を上げる次の一手です。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。