다음을 통해 공유

Azure Files 네트워킹 고려 사항

  • 아티클

Azure 파일 공유에는 공용 인터넷 액세스 가능 엔드포인트를 통해, 네트워크에서 하나 이상의 프라이빗 엔드포인트를 통해 또는 Azure 파일 동기화 사용하여 온-프레미스에서 Azure 파일 공유를 캐싱하여 액세스할 수 있습니다(SMB 파일 공유만 해당). 이 문서에서는 퍼블릭 및/또는 프라이빗 엔드포인트에 대한 직접 액세스를 위해 Azure Files를 구성하는 방법에 중점을 둡니다. Azure 파일 동기화 사용하여 온-프레미스에서 Azure 파일 공유를 캐시하는 방법을 알아보려면 Azure 파일 동기화 소개를 참조하세요.

이 가이드를 읽기 전에 Azure Files 배포 계획을 읽는 것이 좋습니다.

Azure 파일 공유에 직접 액세스하려면 네트워킹과 관련하여 추가적인 고려가 필요한 경우가 많습니다.

  • SMB 파일 공유는 많은 조직 및 ISP(인터넷 서비스 공급자)가 아웃바운드(인터넷) 트래픽을 차단하는 포트 445를 통해 통신합니다. 이 방법은 더 이상 사용되지 않고 인터넷에 안전하지 않은 버전의 SMB 프로토콜에 대한 레거시 보안 지침에서 비롯됩니다. SMB 3.x는 인터넷 안전 프로토콜이지만 조직 또는 ISP 정책을 변경하지 못할 수 있습니다. 따라서 SMB 파일 공유를 탑재하려면 Azure 외부에서 사용하기 위해 추가 네트워킹 구성이 필요한 경우가 많습니다.

  • NFS 파일 공유는 네트워크 수준 인증을 사용하므로 제한된 네트워크를 통해서만 액세스할 수 있습니다. NFS 파일 공유를 사용하려면 항상 일정 수준의 네트워킹 구성이 필요합니다.

Azure Files에 대한 퍼블릭 및 프라이빗 엔드포인트 구성은 Azure Files에 대한 최상위 관리 개체인 Azure Storage 계정에서 수행됩니다. 스토리지 계정은 여러 Azure 파일 공유를 배포할 수 있는 스토리지의 공유 풀과 Blob 컨테이너 또는 큐와 같은 다른 Azure 스토리지 서비스를 위한 스토리지 리소스를 나타내는 관리 구문입니다.

이 비디오는 간단한 다섯 가지 단계를 통해 Azure 파일 공유를 정보 근로자 및 앱에 직접 안전하게 노출하는 방법에 대한 가이드 및 데모입니다. 아래 섹션에서는 비디오에서 참조되는 설명서에 대한 링크와 추가 컨텍스트를 제공합니다. Azure Active Directory는 이제 Microsoft Entra ID입니다. 자세한 내용은 Azure AD의 새 이름을 참조하세요.

적용 대상

파일 공유 유형 SMB NFS
표준 파일 공유(GPv2), LRS/ZRS 예 아니요
표준 파일 공유(GPv2), GRS/GZRS 예 아니요
프리미엄 파일 공유(FileStorage), LRS/ZRS 예 예

보안 전송

기본적으로 Azure 스토리지 계정에는 데이터를 퍼블릭 또는 프라이빗 엔드포인트를 통해 액세스하는지 여부에 관계없이 보안 전송이 필요합니다. Azure Files 경우 보안 전송 필요 설정이 Azure 파일 공유에 저장된 데이터에 대한 모든 프로토콜(SMB, NFS 및 FileREST 포함) 액세스에 적용됩니다. 암호화되지 않은 트래픽을 허용할 경우 보안 전송 필요 설정을 사용하지 않도록 설정할 수 있습니다. 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 Storage 계정 간의 통신은 TLS(전송 계층 보안)를 사용하여 암호화됩니다. Azure Files는 OpenSSL을 기반으로 하지 않는 Windows SSL 구현을 사용하므로 OpenSSL 관련 취약성에 노출되지 않습니다.

공용 엔드포인트

스토리지 계정 내의 Azure 파일 공유에 대한 퍼블릭 엔드포인트는 인터넷에 노출된 엔드포인트입니다. 퍼블릭 엔드포인트는 스토리지 계정의 기본 엔드포인트이지만 원하는 경우 사용하지 않도록 설정할 수 있습니다.

SMB, NFS 및 FileREST 프로토콜은 모두 퍼블릭 엔드포인트를 사용할 수 있습니다. 그러나 각각 액세스에 대한 규칙이 약간 다릅니다.

  • SMB 파일 공유는 암호화가 있는 SMB 3.x를 사용하여 스토리지 계정의 퍼블릭 엔드포인트를 통해 전 세계 어디에서나 액세스할 수 있습니다. 즉, 사용자의 로그온 ID로 권한이 부여된 요청과 같은 인증된 요청이 Azure 지역 내부 또는 외부에서 안전하게 시작될 수 있습니다. 암호화가 없는 SMB 2.1 또는 SMB 3.x가 필요한 경우 다음 두 가지 조건을 충족해야 합니다.

    1. 스토리지 계정의 보안 전송 필요 설정을 사용하지 않도록 설정해야 합니다.
    2. 요청은 Azure 지역 내에서 시작되어야 합니다. 앞에서 설명한 것처럼 암호화된 SMB 요청은 Azure 지역 내부 또는 외부 어디에서나 허용됩니다.

  • NFS 파일 공유는 스토리지 계정의 퍼블릭 엔드포인트가 서비스 엔드포인트를 사용하는 특정 가상 네트워크로 제한된 경우에만 스토리지 계정의 퍼블릭 엔드포인트에서 액세스할 수 있습니다. 서비스 엔드포인트에 대한 자세한 내용은 퍼블릭 엔드포인트 방화벽 설정을 참조하세요.

  • FileREST는 퍼블릭 엔드포인트를 통해 액세스할 수 있습니다. 보안 전송이 필요한 경우 HTTPS 요청만 수락됩니다. 보안 전송을 사용하지 않도록 설정하면 HTTP 요청은 출처에 관계없이 퍼블릭 엔드포인트에서 수락됩니다.

퍼블릭 엔드포인트 방화벽 설정

스토리지 계정 방화벽은 스토리지 계정의 퍼블릭 엔드포인트에 대한 액세스를 제한합니다. 스토리지 계정 방화벽을 사용하면 특정 IP 주소/IP 주소 범위에 대한 액세스를 특정 가상 네트워크로 제한하거나 퍼블릭 엔드포인트를 완전히 사용하지 않도록 설정할 수 있습니다.

퍼블릭 엔드포인트의 트래픽을 하나 이상의 가상 네트워크로 제한하는 경우 서비스 엔드포인트라는 가상 네트워크의 기능을 사용합니다. Azure Files의 서비스 엔드포인트로 전달되는 요청은 여전히 스토리지 계정 공용 IP 주소로 이동하지만 네트워킹 계층은 권한 있는 가상 네트워크에서 오는지 확인하기 위해 요청에 대한 추가 확인을 수행하고 있습니다. SMB, NFS 및 FileREST 프로토콜은 모두 서비스 엔드포인트를 지원합니다. 그러나 SMB 및 FileREST와 달리 NFS 파일 공유는 서비스 엔드포인트를 통해 퍼블릭 엔드포인트에서만 액세스할 수 있습니다.

스토리지 계정 방화벽을 구성하는 방법에 대한 자세한 내용은 Azure Storage 방화벽 및 가상 네트워크 구성을 참조하세요.

퍼블릭 엔드포인트 네트워크 라우팅

Azure Files는 여러 네트워크 라우팅 옵션을 지원합니다. 기본 옵션인 Microsoft 라우팅은 모든 Azure Files 구성에서 작동합니다. 인터넷 라우팅 옵션은 AD 도메인 가입 시나리오 또는 Azure 파일 동기화를 지원하지 않습니다.

프라이빗 엔드포인트

스토리지 계정에 대한 기본 퍼블릭 엔드포인트 외에도 Azure Files는 하나 이상의 프라이빗 엔드포인트를 포함할 수 있는 옵션을 제공합니다. 프라이빗 엔드포인트는 Azure 가상 네트워크 내에서만 액세스할 수 있는 엔드포인트입니다. 스토리지 계정에 대한 프라이빗 엔드포인트를 만들면 스토리지 계정은 가상 네트워크의 주소 공간 내에서 개인 IP 주소를 가져옵니다. 이는 온-프레미스 파일 서버 또는 NAS 디바이스에서 온-프레미스 네트워크의 전용 주소 공간 내에 있는 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 Gateway는 인터넷을 통해 Azure 가상 네트워크와 대체 위치(예: 온-프레미스) 간에 암호화된 트래픽을 보내는 데 사용되는 특정 유형의 가상 네트워크 게이트웨이입니다. Azure VPN Gateway는 스토리지 계정 또는 다른 Azure 리소스와 함께 리소스 그룹에 배포할 수 있는 Azure 리소스입니다. VPN 게이트웨이는 다음 두 가지 유형의 연결을 공개합니다.
  • ExpressRoute - 이를 사용하면 인터넷을 트래버스하지 않는 온-프레미스 네트워크와 Azure 간에 정의된 경로를 만들 수 있습니다. ExpressRoute는 온-프레미스 데이터 센터와 Azure 간의 전용 경로를 제공하므로 네트워크 성능을 고려할 때 ExpressRoute가 유용할 수 있습니다. ExpressRoute는 조직의 정책 또는 규정 요구 사항에서 클라우드의 리소스에 대한 결정적 경로가 필요한 경우에도 유용한 옵션입니다.

참고 항목

온-프레미스 네트워크를 Azure로 확장하는 데 도움이 되도록 프라이빗 엔드포인트를 사용하는 것이 좋지만 VPN 연결을 통해 퍼블릭 엔드포인트로 라우팅하는 것이 기술적으로 가능합니다. 그러나 이렇게 하려면 스토리지 계정을 제공하는 Azure 스토리지 클러스터의 퍼블릭 엔드포인트에 대한 IP 주소를 하드 코딩해야 합니다. 스토리지 계정은 언제든지 스토리지 클러스터 간에 이동될 수 있고 새 클러스터는 자주 추가 및 제거되므로 가능한 모든 Azure 스토리지 IP 주소를 라우팅 규칙에 정기적으로 하드 코딩해야 합니다.

DNS 구성

프라이빗 엔드포인트를 만드는 경우 기본적으로 privatelink 하위 도메인에 해당하는 프라이빗 DNS 영역을 만들거나 기존 영역을 업데이트합니다. 엄밀히 말해, 스토리지 계정에 프라이빗 엔드포인트를 사용하기 위해 프라이빗 DNS 영역을 만들 필요는 없습니다. 하지만 Active Directory 사용자 주체 권한으로 Azure 파일 공유를 탑재하거나 FileREST API에서 액세스하는 경우에는 일반적으로 적극 권장되며 명시적으로 필요합니다.

참고 항목

이 문서에서는 core.windows.net Azure 퍼블릭 지역에 대한 스토리지 계정 DNS 접미사를 사용합니다. 이는 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 cmdlet(또는 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 Storage 클러스터에 대한 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

이는 스토리지 계정에서 퍼블릭 엔드포인트와 하나 이상의 프라이빗 엔드포인트를 모두 공개할 수 있다는 사실을 반영합니다. 스토리지 계정 이름이 프라이빗 엔드포인트의 개인 IP 주소로 확인되도록 하려면 온-프레미스 DNS 서버의 구성을 변경해야 합니다. 이 작업은 다음과 같이 여러 가지 방법으로 수행할 수 있습니다.

  • storageaccount.file.core.windows.net이 원하는 프라이빗 엔드포인트의 개인 IP 주소로 확인되도록 클라이언트에서 hosts 파일을 수정합니다. 이는 프로덕션 환경에 추천되지 않습니다. Azure 파일 공유를 탑재하려는 모든 클라이언트에 대해 이러한 변경을 수행해야 하며, 스토리지 계정 또는 프라이빗 엔드포인트에 대한 변경이 자동으로 처리되지 않기 때문입니다.
  • 온-프레미스 DNS 서버에서 storageaccount.file.core.windows.net에 대한 A 레코드를 만듭니다. 이는 온-프레미스 환경의 클라이언트에서 각 클라이언트를 구성하지 않고도 스토리지 계정을 자동으로 확인할 수 있다는 이점이 있습니다. 그러나 이 솔루션은 변경 내용이 반영되지 않으므로 hosts 파일을 수정하는 것과 유사하게 취약합니다. 이 솔루션은 취약하지만 일부 환경에서는 최선의 선택일 수 있습니다.
  • core.windows.net 영역을 온-프레미스 DNS 서버에서 Azure 프라이빗 DNS 영역으로 전달합니다. Azure 프라이빗 DNS 호스트는 Azure 프라이빗 DNS 영역에 연결된 가상 네트워크 내에서만 액세스할 수 있는 특수 IP 주소(168.63.129.16)를 통해 연결할 수 있습니다. 이 제한을 해결하려면 core.windows.net을 Azure 프라이빗 DNS 영역으로 전달하는 추가 DNS 서버를 가상 네트워크 내에서 실행할 수 있습니다. 이 설정을 간소화하기 위해 DNS 서버를 Azure Virtual Network에 자동으로 배포하고 원하는 대로 구성할 수 있는 PowerShell cmdlet을 제공했습니다. DNS 전달을 설정하는 방법에 대한 자세한 내용은 Azure Files를 사용하여 DNS 구성을 참조하세요.

SMB over QUIC

Windows Server 2022 Azure Edition은 파일 서버 역할에서 제공하는 SMB 서버에 대해 QUIC라는 새 전송 프로토콜을 지원합니다. QUIC는 UDP를 기반으로 구축된 TCP를 대체하며 TCP보다 많은 이점을 제공하는 동시에 안정적인 전송 메커니즘을 제공합니다. 포트 445를 사용하는 대신 SMB 프로토콜을 사용할 경우의 한 가지 주요 이점은 HTTPS를 지원하기 위해 널리 열려 있는 아웃바운드 포트 443을 통해 모든 전송이 수행된다는 것입니다. 이는 SMB over QUIC가 공용 인터넷을 통해 파일 공유를 위한 "SMB VPN"을 제공한다는 의미입니다. Windows 11은 SMB over QUIC 지원 클라이언트와 함께 제공합니다.

현재 Azure Files는 SMB over QUIC를 직접 지원하지 않습니다. 그러나 아래 다이어그램과 같이 Windows Server에서 실행되는 Azure 파일 동기화를 통해 Azure 파일 공유에 액세스할 수 있습니다. 또한 온-프레미스 또는 다른 Azure 데이터 센터에 Azure 파일 동기화 캐시를 제공하여 분산된 인력에 대한 로컬 캐시를 제공할 수도 있습니다. 이 옵션에 대한 자세한 내용은 Azure 파일 동기화 배포 및 SMB over QUIC를 참조하세요.

Azure File Sync를 사용하여 Windows Server 2022 Azure Edition V M에 Azure 파일 공유의 경량 캐시를 만들기 위한 다이어그램.

참고 항목