2020年3月17日 3:17 AM

Office 365 トラフィックをリモート ワークのためにすばやく最適化し、インフラストラクチャへの負荷を軽減するには

By

※ 本ブログは、米国時間 3/6 に公開された ”How to quickly optimize Office 365 traffic for remote staff & reduce the load on your infrastructure” の抄訳です。

この数週間、マイクロソフト、正確にいうと Office 365 ネットワーク チームは、多くのユーザーが急遽在宅勤務となって今後の計画を練っているお客様から、Office 365 への接続を最適化する最善の方法についてたくさんの問い合わせを頂いています。また、無料の Teams プランや 6 か月間の E1 無料試用版といった最近発表された Office 365 のお得なプランを利用して Teams を迅速にロールアウトしたものの、ベスト プラクティスがよくわからないというお客様からも同様のお問い合わせを頂いています。業務を継続していくと共に、ユーザーがオフィスにいなくても効果的にコラボレーションできるようにしたいというわけです。

昨今の新型コロナウイルス (COVID-19) の大流行により、多くのお客様が、大勢の従業員が在宅勤務できるようにと計画を急ピッチで進めています。大量のユーザーに対応するという接続モデルの急激な変化は、主要なクラウド サービスが登場する前にスケーリングや設計を行っていた企業や、ユーザー全員が同時に接続する必要がある状況を想定した設計になっていない企業のネットワーク インフラストラクチャに大きなインパクトを及ぼします。

VPN コンセントレーター、プロキシなどの中央ネットワーク エグレス装置、DLP、中央インターネット帯域幅、バックホール MPLS サーキット、NAT 機能といった各種のネットワーク要素は、全社的な使用により急に大きな負荷がかかることになり、その結果、パフォーマンスと生産性が低下するともに、在宅勤務を強いられたユーザーのエクスペリエンスも低下します。

下の図は従来のネットワーク モデルをシンプルに表現したものです。リモート ユーザーは企業ネットワークを経由して、重要なリソースにアクセスしたり、支社から MPLS サーキットを通じて本社で提供されているサービスにアクセスしたりします。世界中の企業でよく見られるネットワーク モデルですが、クラウドが登場する前に有効だった設計です。

クラウド ファーストの世界ではうまく機能しない従来型の企業ネットワーク

このモデルは、アプリケーション、データ、サービスの大半が企業ネットワーク (図の破線) の内側にある場合は理にかなっていてうまく機能しますが、クラウドにシフトしている現在では、拡張性に優れず、今日私たちが直面している状況にも俊敏に対応できない、扱いにくい環境になってしまっています。ネットワークを取り巻く環境が急激に変化し、企業ネットワークの外に出ることのなかったネットワーク トラフィックが、今では外部のクラウドベースのソースにしかほとんど接続していない、という報告を多くのお客様から耳にしています。

幸い、マイクロソフトには長年にわたりお客様や幅広い業界と緊密に連携してきた経験があり、こうした問題に対する効果的な最新の解決策をマイクロソフトのサービスの中から業界のベスト プラクティスに沿った形で提供することができます。リモート ワーカーにも支社にも、とてもシンプルかつ効果的に適用できる手法です。リモート ユーザーにとって Office 365 サービスが効率的に機能し、同時に組織がセキュリティの維持と接続の管理を行えるようにすることを要件として設計されています。

その簡単なステップを以下に説明します。この解決策で、大勢のユーザーが一度にリモート ワークに入ることになったときに Office 365 のトラフィックが従来型の企業インフラストラクチャに及ぼす影響を大きく緩和できます。これはユーザー パフォーマンスにも大きな効果があり、必要な企業リソースに余裕が生まれるというメリットもあります。

仮想デスクトップを使用していないリモート ユーザーの多くは、何らかの VPN ソリューションで企業環境に接続し、そこから Web ブラウジング用に設計されたオンプレミス セキュリティ スタックを通じて Office 365 に接続するのが一般的です。

ご紹介する解決策の鍵は、クリティカルな Office 365 トラフィックを分離することにあります。Office 365 トラフィックは遅延の影響を受けやすく、従来のネットワーク アーキテクチャに多大な負担がかかるからです。このトラフィックの扱い方を変え、ユーザーのローカル インターネット接続を通じてサービスに直接接続します。これには次の簡単な作業を行います。

1.最適化が必要なエンドポイントを特定する

マイクロソフトは既にこうしたエンドポイントを特定し、参照のために明確に分類しています。こうしたエンドポイントは、サービスの URL/IP リストに「最適化」と指定されています。最適化が必要なものは URL が 4 つ、IP サブネットが 19 個で、この少数のエンドポイントだけでサービスへのトラフィックのおよそ 80% を受け取っています。これには Teams メディアなど遅延の影響を受けやすいエンドポイントも含まれます。特別な注意が必要なトラフィックであり、従来のネットワーク パスをかなり圧迫するトラフィックです。

この「最適化」と指定されている URL には次の特徴があります。

  • マイクロソフトが所有・管理するエンドポイントであり、マイクロソフトのインフラストラクチャにホストされている
  • IP が用意されている
  • 他の 2 つのカテゴリと比べて URL/IP の変更頻度が低い
  • URL の数は増えないことが予想される
  • トラフィック量が多く、遅延の影響を受けやすい

この情報は REST API Web サービスで照会できます。エンドポイントの URL/IP/ポートを 3 つのカテゴリごとに出力する PowerShell のサンプル スクリプト (英語) も公開されています。

最適化の対象のエンドポイント ポート 用途
https://outlook.office365.com TCP 443 Outlook が Exchange Online サーバーに接続するために使用する中核的な URL の 1 つで、帯域幅の使用量と接続数が膨大です。クイック検索、他のメールボックスの予定表、空き時間情報の検索、ルールとアラートの管理、Exchange オンライン アーカイブ、送信トレイからのメール送信などのオンライン機能には、ネットワークの低遅延が必須です。
https://outlook.office.com TCP 443 Outlook Online の Web アクセスでの Exchange Online サーバーへの接続に使用され、ネットワーク遅延に関係します。SharePoint Online でのサイズの大きいファイルのアップロードやダウンロードには、接続性が特に重要です。
https://<テナント>.sharepoint.com TCP 443 SharePoint Online のプライマリ URL で、帯域幅の使用量が膨大です。
https://<テナント>-my.sharepoint.com TCP 443 OneDrive for Business のプライマリ URL で、帯域幅使用量が膨大です。OneDrive for Business 同期ツールからの接続数が多くなる可能性があります。
Teams メディア IP (URL なし) UDP 3478、3479、3480、3481 リレー検出の割り当てとリアルタイム トラフィック (3478)、オーディオ (3479)、ビデオ (3480)、ビデオ画面共有 (3481) というように、Skype for Business や Microsoft Teams メディアのトラフィック (通話、会議など) に使用されるエンドポイントです。ほとんどのエンドポイントは Microsoft Teams クライアントが通話を確立すると提供されます (サービス用に必要な IP 内に制限されます)。

UDP は最適なメディア品質のために必要です。

「<テナント>」は Office 365 テナント名に置き換えます。たとえば、contoso.onmicrosoft.com の場合は contoso.sharepoint.com と constoso-my.sharepoint.com を使用します。

執筆時点でこれらのエンドポイントに対応する IP の範囲は次のとおりです。ポリシーを適用する際は、前述のスクリプトを使用するか、URL/IP ページにアクセスして、更新がないか定期的に確認することを強くお勧めします。

104.146.128.0/17
13.107.128.0/22
13.107.136.0/22
13.107.18.10/31
13.107.6.152/31
13.107.64.0/18
131.253.33.215/32
132.245.0.0/16
150.171.32.0/22
150.171.40.0/22
191.234.140.0/22
204.79.197.215/32
23.103.160.0/20
40.104.0.0/15
40.108.128.0/17
40.96.0.0/13
52.104.0.0/14
52.112.0.0/14
52.96.0.0/14

  • TCP ポート 80/443
  • UDP ポート 3478、3479、3480、3481

IPV6 エンドポイントは現在必要でなければ、つまり IPV4 のみで問題なく機能しているなら無視できます (無視できるからといって必要ないわけではありません)。今後状況は変化していくと思われますが、現時点では IPV4 のみでかまいません。

2.こうした VPN 経由のエンドポイントへのアクセスを最適化する

クリティカルなエンドポイントを特定したら、これらを VPN トンネルではなくユーザーのインターネット接続から直接サービスに接続するよう経路を変更する必要があります。VPN ソリューションの大半は、特定のトラフィックを VPN トンネルを通じて企業ネットワークに送信せずにユーザーのローカル インターネット接続に直接送信する「分割トンネル (英語)」に対応しています。前述の最適化指定の URL/IP/ポートへのトラフィックがそのようにルーティングされるように VPN クライアントを構成します。これで、地域のマイクロソフト リソースをトラフィックが活用できるようになります。たとえば、Office 365 サービスのフロント ドアは AFD (英語) によって支えられており、できる限りユーザーの近くに Office 365 サービスと接続ポイントが配置されています。ユーザーが世界中どこにいても、非常に高いパフォーマンスが実現されます。また、その向こうにはマイクロソフトの世界屈指のグローバル ネットワークも存在しています。これにより、ユーザーの直接エグレス トラフィックは数ミリ秒以内に抑えられる可能性が高く、ユーザーがどこにいるかにかかわらず、トラフィックは効率的かつ安全にマイクロソフト リソースに送信されます。
このソリューションは下図のようになります。

分割トンネルを有効にしたクライアントの VPN 接続

簡単そうでしょうか。たいていの場合そうですが、企業にとってはこうした接続方法にすることによってどうしてもセキュリティの問題が生じます。従来のネットワーク アプローチでは、ネットワーク トラフィックがインターネットへと出る時点でセキュリティが施されていて、プロキシやファイアウォールがトラフィックを検査し、データが外に漏れていないか、ウイルスがないかなどをチェックしています。これを迂回すると、インターネット接続に欠かせなくなったこの保護レイヤーを失うことになります。幸い、前述のエンドポイント向けにマイクロソフトは多数の機能を既に用意しているため、新しい接続方法にすることでセキュリティが以前よりも向上する可能性があります。次に、一般的な解決策をいくつか紹介していきます。すべてのお客様に当てはまるもの、あるいは必須のものではありませんが、新しいネットワーク接続方法を実装する際によく持ち上がる懸念事項の多くに対応しています。

3.Office 365 のローカル ブレイクアウトや分割トンネルの実装においてよくある質問

現在の状況を受けて移行を早急に進めなければならない場合は、前述の 2 つのステップを実行することで、パフォーマンスや拡張性の問題を十分に解決できます。必要に応じて時間が許す限り、あるいは既に実施済みなら下の要素を追加するとよいでしょう。

Q1. データ漏洩の可能性がある信頼できない他のテナントにユーザーがアクセスするのを止めさせるにはどうすればよいですか。

A: テナント制限という機能を使用します。認証トラフィックは量が大きくなく、遅延の影響も取り立てて受けないため、VPN ソリューションを通じて、この機能を適用したオンプレミスのプロキシに送信できます。信頼できるテナントのアクセス許可リストがそこに保持されており、信頼できないテナントのトークンをクライアントが取得しようとすると、プロキシがその依頼を拒否します。テナントが信頼でき、ユーザーが適正な資格情報や権利を持っていればトークンを利用できます。

ユーザーは前述の最適化指定エンドポイントに TCP/UDP 接続できますが、テナントにアクセスするための有効なトークンを持っていなければ、ログインしたりデータにアクセスして移動したりすることはできません。

Q2. このモデルは OneDrive の個人用アカウントなどコンシューマー サービスへのアクセスを許可しますか。

A: いいえ、許可しません。Office 365 エンドポイントはコンシューマー サービス (onedrive.live.com など) とは異なるため、分割トンネルはユーザーがコンシューマー サービスに直接アクセスするのを許可しません。これまでと同様、コンシューマー エンドポイントへのトラフィックには VPN トンネルが使用され、既存のポリシーが適用されます。

Q3. トラフィックがオンプレミス ソリューションを通過しなくなったので、DLP を適用してセンシティブなデータを保護するにはどうすればよいですか。

A: 必要ならばエンドポイントを Office DLP で保護できます。この機能をサービス自体で用意する方が、ネットワーク エッジでその範囲内で実行するよりもずっと効率的です。必要に応じて、Azure Information Protection を使用して高度な情報保護を実現することもできます。

Q4. 直接接続するユーザーの認証を評価し、制御を維持するにはどうすればよいですか。

A: Q.1 で紹介したテナント制限機能に加えて、条件付きアクセス ポリシーを適用すれば、認証リクエストのリスクを動的に評価して適宜対応できます。マイクロソフトが推奨するゼロ トラスト モデルを実装し、Azure AD の条件付きアクセス ポリシーを使用することで、モバイル ファースト、クラウド ファーストで制御を維持できます。条件付きアクセス ポリシーを使用すると、次のような要素を基に認証リクエストを許可するかどうかをリアルタイムで決定できます。

  • デバイス: デバイスは既知のものか、信頼できるか、ドメインに参加しているか
  • IP: 認証リクエストは既知の企業 IP アドレスから届いているか、それとも信頼できない国からか
  • アプリケーション: ユーザーはこのアプリケーションを使用することが承認されているか

その後で、承認などのポリシーをトリガーしたり、MFA をトリガーしたり、ポリシーに基づいて認証を阻止したりすることができます。

Q5. ウイルスやマルウェアから保護するにはどうすればよいですか。

A: 前述のように、Office 365 は最適化指定のエンドポイントをサービス自体のさまざまなレイヤーで保護しています。概要はこちらの資料をご覧ください。こうしたセキュリティ要素はサービス自体の中で提供する方が、プロトコル/トラフィックを完全には理解していない可能性のあるデバイスに合わせて試行錯誤するよりもずっと効率的です。

前述の Exchange エンドポイントについては、Exchange Online Protection と Office 365 Advanced Threat Protection がサービスへのトラフィックに対してセキュリティを提供します。

Q6. 最適化対象トラフィック以外も直接送信できますか。

A. 少しの作業で最大限のメリットが得られる最適化指定エンドポイントを優先すべきです。ただし、「許可」が指定されているエンドポイントはサービスが機能するために欠かせないため、必要に応じて使用可能なエンドポイントの IP が用意されています。

また、セキュア Web ゲートウェイと呼ばれるクラウド ベースのプロキシ/セキュリティ ソリューションを提供しているさまざまなベンダーから、一般的な Web ブラウジング用の中央セキュリティ システム、コントロール機能、企業ポリシー アプリケーションなどが提供されています。これらのソリューションが高い可用性とパフォーマンス性能を備え、ユーザーに近いクラウド ベースの場所から安全なインターネット アクセスを提供しているなら、クラウド ファーストの世界でうまく活用できるでしょう。それによって、ブラウジング全般のトラフィックのために VPN/企業ネットワークを経由する必要がなくなると共に、中央でのセキュリティ コントロールが可能になります。
しかし、こうしたソリューションが用意されていても、マイクロソフトは最適化指定の Office 365 トラフィックをサービスに直接送信することを強くお勧めします。

Q7. なぜポート 80 が必要なのですか。トラフィックは平文で送信されるのですか。

A. ポート 80 は、ポート 443 セッションへのリダイレクトなど、限定的に使用します。お客様のデータがポート 80 へ送信されたり、アクセス可能になったりすることはありません。Office 365 の転送中および保存中のデータの暗号化については、こちらのドキュメントで概説しています。SRTP を使用して Teams メディア トラフィックをどのように保護しているかについては、こちらのドキュメントをご覧ください。

Q8. ここで紹介されているアドバイスは、Office 365 のワールドワイド インスタンスを使用している中国のユーザーにも適用できますか。

A. いいえ。Office 365 のワールドワイド インスタンスに接続している中国のユーザーについては注意が必要です。この地域では国境を越えたネットワークの混雑が頻繁に発生するため、インターネットによる直接エグレスのパフォーマンスは安定しない可能性があります。この地域のほとんどのお客様は、VPN を使用してトラフィックを企業ネットワークに送信し、承認された MPLS 回線または同等のものを利用して、最適化されたパスを介して国外へ送信しています。これについては、こちらのドキュメント (https://docs.microsoft.com/ja-jp/office365/enterprise/office-365-networking-china) をご覧ください。

何かご質問がございましたら、下のコメント欄までお寄せください。できるだけ速やかに回答できるよう最善を尽くします。

4.関連情報

Office 365 の接続に関する一般的なベスト プラクティス
http://aka.ms/pnc
https://docs.microsoft.com/ja-jp/archive/blogs/onthewire/__guidance (英語)

Ignite の録画セッション
https://myignite.techcommunity.microsoft.com/sessions/81561?source=sessions (英語)
https://myignite.techcommunity.microsoft.com/videos/64276 (英語)
https://myignite.techcommunity.microsoft.com/videos/64275 (英語)

Office 365 パートナー プログラム
https://resources.techcommunity.microsoft.com/networking/ (英語)
現在のパートナーは Citrix (英語)、Netfoundry (英語)、NTT、SilverPeak (英語)、Zscaler (英語) です。

ネットワークの接続のパフォーマンス テスト
https://connectivity.office.com/ (英語)
このツールは、最適化指定のエンドポイントを含む Office 365 エンドポイントに対してテストを実行し、接続の際にこうしたエンドポイントの探し方や接続性を向上させるためにできることについて、わかりやすいフィードバックを提供します。

帯域幅の計画
https://aka.ms/bandwidth/
このツールは、ユーザーの Office 365 ネットワーク トラフィック量を監視して、広範な企業の帯域幅要件に関して明確な数字を把握できるようになっています。

Join the conversation