Google Workspace 組織全体でMFAを強制する方法

多要素認証は、ほとんどの組織が導入できる中で最も投資対効果の高いセキュリティ対策であり、Google Workspaceでは「2段階認証プロセス（2SV）」と呼ばれています。問題は「強制する」という言葉にあります。MFAを利用可能にするだけなら簡単ですが、それだけではほとんど意味がありません。攻撃を受けやすいアカウントほど、自主的に有効化する可能性が低いからです。真の保護は、組織全体で必須化し、適切な認証要素を選び、誰もロックアウトされない展開計画を実行する「強制」から生まれます。本記事では、その展開計画を解説します。

「利用可能」は「強制」ではない

2SVが任意であれば、導入は抵抗の少ない道をたどります。技術やセキュリティに明るい従業員は登録しますが、多忙な経営幹部やサービス関連のアカウントは登録しません。攻撃者はこれを知っています。認証情報を狙うフィッシングやパスワード使い回しへの攻撃は、まさに登録をスキップしたアカウントを標的にします。任意の対策は、本来最も保護が必要でない人々を守ってしまうのです。

強制はこの状況を逆転させます。2SVが必須になれば、盗まれたパスワードだけではアカウントを乗っ取れなくなり、アカウント侵害における最も一般的な経路を一挙に無力化できます。

認証要素は意図的に選ぶ

すべての第二認証要素が同等というわけではありません。強い順に並べると以下の通りです。

• パスキーおよびハードウェアセキュリティキー（FIDO2）。 フィッシング耐性があります。正規のサイトと暗号的に紐づいているため、フィッシングページが認証情報を中継することはできません。最高水準の選択肢であり、管理者やその他の重要なアカウントには強く推奨されます。
• Googleプロンプト／認証アプリ（TOTP）。 パスワードに比べれば大幅な改善ですが、執拗なリアルタイムフィッシングキットにはワンタイムコードを中継されるおそれがあります。一般ユーザーには適しています。
• SMSコード。 ないよりはましですが、SIMスワッピングや傍受に弱いという弱点があります。フォールバックとしては許容できますが、主要な認証要素としては不十分です。

健全なポリシーとは、管理者や機密性の高いグループには強力でフィッシング耐性のある認証要素を必須とし、それ以外のユーザーにはアプリベースのコードを許可し、SMSの使用を最小限にとどめることです。

ロックアウトを避ける段階的な展開

MFAの強制導入を躊躇させる不安の正体は、「ユーザーをロックアウトしてしまうかもしれない」という懸念です。展開を段階的に進めることで、そのリスクを取り除けます。

1. まず周知する。 何がどう変わるのか、なぜ変わるのか、いつまでに対応が必要なのかを組織に伝えます。登録手順も提供しましょう。予告なしの強制導入は、ヘルプデスクへの問い合わせと不満を生みます。
2. 登録期間を設ける。 2SVを利用可能な状態にし、期限を設定します。登録の進捗を追跡し、まだ登録していないユーザーを把握できるようにします。
3. 未登録者に働きかける。 期限が近づいたら、未登録のアカウントにリマインドを送ります。ここで長期未登録者の大部分が登録を完了します。
4. 新規ユーザーの猶予期間を設けて強制する。 強制を有効化しますが、新規作成アカウントには猶予期間を設定し、初回ログイン時にオンボーディングが妨げられないようにします。
5. バックアップ手段を配布する。 バックアップコードや第二の認証要素を登録済みにしておき、スマートフォンの紛失が軽微な不便で済み、ロックアウトにつながらないようにします。
6. 例外は限定的に扱う。 サービスアカウントや共有アカウントの中には、対話型の2SVに本当に対応しづらいものもあります。ユーザーポリシーに広範な例外を設けるのではなく、より適切な認証モデル（サービスアカウント鍵、専用の取り扱いなど）へ移行させましょう。

管理コンソールは組織部門単位での強制をサポートしているため、まずIT部門で試験導入し、次に一部の部門、最後に組織全体へと展開することで、リスクをさらに抑えられます。

よくある落とし穴

• 「利便性のため」に経営幹部を例外扱いする。 最も価値の高いアカウントを例外にするのは最悪の選択です。むしろ、彼らにこそ*最も強力な*認証要素を課すべきです。
• SMSのみを許可する。 チェックボックス上は要件を満たしますが、SIMスワップという抜け穴を残したままです。アプリベースまたはハードウェアの認証要素を推進しましょう。
• サービスアカウントや共有アカウントを見落とす。 これらは重要なアクセス権を持ちながら、対話型認証を回避しがちです。意図的に統制しましょう。詳しくはリスクの高いAIエージェントやサービスアカウントの検出をご覧ください。
• 一度設定すれば終わりだと考える。 新規アカウントの発生、新たな例外、ポリシーのドリフトを踏まえると、強制設定は一度限りの切り替えではなく、定期的な検証が必要です。

強制されていることを検証する — 前提としない

ポリシーを有効化することと、それが*実際にすべてのアカウントに適用されている*ことを確認することは別問題です。ポリシー適用前に作成されたアカウント、例外扱いの組織部門に属するアカウント、猶予期間中のアカウントは、気づかぬうちに強制の対象外になっていることがあります。健全なGoogle Workspaceセキュリティ体制の一部であり、SOC 2監査人がCC6.1のもとで具体的に検証する対象でもあるのが、トグルがオンになっているかどうかだけでなく、MFAの強制が組織全体で維持されているかを確認することです。

これはまさにドリフトしやすい設定であり、監査人がエビデンスの提示を求める種類のものです。組織全体の設定を確認するポージング・ツールを使えば（該当する管理者権限がある場合）、2SVが強制されていない箇所を検出できるため、「MFAを強制しています」という主張が、想定ではなく検証済みの事実になります。

難しいケースへの対応

ほとんどのアカウントは問題なく登録されます。しかし、いくつかのカテゴリには意図的な対応が必要であり、それらの扱い方次第で強制が実際に維持されるかどうかが決まることが多くあります。

• 経営幹部やVIP。 彼らはフィッシングの主要な標的であり、例外を求める可能性が最も高い層です。例外扱いにするのではなく、最も強力な認証要素を課しましょう。経営幹部アカウントの侵害は最悪の結果の一つであり、利便性と引き換えにする価値はありません。
• 共有メールボックスやロールアカウント。 対話型の2SVは個人には適していますが、5人で使うメールボックスには適していません。これらは個別に保護されたアカウントへの委任アクセスとして再設計し、保護が実在の人物に紐づくようにしましょう。
• サービスアカウントや自動化アカウント。 これらはそもそも対話型ログインを行うべきではありません。別途管理されるサービスアカウント認証情報で認証し、非人間アイデンティティとして統制しましょう。
• 現場スタッフやフロントラインの従業員。 スマートフォンを持たない、または通信環境が限られている従業員には、実行可能な認証要素（ハードウェアキーやバックアップコード）が必要です。強制導入当日にヘルプデスクで即興対応するのではなく、事前に計画しておきましょう。

すべてに共通する原則は次の通りです。少数の例外的なケースに合わせて、ユーザーポリシーに広範な例外を設けてはいけません。それぞれのケースを適切な仕組みで解決し、ベースラインを維持しましょう。

展開後：強制状態を維持する

強制導入はゴールではありません。新規アカウント、新たに作成された組織部門、個別の例外はいずれも、カバレッジが崩れる経路を生み出します。定期的な確認を日常業務に組み込みましょう。すべての組織部門で2SVが強制され続けていること、例外がひそかに恒久化していないこと、強力な認証要素が求めていた箇所で今も求められていることを確認します。世界最強の対策であっても、誰も「まだ有効か」を確認しなければ劣化していきます。「MFAを強制しています」は、そうであってほしいという願望ではなく、証明できる事実であるべきです。

8200.devは、2段階認証プロセスの強制状況、共有設定、メール認証など、Google Workspaceの管理者設定を監査し、設定へ直接リンクする形でドリフトを検出します。詳しくは仕組みについてをご覧ください。

MFAがすべての場所で実際に強制されているか確認したいですか？ 無料セキュリティ監査を開始することで、Google Workspaceのアイデンティティおよび設定状況を把握できます。