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

✔️ Applies to: すべての Azure ファイル共有

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

このガイドを読む前に、まず「Planning for an Azure Files deployment」をお読みください。

多くの場合、Azure ファイル共有に直接アクセスするには、ネットワークに関して追加の考慮事項が必要です。

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

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

Azure Filesのパブリックおよびプライベートエンドポイントは、Azure Filesのトップレベルの管理オブジェクトであるAzureストレージアカウントで設定します。 ストレージ アカウントは、複数のAzure ファイル共有と、BLOB コンテナーやキューなどの他のAzure ストレージ サービスのストレージ リソースをデプロイできるストレージの共有プールを表す管理コンストラクトです。

安全な転送

既定では、Azureストレージ アカウントでは、パブリック エンドポイントとプライベート エンドポイントのどちらを介してデータにアクセスするかに関係なく、セキュリティで保護された転送が必要です。 Azure Filesの場合、転送中の暗号化はプロトコル レベルで制御されます。

SMB 向けの転送中の暗号化

SMBの「Required Encryption in Transit」設定は、SMBアクセスに暗号化が必要かどうかを制御します。 Azure ポータルを使用して作成された新しいストレージ アカウントの場合、この設定は既定で有効になっています。 Azure PowerShell、Azure CLI、または FileREST API を使用して作成されたストレージ アカウントは、下位互換性を確保するために、この値を [選択されていません に設定します。 既存のストレージ アカウントの場合、プロトコルごとの SMB 設定を明示的に構成するまで、 セキュリティで保護された転送が必要な 設定は引き続き SMB 暗号化動作を管理します。 転送中の SMB 暗号化が必要な場合、そのストレージ アカウント内のすべての SMB ファイル共有には、AES-128-CCM、AES-128-GCM、または AES-256-GCM 暗号化アルゴリズムを使用した SMB 3.x プロトコルが必要です。 SMB セキュリティ設定を使用して、許可されるアルゴリズムを切り替えることができます。 この設定を無効にすると、暗号化なしで SMB 2.1 と SMB 3.x のマウントが有効になります。

NFS の転送中の暗号化

「 Require Encryption in Transit for NFS」 設定は、NFSアクセスに暗号化が必要かどうかを制御します。 NFS Azure ファイル共有では、AZNFS ユーティリティ パッケージを使用して、Stunnel (オープンソース TLS ラッパー) をクライアントにインストールして設定することで、暗号化されたマウントを簡略化します。 NFS Azure ファイル共有の転送中の暗号化を参照してください。 Azure ポータルを使用して作成された新しいストレージ アカウントの場合、この設定は既定で有効になっています。 Azure PowerShell、Azure CLI、または FileREST API を使用して作成されたストレージ アカウントは、下位互換性を確保するために、この値を [選択されていません に設定します。 既存のストレージ アカウントの場合、プロトコルごとの NFS 設定を明示的に構成するまで、 セキュリティで保護された転送が必要な 設定は引き続き NFS 暗号化動作を管理します。

FileREST の転送中の暗号化

REST/HTTPSトラフィックには Secure transfer required 設定が適用されます。 有効にすると、FileREST プロトコルは HTTPS でのみ使用できます。

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

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

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

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

  1. [転送中の暗号化を SMB に要求する] 設定を無効にする必要があります (または、この設定が明示的に構成されていない既存のアカウントの場合は、セキュリティで保護された転送が必要な設定を無効にする必要があります)。
  2. 要求は、Azure リージョン内から送信される必要があります。 前述のように、暗号化された SMB 要求は、Azure リージョンの内外のどこからでも許可されます。

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

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

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

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

パブリックエンドポイントを1つ以上のネットワークに制限すると、仮想ネットワークのサービスエンドポイントという機能を利用していることになります。 Azure Filesのサービスエンドポイントに向けられたリクエストは、依然としてストレージアカウントのパブリックIPアドレスに届きます。 しかし、ネットワーク層はリクエストが認可された仮想ネットワークから来ていることを検証するために追加の検証を行います。 SMB、NFS、および FileREST プロトコルはすべて、サービス エンドポイントをサポートします。 しかし、SMBやFileRESTとは異なり、NFSのファイル共有は サービスエンドポイントを介してパブリックエンドポイントを利用することでのみアクセス可能です。

Azure portal のアクセスとストレージ アカウントのファイアウォール

Azure portal を使用して Azure ファイル共有にアクセスすると、次の 2 つの異なる要求が発生します。

1. ブラウザーから Azure portal UI (https://portal.azure.com) への要求。
2. ブラウザーから Azure Files データ プレーン エンドポイント ( https://<storage-account-name>.file.core.windows.net など) への直接の要求。通常は、ポータル エクスペリエンス用に発行された SAS トークンを使用します。

ストレージ アカウント ファイアウォールは、 portal.azure.com要求ではなく、Azure Files データ プレーン エンドポイントへの直接要求のみを評価します。 そのため、問題なく Azure portal にアクセスできる場合でも、ブラウザーからストレージへの要求のパブリックエグレス IP アドレスがファイアウォールで許可されていない場合、ファイル共有データの参照時に 403 (禁止) エラーが発生する可能性があります。 この制限はFileREST/HTTPSトラフィックにのみ適用され、SMBやNFSには適用されません。 詳細については、Azureポータルのファイルデータへのアクセスを許可する項目をご覧ください。

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

Azure Filesは2つのネットワークルーティングオプションをサポートしています:

• Microsoftルーティング(デフォルト):クライアントとストレージアカウント間のトラフィックは、インターネットに移行する前にできるだけ長くMicrosoftのグローバルネットワークバックボーンを経由します。 このオプションは、Active Directory(AD)ドメイン結合シナリオやAzure File Syncを含むすべてのAzure Files設定で機能します。
• インターネットルーティング:トラフィックはできるだけ早くパブリックインターネット経由でルーティングされます。 このオプションはActive Directory(AD)ドメイン参加シナリオやAzure File Syncをサポートしていません。

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

Azure Filesでは、ストレージ アカウントの既定のパブリック エンドポイントに加えて、1 つ以上のプライベート エンドポイントを持つオプションを提供します。 プライベート エンドポイントは、Azure仮想ネットワーク内でのみアクセスできるエンドポイントです。 ストレージ アカウントのプライベート エンドポイントを作成すると、オンプレミスのファイル サーバーや NAS デバイスがオンプレミス ネットワークの専用アドレス空間内で IP アドレスを受信する方法と同様に、ストレージ アカウントは仮想ネットワークのアドレス空間内からプライベート IP アドレスを取得します。

個々のプライベート エンドポイントは、特定のAzure仮想ネットワーク サブネットに関連付けられます。 ストレージ アカウントには、複数の仮想ネットワークにプライベート エンドポイントが含まれる場合があります。

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

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

プライベート エンドポイントを作成するには、 Azure Filesを参照してください。

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

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

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

ポイント対サイト VPN

Azure VPN Gatewayはポイント・トゥ・サイトVPN接続をサポートしており、これはAzureと個別クライアント間のVPN接続です。 このソリューションは主に、組織のオンプレミス ネットワークに含まれていないデバイスに役立ちます。 一般的なユース ケースは、自宅、コーヒーショップ、またはホテルからAzureファイル共有をマウントできるようにしたい在宅勤務者向けです。 Azure FilesでポイントツーサイトVPN接続を使用するには、接続したいクライアントごとにポイントツーサイトVPN接続を設定する必要があります。 Azure Files で使用する Windows 上のポイント対サイト VPN を構成するおよびAzure Files で使用する Linux 上のポイント対サイト VPN を構成するを参照してください。

サイト間 VPN

Azure VPN Gatewayは、サイト間VPN接続もサポートしており、これはAzureと組織のネットワーク間のVPN接続です。 サイト間VPN接続は、組織のネットワーク上でホストされているVPNサーバーやデバイスに対して一度だけVPN接続を設定できる仕組みで、Azureファイル共有にアクセスするすべてのクライアントデバイスごとに接続を設定する必要はありません。 Azure Filesで使うためのConfigure a Site-to-Site VPNを参照してください。

ExpressRoute

ExpressRouteは、インターネットを経由しないAzureとオンプレミスネットワーク間で定義されたルートを作成できます。 ExpressRoute にはオンプレミスのデータセンターとAzureの間に専用のパスが用意されているため、ネットワーク パフォーマンスが考慮される場合は ExpressRoute が役立ちます。 ExpressRoute はまた、組織のポリシーまたは規制要件にクラウド内のリソースへの確定的なパスが必要な場合の適切なオプションでもあります。

DNS の構成

プライベートエンドポイントを作成すると、Azureはprivatelinkサブドメインに対応するプライベートDNSゾーンも作成または更新します。 厳密に言えば、プライベート DNS ゾーンの作成は、ストレージ アカウントにプライベート エンドポイントを使用する必要はありません。 ただし、これは強く推奨されており、Azureのファイル共有をActive Directoryのユーザープリンシパルでマウントしたり、FileREST APIからアクセスしたりする際には明確に必須です。

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

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     storageaccount.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 サーバーの構成を変更する必要があります。 これはさまざまな方法で実行できます。

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

SMB over QUIC (ネットワークプロトコル)

Windows Server 2022 Azure Editionは、ファイルサーバーの役割が提供するSMBサーバー向けにQUICというトランスポートプロトコルをサポートしています。 QUICはUDPの上に構築されたTCPの代替であり、TCPに比べて多くの利点を持ちながら、信頼性の高いトランスポート機構を提供します。 SMB プロトコルの主な利点の 1 つは、ポート 445 を使用する代わりに、すべてのトランスポートがポート 443 経由で実行され、HTTPS をサポートするために送信が広く開かれているということです。 この構成は、SMB over QUICがパブリックインターネット上でファイル共有のための「SMB VPN」を提供することを意味します。 Windows 11には、SMB over QUIC 対応クライアントが付属しています。

現在、Azure FilesはSMBをQUIC経由でサポートしていません。 しかし、以下の図のようにWindows Server上で動作するAzure File Syncを通じて、Azureファイル共有にはアクセスできます。 この構成では、Azure File Syncをオンプレミスまたは異なるAzureデータセンターにキャッシュ配置し、分散型の職場向けにローカルキャッシュを提供するオプションも提供します。 このオプションについて詳しく知りたい方は、Windows Serverのドキュメントをご覧ください。 Azure File Sync特有のネットワークの詳細については、SMB over QUICを参照してください。

こちらも参照ください

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