はじめに
Azure Files は オンプレミス AD DS との連携も可能な、マネージドなファイル共有サービスです。
今回は、Azure Files へのアクセス経路を検討し、プライベートエンドポイントを構成してみます。
アクセス経路の検討
Azure Files は PaaS サービスですので、既定ではストレージアカウント の パブリックIPアドレスと通信して利用することになります。
しかし、プライベートエンドポイント と組み合わせれば、プライベートIPアドレスでアクセス可能になります。VPNで張ったトンネル内を通るように構成することもできますし、ExpressRoute で接続している場合は、インターネットを経由しないアクセスも可能です。
また、ストレージアカウントにはファイアウォール機能があり、パブリックIPアドレスへのアクセス経路を制限することで、接続元を限定できます。パブリックアクセスを無効化して、プライベートエンドポイントからの接続を強制することや、プライベートエンドポイントを利用しない場合でも、オンプレミスのグローバルIPアドレスからのみに接続元を絞るといったことも検討できます。
念のため、Azure VM も含めて整理してみました。
アクセス経路の検討
| 組合せ | オンプレミス からのアクセス | Azure VM からのアクセス | ストレージアカウントのファイアウォール機能 アクセス元の制限 |
|
|---|---|---|---|---|
| 1 | 既定 | インターネット経由 | MS内 バックボーン経由 | 接続元グローバルIPを絞ることを検討する |
| 2 | サービスエンドポイントを利用する | インターネット経由 | MS内 バックボーン経由 | 接続元VNet と 接続元グローバルIPを絞ることを検討する |
| 3 | プライベートエンドポイント | VPN / ExpressRoute 経由 | 仮想ネットワーク内 | パブリックアクセス無効化し、プライベートエンドポイント経由を強制することを検討する |
オンプレミスからの接続だけ考える場合は、サービスエンドポイントについては関係がありません。
Azure VM の場合は、サービスエンドポイント と プライベートエンドポイント の選択に困る場合もあるかと思います。以下のサポートブログに違いが整理されており参考になります。
基本的にはプライベートエンドポイントを利用するのが間違いないと思います。
プライベートエンドポイントを選択した場合の動作の詳細は、以下が参考になります。
検証環境の全体構成
検証環境の全体構成
今回検証環境は、こんな感じで作っていきます。
- 前提
- オンプレミス側には、AD DS を用意しておき、Azure AD Connect Cloud Sync で Azure AD と同期済みです。
- AADSyncUsers OU 内の demouser01 と demouser02 がハイブリッド ID として構成済みのユーザーです。
- Azure 側には Storag Account を作成し、ファイル共有 ( Azure Files ) を作成してあります。
- Azure Files は オンプレミス AD DS と連携しており、オンプレミス環境内 の クライアント から利用可能な状態です。
事前に用意しておいた範囲
以下２つを実施済みです
- 今回の検証
- Azure側に Azure Files と紐づく プライベートエンドポイント を構成して、プライベートIPアドレスでのアクセスを可能にします。
- Azure側に カスタム DNS サーバー を構築し、オンプレミス DNS に条件付きフォワーダーを構成して、オンプレミスからもプライベートエンドポイントを利用可能にします。
- ストレージアカウント (Azure Files) へのアクセス経路を制限し、プライベートエンドポイント経由以外でのアクセスを拒否させます。
Azure Firewall を利用した場合の構成
Azure側に配置する カスタム DNS サーバー（DNS Proxy)について、Azure Firewall を利用することもできます。オンプレミスと VPN/ExpressRoute で接続する際には、同時に Azure Firewall もデプロイする場合も多く、利用できる場合もあるかと思います。また、カスタム DNS サーバー を構成する場合には、冗長構成とすることも検討が必要ですが、Azure Firewall であれば既定で冗長化されています。
また、Azure DNS Private Resolver を利用して構成することも可能(Japan East GA済み / Japan West 未対応)です。
マネージドサービスなので、既定で冗長化されており、定期的なパッチ適用等が不要など運用負荷がさげられるので、本番利用の際にはご検討頂けると思います。
Step1. ネットワークを用意する
まずは、仮想ネットワークとサブネットを作成します。
その後、仮想ネットワークゲートウェイを作成し、オンプレミスと仮想ネットワークを接続します。
仮想ネットワークとサブネットを作成する
1-1. 仮想ネットワークとサブネットを作成する
特に代り映えのない手順なので、折りたたんでおきます。
Azure Portal から 仮想ネットワーク と サブネット を作成する
作成する 仮想ネットワーク の 仮想ネットワーク名 と リージョンを選択します。
仮想ネットワークの作成
仮想ネットワークのアドレス空間 と サブネット を設定します。
デフォルトで作成されているもののままでも良いですが、調整が必要な場合はゴミ箱アイコンをクリックして削除してから、追加をします。
なお、アドレス空間 は 複数追加することができます。(例えば、一つの VNet に 10.0.0.0/16 と 192.168.0.0/24 を持たせることも可能です。)
IPアドレス空間 と サブネット の設定
[IPアドレス空間の追加] で、仮想ネットワークのアドレス空間を設定します。
アドレス空間のサイズは、プルダウンから選択します。
IPアドレス空間の作成
[+サブネットの追加] で、サブネットを追加します。
[サブネットテンプレート] は Default を選択します。
名前や、開始アドレス、サイズを設定します。
なお、本番環境では [ネットワークセキュリティグループ] の紐づけを検討してください。
サブネットの作成
1-2. オンプレミスと仮想ネットワークを接続する
オンプレミスと仮想ネットワークを接続します。選択肢は Express Route と VPN があります。
オンプレミスとの接続は本記事の本筋ではないので省略してしまいますが、以下などが参考になると思います。
-
Express Route の導入手順
-
VPN の導入手順
また、Azure 上 に 模擬オンプレミス環境を作成して検証する場合などは、リソースグループ や VNet を 2つ作成して VNet Peering で代替しても良いです。
以下の記事を参考に VPN を構成してもよいかと思います。
Step2. プライベートエンドポイント と プライベートDNSゾーン を作成する
プライベートエンドポイント と プライベートDNSゾーン を作成する
2-1. プライベートエンドポイント と プライベートDNSゾーン を作成する
プライベートエンドポイント と プライベートDNSゾーン を 作成します。
プライベートエンドポイントの作成中に、自動的にプライベートDNSゾーンも作成できます。
Azure Portal で [プライベートエンドポイント] と検索して、プライベートエンドポイントの作成を開始します。
プライベートエンドポイントの作成を開始
Private Link センター に移動しますので、[作成] をクリックします。
プライベートエンドポイントの作成を開始
プライベートエンドポイント や NIC のリソース名 などを設定します。
プライベートエンドポイント や NIC のリソース名 を指定する
プライベートエンドポイント と 関連付けするリソースを選択する画面が表示されます。
- [リソースの種類] は ストレージアカウント ですので、
Microsoft.Storage/storageAccountsを選択します。Storage などと検索すると候補がでますので、それで選択すると良いかと思います。 - [リソース] では、ストレージアカウント名 を指定します。これも、選択可能なものがプルダウンメニューに出ますので、そこから選べば良いです。
- [対象サブリソース] は、Azure Files ですので、
fileを選択します。
プライベートエンドポイント と 関連付けするリソースを選択する
プライベートエンドポイント の NIC を配置する仮想ネットワーク と サブネット を選択します。
IPアドレスは、動的に割り当てることも、静的に割り当てることもできます。
動的にしても、NIC を再作成しなければ、IPアドレスは変わりません。
動的でも良いですが、IPアドレスを奇麗に整理したい場合（例えば 10.50.0.0 - 99 は xxx用、 10.50.0.100 - 199 は PrivateEndpoint用 など）には静的で割り当てるとよいでしょう。
今回は、静的に 10.50.0.100 を割り当てることにします。
プライベートエンドポイント の IPアドレス を指定
プライベートエンドポイント を 名前解決できるよう、プライベートDNSゾーン が自動的に作成されます。
既に作成済みの場合は、既存のプライベートDNSゾーンを選択することもできます。
プライベート DNS ゾーン を指定
これで作成を行います。
作成が完了すると、プライベートエンドポイント、NIC、プライベートDNSゾーン が作成されます。
作成完了後のリソースグループの様子
2-2. 作成されたリソースを確認しておく
作成されたリソースの状況をキャプチャしておきましたので、貼っておきます。
プライベートエンドポイントの様子
作成した プライベートエンドポイント を確認すると、プライベートリンクリソースとして、指定した ストレージアカウント と紐づいていることが分かります。
また、 [DNSの構成] を覗いてみると、設定したIPアドレスや、プライベートDNSゾーンとの関連づけられていることが分かります。
プライベートエンドポイント の様子
プライベートエンドポイント の DNSの構成
プライベートDNSゾーンの様子
プライベートDNSゾーン を確認すると、プライベートエンドポイント に対応する Aレコード が登録されていることが分かります。
プライベートDNSゾーン の様子
プライベートDNSゾーン は、仮想ネットワークとリンクさせることで、リンクされた仮想ネットワーク内からフォワードされるようになります。
プライベートエンドポイント の NIC が配置された仮想ネットワークと、リンクされていることが確認できます。
プライベートDNSゾーン がリンクされている仮想ネットワーク
NIC の様子
作成された NIC には、指定したIPアドレスが割り当てられていることが分かります。
また、プライベートエンドポイント と紐づいていることが分かります。
NIC の様子
Plivate Link センターの様子
Plivate Link センターでは、各プライベートエンドポイント の様子を一覧で確認することができます。
Plivate Link センター
Step3. Azure上の DNS サーバーで作成 と プライベートエンドポイント の名前解決を確認
Azure上での名前解決の流れ
ファイル共有へのアクセスは、パブリックIPアドレスではなく、作成した プライベートエンドポイント に名前解決される必要があります。
Azure 上には、168.63.129.16 という特別なIPアドレスがあり、VNet に既定で設定されている DNS サーバー となっています。
このIPアドレスに対して名前解決を要求することで、リンクされたプライベートDNSゾーン に登録された Aレコード が返されるようになっています。
ただし、オンプレミスから直接、168.63.129.16 に名前解決を要求することはできません。
そのため、オンプレミスからの名前解決を行う場合は、Azure 上に DNS サーバー を立てる必要があります。
3-1. 確認用VMの作成して、同一仮想ネットワーク内からアクセスしてみる
まずは、同一仮想ネットワーク内から、名前解決をしてみます。
確認用のVMは、この後 Azure 上のカスタム DNS サーバー （DNS Proxy） として利用するため、DNSvm という名前で作成してみました。
確認用に作成したVM。後ほどDNS サーバー （DNS Proxy）として利用する
作成後、ログインして nslookup を叩きます。
既定で、仮想ネットワーク内の DNSサーバーとして 168.63.129.16 が設定されていることが分かります。
プライベートエンドポイント を 作成した uuesamafileshare01.file.core.windows.net については、プライベートIPアドレスに解決されています。
プライベートエンドポイント を 作成していない uuesamafileshare02.file.core.windows.net については、パブリックIPアドレスに解決されています。
C:\>nslookup
既定のサーバー: UnKnown
Address: 168.63.129.16
> uuesamafileshare01.file.core.windows.net
サーバー: UnKnown
Address: 168.63.129.16
権限のない回答:
名前: uuesamafileshare01.privatelink.file.core.windows.net
Address: 10.50.0.100
Aliases: uuesamafileshare01.file.core.windows.net
> uuesamafileshare02.file.core.windows.net
サーバー: UnKnown
Address: 168.63.129.16
権限のない回答:
名前: file.tyo20prdstr05a.store.core.windows.net
Address: 20.150.105.8
Aliases: uuesamafileshare02.file.core.windows.net
なお、指定する名前は、<ストレージアカウント名>.file.core.windows.net ですが、ストレージアカウント の [エンドポイント] - [File サービス] からも確認ができます。blob や queue などのエンドポイント も、ここで確認できます。
ストレージアカウント の エンドポイント
3-2. Azure 上のカスタム DNS サーバー で 168.63.129.16 をフォワーダーとして設定する
仮想ネットワーク内 に DNS Proxy となるサーバーを作成します。
VM 自体は、Step3-1. で作成した VM を利用します。
DNS の役割をインストールし、DNS フォワーダーを構成します。
168.63.129.16 をフォワーダーとして設定します。
DNS の役割をインストールする
DNS フォワーダーを構成する
既定ではルートヒントに基づいてインターネット側の DNS サーバーに問い合わせが行われますが、これを Azure 上の DNS サーバーに問い合わせるようにするようフォワーダーを設定します。
フォワーダーとして、168.63.129.16 を指定します。
Step4. オンプレミス DNS サーバーで、条件付きフォワーダーを構成する
オンプレミス DNS サーバーの条件付きフォワーダー
オンプレミス側 の DNS サーバーから、Step3 で作成した Azure 上のカスタム DNS サーバー に対して、条件付きフォワーダーを構成します。
条件付きフォワーダーの条件として、file.core.windows.net を指定します。
今回、オンプレミス側の DNS サーバーは AD サーバーです。
早速設定していきます。
条件付きフォワーダーの新規作成
file.core.windows.net を指定し、Step5 で作成した DNS Proxy の プライベートIP アドレスを指定します。
今回、オンプレミス側の DNS サーバーは AD サーバーですので、条件付きフォワーダーの設定をどの範囲でレプリケートするかも指定します。
条件付きフォワーダーの構成
条件付きフォワーダーの構成完了
Step5. オンプレミス側 クライアントPC から Azure File にアクセスする
ファイル共有のプライベートIPへの名前解決 と プライベートIPでのマウント経路
オンプレミス側 クライアントPC に demouser01 でログインして確認してみます。
まずは nslookup から。オンプレミス側 AD サーバーに問い合わせが行われ、条件付きフォワーダーにより、Azure 上のカスタム DNS サーバー に問い合わせが行われ...結果、プライベートIPアドレスに解決されています。
C:\Users\demouser01>nslookup uuesamafileshare01.file.core.windows.net
Server: UnKnown
Address: 10.0.0.4
Non-authoritative answer:
Name: uuesamafileshare01.privatelink.file.core.windows.net
Address: 10.50.0.100
Aliases: uuesamafileshare01.file.core.windows.net
続いて、 PowerShell で、Azure Files に対して TCP ポート 445 (SMB) でアクセスできるかどうかを確認してみます。
プライベートIPアドレス でアクセスできていることが確認できます。
PS C:\Users\demouser01> Test-NetConnection -ComputerName uuesamafileshare01.file.core.windows.net -Port 445 ComputerName : uuesamafileshare01.file.core.windows.net
RemoteAddress : 10.50.0.100
RemotePort : 445
InterfaceAlias : Ethernet
SourceAddress : 10.0.0.7
TcpTestSucceeded : True
Azure File をマウントし、アクセスしてみます。
netstat の結果を TCP ポート 445 でフィルタすると、確かにプライベートIPアドレス経由でマウントしていることが確認できました。
ファイル共有 の 宛先を確認
C:\Users\demouser01>netstat -an | find ":445"
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 10.0.0.7:49774 10.50.0.100:445 ESTABLISHED
TCP [::]:445 [::]:0 LISTENING
Step6. Azure Files のパブリックIPアドレスへのアクセスを拒否するよう設定する
Azure Files のパブリックIPアドレスへのアクセスを拒否する
プライベートエンドポイント経由でアクセスが可能になったことを確認したら、Azure Files のパブリックIPアドレスへのアクセスを拒否する設定を行います。
Azure Files のパブリックIPアドレスへのアクセスを拒否することで、プライベートエンドポイント経由でのアクセスが強制されます。
なお、拒否設定は、データプレーンのみに適用されます。
管理プレーンへのアクセスは、引き続きパブリックIPアドレス(例えば Azure Portal から設定を変更することなど）で可能です。
6-1. Azure Files のファイアウォール設定を変更する
ストレージアカウント [セキュリティとネットワーク] - [ネットワーク] から、[ファイアウォールと仮想ネットワーク]タブの [パブリックネットワークアクセス] の設定を変更します。
既定では [すべてのネットワーク] が許可されていますが、[無効]と設定します。
ストレージアカウント の ネットワーク設定画面
なお、[選択した仮想ネットワークとIPアドレスから有効] に変更した場合には、[ファイアウォール] の欄で、管理用PCだけはパブリックIPで疎通が可能とするなど、設定することができます。
なお、例外欄にある、[信頼されたMicrosoftサービスからのアクセスを許可する] は、Azure のサービスからのアクセスを許可する設定です。これを外してしまうと Backup などの Azure サービスからのアクセスができなくなりますので、注意が必要です。外さないようにします。
選択した仮想ネットワークとIPアドレスから有効 の場合
パブリックIPへの接続を拒否する前に、タブを切替して、プライベートエンドポイントからのアクセスが可能であることは念のため確認しておきます。
プライベートエンドポイント の状態を確認
[無効]と設定します。
無効 の場合
無効 設定後
6-2. パブリックIPアドレスへのアクセスが拒否されていることを確認する
無効 と設定したことでパブリックIPアドレスへのアクセスは拒否されます。
Azure Portal から、Azure Files のファイル共有にアクセスしてみます。
無効化前は確認できていたファイルやフォルダが、確認できなくなっています。
Azure Portal からパブリックアクセス - Deny
プライベートエンドポイント経由であれば、引き続きアクセスできます。
クライアント から プライベートエンドポイント経由でアクセス - Allow
まとめ
Azure Files のプライベートエンドポイントを利用した構成
Azure Files は Azure の PaaS サービスですが、プライベートエンドポイントを利用することで、オンプレミス から プライベートIP でアクセスすることができました。
ExpressRoute と組み合わせれば、インターネットを経由せずに、オンプレミスから Azure Files へのアクセスが可能になります。
オンプレミスの延長のような感覚で、Azure Files を利用することができるのではないでしょうか。
参考情報
Discussion
大変分かりやすくありがたいです。
こちらの部分はAzure DNS Private Resolver 使うことでも代用可能でしょうか👀
もちろん可能です！
Azure DNS Private Resolver であれば、マネージドサービスなので運用負荷が低く、ゾーン冗長の可用性を勝手に組んでくれるので、むしろそちらが推奨です！