Azure Firewall Azure 가상 네트워크에 대한 중앙 집중식 트래픽 검사 및 필터링을 제공하는 관리형 클라우드 네이티브 네트워크 보안 서비스입니다. 계층 4에서 작동하는 네트워크 보안 그룹과 달리 Azure Firewall 계층 3에서 7까지의 트래픽을 검사합니다. 이 기능을 사용하면 FQDN(정규화된 도메인 이름) 필터링, 위협 인텔리전스, IDPS(침입 탐지 및 방지) 및 TLS 검사를 수행할 수 있습니다. 허브 가상 네트워크 내의 전용 서브넷에 Azure Firewall 배포하고 대상에 도달하기 전에 검사를 위해 스포크 워크로드의 트래픽을 방화벽을 통해 라우팅합니다.
이 문서에서는 올바른 Azure Firewall SKU를 선택하고, 허브-스포크 토폴로지에 방화벽을 배치하고, 규칙 유형을 구성하고, NAT 게이트웨이 및 경로 서버와 같은 보완 서비스와 통합하는 방법을 설명합니다. Azure Firewall은 Azure DDoS 보호와 Azure Web Application Firewall과 함께 세 가지 핵심 Azure 네트워크 보안 서비스 중 하나입니다.
이 문서에서 다루는 내용
이 글에서는 Azure Firewall을 이용한 중앙 집중식 네트워크 트래픽 검사에 대해 다룹니다. 다음 항목에 대해 알아봅니다.
- 보안 요구 사항 및 워크로드 민감도에 따라 SKU 계층 선택
- 방화벽을 통해 트래픽이 통과하도록 강제하는 허브 배치 및 UDR(사용자 정의 경로) 패턴입니다.
- DNAT, 네트워크 및 애플리케이션 규칙에 대한 규칙 처리 논리입니다.
- 온-프레미스 검사가 필요한 환경을 위한 강제 터널링
- 프리미엄 계층의 TLS 검사 및 IDPS 기능
- SNAT 포트 크기 조정을 위한 NAT 게이트웨이 및 BGP 기반 라우팅을 위한 경로 서버와의 통합
이 문서가 필요한 사람
워크로드에 다음 기능 중 하나 이상이 필요한 경우 Azure Firewall 배포합니다.
- 중앙 집중식 송신 제어: NSG IP 기반 규칙이 제공하는 것 이상으로 워크로드가 도달할 수 있는 외부 FQDN 및 URL을 제한해야 합니다.
- 동서 트래픽 검사: 스포크 가상 네트워크 간의 트래픽은 방화벽이 이를 허용하기 전에 상태 저장 검사 지점을 통과해야 합니다.
- 규정 준수 위임 로깅: 규정 프레임워크에는 FQDN 수준 세분성과의 허용된 연결 및 거부된 연결에 대한 전체 계층 7 가시성이 필요합니다.
- 위협 방지: 명령 및 제어 콜백, 악용 시도 및 횡적 이동을 비롯한 악의적인 트래픽 패턴을 식별하려면 서명 기반 침입 탐지 및 방지가 필요합니다.
- TLS 검사: 워크로드에 도달하거나 네트워크를 나가기 전에 HTTPS(암호화된 트래픽)의 암호를 해독하고 위협을 검사해야 합니다.
FQDN 인식 없이 계층 4 패킷 필터링만 필요한 조직은 더 간단하고 저렴한 대안으로 NSG 및 ASG 를 고려해야 합니다.
리프트 앤 시프트 포커스: 온-프레미스 방화벽 규칙 기반을 Azure Firewall 정책으로 변환합니다. 비 HTTP/S 트래픽에 대한 네트워크 규칙 및 FQDN 기반 필터링에 대한 애플리케이션 규칙으로 시작합니다. 마이그레이션 중에 광범위한 허용 정책으로 시작한 다음, Azure Firewall 로그를 검토한 후 규칙을 강화합니다.
포커스 현대화: 허브에서 중앙 집중식 SNAT 및 DNAT 지점으로 Azure Firewall 사용합니다. 애플리케이션 스포크 간 및 스포크와 인터넷 간 트래픽을 검사하고, AKS 및 Azure PaaS 아웃바운드 트래픽에는 애플리케이션 규칙과 FQDN 태그를 사용하며, 애플리케이션 계층 간에 민감한 트래픽이 오가는 경우 TLS 검사를 계획하세요.
클라우드 간 포커스: 보안 가상 허브에 Azure Firewall 배포하여 클라우드 간 전송 트래픽을 검사합니다. AWS 또는 Google Cloud에서 IPSec 터널 트래픽에 대한 네트워크 규칙을 구성하고 IDPS를 사용하여 연결된 클라우드 간의 비정상적인 트래픽 패턴을 감시합니다.
Azure Firewall SKU 계층
Azure Firewall 세 가지 SKU 계층에서 사용할 수 있습니다. 각 계층은 이전 계층의 기능을 기반으로 합니다.
| Capability | 기초 | 스탠다드 | Premium |
|---|---|---|---|
| 상태 기반 패킷 검사 | ✔ | ✔ | ✔ |
| FQDN 필터링(아웃바운드) | ✔ | ✔ | ✔ |
| 네트워크 규칙(IP, 포트, 프로토콜) | ✔ | ✔ | ✔ |
| 애플리케이션 규칙(FQDN, URL) | ✔ | ✔ | ✔ |
| NAT 규칙(DNAT) | ✔ | ✔ | ✔ |
| 위협 인텔리전스 필터링 | 경고만 | ✔ (경고 + 거부) | ✔ (경고 + 거부) |
| DNS 프록시 | ✗ | ✔ | ✔ |
| 웹 범주 | ✗ | ✔ | ✔ |
| IDPS(침입 감지 및 방지) | ✗ | ✗ | ✔ |
| TLS 검사 | ✗ | ✗ | ✔ |
| URL 필터링(전체 경로) | ✗ | ✗ | ✔ |
| 명시적 프록시 | ✗ | ✔ | ✔ |
| 지역 가용성 | 제한된 지역 | 모든 지역 | 모든 지역 |
| 적합한 대상 | 개발/테스트, 소규모 워크로드 | 표준 프로덕션 | 높은 보안, 규정 준수 기반 |
SKU를 선택하는 방법
다음 의사 결정 조건을 사용합니다.
- 위협 인텔리전스 필터링(거부 모드) 또는 고급 검사 없이 FQDN 기반 송신 필터링이 필요한 개발/테스트 환경 또는 작은 워크로드가 있는 경우 기본을 선택합니다. 기본 SKU는 경고 전용 모드에서 위협 인텔리전스를 포함하지만 거부 모드, DNS 프록시 또는 웹 범주를 지원하지 않습니다. 기본 SKU에는
AzureFirewallManagementSubnet와 함께 전용AzureFirewallSubnet(최소 /26)가 필요하며, 제한된 지역에서만 사용할 수 있습니다. - 위협 인텔리전스 기반 필터링, FQDN 규칙 확인을 위한 DNS 프록시, 웹 범주 필터링 및 Azure Firewall Manager 통한 중앙 집중식 정책 관리가 필요한 프로덕션 워크로드에 대한 표준을 선택합니다. 표준은 알려진 악성 IP 주소 및 도메인에 대한 연결을 차단하는 위협 인텔리전스 피드와 함께 완전한 상태 저장 검사 엔진을 제공합니다.
- 규정 또는 보안 요구 사항에서 암호화된 트래픽의 TLS 검사, 지속적으로 업데이트되는 규칙이 있는 서명 기반 IDPS(50개 이상의 범주에서 67,000개 이상의 서명, 실시간으로 업데이트됨) 또는 FQDN을 초과하는 전체 URL 경로 필터링을 요구하는 경우 프리미엄을 선택합니다. 암호화된 트래픽 검사가 필수인 금융 서비스, 의료 및 정부와 같은 산업에는 프리미엄이 필요합니다.
메모
방화벽을 다시 배포하지 않고 표준에서 프리미엄으로 업그레이드합니다. 프리미엄에서 표준으로 다운그레이드하려면 재배포가 필요합니다.
허브 배치 및 UDR 라우팅 패턴
허브 가상 네트워크 내에서 정확하게 AzureFirewallSubnet 명명된 전용 서브넷에 Azure Firewall 배포합니다. 이 서브넷에는 최소 크기 /26(사용 가능한 IP 주소 59개)이 필요합니다.
라우팅 아키텍처
허브-스포크 토폴로지에서 스포크 워크로드 서브넷은 트래픽을 인터넷 또는 다른 스포크로 직접 라우팅하지 않습니다. 대신 각 스포크 서브넷의 UDR은 기본 경로(0.0.0.0/0)를 Azure Firewall 개인 IP 주소로 설정합니다. 이 패턴은 북-남(인터넷 방향) 및 동-서(스포크 간) 트래픽을 포함한 모든 트래픽이 검사를 위해 방화벽을 통과하도록 보장합니다.
UDR 구성 패턴:
| 경로 테이블(적용 대상) | 주소 접두사 | 다음 홉 유형 | 다음 홉 주소 |
|---|---|---|---|
| 스포크 서브넷 A | 0.0.0.0/0 | 가상 어플라이언스 | 방화벽 개인 IP |
| 스포크 서브넷 A | 10.1.0.0/16(기타 스포크) | 가상 어플라이언스 | 방화벽 개인 IP |
| 스포크 서브넷 B | 0.0.0.0/0 | 가상 어플라이언스 | 방화벽 개인 IP |
| 스포크 서브넷 B | 10.0.0.0/16(기타 스포크) | 가상 어플라이언스 | 방화벽 개인 IP |
AzureFirewallSubnet 방화벽 자체는 대부분의 상황에서 UDR이 필요하지 않은데, 방화벽이 가상 네트워크 피어링을 통해 시스템 경로를 사용해 스포크 네트워크에 도달하기 때문입니다. Azure Route Server 통합하면 방화벽 서브넷이 BGP를 통해 경로를 학습합니다. 이 접근 방식은 네트워크가 증가함에 따라 수동 경로 유지 관리의 필요성을 제거합니다.
팁 (조언)
Azure Virtual Network Manager 경로 테이블의 구성을 자동화하여 Azure Firewall 다음 홉으로 사용하여 많은 스포크 구독에서 수동 UDR 관리를 줄일 수 있습니다.
서브넷 요구 사항
| Subnet | 최소 크기 | Purpose | Notes |
|---|---|---|---|
AzureFirewallSubnet |
/26 | Azure Firewall 인스턴스 호스트 | 정확히 이름을 지정해야 합니다. AzureFirewallSubnet |
AzureFirewallManagementSubnet |
/26 | 관리 트래픽(기본 SKU만 해당) | Basic SKU에는 필수이며, 다른 SKU에서는 강제 터널링 시 선택 사항입니다. |
허브 가상 네트워크 디자인 및 서브넷 계획에 대한 자세한 내용은 허브-스포크 토폴로지 참조하세요.
규칙 유형 및 처리 논리
Azure Firewall Azure Firewall 정책을 통해 규칙을 처리합니다. 규칙은 규칙 컬렉션으로 구성되며, 규칙 컬렉션은 규칙 컬렉션 그룹으로 그룹화됩니다. 방화벽은 다음 우선 순위 순서로 규칙을 평가합니다.
- DNAT 규칙 (대상 네트워크 주소 변환): 먼저 처리됩니다. 공용 IP에서 방화벽 뒤의 개인 IP로 인바운드 트래픽을 변환합니다.
- 네트워크 규칙: 처리된 두 번째 규칙입니다. 원본 IP, 대상 IP, 포트 및 프로토콜(계층 3/4)에 따라 트래픽을 허용하거나 거부합니다.
- 애플리케이션 규칙: 마지막으로 처리되었습니다. FQDN, URL 또는 웹 범주(계층 7)에 따라 아웃바운드 트래픽을 허용하거나 거부합니다.
각 규칙 유형 내에서 규칙 컬렉션 그룹은 우선 순위(가장 낮은 숫자 = 가장 높은 우선 순위)로 평가됩니다. 그룹 내에서 규칙 컬렉션은 우선 순위에 따라 평가됩니다. 첫 번째 일치 규칙은 작업(허용 또는 거부)을 결정하고 추가 평가를 중지합니다.
DNAT 규칙
DNAT 규칙을 사용하여 방화벽의 공용 IP 주소를 통해 내부 서비스를 게시합니다. 방화벽은 대상 주소를 공용 IP에서 백 엔드 서비스의 개인 IP로 변환합니다. 일반적인 시나리오는 다음과 같습니다.
- 포트 443에서 방화벽의 공용 IP를 통해 내부 웹 서버 노출
- VM에 공용 IP를 할당하지 않고 점프 상자에 제어된 RDP 또는 SSH 액세스 제공
- 인터넷에서 인바운드 액세스가 필요한 비 HTTP/S 서비스 게시
Example: Translate inbound TCP 443 on firewall public IP → 10.1.2.4:443 (internal web server)
DNAT 규칙은 해당 네트워크 규칙을 암시적으로 추가하여 변환된 트래픽을 허용합니다. DNAT 규칙이 일치하면 트래픽이 변환되고 추가 네트워크 규칙 처리 없이 허용됩니다. 보안을 위해 DNAT 규칙의 원본 IP 주소를 와일드카드를 사용하지 않고 특정 인터넷 원본으로 제한합니다.
네트워크 규칙
네트워크 규칙은 계층 3 및 계층 4에서 트래픽을 필터링합니다. 원본 IP 주소, 대상 IP 주소, 대상 포트 및 프로토콜에 따라 트래픽을 허용하거나 거부해야 하는 경우 네트워크 규칙을 사용합니다. 네트워크 규칙은 FQDN 확인을 수행하지 않습니다. IP 주소에서 엄격하게 작동합니다. 일반 사용 사례는 다음과 같습니다.
- 특정 포트에 대해 스포크 간 통신 허용(예: TCP 1433 포트의 SQL Server)
- 특정 시간 서버에 대한 NTP(UDP 123) 허용.
- 거부 규칙을 사용하여 알려진 악성 IP 범위에 대한 트래픽 차단
- 특정 서브넷 간의 네트워크 진단에 대해 ICMP를 허용합니다.
네트워크 규칙은 TCP, UDP, ICMP 및 모든 프로토콜 유형을 지원합니다. IP 주소, IP 범위, 서비스 태그 및 IP 그룹을 원본 및 대상으로 지정할 수 있습니다.
애플리케이션 규칙
애플리케이션 규칙은 FQDN, URL 및 웹 범주를 기반으로 아웃바운드 HTTP/S 및 MSSQL 트래픽을 필터링합니다. 애플리케이션 규칙에는 FQDN 확인을 위한 DNS 프록시 기능이 필요합니다. 다음과 같은 경우 애플리케이션 규칙을 사용합니다.
- 특정 FQDN(예
*.microsoft.com: 또는storage.blob.core.windows.net)에 대한 액세스를 허용해야 합니다. - 예를 들어
github.com/myorg/*는 허용하고 다른 GitHub 경로는 차단하는 방식으로 URL 경로를 기준으로 필터링하려고 합니다(프리미엄 SKU에서만 지원). - 전체 웹 범주를 허용하거나 차단해야 합니다(예: "개발자 도구"를 허용하고 "도박"을 차단).
애플리케이션 규칙은 필요한 FQDN을 단일 태그로 그룹화하여 규칙 생성을 간소화하는 일반적인 Azure 서비스(예: Windows 업데이트, Azure Backup 및 HDInsight)에 대한 FQDN 태그를 제공합니다.
Important
Azure Firewall DNS 프록시를 사용하도록 설정하면 방화벽이 워크로드에 대한 DNS 확인자 역할을 합니다. 가상 네트워크 DNS 설정을 방화벽의 사설 IP를 가리키도록 설정하여 FQDN 기반 규칙이 올바르게 해결되도록 하세요. DNS 아키텍처 세부 정보는 DNS 보안 및 개인 이름 확인을 참조하세요.
SNAT 동작
기본적으로 Azure Firewall 공용 IP 주소로 향하는 아웃바운드 트래픽에 SNAT(원본 네트워크 주소 변환)를 적용합니다. 대상이 개인 IP 범위(RFC 1918) 또는 공유 주소 공간(RFC 6598)인 경우 방화벽은 트래픽을 SNAT하지 않습니다. 방화벽은 인터넷 바인딩 연결의 원본 IP를 공용 IP 주소 중 하나로 변환합니다. 각 공용 IP는 백 엔드 인스턴스당 2,496개의 SNAT 포트를 제공합니다.
아웃바운드 연결 속도가 높은 워크로드의 경우 NAT 게이트웨이와 통합하여 공용 IP당 64,512개의 포트로 확장합니다(최대 16개의 공용 IP, 총 약 100만 개의 SNAT 포트).
NAT 게이트웨이를 AzureFirewallSubnet연결하면 모든 아웃바운드 인터넷 트래픽은 NAT 게이트웨이 공용 IP 주소를 자동으로 사용합니다. 방화벽은 트래픽을 계속 검사하지만 NAT 게이트웨이는 SNAT 변환을 처리합니다. 이중 NAT가 발생하지 않습니다.
메모
영역 중복 Azure Firewall 있는 NAT 게이트웨이에는 StandardV2 NAT Gateway SKU가 필요합니다. NAT 게이트웨이는 Virtual WAN 보안 허브 아키텍처에서 지원되지 않습니다.
방화벽 관리자 및 정책 상속
Azure Firewall Manager 여러 Azure Firewall 인스턴스에서 중앙 집중식 보안 정책 및 경로 관리를 제공합니다. 주요 기능은 다음과 같습니다.
- 정책 계층 구조: 조직 전체 규칙을 사용하여 기본(부모) 정책을 만들고 자식 팀이 부모로부터 상속되는 자식 정책을 만들 수 있도록 허용합니다. 부모 규칙은 자식 우선 순위 값에 관계없이 항상 우선 순위가 적용됩니다.
- 지역 간 관리: 방화벽 정책은 모든 지역 또는 구독의 방화벽과 연결할 수 있는 전역 리소스입니다.
- 다중 방화벽 거버넌스: 여러 지역의 허브 방화벽 또는 보안 Virtual WAN 허브 간에 일관된 보안 태세를 적용합니다.
NAT 규칙은 방화벽별로 지정되며 부모 정책에서 상속되지 않습니다. 위협 인텔리전스 모드는 상속되지만 자식 정책에서 더 엄격한 모드로만 재정의할 수 있습니다. 방화벽 연결이 0개 또는 1개인 정책은 추가 비용 없이 포함됩니다. 추가 연결에는 요금이 부과됩니다.
강제 터널링
일부 규제 환경에서는 인터넷에 연결하기 전에 먼저 모든 인터넷 바인딩 트래픽이 온-프레미스 검사 지점을 통해 라우팅되어야 합니다. Azure Firewall 이 요구 사항을 수용하도록 강제 터널링을 지원합니다.
강제 터널링을 사용하도록 설정하는 경우:
-
AzureFirewallManagementSubnet는 방화벽 관리 트래픽을 인터넷으로 직접 전달합니다. 이 서브넷에는 다음 홉 인터넷이 있는 0.0.0.0/0에 대한 경로가 있어야 합니다. 온-프레미스 검사를 통해 관리 트래픽을 강제 적용할 수 없습니다. - 이 서비스는
AzureFirewallSubnet인터넷 연결 워크로드 트래픽을 ExpressRoute 또는 VPN Gateway를 통해 온프레미스 방화벽 또는 제3자 네트워크 가상 어플라이언스(NVA)로 라우팅합니다. - 인바운드 트래픽이 방화벽 공용 IP에 직접 연결할 수 없으므로 강제 터널링 모드에서는 DNAT 규칙이 지원되지 않습니다.
- 모든 아웃바운드 트래픽이 온-프레미스 경로를 통해 종료되므로 강제 터널링을 구성할 때 방화벽에 공용 IP
AzureFirewallSubnet가 필요하지 않습니다.
규정 준수 의무에 따라 모든 인터넷 바인딩 트래픽의 온-프레미스 가시성이 필요하거나 기존 온-프레미스 보안 스택과 Azure Firewall 연결해야 하는 경우 강제 터널링을 사용합니다. 일반적인 시나리오에는 데이터 상주 규정이 적용되는 금융 서비스 환경과 중앙 집중식 인터넷 중단 요구 사항이 있는 정부 네트워크가 포함됩니다.
Important
강제 터널링 모드 AzureFirewallManagementSubnet 에서는 자체 공용 IP와 0.0.0.0/0이 인터넷을 다음 홉으로 가리키는 UDR이 필요합니다. 이 구성을 통해 Azure 관리 채널을 방화벽으로 유지할 수 있습니다.
TLS 검사(프리미엄)
Azure Firewall Premium은 아웃바운드 HTTPS 연결을 가로채고, 트래픽의 암호를 해독하고, IDPS 서명 및 애플리케이션 규칙에 대해 검사한 다음, 다시 암호화하고 전달합니다. 이 프로세스에는 Azure Key Vault 저장된 중간 CA 인증서가 필요합니다.
인증서 요구 사항
| 요구 사항 | 규격 |
|---|---|
| 인증서 유형 | 중간 CA |
| Key size | RSA 2048비트 최소값 |
| CA 플래그 | TRUE |
| 주요 사용량 | KeyCertSign |
| 유효성 | 최소 1년 앞으로 |
| Storage | Azure Key Vault(내보낼 수 있어야 합니다). |
방화벽은 중간 CA 인증서를 사용하여 가로채는 연결에 대한 서버 인증서를 동적으로 생성합니다. 최종 사용자 브라우저 및 애플리케이션은 신뢰 경고를 피하기 위해 인증서 저장소에서 조직의 루트 CA 또는 중간 CA를 신뢰해야 합니다.
IDPS (침입 탐지 및 예방 시스템)
프리미엄 SKU에는 50개 이상의 범주에 걸쳐 67,000개가 넘는 규칙이 있는 완전 관리형 IDPS 엔진이 포함되어 있습니다. 서명은 매일 20~40개 이상의 새 규칙이 릴리스되어 지속적으로 업데이트됩니다. IDPS는 다음 두 가지 모드로 작동합니다.
- 경고 모드: 트래픽을 차단하지 않고 서명 일치를 기록합니다. 초기 배포 및 튜닝 중에 사용합니다.
- 경고 및 거부 모드: IDPS 서명과 일치하는 트래픽을 기록하고 차단합니다. 튜닝 후 프로덕션에서 사용합니다.
IDPS 범주는 맬웨어 명령 및 제어, 피싱, 트로이 목마, 봇넷, 익스플로잇 키트, 취약성 및 SCADA/ICS 프로토콜을 다룹니다.
Caution
TLS 검사는 대기 시간을 도입하고 개인 정보 보호에 영향을 줍니다. 조직의 법률 및 규정 준수 팀이 암호화된 트래픽 검사를 승인하는지 확인합니다. 바이패스 규칙을 사용하여 필요에 따라 중요한 범주(의료, 은행)를 제외합니다.
AKS 송신 필터링
Azure Kubernetes Service(AKS) 클러스터에 제어된 아웃바운드 트래픽이 필요한 경우 Azure Firewall은 클러스터 노드에 대해 FQDN 기반 아웃바운드 필터링을 제공합니다. 송신 필터링 없이 AKS 노드는 모든 인터넷 엔드포인트에 도달할 수 있으므로 공급망 및 데이터 반출 공격에 대한 공격 노출 영역이 증가합니다.
이 패턴을 구현하려면 다음을 수행합니다.
-
outboundType를userDefinedRouting(으)로 설정하고 노드 서브넷에 사용자 지정 경로 테이블을 사용하는 AKS를 배포합니다. - 기본 경로(0.0.0.0/0)를 Azure Firewall 개인 IP로 설정합니다.
- 필요한 AKS FQDN(컨테이너 레지스트리, API 서버 엔드포인트, Microsoft 패키지 리포지토리)을 허용하는 애플리케이션 규칙을 방화벽 정책에 만듭니다.
- 필수 비 HTTP/S 엔드포인트(NTP, DNS, 터널 연결)에 대한 네트워크 규칙을 만듭니다.
이 패턴은 보안 팀이 AKS 노드가 도달할 수 있는 외부 엔드포인트를 파악하고 제어하는 동시에 클러스터가 올바르게 작동하도록 허용합니다. 필요한 FQDN은 AKS 기능 집합에 따라 다릅니다. GPU 노드, Azure Monitor 또는 Azure Policy 사용하는 클러스터에는 추가 승인된 목록 항목이 필요합니다.
자세한 FQDN 요구 사항 및 규칙 예제는 Azure Firewall 사용하여 AKS 배포를 보호합니다.
메모
Azure Firewall 사용하여 AKS 송신 필터링을 수행하려면 플랫폼과 애플리케이션 팀 간에 신중한 조정이 필요합니다. FQDN 규칙이 없으면 Pod 예약 실패 및 이미지 끌어오기 오류가 발생합니다. 허용 정책으로 시작하고 방화벽 로그에서 트래픽 패턴을 관찰한 후 강화합니다.
디자인 고려 사항
리프트 앤 시프트 방화벽 디자인 포커스
- 온-프레미스 방화벽 규칙을 Azure Firewall 정책으로 변환: HTTP/S가 아닌 프로토콜에 대한 네트워크 규칙 및 FQDN 필터링이 필요한 HTTP/S 또는 MSSQL 대상에 대한 애플리케이션 규칙을 사용합니다.
- 현재 보안 상태를 미러링하는 광범위한 허용 규칙으로 시작한 다음, Azure Firewall 로그를 사용하여 필요한 대상 및 포트를 식별하여 마이그레이션 후 강화합니다.
- 규칙 유지 관리가 기존 세분화 경계를 따르도록 IP 그룹을 사용하여 원본 및 대상 영역을 모델링합니다.
- 액세스 범위를 좁히기 전에 Azure 트래픽 패턴을 온-프레미스 기준과 비교할 수 있도록 첫날에 진단 설정을 사용하도록 설정합니다.
방화벽 디자인 포커스 현대화
- 수신 및 송신 정책이 IT 관리형 허브에 유지되도록 허브 방화벽을 애플리케이션 스포크의 중앙 집중식 SNAT 및 DNAT 지점으로 사용합니다.
- 애플리케이션 계층 간에 동서 TLS 검사 또는 프로덕션 IDPS 적용이 필요한 경우 Azure Firewall Premium을 사용하도록 설정합니다.
- FQDN 태그 및 애플리케이션 규칙을 사용하여 큰 대상 IP 목록을 유지하지 않고 AKS 및 Azure PaaS 종속성을 허용합니다.
- 인바운드 흐름이 승인된 검사 경로를 통해서만 백 엔드 스포크에 도달할 수 있도록 Front Door 또는 Application Gateway 디자인으로 DNAT 요구 사항을 검토합니다.
클라우드 간 방화벽 디자인 포커스
- Azure가 지사, Azure 및 기타 클라우드 네트워크의 경유 지점인 경우 보안이 적용된 가상 허브에 Azure Firewall을 배포합니다.
- 네트워크 규칙을 사용하여 경로가 Azure 도착한 후 AWS Transit Gateway, AWS 가상 프라이빗 게이트웨이 또는 Google Cloud VPN 첨부 파일에서 IPSec 터널 트래픽을 검사합니다.
- IDPS를 사용하여 클라우드 환경 간의 횡적 이동을 나타낼 수 있는 비정상적인 동서 및 클라우드 간 트래픽 패턴을 검색할 수 있습니다.
- 위협 인텔리전스 필터링을 설정하여 단일 정책 화면으로 연결된 모든 클라우드에서 알려진 악성 대상을 차단합니다.
사전 요구 사항
Azure Firewall 배포하기 전에 다음을 수행합니다.
-
AzureFirewallSubnet: 허브 가상 네트워크에는 최소 크기 /26으로 명명된
AzureFirewallSubnet전용 서브넷이 포함되어야 합니다. 서브넷 계획 지침은 가상 네트워크 및 서브넷 디자인을 참조하세요. - 허브-스포크 또는 Virtual WAN 토폴로지: 스포크 네트워크에서 트래픽을 라우팅하는 중앙 허브에 Azure Firewall 배포합니다. 토폴로지 옵션은 허브-스포크 토폴로지 또는 가상 WAN을 참조하세요.
- IP 주소 계획: 방화벽 서브넷, 관리 서브넷(강제 터널링을 사용하는 경우) 및 공용 IP 주소에 대한 주소 공간을 예약합니다. IP 주소 계획을 참조하세요.
- Azure Firewall Manager: 여러 방화벽 인스턴스에서 기본 규칙을 공유하는 정책 계층 구조가 필요한 경우 Azure Firewall Manager 사용합니다.
- Log Analytics 작업 영역: 배포 전에 방화벽 진단 로그에 대한 작업 영역을 만들어 트래픽을 모니터링하고 첫날부터 규칙을 해결할 수 있습니다.
보안 고려 사항
- 로깅: 진단 설정을 사용하도록 설정하여 Log Analytics 작업 영역에 Azure Firewall 로그를 보냅니다. 구조적 로그는 허용 및 거부된 모든 연결에 대한 FQDN 수준의 가시성을 제공하여 감사 및 포렌식 분석을 지원합니다.
- 가용성: 가용성 영역 간에 Azure Firewall 배포하여 가용성 SLA를 최대화합니다. 현재 SLA 백분율은 Azure Firewall SLA를 참조하세요.
- 계층화된 방어: Azure Firewall NSG를 보완하지만 대체하지는 않습니다. 서브넷에 NSG를 적용하고 마이크로 세분화를 위해 NIC 수준을 적용합니다. 중앙 집중식 정책, 위협 인텔리전스 및 계층 7 검사에 방화벽을 사용합니다.
- 검사할 적절한 크기: 웹-앱 및 앱-데이터베이스와 같은 애플리케이션 내 계층을 포함하여 방화벽을 통해 모든 흐름을 강제로 적용하면 대기 시간 및 기가바이트당 처리 비용이 추가됩니다. 신뢰할 수 있는 계층 간의 동서 트래픽에 NSG 및 ASG를 사용하고, 인터넷 바인딩, 스포크 간, 하이브리드 또는 클라우드 간 트러스트 경계를 초과하는 트래픽에 대한 방화벽 검사를 예약합니다. 이 방법은 방화벽이 검사의 이점을 활용하고 불필요한 비용을 방지하는 트래픽에 초점을 맞췄습니다.
- DDoS 보호: Azure DDoS Protection을 사용하여 Azure Firewall 연결된 공용 IP를 보호합니다. DDoS 보호를 참조하세요.
- ExpressRoute 트래픽: ExpressRoute를 사용하는 경우 하이브리드 트래픽 흐름을 검사하기 위해 Azure Firewall 통해 프라이빗 피어링 트래픽을 전달하도록 UDR을 구성합니다.
관련된 문서
- 허브-스포크 네트워크 토폴로지: Azure Firewall 배포하는 허브 가상 네트워크입니다.
- 아웃바운드 인터넷 액세스: Azure Firewall 및 NAT 게이트웨이를 사용하는 아웃바운드 트래픽 제어 패턴
- Web Application Firewall: Azure Firewall 네트워크 수준 검사를 보완하는 계층 7 HTTP/S 보호입니다.
- DNS 보안 및 개인 이름 확인: FQDN 기반 규칙을 사용하도록 설정하는 DNS 프록시 구성입니다.
- Azure 네트워크 보안이란 무엇인가요?: Azure Firewall, DDoS Protection, Web Application Firewall을 비교하는 개요 허브입니다.
자세히 알아보기
- Azure Firewall 설명서
- Azure Firewall 기능
- Azure Firewall 프리미엄 기능
- Azure Firewall Manager 개요
- Azure Firewall 배포 및 구성
- Azure Firewall 가격 책정
다음 단계
팁 (조언)
직접 탐색하시겠습니까? 개요 탐색기로 돌아가서 기능별로 다음 문서를 찾습니다.
리프트 앤 시프트 과정의 다음 단계:
마이그레이션된 네트워크에 대한 모니터링 설정: 방화벽을 구성한 후 Network Watcher 연결 및 성능의 유효성을 검사합니다.
현대화 과정의 다음 단계:
WAF를 사용하여 웹 애플리케이션 보호: 고객용 웹앱에 대한 Front Door 또는 Application Gateway에 Web Application Firewall 추가합니다.
멀티클라우드 여정의 다음 단계:
멀티클라우드 모니터링 설정: 멀티클라우드 환경은 운영 측면에서 문제를 진단하고 해결하기가 더 어렵습니다. 모니터링은 선택 사항이 아니라 필수입니다.