Azure Portal や Office 365 への通信は、ExpressRoute のみでは完結しません

[サマリー]

  • ExpressRoute の Microsoft Peering を構成すれば、Azure や Office 365 (要個別承認) の Public IP に対して閉域網で通信できます。
  • ただし、Azure Portal や Office 365 宛の通信は ExpressRoute のみでは完結せず、一部は Internet 宛の通信が必要です。
  • Proxy や Azure Firewall 等で URL フィルターはできますが、ACL や NSG のように IP でフィルターすることはできません。

[詳細]

Azure Portal や Office 365 にアクセスをする際に F12 や Fiddler トレースをとれば明らかなように、単一のページを表示するだけでも裏では多量の通信先へアクセスが行われています。Azure Portal は様々な REST API を叩いて各種リソースの情報を呼び出して表示をしていますが、どのブレード (ページ) を開くかによって REST API も様々ですし、アイコン等は Azure 外の CDN 上でホストされていることもあり、通信先は ExpressRoute でアクセスできる Public IP だけではありません。

このため、完全閉域で Internet に一切アクセスできない環境からは、Azure Portal 等へアクセスをすることはできません。

なお、Proxy や Azure Firewall 等で URL フィルターをしている場合には、以下のブログやドキュメントに記載の URL を許可してあげることで概ね解決できるかと思います。(IP は変動する可能性もあり非公開のため、ACL や NSG で IP フィルターにて制御することはできません。)

※「概ね」と書いているのは、Azure Portal は毎日のように実装が変わるものであり、新機能が追加された際に通信先が追加される可能性も十分考えられるからです。

また、Office 365 については、以下のドキュメントやリンク先の RSS / JSON / PAC ファイルに、ER の疎通可否 (ER 列の「はい / いいえ」)、URL / IP / Port などが詳しくまとまっています。上記 Azure の場合と同様に、ワイルドカード指定で IP 未記載のものもありますので、ACL や NSG で IP フィルターを行うことはできないものと認識しましょう。

あと、Azure AD Connect の通信も、証明書の失効確認等で Azure 外のエンドポイントと通信するらしいので、ExpressRoute だけでは完結しないとのことです。

IP も FQDN も変動するおそれがありますし、ぶっちゃけ管理工数がバカにならないので、法規制があるような場合を除いては Internet 宛の通信を制限しない方が良いと思います。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください