AWSエンジニアのためのGoogle Cloudサービスまとめ その10 Google Workspace管理編

0. はじめに

前回はデベロッパーツール系のサービスをまとめました。今回はその第10弾として、Google Workspaceの管理機能を扱います。

これまでの9回はコンピューティングからデベロッパーツールまで、AWSのサービスとGoogle Cloudのサービスを1対1で対比する形式で進めてきました。ですが今回のGoogle Workspaceは、Gmail・Drive・カレンダー・Chat・Meetなどを束ねた生産性スイートであり、AWSにはこのスイート全体に相当する単一製品がありません(Amazon WorkMailはメール機能のみが対応領域で、スイート全体の代替にはなりません)。第5回(セキュリティ・ID管理編)の対応表には「グループウェア: - ↔ Google Workspace」として1行だけ記載しているため、本記事は対応表ではなく管理機能ごとの解説で構成します。

1. Google Workspace管理機能

1-1. Google Vault(法的ホールド・eディスカバリ)

AWSに直接対応するサービスはなく、法務・監査目的でデータを保持するためのGoogle Workspace独自の仕組みです。

• 案件(Matter)を作成し、その中に保存要求(Hold)を設定してデータを保持します。保存要求はサービス(Gmail/Chat/Drive/Groups等)・対象範囲(ユーザーまたは組織単位)・絞り込み条件を指定できます。
• 対象ユーザーがデータを削除してもVault側にはコピーが保持され、通常の保持ルールより優先されます。
• eディスカバリでは案件単位で検索・エクスポートを行い、必要最小限のデータだけを関係者に共有します。案件へのアクセスは作成者・共有された利用者に限定できるため、調査に無関係な担当者に情報を見せずに済みます。
• Vaultは証拠の保持・検索・エクスポートが目的で、Gmailメッセージをリアルタイムに削除・隔離するインシデント対応(なりすまし対策等)には使いません。その用途は後述のセキュリティ調査ツールです。

1-2. アーカイブユーザーライセンス

退職者・長期休職者向けの低コストライセンスで、AWS側に対応する概念はありません。

• 付与するとサインインはできなくなりますが、Gmail/Driveなどのデータは組織内に残り続け、Vaultでの保持・検索・エクスポート対象になります。本人はサインイン不可ですが、管理者や権限を持つユーザーは当該アカウントのDrive/メールに引き続きアクセスできるため、業務ドキュメントの参照継続にも対応します。
• 通常ライセンスとは別課金のため、大量の退職者データを長期保持する際のコストを抑えられます。
• アカウントの一時停止(サインイン不可・通常ライセンスは維持)やパスワード変更だけでは、ライセンスコストは下がりません。データを他ユーザーへ移行してアカウントごと削除する方式は、送信者情報の混在や監査証跡の喪失につながるため、コンプライアンス目的の長期保持には向きません。

1-3. グループの種類と使い分け

Google Workspaceのグループは、目的に応じて4種類を使い分けます。

• 動的グループ: 部署・役職などのユーザー属性に対するクエリ(Common Expression Language)でメンバーシップを自動管理するグループです。属性が変われば追加・除外も自動で行われるため、人事異動が多い部門のアクセス権限管理に向きます。上位エディション(Cloud Identity Premium等)が必要になる場合があります(要確認)。
• セキュリティグループ: 通常のGoogle Groupをアクセス制御用に切り替えたグループです。メンバーは手動管理ですが、共有ドライブ等の権限付与単位としてGoogleが推奨する形式です。
• 構成グループ: 組織単位(OU)の設定(ストレージ容量上限など)を、特定ユーザーの集合にだけ上書き適用するためのグループです。「例外設定」の実装に使います。
• アクセスグループ: 特定のGoogle Workspaceサービス(Sitesなど)のON/OFFを、OU構造を変更せずに特定ユーザー集合へ適用するためのグループです。一時的なプロジェクトチームなどにサービスを限定公開したい場合、OUを新設するより変更の影響範囲が小さくなります(後述の「サービスのOU/グループ単位アクセス制御」も参照してください)。

1-4. ドメイン所有権の確認とメールルーティング

• Google Workspaceに申し込んだ直後は、DNSにGoogle指定のTXTレコードを追加してドメイン所有権を証明するまで、ユーザー作成などの管理機能の多くがロックされます。時間経過だけでは解除されません。
• ドメイン宛のメールをGmailで受信するには、①ドメインの追加・所有権確認、②DNSのMXレコードをGoogleのメールサーバーへ向ける、の両方が必要です。TLS設定やSPF/DKIM/DMARCは認証・暗号化の強化であり、配送先(ルーティング)自体は変えません。
• 配送不具合の切り分けは、まずメールログ検索(Email Log Search)でGoogle側にメールが到達しているかを確認し、到達していなければMXレコードを疑う、という順序が基本です。カレンダー招待もメールとして配送されるため、同様にAdmin Toolboxのメッセージヘッダー解析ツールでヘッダーを確認するのが定石です。

1-5. ドメインエイリアス・セカンダリドメイン

• セカンダリドメイン: 同一顧客IDの配下に別ドメイン名を追加する仕組みで、[e-mail]と[e-mail]は別アカウントとして扱われます。買収した会社を独立した組織として統合したい場合などに使います。
• ユーザーエイリアスドメイン(ドメインエイリアス): 既存アカウントに対して別ドメイン名のメールアドレスを追加する仕組みで、同一のメールボックス・同一アカウントのまま複数ドメインのアドレスを受信できます。1人のユーザーが新旧複数のブランドのメールアドレスを併用したい場合に向きます。
• 「アカウントを増やす(セカンダリドメイン)」か「アドレスだけ増やす(エイリアスドメイン)」かの違いを混同しないよう注意が必要です。

1-6. 共有ドライブのロール設計

• 共有ドライブのロールはUI表示名で管理者(organizer)・コンテンツ管理者(fileOrganizer)・投稿者(writer)・閲覧者(reader)等に分かれます。投稿者はファイルの追加・編集・閲覧はできますが、移動・削除・共有権限の変更はできません。コンテンツ管理者は追加・編集に加えて移動・削除・共有・整理まで行えます。
• 外部委託先など「編集はさせたいが削除はさせたくない」相手には投稿者ロールを付与するのが最小権限の原則に沿います。
• 150人規模など大人数のロール管理は、個々のユーザーに直接付与するのではなくGoogleグループ単位でロールを付与すると運用が効率化します。

1-7. Driveラベルによるファイル検索

• Driveラベルはファイル・フォルダに付与するメタデータで、「契約書」「機密度:高」等の属性による検索・フィルタリングを可能にします。キーワード検索は表記揺れや本文中の偶発的な一致に弱く、正式な分類として整理されたラベル検索の方が精度が高くなります。

1-8. Driveの共有範囲制御とDLP

• ドメインのドライブ共有オプションには「内部のみ」「許可リストドメインに限定」などがあります。内部コラボレーションを維持しつつ外部への共有だけを禁止したい場合は「内部のみ」、特定の信頼できる外部パートナーとだけ共有したい場合は「許可リストドメイン」を使います。「共有を完全に無効化」は業務への影響が大きいため過剰な対応になりやすい選択肢です。
• Drive DLP(データ保護ルール)は、クレジットカード番号など事前定義された検出器でファイル内容をスキャンし、条件に合致したファイルの外部共有を自動ブロックしつつイベントをログに記録できます。予防的コントロール(ブロック)と検出的コントロール(ログ)を同時に満たせる点が、サードパーティDLP導入や保持ポリシーによる自動削除よりも直接的です。

1-9. Gmailのコンプライアンスルール

• 管理コンソールのGmail設定には、件名・本文・添付ファイル種類などを条件に拒否・隔離・件名書き換え等のアクションを自動適用するコンテンツコンプライアンス・添付ファイルコンプライアンスルールがあります。
• 「特定のファイル種類を送受信させない」場合は添付ファイルコンプライアンス、「特定キーワードを含むメールの外部転送を禁止する」場合はコンテンツコンプライアンスが対応する標準機能です。
• 承認済み送信者リストは、信頼できる特定の送信者・ドメインからのメールをスパムフィルタリングの対象外にする機能です。既知の取引先からのメールが誤ってスパム判定される場合、ドメイン全体のフィルタ強度を下げるより、この機能でピンポイントに例外を設ける方が追加リスクを抑えられます。組織全体で大量の誤判定が起きている場合は、テナント側の設定変更ではなくGoogle Workspaceサポートへの報告(バックエンドのスパム判定ロジックの問題である可能性)が推奨されます。

1-10. なりすまし・フィッシング対応(セキュリティ調査ツール)

• セキュリティ調査ツール(Security Investigation Tool)は、Gmail・Drive・ログイン・Meet等のイベントを横断的に検索し、該当する対象に対して削除・隔離・フィッシング指定・会議終了などの一括アクションを実行できる管理者向けツールです。フィッシングメールの受信者特定と一括削除、無監督のMeet会議の一括終了、データ侵害調査時のデバイス・アプリケーション横断調査など、幅広いインシデント対応の起点になります。
• フィッシングメールは「フィッシングとしてマーク」で分類し(スパムと分類先を混同しないよう注意)、Gmailのなりすまし防止と認証保護の安全オプションを有効化することで、当面の封じ込めと将来的な検知精度向上の両方に対応できます。

1-11. TLS準拠ポリシー

• 金融機関など特定の外部ドメインとの間でメッセージの盗聴・改ざんリスクを抑えたい場合、Gmailの設定で対象ドメイン一覧に対してTLS(トランスポート層セキュリティ)接続を必須にし、TLS接続の検証を有効化できます。SPF/DKIM/DMARCは送信元のなりすまし対策(認証)、Gmail機密モードは受信者側の閲覧・転送制御であり、いずれも経路上の盗聴対策(暗号化)そのものではありません。

1-12. モバイルデバイス管理レベル

• 基本管理: OS標準機能を使い、エージェントアプリのインストールなしでパスコード強制やアカウントワイプ(端末上の組織アカウントだけを削除)を適用できます。追加ライセンス不要でiOS/Android双方に同一ポリシーを適用できるため、BYOD環境でエージェント不要・低コストという制約がある場合に適します。
• 高度な管理: エージェントやプロファイルの導入を前提に、端末全体のワイプやアプリ配信など、より強力な制御が可能です。要件が「アカウントレベルの保護」にとどまる場合は基本管理で十分で、高度な管理は過剰な選択肢になりやすいといえます。

1-13. AppSheet

Googleが提供するノーコードアプリ開発プラットフォームです。

• スプレッドシート等のデータソースを指定するだけで、Web・モバイル双方に対応した業務アプリ(承認ワークフロー含む)を構築できます。開発者不在・外部委託予算なしという制約下で、Webとモバイル双方に対応した業務アプリが必要な場合の第一候補です。
• Apps Scriptはコードを書く前提の自動化機能で、非開発者中心の要件には荷が重い選択肢です。

1-14. アクティビティルール

• Google Workspaceセキュリティセンターの機能で、Gmail・デバイス・ユーザーのログイベントを対象に、期間としきい値の条件(例:1時間以内に20回以上のログイン失敗)を定義し、条件に合致した場合にパスワード変更の強制やアラート通知などのアクションを自動実行できます。単なるメール通知はユーザーの対応漏れに依存するため、「義務付ける」対応が必要な場合は強制アクションを伴うルールを選びます。
• ログイン失敗回数のような履歴情報は「ユーザーログイベント」をデータソースに使います(現在の状態を示す「ライブ状態データソース」とは性質が異なります)。

1-15. Meetライブ配信の視聴制限

• Google Meetの管理コンソールには、会議への参加や配信の視聴を許可する範囲を制御する設定があります。ただし「自社ドメインに加えて指定した関連ドメインのみライブ配信の視聴を許可する」という具体的な仕組みについては、公式ドキュメントで裏取りできていません(要確認)。近い設定として参加範囲を制御するmeet.safety_access(任意のWorkspace組織を許可するかどうか)やmeet.joining(信頼済みの参加者のみを許可するかどうか)がありますが、いずれも「視聴」ではなく「参加」を制御する設定である可能性があり、本節の記述と一致するかは未確認です。

1-16. カレンダーリソース管理

• 会議室等はカレンダーリソース(Building/CalendarResource)として登録し、収容人数・設備(プロジェクター等)・階数などの属性を付与します。属性はユーザーがカレンダーで部屋を検索・絞り込みする条件になります。
• 多数の会議室を新規登録・属性変更する場合は、管理コンソールでのCSV一括アップロードが最も効率的です。既存リソースの削除・再作成は、そのリソースが参加者として登録済みの予定に影響するため、属性変更だけの目的では避けます。
• 会議室へのアクセス(閲覧・予約)を特定チームに限定したい場合は、リソースカレンダー自体の共有設定(権限)を対象グループに絞ります。

1-17. Chatのモデレーション

• Google Chatのスペースには、メッセージ削除やメンバー追加・削除などスペース運営に必要な権限を持つモデレーターロールがあります。不適切な投稿やスパムを現場レベルで即座に対処したい場合、DLPやセキュリティ調査ツールのような横断的・管理者向けの機能ではなく、信頼できる従業員にモデレーターを割り当てるのが直接的な対応になります。

1-18. メール委任と共同受信トレイ

• メール委任(Delegated access): 役員のアシスタント業務など、1対少数の代理対応に向きます。パスワードを共有せず、委任先ユーザーは自分のアカウントでログインしたまま対象アカウントのメールを閲覧・送受信できます(委任できる人数には上限がありますが、具体的な人数・対象範囲の条件は要確認です)。
• 共同受信トレイ(Collaborative Inbox): Google Groupの特別なモードで、外部顧客からの問い合わせメールをチームで分担処理する用途に向きます。投稿権限を「ウェブ上の誰でも」に設定すれば外部顧客からのメール受付窓口になり、担当者の割り当てや対応ステータス管理が可能です。アカウント共有(ID/パスワードを複数人で使い回す)は監査性が失われるため避けます。

1-19. カスタム管理者ロールと最小権限

• Directory APIのロールベースアクセス制御(RBAC)により、必要な権限(プリビレッジ)だけを含むカスタム管理者ロールを作成し、ユーザーに割り当てられます。セキュリティ調査ツールなど特定機能だけを使わせたいチームには、その機能に必要な権限に絞ったカスタムロールを付与し、スーパー管理者ロールのような広範な権限は与えません。

1-20. Chromeブラウザ管理

• Chromeウェブストアポリシー(許可/ブロックモード): 「すべて許可+管理者がブロックリストを管理」と「すべてブロック+管理者が許可リストを管理」の2方式があります。審査済みアプリ以外をすべて禁止したい(Default Deny)場合は後者を使います。前者(ブラックリスト方式)は未知の危険なアプリの後追い対応にとどまり、既にインストール済みの未承認アプリの洗い出しと登録が必要で、見落としが生じやすくなります。
• デバイスポリシーとユーザーポリシー: Chrome管理の適用対象は「デバイス」と「ユーザーとブラウザ」に分かれます。共有端末など「誰がログインしても同じ制限をかけたい」場合はデバイスポリシー側でアプリ・拡張機能を制御します。ユーザーサインイン必須化や2段階認証は認証強化の話であり、端末上で使えるアプリの制御とは別レイヤーです。
• 拡張機能の強制インストール(ExtensionInstallForcelist): 管理者が指定した拡張機能をユーザー操作なしに自動インストールし、ユーザーは無効化・削除できません。「許可リストに載せる」だけでは自動インストールされない(ユーザー自身がストアからインストールする必要がある)点を混同しないよう注意します。

1-21. サービスのOU/グループ単位アクセス制御

• YouTubeやMerchant Centerなど個別サービスのON/OFFは、管理コンソールの「アプリとサービス」設定で組織単位(OU)またはグループ単位に切り替えられます。「特定のグループだけに許可」したい場合に全社一律でONにしてしまうと要件を満たしません。

1-22. Google Groups for Businessの外部アクセス制御

• 「この組織外からのグループへのアクセス」をドメインレベルで「非公開」に設定すると、組織内ユーザーが外部ドメインのGoogleグループを検索・閲覧・参加することを一括で禁止できます。社内グループの作成・利用には影響しません。
• 「会話の閲覧権限のデフォルト」設定は社内公開範囲(内部向け)の制御であり、外部グループへの参加可否とは無関係です。どちら向き(外部へ出ていく/外部から入ってくる)の制御かを混同しないよう注意します。

1-23. トラブルシューティングの基本パターン

• HARファイル: 断続的でユーザー環境に依存するGmail等の遅延・エラーは、管理者側で再現しにくいことが多くあります。次回発生時にブラウザの開発者ツールでHAR(HTTP Archive)ファイルを取得してもらうと、リクエストごとの応答時間やエラーコードなど、証拠に基づく原因切り分けができます。キャッシュ削除や別端末での再現確認は暫定対応にとどまり、根本原因の特定にはつながりにくい対応です。
• セキュリティ状態(セキュリティセンター/アラートセンター): Gmail・Drive・カレンダー等のセキュリティ設定を推奨値と比較して一覧できるダッシュボードです。半期ごとのリスク評価など「複数サービスの設定を迅速に俯瞰したい」場面に向きます。個別のレポート画面(利用状況の集計)やアラートセンター(発生済みイベントの通知)は、設定そのものの健全性を俯瞰する目的には代替になりません。

2. まとめ

今回はこれまでの1対1対応表形式から離れ、Google Workspaceの管理機能を独立した回としてまとめました。

Vaultやアーカイブユーザーライセンスのように法務・コンプライアンス目的でAWS側に対応概念がないものもあれば、共有ドライブのロール設計やカスタム管理者ロールのように「最小権限の原則」というIAMと共通する考え方が根底にあるものもあり、AWSの知識がそのまま応用できる部分と、Google Workspace特有の仕組みとして新たに覚える必要がある部分が入り混じっているという印象です。

Google Workspace管理者ロールを担当される方にとって、この記事が頭の整理の助けになれば幸いです。

参考