IP 기반 ACL(액세스 제어 목록)이란?

Azure 서비스 태그는 Azure의 네트워크 보안 관리를 간소화하기 위해 2018년에 도입되었습니다. 서비스 태그는 특정 Azure 서비스와 연결된 IP 주소 접두사 그룹을 나타내며 NSG(네트워크 보안 그룹), Azure Firewall 및 UDR(사용자 정의 경로)에서 사용할 수 있습니다. 서비스 태그의 목적은 IP 기반 ACL 사용하도록 설정을 간소화하는 것이지만 이것이 구현되는 유일한 보안 조치가 되어서는 안 됩니다.

Azure의 서비스 태그에 대한 자세한 내용은 서비스 태그를 참조하세요.

배경

권장 사항 및 표준 절차 중 하나는 ACL(액세스 제어 목록)을 사용하여 유해한 트래픽으로부터 환경을 보호하는 것입니다. 액세스 목록은 기준과 작업에 대한 문입니다. 기준은 IP 주소와 같이 일치시킬 패턴을 정의합니다. 작업은 허용 또는 거부와 같이 수행해야 하는 예상 작업이 무엇인지 나타냅니다. 이러한 기준과 작업은 포트와 IP를 기반으로 네트워크 트래픽에 대해 설정할 수 있습니다. 포트 및 IP를 기반으로 하는 TCP(Transmission Control Protocol) 대화는 5튜플로 식별됩니다.

튜플에는 다섯 가지 요소가 있습니다.

• 프로토콜(TCP)

• 원본 IP 주소(패킷을 보낸 IP)

• 원본 포트(패킷을 보내는 데 사용된 포트)

• 대상 IP 주소(패킷이 이동해야 하는 위치)

• 대상 포트

IP ACL을 설정할 때 네트워크 트래버스를 허용하고 다른 모든 주소는 차단할 IP 주소 목록을 설정하게 됩니다. 또한 이러한 정책은 IP 주소뿐만 아니라 포트에도 적용됩니다.

IP 기반 ACL은 네트워크 디바이스부터 방화벽까지 네트워크의 다양한 수준에서 설정할 수 있습니다. IP ACL은 서비스 거부 공격을 차단하고 트래픽을 수신할 수 있는 애플리케이션과 포트를 정의하는 등 네트워크 보안 위험을 줄이는 데 유용합니다. 예를 들어, 웹 서비스를 보호하기 위해 웹 트래픽만 허용하고 다른 모든 트래픽은 차단하도록 ACL을 만들 수 있습니다.

Azure 및 서비스 태그

Azure 내의 IP 주소에는 보안 위협에 대한 추가 보호 계층을 빌드하기 위해 기본적으로 보호 기능이 사용하도록 설정되어 있습니다. 이러한 보호에는 통합 DDoS 보호 및 RPKI(리소스 공개 키 인프라) 사용과 같은 에지에서의 보호가 포함됩니다. RPKI는 암호화 신뢰를 사용하도록 설정하여 인터넷 라우팅 인프라의 보안을 개선하도록 설계된 프레임워크입니다. RPKI는 다른 누구도 인터넷에서 Microsoft IP 공간을 알리려고 시도하지 않도록 Microsoft 네트워크를 보호합니다.

많은 고객이 방어 전략의 일환으로 서비스 태그를 사용하도록 설정합니다. 서비스 태그는 IP 범위로 Azure 서비스를 식별하는 레이블입니다. 서비스 태그의 값은 접두사 목록이 자동으로 관리된다는 것입니다. 자동 관리를 통해 개별 IP 주소를 수동으로 유지 관리하고 추적할 필요성이 줄어듭니다. 서비스 태그의 자동 유지 관리를 통해 서비스가 중복성 및 개선된 보안 기능을 제공하도록 제공 사항을 개선하므로 즉시 이점을 활용할 수 있습니다. 서비스 태그는 필요한 수동 터치 횟수를 줄이고 서비스 트래픽이 항상 정확하도록 보장합니다. NSG 또는 UDR의 일부로 서비스 태그를 사용하도록 설정하면 사용자에게 트래픽을 보낼 수 있는 서비스 태그를 지정하여 IP 기반 ACL이 사용하도록 설정됩니다.

제한 사항

IP 기반 ACL에만 의존할 때의 한 가지 과제는 RPKI가 구현되지 않으면 IP 주소가 위조될 수 있다는 것입니다. Azure는 자동으로 RPKI 및 DDoS 보호를 적용하여 IP 스푸핑을 완화합니다. IP 스푸핑은 신뢰할 수 있다고 생각했던 IP가 더 이상 신뢰해야 할 IP가 아닌 악성 작업의 범주입니다. 신뢰할 수 있는 원본인 것처럼 가장하기 위해 IP 주소를 사용함으로써 해당 트래픽은 컴퓨터, 디바이스 또는 네트워크에 대한 액세스 권한을 얻습니다.

알려진 IP 주소가 반드시 안전하거나 신뢰할 수 있다는 의미는 아닙니다. IP 스푸핑은 네트워크 계층뿐만 아니라 애플리케이션 내에서도 발생할 수 있습니다. HTTP 헤더의 취약성으로 인해 해커가 보안 이벤트로 이어지는 페이로드를 삽입할 수 있습니다. 유효성 검사 계층은 네트워크뿐만 아니라 애플리케이션 내에서도 발생해야 합니다. 사이버 공격이 발전함에 따라 신뢰의 철학을 빌드하되 검증이 필요합니다.

향후 계획

모든 서비스는 서비스 태그에 IP 접두사의 역할과 의미를 문서화합니다. 서비스의 성격과 서비스가 보내는 트래픽을 고려하지 않고 서비스 태그만으로는 트래픽을 보호하기에 충분하지 않습니다.

서비스의 IP 접두사 및 서비스 태그에는 서비스 자체를 넘어서는 트래픽과 사용자가 있을 수 있습니다. Azure 서비스가 고객이 제어할 수 있는 대상을 허용하는 경우 고객은 동일한 Azure 서비스의 다른 사용자가 제어하는 트래픽을 실수로 허용하는 것입니다. 활용하려는 각 서비스 태그의 의미를 이해하면 위험을 이해하고 필요한 추가 보호 계층을 식별하는 데 도움이 됩니다.

IP 주소에만 의존하기보다는 트래픽에 대한 인증/권한 부여를 구현하는 것이 항상 모범 사례입니다. 헤더를 포함하여 클라이언트가 제공한 데이터의 유효성 검사를 통해 스푸핑에 대한 보호 수준을 한 단계 더 높일 수 있습니다. AFD(Azure Front Door)에는 헤더를 평가하여 확장된 보호 기능이 포함되어 있으며 헤더가 애플리케이션 및 식별자와 일치하는지 확인합니다. Azure Front Door의 확장된 보안에 대한 자세한 내용은 Azure Front Door 원본에 대한 트래픽 보안을 참조하세요.

요약

서비스 태그와 같은 IP 기반 ACL은 네트워크 트래픽을 제한함으로써 우수한 보안 방어 수단이 되지만 악의적인 트래픽에 대한 유일한 방어 계층이 되어서는 안 됩니다. 서비스 태그 외에 Private Link, Virtual Network 주입 등 Azure에서 사용할 수 있는 기술을 구현하면 보안 태세가 개선됩니다. Private Link 및 Virtual Network 주입에 대한 자세한 내용은 Azure Private Link 및 Virtual Network에 전용 Azure 서비스 배포를 참조하세요.