0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

1.はじめに

はじめまして。本記事を閲覧いただきありがとうございます。
株式会社NTTデータ九州 ビジネス共創部 デジタルビジネス推進室の野田です。

当部門では Workstyle Invention (以下、WSI。詳細は後述)というサービスを通じて、デジタルワークスペースの導入をテーマにお客様の働き方改革を推進しています。
本記事では、デジタルワークスペースとして採用することが多いツールである Microsoft 365(以下、M365)について、概要やユースケースをご紹介します。


2. Workstyle Invention の紹介

まず、本題に入る前にWSIについて紹介させてください。
WSIはNTTデータ社が提供する、ワークスペースのモダナイズに関するコンサルティングから、ツール導入/利用促進までを一気通貫で対応するトータルサービスです。
デジタルワークスペースの導入において、「構想検討」「導入」「活用」の3つのフェーズに応じたサービスメニューを提供しています。
当部門ではNTTデータ社と連携しながら、OA高度化やゼロトラストの領域における実績をもとに、九州のお客様の働き方改革を支援してまいります。

  • 構想検討 :お客様の最適な働き方の定義やロードマップ策定を支援
  • 導入 :最適なソリューションを選択しデジタルワークスペース導入を支援
  • 活用 :継続的なデジタルワークスペースのアップデート

wsi.png


3.M365とは

それでは、改めてM365についてご説明します。
M365は、以下のような Microsoft 社が提供する様々なサービスが1つにまとめられた、最も利用されているSaaSの1つです。
これらのサービスを用いて、ゼロトラストの考え方に基づいたセキュリティ強化をベースとしたハイブリッドワークの実現に寄与しています。

  • WordExcelPowerPoint などの Office アプリ
  • Exchange OnlineOneDriveSharePoint OnlineTeams などのコミュニケーションツール
  • ローコードプラットフォームの Power Platform
  • Entra IDIntuneMicrosoft Defender for EndpointMicrosoft Defender for Cloud Apps などのセキュリティサービス
  • AIアシスタントツールの Copilot

microsoft365.png


4.M365のユースケース

次に、M365のユースケースについて 当部門が担当したお客様 の導入・支援事例をもとにご紹介します。

4-1.コミュニケーション基盤と認証基盤によるOA高度化

1つ目はすでに利用されているお客様も多い、M365の主要サービスである Exchange OnlineTeamsEntra ID などを用いたコミュニケーション基盤及び認証基盤です。
当部門が担当したお客様 は、この基盤により以下のようなOA高度化を実現されています。

  • コミュニケーション基盤統合によるグループ会社間の連携強化
  • Teams によりWeb会議やチャットを利用することで、生産性を落とさないリモートワークを実現
  • Active Directory (以下、AD)でアカウントを一括管理し、 Entra IDEntra Connect によるアカウント同期及びM365や外部SaaSへのシングルサインオン(以下、SSO)を可能にしたことで、利用者は端末ログイン時のIDとパスワード認証のみで各サービスを利用でき、利便性向上やセキュリティ強化を両立
  • M365標準の監査ログでは長期保管を実現できないため、 Graph API を活用してログ分析基盤へログ保管することにより、M365監査ログの長期保管の実現

communication.png

上記の特にSSOを実現するにあたり、本基盤では以下の課題がありました。
Entra Connect 構築時の参考となればと思います。

【課題】ADと Entra ID のドメイン不一致による Entra ID ユーザのUPN強制変換

前提として、M365および Entra ID では、ユーザープリンシパル名(以下、UPN)に.com.jpといったカスタムドメインを利用するケースが一般的です。
本基盤でもカスタムドメインを利用しています。
※UPNはM365へサインインする際のIDとして使用されます。

Entra Connect を用いてADから Entra ID へアカウント同期する場合、双方に同一のドメインを登録しておくことで、そのドメインを持つUPNのまま正常に同期されます。
しかし、本環境ではADのドメイン名が.localでしたが、 Entra ID では.localのような非ルーティングドメインを登録できないため、ADと Entra ID で同一ドメインを使用できませんでした。
その結果、アカウント自体は同期されるものの、Entra ID 上のUPNはカスタムドメインではなく、初期ドメインの.onmicrosoft.comドメインとなってしまいます。

⇒【解決策】UPNサフィックスの追加

この課題に対して、ADにカスタムドメインのUPNサフィックスを追加することで解決しました。
UPNサフィックスを追加することで、以降はADユーザのUPNを Entra ID ユーザと同じ値で登録可能となり、アカウント同期もADと Entra ID で同じUPNの値を同期することが可能です。
詳細な設定手順は以下の公式情報をご参照ください。

UPNsuffix.png


4-2.M365シングルプラットフォームによるゼロトラスト推進

2つ目は、M365のセキュリティサービスをフル活用したゼロトラストの推進です。
※ゼロトラスト推進の必要性については、以下の記事を参照ください。

本PoCでは、以下のサービスを活用して構築したM365シングルプラットフォームでのゼロトラスト基盤の実現可能性を検証しました。
技術要素ごとのM365のサービスは以下の通りです。

技術要素 M365サービス
IDaaS(Identity as a Service) Entra ID
MDM(Mobile Device Management)
/MAM(Mobile Application Management)
Intune
EDR(Endpoint Detection and Response) Microsoft Defender for Endpoint
CASB(Cloud Access Security Broker) Microsoft Defender for Cloud Apps
SWG(Secure Web Gateway) Microsoft Entra Internet Access

zerotrust.png

また、本PoCの検証結果より以下の課題が発生しました。
Microsoft Entra Internet Access (以下、MEIA)や Microsoft Defender for Cloud Apps (以下、MDCA)を構築する際にご参考となればと思います。
※本記事においてMEIAはパブリックプレビュー(2024年3月時点)での情報となります。

【課題①】 Microsoft Entra Internet Access のWebフィルタリングにおける想定外挙動

1つ目はMEIAのWebフィルタリングの挙動についてです。
MEIAでは、URL単位での制御ができずFQDN単位またはコンテンツカテゴリ単位での制御が基本ですが、PoCでは想定外のカテゴリに分類されるWebサイトが存在し、カテゴリ制御のみでは意図した制御ができませんでした。

⇒【解決策】カテゴリ制御とFQDN制御の二段構成

この点はカテゴリ制御を基本として、業務影響が大きいサイトをFQDN単位で個別制御する二段構えの構成で対応しました。
MEIAではユーザのアクセスログを参照可能なため、ログからFQDNを読み取って追加の制御を行う、利用者からの申請に応じて追加の制御を行うなどが可能と思われます。
ただし、運用負荷を上げすぎない運用設計が必要になります。

【課題②】GSAクライアントの抜け穴

2つ目は、利用者自身が Global Secure Access (以下、GSA)クライアントをアンインストールや停止して、MEIAの制御を回避できる点です。
GSAクライアントがアンインストールや停止されると、MEIAで制御しているポリシーが適用されず、利用者が任意のWebサイトにアクセスできてしまいます。

⇒【解決策】 Intune によるGSAクライアントの制御

GSAクライアントのアンインストール対策として、Intune にてGSAクライアントの強制配布及びアンインストール制御が可能です。
制御方法が公開されているのでご参照ください。
GSAクライアントの停止に対する対策についても、PoC当時は結論が出ませんでしたが、現在は Intune の修復スクリプトによるGSAクライアント停止の制御方法が公開されています。
こちらもあわせてご参照ください。

GSAclient.png

GSAclient2.png

【課題③】 Microsoft Defender for Cloud Apps による秘密度ラベル自動適用における制約

本PoCでは、MDCAと秘密度ラベルを連携させて、端末とSaaS間のファイルアップロード/ダウンロードの制御を検証しました。
その中で、MDCAと秘密度ラベルの連携に関する2つの制約を確認しました。

  • 適用対象のファイル:Office ファイル( WordExcelPowerPoint )、PDF
  • 適用対象のサービス:SharePoint OnlineOneDriveBoxGoogle Workspace

つまり、CSVやTXTなどのファイルや上記以外のサービスに対して、秘密度ラベルは自動適用されずファイルアップロード/ダウンロードが制御できないということになります。

⇒【代替策】 秘密度ラベルの手動付与やDLPポリシーによる自動適用

代替策としては、利用者に Microsoft Purview Information Protection クライアントを用いて手動で秘密度ラベルを付与してもらう運用や、 Purview のDLPポリシーに自動適用が候補になると考えられます。

dlp.png


5.さいごに

本記事では当部門の事例をもとに、M365のユースケースをご紹介しました。
M365は Office アプリや Exchange Online (メール)、Teams だけでなく、ゼロトラストに対応したセキュリティ強化などOA環境全体で活用できるSaaSです。
当部門では、ご紹介した事例を九州のお客様に対しても展開して、お客様のデジタルワークスペースの導入及び働き方改革を支援してまいります。
本記事が、M365の導入や活用に興味を持つ方々の参考になれば幸いです。


6.執筆日・免責事項

  • 執筆日:2026年3月10日
  • 免責事項:本記事は執筆時点の情報に基づいています。内容は将来変更される可能性があります。
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?