PCI-DSS 3.2.1용 AKS 규제 클러스터의 아키텍처(총 9부 중 2부)

이 문서에서는 PCI-DSS 3.2.1(지불 카드 업계 데이터 보안 표준)에 따라 워크로드를 실행하는 AKS(Azure Kubernetes Service) 클러스터의 참조 아키텍처를 설명합니다. 이 아키텍처는 PCI-DSS 3.2.1 워크로드가 아닌 인프라에 중점을 둡니다.

이 문서는 시리즈의 일부입니다. 소개를 읽습니다.

권장 사항 및 예제는 다음과 같은 참조 구현에서 추출됩니다.

GitHub: 규제된 워크로드용 AKS(Azure Kubernetes Service) 기준 클러스터에서는 규제된 인프라를 보여줍니다. 이 구현에서는 마이크로 서비스 애플리케이션을 제공합니다. 이 애플리케이션은 인프라를 경험하고 네트워크 및 보안 제어를 설명하는 데 도움이 됩니다. 애플리케이션은 실제 PCI DSS 워크로드를 나타내거나 구현하지는 않습니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

해당 네트워크 아키텍처는 허브 스포크 토폴로지 기반입니다. 허브 가상 네트워크에는 송신 트래픽, 온-프레미스 네트워크의 게이트웨이 트래픽 및 SRE(사이트 안정성 엔지니어) 클러스터 액세스를 위한 세 번째 네트워크를 제어하는 ​​방화벽이 포함됩니다. 스포크 가상 네트워크에는 다음과 같이 두 가지가 있습니다. 한 스포크에는 CDE(카드 소유자 환경)의 구성 요소인 AKS 클러스터가 포함되어 있으며 PCI DSS 워크로드를 호스팅합니다. 다른 스포크는 환경에 대해 제어된 SRE 액세스에 사용되는 가상 머신 이미지를 빌드합니다.

구성 요소

이 아키텍처에 사용되는 주요 구성 요소는 다음과 같습니다. 이러한 서비스에 익숙하지 않은 경우 제품 설명서에 대한 링크는 관련 Azure 서비스를 참조하세요.

Azure Firewall

방화벽 인스턴스는 아웃바운드 네트워크 트래픽을 보호합니다. 이 보안 계층이 없으면 흐름이 중요한 회사 데이터를 반출할 수 있는 악의적인 타사 서비스와 통신할 수 있습니다.

Azure Bastion

기준 아키텍처는 Azure Bastion에 대한 서브넷을 제공했지만 리소스를 프로비전하지 않았습니다. 이 아키텍처는 서브넷에서 Azure Bastion을 추가하고 점프 상자에 대한 보안 액세스를 제공합니다.

Azure Image Builder

별도의 가상 네트워크에 프로비전되어 기본 보안 및 구성을 사용하여 VM 이미지를 만듭니다. 이 아키텍처에서는 Azure CLI, kubectl 및 Flux CLI와 같은 관리 도구가 미리 설치된 보안 노드 이미지를 빌드하도록 사용자 지정됩니다.

점프 상자 인스턴스에 대한 Azure Virtual Machine Scale Sets

스포크 네트워크에는 점프 상자에 대한 추가 컴퓨팅이 있습니다. 이 확장 집합은 필요에 따라 AKS 클러스터에 대해 도구를 실행하는 관리되는 액세스 지점이 되기 위한 것입니다(예: kubectl).

WAF(웹 애플리케이션 방화벽)가 통합된 Azure Application Gateway

계층 7에서 Azure Application Gateway 부하 분산 WAF는 일반적인 웹 트래픽 공격으로부터 들어오는 트래픽을 보호합니다. 인스턴스에는 사용자 요청을 수신하는 공용 프런트 엔드 IP 구성이 있습니다.

AKS(Azure Kubernetes Service)

CDE(카드 소유자 데이터 환경)의 핵심 부분인 호스팅 인프라입니다. AKS 클러스터는 프라이빗 클러스터로 배포됩니다. 따라서 Kubernetes API 서버는 공용 인터넷에 노출되지 않으며 API 서버에 대한 트래픽은 개인 네트워크로 제한됩니다.

ACR 작업

컨테이너 이미지를 빌드하고 유지 관리하는 자동화된 방법을 제공합니다.

Azure Key Vault

인증서 및 암호화 키와 같은 클러스터 작업에 필요한 비밀을 저장하고 관리합니다.

클러스터 구성

기준 아키텍처의 몇 가지 중요한 변경 사항은 다음과 같습니다.

노드 풀 세분화

이 아키텍처의 클러스터에는 두 개의 사용자 노드 풀과 하나의 시스템 노드 풀이 있습니다. 노드 풀을 위한 컴퓨팅 선택은 기준 아키텍처와 동일하게 유지됩니다. 기준 아키텍처와 달리 각 노드 풀은 컴퓨팅 계층 간에 추가된 네트워크 격리 경계를 제공하기 위해 전용 서브넷에 상주합니다.

PCI-DSS 3.2.1을 사용하려면 작업 및 연결 측면에서 다른 워크로드로부터 PCI 워크로드를 격리해야 합니다.

• 범위 내: PCI 워크로드, PCI 워크로드가 있는 환경 및 작업

• 범위 외: 서비스를 공유할 수 있지만 범위 내 구성 요소와 격리된 다른 워크로드

주요 전략은 필요한 수준의 분리를 제공하는 것입니다. 기본 방법은 범위 내 구성 요소와 범위를 벗어난 구성 요소를 별도의 클러스터에 배포하는 것입니다. 여러 클러스터를 사용할 때의 단점은 추가된 인프라와 유지 관리 오버헤드에 드는 비용이 더 높다는 것입니다. 이 구현은 간단히 하기 위해 공유 클러스터의 모든 구성 요소를 공동 배치합니다. 단일 클러스터 모델을 따르도록 선택하는 경우 엄격한 클러스터 내 세분화 전략을 사용합니다. 분리를 유지 관리하는 방법에 관계없이 솔루션이 발전함에 따라 일부 범위를 벗어난 구성 요소가 범위 내가 될 수 있다는 점에 유의하세요.

참조 구현에서는 단일 클러스터에 마이크로 서비스 애플리케이션을 배포하는 공유 클러스터 접근 방식을 설명합니다. 범위 내 워크로드와 범위를 벗어난 워크로드가 개별 사용자 노드 풀 두 개로 분할됩니다. 애플리케이션에는 두 개의 서비스 집합이 있습니다. 한 집합에는 범위 내 Pod가 있고 다른 집합은 범위를 벗어난 Pod가 있습니다. 두 집합 모두 두 개의 사용자 노드 풀에 분산됩니다. Kubernetes taints를 사용하면 범위 내 및 범위 외 Pod가 별도의 노드에 배포되어 노드 VM 또는 네트워크 IP 공간을 공유하지 않습니다.

수신 컨트롤러

기준 아키텍처에서 수신 제어에 Traefik을 사용했습니다. 이 참조 아키텍처에서는 그 대신 Nginx를 사용합니다. 이 변경 내용은 워크로드의 요구 사항에 따라 이 구성 요소를 변경할 수 있음을 보여 줍니다.

프라이빗 Kubernetes API 서버

기준 아키텍처는 AKS 클러스터를 퍼블릭 모드로 배포했습니다. 즉, AKS 관리 Kubernetes API 서버와의 모든 통신은 공용 인터넷을 통해 이루어집니다. PCI-DSS 3.2.1은 모든 시스템 구성 요소에 대한 공개 노출을 금지하므로 이 아키텍처에서는 허용되지 않습니다. 이 규제 아키텍처에서 클러스터는 프라이빗 클러스터로 배포됩니다. Kubernetes API 서버에 대한 네트워크 트래픽은 개인 네트워크로 제한됩니다. API 서버는 클러스터 네트워크의 프라이빗 엔드포인트를 통해 노출됩니다. 네트워크 보안 그룹 및 기타 기본 제공 기능을 사용하면 보안이 더욱 강화됩니다. 이 내용은 네트워크 구성에 설명되어 있습니다.

Pod 보안

워크로드의 보안 요구 사항을 설명할 때 컨테이너에 대한 관련 securityContext 설정을 사용합니다. 여기에는 fsGroup, runAsUser / runAsGroup같은 기본 설정이 포함되고 allowPrivilegeEscalation 설정(필수가 아닌 경우)은 false로 설정됩니다. seLinuxOptions에서 Linux 기능을 정의 및 제거하고 SELinux 옵션을 정의하는 방법에 대해 명확히 해야 합니다.

배포 매니페스트에서 태그로 이미지를 참조하지 않습니다. 대신 실제 이미지 ID를 사용합니다. 이렇게 하면 컨테이너 검사 결과를 클러스터에서 실행되는 실제 콘텐츠와 안정적으로 매핑할 수 있습니다. 허용된 정규식에 이미지 ID 패턴을 포함하도록 이미지 이름에 대한 Azure Policy를 통해 적용할 수 있습니다. 또한 Dockerfile FROM 지침을 사용하는 경우 이 참고 자료를 따릅니다.

네트워킹 구성

허브-스포크는 각각 해당 프라이빗 주소 공간에 있는 별도의 가상 네트워크에 모두 배포됩니다. 기본적으로 두 가상 네트워크 간에는 트래픽이 허용되지 않습니다. 네트워크 내에서 서브넷을 만들어 세분화가 적용됩니다.

다양한 Azure 서비스 및 기능과 네이티브 Kubernetes 구문의 조합은 필요한 수준의 제어를 제공합니다. 이 아키텍처에서 사용되는 몇 가지 옵션은 다음과 같습니다.

NSG(네트워크 보안 그룹)를 통한 서브넷 보안

클러스터 내/외부 흐름을 제어하는 여러 NSG가 있습니다. 다음은 몇 가지 예입니다.

• 클러스터 노드 풀은 전용 서브넷에 배치됩니다. 각 서브넷에는 노드 VM에 대한 SSH 액세스를 차단하고 가상 네트워크의 트래픽을 허용하는 NSG가 있습니다. 노드 풀의 트래픽은 가상 네트워크로 제한됩니다.

• 인터넷의 모든 인바운드 트래픽은 Azure Application Gateway에 의해 차단됩니다. 예를 들어 NSG 규칙은 다음을 확인합니다.

  • HTTPS 트래픽만 허용됩니다.
  • Azure 컨트롤 플레인의 트래픽은 서비스 태그를 사용하여 허용합니다. 자세한 내용은 몇 가지 원본 IP에 대한 액세스 허용을 참조하세요.

• Azure Container Registry 에이전트가 있는 서브넷에서 NSG는 필요한 아웃바운드 트래픽만 허용합니다. 예를 들어, 컨테이너 레지스트리가 통신해야 하는 Azure Key Vault, Microsoft Entra ID, Azure Monitor 및 기타 서비스로 트래픽이 허용됩니다.

• 점프 상자가 있는 서브넷은 관리 작업을 위한 것입니다. 점프 상자 서브넷에 관한 NSG 규칙에서는 허브의 Azure Bastion에서의 SSH 액세스와 제한된 아웃바운드 연결만 허용합니다. 점프 상자는 범용 인터넷에 액세스할 수 없으며 서브넷 NSG 및 Azure Firewall 둘 다에서 제어됩니다.

워크로드, 시스템 보안 에이전트 및 기타 구성 요소가 배포되면 허용해야 하는 트래픽 유형을 정의하는 데 도움이 되는 NSG 규칙을 더 추가합니다. 트래픽은 해당 서브넷 경계를 트래버스하면 안 됩니다. 각 노드 풀은 자체 서브넷에 있으므로 트래픽 패턴을 관찰한 다음 보다 구체적인 규칙을 적용합니다.

네트워크 정책을 사용하여 Pod-Pod 보안

이 아키텍처는 Microsoft의 “제로 트러스트” 원칙을 최대한 구현하려고 합니다.

구현에서 a0005-i 및 a0005-o 사용자 제공 네임스페이스 내에서 개념으로서의 제로 트러스트 네트워크의 예를 설명합니다. 각 워크로드 네임스페이스에는 제한된 NetworkPolicy가 적용되어야 합니다. 정책 정의는 해당 네임스페이스에서 실행되는 Pod에 따라 달라집니다. 준비 상태, 활동성 및 시작 프로브를 참작하고 Log Analytics 에이전트가 수집한 메트릭을 고려해야 합니다. 허용된 컨테이너 포트에 대해 일관된 NetworkPolicy 및 Azure Policy가 제공할 수 있도록 워크로드의 포트를 표준화하는 것이 좋습니다.

경우에 따라 클러스터 내의 통신에는 실용적이지 않습니다. 사용자가 제공한 모든 네임스페이스가 제로 트러스트 네트워크를 사용할 수 있는 것은 아닙니다(예: cluster-baseline-settings은(는) 제로 트러스트 네트워크를 사용할 수 없음).

TLS 암호화

기준 아키텍처는 클러스터의 수신 컨트롤러까지 TLS 암호화 트래픽을 제공하지만 Pod-Pod 통신은 명확하지 않습니다. 이 아키텍처에서 TLS는 CA(인증 기관) 유효성 검사를 사용하여 Pod-Pod 트래픽으로 확장됩니다. 해당 TLS는 통신을 허용하기 전에 mTLS 연결 및 확인을 적용하는 서비스 메시에서 제공됩니다.

구현에서는 mTLS를 사용합니다. mTLS 지원은 서비스 메시를 사용하거나 사용하지 않고 구현할 수 있습니다. 메시를 사용하는 경우 선택한 인증서 발급자와 호환되는지 확인합니다. 이 구현에서는 개방형 서비스 메시를 사용합니다.

이 구현의 수신 컨트롤러는 수신 리소스에 특정 인증서가 없는 경우 와일드카드 인증서를 사용하여 기본 트래픽을 처리합니다. 이는 허용될 수 있지만 조직 정책에서 와일드카드 인증서 사용을 허용하지 않는 경우 와일드카드 인증서를 사용하지 않도록 수신 컨트롤러를 조정해야 할 수 있습니다.

Azure Key Vault 네트워크 제한 사항

모든 비밀, 키 및 인증서는 Azure Key Vault에 저장됩니다. Key Vault는 회전과 같은 인증서 관리 작업을 처리합니다. Key Vault와의 통신은 Azure Private Link를 통해 이루어집니다. Key Vault와 연결된 DNS 레코드는 인터넷에서 확인할 수 없도록 프라이빗 DNS 영역에 있습니다. 이렇게 하면 보안이 향상되지만 몇 가지 제한 사항이 있습니다.

Azure Application Gateway는 Private Link로 노출된 Key Vault 인스턴스에서 HTTP 수신기에 대한 TLS 인증서 소싱을 지원하지 않습니다. 따라서 구현은 하이브리드 모델에 Key Vault를 배포합니다. 여전히 Private Link를 지원하는 연결에 사용하지만 Application Gateway 통합에 대한 공용 액세스를 허용합니다. 이 하이브리드 접근 방식이 배포에 적합하지 않은 경우 인증서 관리 프로세스를 Application Gateway로 이동합니다. 이렇게 하면 관리 오버헤드가 추가되지만 Key Vault 인스턴스가 완전히 격리됩니다. 자세한 내용은

• Azure Application Gateway 및 Key Vault 통합
• Azure CLI를 사용하여 TLS 종료로 애플리케이션 게이트웨이 만들기

DDoS 보호

공용 IP 주소를 사용하는 가상 네트워크가 있는 경우 Azure DDoS 네트워크 보호를 사용하도록 설정합니다. 이 참조 아키텍처에서는 Application Gateway를 포함하는 서브넷에 공용 IP 주소가 연결되어 있어 DDoS 보호 범위 내에 있습니다.

Azure DDoS 네트워크 보호는 대량의 사기성 요청으로부터 인프라와 워크로드를 보호합니다. 이러한 요청은 서비스 중단을 유발하거나 또 다른 동시 공격을 마스킹할 수 있습니다. Azure DDoS 네트워크 보호는 상당한 비용이 소요되며 일반적으로 많은 IP 주소에 걸쳐 있는 많은 워크로드에서 분할 상환됩니다. 귀사 네트워킹 팀과 협력하여 워크로드에 대한 적용 범위를 조정합니다.

ID 및 액세스 관리

역할의 요구 사항에 따라 역할을 정의하고 액세스 제어를 설정합니다. 역할을 실질적으로 범위가 좁게 지정된 Kubernetes 작업에 매핑합니다. 여러 함수에 걸쳐 있는 역할을 사용하지 않습니다. 한 사람이 여러 역할을 채우는 경우 해당 사용자에게 해당하는 작업 함수와 관련된 모든 역할을 할당합니다. 따라서 한 사람이 클러스터와 워크로드를 직접 담당하더라도 별도의 개인이 있는 것처럼 Kubernetes ClusterRole을 만듭니다. 그런 다음, 해당 단일 개인에게 모든 관련 역할을 할당합니다.

특히 클러스터와의 SRE/Ops 상호 작용과 같은 영향력이 높은 계정의 경우 고정 액세스를 최소화합니다. AKS 컨트롤 플레인은 빌드하는 규칙에 따라 권한 있는 액세스에 필요한 인증 유효성 검사의 추가 계층을 제공하는 Microsoft Entra ID PAM(Privileged Access Management) JIT(Just-In-Time) 및 조건부 액세스 정책을 모두 지원합니다.

PowerShell을 사용하여 조건부 액세스를 구성하는 방법에 대한 자세한 내용은 New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy, and Remove-MgIdentityConditionalAccessPolicy를 참조하세요.

디스크 암호화

미사용 데이터에 대한 암호화를 디자인할 때 스토리지 디스크, AKS 에이전트 노드 VM, 기타 VM 및 임시 및 운영 체제 디스크를 고려합니다.

저장소 디스크

기본적으로 Azure Storage 디스크는 Microsoft 관리형 키를 사용하여 미사용 시 암호화됩니다. 임시 운영 체제 디스크를 사용하거나 데이터 디스크를 추가하는 경우 암호화 키를 제어하기 위해 고객 관리형 키를 사용하는 것이 좋습니다. 스토리지 계층 외부에서 암호화하고 암호화된 데이터만 스토리지 매체에 씁니다. 또한 키가 스토리지 계층에 인접하지 않는지 확인합니다. 자세한 내용은 Azure 디스크를 사용하여 BYOK(Bring Your Own Key)를 참조하세요.

Azure Bastion 프런트 점프 상자와 같이 클러스터와 상호 작용할 수 있는 다른 디스크에 BYOK를 사용하는 것이 좋습니다. BYOK를 선택하는 경우 이 기능은 모든 SKU 또는 지역에서 지원되지 않으므로 VM 및 지역별 가용성에 대해 SKU 선택이 제한됩니다.

VM 호스트

호스트에서 암호화 기능을 사용하도록 설정하는 것이 좋습니다. 그러면 VM 호스트 및 임시 운영 체제 또는 VM 호스트에 캐시된 데이터 디스크가 암호화됩니다. 호스트 기반 암호화에 대한 VM 지원에 대해 자세히 알아보세요.

이 기능은 호스트 기반 암호화 기능을 통해 AKS 에이전트 노드의 VM 호스트에 저장된 데이터로 확장됩니다. BYOK와 마찬가지로 이 기능은 VM SKU 및 지역 선택을 제한할 수 있습니다.

Azure Policy를 통해 해당 기능을 적용할 수 있습니다.

클러스터 백업(상태 및 리소스)

워크로드에 클러스터 내 스토리지가 필요한 경우 백업 및 복구를 위한 강력하고 안전한 프로세스를 사용합니다. PersistentVolumeClaim의 백업 및 복구를 위해 Azure Backup(Azure 디스크 및 Azure Files)과 같은 서비스를 고려합니다. 백업 시스템이 네이티브 Kubernetes 리소스를 지원하는 경우 이점이 있습니다. 중요한 시스템 복구 기술에 대한 백업 시스템을 사용하여 클러스터를 잘 알려진 상태로 조정하는 기본 방법을 보완할 수 있습니다. 예를 들어 Kubernetes 리소스 수준에서 시간이 지남에 따라 시스템 상태 변경을 드리프트 검색 및 카탈로그로 지정하는 데 도움이 될 수 있습니다.

백업 프로세스는 데이터가 클러스터에서 왔는지 아니면 클러스터 외부에 있었는지에 상관없이 백업의 데이터를 분류해야 합니다. 데이터가 PCI DSS 3.2.1의 범위에 있는 경우 클러스터 외부에 있는 백업의 수명 주기 및 대상을 포함하도록 규정 준수 경계를 확장합니다. 백업은 공격 벡터일 수 있습니다. 백업을 디자인할 때 지리적 제한 사항, 미사용 암호화, 액세스 제어, 역할 및 책임, 감사, TTL(Time to Live) 및 변조 방지를 고려합니다.

클러스터 내 백업 시스템은 작업 중에 높은 권한으로 실행되어야 합니다. 백업 에이전트를 클러스터로 가져올 때의 위험과 이점을 평가합니다. 에이전트 기능이 클러스터의 다른 관리 솔루션과 겹치나요? 공격 표면을 확장하지 않고 이 작업을 수행하는 데 필요한 최소 도구 집합은 무엇인가요?

Azure Policy 고려 사항

일반적으로 적용된 Azure 정책에는 워크로드 튜닝 설정이 없습니다. 이 구현에서는 Kubernetes 클러스터 Pod 보안 제안 표준을 기본 제공 정책 이니셔티브 중 하나인 Linux 기반 워크로드 이니셔티브에 적용합니다. 이 이니셔티브는 설정의 튜닝을 허용하지 않습니다. 이 이니셔티브를 내보내고 특정 워크로드에 대한 값을 사용자 지정하는 것이 좋습니다. 하나의 사용자 지정 이니셔티브에 모든 Gatekeeper deny Azure 정책을 포함할 수 있으며 다른 이니셔티브에 따라 모든 audit Azure 정책을 포함할 수 있습니다. 이렇게 하면 정보 전용 정책에서 차단 작업이 분류됩니다.

추가 가시성을 위해 kube-system 및 gatekeeper-system 네임스페이스를 감사 정책에 있는 정책에 포함하는 것이 좋습니다. 해당 네임스페이스를 거부 정책에 포함하면 지원되지 않는 구성으로 인해 클러스터 오류가 발생할 수 있습니다.

일부 Azure Policy 경고를 설정하여 데이터 암호화를 적용할 수 있습니다. 예를 들어 클러스터 리소스의 diskEncryptionSetID에 없는 클러스터를 검색하는 경고로 BYOK를 적용할 수 있습니다. 다른 정책은 agentPoolProfiles에서 호스트 기반 암호화가 사용되는지 검색할 수 있습니다. 참조 구현은 클러스터의 디스크를 사용하지 않으며 운영 체제 디스크는 임시입니다. 이러한 두 예제 정책은 모두 보안 기능을 미리 알리는 역할을 합니다. block이 아닌 audit로 정책이 설정됩니다.

이미지 관리

워크로드에 배포가 없는 기본 이미지를 사용합니다. 이러한 이미지를 사용하면 셸 및 패키지 관리자와 같은 보조 이미지가 제거되므로 보안 노출 영역이 최소화됩니다. 이점은 CVE 적중률 감소입니다.

Azure Container Registry는 OCI(Open Container Initiative) 이미지 형식 사양을 충족하는 이미지를 지원합니다. 서명 유효성 검사를 지원하는 허용 컨트롤러와 결합하면 프라이빗 키로 서명한 이미지만 실행되도록 할 수 있습니다. 이러한 프로세스를 통합하는 SSE Connaisseur 또는 IBM Portieris와 같은 오픈 소스 솔루션이 있습니다.

컨테이너 이미지 및 기타 OCI 아티팩트에는 조직의 지적 재산이 포함되므로 보호합니다. 고객 관리형 키를 사용하고 레지스트리의 콘텐츠를 암호화합니다. 기본적으로 저장 데이터는 서비스 관리형 키를 사용하여 암호화되지만, 규정 준수 표준을 충족하려면 고객 관리형 키가 필요한 경우도 있습니다. Azure Key Vault와 같은 관리형 키 저장소에 키를 저장합니다. 키를 만들고 소유하기 때문에 회전 및 관리를 포함하여 키 수명 주기와 관련된 작업을 담당합니다. 자세한 내용은 고객 관리형 키를 사용하여 레지스트리 암호화를 참조하세요.

Kubernetes API 서버 운영 액세스

점프 상자를 기반으로 운영 프로세스를 빌드하지 않고도 클러스터에 대해 실행되는 명령을 제한할 수 있습니다. IAM 제어 IT 자동화 플랫폼이 있는 경우 미리 정의된 작업을 사용하여 작업 유형을 제어하고 감사합니다.

빌드 에이전트

빌드 프로세스는 위협 벡터일 수 있으므로 파이프라인 에이전트는 규제된 클러스터의 범위를 벗어나야 합니다. 예를 들어, 빌드 프로세스는 테스트되지 않아 신뢰할 수 없는 구성 요소에서 작동하는 경우가 많습니다.

Kubernetes를 탄력적 빌드 에이전트 인프라로 사용하는 것이 일반적이지만 규제된 워크로드 런타임의 경계 내에서 해당 프로세스를 실행하지 마세요. 빌드 에이전트는 클러스터에 직접 액세스할 수 없어야 합니다. 예를 들어 빌드 에이전트에게 컨테이너 이미지, helm 차트 등을 푸시하는 Azure Container Registry에 대한 액세스 권한만 부여합니다. 그런 다음 GitOps를 통해 배포합니다. 일반적으로 빌드 및 릴리스 워크플로는 Kubernetes 클러스터 API(또는 해당 노드)에 직접 액세스할 수 없어야 합니다.

모니터링 작업

클러스터 내 활동

클러스터 내 omsagentPod(kube-system에서 실행 중)는 Log Analytics 컬렉션 에이전트입니다. 원격 분석을 수집하고, 컨테이너 stdout 및 stderr 로그를 스크래핑하고, Prometheus 메트릭을 수집합니다. container-azm-ms-agentconfig.yaml ConfigMap 파일을 업데이트하여 컬렉션 설정을 조정할 수 있습니다. 이 참조 구현에서는 kube-system 및 모든 워크로드에서 로깅을 사용하도록 설정됩니다. 기본적으로 kube-system은(는) 로깅에서 제외됩니다. 로그 수집 프로세스를 조정하여 비용 목표, 로그를 검토할 때의 SRE 효율성 및 규정 준수 요구 사항을 충족하는지 확인합니다.

보안 모니터링

클라우드용 Microsoft Defender의 컨테이너용 Defender를 사용하여 보안 권장 사항을 보고 수정하고 컨테이너 리소스에 대한 보안 경고를 볼 수 있습니다. 카드 소유자 데이터 환경의 다양한 구성 요소에 적용되는 Microsoft Defender 계획을 사용하도록 설정합니다.

데이터를 효율적으로 검토, 분석 및 쿼리할 수 있도록 로그를 통합합니다. Azure는 몇 가지 옵션을 제공합니다. AKS 진단 로그를 켜고 Azure Monitor의 일부인 Log Analytics 작업 영역으로 보낼 수 있습니다. 또 다른 옵션은 데이터를 Microsoft Sentinel과 같은 SIEM(보안 정보 및 이벤트 관리) 솔루션에 통합하는 것입니다.

표준에 따라 모든 Log Analytics 작업 영역은 90일 보존 기간으로 설정됩니다. 장기 스토리지에 대한 연속 내보내기를 설정하는 것이 좋습니다. 중요한 정보를 로그 데이터에 저장하지 말고 보관된 로그 데이터에 대한 액세스에 최근 로그 데이터와 동일한 수준의 액세스 제어가 적용되는지 확인합니다.

전체적인 관점은 온보딩 가이드를 참조하세요. 이 가이드에서는 등록, SIEM 솔루션으로 데이터 내보내기, 경고에 응답 및 워크플로 자동화 빌드에 대해 설명합니다.

관련 Azure 서비스

다음은 이 아키텍처의 일부 주요 구성 요소에 대한 기능 설명서에 대한 링크입니다.

• AKS(Azure Kubernetes Service)
• Azure Firewall
• Azure Bastion
• Azure Image Builder
• Azure Virtual Machine Scale Sets
• WAF(웹 애플리케이션 방화벽)가 통합된 Azure Application Gateway
• Azure Container Registry 작업
• Azure Key Vault

다음 단계

카드 소유자 데이터를 보호하도록 방화벽 구성을 설치 및 유지 관리합니다. 시스템 암호 및 기타 보안 매개 변수에 공급 업체에서 제공하는 기본값을 사용하지 마세요.