Microsoft 365 エンドポイントの管理

  • [アーティクル]

複数のオフィスの場所と接続 WAN を持つほとんどのエンタープライズ組織では、Microsoft 365 ネットワーク接続の構成が必要です。 ネットワークを最適化するには、信頼できるすべての Microsoft 365 ネットワーク要求をファイアウォール経由で直接送信し、追加のパケット レベルの検査または処理をすべてバイパスします。 これにより、待機時間と境界の容量要件が削減されます。 Microsoft 365 ネットワーク トラフィックを特定することは、ユーザーに最適なパフォーマンスを提供するための最初の手順です。 詳細については、「 Microsoft 365 ネットワーク接続の原則」を参照してください。

Microsoft では、Microsoft 365 ネットワーク エンドポイントにアクセスし、 Microsoft 365 IP アドレスと URL Web サービスを使用してそれらのエンドポイントに対する継続的な変更にアクセスすることをお勧めします。

重要な Microsoft 365 ネットワーク トラフィックを管理する方法に関係なく、Microsoft 365 にはインターネット接続が必要です。 接続が必要なその他のネットワーク エンドポイントについては、「 Microsoft 365 IP アドレスと URL Web サービスに含まれていないその他のエンドポイント」を参照してください。

Microsoft 365 ネットワーク エンドポイントの使用方法は、エンタープライズ organization ネットワーク アーキテクチャによって異なります。 この記事では、エンタープライズ ネットワーク アーキテクチャが Microsoft 365 の IP アドレスと URL と統合できるいくつかの方法について説明します。 信頼するネットワーク要求を選択する最も簡単な方法は、各オフィスの場所で自動 Microsoft 365 構成をサポートする SD-WAN デバイスを使用することです。

重要な Microsoft 365 ネットワーク トラフィックのローカル ブランチ エグレス用 SD-WAN

各ブランチ オフィスの場所で、エンドポイントの Microsoft 365 Optimize カテゴリのトラフィックをルーティングするように構成された SD-WAN デバイス、またはカテゴリの最適化と許可を Microsoft のネットワークに直接提供できます。 オンプレミスのデータセンター トラフィック、一般的なインターネット Web サイト トラフィック、Microsoft 365 既定のカテゴリ エンドポイントへのトラフィックなど、その他のネットワーク トラフィックは、より実質的なネットワーク境界がある別の場所に送信されます。

Microsoft は SD-WAN プロバイダーと連携して、自動構成を有効にしています。 詳細については、「Microsoft 365 ネットワーク パートナー プログラム」を参照してください。

重要な Microsoft 365 トラフィックの直接ルーティングに PAC ファイルを使用する

PAC または WPAD ファイルを使用して、Microsoft 365 に関連付けられているが IP アドレスがないネットワーク要求を管理します。 プロキシまたは境界デバイスを介して送信される一般的なネットワーク要求では、待機時間が長くなります。 TLS の中断と検査によって最大の待機時間が作成されますが、プロキシ認証や評判参照などの他のサービスは、パフォーマンスの低下やユーザー エクスペリエンスの低下を引き起こす可能性があります。 さらに、これらの境界ネットワーク デバイスには、すべてのネットワーク接続要求を処理するのに十分な容量が必要です。 Microsoft 365 ネットワーク要求を直接行う場合は、プロキシまたは検査デバイスをバイパスすることをお勧めします。

Get-PacFile PowerShell ギャラリーは、Microsoft 365 IP アドレスと URL Web サービスから最新のネットワーク エンドポイントを読み取り、サンプル PAC ファイルを作成する PowerShell スクリプトです。 スクリプトを変更して、既存の PAC ファイル管理と統合できます。

注:

Microsoft 365 エンドポイントへの直接接続に関するセキュリティとパフォーマンスに関する考慮事項の詳細については、「 Microsoft 365 ネットワーク接続の原則」を参照してください。

ファイアウォールとプロキシを介して Microsoft 365 に接続する。

図 1 - 単純なエンタープライズ ネットワーク境界

PAC ファイルは、図 1 のポイント 1 にある Web ブラウザーに展開されます。 重要な Microsoft 365 ネットワーク トラフィックを直接送信するために PAC ファイルを使用する場合は、ネットワーク境界ファイアウォール上のこれらの URL の背後にある IP アドレスへの接続も許可する必要があります。 これは、PAC ファイルで指定されているのと同じ Microsoft 365 エンドポイント カテゴリの IP アドレスをフェッチし、それらのアドレスに基づいてファイアウォール ACL を作成することで行われます。 ファイアウォールは、図 1 のポイント 3 です。

個別に、カテゴリ エンドポイントの最適化に対してのみ直接ルーティングを実行する場合は、プロキシ サーバーに送信する必要がある [カテゴリ エンドポイントを許可する] をプロキシ サーバーに一覧表示して、追加の処理をバイパスする必要があります。 たとえば、TLS の中断と検査とプロキシ認証は、[最適化] と [許可] の両方のカテゴリ エンドポイントと互換性がありません。 プロキシ サーバーは、図 1 のポイント 2 です。

一般的な構成では、プロキシ サーバーにヒットする Microsoft 365 ネットワーク トラフィックの宛先 IP アドレスに対して、プロキシ サーバーからの送信トラフィックをすべて処理せずに許可します。 TLS の中断と検査に関する問題の詳細については、「 Microsoft 365 トラフィックでサードパーティのネットワーク デバイスまたはソリューションを使用する」を参照してください。

Get-PacFile スクリプトで生成される PAC ファイルには 2 種類あります。

種類 説明
1
最適化エンドポイント トラフィックを直接送信し、その他すべてのトラフィックはプロキシ サーバーに送信します。
2
プロキシ サーバーにエンドポイント トラフィックを直接送信し、[最適化] と [許可] を選択します。 この種類を使用して、Microsoft 365 トラフィックでサポートされているすべての ExpressRoute を ExpressRoute ネットワーク セグメントに送信し、それ以外のすべてをプロキシ サーバーに送信することもできます。

PowerShell スクリプトを呼び出す簡単な例を次に示します。

Get-PacFile -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7

スクリプトに渡すことができるパラメーターは多数あります。

パラメーター 説明
ClientRequestId
このパラメーターは必須です。呼び出しを行うクライアント マシンを表す GUID で、Web サービスに渡されます。
Instance
Microsoft 365 サービス インスタンス。既定値は Worldwide です。 これは Web サービスにも渡されます。
TenantName
Microsoft 365 テナント名。 Web サービスに渡され、一部の Microsoft 365 URL で置換可能なパラメーターとして使用されます。
Type
生成するプロキシ PAC ファイルの型。

より多くのパラメーターを使用して PowerShell スクリプトを呼び出す別の例を次に示します。

Get-PacFile -Type 2 -Instance Worldwide -TenantName Contoso -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7

プロキシ サーバーは、Microsoft 365 ネットワーク トラフィックの処理をバイパスします

PAC ファイルが直接送信トラフィックに使用されない場合でも、プロキシ サーバーを構成することで、ネットワーク境界での処理をバイパスする必要があります。 一部のプロキシ サーバー ベンダーでは、Microsoft 365 ネットワーク パートナー プログラムで説明されているように、この自動構成が有効になっています。

これを手動で行う場合は、Microsoft 365 IP アドレスと URL Web サービスからエンドポイント カテゴリ データの最適化と許可を取得し、これらの処理をバイパスするようにプロキシ サーバーを構成する必要があります。 最適化および許可カテゴリ エンドポイントの TLS の中断と検査とプロキシ認証を回避することが重要です。

Microsoft 365 の IP アドレスと URL の変更管理

ネットワーク境界に適した構成を選択するだけでなく、Microsoft 365 エンドポイントの変更管理プロセスを採用することが重要です。 これらのエンドポイントは定期的に変更されます。 変更を管理しないと、新しい IP アドレスまたは URL が追加された後、ユーザーがブロックされたり、パフォーマンスが低下したりする可能性があります。

Microsoft 365 の IP アドレスと URL への変更は、通常、毎月の最終日近くに公開されます。 場合によっては、運用、サポート、またはセキュリティの要件のために、そのスケジュールの外部で変更が発行されることがあります。

IP アドレスまたは URL が追加されたために動作する必要がある変更が発行された場合は、変更を公開した時点から、そのエンドポイントに Microsoft 365 サービスが存在するまでの 30 日間の通知を受け取る必要があります。 これは有効日として反映されます。 この通知期間を目指していますが、運用、サポート、またはセキュリティの要件により、常に可能であるとは限りません。 削除された IP アドレスや URL など、接続を維持するための即時アクションを必要としない変更や、それほど重要でない変更には、事前通知は含まれません。 これらの場合、有効日は指定されません。 提供される通知に関係なく、変更ごとに予想されるサービスのアクティブな日付が一覧表示されます。

Web サービスを使用した変更通知

Microsoft 365 IP アドレスと URL Web サービスを使用して、変更通知を受け取ることができます。 /version Web メソッドを 1 時間に 1 回呼び出して、Microsoft 365 に接続するために使用しているエンドポイントのバージョンをチェックすることをお勧めします。 使用しているバージョンと比較してこのバージョンが変更された場合は、 /endpoints Web メソッドから最新のエンドポイント データを取得し、必要に応じて /changes Web メソッドとの違いを取得する必要があります。 見つかったバージョンに変更がない場合は、 /endpoints または /changes Web メソッドを呼び出す必要はありません。

詳細については、「 Microsoft 365 IP アドレスと URL Web サービス」を参照してください。

RSS フィードを使用した変更通知

Microsoft 365 IP アドレスと URL Web サービスには、Outlook でサブスクライブできる RSS フィードが用意されています。 IP アドレスと URL の各 Microsoft 365 サービス インスタンス固有のページには、RSS URL へのリンクがあります。 詳細については、「 Microsoft 365 IP アドレスと URL Web サービス」を参照してください。

Power Automate を使用した変更通知および承認確認

毎月発生するネットワーク エンドポイントの変更に対して手動処理が必要になる場合があることを理解しています。 Power Automate を使用すると、電子メールで通知するフローを作成し、必要に応じて、Microsoft 365 ネットワーク エンドポイントに変更があるときに変更の承認プロセスを実行できます。 レビューが完了すると、フローでファイアウォールとプロキシ サーバー管理チームへの変更を自動的に電子メールで送信できます。

Power Automate のサンプルとテンプレートの詳細については、「 Power Automate を使用して、Microsoft 365 の IP アドレスと URL の変更に関するメールを受信する」を参照してください。

Microsoft 365 ネットワーク エンドポイントに関する FAQ

Microsoft 365 ネットワーク接続に関してよく寄せられる質問を参照してください。

質問を送信するにはどうすればよいですか?

下部にあるリンクを選択して、記事が役に立ったかどうかを示し、それ以上の質問を送信します。 フィードバックを監視し、ここでよく寄せられる質問を更新します。

テナントの場所を確認するにはどうすればよいですか?

テナントの場所は、Microsoft のデータセンター マップを使用して最適な場所が決定されます。

私は Microsoft と適切にピアリングされていますか?

ピアリング場所の詳細については、Microsoft とのピアリングのページを参照してください。

2,500 を超える ISP ピアリング関係がグローバルかつ 70 ポイントのプレゼンスを持つ場合、ネットワークから Microsoft への移行はシームレスである必要があります。 ISP のピアリング関係が最も最適であることを確認するために数分を費やすことは問題ありません。ここでは、ネットワークに対する良好でそれほど良くないピアリングのハンドオフ のいくつかの例を示 します。

公開済みの一覧に掲載されていない IP アドレスに対してネットワーク要求を受け取ります。それらの IP アドレスに対してアクセス権を付与する必要はありますか?

直接ルーティングする必要がある Microsoft 365 サーバーの IP アドレスのみが提供されます。 これは、ネットワーク要求が表示されるすべての IP アドレスの包括的な一覧ではありません。 Microsoft およびサード パーティが所有する、公開されていない IP アドレスに対するネットワーク要求が表示されます。 これらの IP アドレスは動的に生成または管理され、変更時のタイムリーな通知を防ぎます。 ファイアウォールでこれらのネットワーク要求の FQDN に基づくアクセスを許可できない場合は、PAC または WPAD ファイルを使用して要求を管理します。

詳細については、Microsoft 365 に関連付けられている IP を参照してください。

  1. IPv4 や IPv6 などの CIDR 計算ツールを使用して、より広く公開されている範囲に IP アドレスが含まれているかどうかを確認します。 たとえば、40.103.0.1 が含まれる IP アドレス 40.96.0.0/13 には、40.96 は一致しますが、40.103 は一致しません。
  2. whois クエリ を使用して、パートナーが IP を所有しているかどうかを確認します。 Microsoft が所有している場合は、内部パートナーである可能性があります。 多くのパートナー ネットワーク エンドポイントは、IP アドレスが公開されていない 既定 のカテゴリに属するものとして一覧表示されます。
  3. IP アドレスは、Microsoft 365 または依存関係の一部ではない可能性があります。 Microsoft 365 ネットワーク エンドポイントの公開には、すべての Microsoft ネットワーク エンドポイントが含まれているわけではありません。
  4. 証明書を確認します。 ブラウザーで、HTTPS://< IP_ADDRESSを使用して IP アドレスに接続し、>証明書に一覧表示されているドメインをチェックして、IP アドレスに関連付けられているドメインを理解します。 Microsoft 所有の IP アドレスであり、Microsoft 365 IP アドレスの一覧にない場合は、IP アドレスが、公開された IP 情報を含まない MSOCDN.NET または別の Microsoft ドメインなどの Microsoft CDN に関連付けられている可能性があります。 証明書のドメインが、Microsoft が IP アドレスの登録を主張しているドメインの場合は、お知らせください。

一部の Microsoft 365 URL は、DNS 内の A レコードではなく CNAME レコードを指します。 CNAME レコードに対して何を行う必要がありますか?

クライアント コンピューターには、クラウド サービスに接続するために 1 つ以上の IP アドレスを含む DNS A または AAAA レコードが必要です。 Microsoft 365 に含まれる一部の URL には、A レコードまたは AAAA レコードではなく CNAME レコードが表示されます。 これらの CNAME レコードは中間であり、チェーン内に複数ある可能性があります。 最終的には、IP アドレスの A レコードまたは AAAA レコードに常に解決されます。 たとえば、最終的に IP アドレス IP_1に解決される次の一連の DNS レコードを考えてみましょう。

serviceA.office.com -> CNAME: serviceA.domainA.com -> CNAME: serviceA.domainB.com -> A: IP_1

これらの CNAME リダイレクトは、DNS の通常の部分であり、クライアント コンピューターに対して透過的であり、プロキシ サーバーに対して透過的です。 これらは、負荷分散、コンテンツ配信ネットワーク、高可用性、サービス インシデントの軽減に使用されます。 Microsoft は中間 CNAME レコードを公開しません。CNAME レコードはいつでも変更される可能性があるため、プロキシ サーバーで許可されるように構成する必要はありません。

プロキシ サーバーは、上記の例で serviceA.office.com された初期 URL を検証し、この URL は Microsoft 365 公開に含まれます。 プロキシ サーバーは、その URL の DNS 解決を IP アドレスに要求し、IP_1を受信します。 中間 CNAME リダイレクト レコードは検証されません。

ハードコーディングされた構成、または間接 Microsoft 365 FQDN に基づく許可リストの使用は推奨されず、Microsoft ではサポートされていません。 顧客の接続の問題が発生することがわかっている。 CNAME リダイレクトをブロックする DNS ソリューション、または Microsoft 365 DNS エントリを誤って解決する DNS ソリューションは、DNS 再帰を有効にした DNS フォワーダーまたは DNS ルート ヒントを使用して解決できます。 多くのサード パーティ製ネットワーク境界製品は、Microsoft 365 の IP アドレスと URL Web サービスを使用して、推奨される Microsoft 365 エンドポイントをネイティブに統合して、構成に許可リストを含めます。

Microsoft ドメイン名に nsatc.net や akadns.net などの名前が表示されるのはなぜですか?

Microsoft 365 およびその他の Microsoft サービスでは、Akamai や MarkMonitor などのいくつかのサード パーティ サービスを使用して、Microsoft 365 のエクスペリエンスを向上させます。 可能な限り最高のエクスペリエンスを提供し続けるために、これらのサービスは今後変更される可能性があります。 サード パーティドメインは、CDN などのコンテンツをホストしたり、地理的なトラフィック管理サービスなどのサービスをホストしたりする場合があります。 現在使用されているサービスの一部は次のとおりです。

MarkMonitor は、 *.nsatc.net を含む要求が表示されたときに使用されます。 このサービスは、悪意のある動作から保護するためのドメイン名の保護と監視を提供します。

ExactTarget は、 *.exacttarget.com への要求が表示されたときに使用されます。 このサービスは、悪意のある動作に対する電子メール リンクの管理と監視を提供します。

Akamai は、次のいずれかの FQDN を含む要求が表示されたときに使用されます。 このサービスでは、geo DNS とコンテンツ配信ネットワーク サービスを提供します。

*.akadns.net
*.akam.net
*.akamai.com
*.akamai.net
*.akamaiedge.net
*.akamaihd.net
*.akamaized.net
*.edgekey.net
*.edgesuite.net

Microsoft 365 で可能な最小限の接続が必要です

Microsoft 365 はインターネット経由で機能するように構築された一連のサービスであるため、信頼性と可用性の約束は、利用可能な多くの標準インターネット サービスに基づいています。 たとえば、DNS、CRL、CDN などの標準インターネット サービスは、最新のインターネット サービスを使用するために到達可能である必要があるのと同じように、Microsoft 365 を使用するには到達可能である必要があります。

Microsoft 365 スイートは、主要なサービス エリアに分割されています。 これらの領域は、接続に対して選択的に有効にでき、共通領域があります。これはすべてのユーザーの依存関係であり、常に必要です。

サービス分野 説明
Exchange
Exchange Online および Exchange Online Protection
SharePoint
SharePoint Online と OneDrive for Business
Skype for Business Online および Microsoft Teams
Skype for Business および Microsoft Teams
共通
Microsoft 365 Pro Plus、ブラウザーの Office、Microsoft Entra ID、およびその他の一般的なネットワーク エンドポイント

基本的なインターネット サービスに加えて、機能の統合にのみ使用されるサード パーティのサービスがあります。 これらのサービスは統合に必要ですが、Microsoft 365 エンドポイントに関する記事では省略可能としてマークされています。 つまり、エンドポイントにアクセスできない場合、サービスのコア機能は引き続き機能します。 必要なネットワーク エンドポイントには、必須の属性が true に設定されています。 オプションのネットワーク エンドポイントには、必須属性が false に設定されており、接続がブロックされている場合に必要な機能が不足していることをメモ属性で詳しく説明します。

Microsoft 365 を使用しようとしているが、サード パーティのサービスにアクセスできない場合は、 この記事で必須または省略可能とマークされているすべての FQDN がプロキシとファイアウォールを介して許可されるようにする必要があります。

Microsoft のコンシューマー サービスへのアクセスをブロックするにはどうすればよいですか?

テナント制限機能では、OneDrive、Hotmail、Xbox.com など、すべての Microsoft コンシューマー アプリケーション (MSA アプリ) の使用のブロックがサポートされるようになりました。 この機能では、login.live.com エンドポイントに対して個別のヘッダーが使用されます。 詳細については、「 テナント制限を使用して SaaS クラウド アプリケーションへのアクセスを管理する」を参照してください。

ファイアウォールには IP アドレスが必要で、URL を処理することはできません。 Microsoft 365 用に構成操作方法ですか?

Microsoft 365 では、必要なすべてのネットワーク エンドポイントの IP アドレスが提供されるわけではありません。 一部は URL としてだけ提供され、既定に分類されます。 必要な既定のカテゴリの URL は、プロキシ サーバー経由で許可する必要があります。 プロキシ サーバーがない場合は、ユーザーが Web ブラウザーのアドレス バーに入力する URL に対する Web 要求をどのように構成したかを確認します。ユーザーは IP アドレスも指定しません。 IP アドレスを提供しない Microsoft 365 の既定のカテゴリ URL は、同じ方法で構成する必要があります。

Microsoft 365 IP アドレスと URL Web サービス

Microsoft Azure データ センターの IP 範囲

Microsoft パブリック IP スペース

Microsoft Intune のネットワーク インフラストラクチャの要件

Microsoft 365 の URL と IP アドレスの範囲

Microsoft 365 ネットワーク接続の原則