プレイブック

HR提供のCSVファイルから数百人の新規ユーザーをオンボーディングします。

→管理コンソールの「一括アップロード」機能を使用します。ユーザーを正しいOUに直接配置するために、CSVに「組織部門パス」列を含めます。

理由: スクリプトを使用せずに、正しいポリシー割り当てで大量のユーザーを作成する最も効率的な方法です。一度限りのオンボーディングではGCDSよりも直接的です。

従業員が退職します。その従業員のDriveファイルを保持し、マネージャーの管理下に転送します。

→ユーザーを停止または削除する前に、管理コンソールの「データ転送」ツールを使用して、すべてのDriveファイルの所有権をマネージャーに転送します。

理由: データ整合性を維持し、事業継続性を確保します。直接的な所有権転送は、共有よりもクリーンで、明確な監査証跡を維持します。

異なる部署やチームが独自のサービス設定とセキュリティポリシーを必要としています。

→階層的な組織部門（OU）構造（例：/Sales/East, /Sales/West）を作成します。親OUで広範なポリシーを適用し、子OUで特定のオーバーライドを適用します。

理由: OUは階層的なポリシー継承を提供し、異なるユーザーグループの設定を拡張可能かつきめ細かく制御できます。

新入社員を含め、エンジニアリング部門の全ユーザーのグループメンバーシップを自動化します。

→ユーザー属性 `department==Engineering` に基づくメンバーシップクエリを使用して、ダイナミックグループを作成します。

理由: ユーザー属性に基づいてメンバーシップを自動的に管理し、手動更新を排除し、ユーザーの役割変更に伴う一貫性を確保します。

ヘルプデスクスタッフに、メインオフィスOUのユーザーのパスワードのみをリセットできる権限を付与します。

→「ユーザー > パスワードのリセット」権限のみを持つカスタム管理者ロールを作成します。このロールをヘルプデスクチームに割り当て、対象のOUのみに適用されるようにスコープを設定します。

理由: 最小特権の原則を実装します。カスタムのスコープ付きロールにより、委任された管理者が担当外のユーザーや設定に影響を与えることを防ぎます。

GCDS経由でActive Directoryから同期していますが、ユーザーのUPNに古いドメインが含まれています。新しい正しいドメインを持つユーザーを作成する必要があります。

→GCDSで、メールアドレス属性の属性変換ルールを設定し、古いドメイン文字列を新しいものに置き換えます。

理由: ソースのActive Directoryの変更を必要とせず（これはしばしば実行不可能）、同期プロセス中にデータを修正します。

ユーザーが15日前に誤って削除されました。マネージャーがそのユーザーのDriveから重要なファイルを必要としています。

→管理コンソールから、最近削除されたユーザーを復元します。復元期間は20日間です。復元後、データを転送し、必要であれば再削除します。

理由: 削除されたユーザーは20日間復元可能です。Vaultの保留/保持が設定されていない場合、そのデータを復元する唯一の方法です。

サポートチームが、複数のメンバーが顧客からの問い合わせを管理、割り当て、追跡できる共有メールアドレス（support@）を必要としています。

→Googleグループを作成し、「共同受信トレイ」として設定します。

理由: このグループタイプは共有ワークフロー向けに設計されており、会話の割り当てと解決の追跡が可能で、標準の配布リストや共有ユーザーアカウントよりも優れています。

営業部門からのすべての送信メールに、標準化された法的免責事項とブランドを強制します。

→Gmail設定で、営業OUにスコープを設定した「フッターを追加」アクションを含むコンプライアンスルールを設定します。

理由: これにより、編集不可能なフッターがサーバーレベルで追加され、100%のコンプライアンスが保証されます。ユーザー側のソリューションは変更またはバイパスされる可能性があります。

ユーザーがDriveファイルを外部と共有することを許可しますが、特定の承認されたパートナードメインとのみ共有できるようにします。

→Driveの共有設定で、パートナードメインを「許可リストドメイン」に追加し、共有ポリシーを「許可リストドメインのみ」に設定します。

理由: セキュリティとコラボレーションのバランスを取り、承認されていない外部とのデータ共有を防ぎつつ、承認されたパートナーシップを可能にします。

Google Meetに外部ゲストを許可しますが、内部ホストが到着する前に参加するのを防ぎます。

→Google Meetの安全設定で、「組織外のユーザーはホストの許可が必要」（ノック）が有効になっていることを確認します。

理由: 仮想ロビーを作成することで会議のセキュリティが強化され、ホストはいつどの外部参加者が参加できるかを制御できます。

オンプレミスExchangeサーバーからGmailへの移行を、受信メールのダウンタイムなしで行います。

→デュアル配信を設定します。Workspaceでメールルートを設定してレガシーExchangeサーバーにメールを転送し、その後MXレコードをGoogleに向けます。

理由: 段階的な移行中にユーザーが両方のメールボックスでメールを受信できるようにし、メッセージの損失を防ぎ、スムーズな移行を可能にします。

ユーザーがDocs、Sheets、Gmailで未承認のサードパーティ製アドオンをインストールするのを防ぎます。

→Marketplace設定で、承認済みアプリケーションの許可リストを設定し、ユーザーを許可リストのアプリのみに制限するポリシーを設定します。

理由: IT承認済みのツールの「walled garden」を作成することで、悪意のある、またはデータ収集を目的としたサードパーティ製アプリによるセキュリティリスクを軽減します。

コンプライアンスのため、ユーザーがメールボックスから削除しても、すべてのメールを7年間保持する必要があります。

→Google Vaultで、Gmail用に期間7年のカスタム保持ルールを作成します。有効期限は設定しないでください。

理由: Vaultの保持はユーザーの操作とは独立して機能します。これは、ライブユーザーメールボックスとは別に、eDiscoveryおよびコンプライアンスのための法的防御可能なアーカイブを提供します。

法務部門は、係争中の訴訟のために、特定の従業員（保管担当者）に関するすべてのデータを無期限に保持することを要求しています。

→Google Vaultで「案件」を作成し、ユーザーを保管担当者として識別し、それらに「法的保留（Legal Hold）」を適用します。

理由: 法的保留はすべての保持および削除ポリシーを上書きします。保留が明示的に解除されるまでデータは保持され、法的な保存義務が確実に満たされます。

ユーザーがクレジットカード番号やPIIを含むドキュメントを誤って外部と共有するのを防ぎます。

→「セキュリティ > データ保護」でデータ損失防止（DLP）ルールを作成します。事前定義された検出器（例：クレジットカード番号）を使用し、外部共有のトリガー条件を設定します。アクションは「外部共有をブロック」に設定します。

理由: DLPはコンテンツをリアルタイムでスキャンし、データ保護ポリシーを自動的に適用することで、人為的ミスによるデータ侵害のリスクを軽減します。

GDPRに準拠するため、ヨーロッパの従業員のすべてのプライマリデータがヨーロッパのデータセンターに保存されることを保証します。

→ヨーロッパのユーザーを専用のOUに配置します。「アカウント > データリージョン」で、そのOUに「ヨーロッパ」のデータリージョンポリシーを適用します。

理由: この機能は、特定のサービスのプライマリデータの地理的な保存場所を制御することで、データレジデンシー要件に直接対応します。

ユーザーが10日前に重要なDriveファイルを完全に削除しました。そのファイルはもうゴミ箱にありません。

→Vaultの保持ルールまたは保留がユーザーをカバーしていた場合、Vaultでファイルを検索し、復旧のためにエクスポートします。

理由: Vaultはセーフティネットとして機能します。保持/保留によってカバーされるデータは、ユーザーによって「完全に」削除された後でも保持されます。

法的保留中の従業員が退職します。そのデータを保持し、保留を維持しつつ、完全なライセンスを解放する必要があります。

→ユーザーアカウントを停止し、「アーカイブ済みユーザー」（AU）ライセンスを割り当てます。データはVaultに残り、保留の対象となります。

理由: AUライセンスは、フルアクティブライセンスを消費することなく、コンプライアンスおよび法務目的で元従業員のデータを保持するための費用対効果の高い方法です。

企業の管理対象デバイスから、またはオフィスネットワークに接続している場合にのみWorkspaceへのアクセスを許可します。

→Context-Aware Accessを設定します。「準拠デバイス」（エンドポイント管理から）および「企業IP範囲」のアクセスレベルを作成します。アクセスにこれらのレベルのいずれかを要求するポリシーを適用します。

理由: これはWorkspaceのゼロトラストモデルの中核であり、ネットワーク境界からデバイスとユーザーのコンテキストに基づいてアクセスポリシーを強制するようにシフトし、場所に関係なく適用されます。

ユーザーアカウントが侵害された疑いがあります。攻撃者がアクティブなセッションやアプリアクセスを持っている可能性があります。

→直ちに：1) ユーザーのパスワードをリセットします。2) すべてのサードパーティOAuthトークンを取り消します。3) すべてのWebセッションからサインアウトさせます。

理由: この3段階のプロセスにより、攻撃者がすべてのアクセスポイント（直接ログイン、アプリベースのアクセス、既存のブラウザセッション）から締め出されることが保証されます。

ユーザーがリスクのある、または未承認のサードパーティOAuthアプリケーションに企業データへのアクセスを許可するのを防ぎます。

→「セキュリティ > APIコントロール」で、「アプリアクセス制御」を設定して、未設定のアプリをデフォルトでブロックし、その後、特定の承認済みアプリを「信頼済み」リストに追加します。

理由: これにより、サードパーティ製アプリのセキュリティ体制がデフォルト許可からデフォルト拒否に移行し、IT部門がどのアプリケーションが会社のデータにアクセスできるかを完全に制御できるようになります。

サードパーティIdPとのシングルサインオン（SSO）を実装しますが、IdPがダウンした場合の管理者アクセスを確保します。

→組織全体でSAML SSOを設定します。スーパー管理者のための個別のグループまたはOUを作成し、ネットワークマスクまたはグループ設定を構成して、SSO要件からそれらを除外します。

理由: 重要な「break-glass」手順を提供し、管理者がIdPの停止中にGoogleの認証情報でログインして環境を管理できるようにします。

フィッシング攻撃でドメインがなりすまされるのを防ぎ、メールの配信可能性を向上させます。

→ドメインのSPF、DKIM、およびDMARC DNSレコードを適切に設定します。完全な強制のためにDMARCポリシーを `p=reject` に設定します。

理由: これら3つの標準が連携して送信メールを認証し、受信者サーバーがドメインになりすます不正なメッセージを自信を持って拒否できるようにします。

不審なログインや政府機関支援の攻撃警告など、セキュリティイベントの事前通知が必要です。

→アラートセンターを定期的に監視します。高優先度のイベントについて、セキュリティチームにメール通知を送信するようにアラートルールを設定します。

理由: アラートセンターはセキュリティ関連イベントの一元化されたハブです。 proactiveな通知により、迅速なインシデント対応が可能になります。

ユーザーが電話を紛失し、バックアップコードもないため、2SV保護されたアカウントからロックアウトされました。

→管理者として、ユーザーを選択し、1回限りのバックアップ確認コードを生成して、アクセスを回復させます。

理由: これは、2SVを一時的に無効にすることなく（これはセキュリティを弱めます）、ユーザー回復を行うための標準的で安全な手順です。

高リスクユーザーをフィッシングから保護するために、最も強力な認証形式を義務付けます。

→セキュリティキー（FIDO）のみの使用を義務付ける2段階認証ポリシーを適用します。

理由: セキュリティキーは公開鍵暗号を使用し、ログインページの起源を検証するため、フィッシング耐性があります。これは、フィッシングされる可能性のあるTOTPやSMSとは異なります。

機密データを含む会社の管理対象携帯電話が紛失または盗難されました。

→管理コンソールのデバイスセクションで、デバイスを見つけて、直ちにリモート「デバイスをワイプ」コマンドを開始します。

理由: これは、紛失した管理対象デバイスに対する主要なセキュリティ対応です。デバイスをリモートで工場出荷時の状態にリセットするか、仕事用プロファイルをワイプして、企業データを不正アクセスから保護します。

すべての企業Chromeブラウザ（Windows、Mac）に、標準のセキュリティ設定と必須の拡張機能を適用します。

→ブラウザをChrome Browser Cloud Management（CBCM）に登録します。ユーザー/ブラウザOUにポリシーを適用して、拡張機能の強制インストール、その他のブロック、設定の構成を行います。

理由: CBCMは、あらゆるプラットフォーム上のChromeブラウザを一元的にクラウドベースで管理し、一貫したポリシーとセキュリティ体制を保証します。

従業員が個人用Androidデバイスを仕事に使用できるようにし（BYOD）、企業データを分離して安全に保ちます。

→高度なモバイル管理を実装し、従業員所有デバイスにAndroid Work Profileの作成を強制します。

理由: Work Profileは、仕事用アプリとデータを個人データから隔離するOSレベルのコンテナを作成します。コンテナ全体はリモートでワイプでき、ユーザーの個人ファイルに影響を与えません。

Context-Aware Accessポリシーは、アクセスを許可する前に、デバイスが会社所有であり、暗号化されていることを検証する必要があります。

→すべての管理対象デバイスにGoogle Endpoint Verification拡張機能/エージェントを展開します。CAAアクセスレベルを、「準拠」または「会社所有」のデバイスステータスを要求するように構成します。

理由: Endpoint Verificationは、CAAエンジンにデバイスの状態を収集して報告するエージェントであり、デバイスの信頼に基づくアクセス制御を可能にします。

ユーザーが特定のパートナーへのメールがバウンスされるか、著しく遅延すると報告しています。

→管理コンソールの「メールログ検索」ツールを使用します。サンプルメッセージを検索して、完全な配信パス、タイムスタンプ、および受信者サーバーからの拒否エラーを確認します。

理由: メールログ検索は、配信問題を診断するための決定的なツールです。メッセージがGoogleを離れたかどうか、そしてなぜ拒否されたのかについて詳細な情報を提供します。

組織全体の複数のユーザーが突然ログインできなくなり、認証情報検証エラーが報告されています。

→問題はサードパーティのIdentity Provider（IdP）にある可能性が高いです。IdPサービスのステータスと、SSO構成内のSAML証明書の有効性を確認します。

理由: SSO環境における広範囲にわたる突然のログイン障害は、ほとんどの場合、個々のユーザーアカウントではなく、外部のIdPが原因です。

ユーザーがGoogle Authenticatorアプリからの6桁のコードが常に拒否されると報告しています。

→ユーザーにモバイルデバイスの時計を確認して同期するように指示します。Authenticatorアプリには時間補正機能があります。

理由: 時間ベースOTP（TOTP）コードは、同期された時間に強く依存します。時計のずれは、コードが拒否される最も一般的な原因です。

特定のオフィスのユーザーがGoogle Meetのビデオ品質が悪いと不平を言っていますが、他のオフィスでは問題ありません。

→影響を受けるオフィスのローカルネットワークを調査します。帯域幅の飽和、高い遅延/ジッターを確認し、ファイアウォールルールがGoogle Meetトラフィックをスロットリングまたはブロックしていないことを確認します。

理由: 場所固有のパフォーマンス問題は、Googleサービス自体ではなく、ほとんどの場合ローカルネットワークの問題が原因です。

あるユーザーだけが外部の送信者からのメールを受信していませんが、同僚は受信しています。

→ユーザーの個人のGmail設定で、受信メールをリダイレクトまたは削除している可能性のあるフィルターやブロックされた送信者ルールがないか確認します。

理由: 問題が単一のユーザーのみに影響する場合、原因は組織レベルのポリシーではなく、ほとんどの場合ユーザーレベルの設定です。

ユーザーはMeetの録画を開始できますが、会議終了後に保存に失敗します。

→ユーザーのGoogle Driveストレージクォータを確認します。ユーザーに十分な空き容量がない場合、録画は失敗します。

理由: Meetの録画は、主催者の「マイドライブ」内の「Meet録画」フォルダに保存されます。Driveクォータがいっぱいであることが、保存失敗の最も一般的な理由です。