Google Workspace管理者が最初にやるセキュリティ設定10項目

Google Workspaceの初期セキュリティ設定とは、管理コンソール（admin.google.com）の緩い既定値を、2段階認証の必須化・管理者権限の分離・外部共有の制限・Gmail保護・OAuthアプリ制御などで会社の運用に合わせて締める作業です。契約直後のWorkspaceは「誰でも外部共有でき、2段階認証は任意で、どんなサードパーティアプリにもドライブを渡せる」状態で、この既定値のまま使い続けている会社が少なくありません。

対象はBusiness Starter以上のエディションで使える範囲で、管理者が最初の1〜2週間でやるべき10項目を、設定場所と推奨値、その設定を入れると何が起きるかまで含めて並べます。メニュー名は執筆時点のもので、Googleは項目の移動をよく行うため、見つからない場合は管理コンソール上部の検索ボックスに設定名を入れてください。

2段階認証の必須化とパスキー

設定場所は「セキュリティ → 認証 → 2段階認証プロセス」です。既定では「ユーザーに2段階認証プロセスの使用を許可する」がオンでも、「適用」がオフなので誰も強制されていません。適用は「今すぐ」ではなく開始日を指定し、未登録の既存ユーザーには開始日までの登録を案内します。開始日を過ぎると未登録のユーザーはログインできません。「新規ユーザーの登録期間」は、入社後に作成したアカウントに与える猶予（1日〜6か月）で、既存ユーザーには効きません。開始日も登録期間も設定せずに即時適用すると、翌朝の全社ロックアウトになります。

「方法」は「確認コード（SMS・音声通話）を除くすべて」を選びます。SMSはSIMスワップやフィッシングに弱く、Googleからのプロンプト（スマホに「ログインしようとしていますか」と出る方式）かパスキーに寄せたほうが安全です。パスキーは「セキュリティ → 認証 → パスワード不要」で「ユーザーがパスキーを使用してログイン時にパスワードをスキップできるようにする」をオンにすると、ユーザーがスマホやPCの生体認証でログインできるようになります。適用は組織部門（OU）単位でできるので、まず情シスのOUで1週間運用し、次に管理職、最後に全社の順にすると問い合わせが分散します。全社展開の進め方はMFAを全社導入する手順で詳しく扱っています。

管理者アカウントの分離と特権管理

特権管理者（スーパー管理者）は、Workspaceのすべての設定とすべてのユーザーのデータに手が届く権限です。日常のメールやドキュメント編集に使うアカウントに特権管理者を付けていると、フィッシングメール1通で会社全体のデータが危険にさらされます。[email protected]のような管理専用アカウントを別に作り、そちらだけに特権管理者を割り当て、日常アカウントからは外します。管理専用アカウントにはライセンスが必要ですが、その代わりに2段階認証の方法を「セキュリティキーのみ」にし、復元用の電話番号とメールアドレスを必ず登録しておきます。

特権管理者は2人（1人が退職・不在でも困らない数）にとどめ、ヘルプデスク業務は「アカウント → 管理者ロール」の事前定義ロール（ヘルプデスク管理者、ユーザー管理者、グループ管理者、サービス管理者）で委任します。ヘルプデスク管理者はパスワードリセットしかできず、ユーザー管理者はユーザー作成や停止までできますが管理者ロールの付与はできません。特権管理者を増やす代わりにこれらを使うと、「誰が何をできるか」が監査で説明できます。特権管理者は、SSOをサードパーティのIdPに向けている場合でも常にGoogleのログイン画面を使う点にも注意してください。

ドライブの外部共有設定

「アプリ → Google Workspace → ドライブとドキュメント → 共有設定」を開きます。既定では「組織外との共有」がオンで、しかもGoogleアカウントを持たない相手にもリンクで共有できる状態です。推奨値は次の通りです。

「オフ」を全社に適用するのは、営業や広報の業務を止めることになるのでおすすめしません。取引先が多くて許可リストの維持が現実的でない会社では、共有を「オン」のまま「警告を表示」と「アクセスチェッカー: 受信者のみ」を入れ、外部共有されたファイルの一覧を「レポート → 監査と調査 → ドライブのログイベント」で月次確認するほうが、実効性があります。

Gmailの保護（添付ファイル、リンク、なりすまし）

「アプリ → Google Workspace → Gmail → 安全性」に、添付ファイル・リンクと外部画像・なりすましと認証の3つのグループがあります。それぞれに「すべて有効にする（推奨設定を適用）」があるので、まずこれを押し、各項目の「アクション」を確認します。添付ファイルの「信頼できない送信者からの暗号化された添付ファイル」と「スクリプトを含む添付ファイル」は「隔離」、リンクの「短縮URLの背後にあるリンクを識別する」と「信頼できないドメインへのリンクをクリックしたときに警告する」はオン、なりすましの「類似ドメイン名によるなりすまし」「従業員名のなりすまし」「受信メールでの自ドメインのなりすまし」「未認証のメール」は「警告を表示」から始めて、誤検知の状況を見て「迷惑メールフォルダに移動」へ上げます。

「受信メールでの自ドメインのなりすまし」と「未認証のメール」の保護は、自社ドメインのSPF・DKIM・DMARCが正しく設定されていることが前提です。設定が不完全だと、自社の複合機や業務システムからの通知メールが「なりすまし」として警告されます。SPF・DKIM・DMARCの設定手順を先に済ませてから、この項目をオンにしてください。もう1点、「迷惑メール、フィッシング、不正なソフトウェア」の「承認済み送信者リスト」にドメイン単位で取引先を登録するのは避けてください。承認済み送信者は迷惑メールフィルタを素通りするため、取引先のなりすましがそのまま受信トレイに入ります。

サードパーティアプリ（OAuth）のアクセス制御

「Googleでログイン」や「Googleドライブと連携」の裏側では、OAuthという仕組みでアプリにトークンが渡されています。このトークンはユーザーがパスワードを変えても有効なままで、アプリ側が侵害されればドライブやGmailの中身がそのまま読まれます。既定では、ユーザーが同意画面で「許可」を押せばどんなアプリにも渡せる状態です。

設定場所は「セキュリティ → アクセスとデータ管理 → APIの制御 → サードパーティ製アプリのアクセスを管理」です。「未設定のサードパーティ製アプリ」を「制限付き（機密性の高いスコープや制限付きスコープを要求しないアプリのみ許可）」にすると、ログインだけのアプリは通り、ドライブ全体やGmailの読み取りを要求するアプリはブロックされます。会社として使うSlackやZoom、会計SaaSなどは「設定済みアプリ」にクライアントIDで登録し、「信頼済み」にします。「Googleサービスへのアクセスを許可しない」まで締めると「Googleでログイン」自体が止まるので、SSOを全面的に別のIdPに寄せている会社以外には向きません。

制限を入れる前に、「レポート → 監査と調査 → OAuthログイベント」と「セキュリティ → APIの制御 → アプリのアクセス制御 → アプリの一覧」で、現在どのアプリが何のスコープでトークンを持っているかを確認してください。いきなり「制限付き」にすると、営業部が使っている名刺管理アプリやスケジュール調整ツールが翌朝から「Error 400: admin_policy_enforced」で使えなくなり、その問い合わせが情シスに集中します。使われているアプリを先に「信頼済み」に登録してから制限をかける順序が正解です。

エンドポイント管理（基本モバイル管理）

「デバイス → モバイルとエンドポイント → 設定 → ユニバーサル設定」で、モバイル管理のレベルを「基本」か「詳細」から選びます。基本モバイル管理は端末にアプリを入れずに動き、画面ロックの必須化、端末一覧の把握、会社アカウントのリモートワイプ（端末全体ではなくWorkspaceアカウントのデータだけ消す）ができます。私物スマホでメールとカレンダーだけ見る運用なら、この基本管理で十分です。詳細管理は仕事用プロファイル（Android）やApple MDM証明書の登録が必要になる代わりに、アプリ配布やパスコードの複雑さ指定ができます。

Windows PCについては、Workspaceの「Windowsデバイス管理」（Google Credential Provider for Windowsを端末に入れて使う）で基本的な管理は可能ですが、BitLockerの強制や更新制御まで求めるなら、Microsoft Intuneなどの専用MDMのほうが機能が揃っています。Workspace中心の会社で「PCは台帳とディスク暗号化の確認だけできればよい」なら、Windowsデバイス管理で足ります。

監査ログとアラート

ログは「レポート → 監査と調査」の下に、管理ログイベント（設定変更・ロール付与）、ログインイベント、ドライブのログイベント、OAuthログイベント、ユーザーのログイベントなどに分かれています。保持期間はログの種類ごとに異なり、執筆時点で多くの監査ログは6か月程度ですが、種類によって短いものもあります。正確な期間はヘルプの「データの保持期間と遅延時間」の一覧で確認し、6か月を超えて保持したいログはBigQueryへのエクスポート（対応エディションのみ）か、月次でCSVをドライブに書き出す運用を決めておきます。

「セキュリティ → アラートセンター」には、Googleが検知したイベントが並びます。「ルール → システム定義のルール」で、少なくとも次のルールのメール通知をオンにしてください。「ユーザーに管理者権限が付与されました」「不審なログイン」「パスワードの漏洩」「ユーザーの一時停止（不審なアクティビティ）」「政府支援の攻撃者」です。管理者権限付与の通知は、攻撃者が侵害したアカウントに管理者を付けて足場を固める動きを最も早く教えてくれます。通知先は特権管理者の個人メールではなく、情シス複数人が見るグループアドレスにします。

退職者のオフボーディング手順

退職処理は「アクセスを止める → データを移す → 削除する」の順です。人事からの連絡当日に実施する手順をチェックリストにしておきます。

ユーザーを削除すると、その人がオーナーのドライブファイルとカレンダーの予定は、削除時に移行先を指定しない限り消えます。人事から「アカウントを消してほしい」と言われても、必ず「一時停止 → オーナー権限の移行 → 削除」の順で進めてください。削除から復元できる期間は短く、期間を過ぎたデータは戻りません。

[退職日当日: アクセス停止]
1. ユーザー → 対象ユーザー → 「ユーザーを一時停止」
   （即時にログイン不可。パスワードリセット＋「ログインCookieをリセット」でも可）
2. セキュリティ → 対象ユーザー → 「アプリパスワード」「バックアップコード」を取り消し
3. セキュリティ → 「接続済みアプリケーション」から OAuth トークンをすべて削除
4. デバイス → 対象ユーザーの端末 → 「アカウントをワイプ」（私物端末は会社データのみ消える）
5. IdP 連携している SaaS（SSO/SCIM）でアカウントが無効化されたことを確認

[1週間以内: データ移行]
6. ドライブ: アプリ → Google Workspace → ドライブとドキュメント → 「オーナー権限を移行」で後任へ
7. カレンダー: 後任へ予定の移行（削除時の「データを移行」でも可）
8. グループ・共有ドライブのオーナーを後任へ変更
9. Gmail: 一定期間のメール転送または自動応答を設定（ルーティング設定で対応）

[30〜90日後: 削除]
10. ライセンスを外して削除。長期保持が必要なら「アーカイブ済みユーザー」ライセンス（対応エディションのみ）

「一時停止」はライセンスを消費し続ける代わりに、メールもドライブもそのまま残り、20日以内なら（執筆時点）削除後の復元も可能です。監査や引き継ぎで中身を見る必要が残るうちは一時停止、確定したら削除という2段階にしておくと、「消したあとに必要なファイルがあった」という事故を避けられます。SSOで連携しているSaaS側の無効化については、SSO/SCIM対応チェックリストのオフボーディングの項を参照してください。

データのバックアップ方針

Googleのデータセンターが冗長化されていることと、自社のデータが復元できることは別の話です。ユーザーが誤って削除したファイル、ランサムウェアに感染したPCの同期クライアントが暗号化して上書きしたファイル、退職処理のミスで消えたデータは、Google側の冗長性では戻りません。標準機能で戻せる範囲と、戻せない範囲を整理します。

方針として決めるのは「何日前の状態に戻せればよいか」と「誰が復元操作をするか」の2点です。25日以内の復元で足りる会社は標準機能とVault（エディションが対応していれば）で運用し、それ以上の遡りや、退職者データの長期保持が必要な会社だけサードパーティのバックアップを契約する、という線引きが現実的です。

セキュリティダッシュボードの活用

「セキュリティ → セキュリティセンター」のダッシュボードとセキュリティの状態（推奨設定と現在値の差分一覧）は、Enterpriseなど上位エディションで使える機能です。Business StarterやStandardでは、「レポート → ユーザーレポート → セキュリティ」を使います。ここにはユーザーごとの「2段階認証の登録」「2段階認証の適用」「外部共有しているファイル数」「安全性の低いアプリへのアクセス」が列で並ぶので、月初に一度CSVで書き出し、2段階認証未登録者と外部共有数の多いユーザーをフォローする運用にします。

確認方法

設定が効いているかは、管理者権限のないテスト用アカウントで実際に試すのが確実です。個人のGmailアドレスへドライブのファイルを共有してブロックされること、未登録のサードパーティアプリで「Googleでログイン」してドライブのスコープを要求するとブロックされること、2段階認証の猶予期間が切れたアカウントでログインすると登録を強制されることを確認します。管理者権限の付与通知は、テストアカウントにヘルプデスク管理者を付けて外すことでアラートセンターのメールが届くかを試せます。

メール認証の設定は、ターミナルから次のように確認します。

$ dig +short TXT example.com | grep spf1
"v=spf1 include:_spf.google.com ~all"

$ dig +short TXT google._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A" "MIIBCgKCAQEA..."

$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:[email protected]"

つまずきポイント

2段階認証を適用したら、管理者自身がログインできなくなった

開始日を指定せず即時に適用し、管理者自身が未登録だったケースです。もう1人の特権管理者が「ユーザー → 対象ユーザー → セキュリティ → 2段階認証プロセス → バックアップコードを取得」で一時的なコードを発行できます。特権管理者が1人しかいなかった場合はGoogleのアカウント復元手続きになり、数日かかります。特権管理者を2人にし、バックアップコードを印刷して金庫に入れておくのは、この事態のためです。

「Error 400: admin_policy_enforced」でSaaSにログインできない

OAuthアプリの制限で、そのアプリが要求するスコープがブロックされているときのエラーです。エラー画面かOAuthログイベントでアプリ名とクライアントIDを確認し、業務で使うものなら「設定済みアプリ」に追加して「信頼済み」または「制限付き」で許可します。全員に影響する前に、制限をかけた直後の数日はOAuthログイベントを毎日見ておきます。

外部共有をオフにしたら、取引先との共有ドライブが見えなくなった

共有設定は既存の共有にも即座に効くため、これまで見えていた外部メンバーが一斉にアクセス不能になります。データは消えていないので、設定を「許可リストに登録済みドメインのみ」に変えて取引先ドメインを登録すれば復旧します。共有ドライブは個別に「外部メンバーを許可」の設定を持つので、そちらも確認します。

DKIMのステータスが「認証中」のまま2日以上変わらない

TXTレコードの値が途中で切れているか、ホスト名がgoogle._domainkey.example.com.example.comのように二重になっているかのどちらかです。dig +short TXT google._domainkey.example.comでv=DKIM1から始まる値が返るかを確認し、返らなければDNS側の登録を直します。

よくある質問

無料のGoogleアカウントとの違いは？

無料アカウントは個人が所有し、会社は退職時にデータを取り戻せず、2段階認証も共有範囲も強制できません。Workspaceは会社がドメインを所有し、管理コンソールからアカウントの停止・データ移行・ポリシー適用・監査ログの確認ができます。業務データを個人アカウントに置くこと自体が、この記事の設定すべてを無効にする最大の穴です。

最低限やるべき設定は？

効果と手間のバランスで選ぶなら、2段階認証の適用（開始日を指定）、特権管理者の分離と2人体制、ドライブの外部共有の既定値変更、Gmailの「推奨設定を適用」、アラートセンターの管理者権限付与通知の5つです。この5つは半日で終わり、アカウント乗っ取りと誤共有という頻度の高い事故の大半に効きます。

ログはどのくらい保持されますか？

ログの種類ごとに異なり、執筆時点では多くの監査ログが6か月程度ですが、種類によって短いものがあります。正確な期間はヘルプの保持期間一覧で確認してください。6か月を超える保持が必要な場合は、BigQueryエクスポート（対応エディション）か、月次でCSVを書き出してドライブの管理者専用フォルダに保存する運用にします。

まとめ

10項目のうち、事故の頻度から見て先に手を付けるべきなのは2段階認証の適用、特権管理者の分離、外部共有の既定値、OAuthアプリの制御の4つで、どれも「既定値が緩い」ことが原因の事故を防ぎます。制限を入れる系の設定は、必ず現状のログ（外部共有の一覧、OAuthトークンの一覧）を先に見てから適用し、業務で使われているものを許可リストに入れてから締めてください。オフボーディングとバックアップは、事故が起きる前に手順と方針を文書にしておくことが設定そのものより効きます。

次に読む

• SPF・DKIM・DMARC設定手順：Gmailのなりすまし保護を有効にする前に済ませる設定
• 多要素認証（MFA）を全社導入する手順：2段階認証の適用を全社に広げるときの周知と例外の扱い
• SaaS管理の始め方：OAuthログで見つかった未把握のアプリを台帳に載せる