Microsoft 365を活用した解決策
前編では、Microsoft 365（以下、M365）を活用した組織統合の際に直面する課題に焦点を当てました。
後編では、それらの課題を克服するためにM365の機能をどう活用するかについて記載していきます。
M365における個別ガバナンスポリシーのカスタマイゼーション
M365では、異なるガバナンスポリシーに適応するための細かいカスタマイゼーションが可能となっています。
例えば、Exchange Online、SharePoint Online、Teamsなどの主要サービスは、ユーザーグループごとに異なるポリシーを設定する機能を提供しています。
ExchangeOnlineではメールボックスの構成、メッセージサイズの制限、情報の転送設定、カレンダーの共有ポリシーなど、細かくユーザーレベルでのカスタマイズが可能です。
SharePoint Online（SPO）やTeamsでは、ファイル共有やメッセージング、会議設定などの各ポリシーをユーザーに紐づけて個別に適用することができます。
大規模組織では各組織が使用するデバイスが異なっている場合が多いですが、M365のデバイス管理で重要となるIntuneにおいては、デバイス登録や構成ポリシー、アプリ管理ポリシー等をデバイス単位、またはユーザー単位で設定し、組織の特定のニーズに応じて適用していくことが可能です。
M365のセキュリティアクセス制御の中核となる条件付アクセスポリシーについても、ユーザーグループに基づいたアクセス制御を提供可能であり、細かいニーズに応じたセキュリティ要件の実現を可能にします。
一方で、セキュリティに関しては個別のポリシーを乱立させた場合、脆弱なポリシーが存在した場合はセキュリティホールになり得るリスクがあるため、個別作成には細心の注意が必要となります。
ユーザー単位でのポリシー分割は比較的容易な一方で、組織全体に適用されるような設定に関しては、単純なポリシー設定では十分な制御を提供しきれない場合があります。
Exchange Onlineでのメールフローを例に取ると、組織単位での複雑なメールフロー制御を実現するためには、基本的なコネクタ設定に加えてトランスポートルールを利用した高度な制御が求められます。
Teamsのフェデレーション機能においても、外部ドメインとの通信を特定のユーザーに限定するなどの細かい制御は、標準の設定では困難です。
例えば、ある組織（A社）が外部ドメインと通信を行いたいが、別の組織（B社）ではそのドメインとの通信を禁止したいという場合、標準機能のみでは対応が不可能になることがあります。
このような状況では、M365機能のみでは実現できないため、サードパーティのセキュリティツールやカスタムスクリプトを使用して特定の通信制御を実施する必要があり、その複雑さや難易度によっては、実装自体を行うべきかを慎重に判断していく必要があります。
ユーザーデータ保持制御
データ保持場所については、Multi-Geo機能を使用することで、特定のユーザーデータを保持するデータセンターロケーションを指定することが可能です。
通常、データセンターのロケーションはテナントのロケーションに基づいて、Exchange OnlineやSharePoint Onlineの各サービスデータが保持されます。
例えば、テナントの代表ロケーションが日本である場合、原則として全ユーザーのデータは日本のデータセンターに格納されます。
しかし、Multi-Geo機能を活用することで、ユーザーが設定したデータロケーションプロパティに基づいて、対応するサービスのデータ格納場所を決定できます。
これにより、各組織が直面するデータ保持場所の法規制に対応できるようになります。
ただし、Multi-Geo機能は対象とするサービスが限定されており、例えばPowerAppsやPower Automateには対応していません。
データロケーションプロパティはユーザー単位でのみ設定可能であり、グループ単位での適用はできない点にも注意が必要であり、オンプレミスのActive DirectoryからユーザーIDを同期している場合は、データロケーションプロパティの設定はオンプレミスのADで行う必要がある点も重要です。
また、この機能を使用するためには追加のMulti-Geo専用ライセンス費用が発生する点も考慮する必要があります。
個々のアイテム保持期間管理に関してはアイテム保持ポリシーのカスタマイズにて対応を行います。
組織は電子メール、ファイルドキュメント、音声録音ファイル、チャットメッセージなど、データの種類ごとに各テナント内組織に応じた独自の保持ポリシーを設計し各ユーザーに対して適用することが可能です。
各国固有の規制対象のデータを特定し、これを法的な保持期間に合わせて別個管理する必要があります。
加えて意図しないデータ漏洩を防ぐために、保持期限が切れたデータを自動的に削除するポリシーを設定することもできます。
これはMicrosoft 365 E5ライセンスが持つ機能となります。
コミュニケーションルールの厳格化
同一テナント内でのコミュニケーション制御には、Microsoft 365 Purviewが持つ情報バリア（Information Barriers / IB）機能を活用することが効果的です。
この機能は、組織内でのセキュリティポリシーに基づき、特定のユーザーグループ間でのコミュニケーションやドキュメントの共有を制限するために提供されています。
情報バリア機能は、特に金融業界など、厳格なコンプライアンス要件を持つ業界での利用が想定されていますが、そのほかの組織でもコミュニケーションコントロールの強化に利用できます。
情報バリアでは組織に存在するコミュニケーションルールに基づき、どのユーザーグループの相互コミュニケーションを許可するか、または禁止するかを定義するポリシーを作成します。
作成したポリシーを特定ユーザー、グループに割り当てることでそれぞれをセグメント化し、異なるセグメントとのコミュニケーションを制御することができます。
情報バリアのポリシーは、SharePoint Online、Teamsなど、M365の複数のアプリケーションにわたって効果を発揮し、ファイル共有、チャット送受信やチームメンバー追加、会議開始等で制御が行われます。
ただし、メール送受信に関しては情報バリアの制御対象外となるため、これが必要な場合はExchangeOnlineのトランスポートルールにて別途メールフローを作成して制御を行う必要があります。
情報バリアのポリシー設定は複雑になる可能性があり、意図しないコミュニケーションブロックを防止するための正確な実装には、事前の計画と入念なテストが必須となります。
また、セグメント間のコミュニケーション制御は双方向でのみ可能であり、一方通行の制御はできない点に留意が必要です。
なお、情報バリア機能をテナントで利用する際は、規制対象が一部のユーザーのみであっても原則としてテナント内の全ユーザーにMicrosoft 365 E5ライセンスが必要となります。
複数のシステム管理者の権限制御と管理範囲の限定化
複数のシステム管理者が存在する環境において、適切な権限制御と管理範囲の明確化は組織のセキュリティと効率性を保つ上で不可欠です。
以下に示す解決策は、管理者の権限を適切に制御し、各管理者が担当する範囲を限定するために有効です。
Entra ID管理単位（Administration Unit）とカスタムロールの活用
管理単位とは、Entra ID上の管理対象ユーザーやデバイスを分類し、それぞれに対する管理権限を細分化するために使用します。
例えば、地理的な場所、所属部門ごとに管理単位を設定し、それぞれの単位に対して特定の管理者を割り当てることができます。
この方法により、管理者は自分の管理単位内のリソースにのみアクセスし、操作することが可能となります。
特定のセキュリティグループメンバーやディレクトリプロパティに基づいて管理単位への自動追加/削除を行うこともできます。
また、管理単位限定のカスタムロールを定義することで、管理者に必要な最小限の権限を付与し、不要なアクセスを防止することができます。
M365やAzure Active Directoryでは、事前に定義されたロールに加えて、組織の具体的なニーズに合わせたカスタムロールを作成し、適用することが可能です。
各ロールには、特定のタスクを実行するために必要な権限のみを含めることにより、各組織が持つ最小特権の原則に沿った管理を実現します。
なお、ExchangeOnlineやIntune上のリソースに対して管理範囲を限定する場合は、さらに各サービス固有の定義を作成する必要があります。
ExchangeOnline役割グループの活用
ExchangeOnlineでもサービス固有のカスタムロール（役割グループ）を定義することができます。
役割グループには書き込みスコープを設定することで、管理者が変更を加えることができる範囲を限定します。
例えば、特定のユーザーグループや組織単位内のオブジェクトに対する変更のみを許可し、それ以外のエリアへのアクセスを制限することができます。
これにより、管理者の操作を限定された範囲内とし、誤操作によるリスクを最小化します。
Intuneスコープタグの活用
Microsoft Intuneのスコープタグは、デバイスやポリシー、プロファイル、アプリケーションなどのIntuneリソースをグループ化し、タグ付リソースに対するアクセス権を特定の管理者に割り当てる機能です。
スコープタグを使用することで、特定の管理者が特定のIntuneリソース群にのみアクセスし、管理することが可能になります。
組織内で異なる部門や地域が独自のデバイス管理ポリシーを持つ場合は必須となる機能です。
これらの機能を利用して、M365上のリソースを論理分割しそれぞれに管理者を割り当てていくことが可能です。
一方で権限分割は有効な手段であるものの、分割対象となる資源が多岐に渡る場合、単一の設定だけで完璧な論理分割を実現することは困難です。
管理単位、カスタムロール、役割グループや書き込みスコープ、Intuneスコープタグなど、多数の機能や設定を組み合わせて使用する必要があります。
このプロセスの結果として、管理者と管理対象を明確に判別することが難しくなり、設計や試験の複雑性が増します。
さらに、複数の組織を兼務するユーザーや、複数の管理対象に所属するリソースが存在する場合、管理の煩雑さは一層増加します。
リソースそれぞれに複数の管理ポリシーを割り当てた結果、予期せぬ管理状態となる可能性があり、机上での検討だけでなく、実機を用いた確実な検証が必須となります。
このような複雑な環境では、以下の点を考慮することが重要です。
- 詳細な計画 … 権限分割を行う前に、どの資源がどの管理単位に属するか、各管理者にどのロールを割り当てるかなど、詳細な計画を立てることが重要です。
- 段階的な実装 … 全体を一度に実装するのではなく、段階的に実装し、各段階での影響を評価することで、複雑性を管理しやすくします。
- 徹底したテスト … 計画した権限制御が意図した通りに機能するか確認するために、広範囲にわたるテストを実施する必要があります。
継続的な監視と評価:
実装後も、継続的にシステムの監視を行い、必要に応じて調整を加えることで、管理の複雑性を適切に管理し続けることが必要です。
特に管理対象への追加を動的メンバーシップ等で自動化している場合、リソースが予期せぬ管理単位へ所属してしまうリスクも存在しています。
複数のリソースとシステム管理者の権限制御と管理範囲の限定化による論理分割は、慎重な計画、段階的な実装、徹底したテスト、そして継続的な監視というプロセスを通じて、ようやく実現されるものとなります。
実装後の運用段階に入っても継続的に意図通りの稼働を保持する必要があり、どこか一つの管理対象組織の統廃合や要件追加によって全体デザインへの影響確認や、見直しが必要となる場合もあります。
また、如何に権限分割を実施してもテナントワイドの設定に関しては全体整合性を横串で管理し、変更可否判断や変更作業の実行を担う部門が必須であり、それに紐づくグローバル管理者は結局必要となります。
M365のテナントワイドのトラブル防止、トラブル対応戦略
M365では、さまざまな規模のインシデントが発生します。
利用対象サービスやユーザーが増加するにつれて、たとえ軽微なインシデントであってもテナント全体として影響を受けやすくなります。
特定リージョンに限定されたインシデントであっても、そのリージョンに所属するテナント内組織が影響を受ける可能性があり、テナント全体としては常に何かしらのサービスインシデントを抱える状態になり得ます。
組織の管理者が個別に対応可能なケースも存在しますが、統合テナント環境においては、テナントワイドで影響を受けるインシデントに対して、あらかじめ対応方針を明確にしておく必要があります。
CSIRT（Computer Security Incident Response Team）に見られるように、各組織の管理者が参加するM365関連のトラブルシューティングチームの設置は、迅速な対応に有効です。
ただし、組織構造上、このようなチームの設置が困難な場合もあります。
そのような場合、グローバル管理者権限を持つシステム部門（例えば本社部門など）が代表して対応することが想定されます。
このため、各組織とのインシデント連携方法や影響特定方法をあらかじめ明確にし、インシデント発生時にはこれらのプロセスを遵守する必要があります。
さらに、月間で200～400件程度発生するサービス更新情報（メッセージセンター情報）の内容確認や影響評価を各組織で個別に実施するのは非効率です。
更新情報の全体共有を行うための仕組みを整備し、サービス仕様の変更や廃止に関する情報や対策をテナントワイドで迅速に共有することが重要です。
まとめ
M365が持つ豊富な機能を駆使することにより、シングルテナントへ複数の組織を統合し、論理的な分割を行うことが可能です。
このアプローチは、管理の効率化、コスト削減、セキュリティ強化とガバナンスの統一、コラボレーションの促進など多くのメリットを提供します。
しかし、論理分割を完全に実施するためには、多数の機能を適切に組み合わせる必要があり、その構築や試験には高度な技術知識と膨大な労力が必要となり、何かしらで力技のような状況が発生します。
さらに、全ての論理分割機能をフルに活用しようとすると、追加のライセンス費用が発生し、テナント集約のコスト削減効果が相殺される可能性があります。
個々ではE3相当で充足していたものが、集約時の論理分割要件に依ってE5相当が必要になるといったケースです。
また、Microsoftは最近、B2B直接接続やマルチテナント組織機能といった、複数テナント間のコラボレーションを強化する機能の提供を徐々に開始しています。
これらの機能を活用することで、テナント統合を行わずとも、異なる組織間での効率的なコラボレーションが可能となり、テナント集約のみが選択肢とは限りません。
ガバナンスを統一できることはシングルテナントの大きなメリットですが、統合を検討する組織それぞれでガバナンスや運用部門が異なる場合、異なるポリシーへの細分化が必要になることがあります。
このような状況では、テナント統合の恩恵を最大限に享受することが難しくなる可能性があります。
まとめるとテナント統合にメリットが見出せるか否かは、最低限以下の条件を満たしていることが重要です。
- テナント統合を検討している全ての組織でセキュリティポリシーを含むガバナンスが統一されていること。
- システム管理、運用、監査を行う組織が統一されていること。
- 組織内の全てのユーザーがシームレスにコミュニケーションを行うことに問題がないこと。
これらの要件を全て満たせる場合は、テナント統合の恩恵を最大限に享受することできます。
一方で、これが難しい場合、テナント統合によってかえってシステム構成やシステム運用が複雑化し、ユーザーにとっても管理者にとっても扱いづらいシステムになってしまう事も考えられるため、テナント統合に限らずマルチテナントでのコラボレーションを含めた様々な選択肢を検討することが最適なアプローチとなります。
最終的には、組織の特定のニーズ、ガバナンス構造、コスト、および運用上の複雑さを総合的に評価し、最も効果的かつ合理的な戦略を選択することが重要となります。
※記載されている会社名、商品名、またはサービス名は、各社の登録商標または商標です。