Google Workspace アラートセンターの運用設計

Google Workspace の管理コンソールには、フィッシングやアカウント侵害などのセキュリティ上の問題を通知する「アラートセンター（Alert Center）」が組み込まれています。この記事では、どのアラートを重視し・誰に通知し・どう初動対応するかの運用設計を整理します。

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

• Alert Center の存在は知っているが、ほぼ確認していない情シス担当者
• 通知先や対応フローが決まっておらず、アラートが「見るだけ」で終わっている
• API 自動化は後回しにして、まず UI ベースの運用設計から固めたい
• 1人情シスまたは2名体制で GWS のセキュリティ体制を整備したい

Google Workspace アラートセンターの役割

Alert Center は Google Workspace 管理コンソールのセキュリティ関連設定配下に用意されたセキュリティ通知ダッシュボードです。Google 側がドメイン内の脅威を検知した時点でアラートが生成され、管理者はそこから状況確認・対応判断・クローズまでを一元管理できます。

Alert Center を理解するうえで重要なのは、「Google が自動的に何かを阻止する仕組み」ではなく「脅威を検知したことを管理者に知らせる仕組み」だという点です。フィッシングメールの隔離や不審なログインのブロックは Google の自動保護機能が行いますが、それらのイベントが起きたことを管理者に伝えるのが Alert Center の役割です。Alert Center の設定が不十分だと、インシデントが起きていても管理者が気づかないまま時間が経過します。

似た機能として「セキュリティダッシュボード（Security Dashboard）」があります。セキュリティダッシュボードは期間ごとの統計・トレンドを可視化するレポートツールです。特定のイベント発生時に管理者へプッシュ通知するのが Alert Center、全体傾向を俯瞰するのがセキュリティダッシュボード、と役割が分かれています。

デフォルトでアクセスできるのはスーパー管理者（Super Admin）とサービス管理者（Services Admin）です。その他の委任管理者は、カスタムロールに Alert Center の閲覧権限または管理権限を付与することでアクセスを有効にできます。誰が実際に確認できるかを最初に確認し、必要に応じてカスタムロール経由でアクセスを分散させてください。スーパー管理者が社内に1名しかいない場合は、その担当者が不在のときに高優先度のアラートを誰も受け取れなくなるリスクがありますが、Alert Center 確認のためだけにスーパー管理者を増やす必要はありません。

アラートは Google 公式ヘルプによると約10年間保存されます。「蓄積しておいて後で見直す」ではなく、発生時に気づく仕組みを先に作るのが運用設計の出発点です。

なお、既存記事では Alert Center API 経由の自動監視フローを扱っています。本記事は API 不要・UI のみで運用できる設定と対応フロー設計を対象とします。Slack 連携やチケット自動起票を検討しているなら、まず本記事の UI 設計を固めてから API 化を進める順序が安定します。詳細は DRASENAS の Alert Center API 記事も参照してください。

アラートカテゴリと優先度設計

Google 公式の Alert Types リファレンスをもとに整理すると、Alert Center のアラートは主に5つのカテゴリに分類されます。情シス担当者が優先度を判断する際の参考として、以下に一覧を示します。

優先度	カテゴリ	代表的なアラート例	初期対応の方向
高	デバイス・ユーザーセキュリティ	漏洩した認証情報の検知 / 不審なログインのブロック	アカウント停止・パスワードリセット
高	Gmailセキュリティ	フィッシングメール検知 / マルウェアの再分類	対象メール確認・送信元ブロック
中優先	データ損失防止（DLP）	DLPルール違反 / ランサムウェアの疑い	ルール確認・対象ファイルの保全
中優先	アクティビティルール	管理者が設定したルールに基づくアラート	ルール内容に応じて判断
低〜参考	Chrome脅威 / サービス状態	ブラウザ脅威検知 / サービス障害通知	状況確認・ユーザーへの案内

「漏洩した認証情報の検知」は、Google が外部の漏洩データベースと照合して特定するアラートです。パスワードリスト攻撃で使われる公開済み認証情報の中に自社ドメインのアカウントが含まれていた場合に発火します。実害が出る前に把握できる数少ない機会のひとつで、1人情シス体制でも確実に受信する設計が必要です。

「不審なログインのブロック」は Google が自動でブロックした後に通知するもので、連続して発生している場合はアカウント乗っ取りを試みられているサインです。確認は当日中に行います。

DLP（Data Loss Prevention: データ損失防止）アラートには注意点があります。DLP ルールを事前に設定していないと発火しないため、Alert Center を有効にしているにもかかわらず中優先度の通知がまったく来ない場合、DLP ルールの未設定が原因のことが多いです。Alert Center の設定が完了したら、DLP ルールも合わせて確認してください。

Chrome 脅威アラートは、Chromebook またはブラウザ管理が適用されているデバイスで発生します。BYOD 環境でブラウザ管理を適用していない場合はこのアラートは届かないため、Chrome 脅威が「来ない＝安全」とは判断しないでください。

GWSアラート通知の設定方針（誰が何を受け取るか）

Alert Center の通知設定でまず決めるべきことは「誰に通知するか」と「全件通知か重要度で絞るか」の2点です。体制別に2つのパターンを示します。

1人情シスパターン

高優先度アラート（漏洩認証情報 / 不審なログイン / フィッシング検知）は、情シス個人メール＋上長のメールにも通知します。上長を CC することで、担当者が不在のときのバックアップと、インシデントを組織として認知している記録を兼ねられます。中優先度アラート（DLP違反 / アクティビティルール）は情シス専用の Google Group に集約し、低優先度（Chromeセキュリティ / サービス状態）はメール通知せずダッシュボード確認のみにします。

2〜3名チームパターン

高優先度アラートはチーム共有 Google Group に通知し、一次担当者をローテーションで指定します。Google Group への通知にすると、メンバーが変わっても Group のメンバー設定を変えるだけで済み、個人メールアドレスを通知設定から都度変更する手間がありません。中優先度アラートはチーム共有 Group に集約して週次で消化、低優先度は通知なし（月次でダッシュボード確認）とします。

「全部自分のメールに来るようにした」という設定は、通知量が増えるにつれて重要なアラートを読み飛ばすリスクを高めます。低優先度を通知しない設計にすることで、高優先度への注意を集中させる構造を作れます。

通知設定を変更したら、実際にアラートが届いているかを確認します。Alert Center のダッシュボードで過去のアラートを開き、詳細画面に通知送信の記録があることを確認するか、テスト用のアクティビティルール違反を意図的に発生させて通知を確認する方法があります。設定だけして「届いているはず」で終わらせないことが重要です。

セキュリティアラートへの初動対応フロー

アラートを受信してからクローズするまでの流れを3ステップで整理します。高優先度アラートは受信から30分以内に確認・初動判断まで進めることを目安にします。中優先度は翌営業日中の確認でも許容できるケースが多いですが、DLP 違反は内容によって対応スピードが変わります。

ステップ1：確認・分類

アラートセンター上で詳細を開き、対象ユーザー・発生時刻・アラートタイプを確認します。1件のアラートが複数ユーザーに関係していることもあるため、影響範囲の把握を最初に行います。Alert Center の詳細画面には発生元 IP アドレスやデバイス情報が含まれる場合があり、対応判断の材料になります。同じアラートタイプが短期間に連続している場合は、単発事象ではなく組織的な攻撃の可能性も考慮します。

ステップ2：初動アクション

アラートタイプごとに判断が分かれます。

• 漏洩した認証情報 / 不審なログイン: 対象アカウントの一時停止とパスワードリセットを優先します。本人確認後に復旧する流れを先に決めておくと、発生時に「停止してよいか判断が取れない」という状況を防げます。2段階認証（2SV）が未適用の場合は、この機会に強制適用を検討します
• フィッシングメール / マルウェア: 対象メールの処理状況を Gmail 管理者画面から確認し、必要に応じて組織全体への注意喚起を並行して送ります。類似フィッシングが複数ユーザーに届いていないかも確認します
• DLP違反: 送信内容と対象ユーザーを確認し、意図的な送信かミスかを本人に確認します。繰り返し違反が出る場合はルールのしきい値調整を検討します
• 管理者権限の変更: 誰が・いつ・誰に対して変更したかを確認します。意図しない権限変更は内部不正または侵害の兆候の可能性があります

ステップ3：記録とクローズ

Alert Center 上でステータス（未着手 / 対応中 / クローズ（Closed））を更新し、対応内容をメモとして記録します。対応が不要と判断した場合（誤検知 / 正常なユーザー行動）も、その判断理由を残すことで後から説明できる状態を維持できます。対応ログは別途スプレッドシートに転記しておくと、月次・四半期レビューのときに振り返りやすくなります。

上長またはセキュリティ責任者への報告基準も事前に決めておきます。たとえば「対象ユーザーが経営陣の場合は即報告」「アカウントを停止した場合は30分以内に上長に口頭報告」など、しきい値を言語化しておくと現場での判断がスムーズになります。

定期レビューと棚卸しの設計

Alert Center は発生時の対応だけでなく、定期的に全体を見直す仕組みを組み込むことで運用が安定します。以下はシンプルなレビューサイクルの例です。

週次レビュー（目安：10〜15分）

• 高優先度アラートのステータスが「対応中」のまま放置されていないかを確認します
• 新規に発生した中優先度アラートを確認し、対応担当者をアサインします
• 1人情シスの場合は、毎週決まった曜日にダッシュボードを確認する習慣をカレンダーに入れておくと確認漏れを防ぎます

月次レビュー（目安：30〜60分）

• 未クローズの中優先度アラートを処理します
• DLP ルールが正常に機能しているかを確認します（アラートが全く来ない場合は DLP ルールの設定を再確認）
• 過去1ヶ月で最も多く発生したアラートタイプを把握し、対応が標準化されているかを確認します

四半期レビュー（目安：1〜2時間）

• 通知設定が現在の体制・メンバー構成と合っているかを見直します
• DLP ルールの誤検知率が高い場合はしきい値を調整します
• スーパー管理者のアカウントリストを棚卸しし、不要な権限が残っていないかを確認します
• 新たに追加されたアラートタイプを確認し（Google が定期的に追加します）、有効化が必要なものを判断します

このサイクルを設けることで、Alert Center が「インストールしたまま放置」の状態から「動いている証拠を定期的に残すセキュリティ運用」に変わります。

1人情シス向けとチーム向けの設定パターン比較

2つの体制における主な設定判断の違いをまとめます。

判断ポイント	1人情シス	2〜3名チーム
高優先度の通知先	個人メール + 上長CC	共有 Group + ローテーション当番
中優先度の消化サイクル	週次まとめて確認	週次で担当割り振り
低優先度の扱い	通知なし（月次確認）	通知なし（月次確認）
対応ログの管理	個人スプレッドシート	チーム共有スプレッドシートまたは Issue 管理
バックアップ体制	上長に高優先度をCC	当番ローテーション + バックアップ指定
誤検知の判断	担当者1名で判断・メモを残す	2名確認ルール（特に権限関連アラート）

1人情シスの場合、Alert Center は日常的に開く習慣がないとアラートが積み残しになりがちです。週次の「アラートチェック」をカレンダーブロックに入れておくと確認漏れを防ぐ運用上の保険になります。チーム体制でも当番の明確化を怠ると「誰かが見ているだろう」という抜け穴が生まれます。共有 Group への通知と一次担当者の指定はセットで設計してください。

運用で見落としやすいポイント

スーパー管理者権限の確認

Alert Center にデフォルトでアクセスできるのはスーパー管理者（Super Admin）とサービス管理者（Services Admin）です。それ以外の委任管理者には、カスタムロールに Alert Center の権限を付与することでアクセスを有効にできます。Alert Center 専用のカスタムロールを作成し、オンコール担当者に付与することで、スーパー管理者を増やさずにアクセス権限を分散できます。スーパー管理者のバックアップは、ビジネス継続性の観点から別途 2 名以上の設定が推奨されますが、Alert Center 確認のためだけにスーパー管理者を増やす必要はありません。

DLPルール未設定の影響

DLP アラートは DLP ルールを設定しないと発火しません。Alert Center を有効にしても中優先度の通知がまったく来ない場合、DLP ルールの有無を最初に確認してください。

通知メールの未設定

Alert Center はデフォルトでダッシュボードに表示されますが、メール通知は別途設定が必要です。設定していない場合、管理コンソールを自ら開かない限りアラートに気づけません。設定後、過去のアラートを開いて「通知済み」の記録があるかを確認してください。

誤検知（False Positive）への対処

正常なユーザー行動が「不審なアクティビティ」として検知されることがあります。たとえば出張中に海外 IP からログインした場合に「不審なログイン」として検知されるケースです。このような場合は Alert Center のメモ欄に「当該ユーザーへの確認済み・正常なアクセスと確認」と残してクローズします。誤検知をそのまま放置すると後日の監査でノイズになるため、判断と記録はセットで行います。

Alert Center と管理者監査ログの違い

「管理者が意図的に行った設定変更」は Alert Center には表示されず、管理コンソールの「監査と調査」配下にある管理者ログに記録されます。Alert Center はあくまで Google が外部脅威・異常行動として検知したイベントに特化した通知ツールです。「誰が何の設定を変更したか」の追跡には管理者ログ、「外部脅威 / 異常なユーザー行動」の検知には Alert Center と役割を切り分けて把握しておくと混乱が減ります。

まとめ

Alert Center は GWS に組み込まれたセキュリティ通知の基盤で、追加費用なしで利用できます。ただし「存在するだけ」では機能しません。通知先を決める・優先度で絞る・対応フローをチームで共有する、この3ステップを先に設計しておくことで、インシデント発生時の初動が安定します。

具体的な最初の一手としては、以下の順で進めるのが現実的です。

1. スーパー管理者の権限を確認し、バックアップ担当者を確保する
2. 高優先度アラートの通知先（個人または Google Group）を設定し、実際に通知が届くことを確認する
3. DLP ルールの有無を確認する
4. 週次の確認カレンダーブロックを作る
5. 初動対応の判断基準（停止・報告・クローズの条件）を1枚のメモにまとめてチームで共有する

API 自動化はその次のステップです。UI で運用フローを回してパターンが見えてきた段階で自動化を検討する順序が、現場での安定運用につながります。Alert Center の設定は一度作って終わりではなく、体制変更・メンバー変更のタイミングで見直す習慣を持つことが、長期的なセキュリティ体制の成熟につながります。

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

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