이 가이드는 결제 카드 산업 데이터 보안 표준(PCI DSS) 요구사항에 대한 고객의 책임을 구현할 때 Google Kubernetes Engine(GKE) 애플리케이션의 고유한 문제를 해결하는 데 도움이 되기 위해 작성되었습니다. 면책 조항:
면책조항: 이 가이드는 정보 제공만을 목적으로 합니다. 본 가이드에서 Google이 제공하는 정보 또는 권장사항은 법적 자문에 해당하지 않습니다. 서비스의 특정한 사용을 적절하게 독립적으로 평가하여 법률 및 규정 준수 의무를 이행할 책임은 각 고객에게 있습니다.
PCI DSS 규정 준수 및 GKE 소개
결제 카드 데이터를 처리하려면 데이터가 온프레미스 데이터베이스에 있든 클라우드에 있든 관계없이 데이터를 보호해야 합니다. PCI DSS는 카드 소지자의 데이터 보안을 촉진하고 향상시키며 전 세계적으로 일관된 데이터 보안 조치를 광범위하게 채택하도록 하기 위해 개발되었습니다. PCI DSS는 신용카드 데이터를 보호하기 위한 기술 및 운영 요구사항의 기준을 제공합니다. PCI DSS는 판매자, 결제 대행업체, 매입사, 발급기관, 서비스 제공업체를 포함하여 결제 카드 처리와 관련된 모든 법인에 적용됩니다. PCI DSS는 카드 소지자 데이터(CHD), 민감한 인증 데이터(SAD) 또는 둘 다를 저장, 처리 또는 전송하는 다른 모든 법인에도 적용됩니다.
최근 많은 레거시 워크로드가 가상 머신(VM) 기반 아키텍처에서 컨테이너화된 아키텍처로 마이그레이션됨에 따라 컨테이너화된 애플리케이션이 널리 사용되고 있습니다. Google Kubernetes Engine은 컨테이너화된 애플리케이션을 배포하기 위한 관리형 환경으로 프로덕션에 즉시 사용할 수 있습니다. GKE는 개발자 생산성, 리소스 효율성, 자동화된 작업, 오픈소스 유연성에 Google의 최신 혁신 기술을 적용하여 TTM(Time To Market)을 단축합니다.
클라우드에서 규정 준수는 공동의 책임입니다. GKE(Autopilot 및 Standard 작업 모드 모두)를 포함한 Google Cloud는 PCI DSS 요구사항을 준수합니다. 공유 책임 규정에 책임이 요약되어 있습니다.
주요 대상
- PCI 규정을 준수하는 워크로드를 GKE가 포함된 Google Cloud로 가져오려는 고객
- 개발자, 보안 담당자, 규정 준수 담당자, IT 관리자, 그리고 PCI DSS 요구사항의 준수를 관리하고 구현할 책임이 있는 기타 직원
시작하기 전에
아래에 나오는 권장사항을 따르려면 다음을 사용해야 할 수 있습니다.
- Google Cloud 조직, 폴더, 프로젝트 리소스
- Identity and Access Management(IAM)
- Google Kubernetes Engine
- Google Cloud VPC
- Google Cloud Armor
- Cloud Data Loss Prevention API(민감한 정보 보호의 일부)
- IAP(Identity-Aware Proxy)
- Security Command Center
이 가이드는 컨테이너와 GKE에 익숙한 사용자를 대상으로 합니다.
범위
이 가이드에서는 다음과 같이 GKE와 관련된 PCI DSS의 요구사항을 확인하고 이를 충족하기 위한 안내를 제공합니다. 이 내용은 표준 버전 4.0을 기준으로 작성되었습니다. 이 가이드에서 PCI DSS의 요구사항을 모두 다루지는 않습니다. 이 가이드에 제공된 정보는 조직의 PCI DSS 규정 준수 활동에 도움이 될 수 있지만 완전한 조언이 아닙니다. 조직의 공식 검증을 위해서는 PCI 공인 보안 평가자(QSA) 활용이 권장됩니다.
용어
이 섹션에는 이 가이드에서 사용되는 용어가 정의되어 있습니다. 자세한 내용은 PCI DSS 용어집을 참조하세요.
- CHD
카드 소지자 데이터. 최소한 전체 기본 계정 번호(PAN)로 구성됩니다. 카드 소지자 데이터는 전체 PAN과 아래의 정보가 조합된 형식으로 표시될 수도 있습니다.
- 카드 소지자 이름
- 만료일 또는 서비스 코드
- 민감한 인증 데이터(SAD)
- CDE
카드 소지자 데이터 환경. 카드 소지자 데이터 또는 민감한 인증 데이터를 저장, 처리 또는 전송하는 사람, 프로세스, 기술입니다.
- PAN
기본 계정 번호: PCI DSS에 따라 보호해야 하는 중요한 카드 소지자 데이터입니다. PAN은 결제 카드(신용 및 직불)의 고유한 번호로서 일반적으로 16자리 숫자이며 발급기관과 카드 소지자 계정을 식별합니다.
- PIN
개인 식별 번호. 사용자와 시스템에만 알려진 숫자 비밀번호이며 사용자를 시스템에 인증하는 데 사용됩니다.
- QSA
자격을 갖춘 보안 평가자. PCI 보안 표준 위원회에서 감사 및 규정 준수 분석을 수행하도록 승인된 사람입니다.
- SAD
민감한 인증 데이터. PCI 규정 준수에서 카드 발급기관이 거래를 승인하는 데 사용하는 데이터입니다. 카드 소지자 데이터와 마찬가지로 PCI DSS에는 SAD의 보호가 필요합니다. 또한 SAD는 판매자와 결제 대행업체가 보관할 수 없습니다. SAD에는 다음이 포함됩니다.
- 마그네틱 선의 '추적' 데이터
- 칩과 미접촉 결제 카드에서 생성된 '추적에 상응하는 데이터'
- 온라인 및 무카드(card-not-present) 거래에 사용되는 보안 유효성 검사 코드(예: 카드에 인쇄된 3~4자리 숫자)
- PIN 및 PIN 차단
- 세분화
PCI DSS와 관련하여 CDE를 법인 네트워크의 나머지 부분에서 분리하는 방법. 세분화가 PCI DSS의 요구사항은 아니지만 다음을 줄이는 데 유용한 방법으로 권장됩니다.
- PCI DSS 평가의 범위와 비용
- PCI DSS 제어를 구현하고 유지 관리하는 비용과 어려움
- 기업에 미치는 위험(카드 소지자 데이터를 더 강력하게 제어되는 더 적은 수의 위치로 통합하여 위험이 감소됨)
카드 소지자 데이터 환경의 세분화
카드 소지자 데이터 환경(CDE)은 카드 소지자 데이터 또는 민감한 인증 데이터를 저장, 처리 또는 전송하는 사람, 프로세스, 기술로 구성됩니다. GKE와 관련하여 CDE는 다음과 같은 요소로 구성됩니다.
- 보안 서비스를 제공하는 시스템(예: IAM)
- 세분화를 용이하게 하는 시스템(예: 프로젝트, 폴더, 방화벽, Virtual Private Cloud(VPC), 서브넷)
- 카드 소지자 데이터를 저장, 처리 또는 전송하는 애플리케이션 pod 및 클러스터. 적절한 세분화가 이루어지지 않으면 전체 클라우드 풋프린트가 PCI DSS의 범위에 포함될 수 있습니다.
PCI DSS의 범위가 아닌 것으로 간주되려면 범위 밖에 있는 시스템 구성요소의 보안이 침해되어도 CDE의 보안에 영향을 미치지 않도록 시스템 구성요소가 CDE에서 적절하게 격리되어야 합니다.
CDE의 범위를 줄이기 위한 중요한 기본 요건은 카드 소지자 데이터의 스토리지, 처리, 전송과 관련된 비즈니스 요구사항 및 프로세스를 명확하게 이해하는 것입니다. 불필요한 데이터를 삭제하고 필요한 데이터를 통합하여 카드 소지자 데이터를 가능한 한 적은 수의 위치로 제한하려면 오랜 비즈니스 관행을 재설계해야 할 수도 있습니다.
Google Cloud에서 다양한 방법으로 CDE를 적절하게 세분화할 수 있습니다. 이 섹션에서는 다음 방법을 설명합니다.
- 리소스 계층 구조를 사용하여 논리적 세분화
- VPC와 서브넷을 사용하여 네트워크 세분화
- VPC를 사용하여 서비스 수준 세분화
- 모든 범위 내 클러스터에 대한 기타 고려사항
리소스 계층 구조를 사용하여 논리적 세분화
Google Cloud의 리소스 계층 구조를 사용하여 조직 구조 내의 CDE를 분리하는 방법에는 여러 가지가 있습니다. Google Cloud 리소스는 계층적으로 구성됩니다. 조직 리소스는 Google Cloud 리소스 계층 구조의 루트 노드입니다. 폴더와 프로젝트는 조직 리소스에 속합니다. 폴더에는 프로젝트와 다른 폴더가 포함될 수 있습니다. 폴더는 폴더 수준의 IAM 권한을 통해 폴더 계층 구조의 리소스에 대한 액세스를 제어하는 데 사용되며, 유사한 프로젝트를 그룹화하는 데도 사용됩니다. 프로젝트는 모든 리소스와 IAM 적용 지점의 트러스트 경계입니다.
폴더 내에서 PCI 범위에 있는 모든 프로젝트를 그룹화하여 폴더 수준에서 분리할 수 있습니다. 모든 범위 내 PCI 클러스터와 애플리케이션에 하나의 프로젝트를 사용하거나, 각 범위 내 PCI 애플리케이션마다 하나의 프로젝트와 클러스터를 만든 다음 이를 Google Cloud 리소스를 구성하는 데 사용할 수도 있습니다. 범위 내의 워크로드와 범위 밖의 워크로드는 서로 다른 프로젝트에 유지하는 것이 좋습니다.
VPC 네트워크와 서브넷을 사용하여 네트워크 세분화
Virtual Private Cloud(VPC)와 서브넷을 사용하여 네트워크를 프로비저닝하고 CDE 관련 리소스를 그룹화하거나 분리할 수 있습니다. VPC는 퍼블릭 클라우드의 섹션을 논리적으로 격리한 것입니다. VPC 네트워크는 Compute Engine 가상 머신(VM) 인스턴스와 GKE를 포함하여 VM 인스턴스를 활용하는 서비스에 확장 가능하고 유연한 네트워킹을 제공합니다. 자세한 내용은 VPC 개요를 읽고 권장사항 및 참조 아키텍처를 참조하세요.
VPC 서비스 제어와 Google Cloud Armor를 사용하여 서비스 수준 세분화
VPC와 서브넷은 세분화를 제공하고 CDE를 분리하는 경계를 만들지만, VPC 서비스 제어는 레이어 7에서 보안 경계를 강화합니다. VPC 서비스 제어를 사용하여 범위 내 CDE 프로젝트 주위에 경계를 만들 수 있습니다. VPC 서비스 제어는 다음 기능을 제공합니다.
- 인그레스 제어. 승인된 ID와 클라이언트만 보안 경계 안으로 진입하도록 허용됩니다.
- 이그레스 제어. 보안 경계 내의 ID와 클라이언트에는 승인된 대상만 허용됩니다.
Google Cloud Armor를 사용하여 IP 주소 목록을 만든 다음 Google Cloud 네트워크의 에지에서 HTTP(S) 부하 분산기에 대한 액세스를 허용하거나 거부할 수 있습니다. 사용자 및 악성 트래픽에 최대한 근접한 IP 주소를 검사하여 악성 트래픽이 리소스를 소비하거나 VPC 네트워크에 들어오는 것을 방지합니다.
범위 내 프로젝트의 서비스 경계를 정의하려면 VPC 서비스 제어를 사용하세요. 이 경계는 VPC 인그레스 및 이그레스 트래픽뿐만 아니라 VM에서 서비스로의 경로와 서비스에서 VM으로의 경로를 제어합니다.
보안 네트워크와 시스템 빌드 및 유지
보안 네트워크를 구축하고 유지관리하려면 PCI DSS의 요구사항 1과 2를 따라야 합니다.
요구사항 1
CDE로 들어오는 또는 CDE에서 나가는 카드 소지자 데이터와 트래픽을 보호하기 위한 방화벽 구성을 설치하고 유지관리합니다.
컨테이너와 GKE의 네트워킹 개념은 기존 VM과 다릅니다. pod는 NAT 없이, 노드 간에도 서로 직접 통신할 수 있습니다. 이렇게 하면 보다 복잡한 시스템을 관리하는 데 익숙한 사용자에게는 놀라울 만큼 단순한 네트워크 토폴로지가 생성됩니다. GKE 네트워크 보안의 첫 번째 단계는 이러한 네트워킹 개념을 익히는 것입니다.
요구사항 1의 개별 요구사항을 살펴보기 전에 먼저 GKE와 관련된 아래의 네트워킹 개념을 살펴보세요.
방화벽 규칙. 방화벽 규칙은 노드에 대한 트래픽을 제한하는 데 사용됩니다. GKE 노드는 Compute Engine 인스턴스로 프로비저닝되며 다른 인스턴스와 동일한 방화벽 메커니즘을 사용합니다. 네트워크 안에서 태그를 사용하여 각 인스턴스에 이러한 방화벽 규칙을 적용할 수 있습니다. 각 노드 풀은 규칙에서 사용할 수 있는 자체 태그 집합을 수신합니다. 기본적으로 노드 풀에 속한 각 인스턴스는 이 노드 풀이 속한 특정 GKE 클러스터를 식별하는 태그를 수신합니다. 이 태그는 GKE에서 자동으로 생성하는 방화벽 규칙에 사용됩니다. Google Cloud CLI에서
--tags플래그를 사용하여 클러스터 또는 노드 풀 생성 시에 커스텀 태그를 추가할 수 있습니다.네트워크 정책. 네트워크 정책을 사용하면 pod 간의 네트워크 연결을 제한할 수 있으므로, pod에 보안 문제가 발생할 경우 클러스터 내의 네트워크 피벗팅과 측면 이동을 제한할 수 있습니다. 네트워크 정책을 사용하려면 GKE 클러스터를 만들 때 이 기능을 명시적으로 사용 설정해야 합니다. 기존 클러스터에서 이 기능을 사용 설정할 수 있지만 그러면 클러스터 노드가 다시 시작됩니다. 기본 동작으로 모든 pod 간 통신이 항상 열려 있습니다. 따라서 네트워크를 세분화하려면 pod 수준의 네트워킹 정책을 적용해야 합니다. GKE에서 Kubernetes Network Policy API를 사용하거나
kubectl도구를 사용하여 네트워크 정책을 정의할 수 있습니다. 이러한 pod 수준의 트래픽 정책 규칙은 클러스터 내에서 서로 액세스할 수 있는 pod와 서비스를 결정합니다.네임스페이스. 네임스페이스는 Kubernetes 클러스터 내에서 리소스 세분화를 허용합니다. Kubernetes에는 기본 네임스페이스가 바로 사용할 수 있도록 제공되지만, 클러스터 내에 여러 개의 네임스페이스를 만들 수 있습니다. 네임스페이스는 논리적으로 서로 분리되어 있습니다. 네임스페이스는 클러스터의 pod, 서비스, 배포를 위한 범위를 제공하므로 하나의 네임스페이스와 상호 작용하는 사용자는 다른 네임스페이스의 콘텐츠를 볼 수 없습니다. 하지만 동일한 클러스터 내의 네임스페이스는 네임스페이스 간의 통신을 제한하지 않습니다. 바로 이러한 경우에 네트워크 정책이 사용됩니다. 네임스페이스 구성에 대한 자세한 내용은 네임스페이스 권장사항 블로그 게시물을 참조하세요.
다음 다이어그램은 앞에 나온 개념 간의 관계와 클러스터, 노드, pod 같은 기타 GKE 구성요소를 나타냅니다.
요구사항 1.1
네트워크 보안 제어를 설치하고 유지관리할 수 있도록 프로세스와 메커니즘을 정의하고 이해합니다.
요구사항 1.1.2
네트워크 구성요소를 관리하기 위한 그룹, 역할, 책임을 명시합니다.
Google Cloud에서 대부분의 서비스에 구성하듯이 IAM 역할을 구성하여 GKE에 대한 승인을 설정해야 합니다. IAM 역할을 구성한 경우 Kubernetes 역할 기반 액세스 제어(RBAC) 구성을 Kubernetes 승인 전략의 일부로 추가해야 합니다.
기본적으로 모든 IAM 구성은 프로젝트 내의 Google Cloud 리소스와 모든 클러스터에 적용됩니다. Kubernetes RBAC 구성은 각 Kubernetes 클러스터의 리소스에 적용되며, 네임스페이스 수준에서 세분화된 승인을 구현합니다. GKE를 사용하면 이러한 승인 방식이 동시에 작동하며, 사용자 권한이 할당된 IAM 및 RBAC 역할을 통합적으로 잘 나타냅니다.
- IAM을 사용하여 GKE에서 네트워크 구성요소의 논리적 관리를 위한 그룹, 역할, 책임을 제어합니다.
- Kubernetes RBAC를 사용하여 Kubernetes 클러스터 내 네트워크 정책에 세분화된 권한을 부여하고, pod 간 트래픽을 제어하고, 비CDE 사용자의 승인되지 않은 또는 우발적인 변경을 방지합니다.
- 모든 IAM 및 RBAC 사용자와 권한을 정당화할 수 있습니다. 일반적으로 QSA는 제어를 테스트할 때 IAM 및 RBAC 샘플의 비즈니스 근거를 찾습니다.
요구사항 1.2
네트워크 보안 제어(NSC)가 구성되고 유지됩니다.
먼저 GKE 노드를 실행하는 Compute Engine 인스턴스에 방화벽 규칙을 구성합니다. 방화벽 규칙은 이러한 클러스터 노드를 보호합니다.
그런 다음 클러스터에서 흐름을 제한하고 pod를 보호하도록 네트워크 정책을 구성합니다. 네트워크 정책은 pod 그룹이 서로 통신하고 다른 네트워크 엔드포인트와 통신하는 방법을 지정합니다. GKE의 네트워크 정책 적용을 사용하여 클러스터의 pod와 서비스 간의 통신을 제어할 수 있습니다. 클러스터를 더 세분화하려면 클러스터 내에 여러 개의 네임스페이스를 만드세요. 네임스페이스는 논리적으로 서로 분리되어 있습니다. 네임스페이스는 클러스터의 pod, 서비스, 배포를 위한 범위를 제공하므로 하나의 네임스페이스와 상호 작용하는 사용자는 다른 네임스페이스의 콘텐츠를 볼 수 없습니다. 하지만 동일한 클러스터 내의 네임스페이스는 네임스페이스 간의 통신을 제한하지 않습니다. 바로 이러한 경우에 네트워크 정책이 사용됩니다. 네임스페이스는 Kubernetes 클러스터 내에서 리소스 세분화를 허용합니다. 네임스페이스 구성에 대한 자세한 내용은 네임스페이스 권장사항 블로그 게시물을 참조하세요.
기본적으로 네임스페이스에 정책이 없으면 해당 네임스페이스의 pod와 주고 받는 모든 인그레스 및 이그레스 트래픽이 허용됩니다. 예를 들면 모든 pod를 선택하지만 이러한 pod로의 인그레스 트래픽을 허용하지 않는 네트워크 정책을 만드는 방법으로 네임스페이스의 기본 격리 정책을 만들 수 있습니다.
요구사항 1.2.2
요구사항 6.5.1에 정의된 변경 제어 프로세스에 따라 네트워크 연결 및 NSC 구성에 대한 모든 변경사항을 승인 및 관리해야 합니다.
네트워킹 구성 및 인프라를 코드로 처리하려면 변경 관리 및 변경 제어 프로세스의 일환으로 지속적 통합 및 지속적 배포(CI/CD) 파이프라인을 설정해야 합니다.
Cloud Deployment Manager 또는 Terraform 템플릿을 CI/CD 파이프라인의 일부로 사용하여 클러스터에 네트워크 정책을 만들 수 있습니다. Deployment Manager 또는 Terraform을 사용하면 구성과 인프라를 현재 프로덕션 또는 다른 환경의 일관된 사본을 재현 가능한 코드로 처리할 수 있습니다. 그런 다음 단위 테스트와 기타 테스트를 작성하여 네트워크 변경사항이 예상대로 작동하도록 할 수 있습니다. 승인이 포함된 변경 제어 프로세스는 버전 저장소에 저장된 구성 파일을 통해 관리할 수 있습니다.
Terraform 구성 검사기를 사용하면 보안 및 거버넌스 정책을 적용하는 제약 조건을 정의할 수 있습니다. CI/CD 파이프라인에 구성 검사기를 추가하여 워크플로에 단계를 추가할 수 있습니다. 이 단계는 Terraform 계획을 검사하여 위반 사항이 발견되면 계획을 거부합니다.
요구사항 1.2.5
허용되는 모든 서비스, 프로토콜, 포트가 식별 및 승인되어 있고 비즈니스 요구가 정의되어 있어야 합니다.
GKE 클러스터의 인그레스를 강력하게 제어하려면 승인된 네트워크를 사용하여 클러스터의 제어 영역에 도달할 수 있는 특정 IP 범위를 제한할 수 있습니다. GKE는 전송 계층 보안(TLS)과 인증을 모두 사용하여 공개 인터넷에서 클러스터 마스터 엔드포인트에 대한 보안 액세스를 제공합니다. 이러한 액세스를 통해 클러스터를 어디서나 유연하게 관리할 수 있습니다. 승인된 네트워크를 사용하면 액세스를 지정된 IP 주소 집합으로 제한할 수 있습니다.
Google Cloud Armor를 사용하여 GKE 호스팅 애플리케이션의 IP 거부 목록 및 허용 목록과 보안 정책을 만들 수 있습니다. GKE 클러스터에서 들어오는 트래픽은 Cloud Load Balancing의 구성요소인 HTTP(S) 부하 분산에 의해 처리됩니다. 일반적으로 HTTP(S) 부하 분산기는 Kubernetes 인그레스 객체에서 구성 정보를 가져오는 GKE 인그레스 컨트롤러에 의해 구성됩니다. 자세한 내용은 GKE를 사용하여 Google Cloud Armor 정책을 구성하는 방법을 참조하세요.
요구사항 1.3
카드 소지자 데이터 환경에 대한 네트워크 액세스는 제한되어 있어야 합니다.
민감한 정보를 비공개로 유지하려면 VPC 서비스 제어 및 비공개 Google 액세스를 사용하여 VPC 네트워크 내의 GKE 클러스터와 온프레미스 하이브리드 배포 간의 비공개 통신을 구성합니다.
요구사항 1.3.1
CDE에 대한 인바운드 트래픽이 다음과 같이 제한되어야 합니다.
- 필요한 트래픽으로만 제한됩니다.
- 다른 모든 트래픽은 특히 거부됩니다.
인바운드 인터넷 트래픽을 해당 클러스터로만 제한하려면 GKE를 사용하는 Cloud NAT 설정을 구현하는 방법을 고려해 보세요. CDE에서 비공개용 클러스터를 위한 비공개 클러스터를 설정할 수 있습니다. 비공개 클러스터에서 노드는 내부 RFC 1918 IP 주소만 가지므로 워크로드가 공개 인터넷에서 격리됩니다.
요구사항 1.4
신뢰할 수 있는 네트워크와 신뢰할 수 없는 네트워크 사이의 네트워크 연결을 통제해야 합니다.
요구사항 1.3에 나열된 것과 동일한 방법을 사용해서 이 요구사항을 해결할 수 있습니다.
요구사항 1.4.3
위조된 소스 IP 주소가 신뢰할 수 있는 네트워크에 들어오는 것을 감지하고 차단하기 위해 스푸핑 방지 조치를 구현해야 합니다.
위조된 소스 IP 주소가 네트워크에 들어오는 것을 감지하고 차단하기 위해 GKE pod와 클러스터에서 별칭 IP 주소를 사용하여 스푸핑 방지 대책을 구현합니다. 별칭 IP 범위를 사용하는 클러스터를 VPC 기반 클러스터라고 부릅니다.
요구사항 1.4.5
내부 IP 주소 및 라우팅 정보 공개는 승인된 당사자로만 제한됩니다.
GKE IP 매스커레이드 에이전트를 사용하여 클러스터의 다대일 IP 주소 변환을 위한 네트워크 주소 변환(NAT)을 수행할 수 있습니다. 매스커레이딩은 단일 주소 뒤에서 여러 소스 IP 주소를 마스킹합니다.
요구사항 2
모든 시스템 구성요소에 보안 구성을 적용해야 합니다.
요구사항 2는 기본값과 공급업체에서 제공한 사용자 인증 정보를 삭제하여 보안 매개변수를 강화하는 방법을 지정합니다. 클러스터를 강화하는 것은 고객의 책임입니다.
요구사항 2.2
시스템 구성요소가 안전하게 구성되고 관리됩니다.
이 표준이 모든 알려진 보안 취약점을 해결하고 업계에서 인정하는 시스템 보안 강화 표준을 따르는지 확인하세요. 업계에서 인정하는 시스템 강화 표준의 출처는 다음을 포함하되 이에 국한되지 않습니다.요구사항 2.2.4
필요한 서비스, 프로토콜, 데몬, 함수만 사용 설정하고 모든 불필요한 기능은 삭제하거나 사용 중지해야 합니다.
요구사항 2.2.5
- 비즈니스 근거가 설명되어 있어야 합니다.
- 안전하지 않은 서비스, 프로토콜, 데몬 사용 위험을 줄여주는 추가적인 보안 기능을 설명 및 구현해야 합니다.
요구사항 2.2.6
오용 방지를 위해 시스템 보안 매개변수를 구성해야 합니다.
사전 배포
컨테이너를 GKE로 이전하기 전에 다음 작업을 수행하는 것이 좋습니다.
- 신뢰할 수 있는 소스로 빌드, 유지관리, 취약성 검사가 수행된 컨테이너 관리형 기본 이미지로 시작합니다. 개발자가 사용할 수 있는 '유효하다고 확인된' 또는 '우수한' 기본 이미지의 집합을 만드는 것이 좋습니다. 더 제한적인 옵션은 distroless 이미지 또는 scratch 기본 이미지를 사용하는 것입니다.
- Artifact Analysis를 사용하여 컨테이너 이미지의 취약점을 검사합니다.
- 컨테이너에 승인되고 신뢰할 수 있는 라이브러리와 바이너리만 포함하도록 내부 DevOps/SecOps 정책을 설정합니다.
설정 시
설정 시 권장사항은 다음과 같습니다.
- 기본 Container-Optimized OS를 GKE의 노드 이미지로 사용합니다. Container-Optimized OS는 Chromium OS를 기반으로 하며 노드 보안에 최적화되어 있습니다.
- 애플리케이션을 실행하는 클러스터에 노드 자동 업그레이드를 사용 설정합니다. 이 기능은 노드를 관리형 제어 영역에서 실행 중인 Kubernetes 버전으로 자동 업그레이드하여 안정성과 보안을 향상시킵니다.
- 자동 복구 노드를 사용 설정합니다. 이 기능을 사용 설정하면 GKE에서 주기적으로 노드의 상태를 확인 및 사용하여 노드를 복구해야 하는지 판단합니다. 노드를 복구해야 하는 경우 노드가 드레이닝되고 새로운 노드가 생성되어 클러스터에 추가됩니다.
- Cloud Monitoring 및 Cloud Logging을 사용 설정하면 보안 이벤트 및 노드 상태를 비롯한 모든 이벤트를 볼 수 있습니다. 보안 문제가 발생할 경우 알림을 받도록 Cloud Monitoring 알림 정책을 만듭니다.
- GKE 노드에 최소 권한 서비스 계정을 적용합니다.
- Google Cloud CIS 벤치마크 가이드의 GKE 섹션을 검토하고 적용합니다(적용 가능한 경우). Kubernetes 감사 로깅은 기본적으로 이미 사용 설정되어 있으며,
kubectl및 GKE API에 대한 요청의 로그는 모두 Cloud 감사 로그에 기록됩니다. - 감사 로깅을 구성합니다.
계정 데이터 보호
카드 소지자 데이터를 보호하려면 PCI DSS의 요구사항 3과 4를 따라야 합니다.
요구사항 3
저장된 계정 데이터를 보호해야 합니다.
PCI DSS 요구사항 3은 암호화, 잘라내기, 마스킹, 해싱과 같은 보호 기법이 카드 소지자 데이터 보호의 중요한 구성요소임을 명시합니다. 침입자가 적절한 암호화 키를 사용하지 않고 다른 보안 제어를 우회하여 암호화된 데이터에 액세스할 수 있게 되면 그 사람이 데이터를 읽을 수 없고 사용할 수 없게 됩니다.
저장된 데이터를 보호하는 다른 방법을 잠재적인 위험을 완화하는 기회로 고려할 수도 있습니다. 예를 들어 위험을 최소화하는 방법으로는 절대적으로 필요한 경우가 아니면 카드 소지자 데이터를 저장하지 않고, 전체 PAN이 필요하지 않으면 카드 소지자 데이터를 자르고, 이메일이나 인스턴트 메시지와 같은 최종 사용자 메시징 기술을 사용하여 보호되지 않는 PAN을 전송하지 않는 방법이 있습니다.
Google Cloud에서 실행될 때 CHD가 결제 처리 흐름의 일부로 지속될 수 있는 시스템의 예시는 다음과 같습니다.
- Cloud Storage 버킷
- BigQuery 인스턴스
- Datastore
- Cloud SQL
CHD가 의도치 않게 이메일 또는 고객 서비스 커뮤니케이션 로그에 저장될 수 있습니다. 민감한 정보 보호를 사용하여 범위 내 환경을 결제 처리 시스템으로 제한하도록 이러한 데이터 스트림을 필터링하는 것이 좋습니다.
Google Cloud에서 데이터는 미사용 시 기본적으로 암호화되고 전송 중에 물리적 경계를 통과할 때 기본적으로 암호화됩니다. 이러한 보호를 사용 설정하기 위한 추가 구성은 필요하지 않습니다.
요구사항 3.5
저장된 위치에 관계없이 기본 계정 번호(PAN)를 안전하게 보호해야 합니다.
PAN 데이터를 읽을 수 없게 만드는 메커니즘 중 하나는 토큰화입니다. 자세한 내용은 PCI DSS에 해당하는 민감한 카드 소지자 데이터 토큰화에 대한 솔루션 가이드를 참조하세요.
DLP API를 사용하여 카드 소지자 데이터를 검사, 발견, 보고할 수 있습니다. 민감한 정보 보호는 Cloud Storage, BigQuery, Datastore에서 12~19자리의 PAN 데이터에 대한 검사와 분류를 기본적으로 지원합니다. 그리고 추가 데이터 소스, 커스텀 워크로드, 애플리케이션을 지원하는 스트리밍 콘텐츠 API도 제공합니다. 또한 DLP API를 사용하여 데이터를 잘라내거나(수정) 해싱할 수도 있습니다.
요구사항 3.6
저장된 계정 데이터 보호에 사용되는 암호화 키를 안전하게 보호해야 합니다.
Cloud Key Management Service(KMS)는 암호화 키를 위한 관리형 스토리지 시스템입니다. KMS는 암호화 키를 생성, 사용, 순환, 폐기할 수 있습니다. Cloud KMS는 카드 소지자 데이터와 같은 보안 비밀을 직접 저장하지는 않지만 이러한 데이터를 암호화하는 데 사용될 수 있습니다.
Kubernetes의 맥락에서 보안 비밀은 비밀번호, 토큰, 키와 같은 민감한 정보를 저장하고 관리할 수 있게 해주는 Kubernetes 보안 비밀 객체입니다.
기본적으로 Google Cloud는 미사용 고객 콘텐츠를 암호화합니다. 사용자가 별도 작업을 수행하지 않아도 GKE가 이러한 기본 암호화를 처리하고 관리합니다. 애플리케이션 레이어 보안 비밀 암호화는 보안 비밀과 같이 민감한 정보에 추가 보안 레이어를 제공합니다. 이 기능을 사용하면 Cloud KMS에서 관리하는 키를 제공하여 애플리케이션 레이어에서 데이터를 암호화할 수 있습니다. 이렇게 하면 클러스터의 Kubernetes 구성 스토리지 인스턴스 복사본에 액세스하는 공격자로부터 보호할 수 있습니다.
요구사항 4
개방형 공개 네트워크를 통해 전송 중 강력한 암호화로 카드 소지자 데이터를 보호해야 합니다.
범위 내 데이터는 악의적인 개인이 쉽게 액세스할 수 있는 네트워크(예: 공개 네트워크)를 통해 전송되는 동안 암호화되어야 합니다.
Istio는 기존의 분산형 애플리케이션에 투명하게 레이어링되는 오픈소스 서비스 메시입니다. Istio는 마이크로서비스 간 트래픽의 인증, 승인, 암호화를 확장 가능한 방식으로 관리합니다. 이는 로깅 플랫폼, 텔레메트리 또는 정책 시스템에 통합할 수 있는 API가 포함된 플랫폼입니다. Istio의 기능 집합을 사용하면 분산된 마이크로서비스 아키텍처를 효율적으로 실행하고 마이크로서비스를 보호, 연결, 모니터링하는 일관된 방법을 제공할 수 있습니다.
요구사항 4.1
개방형 공개 네트워크를 통해 전송 중 강력한 암호화로 카드 소지자 데이터를 보호하기 위한 프로세스와 메커니즘을 정의하고 설명해야 합니다.
Istio를 사용하여 부하 분산, 서비스 간 인증, 모니터링 기능을 갖춘 배포된 서비스의 네트워크를 만들 수 있습니다. 또한 Istio를 사용하면 상호 TLS를 기반으로 하는 강력한 ID 기반 인증과 승인을 통해 클러스터에서 안전한 서비스 간 통신을 제공할 수도 있습니다. 상호 TLS(mTLS)는 두 번 수행되는 TLS 핸드셰이크이며, 일방적인 클라이언트-서버 트러스트와 달리 양방향으로 동일한 수준의 트러스트를 설정합니다.
Istio를 사용하면 애플리케이션 내의 각 GKE pod에 TLS 인증서를 배포할 수 있습니다. pod에서 실행되는 서비스는 mTLS를 사용하여 피어 ID를 강력하게 식별할 수 있습니다. 서비스 간 통신은 클라이언트 측 및 서버 측 Envoy 프록시를 통해 터널링됩니다. Envoy는 SPIFFE ID를 사용하여 서비스 간에 mTLS 연결을 설정합니다. Istio on GKE를 배포하는 방법에 대한 자세한 내용은 GKE 문서를 참조하세요. 지원되는 TLS 버전에 대한 자세한 내용은 Istio 트래픽 관리 참조를 확인하세요. TLS 버전 1.2 이상을 사용합니다.
애플리케이션이 인터넷에 노출된 경우에는 HTTP(S)를 사용하도록 설정된 인그레스 라우팅을 통해 GKE HTTP(S) 부하 분산을 사용하세요. 인그레스 객체로 구성된 HTTP(S) 부하 분산에는 다음과 같은 기능이 포함됩니다.
- 서비스의 유연한 구성. 인그레스 객체는 트래픽이 서비스에 도달하는 방법과 트래픽이 애플리케이션으로 라우팅되는 방법을 정의합니다. 또한 인그레스는 클러스터의 여러 서비스에 단일 IP 주소를 제공할 수 있습니다.
- Google Cloud 네트워크 서비스와 통합. 인그레스 객체는 Google 관리형 SSL 인증서(베타), Google Cloud Armor, Cloud CDN, Identity-Aware Proxy와 같은 Google Cloud 기능을 구성할 수 있습니다.
- 여러 TLS 인증서에 대한 지원. 인그레스 객체는 요청 종료를 위해 여러 TLS 인증서의 사용을 지정할 수 있습니다.
인그레스 객체를 만들면 GKE 인그레스 컨트롤러가 Cloud HTTP(S) 부하 분산기를 만들고 인그레스 및 관련 서비스의 정보에 따라 구성합니다.
취약점 관리 프로그램 유지관리
취약성 관리 프로그램을 유지관리하려면 PCI DSS의 요구사항 5와 6을 따라야 합니다.
요구사항 5
악의적인 소프트웨어로부터 모든 시스템과 네트워크를 보호합니다.
PCI DSS의 요구사항 5는 시스템을 현재의 그리고 진화하는 악성 소프트웨어 위협으로부터 보호하기 위해 일반적으로 멀웨어의 영향을 받는 모든 시스템에서 바이러스 백신 소프트웨어를 사용해야 한다고 규정하며 컨테이너도 예외가 아닙니다.
요구사항 5.2
악성 소프트웨어(멀웨어)를 방지하거나 감지하고 처리해야 합니다.
컨테이너 이미지의 취약점 관리 프로그램을 구현해야 합니다.
다음과 같은 조치를 취하는 것이 좋습니다.
- 정기적으로 최신 보안 패치를 확인하여 컨테이너에 적용합니다.
- 컨테이너화된 애플리케이션과 바이너리/라이브러리에 정기적으로 취약점 스캔을 수행합니다.
- 빌드 파이프라인의 일부로 이미지를 검사합니다.
- 취약점 인텔리전스 서비스를 구독하여 컨테이너에 사용되는 환경 및 라이브러리와 관련된 최신 취약점 정보를 받아봅니다.
Google Cloud는 고객의 Google Cloud 배포 내에서 보안 상태를 개선하기 위해 여러 컨테이너 보안 솔루션 제공업체와 협력합니다. 검증된 보안 솔루션과 기술을 활용하여 GKE 환경에서 방어 수준을 강화하는 것이 좋습니다. Google Cloud에서 검증된 최신 보안 파트너 목록은 보안 파트너를 참조하세요.
요구사항 5.2.2
배포된 멀웨어 방지 솔루션이 다음을 충족해야 합니다.
- 알려진 모든 멀웨어 유형을 감지합니다.
- 알려진 모든 유형의 멀웨어를 삭제, 차단, 제한합니다.
요구사항 5.2.3
멀웨어 위험이 없는 모든 시스템 구성요소에 대해 다음 항목이 포함되는지 주기적으로 검사를 수행해야 합니다.
- 멀웨어 위험이 없는 모든 시스템 구성요소에 대한 설명 목록
- 그러한 시스템 구성요소에 대해 변화하는 멀웨어 위협에 대한 인식 및 평가
- 이러한 시스템 구성요소에 멀웨어 방지 보호가 필요한지 여부에 대한 확인
멀웨어 검사를 수행하는 데 사용할 수 있는 솔루션은 많지만, PCI DSS는 모든 시스템이 동일한 수준으로 취약하지는 않다는 사실을 인식하고 있습니다. 판매자가 Linux 서버, 메인프레임, 이와 유사한 시스템을 '일반적으로 악성 소프트웨어의 영향을 받는 대상'이 아니고 따라서 5.2.2에서 면제된다고 선언하는 경우가 많습니다. 이러한 경우 5.2.3이 적용되며 정기적인 위협 평가를 위한 시스템을 구현해야 합니다.
이 규칙은 GKE 클러스터 내의 노드와 pod에 모두 적용됩니다.
요구사항 5.3
멀웨어 방지 메커니즘과 프로세스가 활성화되어 있고, 유지보수되고, 모니터링되어야 합니다.
요구사항 5.2, 5.3, 11.5는 범위 내 호스트에서 바이러스 백신 검사와 파일 무결성 모니터링(FIM)을 요구합니다. 클러스터 내의 신뢰할 수 있는 에이전트가 모든 노드를 스캔하거나, 노드마다 단일 관리 엔드포인트까지 보고하는 스캐너가 있는 솔루션을 구현하는 것이 좋습니다.
자세한 내용은 GKE 보안 개요 및 Container-Optimized OS 보안 개요를 참조하세요.
바이러스 백신과 FIM 요구사항 둘 다를 위한 일반적인 해결책은 허용된 특정 폴더만 쓰기 액세스 권한을 갖도록 컨테이너를 잠그는 것입니다. 이렇게 하려면 루트가 아닌 사용자로 컨테이너를 실행하고 파일 시스템 권한을 사용하여 컨테이너 파일 시스템 내에서 작업 중인 디렉터리를 제외한 모든 디렉터리에 대한 쓰기 액세스를 차단합니다. 파일 시스템 규칙의 우회를 방지하려면 권한 에스컬레이션을 불허합니다.
요구사항 6
보안 시스템 및 소프트웨어를 개발하고 유지보수해야 합니다.
PCI DSS의 요구사항 6은 소프트웨어 개발의 모든 단계에서 보안이 구축되는 강력한 소프트웨어 개발 수명주기를 수립하도록 규정합니다.
요구사항 6.2
맞춤형 및 커스텀 소프트웨어가 안전하게 개발되었습니다.
요구사항 6.2.1
맞춤형 및 커스텀 소프트웨어를 다음과 같이 안전하게 개발해야 합니다.
- 보안 개발을 위한 업계 표준 또는 권장사항을 따라야 합니다.
- PCI DSS(예: 보안 인증 및 로깅)를 준수해야 합니다.
- 소프트웨어 개발 수명 주기의 각 단계에서 정보 보안 문제를 고려해야 합니다.
Binary Authorization을 사용하면 신뢰할 수 있는 컨테이너만 GKE에 배포할 수 있습니다. 하나 이상의 특정 증명자가 승인한 이미지를 사용 설정하려면 취약점 스캔 결과에 따라 증명이 필요한 규칙이 포함된 정책을 시행하도록 Binary Authorization을 구성할 수 있습니다. 이미지를 배포하려면 먼저 하나 이상의 신뢰할 수 있는 당사자('증명자')가 이미지를 승인해야 한다는 정책을 작성할 수도 있습니다. 이미지가 개발에서 시작하여 테스팅, 프로덕션 클러스터를 거치는 다단계 배포 파이프라인의 경우, 증명자를 사용하여 소프트웨어가 다음 단계로 이동하기 전에 모든 필수 프로세스가 완료되었는지 확인할 수 있습니다.
배포 시 Binary Authorization은 컨테이너 이미지가 모든 필수 제약조건(예를 들면 이미지를 배포할 준비가 완료되었음을 모든 필수 증명자가 확인했음)을 통과했는지 검사하여 정책을 적용합니다. 이미지가 통과했으면 서비스에서 이미지 배포를 허용합니다. 그렇지 않으면 배포가 차단되며, 규정을 준수해야만 이미지를 배포할 수 있습니다.
Binary Authorization에 대한 자세한 내용은 GKE 설정을 참조하세요.
응급 상황에서는 Break Glass 워크플로를 사용하여 Binary Authorization 정책을 우회할 수 있습니다. 모든 Break Glass 이슈는 Cloud 감사 로그에 기록됩니다.
GKE Sandbox는 컨테이너가 호스트와 직접 상호작용할 필요성을 줄여서 호스트를 손상시킬 수 있는 공격 노출 영역을 줄이고 악의적인 행위자의 움직임을 제한합니다.
요구사항 6.3
보안 취약점을 식별하고 해결해야 합니다.
요구사항 6.3.1
보안 취약점을 다음과 같이 식별하고 관리해야 합니다.
- 해외 및 국내 컴퓨터 긴급 응답팀(CERT)의 알림을 포함하여 보안 취약성 정보에 대해 업계에서 알려진 소스를 사용하여 새로운 보안 취약점을 식별해야 합니다.
- 업계 권장사항과 잠재적 영향을 고려하여 취약점에 대해 위험 등급을 할당해야 합니다.
- 최소한 해당 환경에 대해 고위험 또는 치명적으로 고려되는 모든 취약점을 위험 등급별로 식별할 수 있어야 합니다.
- 맞춤형 및 커스텀, 서드 파티 소프트웨어(예: 운영체제 및 데이터베이스)의 취약점이 포함되어야 합니다.
클라우드의 보안은 클라우드 제공업체와 고객이 공유하는 책임입니다.
GKE에서 Google은 마스터 VM, API 서버, 해당 VM에서 실행되는 기타 구성요소를 포함하는 제어 영역과 etcd 데이터베이스를 관리합니다. 여기에는 서비스 수준 목표(SLO)로 지원되는 업그레이드와 패치, 확장, 복구가 포함됩니다. Container-Optimized OS 또는 Ubuntu와 같은 노드 운영체제의 경우 GKE가 이러한 이미지에 대한 패치를 즉시 제공합니다. 자동 업그레이드를 사용 설정하면 이러한 패치가 자동으로 배포됩니다. 이는 컨테이너의 기본 레이어이며, 컨테이너에서 실행되는 운영체제와는 다릅니다.
GKE 공유 책임 모델에 대한 자세한 내용은 컨테이너 보안 탐색: GKE의 공유 책임 모델을 참조하세요.
Google은 CI/CD 파이프라인에 보안을 구축할 수 있도록 여러 보안 서비스를 제공합니다. 컨테이너 이미지의 취약점을 식별하려면 Google Artifact Analysis 취약점 스캔을 사용합니다. 컨테이너 이미지를 Google Container Registry(GCR)로 푸시하면 취약점 스캔에서 자동으로 이미지를 스캔하여 공개된 CVE 소스에서 알려진 취약점과 노출을 찾습니다. CVSS 점수를 기준으로 취약점에 심각도 수준(심각, 높음, 보통, 낮음, 최소)이 지정됩니다.
요구사항 6.4
공개용 웹 애플리케이션을 공격으로부터 보호해야 합니다.
Web Security Scanner를 사용하면 공개 App Engine, Compute Engine, GKE 웹 애플리케이션을 교차 사이트 스크립팅과 잘못된 구성에서 취약한 리소스에 이르기까지 일반적인 취약점에 대해 검사할 수 있습니다. 검사는 필요 시 수행 할 수 있으며 Google Cloud 콘솔에서 예약할 수 있습니다. Security Scanner API를 사용하면 검사를 애플리케이션 빌드 파이프라인의 보안 테스트 제품군의 일부로 자동화할 수 있습니다.
강력한 액세스 제어 수단 구현
강력한 액세스 제어 수단을 구현하려면 PCI DSS의 요구사항 7, 8, 9를 따라야 합니다.
요구사항 7
특정 직무 역할 및 요구사항에 따라 시스템 구성요소 및 카드 소지자 데이터에 대해 접근을 제한해야 합니다.
요구사항 7은 최소 권한 또는 알 필요에 초점을 맞춥니다. PCI DSS는 이를 최소 데이터 양에 대한 액세스 권한을 부여하고 작업 수행을 위해 필요한 최소 권한을 제공하도록 정의합니다.
요구사항 7.2
시스템 구성요소 및 데이터에 대한 액세스가 적절하게 정의되고 할당되어야 합니다.
IAM과 Kubernetes 역할 기반 액세스 제어(RBAC)가 함께 작동하여 GKE 환경에 대한 세분화된 액세스 제어를 제공합니다. IAM은 CDE 프로젝트에서 Google Cloud 리소스에 대한 사용자 액세스 및 권한을 관리하는 데 사용됩니다. GKE에서 IAM을 사용하여 클러스터 생성이나 삭제와 같이 사용자와 서비스 계정이 클러스터에서 수행할 수 있는 액세스와 작업을 관리할 수도 있습니다.
Kubernetes RBAC를 사용하면 특정한 Google Cloud 사용자, Google Cloud 서비스 계정 또는 사용자 그룹(Google 그룹스)이 클러스터 또는 클러스터의 특정 네임스페이스에 있는 Kubernetes 객체와 상호 작용하는 방법을 정의하는 세분화된 권한 집합을 구성할 수 있습니다. RBAC 권한의 예시로는 배포 또는 configmap의 편집, pod 삭제, pod에서 로그 보기 등이 있습니다. Google Kubernetes Engine 클러스터 뷰어나 커스텀 역할과 같은 사용자 또는 서비스에 제한된 IAM 권한을 부여한 다음 Kubernetes RBAC RoleBinding을 적절하게 적용합니다.
Cloud Identity-Aware Proxy(IAP)는 PCI 애플리케이션에 대한 액세스 권한이 필요한 직원이나 사람들의 애플리케이션 수준 액세스를 제어하기 위해 GKE의 인그레스를 통해 통합될 수 있습니다.
또한 조직 정책을 사용하여 프로젝트 내에서 사용 가능한 API와 서비스를 제한할 수 있습니다.
요구사항 7.2.2
권한 있는 사용자를 포함하여 다음을 기준으로 사용자에게 액세스 권한을 할당해야 합니다.
- 직무 분류 및 기능
- 직무 책임을 수행하는 데 필요한 최소 권한
사용자와 서비스 계정이 최소 권한의 원칙을 준수하도록 하는 동시에 컨테이너도 그렇게 해야 합니다. 컨테이너를 실행할 때 권장사항은 루트가 아닌 사용자로 프로세스를 실행하는 것입니다. 이러한 방침은 PodSecurity 허용 컨트롤러를 사용하여 구현하고 적용할 수 있습니다.
PodSecurity는 GKE 클러스터에서 실행되는 포드에 포드 보안 표준을 적용할 수 있는 Kubernetes 허용 컨트롤러입니다. 포드 보안 표준은 Kubernetes에서 포드 보안의 고급 요구사항을 다루는 사전 정의된 보안 정책입니다. 이러한 정책은 매우 허용적인 정책부터 매우 제한적인 정책까지 다양합니다. PodSecurity는 Kubernetes v1.25에서 삭제된 이전의 PodSecurityPolicy 허용 컨트롤러를 대체합니다. PodSecurityPolicy에서 PodSecurity 허용 컨트롤러로 마이그레이션하는 방법을 확인하세요.
요구사항 8
시스템 구성요소에 대한 액세스 식별 및 인증
요구사항 8은 각 개인이 자신의 행동에 대해 고유하게 책임을 지기 위해 내부 PCI 시스템에 액세스할 수 있는 고유 ID를 할당해야 함을 지정합니다.
요구사항 8.2
사용자 및 관리자에 대한 사용자 식별 및 관련 계정은 계정 수명 주기 전반에 걸쳐서 엄격하게 관리되어야 합니다.
요구사항 8.2.1
시스템 구성요소 또는 카드 소지자 데이터에 대한 액세스가 허용되기 전에 모든 사용자에게 고유한 ID를 할당해야 합니다.
요구사항 8.2.5
사용 중지된 사용자의 액세스 권한은 즉시 취소해야 합니다.
IAM 및 Kubernetes RBAC는 둘 다 GKE 클러스터에 대한 액세스를 제어하는 데 사용할 수 있으며, 두 경우 모두 사용자에게 권한을 부여할 수 있습니다. 사용자 계정과 정책을 한 위치에서 관리할 수 있도록 사용자를 기존 ID 시스템에 다시 연결하는 것이 좋습니다.
요구사항 8.3
사용자 및 관리자에 대해 강력한 인증을 설정하고 관리해야 합니다.
요구사항 8.3.1
- 사용자가 알고 있는 대상(예: 비밀번호나 암호)
- 사용자가 소유한 대상(예: 토큰 기기나 스마트 카드)
- 사용자 고유의 특성(예: 생체 요소)
인증서는 kubectl에 따라 인증할 때 사용자의 ID에 결합됩니다.
모든 GKE 클러스터는 사용자 인증 정보의 유효성을 검사하고 사용자 또는 서비스 계정 ID에 연결된 이메일 주소를 검색하여 Google Cloud 사용자 및 서비스 계정 ID를 수락하도록 구성됩니다. 따라서 이러한 계정의 사용자 인증 정보에 userinfo.email OAuth 범위가 포함되어야 인증이 성공합니다.
요구사항 9
카드 소지자 데이터에 대한 물리적 액세스를 제한합니다.
Google은 Google Cloud를 기반으로 하는 모든 Google 데이터 센터의 물리적 보안 제어를 책임집니다.
네트워크를 정기적으로 모니터링 및 테스트
네트워크를 정기적으로 모니터링하고 테스트하려면 PCI DSS의 요구사항 10과 11을 따라야 합니다.
요구사항 10
시스템 구성요소 및 카드 소지자 데이터에 대한 모든 액세스 로깅 및 모니터링
요구사항 10.2
이상치 및 의심스러운 활동의 감지 및 이벤트에 대한 포렌식 분석을 지원하도록 감사 로그를 구현해야 합니다.
Kubernetes 클러스터에는 Kubernetes API 서버로 전송된 호출을 시간순으로 기록하는 Kubernetes 감사 로깅이 기본적으로 사용 설정되어 있습니다. Kubernetes 감사 로그 항목은 의심스러운 API 요청을 조사하거나, 통계를 수집하거나, 원치 않는 API 호출에 대한 모니터링 알림을 생성하는 데 유용합니다.
GKE 클러스터는 GKE 감사 로깅을 위한 기본 구성을 Cloud 감사 로그 및 Logging과 통합합니다. Google Cloud 프로젝트에서 Kubernetes 감사 로그 항목을 볼 수 있습니다.
프로젝트의 감사 로그에는 Kubernetes가 작성한 항목 외에도 GKE가 작성한 항목이 있습니다.
CDE 워크로드와 CDE가 아닌 워크로드를 구별하려면 GKE pod에 이러한 워크로드에서 생성되는 측정항목과 로그로 전달되는 라벨을 추가하는 것이 좋습니다.
요구사항 10.2.2
- 사용자 식별
- 이벤트 유형
- 날짜 및 시간
- 성공 또는 실패의 표시
- 이벤트의 발생
- 영향을 받는 데이터, 시스템 구성요소, 리소스, 서비스의 ID 또는 이름(예: 이름과 프로토콜)
Logging의 모든 감사 로그 항목은 다음 필드를 포함하는 LogEntry 유형의 객체입니다.
protoPayload유형의 페이로드. 각 감사 로그 항목의 페이로드는AuditLog유형의 객체입니다.AuditLog객체의AuthenticationInfo필드에서 사용자 ID를 확인할 수 있습니다.AuditLog의methodName필드에서 찾을 수 있는 특정 이벤트- 타임스탬프
AuditLog객체의response객체에서 찾을 수 있는 이벤트 상태AuditLog객체의request및requestMetadata객체에서 찾을 수 있는 작업 요청serviceData의AuditData객체에서 찾을 수 있는 수행 예정인 서비스
요구사항 11
시스템 및 네트워크 보안 정기 테스트
요구사항 11.3
외부 및 내부 취약점을 정기적으로 식별하고, 우선순위를 나누고, 해결해야 합니다.
요구사항 11.3.1
- 최소 3개월에 한 번 이상
- 요구사항 6.3.1에 정의된 항목의 취약점 위험 등급에 따라 고위험 및 치명적 취약점을 확인해야 합니다.
- 모든 고위험 및 치명적 취약점(위 설명 참조)이 해결되었는지 확인하는 재스캔을 수행해야 합니다.
- 스캔 툴은 최신 취약점 정보로 최신 상태로 유지해야 합니다.
- 테스터 독립성과 자격이 있는 사람이 스캔을 수행해야 합니다.
Artifact Analysis 취약점 스캔은 Container Registry의 이미지에 대해 다음과 같은 유형의 취약점 스캔을 수행합니다.
초기 스캔. Artifact Analysis API를 처음 활성화하면 Container Registry의 이미지를 스캔하고 이미지의 패키지 관리자, 이미지 기반, 취약점 어커런스를 추출합니다.
증분 스캔. Artifact Analysis는 새로운 이미지가 Container Registry에 업로드될 때 이를 스캔합니다.
지속적 분석: Artifact Analysis는 취약점 소스에서 새로운 업데이트된 취약점 정보를 수신하면 컨테이너의 분석을 다시 실행하여 이미 스캔한 이미지의 취약점 어커런스 목록을 최신 상태로 유지합니다.
요구사항 11.5
네트워크 침입 및 예기치 않은 파일 변경사항을 감지하고 대응할 수 있어야 합니다.
요구사항 11.5.1
- CDE 경계에서 모든 트래픽을 모니터링해야 합니다.
- CDE의 중요 지점에서 모든 트래픽을 모니터링해야 합니다.
- 의심스러운 손상이 있으면 이를 직원에게 알려야 합니다.
- 모든 침입 감지 및 방지 엔진, 기준, 서명을 최신 상태로 유지해야 합니다.
Google Cloud 패킷 미러링을 Cloud IDS와 함께 사용하여 네트워크 침입을 감지할 수 있습니다. Google Cloud 패킷 미러링은 Compute Engine VM 또는 Google Cloud 클러스터의 모든 네트워크 트래픽을 지정된 주소로 전달합니다. Cloud IDS는 이 미러링된 트래픽을 사용하여 악용 시도, 포트 스캔, 버퍼 오버플로우, 프로토콜 조각화, 명령어 및 제어(C2) 트래픽, 멀웨어를 비롯한 다양한 위협을 감지할 수 있습니다.
Security Command Center는 조직 전체에서 Google Cloud 서비스(GKE 포함)와 자산의 보안 상태를 파악하는 중앙화된 기능을 제공하여 보다 쉽게 위협을 예방, 감지하고 위협에 대응할 수 있게 합니다. Security Command Center를 사용하면 멀웨어, 암호화폐 채굴, Google Cloud 리소스에 대한 무단 액세스, 발신 DDoS 공격, 포트 검사, SSH 무작위 공격 등 위험도가 높은 위협이 감지되었을 때 Cloud Logging 로그를 통해 이를 확인할 수 있습니다.
정보 보안 정책 유지보수
강력한 보안 정책은 보안 수준을 설정하고 사람들에게 기대되는 사항을 알려줍니다. 여기에서 '사람'은 CDE에 액세스할 수 있는 전일제 및 시간제 직원, 임시 직원, 계약업체, 컨설턴트를 의미합니다.
요구사항 12
조직 정책 및 프로그램으로 정보 보안 지원
요구사항 12에 대한 자세한 내용은 Google Cloud PCI 공유 책임 규정을 참조하세요.
삭제
이 자료를 따르는 과정에서 리소스를 사용한 경우(예를 들어 새 VM을 시작하거나 Terraform 스크립트를 사용한 경우) 해당 리소스를 사용한 프로젝트를 삭제하면 Google Cloud 계정에 요금이 청구되지 않습니다.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
다음 단계
- PCI 데이터 보안 표준 준수에 대해 자세히 알아보기
- Terraform 스타터 키트 사용하기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기. Cloud 아키텍처 센터 살펴보기