Tip
Microsoft Fabric Data Warehouse는 데이터 레이크 기반의 엔터프라이즈 규모 관계형 웨어하우스로, 미래 대비 아키텍처, 기본 제공 AI 및 새로운 기능을 제공합니다. 데이터 웨어하우징이 처음이라면, Fabric Data Warehouse부터 시작하세요. 기존 전용 SQL 풀 워크로드는 업그레이드하면 Fabric을 통해 데이터 과학, 실시간 분석 및 보고 전반에 걸쳐 새로운 기능에 액세스할 수 있습니다.
적용 대상: Azure Synapse Analytics 전용 SQL 풀
가상 네트워크 규칙은 Azure Synapse Analytics의 전용 SQL 풀(이전 명칭: SQL DW) 데이터베이스에 대한 논리 서버가 가상 네트워크 내 특정 서브넷에서 전송되는 통신을 수신하는지 여부를 제어하는 방화벽 보안 기능입니다. 이 글에서는 가상 네트워크 규칙이 전용 SQL 풀과의 통신을 안전하게 허용하는 데 때때로 가장 좋은 선택인 이유를 설명합니다.
가상 네트워크 규칙을 생성하려면 먼저 규칙이 참조할 가상 네트워크 서비스 엔드포인트 가 있어야 합니다.
가상 네트워크 규칙 만들기
가상 네트워크 규칙만 만들고 싶다면, 이 글의 후반부에서 단계와 설명으로 건너뛰어도 됩니다.
가상 네트워크 규칙에 관한 세부 사항
이 섹션에서는 가상 네트워크 규칙에 관한 여러 세부 사항을 설명합니다.
단 하나의 지리적 지역만
각 가상 네트워크 서비스 엔드포인트는 단 하나의 Azure 리전에만 적용됩니다. 엔드포인트를 사용하여 다른 지역이 서브넷에서 보낸 통신을 수락하도록 할 수는 없습니다.
가상 네트워크 규칙은 그 기반 엔드포인트가 적용되는 영역에 한정됩니다.
서버 수준이지 데이터베이스 수준이 아닙니다
각 가상 네트워크 규칙은 서버 내 특정 데이터베이스에만 적용되는 것이 아니라 전체 서버에 적용됩니다. 즉, 가상 네트워크 규칙은 데이터베이스 수준이 아니라 서버 수준에서 적용됩니다.
보안 관리 역할
가상 네트워크 서비스 엔드포인트 관리에는 보안 역할이 분리되어 있습니다. 다음 각 역할별로 조치가 필요합니다.
- 네트워크 관리자(네트워크 기여자 역할): 엔드포인트를 켜세요.
- 데이터베이스 관리자(SQL Server 기여자 역할): ACL(액세스 제어 목록)을 업데이트하여 제공된 서브넷을 서버에 추가합니다.
Azure RBAC 대안
네트워크 관리자와 데이터베이스 관리자 역할은 가상 네트워크 규칙을 관리하는 데 필요한 것보다 더 많은 기능을 가지고 있습니다. 그 기능 중 일부만 필요합니다.
Azure에서 역할 기반 접근 제어(RBAC)를 사용해 필요한 기능의 하위 집합만 가진 단일 커스텀 역할을 생성할 수 있습니다. 사용자 지정 역할은 네트워크 관리자 또는 데이터베이스 관리자 역할을 부여하는 대신 사용할 수 있습니다. 사용자 하나를 사용자 지정 역할에 추가하면 다른 두 주요 관리자 역할에 사용자를 추가하는 것보다 보안 노출 범위가 더 작아집니다.
Note
경우에 따라 전용 SQL 풀과 가상 네트워크 서브넷이 서로 다른 구독에 속해 있습니다. 이 경우, 다음 구성을 반드시 확인해야 합니다.
- 사용자는 서비스 엔드포인트를 활성화하거나 서버에 가상 네트워크 서브넷을 추가하는 등 작업을 시작할 수 있는 필요한 권한을 가집니다.
- 두 구독 모두
Microsoft.Sql공급자가 등록되어 있어야 합니다.
Limitations
독립형 전용 SQL 풀의 경우, 가상 네트워크 규칙 기능은 다음과 같은 제한을 가집니다:
- 논리 서버의 방화벽에서는 각 가상 네트워크 규칙이 서브넷을 참조합니다. 참조된 모든 서브넷은 전용 SQL 풀과 동일한 지리적 영역에 호스팅되어야 합니다.
- 각 서버는 가상 네트워크에 대해 최대 128개의 ACL 항목을 가질 수 있습니다.
- 가상 네트워크 규칙은 Azure Resource Manager 가상 네트워크에만 적용되며, 클래식 배포 모델 네트워크에는 적용되지 않습니다.
- 방화벽에서는 IP 주소 범위가 다음 네트워킹 항목에 적용되지만, 가상 네트워크 규칙은 적용되지 않습니다:
- 사이트 간 사이트(S2S) 가상 사설망(VPN)
- Azure ExpressRoute를 통한 온-프레미스
- 두 구독 모두 같은 Microsoft Entra 테넌트에 있어야 합니다.
서비스 엔드포인트를 사용할 때 고려해야 할 사항
전용 SQL 풀에 서비스 엔드포인트를 사용할 때는 다음 사항을 검토해 보세요:
- Azure Synapse Analytics 공인 IP들에 대한 아웃바운드 접근이 필요합니다. 네트워크 보안 그룹(NSG)은 서비스 IP와의 연결을 허용해야 합니다.
NSG
Sql를 사용할 수 있습니다.
ExpressRoute
공용 피어링 또는 Microsoft 피어링을 위해 온-프레미스에서 ExpressRoute를 사용하는 경우 사용되는 NAT IP 주소를 식별해야 합니다. 공용 피어링의 경우, 각 ExpressRoute 회선은 기본적으로 Microsoft Azure 네트워크 백본에 들어올 때 Azure 서비스 트래픽에 적용되는 두 개의 NAT IP 주소를 사용합니다. Microsoft 피어링의 경우 사용되는 NAT IP 주소는 고객이 제공하거나 서비스 공급자가 제공합니다. 서비스 리소스에 대한 액세스를 허용하려면 리소스 IP 방화벽 설정에서 이러한 공용 IP 주소를 허용해야 합니다. 공용 피어링 ExpressRoute 회선 IP 주소를 찾으려면, Azure 포털을 통해 ExpressRoute에 지원 티켓을 열어보세요. ExpressRoute 퍼블릭 및 Microsoft 피어링의 NAT에 대해 더 알고 싶으시다면, Azure 퍼블릭 피어링의 NAT 요구사항을 참조하세요.
회선에서 Azure Synapse Analytics로 통신하려면 NAT의 공인 IP 주소에 대해 IP 네트워크 규칙을 만들어야 합니다.
Azure Storage와 가상 네트워크 서비스 엔드포인트 사용 영향
Azure Storage는 사용자가 Azure Storage 계정에 대한 연결성을 제한하도록 허용하는 동일한 기능을 구현했습니다. 이 기능을 Azure Synapse Analytics가 사용하는 Azure Storage 계정과 함께 사용하면 문제가 발생할 수 있습니다.
다음 섹션에서는 영향을 받는 Azure Synapse Analytics 기능에 대해 다룹니다.
Azure Synapse Analytics PolyBase and COPY statement
PolyBase와 COPY 문은 대용량 데이터 수집을 위해 Azure Storage 계정에서 Azure Synapse Analytics로 데이터를 로드하는 데 일반적으로 사용됩니다. 데이터를 로드하는 Azure Storage 계정이 가상 네트워크 서브넷 집합으로만 액세스를 제한한다면, PolyBase와 COPY 문을 사용해 해당 스토리지 계정에 액세스할 때 연결이 끊어집니다. 가상 네트워크로 보안이 유지되는 Azure Storage에 연결하는 Azure Synapse Analytics를 통해 COPY 및 PolyBase를 사용하여 가져오기 및 내보내기 시나리오를 사용하도록 설정하는 경우 이 섹션의 단계를 따르세요.
Prerequisites
- Azure PowerShell을 설치합니다. 자세한 내용은 Azure Az PowerShell 모듈 설치를 참조하세요.
- 범용 v1 또는 Azure Blob Storage 계정이 있다면, 먼저 범용 v2 스토리지 계정으로 업그레이드의 단계를 따라 범용 v2로 업그레이드해야 합니다.
- Azure Storage 계정 방화벽 및 가상 네트워크 설정 메뉴에서 신뢰할 수 있는 Microsoft 서비스가 이 스토리지 계정에 액세스하도록 허용합니다.를 설정해야 합니다. 이 구성을 활성화하면 PolyBase와 COPY 문이 네트워크 트래픽이 Azure 백본 내에 유지되는 상태에서 강력한 인증을 사용하여 스토리지 계정에 연결할 수 있습니다. 자세한 내용은 이 가이드를 참조하세요.
Important
PowerShell Azure Resource Manager(AzureRM) 모듈은 2024년 2월 29일에 사용 중단되었습니다. 향후 모든 개발에서는 Az.Sql 모듈을 사용해야 합니다. 사용자는 지속적인 지원 및 업데이트를 보장하기 위해 AzureRM에서 Az PowerShell 모듈로 마이그레이션하는 것이 좋습니다. AzureRM 모듈은 더 이상 유지 관리되거나 지원되지 않습니다. Az PowerShell 모듈 및 AzureRM 모듈의 명령에 대한 인수는 상당히 동일합니다. 호환성에 대한 자세한 내용은 새 Az PowerShell 모듈소개를 참조하세요.
Steps
독립형 전용 SQL 풀(이전 명칭: SQL DW)이 있다면, PowerShell을 사용해 Microsoft Entra ID로 SQL 서버를 등록하세요:
Connect-AzAccount Select-AzSubscription -SubscriptionId <subscriptionId> Set-AzSqlServer -ResourceGroupName your-database-server-resourceGroup -ServerName your-SQL-servername -AssignIdentity이 단계는 Azure Synapse Analytics 작업 공간 내 전용 SQL 풀에는 필요하지 않습니다. 작업 영역의 SA-MI(시스템 할당 관리 ID)는 Synapse 관리자 역할의 구성원이기 때문에 작업 영역의 전용 SQL 풀에서 상승된 권한을 갖습니다.
스토리지 계정 만들기의 단계에 따라 범용 v2 스토리지 계정을 생성하세요.
- 범용 v1 또는 Blob Storage 계정이 있다면, 범용 v2 스토리지 계정으로 업그레이드의 단계를 따라 먼저 v2로 업그레이드해야 합니다.
- Azure Data Lake Storage Gen2의 알려진 문제에 대해서는 'Azure Data Lake Storage Gen2의 알려진 문제들'을 참조하세요.
스토리지 계정 페이지에서 접근 제어(IAM)를 선택하세요.
추가>역할 할당 추가를 선택하여 역할 할당 추가 페이지를 엽니다.
다음 역할을 할당합니다. 세부 단계에 대해서는 Azure Portal을 사용하여 Azure 역할 할당을 참조하세요.
설정 Value 역할 Storage Blob 데이터 기여자 액세스 권한 지정 사용자, 그룹 또는 서비스 주체 Members Microsoft Entra ID에 등록된 전용 SQL 풀을 호스팅하는 서버 또는 작업 공간
Note
스토리지 계정에서 소유자 권한을 가진 회원만 이 단계를 수행할 수 있습니다. 다양한 Azure 내장 역할에 대해서는 Azure 내장 역할을 참조하세요.
Azure Storage 계정에 PolyBase 연결을 활성화하려면:
이전에 만든 적이 없다면 데이터베이스 마스터키를 만들어 보세요.
CREATE MASTER KEY [ENCRYPTION BY PASSWORD = '<password>'];IDENTITY = 'Managed Service Identity'로 데이터베이스 범위 인증 정보를 생성합니다.
CREATE DATABASE SCOPED CREDENTIAL msi_cred WITH IDENTITY = 'Managed Service Identity';이 메커니즘은 관리 신원(Managed Identity)을 사용하기 때문에 Azure Storage 접근 키와 함께 SECRET을 지정할 필요가 없습니다. 이 단계는 Azure Synapse Analytics 작업 공간 내 전용 SQL 풀에는 필요하지 않습니다. 작업 영역의 SA-MI(시스템 할당 관리 ID)는 Synapse 관리자 역할의 구성원이기 때문에 작업 영역의 전용 SQL 풀에서 상승된 권한을 갖습니다.
PolyBase가 가상 네트워크로 보호되는 Azure Storage 계정과 연결되려면 IDENTITY 이름이 'Managed Service Identity'여야 합니다.
PolyBase를 사용하여 범용 v2 스토리지 계정에 연결하기 위해
abfss://스키마를 사용하여 외부 데이터 원본을 만듭니다.CREATE EXTERNAL DATA SOURCE ext_datasource_with_abfss WITH (TYPE = hadoop, LOCATION = 'abfss://myfile@mystorageaccount.dfs.core.windows.net', CREDENTIAL = msi_cred);- 이미 범용 v1이나 Blob Storage 계정과 연결된 외부 테이블이 있다면, 먼저 그 외부 테이블들을 삭제해야 합니다. 그 다음 해당 외부 데이터 소스를 제거하세요. 다음으로, 앞서 보인 것처럼
abfss://스키마를 사용하여 범용 v2 스토리지 계정에 연결하는 외부 데이터 원본을 만듭니다. 그 다음 이 새로운 외부 데이터 소스를 사용해 모든 외부 테이블을 다시 만듭니다. Generate and Publish Scripts Wizard를 사용해서 모든 외부 테이블에 대한 생성 스크립트를 생성할 수도 있습니다. - 이
abfss://방식에 대한 자세한 내용은 'Azure Data Lake Storage Gen2 URI 사용'를 참조하세요. - T-SQL 명령어에 대한 자세한 내용은 CREATE EXTERNAL DATA SOURCE를 참조하세요.
- 이미 범용 v1이나 Blob Storage 계정과 연결된 외부 테이블이 있다면, 먼저 그 외부 테이블들을 삭제해야 합니다. 그 다음 해당 외부 데이터 소스를 제거하세요. 다음으로, 앞서 보인 것처럼
외부 테이블을 사용해 평소처럼 쿼리하세요.
Azure Synapse Analytics Blob Storage 감사
Azure Synapse Analytics 감사는 SQL 감사 로그를 고객의 스토리지 계정에 기록할 수 있습니다. 이 스토리지 계정이 가상 네트워크 서비스 엔드포인트 기능을 사용한다면, VNet과 방화벽 뒤에 있는 스토리지 계정에 감사 로그를 기록하는 방법을 참고하세요.
전용 SQL 풀 SQL 서버에 가상 네트워크 방화벽 규칙을 추가하세요
이 기능이 강화되기 전에는 방화벽에 실시간 가상 네트워크 규칙을 구현하기 전에 가상 네트워크 서비스 엔드포인트를 켜야 했습니다. 엔드포인트는 특정 가상 네트워크 서브넷을 전용 SQL 풀에 연관시킵니다. 2018년 1월 기준으로는 IgnoreMissingVNetServiceEndpoint 플래그를 설정하면 이 요구사항을 우회할 수 있습니다. 이제 가상 네트워크 서비스 엔드포인트를 켜지 않고도 서버에 가상 네트워크 방화벽 규칙을 추가할 수 있습니다.
방화벽 규칙만 설정하는 것만으로는 서버 안전에 도움이 되지 않습니다. 보안이 적용되려면 가상 네트워크 서비스 엔드포인트도 켜야 합니다. 서비스 엔드포인트를 켜면, 가상 네트워크 서브넷은 꺼짐에서 켜짐으로 전환이 완료될 때까지 다운타임을 경험합니다. 이러한 가동 중단 상황은 대규모 가상 네트워크의 경우 특히 두드러집니다. IgnoreMissingVNetServiceEndpoint 플래그를 사용해 전환 중 다운타임을 줄이거나 없앨 수 있습니다.
PowerShell을 사용해 IgnoreMissingVNetServiceEndpoint 플래그를 설정할 수 있습니다. 자세한 내용은 New-AzSqlServerVirtualNetworkRule을 참조하세요.
Azure 포털을 사용해 가상 네트워크 규칙을 생성하세요
Note
이 가상 네트워크 규칙 지침은 독립형 전용 SQL 풀에 적용됩니다. 작업 공간 네트워크 구성에 대해서는 Azure Synapse Analytics IP 방화벽 규칙을 참조하세요.
이 섹션에서는 Azure 포털을 사용해 독립형 전용 SQL 풀에 대한 가상 네트워크 규칙을 만드는 방법을 배웁니다. 이 규칙은 논리 서버가 가상 네트워크 서비스 엔드포인트로 태그된 특정 서브넷에서 통신을 받도록 지시합니다.
Note
서버의 가상 네트워크 방화벽 규칙에 서비스 엔드포인트를 추가할 계획이라면, 먼저 서브넷에서 서비스 엔드포인트가 활성화되어 있는지 확인하세요.
서브넷에서 서비스 엔드포인트가 켜져 있지 않으면, 포털에서 서비스 엔드포인트를 사용하도록 요청합니다. 규칙을 추가한 같은 창에서 '활성화' 버튼을 선택하세요.
Prerequisites
Azure Synapse Analytics에서 사용하는 가상 네트워크 서비스 엔드포인트 type name으로 태그된 서브넷이 이미 있어야 합니다.
- 관련 엔드포인트 타입 이름은
Microsoft.Sql입니다. - 만약 서브넷에 타입 이름이 태그되어 있지 않을 수 있다면, 서비스 엔드포인트가 활성화되었는지 확인하세요.
Azure Portal 단계
Azure Portal에 로그인합니다.
SQL 서버를 검색하여 선택한 다음, 해당 서버를 선택하세요. 보안에서 네트워킹을 선택합니다.
공용 액세스 탭에서 공용 네트워크 액세스가 선택한 네트워크로 설정되어 있는지 확인하세요. 그렇지 않으면 가상 네트워크 설정이 숨겨집니다. 가상 네트워크 섹션에서 + 기존 가상 네트워크 추가를 선택하세요.
새로 생긴 생성/업데이트 창에서 Azure 리소스 이름으로 박스를 채우세요.
Tip
서브넷에 맞는 올바른 주소 접두사를 반드시 포함해야 합니다. 포털에서 주소 접두사 값을 찾을 수 있습니다. 모든 리소스>모든 종류>가상 네트워크로 이동하세요. 필터는 가상 네트워크를 표시합니다. 가상 네트워크를 선택한 다음, 서브넷을 선택하세요. 주소 범위 열에는 필요한 주소 접두사가 있습니다.
방화벽 창에서 생성된 가상 네트워크 규칙을 확인하세요.
'Azure 서비스 및 리소스가 이 서버에 액세스하도록 허용'을 'No'로 설정하세요.
Important
'이 서버에 Azure 서비스 및 리소스 액세스 허용'을 체크하면, 서버는 Azure 경계 내의 어떤 서브넷으로부터의 통신도 허용합니다. 이것은 Azure 데이터 센터에 대해 정의된 범위 내에 있는 것으로 인식되는 IP 주소 중 하나에서 발생하는 통신입니다. 컨트롤을 켜둔 채로 두는 것은 보안 관점에서 과도한 접근일 수 있습니다. Microsoft Azure Virtual Network 서비스 엔드포인트 기능과 Azure Synapse Analytics 가상 네트워크 규칙은 공격 표면을 줄일 수 있습니다.
창 하단 근처에 있는 OK 버튼을 선택하세요.
Note
다음 상태 또는 유형이 규칙에 적용됩니다.
- 준비 완료: 시작한 작업이 성공했음을 나타냅니다.
- 실패: 시작한 작업이 실패했음을 나타냅니다.
-
삭제됨:
Delete연산에만 적용되며, 해당 규칙이 삭제되어 더 이상 적용되지 않음을 나타냅니다. - 진행 중: 작업이 진행 중임을 나타냅니다. 이전 규칙은 작업이 이 상태인 동안 적용됩니다.
PowerShell을 사용해 가상 네트워크 규칙을 만드세요
스크립트는 PowerShell cmdlet New-AzSqlServerVirtualNetworkRule 이나 az network vnet create를 사용하여 가상 네트워크 규칙을 생성할 수도 있습니다. 자세한 내용은 New-AzSqlServerVirtualNetworkRule을 참조하세요.
REST API를 사용해 가상 네트워크 규칙을 생성하세요
내부적으로, Synapse SQL 가상 네트워크 동작을 위한 PowerShell cmdlet은 REST API를 호출합니다. REST API를 직접 호출할 수 있습니다. 자세한 내용은 가상 네트워크 규칙: 작업을 참조하세요.
오류 40914 및 40615 문제 해결
연결 오류 40914는 Azure 포털의 방화벽 창에 명시된 가상 네트워크 규칙과 관련이 있습니다.
오류 40615도 유사하지만, 방화벽의 IP 주소 규칙과 관련이 있습니다.
오류 40914
메시지 텍스트: "로그인에서 요청한 서버 '[서버-이름]'을 열 수 없습니다. 클라이언트가 서버에 액세스할 수 없습니다."
오류 설명: 클라이언트는 가상 네트워크 서버 엔드포인트가 있는 서브넷에 속해 있습니다. 하지만 서버에는 서브넷이 데이터베이스와 통신할 권한을 부여하는 가상 네트워크 규칙이 없습니다.
오류 해결: Azure 포털의 방화벽 창에서 가상 네트워크 규칙 제어를 사용하여 서브넷에 대한 가상 네트워크 규칙을 추가하세요.
오류 40615
메시지 텍스트: "로그인에서 요청한 서버 '{0}'을(를) 열 수 없습니다. IP 주소가 '{1}'인 클라이언트는 서버에 액세스할 수 없습니다."
오류 설명: 클라이언트가 서버에 접속할 권한이 없는 IP 주소에서 연결을 시도하고 있습니다. 서버 방화벽에는 주어진 IP 주소의 클라이언트가 데이터베이스와 통신하도록 허용하는 IP 주소 규칙이 없습니다.
오류 해결: 클라이언트의 IP 주소를 IP 규칙으로 입력하세요. 이 단계를 수행하려면 Azure 포털의 방화벽 패널을 사용하세요.