PCI-DSS 3.2.1에 대한 AKS 규제 클러스터의 데이터 보호(총 9부 중 4부)

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

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

이 아키텍처와 구현은 워크로드가 아닌 인프라에 중점을 줍니다. 이 문서에서는 디자인을 결정하는 데 도움이 되는 일반적인 고려 사항과 모범 사례를 제공합니다. 공식 PCI-DSS 3.2.1 표준의 요구 사항을 따르고 해당하는 경우 이 문서를 추가 정보로 사용합니다.

카드 소유자 데이터 보호

요구 사항 3—저장된 카드 소유자 데이터 보호

사용자의 책임

요구 사항 3.1

모든 CHD(카드 소유자 데이터) 스토리지에 최소한 다음 이상이 포함된 데이터 보존 및 폐기 정책, 절차 및 프로세스를 구현하여 카드 소유자 데이터 스토리지를 최소한으로 보관합니다.

• 데이터 스토리지 용량과 보존 기간을 법률, 규정 및 업무 요구 사항에서 요구하는 수준으로 제한
• 필요 없는 데이터의 안전한 삭제를 위한 프로세스
• 카드 소유자 데이터에 대한 특정 보존 요구 사항
• 정의된 보존 기간을 초과하는 저장된 카드 소유자 데이터를 식별하고 안전하게 삭제하기 위한 분기별 프로세스입니다.

사용자의 책임

AKS 클러스터에 상태를 저장하지 마세요. CHD를 저장하면 보안 스토리지 옵션을 살펴봅니다. 옵션에는 파일 스토리지용 Azure Storage 또는 Azure SQL Database 또는 Azure Cosmos DB와 같은 데이터베이스가 포함됩니다.

저장할 수 있는 CHD 종류에 대한 표준 지침을 엄격하게 준수합니다. 비즈니스 요구 사항과 사용된 스토리지 형식에 따라 데이터 보존 정책을 정의합니다. 일부 주요 고려 사항은 다음과 같습니다.

• 데이터를 어떻게 저장하고 어디에 저장하나요?
• 저장된 데이터가 암호화되어 있나요?
• 보존 기간이 어떻게 되나요?
• 보존 기간 동안에 어떤 작업이 허용되나요?
• 보존 기간이 만료된 후에는 저장된 데이터를 어떻게 삭제하나요?

이러한 선택 사항 중 일부에 대한 거버넌스 정책을 갖습니다. 기본 제공 Azure 정책에서 이러한 선택 사항을 적용합니다. 예를 들어 클러스터 Pod의 볼륨 형식을 제한하거나 루트 파일 시스템에서 쓰기 작업을 거부할 수 있습니다.

이 정책 정의 목록을 검토하고 해당하는 경우 클러스터에 적용합니다.

데이터를 일시적으로 캐시해야 할 수도 있습니다. 스토리지 솔루션으로 이동하는 동안 캐시된 데이터를 보호하는 것이 좋습니다. AKS에서 호스트 기반 암호화 기능을 사용하는 것이 좋습니다. 그러면 노드 VM에 저장된 데이터가 암호화됩니다. 자세한 내용은 AKS(Azure Kubernetes Service)에서 호스트 기반 암호화를 참조하세요. 또한 노드 풀에 대한 임시 디스크와 캐시를 암호화해야 하는 기본 제공 Azure 정책을 사용합니다.

스토리지 기술을 선택할 때 보존 기능을 살펴봅니다. 예를 들어 Azure Blob Storage에서는 시간 기반 보존 정책을 제공합니다. 또 다른 선택은 보존 정책에 따라 데이터를 삭제하는 사용자 지정 솔루션을 구현하는 것입니다. 예로는 데이터 수명 주기 작업을 관리하는 DLM(데이터 수명 주기 관리)이 있습니다. 이 솔루션은 Azure Data Factory, Microsoft Entra ID 및 Azure Key Vault와 같은 서비스와 함께 설계되었습니다.

자세한 내용은 Azure Data Factory를 사용하여 데이터 수명 주기 관리를 참조하세요.

요구 사항 3.2

권한 부여 후에는 중요한 인증 데이터를 저장하지 마세요(암호화된 경우라도). 중요한 인증 데이터가 수신되는 경우, 권한 부여 프로세스가 완료되면 모든 데이터를 복구할 수 없게 렌더링합니다.

사용자의 책임

(적용 대상: 요구 사항 3.2.1, 요구 사항 3.2.2, 요구 사항 3.2.3)

데이터 처리 및 보호는 워크로드와 관련된 문제이므로 이 아키텍처의 범위에 해당되지 않습니다. 다음은 일반적인 몇 가지 고려 사항입니다.

표준에 따라 중요한 인증 데이터는 전체 추적 데이터, 카드 유효성 검사 코드나 값, PIN 데이터로 구성됩니다. CHD 처리의 일부로 인증 데이터가 다음과 같은 원본에 노출되지 않았는지 확인합니다.

• Pod에서 내보내는 로그
• 예외 처리 루틴
• 파일 이름
• 캐시.

일반적인 지침으로 가맹점은 이 정보를 저장해서는 안 됩니다. 필요하면 비즈니스 타당성을 문서화합니다.

요구 사항 3.3

적법한 업무 요구 사항이 있는 담당자만 전체 PAN을 볼 수 있게 할 때와 같이 표시될 때 PAN을 마스킹합니다(표시할 최대 자릿수는 첫 6자리 및 마지막 4자리임).

사용자의 책임

PAN(기본 계정 번호)은 중요한 데이터로 간주되며 이 데이터가 노출되지 않도록 해야 합니다. 한 가지 방법은 마스킹을 통해 표시되는 자릿수를 줄이는 것입니다.

워크로드에서 데이터 마스킹을 구현하지 마세요. 대신 데이터베이스 수준 구문을 사용합니다. Azure Synapse Analytics를 포함하여 Azure SQL 서비스 라인은 애플리케이션 계층에서 노출을 줄이는 동적 데이터 마스킹을 지원합니다. 마스킹되지 않은 데이터를 볼 수 있는 사용자와 마스킹을 통해 노출되는 데이터 양을 정의하는 정책 기반 보안 기능입니다. 기본 제공 신용 카드 마스킹 방식은 지정된 필드의 마지막 4자리를 노출하고 상수 문자열을 신용 카드 형식 접두사로 추가합니다.

자세한 내용은 동적 데이터 마스킹을 참조하세요.

마스킹되지 않은 데이터를 클러스터로 가져와야 하는 경우 가능한 한 빨리 마스킹합니다.

요구 사항 3.4

다음 방식 중 하나를 사용하여 이동식 디지털 미디어, 백업 미디어 및 로그를 포함하여 저장된 어디서나 PAN을 읽을 수 없게 렌더링합니다.

• 강력한 암호화에 기반한 단방향 해시(해시는 전체 PAN이어야 함)
• 잘림(해시를 사용하여 PAN의 잘린 세그먼트를 대체할 수 없음)
• 인덱스 토큰 및 패드(패드를 안전하게 저장해야 함)
• 연결된 키 관리 프로세스 및 프로시저를 사용하는 강력한 암호화.

사용자의 책임

이 요구 사항의 경우 워크로드에서 직접 암호화를 사용해야 할 수 있습니다. PCI DSS 지침에서는 실제 공격을 견딜 수 있도록 업계에서 테스트한 알고리즘을 사용할 것을 권장합니다. 사용자 지정 암호화 알고리즘을 사용하지 마세요.

적절한 데이터 마스킹 기술도 이 요구 사항을 충족합니다. 모든 PAN(기본 계정 번호) 데이터를 마스킹해야 합니다. Azure Synapse Analytics를 포함하여 Azure SQL 서비스 라인에서는 동적 데이터 마스킹을 지원합니다. 요구 사항 3.3을 참조하세요.

PAN이 워크플로 프로세스의 일부로 노출되지 않았는지 확인합니다. 다음은 몇 가지 고려 사항입니다.

• PAN을 로그, 워크플로 로그 및 (예상 또는 예기치 않은) 예외 처리 로그 모두에 보관하지 마세요. 또한 HTTP 헤더와 같은 진단 데이터 흐름에서 이 데이터를 노출해서는 안 됩니다.

• PAN을 캐시 조회 키로 사용하거나 이 프로세스에서 생성된 파일 이름의 일부로 사용하지 마세요.

• 고객은 자유 형식 텍스트 필드에 묻지 않은 PAN을 제공할 수 있습니다. PAN 데이터와 유사한 모든 콘텐츠를 스크러빙하여 모든 자유 형식 텍스트 필드에 콘텐츠 유효성 검사 및 검색 프로세스가 준비되었는지 확인합니다.

요구 사항 3.4.1

파일 또는 열 수준 데이터베이스 암호화 대신 디스크 암호화를 사용하는 경우 논리적 액세스를 기본 운영 체제 인증 및 액세스 제어 메커니즘과 독립적으로 따로 관리해야 합니다(예: 로컬 사용자 계정 데이터베이스나 일반 네트워크 로그인 자격 증명 사용 안 함). 암호 해독 키는 사용자 계정과 연결되지 않아야 합니다.

사용자의 책임

일반적으로 AKS 클러스터에 상태를 저장하지 마세요. 스토리지 엔진 수준 암호화를 지원하는 외부 데이터 스토리지를 사용합니다.

Azure Storage에 저장된 모든 데이터는 강력한 암호화를 통해 암호화되고 암호 해독됩니다. Microsoft는 연결된 키를 관리합니다. 자체 관리형 암호화 키가 선호됩니다. 키가 스토리지 레이어에 인접하지 않도록 항상 스토리지 레이어 외부에서 암호화하고 암호화된 데이터만 스토리지 매체에 기록합니다.

Azure Storage를 사용하면 자체 관리형 키를 사용할 수도 있습니다. 자세한 내용은 Azure Storage 암호화용 고객 관리형 키를 참조하세요.

데이터베이스에서도 비슷한 기능을 사용할 수 있습니다. Azure SQL 옵션은 고객 관리형 키를 사용하여 Azure SQL 투명한 데이터 암호화를 참조하세요.

Azure Key Vault, Azure Managed HSM 또는 타사 키 관리 솔루션 같은 관리형 키 저장소에 키를 저장해야 합니다.

데이터를 임시 저장해야 하면 AKS의 호스트 암호화 기능을 사용하여 VM 노드에 저장된 데이터가 암호화되었는지 확인합니다.

요구 사항 3.5

저장된 카드 소유자 데이터가 공개되어 오용되는 것을 방지하는 데 사용되는 키를 보호하는 절차를 문서화하고 구현합니다.

사용자의 책임

이러한 점은 하위 섹션에 설명되어 있습니다.

• 암호화 키에 대한 최소 권한 액세스 방법을 유지합니다.
• Azure Key Vault 및 Microsoft Entra ID는 권한 부여 및 감사 로깅 요구 사항을 지원하도록 설계되었습니다. 자세한 내용은 Azure Key Vault 대한 인증 요청을 참조하세요.
• 암호화 디바이스에 저장된 키 암호화 키를 사용하여 모든 데이터 암호화 키를 보호합니다.
• Microsoft 관리형 키 대신 자체 관리형 키를 사용하는 경우 키 관리와 관련된 작업을 유지하는 프로세스와 문서가 있습니다.

요구 사항 3.5.1

서비스 공급자 전용 추가 요구 사항: 다음을 포함하는 암호화 아키텍처의 문서화된 설명을 유지합니다.

• 키 강도 및 만료일을 포함하여 카드 소유자 데이터의 보호를 위한 모든 알고리즘, 프로토콜 및 키의 상세 정보
• 각 키의 키 사용량에 대한 설명
• 키 관리에 사용되는 HSM 및 기타 SCD 인벤토리

사용자의 책임

중요한 정보(키, 연결 문자열 등)를 저장하는 한 가지 방법은 원시 Kubernetes Secret 리소스를 사용하는 것입니다. 미사용 시 암호화를 명시적으로 사용해야 합니다. 또는 Azure Key Vault와 같은 관리 저장소에 저장합니다. 두 가지 방법 중에서 관리 저장소 서비스를 사용하는 것이 좋습니다. 한 가지 장점은 키 회전과 같은 키 관리와 관련된 작업의 오버헤드가 줄어든다는 점입니다.

기본적으로 Azure는 고객별로 암호화된 모든 데이터에 Microsoft 관리형 키를 사용합니다. 그러나 일부 서비스에서는 암호화에 자체 관리형 키도 지원합니다. 미사용 암호화에 자체 관리형 키를 사용하는 경우 키 관리 작업을 처리하는 프로세스와 전략을 고려해야 합니다.

문서의 일부로 만료, 위치 및 유지 관리 계획 세부 정보와 같은 키 관리와 관련된 정보를 포함합니다.

요구 사항 3.5.2

암호화 키에 대한 액세스를 필요한 최소 보유자 수로 제한합니다.

사용자의 책임

키에 액세스할 수 있는 사용자 수를 최소화합니다. 그룹 기반 역할 할당을 사용하는 경우 반복 감사 프로세스를 설정하여 액세스 권한이 있는 역할을 검토합니다. 프로젝트 팀 구성원이 변경되면 권한에서 더 이상 관련이 없는 계정을 제거해야 합니다. 올바른 사용자만 액세스할 수 있어야 합니다. Microsoft Entra ID 액세스 검토를 사용하여 정기적으로 그룹 멤버 자격을 검토합니다.

JIT(Just-In-Time) 역할 할당, 시간 기반 역할 활성화 및 승인 기반 역할 활성화를 위해 대기 권한을 제거하는 것이 좋습니다. 예를 들어, Privileged Identity Management 사용을 고려해봅니다.

요구 사항 3.5.3

항상 다음 양식 중 하나 이상에 카드 소유자 데이터를 암호화/암호 해독하는 데 사용되는 비밀 및 프라이빗 키를 저장합니다.

• 데이터 암호화 키만큼 강력하며 데이터 암호화 키와 별도로 저장되는 키 암호화 키로 암호화됨
• 보안 암호화 디바이스(예: HSM(하드웨어(호스트) 보안 모듈) 또는 PTS 승인 상호 작용 지점 디바이스) 안
• 업계에서 허용되는 방법에 따라 둘 이상의 전체 길이 키 구성 요소 또는 키 공유

사용자의 책임

PCI-DSS 3.2.1 워크로드는 미사용 데이터 보호 전략의 일환으로 암호화 키를 두 개 이상 사용해야 합니다. DEK(데이터 암호화 키)는 CHD를 암호화하고 암호 해독하는 데 사용되지만 해당 DEK가 보호되도록 KEK(키 암호화 키)를 추가해야 합니다. 또한 KEK가 암호화 디바이스에 저장되도록 해야 합니다.

Azure Key Vault를 사용하여 DEK를 저장하고 Azure Dedicated HSM을 사용하여 KEK를 저장할 수 있습니다. HSM 키 관리에 대한 자세한 내용은 Azure Dedicated HSM이란?을 참조하세요.

요구 사항 3.6

다음을 포함하여 카드 소유자 데이터 암호화에 사용되는 암호화 키의 모든 키 관리 프로세스와 절차를 완전히 문서화하고 구현합니다.

사용자의 책임

(적용 대상: 요구 사항 3.6.1, 요구 사항 3.6.2, 요구 사항 3.6.3, 요구 사항 3.2.4)

Azure Key Vault를 사용하여 키, 인증서 및 연결 문자열과 같은 비밀을 저장하는 경우 무단 액세스로부터 보호합니다. Microsoft Defender for Key Vault에서 의심스러운 액세스 시도를 감지하고 경고를 생성합니다. 클라우드용 Microsoft Defender에서 이러한 경고를 볼 수 있습니다. 자세한 내용은 Microsoft Defender for Key Vault를 참조하세요.

키 관리에 대한 NIST 지침을 따릅니다. 자세한 내용은 다음을 참조하세요.

• 암호화 키 관리
• SP 800-133 Rev. 2, 암호화 키 생성 권장 사항
• SP 800-57 Part 1 Rev. 5, 키 관리 권장 사항

Microsoft Defender for Key Vault도 참조하세요.

요구 사항 3.6.7

암호화 키의 무단 대체를 방지합니다.

사용자의 책임

• 모든 키 저장소에서 진단을 사용합니다. Azure Monitor for Key Vault를 사용합니다. 로그와 메트릭을 수집하고 Azure Monitor로 보냅니다. 자세한 내용은 Azure Monitor for Key Vault를 사용하여 키 자격 증명 모음 서비스 모니터링을 참조하세요.
• 모든 소비자에게 읽기 전용 권한을 부여합니다.
• 관리 사용자 또는 주체를 위한 대기 권한을 두지 마세요. 대신 JIT(Just-In-Time) 역할 할당, 시간 기반 역할 활성화 및 승인 기반 역할 활성화를 사용합니다.
• 로그와 경고를 Microsoft Sentinel과 같은 SIEM(보안 정보 및 이벤트 관리) 솔루션에 통합하여 중앙 집중식 보기를 만듭니다.
• 경고와 알림, 특히 예기치 않은 변경에 대한 조치를 취합니다.

요구 사항 3.6.8

암호화 키 보유자가 키 보유자 책임을 인식하고 수락함을 공식적으로 인정하도록 하는 요구 사항입니다.

사용자의 책임

키 관리 운영을 담당하는 당사자의 책임을 설명하는 문서를 유지합니다.

요구 사항 3.7

저장된 카드 소유자 데이터를 보호하는 보안 정책과 운영 절차를 문서화하고 사용 중이며 모든 관련 당사자가 알고 있어야 합니다.

사용자의 책임

일반 문으로 문서를 만들고 모든 가상 사용자에 대한 일련의 최신 역할 가이드를 만듭니다. 신입 사원 교육 및 지속적인 교육을 수행합니다.

프로세스 및 정책에 대한 완전한 설명서를 유지 관리하는 것이 중요합니다. 여러 팀에서 미사용 및 전송 중에 데이터를 보호하는 데 참여합니다. 문서에서 모든 가상 사용자에 대한 역할 지침을 제공합니다. 역할에는 SRE, 고객 지원, 영업, 네트워크 운영, 보안 작업, 소프트웨어 엔지니어, 데이터베이스 관리자 등이 포함되어야 합니다. 담당자는 기술 세트가 최신 상태로 유지되도록 NIST 지침 및 미사용 데이터 전략을 학습해야 합니다. 교육 요구 사항은 요구 사항 6.5 및 요구 사항 12.6에서 해결됩니다.

요구 사항 4—개방된 공용 네트워크에서 카드 소유자 데이터의 전송 암호화

사용자의 책임

요구 사항 4.1

다음을 포함하여 강력한 암호화와 보안 프로토콜(예: TLS, IPSEC, SSH 등)을 사용하여 개방된 공용 네트워크를 통한 전송 중에 중요한 카드 소유자 데이터를 보호합니다.

사용자의 책임

공용 인터넷을 통해 전송되는 CHD(카드 소유자 데이터)를 암호화해야 합니다. 데이터는 모든 전송에 대한 암호화 지원이 줄어든 TLS 1.2 이상으로 암호화되어야 합니다. 모든 데이터 전송 서비스에서 TLS에 대한 TLS 이외의 리디렉션을 지원하지 않습니다.

디자인에는 TLS 종료 지점의 전략적 체인이 있어야 합니다. 데이터가 네트워크 홉을 통해 이동하므로 패킷 검사가 필요한 홉에서 TLS를 유지합니다. 클러스터의 수신 리소스에 최종 TLS 종료 지점이 최소한으로 있습니다. 클러스터 리소스 내에서 추가로 수행하는 것이 좋습니다.

Azure Policy를 사용하여 리소스 만들기를 제어합니다.

• HTTPS가 아닌 수신 리소스의 생성을 거부합니다.
• 게이트웨이를 통해 웹 트래픽이 터널링되고 있는지 확인하기 위해 클러스터의 공용 IP 또는 공용 부하 분산 장치 생성을 거부합니다.

자세한 내용은 Azure 암호화 개요를 참조하세요.

요구 사항 4.1.1

카드 소유자 데이터를 전송하거나 카드 소유자 데이터 환경에 연결된 무선 네트워크에서 업계 모범 사례(예: IEEE 802.11i)를 사용하여 인증 및 전송에 강력한 암호화를 구현하도록 합니다.

사용자의 책임

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

요구 사항 4.2

최종 사용자 메시징 기술(예: 이메일, 인스턴트 메시지, SMS, 채팅 등)을 사용하여 보호되지 않는 PAN을 전송하지 않습니다.

사용자의 책임

워크로드에서 이메일을 보내야 하는 경우 이메일 격리 게이트를 빌드하는 것이 좋습니다. 이 유효성 검사를 통해 모든 아웃바운드 메시지의 규정 준수 여부를 검사하고 중요한 데이터가 포함되지 않은지 확인할 수 있습니다. 이상적으로는 고객 지원 메시지에 이 방식을 사용하는 것도 좋습니다.

유효성 검사를 워크로드 수준과 변경 제어 프로세스에서 수행해야 합니다. 승인 게이트는 요구 사항을 이해해야 합니다.

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

요구 사항 4.3

카드 소유자 데이터 전송을 암호화하는 보안 정책과 운영 절차를 문서화하고 사용 중이며 모든 관련 당사자가 알고 있어야 합니다.

사용자의 책임

프로세스 및 정책에 대한 완전한 설명서를 유지 관리하는 것이 중요합니다. TLS(전송 계층 보안)에 대한 정책을 관리하는 경우에 특히 그렇습니다. 다음은 몇 가지 영역입니다.

• 공용 인터넷 수신 지점. 예로는 TLS 암호화에 대한 Azure Application Gateway 지원입니다.
• 경계 네트워크와 워크로드 Pod 간의 네트워크 홉.
• Pod 간 암호화(구현된 경우). 여기에는 서비스 메시 구성에 대한 세부 정보가 포함될 수 있습니다.
• 스토리지에 대한 Pod(아키텍처의 일부인 경우).
• TLS, 결제 게이트웨이 또는 사기 탐지 시스템을 사용하는 Azure PaaS 서비스, 외부 서비스에 대한 Pod입니다.

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

다음 단계

맬웨어에 대한 모든 시스템 보호 및 정기적인 바이러스 백신 소프트웨어나 프로그램 업데이트 보안 시스템과 애플리케이션 개발 및 유지