네트워킹 및 연결에 대한 권장 사항

아티클
11/15/2023

이 Azure Well-Architected Framework 보안 검사 목록 권장 사항에 적용됩니다.

SE:05	수신 흐름과 송신 흐름 모두에서 네트워크 트래픽을 격리, 필터링 및 제어합니다. 동서 및 남북 트래픽에서 사용 가능한 모든 네트워크 경계에서 지역화된 네트워크 제어를 사용하여 심층 방어 원칙을 적용합니다.

이 가이드에서는 네트워크 디자인에 대한 권장 사항을 설명합니다. 아키텍처의 다양한 깊이에서 네트워크 경계를 넘나드는 악의적 사용자를 필터링, 차단 및 검색할 수 있는 보안 컨트롤 에 초점을 맞춥니다.

네트워크 기반 액세스 제어 측정값을 구현하여 ID 제어를 강화할 수 있습니다. ID 기반 액세스 제어와 함께 네트워크 보안은 자산을 보호하기 위한 높은 우선 순위입니다. 적절한 네트워크 보안 제어는 위협을 감지 및 포함하고 공격자가 워크로드에 진입하지 못하도록 방지할 수 있는 심층 방어 요소를 제공할 수 있습니다.

정의

용어	정의
동-서 트래픽	신뢰할 수 있는 경계 내에서 이동하는 네트워크 트래픽입니다.
송신 흐름	아웃바운드 워크로드 트래픽.
적대적인 네트워크	워크로드의 일부로 배포되지 않은 네트워크입니다. 적대적인 네트워크는 위협 벡터로 간주됩니다.
수신 흐름	인바운드 워크로드 트래픽.
네트워크 필터링	지정된 규칙에 따라 네트워크 트래픽을 허용하거나 차단하는 메커니즘입니다.
네트워크 구분 또는 격리	경계에 보안 컨트롤이 적용된 소규모 격리 세그먼트로 네트워크를 나누는 전략입니다. 이 기술은 인터넷과 같은 적대적인 네트워크로부터 리소스를 보호하는 데 도움이 됩니다.
네트워크 변환	네트워크 패킷을 변경하여 가릴 수 있는 메커니즘입니다.
남북 교통	신뢰할 수 있는 경계에서 잠재적으로 적대적인 외부 네트워크로 이동하는 네트워크 트래픽, 그 반대의 경우도 마찬가지입니다.

주요 디자인 전략

네트워크 보안 은 모호성을 사용하여 적대적인 네트워크로부터 워크로드 자산을 보호합니다. 네트워크 경계 뒤에 있는 리소스는 경계 컨트롤이 트래픽을 앞으로 이동하는 것이 안전한 것으로 표시할 때까지 숨겨집니다. 네트워크 보안 디자인은 세 가지 기본 전략을 기반으로 합니다.

세그먼트. 이 기술은 경계를 추가하여 별도의 네트워크에서 트래픽을 격리합니다. 예를 들어 애플리케이션 계층을 주고 받고 있는 트래픽은 다른 보안 요구 사항이 있는 다른 계층과 통신하기 위해 경계를 통과합니다. 세분화 계층은 심층 방어 접근 방식을 실제화합니다.

가장 중요한 보안 경계는 애플리케이션과 공용 네트워크 간의 네트워킹 에지입니다. 적대적인 네트워크를 격리하기 위한 경계를 설정하도록 이 경계를 명확하게 정의하는 것이 중요합니다. 이 경계는 첫 번째 방어선이므로 이 에지의 컨트롤은 매우 효과적이어야 합니다.

가상 네트워크는 논리적 경계를 제공합니다. 의도적으로 피어링을 통해 경계가 끊어지지 않는 한 가상 네트워크는 다른 가상 네트워크와 통신할 수 없습니다. 아키텍처는 강력한 플랫폼 제공 보안 조치를 활용해야 합니다.

가상 네트워크 내에서 조각된 서브넷과 같은 다른 논리적 경계를 사용할 수도 있습니다. 서브넷의 이점은 서브넷을 사용하여 격리 경계 내에 있고 유사한 보안 보증이 있는 리소스를 그룹화할 수 있다는 것입니다. 그런 다음 트래픽을 필터링하도록 경계에서 컨트롤을 구성할 수 있습니다.
필터. 이 전략은 경계에 들어가는 트래픽이 예상되고 허용되며 안전하도록 하는 데 도움이 됩니다. Zero-Trust 관점에서 필터링은 네트워크 수준에서 사용 가능한 모든 데이터 요소를 명시적으로 확인합니다. 경계에 규칙을 배치하여 특정 조건에 대해 검사 수 있습니다.

예를 들어 헤더 수준에서 규칙은 트래픽이 예상된 위치에서 발생하거나 예상 볼륨을 가지고 있는지 확인할 수 있습니다. 그러나 이러한 검사만으로는 충분하지 않습니다. 트래픽이 예상된 특성을 나타내더라도 페이로드는 안전하지 않을 수 있습니다. 유효성 검사에서 SQL 삽입 공격이 표시될 수 있습니다.
변환. 경계에서 패킷을 보안 조치로 변경합니다. 예를 들어 HTTP 헤더를 제거하여 노출 위험을 제거할 수 있습니다. 또는 한 지점에서 TLS(전송 계층 보안)를 해제하고 더 엄격하게 관리되는 인증서를 사용하여 다른 홉에서 다시 설정할 수 있습니다.

트래픽 흐름 분류

흐름을 분류하는 첫 번째 단계는 워크로드 아키텍처의 도형을 연구하는 것입니다. 도식에서 워크로드의 기능 유틸리티 및 운영 측면과 관련하여 흐름의 의도와 특성을 결정 합니다. 흐름을 분류하는 데 도움이 되도록 다음 질문을 사용합니다.

워크로드가 외부 네트워크와 통신해야 하는 경우 해당 네트워크에 필요한 수준의 근접성을 유지해야 하나요?
예상 프로토콜, 패킷의 원본 및 모양과 같은 흐름의 네트워크 특성은 무엇인가요? 네트워킹 수준에서 규정 준수 요구 사항이 있나요?

트래픽 흐름을 분류하는 방법에는 여러 가지가 있습니다. 다음 섹션에서는 일반적으로 사용되는 조건에 대해 설명합니다.

외부 네트워크의 가시성

공용. 공용 인터넷에서 애플리케이션 및 기타 구성 요소에 연결할 수 있는 경우 워크로드는 공용에 연결됩니다. 애플리케이션은 하나 이상의 공용 IP 주소 및 DNS(공용 도메인 이름 시스템) 서버를 통해 노출됩니다.
프라이빗. 워크로드는 VPN(가상 사설망)과 같은 프라이빗 네트워크를 통해서만 액세스할 수 있는 경우 프라이빗입니다. 하나 이상의 개인 IP 주소를 통해서만 노출되며 잠재적으로 프라이빗 DNS 서버를 통해서만 노출됩니다.

개인 네트워크에서는 공용 인터넷에서 워크로드까지 시야가 없습니다. 게이트웨이의 경우 부하 분산 장치 또는 방화벽을 사용할 수 있습니다. 이러한 옵션은 보안 보증을 제공할 수 있습니다.

퍼블릭 워크로드를 사용하더라도 최대한 많은 워크로드를 비공개로 유지하려고 노력합니다. 이 방법은 패킷이 공용 네트워크에서 도착하면 프라이빗 경계를 통과하도록 강제합니다. 해당 경로의 게이트웨이는 역방향 프록시 역할을 하여 전환 지점으로 작동할 수 있습니다.

트래픽 방향

수신. 수신은 워크로드 또는 해당 구성 요소로 이동하는 인바운드 트래픽입니다. 수신을 보호하려면 이전의 주요 전략 집합을 적용합니다. 트래픽 원본의 내용과 예상, 허용 및 안전 여부를 결정합니다. 퍼블릭 클라우드 공급자 IP 주소 범위를 검색하는 공격자는 수신을 검사 않거나 기본 네트워크 보안 조치를 구현하지 않으면 방어에 성공적으로 침투할 수 있습니다.
송신. 송신은 워크로드 또는 해당 구성 요소에서 멀리 흐르는 아웃바운드 트래픽입니다. 송신을 검사 트래픽이 향하는 위치와 대상이 예상, 허용 및 안전한지 여부를 결정합니다. 대상이 악의적이거나 데이터 반출 위험과 관련될 수 있습니다.

워크로드의 공용 인터넷 근접성을 고려하여 노출 수준을 확인할 수도 있습니다. 예를 들어 애플리케이션 플랫폼은 일반적으로 공용 IP 주소를 제공합니다. 워크로드 구성 요소는 솔루션의 얼굴입니다.

영향 범위

남북. 워크로드 네트워크와 외부 네트워크 간에 흐르는 트래픽은 남북 트래픽입니다. 이 트래픽은 네트워크의 가장자리를 교차합니다. 외부 네트워크는 공용 인터넷, 회사 네트워크 또는 제어 scope 외부에 있는 다른 네트워크일 수 있습니다.

수신 및 송신은 모두 남북 트래픽일 수 있습니다.

예를 들어 허브-스포크 네트워크 토폴로지의 송신 흐름을 고려합니다. 허브가 외부 네트워크가 되도록 워크로드의 네트워킹 에지를 정의할 수 있습니다. 이 경우 스포크 가상 네트워크의 아웃바운드 트래픽은 남북 트래픽입니다. 그러나 제어 영역 내에서 허브 네트워크를 고려하면 다음 홉이 잠재적으로 적대적인 인터넷이기 때문에 남북 트래픽이 허브의 방화벽으로 확장됩니다.
동서. 워크로드 네트워크 내에서 흐르는 트래픽은 동서 트래픽입니다. 이러한 유형의 트래픽은 워크로드의 구성 요소가 서로 통신할 때 발생합니다. 예를 들어 n 계층 애플리케이션의 계층 간 트래픽이 있습니다. 마이크로 서비스에서 서비스 간 통신은 동서 트래픽입니다.

심층 방어를 제공하려면 각 홉에 포함되거나 패킷이 내부 세그먼트를 교차할 때 사용하는 보안 어포던스의 엔드투엔드 제어를 유지 관리합니다. 위험 수준이 다르면 다양한 위험 수정 방법이 필요합니다.

위의 다이어그램은 프라이빗 클라우드의 네트워크 방어를 심층적으로 보여 줍니다. 이 다이어그램에서 공용 IP 주소 공간과 개인 IP 주소 공간 간의 경계는 퍼블릭 클라우드 다이어그램보다 워크로드에서 훨씬 더 멀리 떨어져 있습니다. 여러 계층은 공용 IP 주소 공간에서 Azure 배포를 분리합니다.

참고

ID는 항상 기본 경계입니다. 액세스 관리는 네트워킹 흐름에 적용해야 합니다. 네트워크 구성 요소 간에 Azure RBAC(역할 기반 액세스 제어)를 사용할 때 관리 ID를 사용합니다.

흐름을 분류한 후 세분화 연습을 수행하여 네트워크 세그먼트의 통신 경로에서 방화벽 삽입 지점을 식별합니다. 모든 세그먼트 및 모든 트래픽 유형에서 네트워크 방어를 심층 설계할 때 모든 지점에서 위반을 가정합니다. 사용 가능한 모든 경계에서 다양한 지역화된 네트워크 컨트롤의 조합을 사용합니다. 자세한 내용은 구분 전략을 참조하세요.

에지에 방화벽 적용

인터넷 에지 트래픽은 남북 트래픽이며 수신 및 송신을 포함합니다. 위협을 감지하거나 차단하려면 에지 전략은 인터넷에서 가능한 한 많은 공격을 완화해야 합니다.

송신의 경우 트래픽에 대한 향상된 감독, 거버넌스 및 제어 를 제공하는 단일 방화벽을 통해 모든 인터넷 바인딩 트래픽을 보냅니다. 수신의 경우 인터넷의 모든 트래픽이 NVA(네트워크 가상 어플라이언스) 또는 웹 애플리케이션 방화벽을 통과하도록 합니다.

방화벽은 일반적으로 organization 지역별로 배포되는 싱글톤입니다. 결과적으로 워크로드 간에 공유되고 중앙 팀이 소유합니다. 사용하는 NVA가 워크로드의 요구 사항을 지원하도록 구성되어 있는지 확인합니다.
가능한 한 Azure 네이티브 컨트롤을 사용하는 것이 좋습니다.

네이티브 컨트롤 외에도 고급 또는 특수 기능을 제공하는 파트너 NVA를 고려할 수도 있습니다. 파트너 방화벽 및 웹 애플리케이션 방화벽 공급업체 제품은 Azure Marketplace 사용할 수 있습니다.

파트너 솔루션이 아닌 네이티브 기능을 사용하기로 결정하는 것은 organization 경험과 요구 사항에 따라 결정되어야 합니다.

절충: 파트너 기능은 정교하지만 일반적으로 일반적이지 않은 공격으로부터 보호할 수 있는 고급 기능을 제공하는 경우가 많습니다. 이러한 솔루션은 클라우드의 패브릭 컨트롤러와 통합되지 않으므로 파트너 솔루션의 구성은 복잡하고 취약할 수 있습니다. 비용 관점에서 네이티브 컨트롤은 파트너 솔루션보다 저렴하기 때문에 선호됩니다.

고려하는 모든 기술 옵션은 수신 흐름과 송신 흐름 모두에 대한 보안 제어 및 모니터링을 제공해야 합니다. Azure에 사용할 수 있는 옵션을 보려면 이 문서의 Edge 보안 섹션을 참조하세요.

가상 네트워크 및 서브넷 보안 설계

프라이빗 클라우드의 주요 목표는 공용 인터넷에서 리소스를 모호하게 하는 것입니다. 이 목표를 달성하는 방법에는 여러 가지가 있습니다.

가상 네트워크를 사용하여 수행할 수 있는 개인 IP 주소 공간으로 이동합니다. 자체 프라이빗 네트워크 내에서도 네트워크 시야를 최소화합니다.
워크로드를 적게 노출하는 데 사용하는 공용 DNS 항목 수를 최소화합니다.
수신 및 송신 네트워크 흐름 제어를 추가합니다. 신뢰할 수 없는 트래픽을 허용하지 않습니다.

구분 전략

네트워크 가시성을 최소화하려면 네트워크를 분할하고 최소 권한 네트워크 컨트롤로 시작합니다. 세그먼트를 라우팅할 수 없는 경우 액세스할 수 없습니다. 네트워크 액세스를 통해 서로 통신해야 하는 세그먼트만 포함하도록 scope 확장합니다.

서브넷을 만들어 가상 네트워크를 분할할 수 있습니다. 나누기 기준은 의도적이어야 합니다. 서브넷 내에 서비스를 배치할 때 해당 서비스가 서로를 볼 수 있는지 확인합니다.

여러 요인에 따라 세분화를 기반으로 할 수 있습니다. 예를 들어 전용 세그먼트에 다른 애플리케이션 계층을 배치할 수 있습니다. 또 다른 방법은 잘 알려진 프로토콜을 사용하는 일반적인 역할 및 함수를 기반으로 서브넷을 계획하는 것입니다.

자세한 내용은 구분 전략을 참조하세요.

서브넷 방화벽

각 서브넷의 인바운드 및 아웃바운드 트래픽을 검사하는 것이 중요합니다. 이 문서의 앞부분에서 설명한 세 가지 기본 전략을 주요 디자인 전략에서 사용합니다. 흐름이 예상, 허용 및 안전한지 확인합니다. 이 정보를 확인하려면 트래픽의 프로토콜, 원본 및 대상을 기반으로 하는 방화벽 규칙을 정의 합니다.

Azure에서는 네트워크 보안 그룹에서 방화벽 규칙을 설정합니다. 자세한 내용은 이 문서의 네트워크 보안 그룹 섹션을 참조하세요.

서브넷 디자인의 예제는 Azure Virtual Network 서브넷을 참조하세요.

구성 요소 수준에서 컨트롤 사용

네트워크의 가시성을 최소화한 후 네트워크 관점에서 Azure 리소스를 매핑하고 흐름을 평가합니다. 다음과 같은 유형의 흐름이 가능합니다.

아키텍처 디자인에 따라 계획된 트래픽 또는 서비스 간의 의도적인 통신. 예를 들어 아키텍처에서 Azure Functions Azure Service Bus 메시지를 끌어오라고 권장하는 경우 트래픽을 계획했습니다.
관리 트래픽 또는 서비스 기능의 일부로 발생하는 통신입니다. 이 트래픽은 디자인의 일부가 아니며 제어할 수 없습니다. 관리되는 트래픽의 예로는 아키텍처의 Azure 서비스와 Azure 관리 평면 간의 통신이 있습니다.

계획된 트래픽과 관리 트래픽을 구분하면 지역화된 컨트롤 또는 서비스 수준 컨트롤을 빌드하는 데 도움이 됩니다. 각 홉에서 원본 및 대상을 잘 이해합니다. 특히 데이터 평면이 노출되는 방식을 이해합니다.

시작점으로 각 서비스가 인터넷에 노출되는지 여부를 결정합니다. 이 경우 액세스를 제한하는 방법을 계획합니다. 그렇지 않은 경우 가상 네트워크에 배치합니다.

서비스 방화벽

서비스가 인터넷에 노출될 것으로 예상되는 경우 대부분의 Azure 리소스에 사용할 수 있는 서비스 수준 방화벽을 활용합니다. 이 방화벽을 사용하는 경우 액세스 패턴에 따라 규칙을 설정할 수 있습니다. 자세한 내용은 이 문서의 Azure 서비스 방화벽 섹션을 참조하세요.

참고

구성 요소가 서비스가 아닌 경우 네트워크 수준 방화벽 외에 호스트 기반 방화벽을 사용합니다. VM(가상 머신)은 서비스가 아닌 구성 요소의 예입니다.

PaaS(Platform as a Service) 서비스에 연결

프라이빗 엔드포인트를 사용하여 PaaS 서비스에 대한 액세스를 보호하는 것이 좋습니다. 프라이빗 엔드포인트에는 가상 네트워크의 개인 IP 주소가 할당됩니다. 엔드포인트를 사용하면 네트워크의 다른 리소스가 개인 IP 주소를 통해 PaaS 서비스와 통신할 수 있습니다.

PaaS 서비스와의 통신은 서비스의 공용 IP 주소 및 DNS 레코드를 사용하여 이루어집니다. 이러한 통신은 인터넷을 통해 발생합니다. 해당 통신을 비공개로 만들 수 있습니다.

PaaS 서비스에서 서브넷 중 하나로의 터널은 프라이빗 채널을 만듭니다. 모든 통신은 구성 요소의 개인 IP 주소에서 해당 서브넷의 프라이빗 엔드포인트로 이동한 다음 PaaS 서비스와 통신합니다.

이 예제에서 왼쪽의 이미지는 공개적으로 노출된 엔드포인트의 흐름을 보여 줍니다. 오른쪽에서 해당 흐름은 프라이빗 엔드포인트를 사용하여 보호됩니다.

자세한 내용은 이 문서의 프라이빗 엔드포인트 섹션을 참조하세요.

참고

서비스 방화벽과 함께 프라이빗 엔드포인트를 사용하는 것이 좋습니다. 서비스 방화벽은 들어오는 인터넷 트래픽을 차단한 다음 프라이빗 엔드포인트를 사용하는 내부 사용자에게 서비스를 비공개로 노출합니다.

프라이빗 엔드포인트를 사용하는 또 다른 이점은 아웃바운드 트래픽을 위해 방화벽에서 포트를 열 필요가 없다는 것입니다. 프라이빗 엔드포인트는 공용 인터넷용 포트의 모든 아웃바운드 트래픽을 잠급니다. 연결은 네트워크 내의 리소스로 제한됩니다.

절충: Azure Private Link 처리되는 인바운드 및 아웃바운드 데이터에 대한 미터가 있는 유료 서비스입니다. 프라이빗 엔드포인트에 대해서도 요금이 청구됩니다.

DDoS(분산 서비스 거부) 공격으로부터 보호

DDoS 공격은 애플리케이션의 리소스를 소진하여 합법적인 사용자가 애플리케이션을 사용할 수 없도록 하려고 시도합니다. DDoS 공격은 인터넷을 통해 공개적으로 연결할 수 있는 모든 엔드포인트를 대상으로 할 수 있습니다.

DDoS 공격은 일반적으로 원본을 정확히 파악하고 차단하기 어렵게 만드는 시스템 리소스의 대규모 광범위하고 지리적으로 분산된 남용입니다.

이러한 공격으로부터 보호하는 데 도움이 되는 Azure 지원 이 문서의 Azure DDoS Protection 섹션을 참조하세요.

Azure 촉진

다음 Azure 서비스를 사용하여 네트워크에 심층 방어 기능을 추가할 수 있습니다.

Azure Virtual Network

Virtual Network Azure 리소스가 서로, 인터넷 및 온-프레미스 네트워크와 안전하게 통신하는 데 도움이 됩니다.

기본적으로 가상 네트워크의 모든 리소스는 인터넷과의 아웃바운드 통신에 참여할 수 있습니다. 그러나 인바운드 통신은 기본적으로 제한됩니다.

Virtual Network 트래픽 필터링 기능을 제공합니다. UDR(사용자 정의 경로) 및 방화벽 구성 요소를 사용하여 가상 네트워크 수준에서 액세스를 제한할 수 있습니다. 서브넷 수준에서 네트워크 보안 그룹을 사용하여 트래픽을 필터링할 수 있습니다.

Edge 보안

기본적으로 수신 및 송신은 모두 공용 IP 주소를 통해 흐릅니다. 서비스 또는 토폴로지에 따라 이러한 주소를 설정하거나 Azure에서 할당합니다. 다른 수신 및 송신 가능성에는 부하 분산 장치 또는 NAT(네트워크 주소 변환) 게이트웨이를 통한 트래픽 전달이 포함됩니다. 그러나 이러한 서비스는 트래픽 분산을 위한 것이며 반드시 보안을 위한 것은 아닙니다.

다음 기술을 선택하는 것이 좋습니다.

Azure Firewall. 네트워크 에지 및 허브 스포크 네트워크 및 가상 WAN과 같은 인기 있는 네트워크 토폴로지에서 Azure Firewall 사용할 수 있습니다. 일반적으로 트래픽이 인터넷으로 이동하기 전에 최종 보안 게이트 역할을 하는 송신 방화벽으로 Azure Firewall 배포합니다. Azure Firewall RDP(원격 데스크톱 프로토콜), SSH(Secure Shell Protocol) 및 FTP(파일 전송 프로토콜)와 같이 비 HTTP 및 비 HTTPS 프로토콜을 사용하는 트래픽을 라우팅할 수 있습니다. Azure Firewall 기능 집합에는 다음이 포함됩니다.
- DNAT(대상 네트워크 주소 변환) 또는 포트 전달.
- IDPS(침입 감지 및 방지 시스템) 서명 검색.
- 강력한 계층 3, 계층 4 및 FQDN(정규화된 도메인 이름) 네트워크 규칙
참고

대부분의 조직에는 트래픽이 NVA를 통해 흐르도록 강제하는 강제 터널링 정책이 있습니다.

가상 WAN 토폴로지를 사용하지 않는 경우 의 UDR을NextHopTypeInternet NVA의 개인 IP 주소에 배포해야 합니다. UDR은 서브넷 수준에서 적용됩니다. 기본적으로 서브넷-서브넷 트래픽은 NVA를 통해 흐르지 않습니다.

수신에 Azure Firewall 동시에 사용할 수도 있습니다. HTTP 및 HTTPS 트래픽을 라우팅할 수 있습니다. 상위 계층 SKU에서 Azure Firewall 페이로드 수준 검사를 구현할 수 있도록 TLS 종료를 제공합니다.

권장되는 방법은 다음과 같습니다.
- Azure Firewall 진단 설정을 사용하도록 설정하여 트래픽 흐름 로그, IDPS 로그 및 DNS 요청 로그를 수집합니다.
- 규칙에서 가능한 한 구체적이어야 합니다.
- 실용적인 경우 FQDN 서비스 태그를 사용하지 마세요. 그러나 이를 사용하는 경우 서비스의 모든 엔드포인트와 통신할 수 있는 지역별 변형을 사용합니다.
- IP 그룹을 사용하여 IP 그룹의 수명 동안 동일한 규칙을 공유해야 하는 원본을 정의합니다. IP 그룹은 구분 전략을 반영해야 합니다.
- 워크로드에 절대 송신 제어가 필요한 경우에만 인프라 FQDN 허용 규칙을 재정의합니다. 이 규칙을 재정의하면 Azure 플랫폼 요구 사항이 서비스에서 변경되므로 안정성이 손상됩니다.
절충: Azure Firewall 성능에 영향을 미칠 수 있습니다. 규칙 순서, 수량, TLS 검사 및 기타 요인으로 인해 상당한 대기 시간이 발생할 수 있습니다.

워크로드의 안정성에도 영향을 미칠 수 있습니다. 원본 SNAT(네트워크 주소 변환) 포트 소모가 발생할 수 있습니다. 이 문제를 해결하려면 필요에 따라 공용 IP 주소를 추가합니다.

위험: 송신 트래픽의 경우 Azure는 공용 IP 주소를 할당합니다. 이 할당은 외부 보안 게이트에 다운스트림 영향을 줄 수 있습니다.
Azure Web Application Firewall. 이 서비스는 인바운드 필터링을 지원하며 HTTP 및 HTTPS 트래픽만 대상으로 합니다.

OWASP(Open Worldwide Application Security Project)가 OWASP 상위 10개 문서에서 식별하는 위협과 같은 일반적인 공격에 대한 기본 보안을 제공합니다. 또한 Azure Web Application Firewall 속도 제한, SQL 삽입 규칙 및 사이트 간 스크립팅과 같은 계층 7에 중점을 둔 다른 보안 기능도 제공합니다.

대부분의 검사는 페이로드를 기반으로 하므로 Azure Web Application Firewall TLS 종료가 필요합니다.

Azure Web Application Firewall Azure Application Gateway 또는 Azure Front Door와 같은 라우터와 통합할 수 있습니다. 이러한 종류의 라우터에 대한 Azure Web Application Firewall 구현은 다를 수 있습니다.

Azure Firewall 및 Azure Web Application Firewall 상호 배타적인 선택이 아닙니다. 에지 보안 솔루션의 경우 다양한 옵션을 사용할 수 있습니다. 예제는 가상 네트워크에 대한 방화벽 및 Application Gateway 참조하세요.

네트워크 보안 그룹

네트워크 보안 그룹은 서브넷 또는 NIC(네트워크 인터페이스 카드) 수준에서 적용하는 계층 3 및 계층 4 방화벽입니다. 네트워크 보안 그룹은 기본적으로 생성되거나 적용되지 않습니다.

네트워크 보안 그룹 규칙은 서브넷 경계에서 들어오고 나가는 트래픽을 중지하는 방화벽 역할을 합니다. 네트워크 보안 그룹에는 지나치게 허용되는 기본 규칙 집합이 있습니다. 예를 들어 기본 규칙은 송신 관점에서 방화벽을 설정하지 않습니다. 수신의 경우 인바운드 인터넷 트래픽은 허용되지 않습니다.

규칙을 만들려면 기본 규칙 집합으로 시작합니다.

인바운드 트래픽 또는 수신의 경우:
- 직접, 피어링 및 VPN 게이트웨이 원본의 가상 네트워크 트래픽이 허용됩니다.
- Azure Load Balancer 상태 프로브가 허용됩니다.
- 다른 모든 트래픽이 차단됩니다.
아웃바운드 트래픽 또는 송신의 경우:
- 직접, 피어링 및 VPN 게이트웨이 대상에 대한 가상 네트워크 트래픽이 허용됩니다.
- 인터넷으로의 트래픽이 허용됩니다.
- 다른 모든 트래픽이 차단됩니다.

그런 다음, 다음 5가지 요소를 고려합니다.

프로토콜
원본 IP 주소
원본 포트
대상 IP 주소
대상 포트

FQDN에 대한 지원이 부족하면 네트워크 보안 그룹 기능이 제한됩니다. 워크로드에 특정 IP 주소 범위를 제공해야 하며 유지 관리가 어렵습니다.

그러나 Azure 서비스의 경우 서비스 태그를 사용하여 원본 및 대상 IP 주소 범위를 요약할 수 있습니다. 서비스 태그의 보안 이점은 사용자에게 불투명하고 책임이 Azure로 오프로드된다는 것입니다. 애플리케이션 보안 그룹을 대상 유형으로 할당하여 트래픽을 라우팅할 수도 있습니다. 이 유형의 명명된 그룹에는 인바운드 또는 아웃바운드 액세스 요구 사항이 비슷한 리소스가 포함되어 있습니다.

위험: 서비스 태그 범위는 매우 광범위하므로 가능한 가장 넓은 범위의 고객을 수용할 수 있습니다. 서비스 태그에 대한 업데이트 서비스의 변경 내용보다 뒤쳐집니다.

이전 이미지에서 네트워크 보안 그룹은 NIC에 적용됩니다. 인터넷 트래픽 및 서브넷-서브넷 트래픽이 거부됩니다. 네트워크 보안 그룹은 태그와 함께 VirtualNetwork 적용됩니다. 따라서 이 경우 피어링된 네트워크의 서브넷에 직접적인 시야가 있습니다. 태그의 광범위한 정의는 VirtualNetwork 보안에 상당한 영향을 미칠 수 있습니다.

서비스 태그를 사용하는 경우 가능하면 지역 버전(예: Storage.WestUS 대신)을 Storage사용합니다. 이 방법을 사용하면 특정 지역의 모든 엔드포인트로 scope 제한할 수 있습니다.

일부 태그는 인바운드 또는 아웃바운드 트래픽 전용입니다. 다른 형식은 두 형식 모두 에 대한 것입니다. 인바운드 태그는 일반적으로 와 같은 AzureFrontDoor.Backend모든 호스팅 워크로드 또는 Azure의 트래픽을 허용하여 과 같은 LogicAppsManagement서비스 런타임을 지원합니다. 마찬가지로 아웃바운드 태그를 사용하면 모든 호스팅 워크로드 또는 Azure의 트래픽이 서비스 런타임을 지원할 수 있습니다.

규칙의 범위를 가능한 한 많이 지정합니다. 다음 예제에서는 규칙이 특정 값으로 설정됩니다. 다른 유형의 트래픽은 거부됩니다.

정보 산업	예제
프로토콜	TCP(Transmission Control Protocol), UDP
원본 IP 주소	source-IP-address-range>: 4575/UDP에서 <서브넷으로 수신 허용
원본 포트	service-tag>에서 <서브넷으로의 수신 허용: 443/TCP
대상 IP 주소	서브넷에서 destination-IP-address-range>로 <송신 허용: 443/TCP
대상 포트	서브넷에서 서비스 태그>로 <송신 허용: 443/TCP

요약:

규칙을 만들 때는 정확해야 합니다. 애플리케이션이 작동하는 데 필요한 트래픽만 허용합니다. 다른 모든 것을 거부합니다. 이 방법은 네트워크 시야를 워크로드 작업을 지원하는 데 필요한 네트워크 흐름으로 제한합니다. 필요한 것보다 더 많은 네트워크 흐름을 지원하면 불필요한 공격 벡터가 발생하며 노출 영역이 확장됩니다.

트래픽을 제한한다고 해서 허용되는 흐름이 공격의 scope 벗어나는 것은 아닙니다. 네트워크 보안 그룹은 OSI(Open Systems Interconnection) 스택의 계층 3과 4에서 작동하므로 셰이프 및 방향 정보만 포함합니다. 예를 들어 워크로드가 인터넷에 대한 DNS 트래픽을 허용해야 하는 경우 의 Internet:53:UDP네트워크 보안 그룹을 사용합니다. 이 경우 공격자는 포트 53의 UDP를 통해 데이터를 다른 서비스로 유출할 수 있습니다.
네트워크 보안 그룹이 서로 약간 다를 수 있음을 이해합니다. 차이점의 의도를 간과하기 쉽습니다. 세분화된 필터링을 사용하려면 추가 네트워크 보안 그룹을 만드는 것이 더 안전합니다. 네트워크 보안 그룹을 하나 이상 설정합니다.
- 네트워크 보안 그룹을 추가하면 흐름 로그 및 네트워크 트래픽 분석과 같은 많은 진단 도구가 잠금 해제됩니다.
- Azure Policy 사용하여 네트워크 보안 그룹이 없는 서브넷의 트래픽을 제어할 수 있습니다.
서브넷이 네트워크 보안 그룹을 지원하는 경우 최소한의 영향을 주는 경우에도 그룹을 추가합니다.

Azure 서비스 방화벽

대부분의 Azure 서비스는 서비스 수준 방화벽을 제공합니다. 이 기능은 지정된 CIDR(클래스리스 도메인 간 라우팅) 범위에서 서비스에 대한 수신 트래픽을 검사합니다. 이러한 방화벽은 다음과 같은 이점을 제공합니다.

기본 수준의 보안을 제공합니다.
견딜 수 있는 성능 영향이 있습니다.
대부분의 서비스는 추가 비용 없이 이러한 방화벽을 제공합니다.
방화벽은 Azure 진단 통해 로그를 내보내며, 이는 액세스 패턴을 분석하는 데 유용할 수 있습니다.

그러나 이러한 방화벽과 관련된 보안 문제도 있으며 매개 변수 제공과 관련된 제한 사항이 있습니다. 예를 들어 Microsoft 호스팅 빌드 에이전트를 사용하는 경우 모든 Microsoft 호스팅 빌드 에이전트에 대한 IP 주소 범위를 열어야 합니다. 그런 다음, 해당 범위는 빌드 에이전트, 다른 테넌트 및 서비스를 남용할 수 있는 악의적 사용자에게 열립니다.

서비스 방화벽 규칙 집합으로 구성할 수 있는 서비스에 대한 액세스 패턴이 있는 경우 서비스를 사용하도록 설정해야 합니다. Azure Policy 사용하여 사용하도록 설정할 수 있습니다. 기본적으로 사용하도록 설정되지 않은 경우 신뢰할 수 있는 Azure 서비스 옵션을 사용하도록 설정하지 않도록 합니다. 이렇게 하면 규칙의 scope 있는 모든 종속 서비스가 제공됩니다.

자세한 내용은 개별 Azure 서비스의 제품 설명서를 참조하세요.

프라이빗 엔드포인트

Private Link PaaS instance 개인 IP 주소를 제공하는 방법을 제공합니다. 그러면 인터넷을 통해 서비스에 연결할 수 없습니다. 프라이빗 엔드포인트는 모든 SKU에 대해 지원되지 않습니다.

프라이빗 엔드포인트를 사용하는 경우 다음 권장 사항을 염두에 두세요.

이러한 PaaS 서비스도 공용 액세스를 제공해야 하는 경우에도 프라이빗 엔드포인트를 통해 PaaS 서비스에 연결하도록 가상 네트워크에 바인딩된 서비스를 구성합니다.
프라이빗 엔드포인트에 대한 네트워크 보안 그룹 사용을 촉진하여 프라이빗 엔드포인트 IP 주소에 대한 액세스를 제한합니다.
프라이빗 엔드포인트를 사용하는 경우 항상 서비스 방화벽을 사용합니다.
가능하면 프라이빗 엔드포인트를 통해서만 액세스할 수 있는 서비스가 있는 경우 퍼블릭 엔드포인트에 대한 DNS 구성을 제거합니다.
프라이빗 엔드포인트를 구현할 때 런타임 가시선 문제를 고려합니다. 그러나 DevOps 및 모니터링 문제도 고려합니다.
Azure Policy 사용하여 리소스 구성을 적용합니다.

절충: 프라이빗 엔드포인트가 있는 서비스 SKU는 비용이 많이 듭니다. 프라이빗 엔드포인트는 네트워크 모호성으로 인해 작업을 복잡하게 만들 수 있습니다. 자체 호스팅 에이전트, 점프 상자, VPN 및 기타 구성 요소를 아키텍처에 추가해야 합니다.

DNS 관리는 일반적인 네트워크 토폴로지에서 복잡할 수 있습니다. DNS 전달자 및 기타 구성 요소를 도입해야 할 수 있습니다.

가상 네트워크 삽입

가상 네트워크 삽입 프로세스를 사용하여 일부 Azure 서비스를 네트워크에 배포할 수 있습니다. 이러한 서비스의 예로는 Azure App Service, Functions, Azure API Management 및 Azure Spring Apps가 있습니다. 이 프로세스 는 인터넷 , 프라이빗 네트워크의 시스템 및 기타 Azure 서비스에서 애플리케이션을 격리합니다. 애플리케이션의 인바운드 및 아웃바운드 트래픽은 네트워크 규칙에 따라 허용되거나 거부됩니다.

Azure Bastion

Azure Bastion을 사용하여 브라우저 및 Azure Portal 사용하여 VM에 연결할 수 있습니다. Azure Bastion 은 RDP 및 SSH 연결의 보안을 강화합니다. 일반적인 사용 사례에는 동일한 가상 네트워크 또는 피어링된 가상 네트워크의 점프 상자에 연결하는 것이 포함됩니다. Azure Bastion을 사용하면 VM에 공용 IP 주소가 필요하지 않습니다.

Azure DDoS Protection

Azure의 모든 속성은 추가 비용 없이 추가 구성 없이 Azure DDoS 인프라 보호로 보호됩니다. 보호 수준은 기본이지만 보호에는 높은 임계값이 있습니다. 또한 원격 분석 또는 경고를 제공하지 않으며 워크로드에 구애받지 않습니다.

DDoS Protection의 상위 계층 SKU를 사용할 수 있지만 무료는 아닙니다. 전역적으로 배포된 Azure 네트워크의 규모와 용량은 일반적인 네트워크 계층 공격에 대한 보호를 제공합니다. 상시 트래픽 모니터링 및 실시간 완화와 같은 기술은 이 기능을 제공합니다.

자세한 내용은 Azure DDoS Protection 개요를 참조하세요.

예제

다음은 이 문서에서 권장되는 네트워크 컨트롤의 사용을 보여 주는 몇 가지 예입니다.

IT 환경

이 예제는 보안 기준(SE:01)에 설정된 IT(정보 기술) 환경을 기반으로 합니다. 이 방법은 트래픽을 제한하기 위해 다양한 경계에 적용되는 네트워크 제어를 광범위하게 이해합니다.

네트워크 공격 페르소나. 관리자, 직원, 고객의 클라이언트 및 익명 공격자를 포함하여 네트워크 공격에서 여러 가상 사용자를 고려할 수 있습니다.
VPN 액세스. 잘못된 행위자가 VPN을 통해 온-프레미스 환경에 연결된 VPN 또는 Azure 환경을 통해 온-프레미스 환경에 액세스할 수 있습니다. IPSec 프로토콜을 사용하여 구성하여 보안 통신을 사용하도록 설정합니다.
애플리케이션에 대한 공용 액세스. 네트워크 OSI 계층의 계층 7에서 보호하기 위해 애플리케이션 앞에 WAF(웹 애플리케이션 방화벽)가 있습니다.
운영자 액세스. 네트워크 OSI 계층의 계층 4를 통한 원격 액세스는 보호되어야 합니다. IDP/IDS 기능과 함께 Azure Firewall 사용하는 것이 좋습니다.
DDoS 보호 전체 VNet에 대한 DDoS 보호를 갖습니다.
네트워크 토폴로지. 허브-스포크와 같은 네트워크 토폴로지는 더 안전하며 비용을 최적화합니다. 허브 네트워크는 피어링된 모든 스포크에 중앙 집중식 방화벽 보호를 제공합니다.
프라이빗 엔드포인트: 프라이빗 엔드포인트를 사용하여 프라이빗 네트워크에 공개적으로 노출된 서비스를 추가하는 것이 좋습니다. 프라이빗 VNet에 NIC(네트워크 카드)를 만들고 Azure 서비스에 바인딩합니다.
TLS 통신. TLS를 통해 통신하여 전송 중인 데이터를 보호합니다.
NSG(네트워크 보안 그룹): IP 및 포트 범위를 고려하여 TCP/UDP 인바운드 및 아웃바운드 통신을 필터링하는 무료 리소스인 NSG를 사용하여 VNet 내에서 세그먼트를 보호합니다. NSG의 일부는 보다 쉽게 관리할 수 있도록 트래픽 규칙에 대한 태그를 만들 수 있는 ASG(애플리케이션 보안 그룹)입니다.
Log Analytics. Azure 리소스는 Log Analytics에서 수집된 원격 분석을 내보낸 다음 분석을 위해 Microsoft Sentinel과 같은 SIEM 솔루션과 함께 사용됩니다.
Microsoft Sentinel 통합. Log Analytics는 Microsoft Sentinel 및 클라우드용 Microsoft Defender 같은 다른 솔루션과 통합됩니다.
클라우드용 Microsoft Defender 클라우드용 Microsoft Defender 환경에 대한 네트워크 권장 사항을 포함하여 많은 워크로드 보호 솔루션을 제공합니다.
Traffic Analytics: Traffic Analytics를 사용하여 네트워크 컨트롤을 모니터링합니다. Azure Monitor의 일부인 Network Watcher 통해 구성되며 NSG에서 수집한 서브넷에서 인바운드 및 아웃바운드 적중을 집계합니다.

컨테이너화된 워크로드에 대한 아키텍처

이 예제 아키텍처는 이 문서에 설명된 네트워크 컨트롤을 결합합니다. 이 예제에서는 전체 아키텍처를 표시하지 않습니다. 대신 프라이빗 클라우드의 수신 제어에 중점을 둡니다.

Application Gateway 웹 애플리케이션에 대한 트래픽을 관리하는 데 사용할 수 있는 웹 트래픽 부하 분산 장치입니다. 네트워크 보안 그룹 컨트롤 및 웹 애플리케이션 방화벽 컨트롤이 있는 전용 서브넷에 Application Gateway 배포합니다.

모든 PaaS 서비스와의 통신은 프라이빗 엔드포인트를 통해 수행됩니다. 모든 엔드포인트는 전용 서브넷에 배치됩니다. DDoS Protection은 기본 또는 더 높은 수준의 방화벽 보호를 위해 구성된 모든 공용 IP 주소를 보호하는 데 도움이 됩니다.

관리 트래픽은 Azure Bastion을 통해 제한되므로 TLS를 통해 Azure Portal 직접 VM에 안전하고 원활한 RDP 및 SSH 연결을 제공합니다. 빌드 에이전트는 컴퓨팅 리소스, 컨테이너 레지스트리 및 데이터베이스와 같은 워크로드 리소스에 대한 네트워크 보기를 갖도록 가상 네트워크에 배치됩니다. 이 방법을 사용하면 빌드 에이전트에 안전하고 격리된 환경을 제공하여 코드 및 아티팩트 보호를 강화합니다.

컴퓨팅 리소스의 서브넷 수준에서 네트워크 보안 그룹은 송신 트래픽을 제한합니다. 강제 터널링 은 Azure Firewall 통해 모든 트래픽을 라우팅하는 데 사용됩니다. 이 방법을 사용하면 컴퓨팅 리소스에 안전하고 격리된 환경을 제공하여 데이터 및 애플리케이션에 대한 보호를 강화합니다.

보안 검사 목록

전체 권장 사항 집합을 참조하세요.

보안 검사 목록

네트워킹 및 연결에 대한 권장 사항