Azure Files のネットワークに関する考慮事項

Azure ファイル共有には、インターネットにアクセスできるパブリック エンドポイント経由で、ネットワーク上の 1 つ以上のプライベート エンドポイント経由で、またはオンプレミスの Azure ファイル共有を Azure File Sync (SMB ファイル共有のみ) でキャッシュすることでアクセスできます。 この記事では、パブリック エンドポイントまたはプライベート エンドポイント経由で直接アクセスできるように Azure Files を構成する方法について説明します。 Azure File Sync を使用してオンプレミスで Azure ファイル共有をキャッシュする方法については、「Azure File Sync の概要」を参照してください。

このガイドを読む前に、「Azure Files のデプロイの計画」を読むことをお勧めします。

Azure ファイル共有への直接アクセスでは、多くの場合、ネットワークに関するさらなる考慮が必要になります。

• SMB ファイル共有はポート 445 を介して通信します。このポートでは、多くの組織やインターネット サービス プロバイダー (ISP) が送信 (インターネット) トラフィックをブロックしています。 この慣例の由来は、SMB プロトコルの非推奨かつ非インターネットセーフのバージョンに関する以前のセキュリティ ガイダンスにあります。 SMB 3.x はインターネットセーフのプロトコルですが、組織や ISP のポリシーは変更できないことがあります。 そのため、SMB ファイル共有をマウントするには、多くの場合、Azure の外部で使用するためネットワーク構成に追加が必要になります。

• NFS ファイル共有はネットワーク レベルの認証に依存するため、制限されたネットワーク経由でのみアクセスできます。 NFS ファイル共有を使用するには、常に何らかのレベルのネットワーク構成が必要です。

Azure Files のパブリック エンドポイントとプライベート エンドポイントの構成は、Azure Files の最上位の管理オブジェクト (Azure ストレージ アカウント) で行われます。 ストレージ アカウントは、複数の Azure ファイル共有をデプロイできるストレージの共有プールだけでなく、BLOB コンテナーやキューなどのその他の Azure ストレージ サービスのストレージ リソースを表す管理構造です。

このビデオは、簡単な 5 つのステップでインフォメーション ワーカーやアプリに直接 Azure ファイル共有を安全に公開する方法についてのガイドとデモです。 下のセクションでは、ビデオ内で参照されているドキュメントへのリンクと追加のコンテキストを提供します。 Azure Active Directory は Microsoft Entra ID になりましたので注意してください。 詳細については、「Azure AD の新しい名前」を参照してください。

適用対象

ファイル共有の種類	SMB	NFS
Standard ファイル共有 (GPv2)、LRS/ZRS
Standard ファイル共有 (GPv2)、GRS/GZRS
Premium ファイル共有 (FileStorage)、LRS/ZRS

転送がセキュリティで保護される

既定では、パブリック エンドポイントとプライベート エンドポイントのどちらを介してデータにアクセスするかに関わらず、Azure ストレージ アカウントには、安全な転送が必要です。 Azure Files の場合、SMB、NFS、FileREST など、Azure ファイル共有に格納されているデータへのすべてのプロトコル アクセスに対して、[安全な転送が必要]な設定が適用されます。 [安全な転送が必要] の設定を無効にして、暗号化を行わないトラフィックを許可することができます。 また、Azure portal でこの設定が REST API 操作の安全な転送を必須にする と誤ってラベル表示されていることもあります。

SMB、NFS、および FileREST プロトコルの場合は、 [安全な転送が必要] の設定の動作が若干異なります。

• ストレージ アカウントで [安全な転送が必要] が有効になっている場合、そのストレージ アカウントのすべての SMB ファイル共有には、SMB クライアントと Azure Files 間で使用可能/必要な暗号化ネゴシエーションに応じて、AES-128-CCM、AES-128-GCM、または AES-256-GCM 暗号化アルゴリズムを使用した SMB 3.x プロトコルが必要になります。 SMB セキュリティ設定を使用して、許可される SMB 暗号化アルゴリズムを切り替えることができます。 [安全な転送が必要] の設定を無効にすると、暗号化なしで SMB 2.1 と SMB 3.x のマウントが有効になります。

• NFS ファイル共有は暗号化メカニズムをサポートしていないため、NFS プロトコルを使用して Azure ファイル共有にアクセスするには、ストレージ アカウントの [安全な転送が必要] を無効にする必要があります。

• 安全な転送が必要な場合、FileREST プロトコルは HTTPS でのみ使用できます。 現在、FileREST は、SMB ファイル共有のみでサポートされています。

パブリック エンドポイント

ストレージ アカウント内の Azure ファイル共有のパブリック エンドポイントは、インターネットで公開されているエンドポイントです。 パブリック エンドポイントはストレージ アカウントの既定のエンドポイントですが、必要に応じて無効にできます。

SMB、NFS、FileREST のプロトコルはすべて、パブリック エンドポイントを使用できます。 ただし、それぞれアクセスのルールが少し異なります。

• SMB ファイル共有には、暗号化された SMB 3.x を使用して、ストレージ アカウントのパブリック エンドポイントを介して世界のどこからでもアクセスできます。 つまり、ユーザーのログオン ID によって承認された要求など、認証済みの要求は、Azure リージョンの内外から安全に送信できます。 暗号化しない SMB 2.1 または SMB 3.x が必要な場合は、次の 2 つの条件を満たす必要があります。

  1. ストレージ アカウントの [安全な転送が必要] の設定を無効にする必要があります。
  2. 要求は、Azure リージョン内から送信する必要があります。 前述のように、暗号化された SMB 要求は、Azure リージョンの内外を問わず、どこからでも許可されます。

• ストレージ アカウントのパブリック エンドポイントがサービス エンドポイントを使用する特定の仮想ネットワークに制限されている場合にのみ、NFS ファイル共有は、ストレージ アカウントのパブリック エンドポイントからアクセスできます。 サービス エンドポイントの詳細については、パブリック エンドポイントのファイアウォール設定を参照してください。

• FileREST には、パブリック エンドポイント経由でアクセスできます。 安全な転送が必要な場合は、HTTPS 要求のみが受け入れられます。 安全な転送が無効になっている場合、HTTP 要求は、配信元に関係なくパブリック エンドポイントによって受け入れられます。

パブリック エンドポイントのファイアウォール設定

ストレージ アカウント ファイアウォールは、ストレージ アカウントのパブリック エンドポイントへのアクセスを制限します。 ストレージ アカウント ファイアウォールを使用すると、特定の IP アドレス/IP アドレス範囲や、特定の仮想ネットワークへのアクセスを制限したり、パブリック エンドポイントを完全に無効にしたりすることができます。

パブリック エンドポイントのトラフィックを 1 つ以上の仮想ネットワークに制限する場合は、 サービス エンドポイントと呼ばれる仮想ネットワークの機能を使用しています。 Azure Files のサービス エンドポイントに送信された要求は引き続きストレージ アカウントのパブリック IP アドレスに送信されますが、ネットワーク層は、要求が承認された仮想ネットワークからのものであることを検証するために、要求に対する追加の検証を行っています。 SMB、NFS、および FileREST プロトコルはすべて、サービス エンドポイントをサポートします。 ただし、SMB や FileREST とは異なり、NFS ファイル共有には、サービス エンドポイントを使用してパブリック エンドポイントでのみアクセスできます。

ストレージ アカウントのファイアウォールを構成する方法の詳細については、「Azure Storage ファイアウォールおよび仮想ネットワークを構成する」を参照してください。

パブリック エンドポイント のネットワーク ルーティング

複数のネットワーク ルーティング オプションが、Azure Files によってサポートされています。 既定のオプションである Microsoft ルーティングは、Azure Files のすべての構成で動作します。 インターネット ルーティング オプションでは、AD ドメイン参加シナリオまたは Azure File Sync はサポートされていません。

プライベート エンドポイント

Azure Files では、ストレージ アカウントの既定のパブリック エンドポイントに加え、1 つ以上のプライベート エンドポイントを使用することもできます。 プライベート エンドポイントは、Azure 仮想ネットワーク内でのみアクセス可能なエンドポイントです。 ストレージ アカウントのプライベート エンドポイントを作成すると、ストレージ アカウントには、仮想ネットワークのアドレス空間内のプライベート IP アドレスが与えられます。ちょうど、オンプレミスのファイル サーバーや NAS デバイスに、そのオンプレミス ネットワークの専用アドレス空間から IP アドレスが割り当てられるのと似ています。

個々のプライベート エンドポイントは、Azure 仮想ネットワークの特定のサブネットに関連付けられます。 ストレージ アカウントには、複数の仮想ネットワーク内のプライベート エンドポイントを使用することができます。

Azure Files でプライベート エンドポイントを使用することにより、次のことが可能となります。

• オンプレミス ネットワークから、VPN または ExpressRoute 接続によるプライベートピアリングを使用して Azure ファイル共有に安全に接続します。
• パブリック エンドポイントでのすべての接続をブロックするようにストレージ アカウントのファイアウォールを構成することで、Azure ファイル共有をセキュリティで保護します。 既定では、プライベート エンドポイントを作成しても、パブリック エンドポイントへの接続はブロックされません。
• 仮想ネットワーク (およびピアリングの境界) からのデータの流出をブロックできるようにすることで、仮想ネットワークのセキュリティを強化します。

プライベート エンドポイントを作成する方法については、Azure Files 用のプライベート エンドポイントの構成に関するページを参照してください。

仮想プライベート ネットワークまたは ExpressRoute でトラフィックをトンネリングする

プライベート エンドポイントを使用してオンプレミスから SMB または NFS ファイル共有にアクセスするには、オンプレミス ネットワークと Azure の間にネットワーク トンネルを確立する必要があります。 仮想ネットワーク (VNet) は、従来のオンプレミス ネットワークに似ています。 Azure ストレージ アカウントや Azure VM と同様に、VNet は、リソース グループにデプロイされる Azure リソースです。

オンプレミスのワークステーションやサーバーと Azure SMB/NFS ファイル共有の間のトラフィックをトンネリングするために、Azure Files は次のメカニズムをサポートしています。

• VPN ゲートウェイは、暗号化されたトラフィックをインターネット経由で Azure 仮想ネットワークと別の場所 (オンプレミスなど) の間で送信するために使用される特定の種類の仮想ネットワーク ゲートウェイです。 Azure VPN Gateway は、ストレージ アカウントまたはその他の Azure リソースと共にリソース グループにデプロイできる Azure リソースです。 VPN ゲートウェイは、次の 2 つの異なる種類の接続を公開します。
  • ポイント対サイト (P2S) VPN ゲートウェイ接続。これは、Azure と個々のクライアントの間の VPN 接続です。 このソリューションは主に、組織のオンプレミス ネットワークに含まれていないデバイスに役立ちます。 一般的なユース ケースは、自宅、コーヒー ショップ、またはホテルから外出中に Azure ファイル共有をマウントできるようにしたい在宅勤務者向けです。 Azure Files で P2S VPN 接続を使用するには、接続したいクライアントごとに P2S VPN 接続を構成する必要があります。 P2S VPN 接続のデプロイを簡略化するには、「Windows 上で Azure Files で使用するポイント対サイト (P2S) VPN を構成する」および「Linux 上で Azure Files で使用するポイント対サイト (P2S) VPN を構成する」を参照してください。
  • サイト間 (S2S) VPN。これは、Azure と組織のネットワークの間の VPN 接続です。 S2S VPN 接続を使用すると、Azure ファイル共有にアクセスする必要のあるクライアント デバイスごとにではなく、組織のネットワークでホストされている VPN サーバーまたはデバイスについて 1 回 VPN 接続を構成するだけで済みます。 S2S VPN 接続のデプロイを簡略化するには、Azure Files で使用するサイト間 (S2S) VPN の構成に関するページを参照してください。
• ExpressRoute。これにより、Azure とインターネットを経由しないオンプレミス ネットワークの間に定義されたルートを作成できます。 ExpressRoute はオンプレミスのデータセンターと Azure の間の専用のパスを提供するため、ExpressRoute は、ネットワーク パフォーマンスが考慮事項であるときに役立つことがあります。 ExpressRoute はまた、組織のポリシーまたは規制要件にクラウド内のリソースへの確定的なパスが必要な場合の適切なオプションでもあります。

Note

プライベート エンドポイントを使用してオンプレミス ネットワークを Azure に拡張することをお勧めしますが、技術的には VPN 接続経由でパブリック エンドポイントへのルーティングが可能です。 ただし、これには、ストレージ アカウントを提供する Azure ストレージ クラスターのパブリック エンドポイントの IP アドレスをハードコーディングする必要があります。 ストレージ アカウントはいつでもストレージ クラスター間で移動される可能性があり、新しいクラスターは頻繁に追加および削除されるため、可能なすべての Azure ストレージ IP アドレスをルーティング規則に定期的にハードコーディングする必要があります。

DNS の構成

プライベート エンドポイントを作成すると、既定では、privatelink サブドメインに対応するプライベート DNS ゾーンも作成 (または既存のゾーンが更新) されます。 厳密に言うと、ストレージ アカウントにプライベート エンドポイントを使用するためプライベート DNS ゾーンを作成する必要はありません。 ただし、Azure ファイル共有を Active Directory ユーザー プリンシパルでマウントする場合、または FileREST API からアクセスする場合は、一般的に強くお勧めします。

Note

この記事では、Azure パブリック リージョンを対象に、ストレージ アカウントの DNS サフィックス core.windows.net を使用しています。 この解説は、Azure ソブリン クラウド (Azure US Government クラウドや 21Vianet によって運営される Microsoft Azure クラウドなど) にも当てはまります。ご利用の環境の適切なサフィックスに置き換えてください。

プライベート DNS ゾーンに、storageaccount.privatelink.file.core.windows.net の A レコードを作成すると共に、storageaccount.file.core.windows.net というパターンに従って、ストレージ アカウントの通常の名前に対応する CNAME レコードを作成します。 Azure のプライベート DNS ゾーンは、プライベート エンドポイントを含んだ仮想ネットワークに接続されているため、Azure VM の PowerShell から Resolve-DnsName コマンドレット (Windows および Linux では nslookup でも可) を呼び出せば、DNS 構成を観察することができます。

Resolve-DnsName -Name "storageaccount.file.core.windows.net"

この例では、ストレージ アカウント storageaccount.file.core.windows.net が、プライベート エンドポイントのプライベート IP アドレス (192.168.0.4) に解決されます。

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  29    Answer     csostoracct.privatelink.file.core.windows.net
net

Name       : storageaccount.privatelink.file.core.windows.net
QueryType  : A
TTL        : 1769
Section    : Answer
IP4Address : 192.168.0.4


Name                   : privatelink.file.core.windows.net
QueryType              : SOA
TTL                    : 269
Section                : Authority
NameAdministrator      : azureprivatedns-host.microsoft.com
SerialNumber           : 1
TimeToZoneRefresh      : 3600
TimeToZoneFailureRetry : 300
TimeToExpiration       : 2419200
DefaultTTL             : 300

同じコマンドをオンプレミスから実行した場合、同じストレージ アカウント名が、ストレージ アカウントのパブリック IP アドレスに解決されることがわかります。storageaccount.file.core.windows.net は storageaccount.privatelink.file.core.windows.net の CNAME レコードで、さらにそれが、ストレージ アカウントをホストする Azure ストレージ クラスターの CNAME レコードになっています。

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  60    Answer     storageaccount.privatelink.file.core.windows.net
net
storageaccount.privatelink.file.c CNAME  60    Answer     file.par20prdstr01a.store.core.windows.net
ore.windows.net

Name       : file.par20prdstr01a.store.core.windows.net
QueryType  : A
TTL        : 60
Section    : Answer
IP4Address : 52.239.194.40

このことは、ストレージ アカウントが、パブリック エンドポイントと 1 つ以上のプライベート エンドポイントの両方を公開できるという事実を表しています。 ストレージ アカウント名が確実にプライベート エンドポイントのプライベート IP アドレスに解決されるようにするには、オンプレミスの DNS サーバーの構成を変更する必要があります。 これはいくつかの方法で実行できます。

• クライアントの hosts ファイルを変更して、 storageaccount.file.core.windows.net を目的のプライベート エンドポイントのプライベート IP アドレスに解決します。 これは、運用環境では決してお勧めできません。Azure ファイル共有をマウントするすべてのクライアントにこれらの変更を行う必要があり、ストレージ アカウントまたはプライベート エンドポイントへの変更も自動的には処理されないためです。
• オンプレミスの DNS サーバーに storageaccount.file.core.windows.net の A レコードを作成します。 この方法の利点は、オンプレミス環境内のクライアントを個別に構成しなくても、クライアントが自動的にストレージ アカウントを解決できるようになることです。 ただし、このソリューションは、変更が反映されないため、 hosts ファイルの変更に対しても同様に脆弱です。 この解決策は完璧ではありませんが、環境によっては最適な選択肢となりえます。
• core.windows.net ゾーンをオンプレミスの DNS サーバーから Azure のプライベート DNS ゾーンに転送します。 Azure のプライベート DNS ホストには、特殊な IP アドレス (168.63.129.16) でアクセスできますが、このアドレスには、Azure のプライベート DNS ゾーンにリンクされた仮想ネットワーク内からしかアクセスできません。 この制限を回避するには、別の DNS サーバーを仮想ネットワーク内で実行し、 Azure のプライベート DNS ゾーンに core.windows.net を転送します。 この設定を簡略化するために、Azure 仮想ネットワークに DNS サーバーを自動デプロイしてそれらを必要に応じて構成する PowerShell コマンドレットを用意しています。 DNS 転送を設定する方法については、Azure Files を使用した DNS の構成に関するページを参照してください。

SMB over QUIC

Windows Server 2022 Azure Edition では、ファイル サーバー ロールによって提供される SMB サーバーに対して QUIC と呼ばれる新しいトランスポート プロトコルがサポートされています。 QUIC は UDP 上に構築された TCP の代替であり、信頼性の高いトランスポート メカニズムを提供しながら TCP と比べて多くの利点を提供します。 SMB プロトコルの重要な利点の 1 つは、ポート 445 を使用する代わりに、HTTPS をサポートするためにアウトバウンドで広く開かれているポート 443 を使用してすべてのトランスポートが行われることです。 これは事実上、SMB over QUIC がパブリック インターネット経由でファイルを共有するための "SMB VPN" を提供することを意味します。 Windows 11 には、SMB over QUIC 対応クライアントが付属しています。

現時点では、Azure Files は SMB over QUIC を直接サポートしていません。 ただし、次の図のように、Windows Server で実行される Azure File Sync を使用して、Azure ファイル共有にアクセスできます。 これにより、オンプレミスと異なる Azure データセンターの両方の Azure File Sync キャッシュを使用して、分散型ワークフォースのためにローカル キャッシュを提供するオプションも利用できます。 このオプションについて詳しくは、「Azure File Sync のデプロイ」と「SMB over QUIC」を参照してください。

関連項目

• Azure Files の概要
• Azure Files のデプロイの計画