Google Workspaceの組織部門(OU)は、ユーザー管理だけでなく、セキュリティポリシー適用の中核を担う機能です。現代のセキュリティ要件に応えるため、OU設計にゼロトラストの考え方を取り入れることは非常に重要です。
この記事を読んだほうが良い人
- 100名規模の企業でGoogle Workspaceを管理運用している情シス担当者
- Google Workspaceのセキュリティ強化とアクセス制御の厳格化を検討している方
- OU設計のベストプラクティスが分からず、悩んでいる方
- 最小権限の原則に基づいたゼロトラストセキュリティをGoogle Workspaceで実現したいと考えている方
Google Workspace OU設計の現状とゼロトラストの必要性
OU設計の基本とよくある課題
Google Workspaceの組織部門(OU: Organizational Unit)は、ユーザーアカウントを階層的に管理し、特定のグループに対して設定やポリシーを適用するための機能です。例えば、部署ごとのOUを作成し、それぞれに異なるGoogleドライブの共有設定やGmailの署名ポリシーを適用するといった使い方が一般的です。
しかし、OU設計は一度作ると変更が難しい側面があり、以下のような課題に直面することが少なくありません。 - 複雑化: 組織変更や異動のたびにOU構造が複雑になり、管理が煩雑になる。 - 権限の肥大化: 部署単位で大まかにポリシーを適用した結果、本来不要な権限を持つユーザーが発生し、セキュリティリスクが高まる。 - 運用負荷: 細かすぎるOUは管理者の運用負荷を増大させ、逆にポリシーが形骸化する原因となる。
なぜ今、ゼロトラストが求められるのか
従来のセキュリティモデルは、社内ネットワークを「信頼できる領域」、社外ネットワークを「信頼できない領域」として区別し、境界防御を重視してきました。しかし、クラウドサービスの普及やモバイルワークの増加により、この境界は曖昧になり、従来のモデルでは対応しきれない脅威が増えています。
そこで注目されているのがゼロトラスト(Zero Trust)の考え方です。「何も信頼しない、常に検証する」を原則とし、社内外の区別なく、すべてのアクセス要求に対してユーザー、デバイス、アクセス状況などを検証し、最小限の権限のみを付与します。Google Workspaceにおいても、このゼロトラストの原則を適用することで、より堅牢なセキュリティ環境を構築できます。
最小権限の原則とは
ゼロトラストを実現するための重要な柱の一つが最小権限の原則(Principle of Least Privilege)です。これは、ユーザーやシステムには、その職務を遂行するために必要最小限の権限のみを与えるべきであるという考え方です。例えば、経理担当者には経理システムへのアクセス権のみを与え、開発システムへのアクセス権は与えない、といった具合です。
Google WorkspaceのOU設計においてこの原則を適用することで、不必要なデータへのアクセスや設定変更のリスクを大幅に低減できます。
ゼロトラスト視点でのOU設計原則
ゼロトラストの考え方に基づき、OUを設計する際には以下の原則を意識します。
OUの階層化と分離の考え方
OUは、単に組織図を反映するだけでなく、セキュリティポリシーの適用単位として機能するように設計します。
- トップレベルOU: 会社全体に適用される基本ポリシーを定義します。
- 機能別OU: 部署や役割ではなく、セキュリティ要件が異なる「機能」に基づいてOUを分割します。例えば、「全社員OU」「管理者OU」「パートナーOU」「デバイスOU」などです。
- 部門別OU(オプション): 機能別OUの下に、さらに特定の部署やチームを配置し、詳細なポリシーを適用します。ただし、部門別OUが多すぎると管理が複雑になるため、必要最小限にとどめます。
OU設計例:
会社名.com
├── 全社員OU (基本ポリシー適用)
│ ├── 一般社員OU
│ │ ├── 営業部OU
│ │ └── 開発部OU
│ └── 契約社員OU
├── 管理者OU (高度なアクセス権限を持つユーザー)
│ ├── GWS管理者OU
│ └── GCP管理者OU
├── パートナーOU (社外協力者)
├── デバイスOU (管理対象デバイス)
│ ├── PC (Windows)
│ ├── PC (Mac)
│ └── モバイル (Android/iOS)
└── サービスアカウントOU (自動化用アカウント)
この例では、「管理者OU」のように特定の役割を持つユーザーを分離することで、一般社員とは異なる厳格な認証ポリシーやアクセス制限を適用しやすくなります。
ユーザーとデバイスの信頼性評価
ゼロトラストでは、ユーザーとデバイスの「信頼性」を常に評価し、アクセスを許可するかどうかを判断します。Google Workspaceでは、主にContext-Aware Access (CAA)と呼ばれる機能を使ってこれを実現します。
CAAは、以下のような要素に基づいてアクセスを制御します。 - ユーザーの身元: ユーザーアカウントの認証状態(多要素認証の有無など)。 - デバイスの状態: デバイスが管理対象であるか、OSのバージョン、セキュリティパッチの適用状況、画面ロック設定など。 - アクセス元IPアドレス: 信頼できるネットワークからのアクセスか。 - 地理的位置: 許可された国や地域からのアクセスか。
OUを適切に設計することで、特定のOUに所属するユーザーに対して、より厳格なCAAポリシーを適用できるようになります。
最小権限を徹底するためのOU構造例
具体的なOU構造の考え方として、以下の点を考慮します。
- 特権ユーザーの分離: Google Workspaceの管理者権限を持つユーザーは、必ず専用のOUに配置します。このOUには、強力なパスワードポリシー、多要素認証の強制、特定のIPアドレスからのアクセス制限など、最も厳格なセキュリティポリシーを適用します。
- 役割ベースのOU: 一般ユーザーの中でも、経理や人事など機密情報にアクセスする可能性のあるユーザーは、別のOUに分離します。これにより、これらのユーザーに対してのみ、特定のアプリケーションへのアクセス制限やデータ損失防止 (DLP) ポリシーを適用できます。
- デバイス管理のOU: 管理対象のPCやモバイルデバイスもOUで分類します。例えば、Windows PC、Mac PC、モバイルデバイスごとにOUを作成し、それぞれにデバイスポリシー(画面ロック、データ暗号化など)を適用します。
実践!Google Workspace管理コンソールでのOU設計とポリシー適用
ここからは、Google Workspace管理コンソールでの具体的な設定手順を見ていきます。
OUの作成手順
- Google Workspace管理コンソールにログイン: 管理者権限を持つアカウントで
admin.google.comにアクセスします。 - OU管理画面へ移動: メニューから
ディレクトリ > 組織部門を選択します。 - 新しいOUの作成:
- 既存のOUを選択し、右上の
+ボタンをクリックするか、最上位の組織名を選択して新しい組織部門を作成をクリックします。 - 「組織部門名」を入力します(例:
管理者OU)。 - 「説明」には、そのOUの目的や適用される主なポリシーなどを簡潔に記載します。
- 「作成」をクリックしてOUを作成します。
- 既存のOUを選択し、右上の
- ユーザーの移動: 新しく作成したOUに、該当するユーザーを移動させます。ユーザー一覧から対象ユーザーを選択し、
その他 > 組織部門を変更から移動先OUを選択します。
ポリシー適用例 (Context-Aware Access, アプリアクセス制御など)
OU設計が完了したら、各OUに対して適切なセキュリティポリシーを適用します。
Context-Aware Access (CAA) の設定
CAAは、ユーザーがどこから、どのデバイスでアクセスしているかに応じて、Google Workspaceのサービスへのアクセスを制御する強力な機能です。
- アクセスレベルの作成:
- 管理コンソールで
セキュリティ > アクセスとデータ管理 > Context-Aware Accessに移動します。 アクセスレベルタブでアクセスレベルを作成をクリックします。- アクセスレベル名(例:
社内ネットワークからのみ)と条件(例:IPアドレス > 範囲 > 社内IPアドレス帯)を設定します。 - 必要に応じて、デバイスポリシー(例:
管理対象デバイスが必要、画面ロックが必要)を追加します。
- 管理コンソールで
- サービスへのアクセスレベルの割り当て:
Googleサービスにアクセスレベルを割り当てるタブに移動します。- 制御したいサービス(例:
Gmail、Googleドライブ)を選択し、アクセスレベルを割り当てるをクリックします。 - 先ほど作成したアクセスレベルを選択し、適用するOUを指定します。例えば、「管理者OU」のユーザーには「社内ネットワークからのみアクセス可能」なポリシーを適用します。
アプリケーションアクセス制御
特定のOUに属するユーザーに対して、特定のGoogle Workspace MarketplaceアプリやOAuth接続アプリへのアクセスを制限できます。
- 管理コンソールで
セキュリティ > アクセスとデータ管理 > APIの制御に移動します。 アプリのアクセス制御セクションで、ブロックしたいアプリや信頼したいアプリを設定します。- 設定する際に、適用する組織部門を選択することで、OU単位で制御を適用します。例えば、「パートナーOU」には、承認済み以外のサードパーティアプリへのアクセスを禁止するといった設定が可能です。
グループとOUの連携
OUはポリシー適用に優れていますが、一時的なプロジェクトや特定のタスクで共同作業を行う場合は、Googleグループを併用すると管理が柔軟になります。
- OU: 長期的な組織構造やセキュリティポリシーの基盤。
- Googleグループ: 短期的なコラボレーションや特定のドキュメント共有など、柔軟なアクセス制御が必要な場合に活用。
OUで基本的なポリシーを適用し、グループで細かいアクセス権限を付与するという使い分けが効果的です。
OU設計後の運用と改善
OU設計は一度行ったら終わりではありません。組織の変化に合わせて定期的に見直し、改善していくことが重要です。
定期的なレビューと棚卸し
- 年に一度はOU構造を見直す: 組織変更や人事異動があった場合だけでなく、定期的にOU構造が現在の業務実態やセキュリティ要件に合致しているかを確認します。
- ユーザーの所属OUを確認: ユーザーが適切なOUに所属しているかを定期的に監査し、誤って不適切な権限が付与されていないかチェックします。
変更管理とドキュメント化
- 変更履歴の記録: OU構造やポリシーの変更は、必ず履歴として残します。いつ、誰が、なぜ変更したのかを明確にすることで、トラブル発生時の原因究明や将来的な見直しに役立ちます。
- 設計ドキュメントの作成: OU設計の目的、各OUの役割、適用される主要なポリシーなどをまとめたドキュメントを作成し、関係者間で共有します。
監査ログの活用
Google Workspaceの管理監査ログやアクセス透明性ログを活用することで、OUやポリシーの変更履歴、ユーザーのアクセス状況を詳細に確認できます。不審な動きがないか、ポリシーが意図通りに機能しているかを常に監視し、問題があれば速やかに対応します。
まとめ
Google Workspaceの組織部門(OU)設計は、単なる組織管理を超え、ゼロトラストセキュリティを実現するための重要な基盤となります。最小権限の原則に基づき、機能とセキュリティ要件でOUを階層化し、Context-Aware Accessなどのポリシーを適切に適用することで、より堅牢で安全なGoogle Workspace環境を構築できます。
OU設計は一度行えば終わりではなく、組織の変化に合わせて定期的に見直し、ドキュメント化し、監査ログで監視する運用が不可欠です。情シス担当者として、常にセキュリティの視点を持ってOU設計と運用に取り組むことが、企業のデジタル資産を守る上で極めて重要です。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
御社の IT 部門、ここにあります。
「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。