설명
공개 엔드포인트에 0.0.0.0부터 255.255.255.255까지 허용하면 출발지 IPv4 제한이 없어집니다. 업무상 접속이 필요 없는 외부 클라이언트도 연결을 시도할 수 있으므로 승인된 출발지로 범위를 제한해야 합니다. 네트워크 연결이 허용되어도 데이터베이스 인증과 권한은 계속 적용됩니다.
Azure SQL Database에서 시작과 끝을 모두 0.0.0.0으로 설정하면 Azure 서비스의 연결을 허용하는 별도 예외가 됩니다. 다른 고객의 Azure 리소스도 포함될 수 있으며, 필요한 클라이언트만 허용하는 설정이 아닙니다. 이 예외는 전체 IPv4 범위와 구분해야 하며 다른 서비스에 그대로 적용해서는 안 됩니다.
잠재적 영향
- 불필요한 외부 출발지에서 데이터베이스 연결을 시도할 수 있는 범위가 넓어집니다.
- 인증 정보 유출이나 과도한 데이터 권한이 겹치면 비인가 데이터 조회·변경 위험이 커질 수 있습니다.
해결 방법
- 승인된 애플리케이션과 관리 도구의 실제 공인 출발지 주소를 확인하고 필요한 주소만 허용하세요. NAT를 거친 주소는 클라이언트의 로컬 주소와 다를 수 있습니다. Azure SQL에서는 서버 수준과 데이터베이스 수준 방화벽 규칙을 함께 검토하세요.
- 공개 연결이 필요하지 않다면 해당 서비스가 지원하는 프라이빗 연결, DNS와 클라이언트 경로를 구성하고 시험한 뒤 공개 접근을 비활성화하세요. 사설 IP를 방화벽에 적는 것만으로 프라이빗 경로가 구성되지는 않습니다.
- AzureRM 버전과 서비스에 맞는 리소스를 사용하세요. 리소스 종류나 주소를 변경할 때 Terraform 상태와 계획을 확인하고, 적용 후 필요한 연결과 불필요한 출발지의 차단을 시험하세요. 인증과 최소 데이터 권한도 점검하세요.
예시
아래 부분 예제는 AzureRM v4.50.0의 azurerm_mssql_firewall_rule을 사용합니다. 참조하는 azurerm_mssql_server.example을 정의하고 문서용 주소 203.0.113.10을 승인된 클라이언트의 실제 공인 출발지로 바꿔 사용하세요. 이전 azurerm_sql_firewall_rule에서 옮길 때는 Terraform 상태와 변경 계획을 별도로 확인해야 합니다.
변경 전
hcl
resource "azurerm_mssql_firewall_rule" "public_firewall_rule" {
name = "FirewallRule1"
server_id = azurerm_mssql_server.example.id
start_ip_address = "0.0.0.0"
end_ip_address = "255.255.255.255"
}
변경 후
hcl
resource "azurerm_mssql_firewall_rule" "public_firewall_rule" {
name = "FirewallRule1"
server_id = azurerm_mssql_server.example.id
start_ip_address = "203.0.113.10"
end_ip_address = "203.0.113.10"
}
설명:
- 변경 전: 전체 IPv4 범위를 허용해 출발지 제한이 없습니다.
- 변경 후: 한 클라이언트 주소만 허용합니다. 다른 방화벽 규칙이 불필요한 접근을 추가하지 않는지도 확인해야 합니다.