PCI-DSS 3.2.1에 대한 AKS 규제 클러스터의 네트워킹 구성(총 9부 중 3부)

이 문서에서는 PCI-DSS 3.2.1(Payment Card Industry Data Security Standard)에 따라 구성된 AKS(Azure Kubernetes Service) 클러스터에 대한 네트워킹 고려 사항을 설명합니다.

이 문서는 시리즈의 일부입니다. 소개를 읽어보세요.

PCI-DSS 3.2.1 표준의 주요 테마는 보안입니다. 허브 스포크 토폴로지는 규제된 네트워크 환경을 설정하기 위한 자연스러운 선택입니다. 보안 통신을 허용하는 인프라를 만드는 것이 더 쉽습니다. 네트워크 컨트롤은 두 허브 스포크 네트워크에 배치되며 Microsoft 제로 트러스트 모델을 따릅니다. 트래픽을 보호하기 위해 최소 권한으로 컨트롤을 조정하여 알아야 할 필요성에 따라 액세스할 수 있습니다. 그리고 각 네트워크 홉 및 계층에 컨트롤을 추가하여 여러 가지 심층 방어 접근 방식을 적용할 수 있습니다.

Kubernetes에서 워크로드를 호스팅하는 경우 방화벽 규칙과 같은 기존 네트워크 구성에 의존하는 것으로는 충분하지 않습니다. NetworkPolicy 리소스와 같이 클러스터 내의 트래픽 흐름을 제어하는 Kubernetes 기본 구성도 있습니다. 격리된 Pod, 수신 및 송신 정책에 대한 핵심 개념을 이해하려면 Kubernetes 설명서를 참조하는 것이 좋습니다.

보안 네트워크 및 시스템 빌드 및 유지 관리

요구 사항 1—카드 소유자 데이터를 보호하기 위한 방화벽 구성을 설치하고 유지 관리합니다.

AKS 기능 지원

AKS는 개인 가상 네트워크에 클러스터를 프라이빗 클러스터로 배포하는 것을 지원합니다. 클러스터와 AKS 관리형 Kubernetes API 서버 간의 통신은 신뢰할 수 있는 네트워크를 통해 이루어집니다. 프라이빗 클러스터를 사용하면 Azure Virtual Network, NSG(네트워크 보안 그룹) 및 기타 기본 제공 네트워크 컨트롤을 사용하여 전체 CDE(카드 소유자 데이터 환경)를 보호할 수 있습니다. 이렇게 구성하면 인터넷과 환경 간의 무단 공용 액세스가 금지됩니다. 이러한 클러스터를 프로비전하는 방법에 대한 자세한 내용은 프라이빗 Azure Kubernetes Service 클러스터 만들기를 참조하세요.

Azure Firewall은 AKS와 통합될 수 있으며 CDE의 핵심 구성 요소인 클러스터에서 아웃바운드 트래픽을 제한할 수 있습니다. AKS FQDN 태그를 사용하여 쉽게 구성할 수 있습니다. 권장 프로세스는 Azure Firewall을 사용하여 AKS(Azure Kubernetes Service) 배포 보호에 나와 있습니다.

AKS 클러스터에는 일부 공용 인터넷 액세스가 필요합니다. 클러스터 서브넷에서 Azure Firewall 및 NSG를 사용하여 인터넷에 대한 아웃바운드 트래픽을 제한합니다. 자세한 내용은 AKS(Azure Kubernetes Service)에서 클러스터 노드의 송신 트래픽 제어를 참조하세요.

AKS에서는 클러스터에 대한 추가적인 아웃바운드 트래픽 제어 및 모니터링에 사용할 수 있는 HTTP 프록시 정의 기능이 추가적으로 지원됩니다. 클러스터 노드는 아웃바운드 트래픽을 라우팅하기 위해 지정된 HTTP 프록시 구성을 사용합니다. 또한 생성 시 Pod에 프록시 정보를 삽입하도록 MutatingWebhook이 등록되므로, 워크로드가 동일한 프록시 정보를 상속할 수 있는 것이 좋습니다. Pod가 프록시 정보를 재정의할 수 있으므로, Azure Firewall 외에도 HTTP 프록시를 사용하는 것이 좋습니다.

AKS 클러스터는 NetworkPolicy 플러그 인을 사용하여 만들어야 합니다. AKS에는 Calico, Azure 네트워크 정책 관리 및 Cilium을 포함하여 네트워크 정책 플러그인용 옵션이 여러 개 있습니다. Calico 네트워크 정책을 사용하여 Kubenet 또는 Azure CNI를 사용할 수 있습니다. Azure 네트워크 정책 관리의 경우 Azure CNI(Kubenet이 아닌)만 사용할 수 있습니다. Azure 및 Calico 네트워크 정책 플러그 인은 모두 오픈 소스입니다. Project Calico에 대한 자세한 내용은 아래의 많은 방화벽 요구 사항을 다루는 포괄적인 PCI 솔루션 백서를 참조하세요.

사용자의 책임

요구 사항	책임
요구 사항 1.1	방화벽 및 라우터 구성 표준을 설정하고 구현합니다.
요구 사항 1.2	신뢰할 수 없는 네트워크와 카드 소유자 데이터 환경의 모든 시스템 구성 요소 간의 연결을 제한하는 방화벽 및 라우터 구성을 구축합니다.
요구 사항 1.3	인터넷과 카드 소유자 데이터 환경의 모든 시스템 구성 요소 간의 직접적인 공용 액세스를 금지합니다.
요구 사항 1.4	네트워크 외부(예: 직원이 사용하는 랩톱)에서 인터넷에 연결되고 CDE에 액세스하는 데에도 사용되는 모든 휴대용 컴퓨팅 디바이스(회사 및/또는 직원 소유 포함)에 개인 방화벽 소프트웨어 또는 이와 동등한 기능을 설치합니다.
요구 사항 1.5	방화벽 관리에 대한 보안 정책 및 운영 절차가 문서화되고, 사용되고, 영향을 받는 모든 당사자에게 알려지도록 합니다.

요구 사항 1.1

다음을 포함하는 방화벽 및 라우터 구성 표준을 설정하고 구현합니다.

요구 사항 1.1.1

모든 네트워크 연결과 방화벽 및 라우터 구성 변경을 승인 및 테스트하기 위한 공식 프로세스입니다.

사용자의 책임

Azure Portal 또는 Azure CLI를 직접 사용하는 것과 같이 구성을 수동으로 구현하지 마세요. IaC(Infrastructure as Code)를 사용하는 것이 좋습니다. IaC를 사용하면 버전 관리 시스템을 사용하는 설명 모델을 통해 인프라를 관리합니다. IaC 모델은 적용될 때마다 동일한 환경을 생성합니다. IaC의 대표적인 예는 Bicep, Azure Resource Manager 템플릿(ARM 템플릿) 또는 Terraform입니다. IaC가 옵션이 아닌 경우 방화벽 규칙 변경 사항을 추적, 구현 및 안전하게 배포하기 위한 잘 문서화된 프로세스가 있어야 합니다. 자세한 내용은 요구 사항 11.2의 일부로 제공됩니다.

Azure Firewall, NSG(네트워크 보안 그룹) 및 Kubernetes NetworkPolicy 리소스를 비롯한 다양한 네트워크 컨트롤의 조합을 사용해야 합니다.

네트워크 컨트롤에 액세스하고 수정할 수 있는 사용자 수를 최소화합니다. 역할을 정의하고 팀에 대한 책임을 명확히 합니다. 예를 들어, 조직의 네트워크 팀은 IT 팀에서 설정한 거버넌스 정책에 따라 변경 사항의 유효성을 검사합니다. 모든 네트워크 구성에 대한 변경을 승인하는 사용자 및 프로세스를 포함하는 제어된 승인 프로세스가 있어야 합니다. 이 프로세스에는 모든 네트워크 컨트롤을 테스트하는 단계가 포함되어야 합니다. 프로세스를 설명하는 자세한 설명서가 있어야 합니다.

요구 사항 1.1.2

카드 소유자 데이터 환경과 다른 네트워크(모든 무선 네트워크 포함) 간의 모든 연결을 식별하는 현재 네트워크 다이어그램

사용자의 책임

설명서의 일부로 보안 컨트롤을 사용하여 들어오고 나가는 트래픽을 보여주는 네트워크 흐름 다이어그램을 유지 관리합니다. 여기에는 무선 네트워크를 포함한 다른 네트워크에서 CDE로의 트래픽 흐름이 포함됩니다. 다이어그램에는 클러스터 내의 흐름도 표시되어야 합니다. 침입 센서와 적용된 모든 컨트롤을 표시해야 하는 것을 포함하여 다이어그램용 요구 사항이 몇 가지 있습니다.

이 이미지는 참조 구현의 네트워크 다이어그램을 보여 줍니다.

이 다이어그램의 Visio 파일을 다운로드합니다.

그림 1.1.2 - 네트워크 흐름

이 흐름에 대한 설명은 다음 섹션에 있습니다.

Azure Network Watcher가 있는 경우 Azure 가상 네트워크의 토폴로지를 볼 수 있습니다. 가상 네트워크의 모든 리소스, 가상 네트워크의 리소스에 연결된 리소스 및 리소스 간의 관계를 볼 수 있습니다.

요구 사항 1.1.3

모든 카드 소유자 데이터 흐름을 시스템 및 네트워크 전반에 걸쳐 보여주는 현재 다이어그램입니다.

사용자의 책임

설명서의 일부로 미사용 데이터 및 전송 중인 데이터를 보호하는 방법을 보여주는 데이터 흐름 다이어그램을 포함합니다.

이 다이어그램은 워크로드 간 데이터 흐름과 한 리소스에서 다른 리소스로 전달되는 정보를 표시해야 합니다. 다이어그램이 최신 상태로 유지되는지 확인합니다. 변경 관리 프로세스의 일부로 단계를 추가하여 데이터 흐름 다이어그램을 업데이트합니다.

이 아키텍처는 워크로드가 아닌 인프라에 중점을 두고 있기 때문에 여기에서는 그림을 생략했습니다.

요구 사항 1.1.4

각 인터넷 연결 및 DMZ(완충 영역)와 내부 네트워크 영역 간의 방화벽 요구 사항입니다.

사용자의 책임

DMZ의 경계를 정의하는 항목을 명확하게 정의합니다. 예를 들어, CDE(카드 소유자 데이터 환경)는 방화벽, 네트워크 정책 및 기타 제어로 보호되는 DMZ 내에 있을 수 있습니다. 자세한 내용은 Cloud DMZ를 참조하세요.

PCI DSS 인프라의 경우 네트워크 컨트롤을 사용하여 CDE가 있는 네트워크 안팎으로의 무단 액세스를 차단하여 CDE를 보호해야 합니다. 강력한 보안 태세에 맞게 네트워크 컨트롤을 올바르게 구성해야 하며 다음을 적용해야 합니다.

• 클러스터 내에 공동 배치된 구성 요소 간의 통신.
• 신뢰할 수 있는 네트워크의 워크로드와 기타 구성 요소 간의 통신.
• 워크로드와 공용 인터넷 간의 통신.

이 아키텍처는 서로 다른 방화벽 기술을 사용하여 CDE를 호스트하는 클러스터 간에 양방향으로 흐르는 트래픽을 검사합니다.

• Azure Application Gateway는 트래픽 라우터로 사용되며, 그 통합 WAF(웹 애플리케이션 방화벽)는 클러스터에 대한 인바운드(수신) 트래픽을 보호하는 데 사용됩니다.

• Azure Firewall은 모든 네트워크 및 해당 서브넷에서 모든 아웃바운드(송신) 트래픽을 보호하는 데 사용됩니다.

  트랜잭션 또는 관리 작업 처리의 일부로 클러스터는 외부 엔드포인트와 통신해야 합니다. 예를 들어, AKS 컨트롤 플레인과의 통신, 운영 체제 및 패키지 업데이트 시스템과의 통신, 외부 API와의 여러 워크로드 상호 작용이 클러스터에 필요할 수 있습니다. 이러한 상호 작용 중 일부는 HTTP를 통해 발생할 수 있으며 공격 벡터로 간주되어야 합니다. 이러한 벡터는 데이터 반출을 초래할 수 있는 중간자(man-in-the-middle) 공격의 대상입니다. 송신 트래픽에 방화벽을 추가하면 해당 위협이 완화됩니다.

  Pod 간 통신도 TLS로 암호화하는 것이 좋습니다. 이 방법은 상호 TLS(mTLS) 인증을 사용하여 참조 구현에 표시됩니다.

• NSG는 클러스터와 인프라 내 다른 구성 요소 간의 트래픽을 보호하기 위해 추가됩니다. 예를 들어, 참조 구현에서는 모든 SSH 액세스 시도를 차단하는 노드 풀이 있는 서브넷에 NSG가 있습니다. 가상 네트워크 내에서 나오는 트래픽만 허용됩니다.

  아키텍처에 구성 요소를 추가할 때 서브넷 경계에서 트래픽 유형을 허용하거나 거부하는 NSG를 더 추가하는 것이 좋습니다. 각 노드 풀은 전용 서브넷에 있으므로 워크로드의 예상 트래픽 패턴에 따라 보다 구체적인 규칙을 적용합니다.

• Kubernetes NetworkPolicy 개체는 클러스터 내 통신 제어에 사용됩니다.

  기본적으로 Pod 간 통신에는 제한이 없습니다. 제로 트러스트 네트워크에서 시작하여 필요에 따라 경로를 열어 클러스터 내 통신에 NetworkPolicy를 적용해야 합니다. 참조 구현은 a0005-i 및 a0005-o 네임스페이스의 제로 트러스트 네트워크를 보여 줍니다. 모든 네임스페이스(kube-system, gatekeeper-system 및 기타 AKS 제공 네임스페이스 제외)에는 제한적인 네트워크 정책이 적용됩니다. 정책 정의는 해당 네임스페이스에서 실행되는 Pod에 따라 달라집니다. 준비 상태, 활성 상태 및 시작 프로브를 위한 경로를 열어야 합니다. 또한 노드 수준 메트릭을 보낼 수 있도록 oms-agent에 대한 경로를 엽니다. 허용된 컨테이너 포트에 대해 일관된 NetworkPolicy 및 Azure Policy를 제공할 수 있도록 워크로드에서 포트를 표준화하는 것이 좋습니다.

요구 사항 1.1.5

네트워크 구성 요소 관리에 대한 그룹, 역할 및 책임에 대한 설명입니다.

사용자의 책임

네트워크 흐름 및 관련된 구성 요소에 대한 컨트롤을 제공해야 합니다. 결과 인프라에는 여러 개의 네트워크 세그먼트가 있으며, 각 세그먼트에는 많은 컨트롤이 있고 각 컨트롤에는 목적이 있습니다. 네트워크 계획부터 적용되는 모든 구성에 이르기까지 광범위한 범위를 설명서에서 다루는 확인하세요. 소유권에 관한 상세한 정보와 명확한 책임 라인, 소유권을 담당하는 역할도 포함되어야 합니다.

예를 들어, Azure와 인터넷 사이의 네트워크 보안 거버넌스 담당자를 알아야 합니다. 기업에서는 일반적으로 IT 팀이 Azure Firewall 규칙, WAF(웹 애플리케이션 방화벽) 규칙, NSG 및 기타 네트워크 간 트래픽의 구성과 유지 관리를 담당합니다. 또한 엔터프라이즈 차원의 가상 네트워크 및 서브넷 할당, IP 주소 계획을 담당할 수도 있습니다.

워크로드 수준에서 클러스터 운영자는 네트워크 정책을 통해 제로 트러스트(Zero-Trust)를 유지 관리해야 합니다. 또한 책임에는 Azure 컨트롤 플레인, Kubernetes API와의 통신 및 모니터링 기술이 포함될 수 있습니다.

항상 모두 거부 전략으로 시작하세요. 비즈니스 필요성 또는 역할 타당성이 있는 경우에만 권한을 부여하세요.

요구 사항 1.1.6

허용된 모든 서비스, 프로토콜 및 포트 사용에 대한 비즈니스 타당성 및 승인 설명서(안전하지 않은 것으로 간주되는 프로토콜에 대해 구현된 보안 기능 설명서 포함).

사용자의 책임

네트워크 컨트롤에 사용되는 서비스, 프로토콜 및 포트를 설명하는 자세한 설명서가 있어야 합니다. 명시적으로 허용된 포트를 제외한 모든 포트를 거부합니다. 안전하지 않은 프로토콜의 사용을 피할 수 없는 경우 비즈니스 타당성 및 문서화된 보안 기능을 문서화합니다. 다음은 Azure Firewall에 대한 참조 구현의 몇 가지 예입니다. 방화벽 규칙은 관련 리소스로만 범위가 지정되어야 합니다. 즉, 특정 원본의 트래픽만 특정 FQDN 대상으로 이동하도록 허용됩니다.

다음은 트래픽이 허용될 수 있는 몇 가지 예입니다.

규칙	프로토콜:포트	원본	대상	근거
노드와 컨트롤 플레인 간의 보안 통신을 허용합니다.	HTTPS:443	클러스터 노드 풀에 할당된 권한 있는 IP 주소 범위	AKS 컨트롤 플레인의 FQDN 대상 목록입니다. 이는 AzureKubernetesService FQDN 태그로 지정됩니다.	노드는 관리 도구, 상태 및 구성 정보, 확장할 수 있는 노드에 대한 정보를 위해 컨트롤 플레인에 액세스해야 합니다.
Flux와 GitHub 간의 보안 통신을 허용합니다.	HTTPS:443	AKS 노드 풀	github.com: api.github.com	Flux는 노드에서 실행되는 타사 통합입니다. 클러스터 구성을 프라이빗 GitHub 리포지토리와 동기화합니다.

요구 사항 1.1.7

적어도 6개월마다 방화벽 및 라우터 규칙 집합을 검토해야 합니다.

사용자의 책임

적어도 6개월마다 네트워크 구성 및 범위가 지정된 규칙을 검토하는 프로세스가 있어야 합니다. 이렇게 하면 보안 보증이 최신 상태이고 유효한지 확인할 수 있습니다. 다음 구성을 검토해야 합니다.

• Azure Firewall 규칙.
• NSG 규칙.
• Azure Application Gateway 및 WAF 규칙.
• 기본 Kubernetes 네트워크 정책.
• 방화벽은 해당 Azure 리소스를 제어합니다. 예를 들어, 이 아키텍처는 프라이빗 엔드포인트의 트래픽만 허용하는 Azure Container Registry의 규칙을 사용합니다.
• 아키텍처에 추가한 다른 모든 네트워크 컨트롤.

이전 검토 후 워크로드를 사용 중지하거나 클러스터의 구성을 변경한 경우, 필요한 방화벽 예외 또는 NSG 규칙에 대한 가정이 여전히 유효한지를 확인해야 합니다.

요구 사항 1.2

신뢰할 수 없는 네트워크와 카드 소유자 데이터 환경의 모든 시스템 구성 요소 간의 연결을 제한하는 방화벽 및 라우터 구성을 구축합니다.

사용자의 책임

이 아키텍처에서 AKS 클러스터는 CDE(카드 소유자 데이터 환경)의 핵심 구성 요소입니다. 보안 강화를 위해 클러스터를 프라이빗 클러스터로 배포하는 것이 좋습니다. 프라이빗 클러스터에서 AKS 관리형 Kubernetes API 서버와 노드 풀 간의 네트워크 트래픽은 비공개입니다. API 서버는 클러스터 네트워크의 Private Endpoint를 통해 노출됩니다.

공용 클러스터를 선택할 수도 있지만, 이 설계는 규제 대상 워크로드가 포함된 클러스터에 권장되지 않습니다. API 서버는 인터넷에 노출됩니다. DNS 레코드는 항상 검색 가능합니다. 따라서 클러스터 API를 공용 액세스로부터 보호하는 컨트롤이 필요합니다. 공용 클러스터 사용이 필요할 때는 AKS API 서버에 액세스할 수 있는 사용자를 제한하기 위해 AKS의 권한 있는 IP 범위와 함께 연결된 Kubernetes RBAC(역할 기반 액세스 제어)를 통해 엄격하게 제어하는 것이 좋습니다. 그러나 이 솔루션은 규제된 워크로드를 포함하는 클러스터에는 권장되지 않습니다.

CHD(카드 소유자 데이터)를 처리할 때 클러스터는 신뢰할 수 있거나 신뢰할 수 없는 것으로 간주되는 네트워크와 상호 작용해야 합니다. 이 아키텍처에서 PCI-DSS 3.2.1 워크로드 경계 내의 두 허브 스포크 네트워크는 모두 신뢰할 수 있는 네트워크로 간주됩니다.

신뢰할 수 없는 네트워크는 해당 경계 외부의 네트워크입니다. 다음은 신뢰할 수 없는 네트워크입니다.

• 동일 인프라에 있을 수 있지만 워크로드 경계 밖에 있는 나머지 허브 및 스포크.
• 공용 인터넷.
• 회사 네트워크.
• Azure 또는 다른 클라우드 플랫폼의 기타 가상 네트워크.

이 아키텍처에서 이미지 작성기를 호스트하는 가상 네트워크는 CHD 처리에서 수행할 역할이 없으므로 신뢰할 수 없습니다. 이러한 네트워크와 CDE의 상호 작용은 요구 사항에 따라 보호되어야 합니다. 이 프라이빗 클러스터를 사용하면 가상 네트워크, NSG 및 기타 기본 제공 기능을 사용하여 전체 환경을 보호할 수 있습니다.

프라이빗 클러스터에 대한 자세한 내용은 프라이빗 Azure Kubernetes Service 클러스터 만들기를 참조하세요.

요구 사항 1.2.1

인바운드 및 아웃바운드 트래픽을 카드 소유자 데이터 환경에 필요한 트래픽으로 제한하고 특히 다른 모든 트래픽을 거부합니다.

사용자의 책임

기본적으로 Azure 가상 네트워크는 공용 인터넷에서 직접 연결할 수 없습니다. 모든 인바운드(또는 수신) 트래픽은 중간 트래픽 라우터를 통과해야 합니다. 그러나 기본적으로 네트워크의 모든 구성 요소는 공용 엔드포인트에 연결할 수 있습니다. 프라이빗 서브넷을 구성하거나 UDR을 사용하여 방화벽을 통해 모든 아웃바운드 트래픽을 전송하여 해당 동작을 사용하지 않도록 설정할 수 있습니다. 해당 아웃바운드(또는 송신) 트래픽을 명시적으로 보호하여 보안 암호 및 TLS 1.2 이상만 허용하도록 해야 합니다.

• Azure Application Gateway의 통합 WAF는 모든 HTTP(S) 수신 트래픽을 가로채고 검사된 트래픽을 클러스터로 라우팅합니다.

  이 트래픽은 신뢰할 수 있거나 신뢰할 수 없는 네트워크에서 발생할 수 있습니다. Application Gateway는 스포크 네트워크의 서브넷에서 프로비전되고 NSG로 보호됩니다. 트래픽이 유입되면 WAF 규칙은 트래픽을 허용 또는 거부하고 Application Gateway는 구성된 백 엔드로 트래픽을 라우팅합니다. 예를 들어, Application Gateway는 다음 유형의 트래픽을 거부하여 CDE를 보호합니다.

  • TLS로 암호화되지 않은 모든 트래픽입니다.
  • Azure 인프라에서 컨트롤 플레인 통신을 위한 포트 범위 외부의 트래픽입니다.
  • 클러스터의 내부 부하 분산 장치가 아닌 엔터티에서 보낸 상태 프로브 요청입니다.

• Azure Firewall은 신뢰할 수 있는 네트워크와 신뢰할 수 없는 네트워크의 모든 아웃바운드(송신) 트래픽을 보호하는 데 사용됩니다.

  Azure Firewall은 허브 네트워크의 서브넷에 프로비전됩니다. Azure Firewall을 단일 송신 지점으로 적용하기 위해 송신 트래픽을 생성할 수 있는 서브넷에서 UDR(사용자 정의 경로)이 사용됩니다. 여기에는 이미지 작성기 가상 네트워크와 같은 신뢰할 수 없는 네트워크의 서브넷이 포함됩니다. 트래픽이 Azure Firewall에 도달하면 특정 원본의 트래픽이 특정 대상으로 이동하도록 허용하는 몇 가지 범위가 지정된 규칙이 적용됩니다.

  자세한 내용은 Azure Firewall을 사용하여 AKS(Azure Kubernetes Service) 배포 보호를 참조하세요.

• 선택적으로, 클러스터에서 외부 리소스로의 아웃바운드(송신) 트래픽을 모니터링하고 보호하기 위해 HTTP 프록시를 사용할 수 있습니다.

  일부 조직에서는 방화벽 외에도 송신 트래픽에 대한 추가 제어를 위해 HTTP 프록시를 사용해야 할 수 있습니다. 사용자 정의 경로를 방화벽으로 이동하고 송신 트래픽은 HTTP 프록시로만 이동하도록 제한하는 것이 좋습니다. 이 설정을 사용하면 Pod가 프록시를 재정의하려고 시도하더라도 방화벽으로 송신 트래픽을 차단할 수 있습니다.

  자세한 내용은 Azure Kubernetes Service의 HTTP 프록시 지원을 참조하세요.

클러스터는 공용 인터넷을 통해 다른 서비스에 액세스해야 할 수 있습니다. 예를 들어, 타사 맬웨어 방지 소프트웨어를 사용하는 경우 공용 인터넷을 통해 서버에서 바이러스 정의를 가져와야 합니다.

다른 Azure 서비스의 엔드포인트와의 상호 작용은 Azure 백본을 통해 이루어집니다. 예를 들어, 일반 작업의 일부로 클러스터는 관리되는 키 저장소에서 인증서를 가져오고, 컨테이너 레지스트리에서 이미지를 가져오는 등의 작업을 수행해야 합니다. Azure Private Link를 사용해서 이러한 상호 작용이 비공개 및 보안 상태로 수행되는지 확인하십시오.

방화벽 규칙 및 사설망 외에도 트래픽 흐름은 NSG 규칙을 통해 보호됩니다. 다음은 트래픽을 거부하여 CDE를 보호하는 이 아키텍처의 몇 가지 예입니다.

• 노드 풀이 있는 서브넷의 NSG는 해당 노드에 대한 모든 SSH 액세스를 거부합니다. 모두 거부 원칙을 유지하면서 Just-In-Time 비상 액세스를 위한 프로세스를 마련해야 합니다.
• 관리 도구를 실행하기 위한 점프 상자가 있는 서브넷의 NSG는 허브 네트워크에 있는 Azure Bastion을 제외한 모든 트래픽을 거부합니다.
• Azure Key Vault 및 Azure Container Registry에 대한 프라이빗 엔드포인트가 있는 서브넷의 NSG는 내부 부하 분산 장치 및 Azure Private Link를 통한 트래픽을 제외하고 트래픽을 모두 거부합니다.

요구 사항 1.2.2

라우터 구성 파일을 보호하고 동기화합니다.

사용자의 책임

실제 배포된 상태와 원하는 상태 사이의 델타를 검색하는 메커니즘이 있어야 합니다. IaC(Infrastructure as Code)는 이러한 용도에 적합한 선택입니다. 예를 들어, Bicep 파일 또는 ARM 템플릿(Azure Resource Manager 템플릿)은 원하는 상태의 레코드를 유지 관리합니다.

Bicep 파일 같은 배포 자산은 모든 변경 내역을 보유할 수 있도록 소스 제어되어야 합니다. Azure 활동 로그, 배포 파이프라인 로그 및 Azure 배포 로그에서 정보를 수집합니다. 이러한 소스는 배포된 자산을 추적하는 데 도움이 됩니다.

클러스터에서 Kubernetes 네트워크 정책과 같은 네트워크 컨트롤도 소스 제어 흐름을 따라야 합니다. 이 구현에서 Flux는 GitOps 연산자로 사용됩니다. 네트워크 정책과 같은 클러스터 구성을 동기화할 때 Flux 및 API 로그와 결합된 Git 기록은 구성 기록 원본이 될 수 있습니다.

요구 사항 1.2.3

모든 무선 네트워크와 카드 소유자 데이터 환경 간에 경계 방화벽을 설치하고 이러한 방화벽을 거부하도록 구성하거나, 트래픽이 업무용으로 필요한 경우 무선 환경과 카드 소유자 데이터 환경 간에 승인된 트래픽만 허용합니다.

사용자의 책임

AKS 노드 및 노드 풀은 무선 네트워크에서 연결할 수 없어야 합니다. 또한 Kubernetes API 서버에 대한 요청을 거부해야 합니다. 이러한 구성 요소에 대한 액세스는 승인된 보안 서브넷으로 제한됩니다.

일반적으로 온-프레미스 트래픽에서 스포크 네트워크로의 액세스를 제한합니다.

요구 사항 1.3

인터넷과 카드 소유자 데이터 환경의 모든 시스템 구성 요소 간의 직접적인 공용 액세스를 금지합니다.

사용자의 책임

AKS 클러스터 노드 풀은 가상 네트워크 내에서 작동하며 인터넷과 같은 공용 네트워크에서 격리됩니다. 공용 IP가 클러스터 노드에 연결되지 않도록 하고 클러스터 서브넷에 NSG 규칙을 적용하여 인터넷 트래픽이 차단되도록 하여 격리를 유지합니다. 제어된 액세스에 대한 자세한 내용은 DMZ 섹션을 참조하세요.

AKS 클러스터에는 중요한 시스템 Pod를 호스트하는 시스템 노드 풀이 있습니다. 사용자 노드 풀에도 클러스터 작업에 참여하는 다른 서비스를 실행하는 Pod가 있습니다. 예를 들어, Pod는 클러스터 구성을 GitHub 리포지토리와 동기화하기 위해 Flux를 실행하거나 트래픽을 워크로드 Pod로 라우팅하기 위해 수신 컨트롤러를 실행할 수 있습니다. 노드 풀의 유형에 관계없이 모든 노드를 보호해야 합니다.

또 다른 중요한 시스템 구성 요소는 클러스터 및 구성의 상태를 유지 관리하는 것과 같은 기본 Kubernetes 작업을 수행하는 데 사용되는 API 서버입니다. 프라이빗 클러스터를 사용할 때의 이점은 API 서버 엔드포인트가 기본적으로 노출되지 않는다는 점입니다. 프라이빗 클러스터에 대한 자세한 내용은 프라이빗 Azure Kubernetes Service 클러스터 만들기를 참조하세요.

다른 엔드포인트와의 상호 작용도 보호해야 합니다. 한 가지 방법은 사설망을 통한 통신을 제한하는 것입니다. 예를 들어, 클러스터가 프라이빗 링크를 통해 Azure Container Registry에서 이미지를 가져오도록 합니다.

요구 사항 1.3.1

공용으로 액세스할 수 있는 권한이 있는 서비스, 프로토콜 및 포트를 제공하는 시스템 구성 요소만으로 인바운드 트래픽을 제한하는 DMZ를 구현합니다.

사용자의 책임

다음은 몇 가지 모범 사례입니다.

• 노드 풀 노드에서 공용 IP 주소를 구성하지 마세요.
• Azure Policy를 사용하여 Kubernetes가 공용 부하 분산 장치를 노출하지 않는지 확인합니다. 클러스터 내의 트래픽은 내부 부하 분산 장치를 통해 라우팅되어야 합니다.
• WAF와 통합된 Azure Application Gateway에만 내부 부하 분산 장치를 노출합니다.
• 모든 네트워크 컨트롤은 해당되는 경우 원본, 대상, 포트 및 프로토콜 제한을 지정해야 합니다.
• API 서버를 인터넷에 노출하지 마세요. 프라이빗 모드에서 클러스터를 실행하면 엔드포인트가 노출되지 않으며 노드 풀과 API 서버 간의 통신은 사설망을 통해 이루어집니다.

사용자는 AKS 클러스터를 보호하기 위해 경계 네트워크를 구현할 수 있습니다. 자세한 내용은 Cloud DMZ를 참조하세요.

요구 사항 1.3.2

인바운드 인터넷 트래픽을 DMZ 내의 IP 주소로 제한합니다.

사용자의 책임

클러스터 네트워크에서 내부 부하 분산 장치가 있는 서브넷에 NSG가 있어야 합니다. Azure Application Gateway가 WAF와 통합된 서브넷의 트래픽만 허용하도록 규칙을 구성합니다. AKS 클러스터 내에서 Kubernetes NetworkPolicies를 사용하여 Pod에 대한 수신 트래픽을 제한합니다.

요구 사항 1.3.3

위조된 원본 IP 주소가 네트워크로부터 유입되는 것을 탐지하고 차단하는 스푸핑 방지 조치를 구현합니다.

Azure 책임

Azure는 스푸핑된 트래픽을 방지하고 들어오고 나가는 트래픽을 신뢰할 수 있는 플랫폼 구성 요소로 제한하기 위해 네트워크 필터링을 구현합니다.

요구 사항 1.3.4

카드 소유자 데이터 환경에서 인터넷으로의 무단 아웃바운드 트래픽을 허용하지 않습니다.

사용자의 책임

무단 아웃바운드 트래픽을 차단할 수 있는 방법은 다음과 같습니다.

• 모든 클러스터 서브넷에서 UDR(사용자 정의 경로)를 사용하여 AKS 클러스터의 모든 아웃바운드(송신) 트래픽이 Azure Firewall을 통과하도록 강제합니다. 여기에는 시스템 및 사용자 노드 풀이 있는 서브넷이 포함됩니다.
• 노드 풀이 있는 서브넷에 NSG를 추가하여 아웃바운드 트래픽을 제한합니다.
• Kubernetes NetworkPolicies를 사용하여 Pod에서 송신 트래픽을 제한합니다.
• 서비스 메시를 사용하여 추가 정책을 처리합니다. 예를 들어, Pod 간에 TLS 암호화 트래픽만 허용하는 경우 서비스 메시 프록시가 TLS 확인을 처리할 수 있습니다. 이 구현에서 그 예를 보여 줍니다. Envoy가 프록시로 배포됩니다.
• 방화벽 서브넷과 같이 명시적으로 권한이 부여된 서브넷이 아니면 CDE 내의 네트워크에 공용 IP 주소를 추가하지 마세요.
• Azure Firewall 외에도 HTTP 프록시를 사용해서 AKS 클러스터에서 인터넷으로의 아웃바운드(송신) 트래픽을 제한합니다.
• AMPLS(Azure Monitor Private Link Service)를 사용해서 비공개 보안 연결을 통해 컨테이너 인사이트의 로그를 Azure Monitor로 전송합니다. AMPLS 사용이 미치는 영향을 확인하세요.

자세한 내용은 AKS(Azure Kubernetes Service)에서 클러스터 노드의 송신 트래픽 제어를 참조하세요.

요구 사항 1.3.5

네트워크에 "설정된" 연결만 허용합니다.

Azure 책임

Azure는 스푸핑된 트래픽을 방지하고 들어오고 나가는 트래픽을 신뢰할 수 있는 플랫폼 구성 요소로 제한하기 위해 네트워크 필터링을 구현합니다. Azure 네트워크는 고객 트래픽과 관리 트래픽을 구분하기 위해 분리되어 있습니다.

요구 사항 1.3.6

DMZ 및 신뢰할 수 없는 다른 네트워크와 분리된 내부 네트워크 영역에 카드 소유자 데이터(예: 데이터베이스)를 저장하는 시스템 구성 요소를 배치합니다.

사용자의 책임

예를 들어, Private Link를 사용하여 사설망을 통해서만 스토리지 시스템을 노출합니다. 또한 이를 필요로 하는 노드 풀 서브넷의 액세스를 제한합니다. 클러스터와 자체 전용 보안 영역에서 상태를 유지합니다.

요구 사항 1.3.7

권한이 없는 당사자에게 개인 IP 주소와 라우팅 정보를 공개하지 마세요.

사용자의 책임

이 요구 사항을 충족하기 위해 공용 AKS 클러스터는 옵션이 아닙니다. 프라이빗 클러스터는 프라이빗 DNS 영역을 사용하여 공용 인터넷에서 DNS 레코드를 차단합니다. 그러나 여전히 공용 DNS 주소를 사용하여 프라이빗 AKS 클러스터를 만들 수 있습니다. 따라서 컨트롤 플레인의 개인 IP 주소가 공개되지 않도록 enablePrivateClusterPublicFQDN을 false로 설정하여 이 기능을 사용하지 않도록 명시적으로 설정하는 것이 좋습니다. 공용 DNS 레코드 없이 프라이빗 클러스터를 사용하도록 하려면 Azure Policy를 사용하는 것이 좋습니다.

또한 Azure Application Gateway가 WAF와 통합된 서브넷과 내부 부하 분산 장치가 있는 서브넷 간의 라우팅을 위해 프라이빗 DNS 영역을 사용합니다. 헤더 또는 본문에 개인 IP 정보가 포함된 HTTP 응답이 없는지 확인합니다. IP 및 DNS 레코드를 포함할 수 있는 로그가 운영 요구 사항을 벗어나 노출되지 않도록 합니다.

Private Link를 통해 연결된 Azure 서비스에는 개인 IP 주소를 노출하는 공용 DNS 레코드가 없습니다. 인프라에서 Private Link 사용을 최적화해야 합니다.

요구 사항 1.4

네트워크 외부에서 인터넷에 연결되고 CDE에 액세스하는 데에도 사용되는 모든 휴대용 컴퓨팅 디바이스에 개인 방화벽 소프트웨어 또는 이와 동등한 기능을 설치합니다.

사용자의 책임

프라이빗 클러스터는 AKS 컨트롤 플레인에서 관리합니다. 노드에 직접 액세스할 수 없습니다. 관리 작업을 수행하려면 별도의 컴퓨팅 리소스에서 kubectl과 같은 관리 도구를 사용해야 합니다. 옵션은 명령을 실행할 수 있는 에어 갭 점프 상자를 사용하는 것입니다. 또한 점프 상자로부터의 인바운드 및 아웃바운드 트래픽은 제한되고 안전해야 합니다. VPN이 액세스에 사용되는 경우 클라이언트 컴퓨터가 회사 정책에 따라 관리되고 모든 조건부 액세스 정책이 적용되는지 확인합니다.

이 아키텍처에서 해당 점프 상자는 스포크 네트워크의 별도 서브넷에 있습니다. 점프 상자에 대한 인바운드 액세스는 SSH를 통한 Azure Bastion을 통해서만 액세스할 수 있는 NSG를 사용하여 제한됩니다.

점프 상자에서 특정 명령을 실행하려면 공용 엔드포인트에 도달해야 합니다. 예를 들어, Azure 관리 평면에서 관리하는 엔드포인트입니다. 아웃바운드 트래픽은 안전해야 합니다. 스포크 네트워크의 다른 구성 요소와 마찬가지로 점프 상자의 아웃바운드 트래픽은 HTTPS 트래픽이 Azure Firewall을 통과하도록 강제하는 UDR을 사용하여 제한됩니다.

요구 사항 1.5

방화벽 관리에 대한 보안 정책 및 운영 절차가 문서화되고, 사용되고, 영향을 받는 모든 당사자에게 알려지도록 합니다.

사용자의 책임

프로세스와 정책에 대한 완전한 문서를 유지 관리하는 것이 중요합니다. AKS 클러스터를 분할하는 Azure Firewall 규칙을 관리하는 경우 특히 그렇습니다. 규제된 환경을 운영하는 사용자는 보안 보증을 지원할 수 있도록 교육을 받고 정보를 얻고 인센티브를 받아야 합니다. 이는 광범위한 관리자 권한이 부여된 계정을 가진 사람들에게 특히 중요합니다.

요구 사항 2—시스템 암호 및 기타 보안 매개 변수에 공급 업체에서 제공하는 기본값을 사용하지 마세요.

사용자의 책임

요구 사항	책임
요구 사항 2.1	시스템을 네트워크에 설치하기 전에 항상 공급 업체에서 제공하는 기본값을 변경하고 불필요한 기본 계정을 제거하거나 비활성화합니다.
요구 사항 2.2	모든 시스템 구성 요소에 대한 구성 표준을 개발합니다. 이러한 표준이 모든 알려진 보안 취약성을 해결하며 업계 인정 시스템 강화 표준에 부합하는지 확인합니다.
요구 사항 2.3	강력한 암호화를 사용하여 모든 비 콘솔 관리 액세스를 암호화합니다.
요구 사항 2.4	PCI DSS에 대해 범위 안에 있는 시스템 구성 요소의 인벤토리를 유지 관리합니다.
요구 사항 2.5	공급 업체 기본값 및 기타 보안 매개 변수 관리에 대한 보안 정책 및 운영 절차가 문서화되고, 사용되고, 영향을 받는 모든 당사자에게 알려지도록 합니다.
요구 사항 2.6	공유 호스팅 공급자는 각 엔터티의 호스팅 환경과 카드 소유자 데이터를 보호해야 합니다.

시스템 암호 및 기타 보안 매개 변수에 공급 업체에서 제공하는 기본값을 사용하지 마십시오.

요구 사항 2.1

시스템을 네트워크에 설치하기 전에 항상 공급 업체에서 제공하는 기본값을 변경하고 불필요한 기본 계정을 제거하거나 비활성화합니다.

사용자의 책임

공급 업체에서 제공하는 기본 설정을 변경해야 합니다. 기본 설정은 일반적인 공격 벡터이며 시스템을 공격에 취약하게 만듭니다. 다음은 몇 가지 고려 사항입니다.

• 컨테이너 레지스트리에서 관리자 액세스를 사용하지 않도록 설정합니다.
• 점프 상자 및 빌드 에이전트가 사용자 관리 절차를 따라 필요하지 않은 시스템 사용자를 제거하는지 확인합니다.
• 관리자 사용자에게 노드에 대한 SSH 키 액세스를 생성하거나 제공하면 안 됩니다. 긴급 액세스가 필요한 경우 Azure 복구 프로세스를 사용하여 Just-In-Time 액세스를 가져옵니다.

Azure 책임

Microsoft Entra ID에는 사용자가 제공한 새 암호에 적용되는 암호 정책이 있습니다. 암호를 변경하는 경우 이전 암호의 유효성을 검사해야 합니다. 관리자가 재설정한 암호는 해당 사용자가 다음에 로그인할 때 변경해야 합니다.

요구 사항 2.1.1

카드 소유자 데이터 환경에 연결되었거나 카드 소유자 데이터를 전송하는 무선 환경의 경우 설치 시 모든 무선 공급 업체 기본값을 변경합니다. 여기에는 기본 무선 암호화 키, 암호, SNMP 커뮤니티 문자열을 망라한 모든 항목이 포함됩니다.

사용자의 책임

이 아키텍처와 구현은 무선 연결을 통해 클라우드 트랜잭션에 온-프레미스 또는 회사 네트워크를 수행하도록 설계되지 않았습니다. 고려 사항은 공식 PCI-DSS 3.2.1 표준 지침을 참조하세요.

요구 사항 2.2

모든 시스템 구성 요소에 대한 구성 표준을 개발합니다.

사용자의 책임

Microsoft 클라우드 보안 벤치마크에서 권장 사항을 구현합니다. CIS, NIST, PCI-DSS 3.2.1 등과 같은 업계 프레임워크를 포괄하는 Azure 보안 권장 사항에 대한 통합된 단일 보기를 제공합니다. 클라우드용 Microsoft Defender 기능 및 Azure Policy를 사용하여 표준을 추적할 수 있습니다. Azure 보안 벤치마크는 클라우드용 Microsoft Defender의 기본 이니셔티브입니다. Azure Policy 및 AzTS(Azure 테넌트 보안 솔루션)에서 추가 자동화 검사를 빌드하는 것이 좋습니다.

CDE의 모든 구성 요소, 특히 AKS 노드, 점프 상자, 빌드 에이전트 및 클러스터와 상호 작용하는 기타 구성 요소의 원하는 구성 상태를 문서화합니다.

자세한 내용은 Microsoft 클라우드 보안 벤치마크를 참조하세요.

Azure 책임

Azure는 업계에서 인정하는 강화 표준과 일치하는 보안 구성 표준을 제공합니다. 표준은 최소 1년에 한 번 이상 검토됩니다.

요구 사항 2.2.1

서버당 하나의 기본 기능만 구현하여 서로 다른 보안 수준이 필요한 기능이 동일한 서버에 공존하지 않도록 합니다. (예: 웹 서버, 데이터베이스 서버, DNS는 별도의 서버에 있어야 함).

사용자의 책임

주요 전략은 필요한 수준의 구분을 제공하는 것입니다. 한 가지 방법은 범위 내 구성 요소와 범위를 벗어난 구성 요소를 별도의 클러스터에 배포하는 것입니다. 이로 인해 추가된 인프라 및 유지 관리 오버헤드에 대한 비용이 증가한다는 점을 이해합니다. 또 다른 접근 방식은 공유 클러스터의 모든 구성 요소를 공동 배치하는 것입니다. 구분 전략을 사용하여 분리를 유지합니다. 예를 들어, 클러스터 내에 별도의 노드 풀이 있습니다.

참조 구현에서 두 번째 접근 방식은 단일 클러스터에 배포된 마이크로 서비스 애플리케이션을 사용하여 입증하는 것입니다. 애플리케이션에는 두 개의 서비스 세트가 있습니다. 한 세트에는 범위 내 Pod가 있고 다른 세트에는 범위를 벗어난 Pod가 있습니다. 두 세트 모두 두 개의 사용자 노드 풀에 분산되어 있습니다. Kubernetes taints를 사용하면 범위 내 Pod 및 범위를 벗어난 Pod가 별도의 노드 풀에 배포되며 노드 VM을 공유하지 않습니다.

컨테이너 기술의 경우 컨테이너의 하나의 인스턴스만 시스템에서 하나의 기능을 담당하기 때문에 기본적으로 해당 구분이 제공됩니다.

각 워크로드 Pod마다 자체 ID를 사용해야 합니다. 클러스터 수준 또는 노드 수준 ID를 상속해서는 안됩니다.

가능한 경우 노드 내(클러스터 내) 스토리지 대신 외부 스토리지를 사용합니다. 카드 소유자 데이터 처리 작업의 일부로 수행해야 하는 작업에만 클러스터 Pod를 예약된 상태로 유지합니다. 범위를 벗어난 작업을 클러스터 외부로 이동합니다. 이 지침은 빌드 에이전트, 관련되지 않은 워크로드 또는 클러스터 내부에 점프 상자가 있는 것과 같은 활동에 적용됩니다.

요구 사항 2.2.2

시스템의 기능에 필요한 경우 필요한 서비스, 프로토콜, 디먼 등만 사용하도록 설정합니다.

사용자의 책임

기능을 사용하도록 설정하기 전에 기능 및 의미를 검토합니다. 기본 설정에는 필요하지 않은 기능이 포함될 수 있으며 이러한 기능에는 워크로드에 대한 표시 유형이 필요할 수 있습니다. 이에 대한 예는 Azure Application Gateway에 대한 기본 SSL 정책의 암호화입니다. 정책이 지나치게 관대한지 확인합니다. 필요한 암호만 선택하여 사용자 지정 정책을 만드는 것이 좋습니다.

완전히 제어할 수 있는 구성 요소는 이미지에서 불필요한 시스템 서비스를 모두 제거합니다. 예를 들어, 점프 상자 및 빌드 에이전트의 이미지를 검토하고 필요하지 않은 구성 요소를 모두 제거합니다.

AKS 노드와 같이 표시 유형만 있는 구성 요소의 경우 Azure가 노드에 설치하는 항목을 문서화합니다. 이러한 클라우드 제어 구성 요소에 필요한 추가 감사를 제공하려면 DaemonSets를 사용하는 것이 좋습니다.

요구 사항 2.2.3

안전하지 않다고 간주되는 필수 서비스, 프로토콜 또는 디먼에 대해 추가적인 보안 기능을 구현합니다.

사용자의 책임

Application Gateway에는 통합된 WAF가 있으며, 공용 엔드포인트로 전송된 요청에 대해 TLS 핸드셰이크를 협상하여 보안 암호만 허용합니다. 참조 구현은 TLS 1.2 및 승인된 암호만 지원합니다.

Azure Application Gateway를 통해 CDE와 상호 작용해야 하는 레거시 디바이스가 있다고 가정합니다. 이 요구 사항을 충족하려면 Application Gateway에서 안전하지 않은 프로토콜을 사용하도록 설정해야 합니다. 해당 예외를 문서화하고 해당 프로토콜이 해당 레거시 디바이스 이외에도 사용되는지 모니터링합니다. 레거시 상호 작용이 중단된 직후에 해당 프로토콜을 사용하지 않도록 설정합니다.

Application Gateway에서 포트 80의 요청에 응답하지 않아야 합니다. 애플리케이션 수준에서 리디렉션을 수행하지 마세요. 이 참조 구현에는 포트 80 트래픽을 차단하는 NSG 규칙이 있습니다. 규칙은 Application Gateway가 있는 서브넷에 있습니다.

클러스터의 워크로드가 보안 규정 준수 프로필 또는 기타 컨트롤(예: 제한 및 할당량)에 대한 조직 정책을 준수할 수 없는 경우 예외가 문서화되었는지 확인합니다. 예상 기능만 수행되는지 모니터링해야 합니다.

요구 사항 2.2.4

잘못 사용되지 않게 시스템 보안 매개 변수를 구성합니다.

사용자의 책임

아키텍처에 사용되는 모든 Azure 서비스는 Microsoft 클라우드 보안 벤치마크에서 제공하는 권장 사항을 따라야 합니다. 이러한 권장 사항은 특정 보안 구성 설정을 선택하기 위한 시작점을 제공합니다. 또한 해당 서비스에 대한 기준 구현과 구성을 비교합니다. 보안 기준에 대한 자세한 내용은 Azure의 보안 기준을 참조하세요.

Open Policy Agent 허용 컨트롤러는 Azure Policy와 함께 작동하여 클러스터에서 잘못된 구성을 감지하고 방지합니다. 노드에서 공용 IP 할당을 허용하지 않는 조직 정책이 있다고 가정합니다. 이러한 할당이 감지되면 정책 정의에 지정된 작업에 따라 감사 대상으로 표시되거나 거부됩니다.

인프라 수준에서 Azure 리소스의 유형 및 구성에 대한 제한을 적용할 수 있습니다. Azure Policy를 사용하여 잘못된 구성을 방지합니다. 이 참조 구현에는 프라이빗이 아닌 AKS 클러스터 생성을 거부하는 정책이 있습니다.

모든 예외를 문서화하고 검토했는지를 정기적으로 확인해야 합니다.

Azure 책임

Azure는 다단계 액세스 제어와 문서화된 비즈니스 요구 사항을 통해 권한이 있는 직원만 Azure 플랫폼 보안 제어를 구성할 수 있도록 합니다.

요구 사항 2.2.5

스크립트, 드라이버, 기능, 하위 시스템, 파일 시스템 및 불필요한 웹 서버 등 모든 불필요한 기능을 제거합니다.

사용자의 책임

점프 상자에 소프트웨어를 설치하거나 트랜잭션 처리에 참여하지 않거나 보안 에이전트와 같은 규정 준수 요구 사항에 대한 준수 가능성을 제공하지 않는 에이전트를 빌드하지 마세요. 이 권장 사항은 DaemonSet 및 Pod와 같은 클러스터 엔터티에도 적용됩니다. 모든 설치가 감지되고 기록되는지 확인합니다.

요구 사항 2.3

강력한 암호화를 사용하여 모든 비 콘솔 관리 액세스를 암호화합니다.

사용자의 책임

클러스터에 대한 모든 관리 액세스는 콘솔을 사용하여 수행해야 합니다. 클러스터의 컨트롤 플레인을 노출하지 마세요.

Azure 책임

Azure는 하이퍼바이저 인프라에 액세스할 때 강력한 암호화 사용이 적용되도록 합니다. Azure Portal을 사용하는 고객은 강력한 암호화를 통해 서비스 및 호스트 콘솔에 액세스할 수 있습니다.

요구 사항 2.4

PCI DSS에 대해 범위 안에 있는 시스템 구성 요소의 인벤토리를 유지 관리합니다.

사용자의 책임

아키텍처에 사용되는 모든 Azure 리소스는 적절하게 태그를 지정해야 합니다. 태그는 데이터 분류에 도움이 되며 서비스가 범위 내인지 범위를 벗어났는지 여부를 나타냅니다. 세심한 태그 지정을 통해 리소스를 쿼리하고, 인벤토리를 유지하고, 비용을 추적하고, 경고를 설정할 수 있습니다. 또한 해당 설명서의 스냅샷을 주기적으로 유지 관리합니다.

세분화된 수준에서 범위 내 또는 범위를 벗어난 리소스에 태그를 지정하지 마세요. 솔루션이 발전함에 따라 범위를 벗어난 리소스가 간접적으로 상호 작용하거나 카드 소유자 데이터에 인접하더라도 범위 내 리소스가 될 수 있습니다. 이러한 리소스는 감사 대상이며 감사 중에 대표적인 샘플의 일부가 될 수 있습니다. 구독 및 클러스터 수준에서 더 높은 수준의 태그를 지정하는 것이 좋습니다.

태그 지정 고려 사항에 대한 자세한 내용은 리소스 명명 및 태그 지정 결정 가이드를 참조하세요.

Kubernetes 레이블을 적용하여 클러스터 내 개체에 태그를 지정합니다. 이렇게 하면 개체를 구성하고 개체 컬렉션을 선택하고 인벤토리를 보고할 수 있습니다.

요구 사항 2.5

공급 업체 기본값 및 기타 보안 매개 변수 관리에 대한 보안 정책 및 운영 절차가 문서화되고, 사용되고, 영향을 받는 모든 당사자에게 알려지도록 합니다.

사용자의 책임

프로세스 및 정책에 대한 완전한 설명서를 유지 관리하는 것이 중요합니다. 담당자는 각 Azure 리소스의 보안 기능 및 구성 설정에 대해 학습해야 합니다. 규제된 환경을 운영하는 사용자는 보안 보증을 지원할 수 있도록 교육을 받고 정보를 얻고 인센티브를 받아야 합니다. 이러한 단계는 광범위한 관리 권한이 부여된 사람들에게 특히 중요합니다.

요구 사항 2.6

공유 호스팅 공급자는 각 엔터티의 호스팅 환경과 카드 소유자 데이터를 보호해야 합니다.

사용자의 책임

Azure는 공유되는 호스팅 환경 구성 요소에 대한 보안 보증을 제공합니다. AKS 노드를 이 워크로드의 전용 호스트로 취급할 것을 적극 권합니다. 즉, 모든 컴퓨팅은 작동할 수 있는 다른 워크로드와 공유되지 말고 단일 테넌트 모델에 있어야 합니다.

Azure 인프라 수준에서 완전한 컴퓨팅 격리가 필요한 경우 AKS(Azure Kubernetes Service) 클러스터에 Azure Dedicated Host를 추가할 수 있습니다. 이 제품은 워크로드 전용 물리적 서버를 제공하므로 AKS 노드를 프로비전된 호스트에 직접 배치할 수 있습니다. 이 아키텍처 선택은 비용적으로 상당한 영향이 있으므로 용량을 신중하게 계획해야 합니다. 대부분의 시나리오에는 일반적이지 않습니다.

다음 단계

저장된 카드 소유자 데이터를 보호합니다. 개방형 공용 네트워크를 통한 카드 소유자 데이터 전송을 암호화합니다.

관련 리소스

• AKS(Azure Kubernetes Service) 아키텍처 디자인
• PCI-DSS 3.2.1에 대한 AKS 규제 클러스터 소개(총 9부 중 1부)
• PCI-DSS 3.2.1용 AKS 규제 클러스터의 아키텍처(총 9부 중 2부)
• AKS(Azure Kubernetes Service) 클러스터에 대한 기본 아키텍처
• 다중 지역 클러스터에 대한 AKS 기준