이 문서에서는 PCI(결제 카드 산업) 보안 표준 위원회 규정 준수를 위한 클라우드 환경 설계 권장사항에 대해 설명합니다. 이 권장사항은 PCI 규정 준수 요구사항이 적용되는 시스템을 클라우드에서 마이그레이션하거나 설계하는 조직에 유용합니다. 이 문서는 해당하는 경우 PCI DSS 4.0 요구사항을 다룹니다.
PCI DSS 평가 범위 이해
인터넷을 통해 상거래에 종사하는 조직은 PCI 규정 준수를 지원하고 유지해야 합니다. 클라우드 환경을 설계하고 관리하는 방식에 따라 PCI 데이터 보안 표준(DSS) 평가에서 내 시스템의 범위가 지정됩니다. 범위 지정은 IT 애셋의 보안과 PCI 규정 준수 지원 및 유지보수 역량에 중요한 영향을 미칩니다. PCI 환경의 범위를 올바르게 지정하려면 비즈니스 프로세스와 설계 결정이 범위에 미치는 영향을 이해해야 합니다.
범위란 무엇인가요?
카드 소지자 데이터(CHD)를 저장, 처리, 전송하는 모든 시스템은 PCI DSS 평가 범위에 들어갑니다. 보안은 전체 클라우드 환경에 중요합니다. 범위 내 시스템의 보안이 침해되면 정보 유출 및 CHD의 노출로 이어질 수 있습니다.
그림 1에서 카드 소지자 데이터 환경(CDE), 연결된(connected-to) 시스템, 보안에 영향을 미치는(security-impacting) 시스템은 평가 범위 경계 내에 있으며 경계 밖 신뢰할 수 없는 시스템은 평가 범위 외부에 위치합니다.
PCI DSS에 따르면 범위 내의 시스템은 신뢰할 수 있는 시스템입니다. 범위 내의 시스템에는 CDE와 CDE 보안과 관련되거나 CDE 보안에 영향을 미칠 수 있는 모든 시스템이 포함됩니다.
시스템이 동일한 네트워크에 있거나 데이터베이스 또는 파일 저장소를 공유하거나, 그렇지 않으면 CDE 내부에 위치한 시스템이나 프로세스에 액세스하거나 연결할 수는 있지만 CHD에 직접 액세스할 수 없는 경우 연결된(connected-to) 시스템이라고 합니다.
보안이 침해되면 공격자가 CDE에 액세스할 수 있는 시스템은 보안에 영향을 미치는(security-impacting) 시스템입니다. 연결된 시스템과 보안에 영향을 미치는 시스템은 둘 다 항상 범위 안에 존재합니다.
범위 밖에 있는 시스템은 PCI DSS의 정의 상 신뢰할 수 없는 시스템으로, CHD 또는 민감한 인증 데이터(SAD)에 액세스하려는 공격자에게는 아무런 가치가 없습니다. 시스템이 손상되어도 범위 내 시스템의 보안에 영향을 미칠 수 없는 경우 해당 시스템은 범위 밖 시스템입니다. 범위 밖 시스템은 직접 평가되지는 않지만 PCI Qualified Security Assessor(QSA)는 범위 지정이 정확한지 검증하여 PCI DSS에 따라 CHD를 보호합니다. 따라서 범위 경계를 강력하게 보호하고, 지속적으로 엄격하게 모니터링하며, 명료하게 문서화하는 것은 매우 중요한 일입니다.
PCI 컨텍스트에서의 연결
일부 PCI DSS 요구사항은 연결을 다루지만 PCI DSS는 연결을 명시적으로 연결을 정의하지 않습니다. PCI DSS 범위 지정 및 네트워크 세분화에 대한 PCI SSC 지침(PDF)의 범위 지정 결정 트리를 이해하면 이 맥락에서 연결의 의미를 해석할 수 있습니다.
PCI 범위를 평가하는 차원에서의 연결은 다음과 같이 정의됩니다.
- 두 컴퓨터 또는 시스템을 연결하는 활성 정보 전송
- 호출을 개시한 두 당사자
환경을 문서화할 때 연결을 시작할 수 있는 권한이 있는 당사자를 명확하게 명시하는 것이 가장 좋습니다. 트래픽을 한 방향으로만 보내도록 구성된 방화벽은 단방향 연결을 적용할 수 있습니다. 예를 들어 범위 내 결제 대행 애플리케이션은 다음 조건이 모두 충족되면 범위 밖 서버가 범위 내에 있지 않아도 범위 밖 데이터베이스 서버에 쿼리할 수 있습니다.
- 연결된 범위 밖 데이터베이스가 CHD 또는 SAD를 저장, 처리 또는 전송하지 않습니다.
- 데이터베이스가 별도의 네트워크에 위치하거나 그렇지 않으면 CDE에서 분할되어 있습니다.
- 데이터베이스가 CDE를 직접 또는 간접적으로 호출할 수 없습니다.
- 데이터베이스가 CDE에 보안 서비스를 제공하지 않습니다.
- 데이터베이스가 CDE의 구성이나 보안에 영향을 미치지 않습니다.
- 데이터베이스에서 PCI DSS 요구사항을 지원합니다.
다음 다이어그램은 시스템 범위를 결정하는 요소들을 보여줍니다.
그림 2에서 시스템 범위는 다음과 같이 결정됩니다.
PCI DSS의 범위 안의 시스템 구성요소:
- 다음 중 하나가 참인 CDE 안의 시스템:
- 시스템 구성요소가 CHD 또는 SAD를 저장, 처리 또는 전송합니다.
- 시스템 구성요소가 CHD를 저장, 처리 또는 전송하는 시스템과 동일한 네트워크 세그먼트, 예를 들어 동일한 서브넷이나 VLAN에 위치합니다.
- 다음 중 하나가 참인 연결된 시스템 또는 보안에 영향을 미치는 시스템:
- 시스템 구성요소가 CDE에 직접 연결됩니다.
- 시스템 구성요소가 CDE의 구성 또는 보안에 영향을 미칩니다.
- 시스템 구성요소가 범위 밖 시스템 및 네트워크의 CDE 시스템을 분할합니다.
- 시스템 구성요소가 CDE에 간접적으로 연결됩니다.
- 시스템 구성요소가 CDE에 보안 서비스를 제공합니다.
- 시스템 구성요소가 PCI DSS 요구사항을 지원합니다.
- 다음 중 하나가 참인 CDE 안의 시스템:
다음 사항이 모두 참일 때 시스템 구성요소를 PCI DSS의 신뢰할 수 없는, 범위 밖 시스템으로 간주할 수 있습니다.
- 시스템 구성요소가 CHD 또는 SAD를 저장, 처리 또는 전송하지 않습니다.
- 시스템 구성요소가 CHD 또는 SAD를 저장, 처리, 또는 전송하는 시스템과 동일한 네트워트 세그먼트, 예를 들어 동일한 서브넷이나 VLAN에 위치하지 않습니다.
- 시스템 구성요소가 CDE의 어떠한 시스템에도 연결할 수 없습니다.
- 시스템 구성요소가 연결된 시스템이나 보안에 영향을 미치는 시스템에 필요한 기준을 충족하지 않습니다.
범위 밖 시스템에는 연결된 시스템 또는 보안에 영향을 미치는 시스템 구성요소에 연결된 시스템이 포함될 수 있으며, 이 경우 범위 밖 시스템이 CDE에 액세스하지 못하도록 방지하는 제어 시스템이 존재합니다.
실질적으로, 시스템 범위의 PCI DSS 정의는 만일 세분화가 제대로 구현되고 문서화된다면 웹 애플리케이션의 세션 저장소 및 전자상거래 데이터베이스는 범위 밖에 해당할 수도 있음을 의미합니다. 다음 다이어그램은 범위 내 시스템과 범위 밖 시스템 간의 읽기 및 쓰기 연결이 작동하는 방식을 보여줍니다.
그림 3에서는 다음 연결을 보여줍니다.
- 읽기 전용:
- 범위 내 결제 처리 애플리케이션은 범위 밖 장바구니 데이터베이스에서 장바구니 ID를 읽고 DNS와 NTP에서 데이터를 읽습니다.
- 쓰기 전용:
- 범위 내 결제 처리 애플리케이션은 범위 밖 애플리케이션 기본 데이터베이스와 Cloud Logging에 기록합니다.
- 범위 밖 기본 웹 애플리케이션은 데이터를 로깅 서비스에 작성합니다. 이 데이터에는 CHD나 SAD가 포함되지 않습니다.
- 읽기 및 쓰기:
- 공개 웹 사용자는 다음과 같이 요청 메타데이터를 읽고 씁니다:
- 사용자가 범위 내 결제 대행 애플리케이션을 읽고 씁니다. 이 요청 메타데이터는 CHD 및 SAD가 포함된 장바구니 ID이자 장바구니 인증 키입니다.
- 사용자가 범위 밖 기본 웹 애플리케이션을 읽고 씁니다. 이 요청 메타데이터는 CHD 또는 SAD가 포함되지 않은 세션 ID입니다.
- 범위 밖 기본 웹 애플리케이션은 범위 밖 장바구니 데이터베이스, 세션 저장소, 애플리케이션 기본 데이터베이스에서 데이터를 읽고 씁니다. 이 데이터에는 CHD나 SAD가 포함되지 않습니다.
- 범위 내 결제 대행 애플리케이션은 데이터를 읽고 범위 내 카드 토큰화 서비스와 공개 웹의 신용카드 프로세서에 씁니다. 이 데이터에는 CHD 및 SAD가 포함됩니다.
- 공개 웹 사용자는 다음과 같이 요청 메타데이터를 읽고 씁니다:
그림 3의 아키텍처는 PCI의 범위 밖 기본 웹 애플리케이션(기본 애플리케이션)과 범위 내 결제 처리 애플리케이션(결제 애플리케이션)이라는 두 가지 개별 웹 애플리케이션에 대해 설명합니다. 이 아키텍처에서는 앞의 목록에 설명된 방향으로만 두 항목 간의 연결을 개시할 수 있습니다. 항목 간의 연결은 호출자 관점에서 읽기 전용, 읽기 및 쓰기 또는 쓰기 전용이 될 수 있습니다. 명시적으로 설명되지 않은 경로 또는 요청 방향은 세분화로 차단합니다. 예를 들어 결제 처리 애플리케이션은 장바구니 데이터베이스에서 읽을 수 있고, 해당 항목에 대한 연결을 시작하는 로깅 서비스에 쓸 수 있습니다.
범위 내 시스템은 일반적으로 범위 밖 시스템 및 서비스를 호출합니다. 세분화로 인해 원격 호출자(카드 소지자 제외)가 CDE에 대한 연결을 직접 또는 간접적으로 시작할 수 없기 때문에 연결이 안전하게 유지됩니다. 그림 3은 결제 애플리케이션의 유일한 인그레스 경로가 사용자로부터 시작됨을 보여줍니다.
그림 3에서는 범위 밖 서비스 또는 애플리케이션이 결제 대행 애플리케이션에 구성이나 보안 데이터를 제공하지 않습니다. 데이터는 다음과 같이 아키텍처를 통해 이동합니다.
- 기본 애플리케이션은 사용자를 결제 애플리케이션으로 전달하고 HTTP
POST를 사용하여CartID및CartAuthKey라는 이름의 검사기를 전송합니다.CartAuthKey는CartID의 해시이자 기본 및 결제 애플리케이션에만 알려진 사전 공유 보안 비밀입니다. - 결제 애플리케이션에서는
CartID를 이 보안 비밀과 함께 해싱하고 이 값을CartAuthKey와 비교하여 사용자를 검증합니다. - 사용자 데이터가 인증되면
CartID는 장바구니 데이터베이스에서 장바구니 콘텐츠를 읽는 데 사용됩니다. 모든 카드 소지자 데이터는 직접 사용자로부터 체크아웃 애플리케이션으로 전송됩니다. - 결제 프로필을 사용하는 경우 카드 소지자 데이터는 토큰화 서비스에 저장됩니다.
- 결제가 처리되면 결과는 읽기 전용 데이터베이스 서비스 계정으로 기본 애플리케이션의 데이터베이스에 삽입됩니다.
범위 지정 관련 고려사항
PCI DSS 범위 지정 및 네트워크 세분화 지침에서 PCI 보안 표준 위원회(SSC)는 달리 검증되기 전까지는 모든 항목이 범위 내에 있다고 가정할 것을 권장합니다. 이 SSC 권장사항은 범위를 최대한 넓히라는 의미가 아닙니다. 시스템이 CDE에 연결되어 있지 않거나 CDE에 보안 영향을 미친다고 입증할 수 없는 한, QSA는 모든 시스템을 신뢰할 수 있는 것으로 평가한다는 뜻입니다. 규정 준수 요구사항을 충족하고 IT 애셋을 안전하게 유지하려면 최대한 적은 시스템을 신뢰하여 최소 권한의 원칙에 따라 환경의 범위를 조정해야 합니다.
평가 전에 환경을 평가하여 범위 내 시스템과 범위 밖 시스템 간의 경계를 이해하고 문서화하세요. QSA의 첫 번째 작업은 문서화된 범위가 CDE 및 연결된 시스템을 합리적으로 요약하고 있는지 확인하는 것입니다. 그런 다음 QSA는 전체적인 평가의 일환으로 범위 밖 시스템이 범위 내 시스템에 부정적인 영향을 미칠 수 없는지 확인합니다.
다음과 같이 내 환경에 해당하는 특별 상황들을 이해해야 합니다.
- 전화나 VOIP 시스템을 통해 카드 소지자 데이터를 수집하는 경우 전화 기반 결제 카드 데이터 보호(PDF)에 설명된 추가 범위 지정 문제를 고려합니다.
- 서비스 제공업체에서 POS 시스템을 운영하기 위해 CDE(PDF)에 액세스해야 하는 경우 서비스 제공업체에서 사용하는 시스템을 연결된 시스템이라고 간주할 수 있습니다. 여기에는 추가적인 범위 및 실사 고려사항이 필요할 수 있습니다.
Google의 보안 권장사항을 사용하면 범위 내 시스템과 신뢰할 수 없는 시스템 간의 명확하고 방어 가능한 경계 설정을 수립하고 실증할 수 있습니다. 최소 권한 원칙을 준수하여 액세스 및 보안을 관리하는 경우에는 카드 소지자 데이터의 노출 지점 수를 최소화하여 CDE의 공격 표면을 최소화하므로 결과적으로 범위가 줄어듭니다. 범위 내 시스템의 부담을 줄이면 시스템의 복잡성이 줄어들고 PCI DSS 평가를 간소화할 수 있습니다.
잘못된 범위 지정의 위험
범위가 너무 넓으면 평가 비용이 증가하고 규정 준수 위험이 커질 수 있습니다. 범위를 좁힐 수 있도록 가급적 적은 시스템을 신뢰하고 지정된 일부 사용자에게만 액세스 권한을 부여하세요. 정밀 평가와 자가 진단을 통해 PCI DSS의 범위에 속하지 않는 시스템을 식별하고 이들이 범위 밖 시스템의 가이드라인을 충족하는지 확인하고 이에 따라 범위를 줄일 수 있습니다. 이러한 제거 절차는 신뢰할 수 없는 시스템을 발견하여 현재 범위 내 시스템에 영향을 주지 않게 하는 가장 안전한 방법입니다.
PCI DSS 요구사항을 충족하기 위해 대규모 인프라 공간이 필요한 경우 평가 범위에 관련 없는 시스템이 포함될 수 있습니다. 범위에 관련 없는 시스템을 포함하면 규정 준수를 달성하는 능력이 위태로워집니다. 또한 신뢰할 수 있는 범위 내 환경의 공격 표면이 확대되어 전체적인 보안 상태가 저하될 수 있습니다.
네트워크 보안 및 PCI DSS의 핵심 원칙은 네트워크의 일부 또는 전부가 이미 손상되었다고 가정하는 것입니다. 이 원칙은 Google의 제로 트러스트 보안 모델에 명시되어 있는데, 이 모델은 각 시스템이 자체 보안을 담당한 모델을 우선하도록 경계 전용 보안을 거부합니다. Google의 보안 모델은 PCI DSS와 연동되므로, CDE 및 연결된 시스템들이 광범위한 IT 환경으로부터 세분화된 작고 신뢰할 수 있는 공간에 배포되어 서로 섞이지 않는 것을 권장하고 있습니다.
범위 내 PCI 환경 내에서, CDE를 넓은 경계를 가진 크고 신뢰할 수 있는 공간에 배치하지 마세요. 이렇게 하면 거짓된 보안 인식이 생겨서 전체적이고 심층적인 방어 전략을 약화시킬 수 있습니다. 그러면 경계 보안을 뚫은 공격자는 신뢰할 수 있는 비공개 인트라넷 내에서 쉽게 작업할 수 있습니다. 신뢰할 수 있는 공간 확보를 위해 실행 및 보안 필요한 작업만 포함하도록 제한하며 경계 보안에만 의존하지 않도록 하세요. 이러한 원칙을 이해하고 준수하면 클라우드 환경을 설계하여 중요 시스템을 보호하고 보안 침해 위험을 줄일 수 있습니다.
신뢰할 수 있는 시스템의 대규모 범위 내 환경에는 이러한 시스템의 지속적인 모니터링, 유지보수, 감사, 인벤토리를 유지하기 위해 유사한 대규모 관리 장치가 필요합니다. 시스템 아키텍처, 변경 관리 프로세스, 액세스 제어 정책의 복잡성으로 인해 보안 및 규정 준수 위험이 발생할 수 있습니다. 이러한 모니터링 프로세스를 유지 관리하는 데 어려움이 있을 경우 PCI DSS 요구사항 10 및 11을 충족하는 데 어려움을 겪을 수 있습니다. 이러한 리스크를 이해하고 평가된 환경의 범위를 제한하는 전략을 구현하는 것이 중요합니다. 자세한 내용은 이 문서의 뒷부분에 나오는 지속적 규정 준수 지원을 참조하세요.
PCI DSS 범위 내의 Google Cloud 서비스
PCI 환경의 범위를 줄이기 전에 PCI DSS 범위 내의 Google Cloud 서비스를 이해해야 합니다. 이러한 서비스는 카드 소지자 데이터를 저장, 처리, 또는 전송하는 자체 서비스 또는 애플리케이션을 구축할 수 있는 인프라를 제공합니다.
범위 축소 전략
이 섹션에서는 평가 범위를 줄이기 위한 리소스 계층 구조 제어, VPC 서비스 제어 세분화, 토큰화 전략에 대해 설명합니다. 한 가지 접근 방식만 선택하는 대신에 이 모든 전략을 채택하여 가능한 범위를 줄이는 것이 좋습니다.
PCI 범위 지정을 위한 범용 솔루션은 존재하지 않습니다. 사용자의 온프레미스 네트워크에 기존 세분화가 탑재되어 있거나, 여기에 설명된 것과 다소 다르게 보이는 인프라 설계를 유발할 수 있는 카드 처리 솔루션이 있을지도 모릅니다. 이러한 전략을 자신의 환경에 적용할 수 있는 원칙으로 사용하세요.
리소스 계층 구조 제어 설정
Google Cloud 리소스는 다음과 같이 계층적으로 구성됩니다.
- 조직 리소스는 Google Cloud 리소스 계층 구조의 루트 노드입니다. 조직 리소스에는 폴더와 프로젝트 리소스가 포함됩니다. 조직 리소스에 적용된 Identity and Access Management(IAM) 액세스 제어 정책은 조직 내 모든 리소스의 계층 구조 전체에 적용됩니다.
- 폴더는 프로젝트와 기타 폴더를 포함할 수 있으며 폴더 수준 IAM 권한을 사용하여 리소스에 대한 액세스를 제어할 수 있습니다. 폴더는 유사한 프로젝트를 그룹화하는 데 흔히 사용됩니다.
- 프로젝트는 모든 리소스의 트러스트 경계이자 IAM 적용 지점입니다.
평가 범위를 좁히려면 리소스 계층 구조를 정의하는 Google의 Google 권장사항을 따릅니다. 다음 이미지에서는 PCI 규정 준수를 위한 리소스 계층 구조 예시를 보여줍니다.
그림 4에서는 PCI 범위 내의 모든 프로젝트가 한 폴더로 그룹화되어 폴더 수준에서 분리됩니다. PCI 범위의 폴더에는 CDE 및 공유 서비스를 포함한 다른 프로젝트가 포함됩니다. 유사한 리소스 계층 구조를 구현하면 PCI 범위의 폴더가 PCI 규정 준수 범위의 논리적 루트를 형성합니다. 지정된 사용자만 이 폴더와 해당 프로젝트에 액세스할 수 있도록 허용하면 평가 범위에서 계층 구조의 다른 폴더, 프로젝트, 리소스를 제외할 수 있습니다.
필요에 따라 사용자에게 필요한 폴더와 프로젝트에만 액세스 권한을 부여하면 지정된 사용자만 범위 내 구성요소에 액세스할 수 있습니다. 이는 PCI DSS 요구사항 7.2 및 7.3(PDF) 등을 지원합니다. 상위 조직과 폴더에 대한 권한이 적절하게 설정되었는지 확인하려면 정책 상속의 영향을 이해합니다. PCI DSS 요구사항 8.4.1을 지원하려면 지정된 사용자에 다중 인증(MFA)을 적용해야 합니다. 다중 인증 안내 PCI DSS 보충자료(PDF)를 참조하세요. 리소스 계층 구조에서 규정 준수를 시행하려면 조직 정책 제약조건을 설정하는 방법을 이해해야 합니다. 이러한 제약 조건은 지속적인 규정 준수를 지원하며 권한 에스컬레이션으로부터 신뢰할 수 있는 환경을 보호하는 데 도움이 될 수 있습니다.
모든 PCI 규정 준수와 마찬가지로 환경 및 범위가 지정된 구성요소를 적절하게 로깅하고 모니터링하려면 범위 경계를 명확하게 설정해야 합니다. 리소스 계층 구조는 일반적으로 ID 및 액세스 관리를 통해 서로 밀접하게 연결되어 있으며, 이들을 서로 분리하기 위해서는 사용자 작업의 효과적인 로깅, 감사, 모니터링이 필요합니다.
네트워크 세분화 구현
네트워크 세분화는 PCI SSC 네트워크 세분화(PDF) 보충 가이드의 설명대로 CDE 및 연결된 시스템을 보호하는 데 도움이 되는 중요한 아키텍처 패턴입니다. 네트워크 세분화는 제대로만 구현한다면 신뢰할 수 없는 시스템에서 CDE나 연결된 구성요소에 액세스할 때 사용할 수 있는 네트워크 경로를 삭제하여 평가 범위를 좁혀줍니다. 신뢰할 수 있는 구성요소 간의 통신을 허용하는 데 필요한 경로만 정의하세요. 신뢰할 수 없는 시스템에 신뢰할 수 있는 시스템에서 패킷을 주고받을 수 있는 경로가 없으면 신뢰할 수 없는 시스템이 범위에서 벗어나며 범위 내 구성요소의 보안에 영향을 미칠 수 없게 됩니다.
네트워크 세분화를 구현하려면 VPC 서비스 제어가 사용 설정된 전용 Virtual Private Cloud(VPC)에 CDE를 배치합니다. 신뢰할 수 있는 네트워크에 대한 기본 액세스를 사용 설정할 수 있는 불필요한 서브넷 또는 경로가 만들어지지 않도록 커스텀 모드에서 이 VPC를 생성하세요. 조직 정책 제약조건을 구현하여 이 VPC를 다른 프로젝트와 공유할 수 없게 하고 오로지 신뢰할 수 있는 다른 네트워크와만 피어링할 수 있게 하세요.
다음 다이어그램은 네트워크 세분화 전략이 리소스 계층 구조와 어떤 밀접한 관련이 있는지 보여줍니다. 이 다이어그램에서는 범위 내 PCI 환경과 관련된 단일 폴더가 있는 리소스 계층이 하나 있고 CDE 및 공유 서비스에 대한 해당 폴더에 프로젝트가 2개 있다고 가정합니다.
그림 5에서 공유 서비스 프로젝트는 CDE의 일부는 아니지만 연결된 시스템이므로 PCI 범위 내에 있습니다. 이러한 네트워크를 보호하고 PCI DSS 요구사항 1.2 및 1.3을 충족하기 위해 CDE에 대한 액세스는 부하 분산기 및 방화벽 규칙이나 방화벽 정책에 의해 네트워크 수준에서 제한됩니다. 토큰화 시스템과 결제 시스템은 별도의 서브넷에 배치되며, 해당 통신은 필요한 통신만 허용하도록 각 서브넷 사이에 방화벽 규칙이 적용됩니다. PCI DSS 요구사항 10.2, 10.4, 10.5를 충족하는 필수 로깅, 모니터링, 알림 함수는 별도의 프로젝트에 있습니다. 공유 서비스와 CDE는 실수로 인한 잘못된 구성이나 IAM 액세스 제어 보안 침해로부터 보호되도록 VPC 서비스 제어 보안 경계 내에 있습니다.
배포가 Google Kubernetes Engine(GKE)에 있는 경우 CDE를 분할하여 신뢰할 수 없는 시스템으로부터 카드 소지자 데이터를 보호할 수 있는 방법은 다음과 같습니다.
- 네임스페이스는 Kubernetes 클러스터 내의 특정 pod, 서비스, 배포에 대한 액세스 권한만 사용자에게 부여할 수 있는 추가 액세스 제어 격리 레이어를 제공합니다. 지정된 사용자에게 더욱 세분화된 액세스 권한을 제공하는 데 유용합니다.
- 네트워크 정책은 pod와 서비스를 서로 격리하여 데이터 흐름을 제한하고 클러스터 내에서 네트워크 세분화 레이어를 추가로 제공할 수 있습니다.
- PodSecurity는 GKE 클러스터에서 실행되는 포드에 포드 보안 표준을 적용할 수 있는 Kubernetes 허용 컨트롤러입니다.
각 레이어는 심층 방어 보안 상태의 중요한 요소가 되어 주변 환경에서 신뢰할 수 있는 구성요소를 추가로 격리하고 보호하여 범위를 좁히는 데 도움을 줍니다. CDE의 전체 또는 일부를 Kubernetes로 배포하는 경우에는 GKE에서 PCI 규정 준수 환경을 실행하는 방법에 대해 자세히 알아보세요.
토큰화 구현
토큰화는 기본 계정 번호(PAN)를 되돌릴 수 없도록 가리는 프로세스입니다. 토큰화된 PAN 또는 토큰은 수학적 수단으로는 PAN에 사용할 수 없습니다. PCI SSC는 토큰화 가이드라인 보충 자료(PDF) 3장에서 토큰화가 범위 지정에 미치는 영향을 설명하고 있습니다. PCI DSS 범위는 카드 소지자 데이터를 저장하고 전송하는 구성요소 집합의 영향을 많이 받습니다. 토큰화가 올바르게 구현되면 기본 계정 번호의 발생 및 전송을 최소화하여 평가 범위를 줄이는 데 도움이 될 수 있습니다.
또한 토큰화는 카드 소지자 데이터를 저장하고 전송하는 시스템과 오직 토큰만 사용하여 작업을 수행할 수 있는 시스템을 분리하기 때문에 데이터 흐름별로 세분화하는 형태의 하나입니다. 예를 들어 소비자 활동을 분석하여 부정 행위를 찾는 시스템에서는 PAN이 필요하지 않지만 대신 토큰화된 데이터를 사용하여 이러한 분석을 수행할 수 있습니다. 또한 토큰화는 PAN과 전자상거래 웹 애플리케이션을 저장하고 전송하는 시스템 사이에 분리 계층을 추가합니다. 웹 애플리케이션이 토큰을 사용하는 시스템과만 상호작용할 경우 연결된 시스템 집합에서 웹 애플리케이션이 제거될 수 있으므로 범위가 축소됩니다.
다음 다이어그램은 CHD, PAN, 토큰화된 데이터가 일반적인 토큰화 시스템에서 처리되는 방식을 보여줍니다.
그림 6에서 PAN 및 기타 카드 소지자 데이터가 사용자로부터 수신된 후 토큰화 서비스로 즉시 전송됩니다. 토큰화 서비스에서 PAN을 암호화하고 토큰을 생성한 후 이를 보안 토큰 Vault에 저장합니다. 정산 서비스와 같이 지정된 서비스에서만 네트워크의 Vault에 액세스할 수 있으며 생성된 토큰을 사용하여 PAN을 사용하도록 승인됩니다. 정산 서비스는 PAN만 사용하여 이를 결제 대행업체로 보냅니다. 이처럼 엄격하게 제어되는 데이터 흐름 밖에서는 PAN이나 기타 카드 소지자 데이터가 발생하지 않습니다. 심층 방어 전략의 일부로 이 아키텍처에서는 PAN 또는 기타 카드 소지자 데이터가 의도치 않게 유출되지 않도록 막는 또 다른 방어 레이어로 Sensitive Data Protection을 사용합니다.
그림 6에서 토큰화 시스템은 엄격하게 보호되는 보안 비밀 저장소인 Hashicorp Vault를 사용하여 PAN-토큰 매핑을 관리합니다. 승인된 사용자와 서비스만 조회 프로세스를 사용하여 토큰에서 PAN을 사용할 수 있습니다. 토큰 보관함에 액세스할 수 있는 권한이 있는 구성요소에는 구성요소가 기능을 수행하는 데 필요한 특정 기간 동안에만 PAN을 사용할 수 있도록 시간 제한 액세스 권한을 부여할 수 있습니다. 비즈니스 요구사항에 따라 다른 Datastore도 적합할 수 있습니다. 사용자 환경에서 토큰화를 안전하게 구현하는 방법에 대한 자세한 내용은 PCI DSS에 해당하는 민감한 카드 소지자 데이터 토큰화를 참조하세요.
예시 아키텍처
다음 다이어그램은 Pub/Sub 및 Dataflow를 사용하여 토큰화된 트랜잭션을 처리하고 Spanner에 토큰화된 트랜잭션 레코드를 저장하는 예제 아키텍처를 보여줍니다.
그림 7에서 트랜잭션 처리 프로젝트는 연결된 시스템이며 PCI 범위 내에 있습니다. 트랜잭션 처리 프로젝트의 구성요소가 손상되면 공격자가 CHD에 액세스할 수 없으므로 보안이 영향을 받지 않습니다. 웹 앱 프로젝트는 CDE에 연결되지 않고 정화된 데이터와만 상호작용하므로 범위를 벗어납니다.
토큰화된 데이터는 CDE에서 Pub/Sub로 전송됩니다. 토큰화된 데이터가 다른 구독자에게 게시되기 전에 Sensitive Data Protection은 CHD가 포함되어 있지 않은지 확인합니다. 토큰화된 데이터는 Dataflow에서 처리되고 Spanner 트랜잭션 데이터베이스에 저장됩니다. PAN에 액세스하지 않고 토큰을 사용하여 트랜잭션을 특정 사용자와 연결할 수 있습니다. Looker와 같은 비즈니스 인텔리전스(BI) 도구를 사용하여 Spanner 트랜잭션 데이터베이스를 보고와 분석에 사용할 수도 있습니다.
지속적인 규정 준수 지원
보안과 규정 준수는 올바른 아키텍처 및 우수한 엔지니어링 이상의 의미를 가집니다. 올바른 아키텍처로는 환경이 이론적으로 안전하게 설계되었음을 입증할 수 있습니다. 또한 환경이 실제로 안전하게 유지되도록 효과적인 감사, 로깅, 모니터링, 해결 프로세스도 필요합니다.
12가지 PCI DSS 요구사항 카테고리의 규정 준수를 지원하려면 해당 요구사항의 구현을 지속적으로 모니터링해야 합니다. 모든 범위 내 구성요소가 PCI DSS 평가가 완료된 후에도 장기간 안전하게 유지될 것임을 직접 확인하고 평가사에게 증명해야 합니다. 적절한 감독과 즉각적인 해결 조치를 합쳐 지속적인 규정 준수라고 부릅니다. 지속적인 규정 준수는 PCI DSS의 요구사항이며 제대로 구현할 경우 다른 범위 축소 전략의 효과를 극대화하는 데 도움이 될 수 있습니다.
Google Cloud에서는 방화벽 규칙 로깅 ,VPC 흐름 로그 ,VPC 서비스 제어 로그, Cloud Load Balancing 로그를 사용하여 네트워크에서 발생하는 모든 것을 로깅할 수 있습니다. Cloud 감사 로그를 사용하면 시스템 및 사용자의 활동을 모니터링할 수 있습니다. 이러한 로그를 정기적으로 모니터링하면 PCI DSS 요구사항 10.4를 준수하는 데 도움이 되고 잠재적인 보안 위협에 신속하게 대응하고 해결할 수 있습니다. 자세한 내용은 효과적인 일일 로그 모니터링에 대한 PCI DSS 보충 자료(PDF)를 참조하세요.
Security Command Center에서는 애셋 인벤토리, 탐색, 검색, 관리를 제공하여 보안 및 데이터 공격 표면을 파악할 수 있습니다. Security Command Center는 Sensitive Data Protection 스캔 결과를 분석하여 유출된 카드 소지자 데이터를 식별하고 토큰화 시스템이 악용되어 PAN이 악의적으로 사용되지 않는지 확인하는 데 도움을 줄 수 있습니다. Event Threat Detection을 사용하는 Security Command Center에서는 공격자가 방어 기능을 파악하기 위해 시스템을 프로브할 수 있는지 여부를 표시하여 네트워크 및 VM에서 위협과 비정상적인 활동을 사전에 감지할 수 있습니다. 또한 Security Command Center에서 환경에 맞는 커스텀 보안 소스를 만들 수도 있습니다.
Google Cloud Armor는 공개용 Google Cloud 웹 애플리케이션 보안을 강화하고 PCI DSS 요구사항 6.4를 준수할 수 있도록 지원합니다. Google Cloud Armor는 다양한 일반 웹 공격에 대한 수신 요청을 평가하고 요구사항 6.4에 지정된 노동 집약적인 수동 코드 검토를 방지할 수 있도록 지원합니다. WAF를 마련하면 지속적인 규정 준수 유지하는 동시에 규정 준수에 필요한 비용과 위험을 줄일 수 있습니다.
다음 단계
- 규정 준수 의무 관리 권장사항 검토
- Google Cloud의 PCI 데이터 보안 표준 규정 준수 읽어보기
- PCI DSS 범위 지정 및 네트워크 세분화를 위한 PCI 위원회 지침(PDF)
- GKE의 PCI 청사진 사용해 보기
- PCI DSS를 위한 Kubernetes 워크로드 보안
- PCI DSS를 위한 민감한 카드 소지자 데이터 토큰화
- PCI Starter Terraform 프로젝트 배포하기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기. Cloud 아키텍처 센터 살펴보기