PCI-DSS 3.2.1에 대한 AKS 규제 클러스터의 취약성 검색(5/9부)

이 문서에서는 PCI-DSS 3.2.1(지불 카드 업계 데이터 보안 표준)에 따라 구성된 AKS(Azure Kubernetes Service) 클러스터에 대한 고려 사항을 설명합니다.

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

다른 클라우드 솔루션과 마찬가지로 PCI 워크로드는 네트워크, ID 및 데이터 위협의 영향을 받습니다. 워크로드 및 시스템 취약성을 활용하는 원본의 일반적인 예는 바람직하지 않은 결과를 생성하는 바이러스 또는 소프트웨어 업데이트입니다. 위협을 조기에 탐지하고 완화를 사용하여 적시에 대응합니다. 워크로드 활동에 대한 중요한 경고를 작성하고 이러한 경고를 핵심 시스템 프로세스로 확장합니다. 바이러스 백신 또는 FIM(파일 무결성 모니터링) 도구는 항상 실행해야 합니다. 경고를 조사하고 조치를 취하는 책임 있는 대응 계획과 팀이 있어야 합니다.

취약성 관리 프로그램의 유지 관리

요구 사항 5 - 맬웨어로부터 모든 시스템 보호 및 정기적으로 바이러스 백신 소프트웨어 또는 프로그램 업데이트

AKS 기능 지원

AKS는 기존 애플리케이션 호스트처럼 동작하지 않습니다. AKS 클러스터의 노드 VM은 노출이 제한되어 있으며 직접 액세스할 수 없도록 설계되었습니다. 노드 VM은 기존 VM과 동일하지 않으므로 일반적인 VM 도구를 사용할 수 없습니다. 따라서 이 섹션의 권장 사항은 네이티브 Kubernetes 구성을 통해 적용됩니다. 이러한 요구 사항을 VM 수준에서 직접 적용하면 클러스터가 지원되지 않을 수 있습니다.

선택한 맬웨어 방지 소프트웨어를 모든 노드의 Pod에서 실행되는 DaemonSets에 배포해야 합니다.

사용자의 책임

소프트웨어가 Kubernetes 및 컨테이너에 특수화되어 있는지 확인합니다. 여러 타사 소프트웨어 옵션이 있습니다. 인기 있는 선택 항목으로 Prisma Cloud 및 Aquasec이 있습니다. Falco와 같은 오픈 소스 옵션도 있습니다. 타사 소프트웨어가 최신 상태인지 확인하는 프로세스가 있는지 확인하는 것은 사용자의 책임입니다. 또한 솔루션을 모니터링하고 경고하는 것도 사용자의 책임입니다.

요구 사항 6—보안 시스템 및 애플리케이션 개발 및 유지 관리

AKS 기능 지원

다른 Azure 서비스와 마찬가지로 AKS는 개발 ​​프로세스의 단계 전체에서 보안을 위해 Microsoft SDL(보안 개발 수명 주기) 프로세스를 따릅니다. 개발 초기 단계부터 다양한 구성 요소를 검사하고 보안 격차를 최대한 빨리 처리합니다.

AKS 이미지는 이미지의 취약성을 30일 이내에 패치해야 하는 FedRAMP SLA 접근 방식을 따릅니다. 이 요구 사항을 적용하기 위해 모든 이미지가 DevSecOps 파이프라인을 통해 삭제됩니다.

매주 AKS는 노드 풀에 대한 새 이미지를 제공합니다. Virtual Machine Scale Sets 작업자 노드의 패치와 업데이트를 보장하기 위해 이를 적용하는 것은 사용자의 책임입니다. 자세한 내용은 AKS(Azure Kubernetes Service) 노드 이미지 업그레이드를 참조하세요.

AKS 컨트롤 플레인의 경우 AKS에서 보안 패치를 설치하거나 업그레이드합니다. 24시간마다 업데이트됩니다.

CIS(인터넷 보안 센터) 벤치마크, 특히 AKS CIS, Ubuntu CIS 및 Windows CIS를 사용하여 AKS 컨트롤 플레인 및 작업자 노드를 강화했습니다.

AKS가 ACR(Azure Container Registry)과 통합되었습니다. 클라우드용 Microsoft Defender의 지속적인 검사 기능과 함께 Azure Container Registry를 사용하여 취약한 이미지와 애플리케이션을 다양한 위험 수준에서 식별합니다. 이미지 검사 및 위험 제어에 대한 자세한 내용은 컨테이너용 Microsoft Defender를 참조하세요.

사용자의 책임

요구 사항 5.1

일반적으로 악성 소프트웨어의 영향을 받는 모든 시스템, 특히 개인용 컴퓨터 및 서버에 바이러스 백신 소프트웨어를 배포합니다.

사용자의 책임

적절한 맬웨어 방지 소프트웨어를 선택하여 워크로드, 인프라 및 배포 파이프라인을 보호하는 것은 사용자의 책임입니다.

AKS 노드 VM에 대한 액세스가 제한되므로 맬웨어를 노드 VM에 삽입할 수 있는 각 계층에서 시스템을 보호합니다. 여기에는 클러스터 노드, 컨테이너 이미지, Kubernetes API 서버와의 런타임 상호 작용에서의 검색 및 방지가 포함됩니다. 클러스터 외에도 클러스터와 상호 작용하고 바이러스 백신 소프트웨어를 기존 방식으로 설치할 수 있는 다음 구성 요소를 보호합니다.

• 점프 상자
• 빌드 에이전트

검색 활동을 SDL(Security Development Lifecycle)에 맞춥니다. SDL을 따르면 아키텍처의 다양한 구성 요소 검사가 개발 초기 단계에서 시작되고 보안 격차가 가능한 한 빨리 해결됩니다.

요구 사항 5.1.1

바이러스 백신 프로그램에서 알려진 모든 유형의 악성 소프트웨어를 탐지, 제거 및 보호할 수 있어야 합니다.

사용자의 책임

각 소프트웨어 제품의 기능 세트 및 수행할 수 있는 검사의 깊이에 대해 알아봅니다. 소프트웨어는 일반적인 위협을 차단하고 새로운 위협을 모니터링해야 합니다. 소프트웨어가 적합하지 않은 경우 정기적으로 업데이트, 테스트 및 교체되도록 합니다. 평판이 좋은 공급업체에서 개발한 소프트웨어를 고려합니다.

• 클러스터 취약성을 검색하는 모니터링 도구.

  AKS에서는 노드 VM에서 직접 기존 에이전트 기반 VM 솔루션을 실행할 수 없습니다. 맬웨어 방지 소프트웨어를 모든 노드의 Pod에서 실행되는 DaemonSets에 배포해야 합니다.

  Kubernetes 및 컨테이너화된 워크로드에 특수화된 소프트웨어를 선택합니다. 여러 타사 소프트웨어 옵션이 있습니다. 인기 있는 선택 항목으로 Prisma Cloud 및 Aquasec이 있습니다. Falco와 같은 오픈 소스 옵션도 있습니다.

  배포되면 모든 사용자 및 시스템 노드 풀을 검사하는 클러스터에서 에이전트로 실행됩니다. AKS에서 시스템 노드 풀을 런타임 시스템 이진 파일에 사용하더라도 기본 컴퓨팅은 여전히 ​​사용자의 책임입니다.

  에이전트를 실행하는 목적은 비정상 클러스터 작업을 검색하는 것입니다. 예를 들어 애플리케이션에서 API 서버를 호출하려고 하는가요? 일부 솔루션에서는 Pod 간에 API 호출 로그를 생성하고, 보고서를 생성하고, 경고를 생성합니다. 해당 로그를 검토하고 필요한 작업을 수행해야 합니다.

  클러스터의 부트스트래핑 직후 보안 에이전트를 설치하여 클러스터와 AKS 리소스 배포 간의 모니터링되지 않는 격차를 최소화합니다.

  보안 에이전트는 높은 권한으로 실행되며 워크로드뿐만 아니라 클러스터에서 실행되는 모든 항목을 검사합니다. 데이터 반출 원본이 되지 않아야 합니다. 또한 공급망 공격은 컨테이너에 일반적입니다. 심층 방어 전략을 사용하고, 소프트웨어와 모든 종속성을 신뢰할 수 있는지 확인합니다.

  또한 클러스터 작업에 참여하는 외부 자산에서 바이러스 백신 소프트웨어를 실행합니다. 몇 가지 예로 클러스터와 상호 작용하는 점프 상자, 빌드 에이전트 및 컨테이너 이미지가 있습니다.

  에이전트가 검사할 때 파일 잠금과 같은 클러스터의 중요한 작업을 차단하거나 방해해서는 안 됩니다. 구성이 잘못되면 안정성 문제가 발생할 수 있으며 클러스터 지원이 중단될 수 있습니다.

  중요

  참조 구현은 맬웨어 방지 에이전트를 실행하는 자리 표시자 DaemonSet 배포를 제공합니다. 에이전트는 클러스터의 모든 노드 VM에서 실행됩니다. 선택한 맬웨어 방지 소프트웨어를 이 배포에 배치합니다.

• 컨테이너 안전 유지 관리. 파이프라인에서 컨테이너 검사 도구를 실행하여 컨테이너 이미지를 통해 발생할 수 있는 위협(예: 컨테이너용 Microsoft Defender의 CI/CD 취약성 검사)을 탐지합니다. 타사 선택 항목으로 Trivy 및 Clair가 있습니다. 이미지를 빌드하는 경우 항상 배포판 없는 이미지를 얻으려고 노력합니다. 이러한 이미지는 기본 Linux 이미지의 필수 이진 파일만 포함하고 공격에 대한 노출 영역을 줄입니다. 리포지토리에 이미 저장되어 있는 이미지를 지속적으로 검사하려면 컨테이너용 Microsoft Defender의 취약성 평가와 같은 지속적인 검사 솔루션을 사용합니다.

요구 사항 5.1.2

일반적으로 악의적인 소프트웨어의 대상이 아니거나 영향을 받지 않는 시스템의 경우 주기적인 평가를 수행하여 진화하는 맬웨어 위협을 식별하고 평가하여 바이러스 백신 소프트웨어가 계속 필요하지 않은지 확인합니다.

사용자의 책임

일반적인 취약성은 클러스터 외부의 구성 요소에 영향을 줄 수 있습니다. Azure 플랫폼의 CVE 및 기타 보안 경고를 조사하여 보안 취약성을 추적합니다. Azure 호스팅 서비스에서 취약성을 검색하고 바이러스 백신 솔루션을 실행할 수 있는 새로운 기능에 대한 Azure 업데이트를 확인합니다.

예를 들어 Blob 스토리지에는 의심스러운 업로드를 검색하기 위한 맬웨어 평판 검사가 있어야 합니다. 스토리지용 Microsoft Defender에는 맬웨어 평판 검사가 포함됩니다. 또한 이러한 서비스에 바이러스 백신 솔루션이 필요한지 여부를 고려합니다.

요구 사항 5.2

모든 바이러스 백신 메커니즘이 다음과 같이 유지되고 있는지 확인합니다.

• 최신 상태로 유지됩니다.
• 정기 검사를 수행합니다.
• PCI DSS 요구 사항 10.7에 따라 유지되는 감사 로그를 생성합니다.

사용자의 책임

• 최신 버전의 바이러스 백신 소프트웨어를 사용하여 클러스터가 새로운 공격으로부터 보호되도록 합니다. 고려해야 할 다음 두 유형의 업데이트가 있습니다.
  • 바이러스 백신 소프트웨어는 최신 기능 업데이트를 따라야 합니다. 한 가지 방법은 플랫폼 업데이트의 일부로 업데이트를 예약하는 것입니다.
  • 보안 인텔리전스 업데이트는 최신 위협을 탐지하고 식별하는 데 사용할 수 있는 즉시 적용해야 합니다. 자동 업데이트를 선택합니다.
• 취약성 검사가 예약한 대로 실행되고 있는지 확인합니다.
• 정상 및 비정상 구성 요소를 나타내는 검사 결과로 생성된 모든 로그를 유지합니다. 권장 보존 기간은 요구 사항 10.7에 나와 있으며, 1년입니다.
• 검색된 문제를 심사하고 수정하는 프로세스를 갖춥니다.

엔드포인트용 Microsoft Defender 바이러스 백신 업데이트를 적용하는 방법에 대한 자세한 내용은 Microsoft Defender 바이러스 백신 보안 인텔리전스 및 제품 업데이트를 참조하세요.

요구 사항 5.3

바이러스 백신 기능을 적극적으로 실행해야 하며 사용자가 사용하지 않도록 설정하거나 변경할 수 없습니다. 제한된 기간 동안 사례별로 관리에서 권한을 부여한 경우는 제외합니다.

사용자의 책임

보안 에이전트의 모니터링 및 경고를 설정하는 것은 사용자의 책임입니다. 워크로드뿐만 아니라 핵심 시스템 프로세스에 대한 중요한 경고도 빌드합니다. 에이전트는 반드시 항상 실행 중이어야 합니다. 맬웨어 방지 소프트웨어에서 발생하는 경고에 응답합니다.

• 검사 작업의 로그 내역을 유지합니다. 검사 프로세스에서 디스크 또는 메모리에서 스크랩한 카드 소지자 데이터를 로그하지 않는지 확인합니다.
• 규정 준수를 예기치 않게 지연시킬 수 있는 작업에 대한 경고를 설정합니다. 경고를 실수로 해제하면 안 됩니다.
• 에이전트 및 기타 중요한 보안 도구의 배포를 수정할 수 있는 권한을 제한합니다. 이러한 권한은 워크로드 배포 권한과 별도로 유지합니다.
• 보안 에이전트가 예상대로 실행되지 않는 경우 워크로드를 배포하지 않습니다.

요구 사항 5.4

맬웨어로부터 시스템을 보호하기 위한 보안 정책 및 운영 절차가 문서화되고 사용되며 영향을 받는 모든 당사자에게 전달되는지 확인합니다.

사용자의 책임

프로세스 및 정책, 특히 시스템을 보호하는 데 사용되는 바이러스 백신 솔루션의 세부 정보에 대한 완전한 설명서를 유지 관리하는 것이 중요합니다. 제품 주기에서 보안 인텔리전스 업데이트가 유지되는 위치, 검사 빈도 및 실시간 검사 기능에 대한 정보와 같은 정보를 포함합니다.

로그를 저장하기 위한 보존 정책을 갖춥니다. 규정 준수를 위해 장기 스토리지를 사용할 수 있습니다.

문제를 평가하고 수정하기 위한 표준 운영 절차에 대한 설명서를 유지 관리합니다. 규제된 환경을 운영하는 사용자는 보안 보증을 지원하기 위해 교육, 정보 및 인센티브를 받아야 합니다. 정책 관점에서 승인 프로세스에 참여하는 사용자에게 중요합니다.

요구 사항 6.1

보안 취약성 정보에 대해 신뢰할 수 있는 외부 원본을 사용하여 보안 취약성을 식별하는 프로세스를 수립하고 위험 순위(예: 높음, 중간 또는 낮음)를 새로 검색된 보안 취약성에 할당합니다.

사용자의 책임

검색된 취약성을 확인하고 적절하게 순위를 매기는 프로세스를 갖춥니다. 클라우드용 Microsoft Defender는 리소스 종류와 그 심각도 및 환경을 기반으로 하는 권장 사항 및 경고를 표시합니다. 대부분의 경고에는 킬 체인 의도를 이해하는 데 도움이 되는 MITRE ATT&CK® 전술이 있습니다. 문제를 조사하고 완화하기 위한 수정 계획을 갖추도록 합니다.

AKS에서는 지속적인 검사와 함께 Azure Container Registry를 사용하여 취약한 이미지와 애플리케이션을 다양한 위험 수준에서 식별할 수 있습니다. 클라우드용 Microsoft Defender에서 결과를 볼 수 있습니다.

자세한 내용은 클라우드용 Defender에서 컨테이너 보호를 참조하세요.

요구 사항 6.2

해당 공급업체 제공 보안 패치를 설치하여 모든 시스템 구성 요소와 소프트웨어가 알려진 취약성으로부터 보호되도록 합니다. 중요 패치는 릴리스 후 한 달 이내에 설치합니다.

사용자의 책임

• 타사 공급업체의 공급망 공격을 방지하려면 모든 종속성을 신뢰할 수 있도록 합니다. 평판이 좋고 신뢰할 수 있는 공급업체를 선택해야 합니다.

• 매주 AKS는 노드 풀에 대한 새 이미지를 제공합니다. 이러한 이미지는 자동으로 적용되지 않습니다. 사용 가능한 즉시 적용합니다. 노드 이미지 업데이트를 통해 수동 또는 자동으로 업데이트할 수 있습니다. 자세한 내용은 AKS(Azure Kubernetes Service) 노드 이미지 업그레이드를 참조하세요.

  AKS 컨트롤 플레인의 경우 AKS에서 보안 패치를 설치하거나 업그레이드합니다.

• AKS 노드는 24시간마다 운영 체제 및 보안 패치를 개별적으로 자동으로 다운로드하여 설치합니다. 이러한 업데이트를 받으려면 방화벽에서 이 트래픽을 차단하지 않아야 합니다.

  보안 에이전트에서 보고 기능을 사용하도록 설정하여 적용된 업데이트에 대한 정보를 가져오는 것이 좋습니다. 일부 보안 업데이트는 다시 시작해야 합니다. 경고를 검토하고 이러한 다시 시작에서 애플리케이션 가동 중지 시간을 최소화하거나 0이 되도록 하는 작업을 수행해야 합니다. 다시 시작을 제어된 방식으로 수행하는 오픈 소스 옵션은 Kured(Kubernetes 재부팅 디먼)입니다.

• 패치 프로세스를 프로비전하는 클러스터 외부의 리소스(예: 점프 상자 및 빌드 에이전트)로 확장합니다.

• 지원되는 AKS 버전을 사용하여 최신 상태를 유지합니다. 수명이 다한 버전을 디자인에서 사용하는 경우 현재 버전으로 업그레이드합니다. 자세한 내용은 지원되는 AKS 버전을 참조하세요.

요구 사항 6.3

다음과 같이 내부 및 외부 소프트웨어 애플리케이션(애플리케이션에 대한 웹 기반 관리 액세스 포함)을 안전하게 개발합니다.

• PCI DSS(예: 보안 인증 및 로깅)에 따라
• 업계 표준 및/또는 모범 사례를 기반으로 합니다.
• 타사에서 개발한 맞춤형 또는 사용자 지정 소프트웨어를 포함하여 내부에서 개발한 모든 소프트웨어에 적용되는 소프트웨어 개발 수명 주기 전반에 걸쳐 정보 보안을 통합합니다.

사용자의 책임

워크로드 수명 주기 및 운영의 일부로 보안 선택 사항을 통합하고 우선 순위를 지정합니다.

NIST 프레임워크와 같은 몇 가지 업계 프레임워크는 수명 주기에 매핑됩니다. NIST 기능(식별, 보호, 검색, 대응 및 복구)은 각 단계에서 예방 제어에 대한 전략을 제공합니다.

Microsoft SDL(보안 개발 수명 주기)은 개발 프로세스의 단계 전체에서 보안에 대한 모범 사례, 도구 및 프로세스를 제공합니다. AKS를 포함한 모든 Azure 서비스에 대해 Microsoft SDL 사례를 따릅니다. 또한 클라우드 서비스를 운영하기 위한 OSA(Operational Security Assurance) 프레임워크를 따릅니다. 비슷한 프로세스가 있는지 확인합니다. 이러한 사례는 애플리케이션을 보호하는 데 도움이 되도록 게시됩니다.

• Microsoft SDL
• Microsoft OSA

요구 사항 6.3.1

애플리케이션이 활성화되거나 고객에게 릴리스되기 전에 개발, 테스트 및/또는 사용자 지정 애플리케이션 계정, 사용자 ID 및 암호를 제거합니다.

사용자의 책임

클러스터 만들기의 일환으로 여러 로컬 Kubernetes 사용자가 기본적으로 만들어집니다. 이러한 사용자는 고유 ID를 나타내지 않으므로 감사할 수 없습니다. 이 중 일부는 높은 권한을 가지고 있습니다. AKS의 로컬 계정 사용 안 함 기능을 사용하여 해당 사용자를 사용하지 않도록 설정합니다.

기타 고려 사항은 공식 PCI-DSS 3.2.1 표준의 지침을 참조하세요.

요구 사항 6.3.2

프로덕션 또는 고객 릴리스에 앞서 사용자 지정 코드를 검토하여 다음을 포함하는 잠재적인 코딩 취약성을 식별합니다(수동 또는 자동 프로세스 사용).

• 코드 변경 내용을 원래의 코드 작성자가 아닌 다른 사람과, 코드 검토 기법 및 안전 코딩 실무를 아는 사람이 검토합니다.
• 코드 검토에서는 코드가 안전 코딩 지침에 맞게 개발되었는지 확인합니다.
• 릴리스하기 전에 적절한 수정이 구현됩니다.
• 코드 검토 결과는 릴리스하기 전에 관리에서 검토되고 승인됩니다.

사용자의 책임

클러스터에 설치된 모든 소프트웨어는 컨테이너 레지스트리에서 제공됩니다. 애플리케이션 코드와 마찬가지로 프로세스와 사용자가 Azure 및 타사 이미지(Dockerfile 및 OCI)를 면밀히 조사하도록 합니다. 또한 다음 작업도 수행합니다.

• 클러스터를 만들 때 초기 단계에서 컨테이너 이미지 검사를 시작합니다. 검사 프로세스를 연속 통합/지속적인 배포 파이프라인의 일부로 만듭니다.

  클러스터 부트스트랩 이미지와 워크로드가 모두 검토 및/또는 격리 게이트를 통과하는 방식으로 배포 파이프라인이 제어되도록 합니다. 클러스터로 끌어오기 전에 사용된 프로세스와 방법에 대한 기록을 유지 관리합니다.

• 이미지 크기를 줄입니다. 일반적으로, 필요한 것보다 많은 이진 파일이 이미지에 포함되어 있습니다. 이미지 크기를 줄이면 성능이 향상될 뿐만 아니라 공격 표면도 제한됩니다. 예를 들어, distroless 이미지를 사용하면 기본 Linux 이미지의 공격 표면이 최소화됩니다.

• Dockerfile 및 매니페스트의 무결성을 확인하는 정적 분석 도구를 사용합니다. 타사 옵션으로 Dockle 및 Trivy가 있습니다.

• 서명된 이미지만 사용합니다.

• Azure에서 제공하는 기본 이미지와 이것이 CIS 벤치마크를 준수하는 방법을 이해하고 수락합니다. 자세한 내용은 CIS(Center for Internet Security) 벤치마크를 참조하세요.

클라우드용 Microsoft Defender에서 지속적인 검사를 사용하는 Azure Container Registry는 취약한 이미지와 워크로드에 발생할 수 있는 다양한 위험을 식별하는 데 도움이 됩니다. 이미지 검사 및 위험 제어에 대한 자세한 내용은 컨테이너 보안을 참조하세요.

요구 사항 6.4

시스템 구성 요소에 대한 모든 변경에 대한 변경 제어 프로세스 및 절차를 따릅니다.

사용자의 책임

변경 제어 프로세스를 문서화하고 해당 프로세스에 따라 배포 파이프라인을 설계해야 합니다. 프로세스와 실제 파이프라인이 일치하지 않는 상황을 검색하는 다른 프로세스를 포함합니다.

요구 사항 6.4.1, 6.4.2

• 개발/테스트 환경과 프로덕션 환경을 분리하고 액세스 제어를 사용하여 분리를 적용합니다.
• 개발/테스트 및 프로덕션 환경 간에 업무를 분리합니다.

사용자의 책임

별도의 프로덕션 및 사전 프로덕션 환경과 이러한 환경에서 작동하는 역할을 유지 관리합니다.

• 프로덕션 클러스터를 개발/테스트 목적으로 사용하지 않습니다. 예를 들어, Bridge to Kubernetes를 프로덕션 클러스터에 설치하지 마세요. 비 프로덕션 워크로드에는 전용 클러스터를 사용합니다.

• 프로덕션 환경에서 사전 프로덕션 환경에 대한 네트워크 액세스를 허용하지 않도록 합니다. 그 반대의 경우도 마찬가지입니다.

• 사전 프로덕션 및 프로덕션 환경에서 시스템 ID를 다시 사용하지 않습니다.

  클러스터 관리자 또는 파이프라인 보안 주체 같은 그룹에는 Microsoft Entra 그룹을 사용합니다. 일반화되거나 일반적인 그룹을 액세스 제어로 사용하지 않습니다. 이러한 그룹을 사전 프로덕션 클러스터와 프로덕션 클러스터 간에 다시 사용하지 마세요. 한 가지 방법은 그룹 이름에서 클러스터 이름(또는 다른 불투명 식별자)을 사용하여 멤버 자격을 명시적으로 지정하는 것입니다.

  Azure RBAC(역할 기반 액세스 제어) 역할을 환경 간에 적절하게 사용합니다. 일반적으로, 사전 프로덕션 환경에는 역할과 권한이 더 많이 할당됩니다.

  사전 프로덕션 전용 ID(파이프라인 또는 소프트웨어 엔지니어링 팀에 부여)는 프로덕션에서 액세스 권한이 부여되면 안 됩니다. 반대로 프로덕션 전용 ID(예: 파이프라인)에는 사전 프로덕션 클러스터에서 액세스 권한이 부여되면 안 됩니다.

  동일한 사용자 할당 관리 ID를 사전 프로덕션 및 프로덕션의 리소스에 사용하지 않습니다. 이 권장 사항은 클러스터에 배포된 리소스뿐만 아니라 사용자 할당 관리 ID를 지원하는 모든 리소스에도 적용됩니다. 일반적으로 ID가 필요한 Azure 리소스는 다른 리소스와 공유하는 대신 자체의 고유 ID를 가져야 합니다.

• 가능한 경우 사전 프로덕션 클러스터를 포함하여 JIT(Just-In-Time) 액세스를 높은 권한 액세스에 사용합니다. 사전 프로덕션 클러스터와 프로덕션 클러스터 모두에서 조건부 액세스 정책을 사용합니다.

요구 사항 6.4.3

프로덕션 데이터(라이브 PAN)는 테스트 또는 개발에 사용되지 않습니다.

사용자의 책임

CHD 데이터가 개발/테스트 환경으로 이동하지 않도록 합니다. 데이터를 프로덕션에서 개발/테스트로 이동하는 절차를 제공하는 명확한 설명서를 갖춥니다. 실제 데이터의 제거는 해당 절차에 포함되어야 하며 책임 있는 당사자의 승인을 받아야 합니다.

요구 사항 6.4.4

시스템이 활성화되거나 프로덕션으로 전환되기 전에 시스템 구성 요소에서 테스트 데이터 및 계정을 제거합니다.

사용자의 책임

프로덕션에 배포하기 전에 시스템에서 기본 구성 데이터, 샘플 데이터 및 잘 알려진 테스트 데이터를 제거합니다. 카드 소유자 데이터를 테스트 목적으로 사용하지 마세요.

요구 사항 6.4.5

보안 패치 및 소프트웨어 수정을 구현하기 위한 변경 제어 절차는 다음을 포함해야 합니다.

• 6.4.5.1 영향의 문서화
• 6.4.5.2 권한 있는 당사자의 문서화된 변경 승인
• 6.4.5.3 변경이 시스템 보안에 부정적인 영향을 미치지 않는지 확인하기 위한 기능 테스트
• 6.4.5.4 철회 절차

사용자의 책임

다음과 같은 지침 사항은 이전 요구 사항에 매핑됩니다.

• 보안 패치 및 소프트웨어 수정의 결과로 필요한 인프라 변경 내용을 문서화합니다. IaC(Infrastructure-as-Code) 접근 방식을 사용하면 이 프로세스가 더 쉬워집니다. 예를 들어, Bicep 파일 또는 ARM 템플릿(Azure Resource Manager 템플릿)을 사용하면 가상 작업을 통해 배포의 변경 내용을 미리 볼 수 있습니다. 자세한 내용은 인프라 변경에 대한 Bicep 배포 가상 작업을 참조하세요.

• 일반 배포에 대한 변경 승인의 유효성을 검사하는 게이트를 배포 파이프라인에 구현합니다. 게이트가 무시되었을 수 있는 긴급 배포에 대한 근거를 문서화합니다.

  변경의 수준 및 깊이를 정의합니다. 사소한 변경과는 달리 팀에서 중요한 변경의 정의에 동의해야 합니다. 실용적인 경우 이러한 변경 내용 중 일부의 검색을 자동화합니다. 워크로드, 인프라 및 파이프라인에 대한 검토자는 수준을 명확하게 이해하고 해당 기준에 대해 유효성을 검사해야 합니다.

• 보안 어포던스를 테스트합니다. 가상 트랜잭션에서 보안(허용 및 거부) 문제를 테스트하도록 합니다. 또한 이러한 가상 테스트가 사전 프로덕션 환경에서 실행되도록 합니다.

• 보안 수정에서 예기치 않은 결과가 발생하는 경우에 대비하여 철회 프로세스를 갖춥니다. 일반적인 전략은 파란색-녹색 배포를 사용하여 이전 상태를 유지하면서 배포하는 것입니다. 데이터베이스를 포함한 워크로드의 경우 특정 토폴로지에서 작동하고 범위가 배포 단위로 지정된 전략이 있습니다.

요구 사항 6.5

다음과 같이 소프트웨어 개발 프로세스의 일반적인 코딩 취약성을 해결합니다.

• 매년 한 번 이상 일반적인 코딩 취약성 방지 방법을 포함한 안전 코딩 기법에 대해 개발자를 교육합니다.
• 안전 코딩 지침에 따라 애플리케이션을 개발합니다.

사용자의 책임

애플리케이션 팀 및 운영 팀에서 워크로드 및 인프라의 검사 작업을 지원하기 위해 교육, 정보 및 인센티브를 받아야 합니다. 다음은 관련 리소스입니다.

• 보안 코딩 지침
• 보안 DevOps
• 보안 개발 수명 주기 리소스

요구 사항 6.6

퍼블릭 웹 애플리케이션의 경우 지속적으로 새로운 위협과 취약성을 해결합니다. 다음 방법 중 하나에 의해 이러한 애플리케이션이 알려진 공격으로부터 보호되는지 확인합니다.

• 수동 또는 자동화된 애플리케이션 취약성 보안 평가 도구 또는 방법을 사용하여 퍼블릭 웹 애플리케이션을 검토합니다. 적어도 1년에 한 번 및 변경 후에 취약성 평가를 수행합니다.

  참고

  이 평가는 요구 사항 11.2의 일부로 수행된 취약성 검사와 다릅니다.

• 웹 기반 공격을 감지하고 방지하는 자동화된 솔루션을 설치합니다. 예를 들어 웹 애플리케이션 방화벽입니다. 퍼블릭 웹 애플리케이션 앞에 배포하고 모든 트래픽을 적극적으로 평가합니다.

사용자의 책임

WAF(웹 애플리케이션 방화벽)를 사용하여 공용 인터넷에서 들어오는 트래픽을 검색하는 검사를 갖춥니다. 이 아키텍처에서 Azure Application Gateway는 통합 WAF를 사용하여 들어오는 모든 트래픽을 확인합니다. WAF는 OWASP(Open Web Application Security Project)의 CRS(핵심 규칙 집합)에 기반합니다. 기술적 제어가 없는 경우 보상 제어를 갖춥니다. 한 가지 방법은 수동 코드 검사를 통하는 것입니다.

최신 버전의 규칙 집합을 사용하고 있는지 확인하고 워크로드와 관련된 규칙을 적용합니다. 규칙은 방지 모드에서 실행해야 합니다. WAF가 사용하도록 설정되고 해당 모드에서 작동하는지 확인하는 Azure Policy 인스턴스를 추가하여 해당 요구 사항을 적용할 수 있습니다.

탐지된 위협에 대한 세부 정보를 얻으려면 Application Gateway WAF에서 생성된 로그를 유지합니다. 필요에 따라 규칙을 미세 조정합니다.

애플리케이션 코드에 초점을 맞춘 침투 테스트를 수행합니다. 이렇게 하면 애플리케이션 팀에 속하지 않는 실무자가 정보를 수집하고, 취약성을 분석하고, 보고하여 보안 격차(예: SQL 삽입 및 디렉터리 통과)를 확인할 수 있습니다. 이 연습에서 실무자는 중요한 데이터에 액세스해야 할 수 있습니다. 의도가 잘못 사용되지 않도록 하려면 사용자 참여의 침투 테스트 규칙에서 제공하는 지침을 따릅니다.

요구 사항 6.7

보안 시스템과 애플리케이션을 개발하고 유지 관리하기 위한 보안 정책과 운영 절차가 문서화되고 사용되고 있으며 영향을 받는 모든 당사자에게 알려져 있는지 확인하세요.

사용자의 책임

프로세스 및 정책에 대한 완전한 설명서를 유지 관리하는 것이 중요합니다. 귀사 팀은 워크로드 수명 주기 및 운영의 일부로 보안 선택 항목의 우선 순위를 지정하도록 교육을 받아야 합니다.

Microsoft SDL은 개발 프로세스의 단계 전체에서 보안에 대한 모범 사례, 도구 및 프로세스를 제공합니다. Microsoft에서 소프트웨어를 빌드할 때 Microsoft SDL 방식을 엄격하게 준수합니다. 또한 클라우드 서비스를 운영하기 위한 OSA(Operational Security Assurance) 프레임워크를 따릅니다. 이러한 사례는 애플리케이션을 보호하는 데 도움이 되도록 게시됩니다.

• Microsoft SDL
• Microsoft OSA

검색된 문제에 대한 테스트, 심사 프로세스 및 수정 전략의 범위를 설명하는 침투 테스트에 대한 완전한 설명서를 유지합니다. 인시던트가 발생하는 경우 근본 원인 분석의 일부로 요구 사항 6의 평가를 통합합니다. 격차가 검색되면(예: OWASP 규칙 위반 감지) 해당 격차를 닫습니다.

설명서에는 예상되는 WAF 보호 상태에 대한 명확한 지침이 있습니다.

규제된 환경을 운영하는 사용자는 보안 보증을 지원하기 위해 교육, 정보 및 인센티브를 받아야 합니다. 정책 관점에서 승인 프로세스에 참여하는 사용자에게 중요합니다.

다음 단계

알아야 할 비즈니스 요구 사항에 따라 카드 소유자 데이터에 대한 액세스를 제한합니다. 시스템 구성 요소에 대한 액세스를 식별하고 인증합니다. 카드 소유자 데이터에 대한 물리적 액세스를 제한합니다.