Azure ファイル共有には、パブリック インターネットアクセス可能なエンドポイント、ネットワーク上の 1 つ以上のプライベート エンドポイント経由、または Azure File Sync (SMB ファイル共有のみ) を使用してオンプレミスで Azure ファイル共有をキャッシュすることでアクセスできます。 この記事では、パブリック エンドポイントまたはプライベート エンドポイント経由で直接アクセスできるように 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 Storage アカウントである Azure Files の最上位の管理オブジェクトで行われます。 ストレージ アカウントは、複数の Azure ファイル共有と、BLOB コンテナーやキューなどの他の Azure ストレージ サービスのストレージ リソースをデプロイできるストレージの共有プールを表す管理コンストラクトです。
このビデオは、簡単な 5 つのステップでインフォメーション ワーカーやアプリに直接 Azure ファイル共有を安全に公開する方法についてのガイドとデモです。 以下のセクションでは、ビデオで参照されているドキュメントへのリンクと追加のコンテキストを示します。 Azure Active Directory は Microsoft Entra ID になりましたので注意してください。 詳細については、「Azure AD の新しい名前」を参照してください。
対象
| ファイル共有の種類 | SMB | NFS |
|---|---|---|
| スタンダードファイル共有 (GPv2)、LRS/ZRS |  |
 |
| 標準ファイル共有 (GPv2)、GRS/GZRS | |
|
| Premium ファイル共有 (FileStorage)、LRS/ZRS | |
|
安全な転送
既定では、Azure ストレージ アカウントでは、パブリック エンドポイントとプライベート エンドポイントのどちらを介してデータにアクセスするかに関係なく、セキュリティで保護された転送が必要です。 Azure Files の場合、SMB、NFS、FileREST など、Azure ファイル共有に格納されているデータへのすべてのプロトコル アクセスに対して、 安全な転送が必要な 設定が適用されます。 暗号化されていないトラフィックを許可するために、 安全な転送に必要な 設定を無効にすることができます。
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 Azure ファイル共有では、AZNFS ユーティリティ パッケージを使用して、Stunnel (オープンソース TLS ラッパー) をクライアントにインストールして設定することで、暗号化されたマウントを簡略化します。 NFS Azure ファイル共有の転送中の暗号化に関するページを参照してください。
安全な転送が必要な場合、FileREST プロトコルは HTTPS でのみ使用できます。
注
クライアントと Azure ストレージ アカウント間の通信は、トランスポート層セキュリティ (TLS) を使用して暗号化されます。 Azure Files は、OpenSSL に基づいていない SSL の Windows 実装に依存しているため、OpenSSL 関連の脆弱性にさらされません。 同じストレージ アカウント上の TLS 接続と TLS 以外の接続の間で柔軟性を維持したいユーザーは、 セキュリティで保護された転送を無効にする必要があります。
パブリック エンドポイント
ストレージ アカウント内の Azure ファイル共有のパブリック エンドポイントは、インターネットで公開されているエンドポイントです。 パブリック エンドポイントはストレージ アカウントの既定のエンドポイントですが、必要に応じて無効にすることができます。
SMB、NFS、FileREST のプロトコルはすべてパブリック エンドポイントを使用できます。 ただし、それぞれアクセスに関する規則が若干異なります。
SMB ファイル共有は、暗号化を使用して SMB 3.x を使用して、ストレージ アカウントのパブリック エンドポイントを介して世界中のどこからでもアクセスできます。 つまり、認証された要求 (ユーザーのログオン ID によって承認された要求など) は、Azure リージョンの内部または外部から安全に送信できます。 暗号化なしの SMB 2.1 または SMB 3.x が必要な場合は、次の 2 つの条件を満たす必要があります。
- ストレージ アカウントの 安全な転送に必要な 設定を無効にする必要があります。
- 要求は、Azure リージョン内から送信される必要があります。 前述のように、暗号化された SMB 要求は、Azure リージョンの内外のどこからでも許可されます。
NFS ファイル共有は、ストレージ アカウントのパブリック エンドポイントがサービス エンドポイントを使用する特定の仮想ネットワークに制限されている場合にのみ、ストレージ アカウントのパブリック エンドポイントからアクセス できます。 サービス エンドポイントの詳細については、パブリック エンドポイントのファイアウォール設定を参照してください。
FileREST には、パブリック エンドポイント経由でアクセスできます。 安全な転送が必要な場合は、HTTPS 要求のみが受け入れられます。 セキュリティで保護された転送が無効になっている場合、HTTP 要求は、配信元に関係なくパブリック エンドポイントによって受け入れられます。
パブリック エンドポイントのファイアウォール設定
ストレージ アカウント ファイアウォールは、ストレージ アカウントのパブリック エンドポイントへのアクセスを制限します。 ストレージ アカウント ファイアウォールを使用すると、特定の IP アドレス/IP アドレス範囲へのアクセスを特定の仮想ネットワークに制限したり、パブリック エンドポイントを完全に無効にしたりすることができます。
パブリック エンドポイントのトラフィックを 1 つ以上の仮想ネットワークに制限する場合は、 サービス エンドポイントと呼ばれる仮想ネットワークの機能を使用します。 Azure Files のサービス エンドポイントに送信された要求は、引き続きストレージ アカウントのパブリック IP アドレスに送信されます。ただし、ネットワーク層は、承認された仮想ネットワークから送信されていることを検証するために、要求の追加検証を行っています。 SMB、NFS、および FileREST プロトコルはすべて、サービス エンドポイントをサポートします。 ただし、SMB や FileREST とは異なり、NFS ファイル共有には 、サービス エンドポイントを使用してパブリック エンドポイントでのみアクセスできます。
ストレージ アカウント ファイアウォールを構成する方法の詳細については、 Azure ストレージ ファイアウォールと仮想ネットワークの構成に関するページを参照してください。
パブリック エンドポイント ネットワーク ルーティング
Azure Files では、複数のネットワーク ルーティング オプションがサポートされています。 既定のオプションである Microsoft ルーティングは、Azure Files のすべての構成で動作します。 インターネット ルーティング オプションは、AD ドメイン参加シナリオまたは Azure File Sync をサポートしていません。
プライベート エンドポイント
Azure Files には、ストレージ アカウントの既定のパブリック エンドポイントに加えて、1 つ以上のプライベート エンドポイントを持つオプションが用意されています。 プライベート エンドポイントは、Azure 仮想ネットワーク内でのみアクセスできるエンドポイントです。 ストレージ アカウントのプライベート エンドポイントを作成すると、オンプレミスのファイル サーバーや NAS デバイスがオンプレミス ネットワークの専用アドレス空間内で IP アドレスを受信する方法と同様に、ストレージ アカウントは仮想ネットワークのアドレス空間内からプライベート IP アドレスを取得します。
個々のプライベート エンドポイントは、Azure 仮想ネットワークの特定のサブネットに関連付けられます。 ストレージ アカウントには、複数の仮想ネットワークにプライベート エンドポイントが含まれる場合があります。
Azure Files でプライベート エンドポイントを使用すると、次のことが可能になります。
- オンプレミス ネットワークから、VPN または ExpressRoute 接続によるプライベートピアリングを使用して Azure ファイル共有に安全に接続します。
- パブリック エンドポイントでのすべての接続をブロックするようにストレージ アカウントのファイアウォールを構成することで、Azure ファイル共有をセキュリティで保護します。 既定では、プライベート エンドポイントを作成しても、パブリック エンドポイントへの接続はブロックされません。
- 仮想ネットワーク (およびピアリングの境界) からのデータの流出をブロックできるようにすることで、仮想ネットワークのセキュリティを強化します。
プライベート エンドポイントを作成するには、「 Azure Files のプライベート エンドポイントの構成」を参照してください。
仮想プライベート ネットワークまたは ExpressRoute でトラフィックをトンネリングする
プライベート エンドポイントを使用してオンプレミスから SMB または NFS ファイル共有にアクセスするには、オンプレミス ネットワークと Azure の間にネットワーク トンネルを確立する必要があります。 仮想ネットワーク (VNet) は、従来のオンプレミス ネットワークに似ています。 Azure ストレージ アカウントや Azure VM と同様に、VNet はリソース グループにデプロイされる Azure リソースです。
Azure Files では、オンプレミスのワークステーションとサーバーと Azure SMB/NFS ファイル共有の間でトラフィックをトンネリングするための次のメカニズムがサポートされています。
- Azure VPN Gateway: VPN ゲートウェイは、暗号化されたトラフィックをインターネット経由で Azure 仮想ネットワークと別の場所 (オンプレミスなど) の間で送信するために使用される特定の種類の仮想ネットワーク ゲートウェイです。 Azure VPN Gateway は、ストレージ アカウントまたはその他の Azure リソースと共にリソース グループにデプロイできる Azure リソースです。 VPN ゲートウェイは、次の 2 種類の接続を公開します。
- ポイント対サイト (P2S) VPN ゲートウェイ接続。これは、Azure と個々のクライアント間の VPN 接続です。 このソリューションは主に、組織のオンプレミス ネットワークに含まれていないデバイスに役立ちます。 一般的なユース ケースは、自宅、コーヒーショップ、またはホテルから Azure ファイル共有をマウントしたい在宅勤務者向けです。 Azure Files で P2S VPN 接続を使用するには、接続するクライアントごとに P2S VPN 接続を構成する必要があります。 Azure Files で使用する Windows でのポイント対サイト (P2S) VPN の構成と、Azure Files で使用するポイント対サイト (P2S) VPN on Linux の構成に関するページを参照してください。
- サイト間 (S2S) VPN。Azure と組織のネットワーク間の VPN 接続です。 S2S VPN 接続を使用すると、Azure ファイル共有にアクセスする必要があるクライアント デバイスごとに接続を構成するのではなく、組織のネットワークでホストされている VPN サーバーまたはデバイスに対して VPN 接続を 1 回構成できます。 Azure Files で使用するサイト間 (S2S) VPN の構成に関するページを参照してください。
- ExpressRoute を使用すると、インターネットを経由しない Azure とオンプレミス ネットワークの間に定義されたルートを作成できます。 ExpressRoute にはオンプレミスのデータセンターと Azure の間に専用のパスが用意されているため、ネットワーク パフォーマンスが考慮される場合は ExpressRoute が役立ちます。 ExpressRoute はまた、組織のポリシーまたは規制要件にクラウド内のリソースへの確定的なパスが必要な場合の適切なオプションでもあります。
注
プライベート エンドポイントを使用してオンプレミス ネットワークを Azure に拡張することをお勧めしますが、VPN 接続経由でパブリック エンドポイントにルーティングすることは技術的には可能です。 ただし、これには、ストレージ アカウントを提供する Azure ストレージ クラスターのパブリック エンドポイントの IP アドレスをハードコーディングする必要があります。 ストレージ アカウントはいつでもストレージ クラスター間で移動される可能性があり、新しいクラスターは頻繁に追加および削除されるため、可能なすべての Azure ストレージ IP アドレスをルーティング規則に定期的にハードコーディングする必要があります。
DNS の構成
プライベート エンドポイントを作成する場合、既定では、 privatelink サブドメインに対応するプライベート DNS ゾーンも作成 (または既存のプライベート DNS ゾーンを更新) します。 厳密に言えば、プライベート DNS ゾーンの作成は、ストレージ アカウントにプライベート エンドポイントを使用する必要はありません。 ただし、一般的には強くお勧めします。Active Directory ユーザー プリンシパルを使用して Azure ファイル共有をマウントする場合、または FileREST API からアクセスする場合は、明示的に必要です。
注
この記事では、Azure パブリック リージョンを対象に、ストレージ アカウントの DNS サフィックス core.windows.net を使用しています。 この解説は、Azure US Government クラウドや 21Vianet クラウドが運用する Microsoft Azure などの Azure ソブリン クラウドにも適用されます。環境に適したサフィックスに置き換えてください。
プライベート DNS ゾーンでは、 storageaccount.privatelink.file.core.windows.net の A レコードと、 storageaccount.file.core.windows.netパターンに従うストレージ アカウントの通常の名前の CNAME レコードが作成されます。 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 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 サーバーの構成を変更する必要があります。 これはいくつかの方法で実行できます。
- 必要なプライベート エンドポイントのプライベート IP アドレスに
storageaccount.file.core.windows.net解決するように、クライアント上の hosts ファイルを変更します。 これは、Azure ファイル共有をマウントするすべてのクライアントにこれらの変更を加える必要があり、ストレージ アカウントまたはプライベート エンドポイントへの変更は自動的に処理されないため、運用環境では強くお勧めしません。 - オンプレミスの DNS サーバーで
storageaccount.file.core.windows.netの A レコードを作成する。 これは、オンプレミス環境のクライアントが、各クライアントを構成しなくてもストレージ アカウントを自動的に解決できるという利点があります。 ただし、このソリューションは、変更が反映されないため、 hosts ファイルの変更と同様に脆弱です。 この解決策は完璧ではありませんが、環境によっては最適な選択肢となりえます。 - オンプレミスの DNS サーバーから Azure プライベート DNS ゾーンに
core.windows.netゾーンを転送します。 Azure のプライベート DNS ホストには、特殊な IP アドレス (168.63.129.16) でアクセスできますが、このアドレスには、Azure のプライベート DNS ゾーンにリンクされた仮想ネットワーク内からしかアクセスできません。 この制限を回避するには、仮想ネットワーク内で追加の DNS サーバーを実行し、core.windows.netを Azure プライベート DNS ゾーンに転送します。 この設定を簡略化するために、Azure 仮想ネットワークに DNS サーバーを自動デプロイし、必要に応じて構成する PowerShell コマンドレットを提供しました。 DNS 転送を設定する方法については、Azure Files を使用した DNS の構成に関するページを参照してください。
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 では QUIC 経由の SMB は直接サポートされていません。 ただし、次の図のように、Windows Server で実行されている Azure File Sync を使用して Azure ファイル共有にアクセスできます。 これにより、Azure File Sync をオンプレミスまたは異なる Azure データセンターの両方にキャッシュして、分散従業員のローカル キャッシュを提供することもできます。 このオプションの詳細については、「QUIC 経由で Azure File Sync と SMB をデプロイする」を参照してください。
