COLUMN

2024.07.03 ｜ Writer：タクヤ、カズキ

NTT東日本でEntra ID・Intuneを活用してみた

ゼロトラストセキュリティを導入したいが、何からはじめたらよいかわからない、最適なソリューションがわからないなどNTT東日本のセキュリティエンジニアが無料でご相談をおうけいたします。ぜひ、お気軽にお問い合わせください。

こんにちは！NTT東日本セキュリティエンジニアのタクヤです。

ゼロトラストセキュリティコラムの４回目になります。

過去のコラムをまだご覧になっていない方は、是非ご覧ください。

第１弾コラム：「NTT東日本で実際に導入しているゼロトラストセキュリティを徹底解説！」

第２弾コラム：「NTT東日本におけるゼロトラストセキュリティの設計と導入」

第３弾コラム：「NTT東日本でゼロトラストセキュリティの運用・監視をやってみた」

今回からは製品ごとに運用時の困りごとを例に挙げながら、どういう運用を行っているのか、どういう点を工夫しているのかについてご紹介していこうと思います。

本コラムではゼロトラストセキュリティに欠かせないEntraIDとIntuneにスポットを当ててご紹介いたします。最後までお付き合いいただけますと幸いです。

1. EntraID、Intuneの活用ポイントについて: 1-1. NTT東日本のセキュリティ要件と活用ポイント
2. EntraIDの運用で困ったこと: 2-1. 困りごと①：ポリシーの命名; 2-2. 困りごと②：Microsoft Teams Roomsに対する情報漏えい対策; 2-3. 困りごと③：モバイル上のアプリケーション保護について; 2-4. 困りごと④：アカウントに対するロール付与
3. まとめ

1. EntraID、Intuneの活用ポイントについて

EntraIDやIntuneの困りごとを紹介する前にどのようなセキュリティ要件を定めたのか、実際にどのようなポリシーを適用してゼロトラストセキュリティ環境を目指したのかについて、改めてご紹介します。

1-1. NTT東日本のセキュリティ要件と活用ポイント

NTT東日本のセキュリティ要件

セキュリティ要件1	リモートから会社リソースへのセキュアなアクセス方法の確立
セキュリティ要件2	利便性の高いアプリケーションの利用促進と、セキュリティの両立
セキュリティ要件3	情報漏えい対策を確保した上での、外部とのコラボレーション方法の確立
セキュリティ要件4	高度化するサイバー攻撃や内部不正に対する状況の可視化及び防御策

第1回コラムで詳しくご紹介

上記を踏まえて、NTT東日本の環境をユーザ、端末、利用場所、アプリ、サービス、データ種別の視点で可視化すると以下のようになります。

基本方針として、会社支給PC等の「準拠端末」においては、利便性を追求しつつ、セキュリティ上のリスクが高まる場合のみアクセス制御を加えることとしました。一方、統制が効かない「非準拠端末」においては、情報漏えいリスクの最小化を考慮し、常時、機能制限を加えた上で、アクセスを許容することとしました。

ここから実現可能な最適解を考えた結果、アクセス制御においては、以下のような基本設計を策定しました。

アクセス制御基本設計1	ポリシーに準拠しているデバイスはフルアクセス可能とし、非準拠のデバイスはアクセスを制限する。 (実現案)IntuneとEntraIDを用いて制御する。
アクセス制御基本設計2	SWG機能も含めて認証を一元化する。 (実現案)EntraIDのSAML連携により実現する。
アクセス制御基本設計3	利用ユーザにセキュリティリスクが存在する場合には、リスクの大きさに応じて、認証ブロック、パスワードリセット、再認証の要求等を強制的に適用する。 (実現案)EntraIDの条件付きアクセスを用いて制御する。
アクセス制御基本設計4	会社支給のPC端末から個人向けクラウドサービスは利用不可にする。 (実現案)Zscaler Internet Accessを用いて制御する。
アクセス制御基本設計5	BYOD端末及びゲスト端末PCは、情報漏えい対策として機能を制限した上で、ブラウザアクセスのみを許可する。 (実現案) EntraIDの条件付きアクセスとMicrosoft Defender for Cloud Appsのセッション制御を利用することで、ブラウザアクセスに限定し、機能を制限する。
アクセス制御基本設計6	スマートフォンは、機能を制限した上で、あらかじめ決められたアプリケーションのみに限定して許可する。 (実現案)IntuneのMobile Application Managementを用いて制御する。

アクセス制御概要図

2. EntraIDの運用で困ったこと

セキュリティエンジニアのカズキです。

本項ではEntraIDの運用において発生した困りごとについて、具体的な解決策と解決後どのように利便性が向上したかをご紹介します。

2-1. 困りごと①：ポリシーの命名

まず1点目はEntraIDで作成したポリシーの命名規則に関する困りごとです。

NTT東日本は5万以上の利用者と数千の組織を抱えており、複数の要望に応えるために、条件付きアクセスだけで60以上のポリシーを運用しています。運用開始当初は複雑なポリシーも少なく、制御対象アプリのポリシー名や制御対象者等を冠した比較的シンプルなポリシー名を付与していましたが、途中から制御条件が増えてポリシーが複雑になっていきました。このため、名前から制御内容を把握することができなくなり、常に管理表と見比べる運用が発生するという問題がありました。

この問題について対策を検討し、次のような構文を考えてフォーマット化しました。

以下は活用例となります。

このルールのポイントは条件付きアクセスの条件をプログラミングライクに命名規則に反映することで、読みやすさと命名しやすさを両立している点です。

この命名規則を導入した効果としては、作業対象のポリシーを探す手間が大幅に削減され、更にポリシー把握が容易になったことで、技術の習熟もし易くなったことが挙げられます。

2-2. 困りごと②：Microsoft Teams Roomsに対する情報漏えい対策

次に特殊なクライアントデバイス対応について困ったことをご紹介します。

前述の通り、NTT東日本では条件付きアクセス機能を利用し、デバイスごとのアクセス制御を以下のように導入しています。

横にスクロールします

デバイス種別	準拠端末	Zscalerの有無	会社リソースへのアクセス
会社支給PC	〇	〇	フルアクセス可
個人用PC	×	×	ブラウザのみ制限付きでアクセス可
個人用モバイル	×	×	アプリのみ制限付きでアクセス可

しかし、新たにこの枠組みで制御できないものが発生しました。それはMicrosoft Teams RoomsというWEB会議専用デバイスの扱いに関する事です。

発生した困りごとは以下です。

困ったこと1	専用デバイスのため、Zscaler Internet Accessによるネットワークアクセス制御が不可
困ったこと2	個人用PC同様のブラウザ制御はできず、デスクトップアプリケーションを用いた会社リソースへアクセスが必要

このことから特殊な条件付きアクセスの設計が必要となり、検討を重ねた結果、SharePoint Onlineのテナント設定と連携したセッション制御を新規に設計することでクライアントアクセスさせつつ、非準拠端末相当のセキュリティ制御を実現しました。

2-3. 困りごと③：モバイル上のアプリケーション保護について

3点目はSaaSアプリケーションの制御についてです。

社内からSlack利用の要望があり、以下のようにサンクションITとして制御を検討しました。

横にスクロールします

デバイス種別	準拠端末	Zscalerの有無	Slack利用
会社支給PC	〇	〇	利用可
個人用PC	×	×	ブラウザのみ制限付きで利用可
個人用モバイル	×	×	アプリのみ制限付きで利用可

個人用モバイルはIntuneによるMAM(モバイルアプリケーションマネジメント)機能による保護を検討していたのですが、一部のアプリで保護が完全に効かない事象が発生しました。本事象はAndroid版SlackアプリでURLを開くときのブラウザアクセスはホワイトリスト制御ができないため、任意のURLにアクセス可能となってしまい情報漏洩リスクが残るというクリティカルなものでした。

関係部署とリスク受容可否を検討した結果、弊社ではモバイル上でのアプリケーション利用開放は見送りました。このようにMAM制御には思わぬ落とし穴があるので、細かいところまで調査・検証することが重要です。