전체 IPv4 대역을 지정한 Azure SQL 서버 방화벽 규칙

설명

ARM 또는 Bicep의 Microsoft.Sql/servers/firewallRules에서 startIpAddress를 0.0.0.0, endIpAddress를 255.255.255.255로 지정하면 전체 IPv4 범위를 허용합니다. 이 범위가 공용 엔드포인트에 적용되면 방화벽이 클라이언트의 출발지 주소를 제한하지 못합니다.

실제 연결에는 서버의 네트워크 설정도 영향을 줍니다. publicNetworkAccess가 비활성화되어 있다면 이 방화벽 규칙만으로 공용 연결이 가능해지지 않습니다. 연결할 수 있는 경우에도 데이터베이스 인증과 권한은 별도로 필요합니다.

시작과 끝을 모두 0.0.0.0으로 지정하는 별도 설정은 다른 고객의 구독을 포함한 Azure 리소스의 연결을 허용합니다. 전체 IPv4 범위와는 다른 예외지만, 내부 전용 연결로 간주해서는 안 됩니다.

잠재적 영향

공용 연결이 활성화되고 전체 IPv4 규칙이 적용되면 방화벽이 인터넷상의 IPv4 출발지 주소를 제한하지 못합니다.
네트워크 경로가 허용된 외부 클라이언트가 데이터베이스 인증을 시도할 수 있습니다. 데이터 접근에는 유효한 인증과 권한이 여전히 필요하지만, 유출된 자격 증명이 있다면 넓은 허용 범위가 악용 기회를 늘릴 수 있습니다.

해결 방법

공용 연결이 필요한 경우 실제 클라이언트의 출발지 IPv4 주소만 허용하세요. NAT를 사용하는 환경에서는 서버가 확인하는 공인 출발지 주소를 기준으로 범위를 정하세요. startIpAddress와 endIpAddress에는 CIDR이 아닌 개별 IPv4 주소를 오름차순으로 지정하세요.
전체 IPv4 대역을 허용하는 규칙을 제거하고, 다른 서버 및 데이터베이스 수준 방화벽 규칙과 공용 네트워크 설정도 함께 점검하세요.
프라이빗 엔드포인트를 사용하는 구조라면 필요한 사설 연결을 검증한 뒤 공용 네트워크 액세스를 비활성화하세요. VNet이나 점프 호스트를 사용한다는 사실만으로 공용 경로가 제거되지는 않습니다. 인증과 데이터베이스 권한도 별도로 관리하세요.

예시

다음 발췌는 전체 IPv4 범위와 제한된 범위를 비교합니다. 첫 예시의 관리자 이름과 암호 문자열은 실제 자격 증명으로 사용하면 안 되며, 미리 보기 API 버전과 리소스 스키마도 배포 전에 검증해야 합니다. 두 번째 예시는 기존 sample 서버를 전제로 한 일부 구성으로, 완성된 배포 템플릿이 아닙니다.

전체 IPv4 범위

bicep

resource sqlServer1 'Microsoft.Sql/servers@2021-02-01-preview' = {
  name: 'sqlServer1'
  location: resourceGroup().location
  properties: {
    administratorLogin: 'adminUsername'
    administratorLoginPassword: 'adminPassword'
  }
}

resource sqlServer1AllowAll 'Microsoft.Sql/servers/firewallRules@2021-02-01-preview' = {
  parent: sqlServer1
  location: resourceGroup().location
  name: 'AllowAll'
  properties: {
    endIpAddress: '255.255.255.255'
    startIpAddress: '0.0.0.0'
  }
}

제한된 주소 범위