Google Chat 監査ログで内部脅威を自動検知する

Google Workspace の BigQuery Export は、Google Chat のメッセージ送信・添付ファイル操作・スペース参加などの行動ログをほぼリアルタイムで BigQuery に書き出す機能です。この記事では、Google Chat BigQuery Export 監査の観点から、外部スペースへの大量送信・深夜添付送信・外部ユーザーへの DM 急増という3つのシグナルを SQL クエリで自動検知する設計方針を整理します。

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

• Google Workspace の BigQuery Export を有効化済みだが、Chat ログを監査・分析に活かせていない情シス担当者
• インシデント調査をいまだに管理コンソールの手動目視でこなしている担当者
• 退職予定者や特定ユーザーの行動異常をリアルタイムに近い形で把握したい担当者

Google Chat BigQuery Export 監査で取得できるデータ

対応エディション

Chat ログの BigQuery Export は、Frontline Standard / Frontline Plus / Enterprise Standard / Enterprise Plus / Education Standard / Education Plus / Enterprise Essentials Plus で利用できます（公式管理者ヘルプより）。Business Standard や Business Plus は対象外のため、導入前にエディションを確認してください。

内部脅威に有効なイベントと主なパラメータ

Admin Reports API の公式ドキュメントが定義する Chat のイベントのうち、内部脅威の観点で注目すべきものを以下に示します。

イベント名	概要	主なパラメータ
message_posted	メッセージ送信	conversation_ownership, conversation_type, room_id, dlp_scan_status
attachment_upload	添付ファイル送信	attachment_name, conversation_ownership, dlp_scan_status
direct_message_started	DM 開始	conversation_ownership, room_id
history_turned_off	スペース履歴オフ	room_id
message_deleted	メッセージ削除	room_id, message_id

dlp_scan_status は DLP（Data Loss Prevention：データ損失防止）のスキャン結果を示すパラメータで、GWS の DLP ルールを有効化している組織で参照できます。

検知クエリの中核となるのが conversation_ownership パラメータです。組織内外を区別する際に利用しますが、実際の値（例: external / internal 相当）はエクスポート設定によって異なる場合があります。本番適用前に SELECT DISTINCT chat.conversation_ownership FROM {your_table} を一度実行して、自組織のデータで使われている値を確認してください。

内部脅威として検知すべき3つのシグナル

1. 外部スペースへの大量メッセージ送信

通常業務での外部スペースへの送信量は一定の範囲に収まります。特定のユーザーが急に外部スペースへの送信量を増やすパターンは、情報持ち出しのシグナルになります。退職が決まったタイミングや業務委託先との交渉が切り替わるタイミングに出現しやすいため、こうした時期は意識的にモニタリング頻度を上げます。

2. 深夜・休日の添付ファイル送信

業務時間外（22:00〜06:00 JST）の添付ファイル送信は、通常の業務フローではほとんど発生しません。アカウント乗っ取りが発生した場合も、このパターンが初期兆候として出ます。1件でも検知されたら確認対象にする、という低いしきい値から始めるのが適切です。

3. 外部ユーザーへの短時間 DM 集中

1時間以内に複数の外部ユーザーへ DM を開始するイベントは、情報を持ち出す前の「連絡先確保」段階として出現することがあります。外部パートナーとの接触が業務上多い担当者では false positive（誤検知）も出るため、役割ベースで除外リストを持つと運用負荷を下げられます。

BigQuery SQL で検知クエリを実装する

以下の3本のクエリは、管理コンソールの BigQuery Export 設定から有効化した GWS ネイティブ BigQuery Export が生成する activity テーブルを対象にしています。{gcp_project} と {dataset} は実際の値に置き換えてください。

また、chat.* フィールドの名称は GWS BigQuery Export のフィールド命名規則（login.login_type や drive.visibility と同様）に基づいて記述していますが、公式 Reports API スキーマドキュメントおよび自組織の実データと照合してから本番適用してください。

クエリ 1：外部スペースへの大量メッセージ送信を検知する

過去7日間で、外部スペースに1日あたり20件以上メッセージを送ったユーザーを集計します。しきい値は組織の平均送信量に応じて調整が必要です。

-- 外部スペースへの大量メッセージ送信を日次で集計
SELECT
  email                                AS actor_email,
  DATE(TIMESTAMP_MICROS(time_usec))    AS event_date,
  COUNT(*)                             AS external_post_count
FROM
  `{gcp_project}.{dataset}.activity`
WHERE
  event_type   = 'chat'
  AND event_name = 'message_posted'
  AND chat.conversation_ownership = 'EXTERNALLY_OWNED' -- 実際の値は SELECT DISTINCT で確認（環境によって異なる場合あり）
  AND DATE(TIMESTAMP_MICROS(time_usec))
        >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
GROUP BY
  actor_email,
  event_date
HAVING
  external_post_count >= 20    -- 組織の平均値に合わせて要調整
ORDER BY
  event_date DESC,
  external_post_count DESC
;

TIMESTAMP_MICROS(time_usec) は GWS BigQuery Export の標準的なタイムスタンプ変換です。ログは UTC で格納されています。

クエリ 2：深夜帯の添付ファイル送信を検知する

過去30日間で、深夜帯（22:00〜06:00 JST）に発生した添付ファイル送信を一覧表示します。JST 変換には TIMESTAMP_ADD(..., INTERVAL 9 HOUR) を使います。

-- 深夜帯（22:00〜06:00 JST）の添付ファイル送信を一覧化
SELECT
  email                              AS actor_email,
  TIMESTAMP_MICROS(time_usec)        AS event_time_utc,
  chat.attachment_name               AS attachment_name,
  chat.conversation_ownership        AS space_type
FROM
  `{gcp_project}.{dataset}.activity`
WHERE
  event_type   = 'chat'
  AND event_name = 'attachment_upload'
  AND DATE(TIMESTAMP_MICROS(time_usec))
        >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
  AND (
    EXTRACT(HOUR FROM
      TIMESTAMP_ADD(TIMESTAMP_MICROS(time_usec), INTERVAL 9 HOUR)
    ) >= 22
    OR
    EXTRACT(HOUR FROM
      TIMESTAMP_ADD(TIMESTAMP_MICROS(time_usec), INTERVAL 9 HOUR)
    ) < 6
  )
ORDER BY
  event_time_utc DESC
;

内部スペース・外部スペースを問わず深夜の添付送信を全件取得しています。space_type カラムで内外を確認したうえで優先度を判断してください。

クエリ 3：外部ユーザーへの短時間 DM 集中を検知する

過去14日間で、1時間以内に外部ユーザーへの DM を3件以上開始したケースを抽出します。TIMESTAMP_TRUNC で1時間ウィンドウに丸めて集計します。

-- 1時間以内に外部 DM を3件以上開始したケースを検知
SELECT
  email                                AS actor_email,
  TIMESTAMP_TRUNC(
    TIMESTAMP_MICROS(time_usec), HOUR) AS window_start,
  COUNT(*)                             AS dm_count
FROM
  `{gcp_project}.{dataset}.activity`
WHERE
  event_type   = 'chat'
  AND event_name = 'direct_message_started'
  AND chat.conversation_ownership = 'EXTERNALLY_OWNED' -- 実際の値は SELECT DISTINCT で確認（環境によって異なる場合あり）
  AND DATE(TIMESTAMP_MICROS(time_usec))
        >= DATE_SUB(CURRENT_DATE(), INTERVAL 14 DAY)
GROUP BY
  actor_email,
  window_start
HAVING
  dm_count >= 3
ORDER BY
  window_start DESC,
  dm_count DESC
;

検知ルール設計表

3つのシグナルを整理すると下表のようになります。しきい値はあくまで初期値です。2週間分のデータで false positive 率を確認してから調整するサイクルを回します。

シグナル	イベント名	主な検知条件	推奨初期しきい値	リスクレベル
外部スペースへの大量送信	message_posted	外部スペース宛てメッセージを1日でカウント	20件/日	高
深夜の添付ファイル送信	attachment_upload	22:00〜06:00 JST に送信	1件/回	中〜高
外部ユーザーへの DM 集中	direct_message_started	1時間以内に外部 DM を連続開始	3件/時	中

しきい値設計の出発点は「正常業務でまず発生しない数値」を起点にすることです。最初は低めに設定してデータを取り、false positive が多ければ引き上げ、見落としが気になれば下げる、という判断を繰り返します。

検知後の運用フロー

SQL クエリを書いて終わりでは機能しません。検知後の動きをあらかじめ設計しておくことが重要です。

BigQuery のスケジュールドクエリで上記クエリを毎朝自動実行し、結果を Google スプレッドシートに出力します。Apps Script でスプレッドシートへの書き込みをトリガーに情シス担当者へアラートメールを送る仕組みを組めば、追加コストなしで自動通知が完成します。

通知を受けた後の一次確認は、次の順序で進めます。

1. false positive 確認: 外部パートナーとの協業プロジェクト中か、業務上の合理的な理由があるか確認する
2. 継続パターン確認: 単発か繰り返しかを BigQuery で直近30日の当該ユーザーログを全件確認して判断する
3. 対応判断: 継続パターンで業務上の説明がつかない場合、上長と連携してアカウントの一時停止や Google Vault による保全を検討する

Google Vault は Chat ログの保全・電子情報開示を担う GWS の機能です。インシデント疑いが発生した時点でデータが削除・上書きされないよう、Vault での保留（Hold）操作の手順を事前に確認しておきます。

SQL 検知の限界と今後の拡張

SQL ベースのバッチ検知には構造的な制約があります。

リアルタイム性がない点は大きな制約です。1日1回の定期実行では、実行間隔中に発生したインシデントは翌朝まで把握できません。緊急性の高いシナリオには、Cloud Logging のアラートポリシーを補助的に組み合わせる選択肢を検討してください。

コンテキストのない閾値検知では false positive が必ず出ます。外部パートナーとの接触が業務上多い部門では、ユーザーホワイトリストや OU（組織単位）単位の除外ルールを設けることでノイズを抑えられます。

将来の拡張先としては、BigQuery ML によるユーザーごとのベースライン行動モデル構築があります。個人の平均送信量からの偏差で検知するアプローチはより精度が高くなりますが、モデル維持コストも増えます。SQL ルールで実績を積んでから段階的に移行するのが現実的な順序です。

まとめ

Google Chat BigQuery Export 監査ログを内部脅威検知に活かすには、3点が必要です。

• 検知対象のイベントとしきい値を設計として明示的に決める
• BigQuery スケジュールドクエリ + Apps Script で自動通知を実装する
• false positive 確認からアカウント停止・Vault 保全までの対応フローを事前に定める

追加ツールなしで GWS + BigQuery の既存環境が内部脅威の検知基盤になります。まず「深夜添付ファイル送信」のクエリ1本から始めて1週間様子を見て、そこから残り2本に展開する順序を勧めます。検知ルールは一度作ったら終わりではなく、false positive の実績を見ながら育てるものです。

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

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