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

아티클
10/31/2024

이 Azure 잘 설계된 프레임워크 보안 검사 목록 권장 사항에 적용됩니다.

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

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

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

정의

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

주요 디자인 전략

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

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

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

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

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

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

트래픽 흐름 분류

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

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

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

외부 네트워크의 가시성

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

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

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

트래픽 방향

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

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

영향 범위

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

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

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

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

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

참고 항목

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

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

에지에 방화벽 적용

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

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

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

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

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

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

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

가상 네트워크 및 서브넷 보안 디자인

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

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

세분화 전략

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

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

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

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

서브넷 방화벽

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

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 토폴 로지를 사용하지 않는 경우 NVA의 개인 IP 주소로 UDR 을 NextHopType Internet 배포해야 합니다. 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 웹 애플리케이션 방화벽. 이 서비스는 인바운드 필터링을 지원하고 HTTP 및 HTTPS 트래픽만 대상으로 합니다.

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

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

Azure 애플리케이션 Gateway 또는 Azure Front Door와 같은 라우터와 Azure Web Application Firewall을 통합할 수 있습니다. 이러한 종류의 라우터에 대한 Azure 웹 애플리케이션 방화벽 구현은 다를 수 있습니다.

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사용합니다. 이 방법을 사용하면 범위를 특정 지역의 모든 엔드포인트로 제한합니다.

일부 태그는 인바운드 또는 아웃바운드 트래픽 전용입니다. 다른 형식은 두 형식 모두에 대한 것입니다. 인바운드 태그는 일반적으로 모든 호스팅 워크로드(예: AzureFrontDoor.BackendAzure)의 트래픽을 허용하여 서비스 런타임(예: LogicAppsManagement서비스 런타임)을 지원합니다. 마찬가지로 아웃 바운드 태그는 모든 호스팅 워크로드 또는 Azure의 트래픽을 허용하여 서비스 런타임을 지원합니다.

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

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

요약:

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

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

Azure 서비스 방화벽

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

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

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

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

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

프라이빗 엔드포인트

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

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

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

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

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

가상 네트워크 삽입

가상 네트워크 삽입 프로세스를 사용하여 일부 Azure 서비스를 네트워크에 배포할 수 있습니다. 이러한 서비스의 예로는 Azure 앱 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 보호

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

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

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

예시

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

IT 환경

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

네트워크 공격 페르소나. 네트워크 공격에서 관리자, 직원, 고객의 클라이언트 및 익명 공격자를 비롯한 여러 가상 사용자가 고려될 수 있습니다.
VPN 액세스. 잘못된 행위자가 VPN 또는 VPN을 통해 온-프레미스 환경에 연결된 Azure 환경을 통해 온-프레미스 환경에 액세스할 수 있습니다. IPSec 프로토콜을 사용하여 구성하여 보안 통신을 사용하도록 설정합니다.
애플리케이션에 대한 공용 액세스입니다. 애플리케이션 앞에 WAF(웹 애플리케이션 방화벽)를 사용하여 네트워크 OSI 계층의 계층 7에서 보호합니다.
운영자 액세스. 네트워크 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 환경에 대한 네트워크 권장 사항을 포함하여 많은 워크로드 보호 솔루션을 제공합니다.
트래픽 분석: 트래픽 분석을 사용하여 네트워크 컨트롤을 모니터링합니다. 이는 Azure Monitor의 일부인 Network Watcher를 통해 구성되며 NSG에서 수집한 서브넷의 인바운드 및 아웃바운드 적중을 집계합니다.

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

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

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

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

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

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

보안 검사 목록

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

보안 검사 목록

다음을 통해 공유

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