ネットワーク制限がかかった環境から Azure 上のリソースを管理する場合のベスト プラクティス

Teppei Ishii

こんにちは、Azure サポート部の石井です。

 

オンプレミスで Proxy サーバーがある環境にて、ネットワーク制限がかかった状態から Azure Portal を操作したい、というご要望をいただく事があります。

派生案件としては、そのような環境から、特定のページや操作だけがうまくいかず、スマートフォンのテザリングなど公共網からのアクセスだと問題が無い、というケースに行き着きます。

これは、Azure Portal の実装上、URL フィルターがある環境からのアクセスが難しい、ということが原因です。今回はこのような環境からのベストプラクティスについてご紹介します。

※ 更新 2018/7/4 Cloud Shell用の許可ルールを追記しました

ポータルの仕組み

一見すると、portal.azure.com (と事前認証の Web サイト) にアクセス許可を与えればいいのでは?と考えられるのですが、実は構造上複雑です。

 

具体的には以下が理由です。

1. ポータルはパフォーマンス アップのため、CDN (キャッシュ サーバー群) とも連携し、情報を様々なバックエンドから取得する、役割分担を前提とした設計となっています。(クロス オリジン リソース共有 = CORS と呼ばれるアーキテクチャです。) このバックエンドの URL はコンポーネントにより様々です。

2. クラウドでは常に新しいサービスが追加・更新され、それに伴って URL の変更や追加が行われています。また、機能の変更だけでなく、URL をホスティングするインフラ側の理由にて変更が生じるということも考えられます。このため、今確認できる URL が将来同じとは限りません。

 

このことから、URL 一覧を把握し、あらかじめ Proxy で許可させておく、という利用方法には適しておりません。

 

現行で公開情報から導き出した URL 一覧は後述いたしますが、それでも足りない、あるいは今後動作が変わったという場合、お客様にて Fiddler という解析ツールを用いて URL の動作を確認し、適宜 Proxy サーバーの例外に追加していくという運用が想定され、茨の道であると言えます。

ネットワーク制限がかかった環境から Azure のリソースを管理する場合、以下の利用方法がベストプラクティスとなります。

 

1. Azure ポータル アクセス用の VM を一台用意し、それを踏み台とする

Azure 上に Windows VM を構築し、当該 VM にはインターネット アクセスへの制限をかけない状態とします。オンプレミスからは、そちらに RDP 接続をし、適宜ブラウザーを開いて Azure Portal にアクセスする、いわゆる踏み台サーバーとして利用する方法です。

 

多層防御の観点からも、以下のような選択肢があり、セキュアな方法であると言えます。

1. オンプレミスからは Proxy があるので、誰もポータルにアクセスができない

2. 仮想マシンには、Windows ログオン パスワードが必要であり、Windows のアカウントを所持する人間のみがアクセスできる。

3. [オプション] 仮想マシンには、NSG でソース IP を制限しておくことが可能。つまり、インターネットからの攻撃に晒される可能性は極めて低い

4. [オプション] 仮想マシン自体でログオン監査や、追加のサードパーティ ソフトウェアによる監査も可能。ユーザーがいつ何をしたのか、記録に残すことができる。

5. [オプション] 仮想マシンから Azure ポータルにアクセスするとき、電話認証を使うことでの多要素認証も可能

6. [オプション] Azure でロールベース アクセス制御を使うことで、ユーザーごとにどのリソースにアクセスを許すか定義しておけるため、誤操作・情報漏洩の防止などに役立つ

 

※ VM 上で、別途ユーザー ログオンの監査などを構成いただくと、さらにセキュアな管理が行えるかと存じます。Windows のシステムの監査系の情報を取る場合に有用なツールもあります。

Windows の IaaS VM のセキュリティ対策 – Sysmon ツールのご紹介

https://blogs.technet.microsoft.com/jpaztech/2017/03/26/sysmon_on_azurevm/

 

2. コマンド ベースの Azure PowerShell や Azure CLI  ツールで管理する

Azure PowerShell や CLI によりコマンドベースで管理を行う場合、ログインに使われる URLは判明しており、また、通信は管理系の受け口 (management.azure.com) に集約されるため、以下の通り疎通を行えれば管理が行えます。

 

※ HTTP/HTTPS 両方を許可してください。

(1)Microsoft Azure PowerShell / CLI

login.microsoftonline.com

login.live.com

management.azure.com

directory.services.live.com

management.core.windows.net

(2)Microsoft Azure Active Directoryモジュール(AAD操作用のPowerShell)

login.microsoftonline.com

login.live.com

provisioningapi.microsoftonline.com

graph.windows.net

(3) 認証用の URL

以下ドキュメントに記載の認証用 URL をすべて許可してください。Office 365 も AAD 経由での認証となり、同様の情報となります。

Office 365 の認証と ID

https://support.office.com/ja-jp/article/Office-365-URL-%E3%81%8A%E3%82%88%E3%81%B3-IP-%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E7%AF%84%E5%9B%B2-8548a211-3fe7-47cb-abb1-355ea5aa88a2?omkt=ja-JP&ui=ja-JP&rs=ja-JP&ad=JP#bkmk_identity

※ VM は稼働費用がかかってしまいますが、必要なタイミングのみ PowerShell や CLI から起動していただくことで、VM の稼働費用を抑えていただくことも可能です。PowerShell や CLI での疎通先は、以下 2 にご説明するとおり、あらかじめ把握しておくことができます。

※ ネットワーク制限のないスマートフォンの利用が行えるようでしたら、スマートフォン用の Azure アプリが存在します。ポータルの全ての機能があるわけではありませんが、VM の起動・停止といった管理操作の一部が行えます。

Android 用 Microsoft Azure

https://play.google.com/store/apps/details?id=com.microsoft.azure&utm_source=azure-blog&utm_campaign=preview-announcement

iOS 用 Microsoft Azure

https://itunes.apple.com/us/app/microsoft-azure/id1219013620?ls=1&mt=8

 

補足: 現在把握ができているURL について

どうしても Azure Portal から操作をしたい、という場合、以下が現在公開されている情報に基づく一覧となります。これら URLに対して、HTTP/HTTPS 両方について、Proxy サーバーで許可して下さい。

ただし、この一覧で現在のポータルの全機能へのアクセスができると保証するものではありません。

------------------------------------------------------------------------------------------------------------

Service Type:Global Service URI

------------------------------------------------------------------------------------------------------------

General:

*.windows.net

*.windowsazure.com

*.azure.com

*.azure-api.net

*.azure.net

*.microsoft.com

Compute:

*.cloudapp.net

Storage:

*.blob.core.windows.net

*.queue.core.windows.net

*.table.core.windows.net

*.file.core.windows.net

SQL Database:

*.database.windows.net

Service Bus:

*.servicebus.windows.net

TrafficManagerDnsSuffix:

*.trafficmanager.net

AzureDataLakeStoreFileSystemEndpointSuffix:

*.azuredatalakestore.net

AzureDataLakeAnalyticsCatalogAndJobEndpointSuffix:

*.azuredatalakeanalytics.net

Windows Azure Classic Portal:

https://manage.windowsazure.com

Microsoft Azure Account Portal:

https://account.windowsazure.com

New Azure Portal:

https://portal.azure.com/

Azure Cloud Shell(2018/07/04 追記):

*.console.azure.com

上記に加えて、以下の公開情報の認証の項にある URL すべて

Office 365 の認証と ID

https://support.office.com/ja-jp/article/Office-365-URL-%E3%81%8A%E3%82%88%E3%81%B3-IP-%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E7%AF%84%E5%9B%B2-8548a211-3fe7-47cb-abb1-355ea5aa88a2?omkt=ja-JP&ui=ja-JP&rs=ja-JP&ad=JP#bkmk_identity

Microsoft アカウントでログインをする場合を想定すると以下の URL に対してもアクセス許可が必要となります。

https://*.microsoftonline.com

https://*.live.com

- ソースとなる URL

Developer Notes for Azure in China Applications - Endpoint Mapping

https://msdn.microsoft.com/en-us/library/azure/dn578439.aspx

API Management REST

https://msdn.microsoft.com/en-us/library/azure/dn776326.aspx

Document URLs necessary to configure corporate firewalls

https://feedback.azure.com/forums/223579-azure-portal/suggestions/11569407-document-urls-necessary-to-configure-corporate-fir

 

- 追加の URL を割り出す方法について

運用コストが高い方法となりますが、Fiddler といったツールにて、自社内で通信先を調査し、都度ファイアウォール・Proxy の例外として加えるという、力業で行う方針となります。

Fiddler トレース収集ツール・収集方法について

https://blogs.msdn.microsoft.com/dsazurejp/2014/10/31/fiddler/