[Azure] Azure Front Door 보안 강화 (Service Tag + AFID 기반 백엔드 보호 전략)

Azure Front Door(AFD)는 전 세계 POP(Point of Presence)를 기반으로 고성능 글로벌 트래픽 라우팅과 웹 애플리케이션 보호 기능을 제공한다. 그러나 백엔드 리소스(App Service, VM, AKS 등)가 적절히 보호되지 않는다면 외부 공격자가 직접 백엔드 엔드포인트로 접근하는 상황이 발생할 수 있다.

이 문제를 해결하기 위해 Microsoft는 공식 문서에서 Service Tag + AFID(Azure Front Door ID) 조합을 사용한 백엔드 보호 구성을 **모범 사례(Best Practice)**로 제시하고 있다. 이 방법은 네트워크 계층과 애플리케이션 계층을 모두 보호하여 Zero Trust 기반의 강력한 보안 구조를 완성한다.

본 문서는 AFD 백엔드를 보호하기 위한 최적의 구성 요소와 구현 방법을 상세히 설명한다.

---

1. Azure Front Door 백엔드 보호가 필요한 이유

AFD는 L7 글로벌 트래픽을 처리하지만, 백엔드 리소스가 별도 보호 없이 인터넷에 노출되어 있다면 다음과 같은 위험을 초래한다.

1) 공격자가 AFD를 우회하고 백엔드로 직접 접근

AFD WAF를 거치기 때문에 차단될 공격도 백엔드 직접 호출 시 차단되지 않을 수 있다.

2) 특정 AFD 인스턴스가 아닌 다른 고객의 AFD에서도 백엔드 접근 가능

Service Tag만 사용할 경우, 모든 AFD 인프라의 트래픽이 백엔드에 도달할 수 있다.

3) IP 기반 접근 제어의 유지보수 비용 증가

Azure POP IP는 주기적으로 변경되므로 이를 계속 업데이트하는 것은 비효율적이다.

이러한 이유로 Microsoft는 서비스 태그로 네트워크를 제한하고, AFID로 내 AFD 인스턴스만 허용하는 이중 보안 구조를 권고한다.

---

2. Service Tag 기반 보호의 역할

Azure는 특정 서비스에서 사용되는 공용 IP 범위를 자동 관리하는 Service Tag 기능을 제공한다.

AFD 관련 주요 태그는 다음과 같다.

목적 서비스 태그

AFD가 백엔드로 트래픽을 전달할 때 사용하는 IP	AzureFrontDoor.Backend
AFD POP 프런트엔드 IP	AzureFrontDoor.Frontend

NSG에서 AzureFrontDoor.Backend만 허용하면 아래 효과를 얻을 수 있다.

• 인터넷 트래픽 직접 접근 차단
• Azure Front Door POP 프록시로부터의 트래픽만 허용
• IP 변경 시 자동 반영

하지만 “내 AFD 인스턴스가 아닌 다른 AFD도 모두 허용된다는 구조적 한계”가 존재한다.

---

3. AFID(Azure Front Door ID)의 개념

AFID는 **각 Azure Front Door 프로필이 보유한 고유 식별자(ID)**다.

AFD는 백엔드로 요청을 전달할 때 항상 다음 헤더를 포함한다.

X-Azure-FDID: <FrontDoor-Profile-ID>

백엔드는 이 헤더를 확인해 “해당 요청이 내 Front Door 인스턴스에서 온 것인지”를 판단할 수 있다.

Microsoft 공식 모범 사례

문서: https://learn.microsoft.com/azure/frontdoor/secure-backend

문서에서는 다음과 같이 명시되어 있다.

• Service Tag 기반 네트워크 제한은 필수
• AFID 기반 추가 검증을 통해 특정 AFD만 백엔드 접근 허용
• 두 방법을 결합하는 것이 가장 강력한 보안 모델

---

4. Service Tag + AFID 조합이 최적의 보안 전략인 이유

보안 영역 적용 기술 효과

네트워크 계층(L3/L4)	Service Tag (AzureFrontDoor.Backend)	AFD 이외의 인터넷 접근 차단
애플리케이션 계층(L7)	AFID(Front Door 고유 ID)	내 AFD에서 온 요청만 허용

이 두 가지 조합을 적용하면 다음과 같은 보안 이점을 제공한다.

1) 백엔드가 오직 하나의 Front Door 인스턴스와만 연결

다른 고객의 AFD 또는 임의의 트래픽은 모두 차단된다.

2) WAF 우회 공격 방지

공격자가 Backend URL을 직접 호출하는 방식으로 방어 우회 불가.

3) Azure IP 변경에 자동 대응

Service Tag는 Microsoft가 자동 관리하므로 NSG 수정이 필요 없다.

4) Zero Trust 아키텍처 구축

L3~L7에서 모두 "명시적 허용" 정책만 유지하게 된다.

---

5. 구현 방법

5.1 NSG에서 AFD Service Tag 허용

az network nsg rule create \\
  --resource-group RG-NET \\
  --nsg-name nsg-backend \\
  --name Allow-AFD-Backend \\
  --priority 100 \\
  --direction Inbound \\
  --access Allow \\
  --source-address-prefixes AzureFrontDoor.Backend \\
  --protocol Tcp \\
  --destination-port-ranges 443

5.2 백엔드에서 AFID 검증 적용

백엔드는 X-Azure-FDID 값을 검사하여 허용된 Front Door ID와 일치하지 않으면 요청을 차단한다.

Nginx 예시:

map $http_x_azure_fdid $allowed_fd {
    default 0;
    "<AFD-PROFILE-ID>" 1;
}

server {
    if ($allowed_fd = 0) {
        return 403;
    }
}

App Service는 Access Restriction에서 AFID 검증을 기본 제공한다.

---

6. 리소스별 AFID 적용 가능 여부

서비스 지원 여부 구성 방식

Azure App Service	지원	Access Restrictions → Front Door ID 입력
Azure Storage	지원	Origin Protection 기능 사용
Azure AKS	지원	Ingress controller에서 AFID 검증 구현
VM / VMSS	지원	Nginx/Apache 또는 애플리케이션 코드에서 헤더 검증

특히 Storage Account는 “Front Door Origin Protection”이 기본 기능으로 제공되어 AFD 외의 모든 접근을 자동 차단할 수 있다.

---

7. 보안 아키텍처 요약

Client → Azure Front Door → Backend Resource
                                ↑
                      AFID header validation

• NSG: AzureFrontDoor.Backend만 허용
• 앱: X-Azure-FDID 값 검증
• Storage/App Service: Origin Protection 또는 Access Restriction 사용

이 구조는 AFD 뒤에 있는 모든 백엔드 보호 방식 중 가장 신뢰도가 높은 구성이다.

---

8. 결론

Azure Front Door를 사용하는 환경에서 백엔드 보호를 강화하려면 다음 두 가지를 반드시 적용해야 한다.

1) Service Tag 기반 네트워크 제어(필수)

• AzureFrontDoor.Backend만 허용
• 다른 모든 공용 IP 차단

2) AFID 기반 애플리케이션 계층 검증(권장 → 사실상 필수)

• 특정 Front Door 인스턴스만 백엔드 접근 가능
• WAF 우회 공격 완전 차단

Microsoft에서도 이를 공식적으로 모범 사례로 발표하고 있으며, 현재 Azure 환경에서 가장 안전하고 유지 보수가 최소화되는 L7 보호 방식이다.