PCI 데이터 보안 표준 규정 준수

이 가이드에서는 Google Cloud에서 업무용으로 결제 카드 산업 데이터 보안 표준(PCI DSS)을 구현하는 방법에 대해 설명합니다. 이 가이드에서는 PCI SSC 클라우드 컴퓨팅 지침(PDF)에서 더 나아가 이 표준의 배경과 클라우드 기반 규정 준수에서 개발자의 역할을 설명하고, PCI DSS를 사용하여 결제 처리 앱을 설계, 배포, 구성하기 위한 안내를 제공합니다. 이 가이드에서는 또한 앱 모니터링, 로깅, 검증 방법도 설명합니다.

PCI 보안 표준 위원회에서 작성된 PCI 데이터 보안 표준은 결제 카드(신용카드체크카드 포함) 정보를 처리하는 기업을 위한 정보 보안 표준입니다. PCI 보안 표준 위원회에는 모든 주요 결제 카드 회사가 포함되어 있습니다. Visa, MasterCard, Discover, American Express, JCB를 사용하는 기업은 PCI DSS를 준수해야 하며, 그렇지 않으면 벌금 또는 제재를 받을 수 있습니다.

PCI DSS에는 결제 정보를 개인적으로 수집하는 판매자부터 결제 처리를 완전히 아웃소싱하는 판매자까지 여러 판매자 유형에 대한 분류가 포함되어 있습니다. 이 가이드에서는 SAQ A, SAQ A-EP, SAQ D 판매자 유형을 다룹니다.

목표

  • 결제 처리 앱 아키텍처를 검토합니다.
  • 결제 처리 환경을 설정합니다.
  • 앱 서버를 배포하고 구성합니다.
  • 로깅 및 모니터링을 설정합니다.
  • 결제 처리 환경을 검증합니다.

정의

이 가이드에서는 여러 가지 고유한 용어가 사용됩니다. 가장 일반적인 몇 가지 용어는 다음과 같습니다. 자세한 내용은 PCI DSS 용어를 참조하세요.

CDE: Cardholder Data Environment(카드 소지자 데이터 환경)의 약어입니다. 이 약어는 결제 계좌 번호 또는 카드와 관련된 모든 개인 식별 가능 정보를 포함하여 카드 소유주 데이터를 저장하거나 전송하는 앱의 모든 부분을 나타냅니다.

보완 통제: 원래 요구 사항의 의도 및 기준을 충족하고 비슷한 수준의 방어를 제공하는, 특정 요구 사항에 대한 대안적 솔루션입니다. 공식 정의에 따라, 보완 통제는 다른 PCI DSS 요구 사항을 '초과 및 상회'해야 하며, 원래 요구 사항을 준수하지 않음으로써 발생하는 추가적인 위험에 부합해야 합니다.

PAN: Primary Account Number(주 계좌 번호)의 약어이며 계좌 번호라고도 부릅니다. 발급자 및 카드 소유주 계좌를 식별하는 고유한 결제 카드 번호입니다.

QSA: Qualified Security Assessor(공인 보안 평가자)의 약어입니다. QSA는 PCI SSC(보안 표준 위원회)에 의해 PCI DSS 현장 평가를 수행할 수 있는 자격이 부여됩니다. QSA 기업 및 직원 관련 요구 사항에 대한 자세한 내용은 QSA 자격 요구 사항을 참조하세요.

SAQ: Self-Assessment Questionnaire(자체 평가 질문)의 약어이며, 특정 항목의 PCI DSS 평가에 따른 자체 평가 결과를 기록하기 위해 사용되는 보고 도구입니다.

범위: PCI DSS 평가에 포함되는 시스템, 절차, 사람을 포함합니다.

토큰화: PAN(주 계좌 번호)을 토큰이라고 부르는 대리 값으로 바꾸는 프로세스입니다. 이후에는 PAN이 보안 조회소에 저장됩니다. 토큰화 해제는 이와 반대로 해당 토큰으로 PAN을 조회하는 과정입니다. 토큰은 해시 또는 할당된 값일 수 있습니다.

배경

PCI DSS는 카드 소유주 보안 향상을 위해 디자인된 요구 사항 목록을 제공합니다. 이러한 요구 사항은 번호로 지정된 12가지의 주요 파트와 그 아래의 여러 하위 파트로 나뉩니다. 이 문서에서는 해당 문맥을 확인할 수 있도록 파트 번호가 사용되지만, 적용 가능한 모든 요구 사항 목록이 섹션에 참조되지는 않습니다.

PCI DSS 규정 준수 요구 사항은 해당 기업이 결제 카드 트랜잭션을 처리하는 방법(유형)과 연간 수행되는 트랜잭션 수(수준)에 따라 달라집니다.

트랜잭션 수가 늘어남에 따라 PCI DSS 판매자 수준도 높아지며, PCI DSS 규정 준수 가이드라인이 더 엄격해집니다. 가장 높은 판매자 수준인 Level 1에서는 PCI DSS에 감사가 요구됩니다. 수준은 카드 브랜드에 따라 달라집니다. Level 1은 American Express의 경우 연간 트랜잭션 수 250만 건으로 정의되며, Visa, Mastercard, Discover는 연간 트랜잭션 수 600만 건으로 정의됩니다. 각 카드 브랜드는 이 문서의 범위를 벗어나는 추가적인 수준 요구 사항이 있습니다. 결제 처리 환경이 판매자 수준을 지원하도록 감사되었는지 확인하세요.

Google Cloud는 Level 1 PCI DSS 3.2.1 호환 서비스 제공업체이기 때문에 개발자의 업체 수준이 무엇이든 PCI DSS 규정 준수를 지원할 수 있습니다. 규정 준수 확인 섹션에서는 Google에서 지원되는 범위를 설명합니다.

다른 기본적인 변수는 개발자의 SAQ 유형입니다. SAQ에는 개발자가 PCI DSS를 준수하기 위해 해결해야 하는 기준이 설명되어 있습니다. 개발자의 SAQ 유형은 개발자의 앱 아키텍처 및 개발자가 결제 카드 데이터를 처리하는 정확한 방식에 따라 결정됩니다. 클라우드 환경에서 대부분의 판매자는 다음 중 하나에 해당합니다.

SAQ 유형 설명
A 결제 카드 처리를 제3자 사이트로 완전히 아웃소싱하는 판매자입니다. 고객은 도메인(<iframe> 웹 양식을 통한 도메인 포함)을 떠나 결제를 완료한 다음 개발자의 앱으로 돌아옵니다.

즉, 회사는 고객 카드 데이터에 어떤 방식으로든 접근할 수 없습니다.
A-EP 결제 처리를 제3자 제공업체로 아웃소싱하지만 결제 과정 중 어느 지점에서든 고객 카드 데이터에 액세스할 수 있는 판매자입니다. 카드 데이터에 액세스할 수 있는 판매자에는 제3자 결제 페이지에 포함된 자바스크립트 또는 CSS와 같은 판매자가 통제하는 페이지 요소가 포함됩니다.

즉, 결제 처리 앱이 카드 데이터를 클라이언트 측의 대행업체로 전달하거나 대행업체가 개발자에 의해 호스팅되는 모든 콘텐츠를 렌더링합니다.
D 온라인 결제를 수락하며, SAQ A 또는 SAQ A-EP 자격이 없는 판매자입니다. 이 유형에는 토큰화에 관계없이 자체 서버에서 결제 대행업체 API를 호출하는 모든 판매자가 포함됩니다.

즉, 개발자가 SAQ A 또는 SAQ A-EP가 아니라면 SAQ D에 해당합니다.

SAQ D는 판매자서비스 제공업체로 구분됩니다. 서비스 제공업체는 이 문서에서 다루지 않으며, 여기에서 언급되는 모든 SAQ D는 PCI DSS에 정의된 판매자를 의미합니다.
SAQ 요구사항을 나타내는 벤다이어그램입니다. SAQ A-EP는 SAQ A를 포함하며, SAQ D는 SAQ A-EP를 포함합니다.
SAQ 요구사항을 나타내는 벤다이어그램입니다. SAQ A-EP는 SAQ A를 포함하며, SAQ D는 SAQ A-EP를 포함합니다.

판매자는 수준 및 유형에 따라 임의로 조합될 수 있으며, 규정 준수 요구 사항은 해당 환경에 따라 크게 달라질 수 있습니다.

규정 준수 확인

Google은 Google 서버에 저장되는 정보의 보안을 위해 다양한 기술과 프로세스를 사용합니다. Google은 Google에서 관리하는 Google Cloud 기술 및 인프라에 적용되는 PCI DSS 요구사항을 독립적으로 검증했습니다. Google은 판매자에게 Google 인프라에서 실행되는 컴퓨팅 인스턴스를 제어할 수 있는 권한을 제공하지만, 판매자가 Google Cloud에 배포하는 운영체제, 패키지 또는 앱의 보안을 제어하지는 않습니다. 배포하는 운영체제 패키지 및 앱에 대한 PCI DSS 요구사항과 아키텍처에 필요한 기타 맞춤설정을 준수하는 것은 개발자의 책임입니다.

Google Cloud는 Level 1 서비스 제공업체에 대해 설정된 PCI DSS 요구사항 및 모든 적용 가능한 서비스 제공업체 요구사항을 따릅니다. Google Cloud 공유 책임 규정에는 PCI DSS의 규정 준수 의무가 기술되어 있습니다. 이 책임 규정은 PCI DSS 규정을 준수하고 고유한 PCI DSS 감사를 수행할 때 유용하게 사용될 수 있습니다.

제품 안내

App Engine

App Engine 수신 방화벽 규칙이 제공되지만 송신 규칙은 아직 제공되지 않습니다. 요구 사항 1.2.1 및 1.3.4에 따라 모든 아웃바운드 트래픽이 승인되었는지 확인해야 합니다. SAQ A-EP 및 SAQ D 유형의 판매자는 보완 통제를 제공하거나 다른 Google Cloud 제품을 사용해야 합니다. 이 경우 Compute Engine 및 GKE가 대안 제품으로 권장됩니다.

Cloud Functions

App Engine과 유사하게 Cloud Functions는 현재 이그레스 방화벽 규칙을 지원하지 않습니다. SAQ A-EP 및 SAQ D 유형의 판매자는 보완 통제를 제공하거나 다른 Google Cloud 제품을 사용해야 합니다. 이 경우 Compute EngineGKE가 대안 제품으로 권장됩니다.

Google Kubernetes Engine

GKE 클러스터의 노드 및 포드에는 모든 판매자 관리 서버와 동일한 방식이 사용됩니다. 노드 및 포드 수준 모두에서 로깅, 계측, 패치 적용을 구현합니다. 카드 소유주 데이터는 노드 수준에서 보관하지 마세요. 하지만 노드에 모든 범위 내 포드가 포함되거나 포함될 수 있는 경우 계속 노드가 범위 내에 있게 됩니다.

제어 영역(클러스터 마스터)에 대한 액세스를 제한하려면 승인된 네트워크를 사용하여 외부 Google Cloud의 신뢰할 수 없는 IP 주소를 차단합니다. 이러한 CIDR 규칙은 비공개 클러스터와 호환되며 허용 목록의 역할을 합니다.

범위 내 프로젝트에 다른 유형의 포드가 포함된 경우 GKE 클러스터에서 네트워크 정책을 구현합니다. 네트워크 정책은 개발자가 이미 익숙할 수도 있는 VPC(가상 사설 클라우드) 방화벽과 비슷하게 작동합니다. IP 규칙 또는 라벨을 기준으로 트래픽을 허용하거나 거부할 수 있습니다.

요구 사항 2.2.1에 따르면 서버당 하나의 기본 기능만 구현할 수 있습니다. 이 요구 사항은 2개 이상의 포드 유형을 호스팅하는 단일 GKE 클러스터를 금지하지 않습니다. GKE 노드의 기본 기능은 컨테이너를 제공하고 관리하는 것입니다. 올바르게 디자인된 경우, 개별 포드는 다일 클러스터에서 이러한 기본 기능 규칙을 고수할 수 있습니다.

Cloud Storage

요구 사항 3.4에 따르면 저장된 위치에 관계없이 PAN을 판독할 수 없어야 합니다. Google은 저장 상태의 데이터에 대한 암호화를 자동으로 제공하지만, 이 규칙에서 요구되는 단방향 해시, 잘라내기 또는 토큰화를 자동으로 수행하지 않습니다.

아키텍처 예

이 섹션에서는 SAQ A, SAQ A-EP, SAQ D를 준수하는 환경을 구현하기 위한 접근 방법을 보여줍니다.

아키텍처 개요

SAQ A

SAQ A는 가장 기본적인 결제 처리 아키텍처입니다. 제3자에 의해 결제가 처리되고, 카드 데이터는 판매자 앱 또는 페이지에서 액세스되지 않습니다.

대략적인 결제 처리 흐름은 다음과 같습니다.

  1. 고객이 자신의 옵션을 선택하고 체크아웃을 진행합니다.

  2. 체크아웃 앱이 고객을 제3자 결제 프로세서로 리디렉션합니다.

  3. 고객이 제3자 프로세서가 소유하고 유지 관리하는 결제 양식에 자신의 결제 카드 정보를 입력합니다.

  4. 제3자 프로세서가 결제 카드 정보를 확인한 후 해당 카드에 비용을 부과하거나 카드를 거절합니다.

  5. 트랜잭션을 처리한 후 제3자 결제 프로세서가 트랜잭션 세부정보와 함께 고객을 다시 판매자 앱으로 보냅니다.

  6. 판매자 앱이 트랜잭션 확인을 위해 결제 프로세서에 확인 요청을 보냅니다.

  7. 결제 대행업체가 트랜잭션 세부정보를 확인하고 응답합니다.

고객의 브라우저, 판매자 사이트, 결제 대행업체, 결제 게이트웨이 사이의 정보 처리.
SAQ A 제3자 결제 처리 환경 아키텍처

SAQ A-EP

SAQ A-EP 결제 처리 아키텍처는 Compute Engine 가상 머신 인스턴스에서 실행되는 결제 처리 앱을 중심으로 합니다. 이러한 인스턴스는 보안 비공개 네트워크에 있으며, 보안 채널을 사용해서 네트워크 외부에 있는 서비스와 통신합니다.

대략적인 결제 처리 흐름은 다음과 같습니다.

  1. 고객이 개발자 회사에서 소유하고 유지 관리하는 결제 양식에 자신의 결제 카드 정보를 입력합니다.

  2. 고객이 자신의 정보를 제출하면 해당 양식 정보가 제3자 결제 프로세서에 안전하게 전달됩니다.

  3. 제3자 프로세서가 결제 카드 정보를 확인한 후 해당 카드에 비용을 부과하거나 카드를 거절합니다.

  4. 결제 대행업체가 개발자의 결제 앱으로 응답을 다시 보낸 후, 결제 앱이 메시지를 개발자의 핵심 앱으로 전달합니다.

이러한 모든 상호작용은 Cloud LoggingCloud Monitoring을 통해 로깅되고 모니터링됩니다.

SAQ A-EP 결제 처리 환경 아키텍처
SAQ A-EP 결제 처리 환경 아키텍처

SAQ D

SAQ D 결제 처리 아키텍처는 Compute Engine 가상 머신 인스턴스에서 실행되는 결제 처리 앱을 중심으로 합니다. 이러한 인스턴스는 보안 비공개 네트워크에 있으며, 보안 채널을 사용해서 네트워크 외부에 있는 서비스와 통신합니다.

대략적인 결제 처리 흐름은 다음과 같습니다.

  1. 고객이 개발자 회사에서 소유하고 유지 관리하는 결제 양식에 자신의 결제 카드 정보를 입력합니다.

  2. 고객이 자신의 정보를 제출하면 개발자의 결제 앱이 양식 정보를 수신합니다.

  3. 결제 앱이 결제 정보를 검증하고 백엔드 API를 통해 제3자 결제 프로세서로 이를 안전하게 전달합니다.

  4. 제3자 프로세서가 결제 카드 정보를 확인한 후 해당 카드에 비용을 부과하거나 카드를 거절합니다.

  5. 결제 프로세서가 개발자의 결제 앱으로 응답을 다시 보낸 후, 결제 앱이 메시지를 개발자의 핵심 앱으로 전달합니다.

이러한 모든 트랜잭션은 LoggingMonitoring을 통해 로깅되고 모니터링됩니다.

SAQ D 결제 처리 환경 아키텍처
SAQ D 결제 처리 환경 아키텍처

고객 측 결제 처리 흐름

SAQ A

이 섹션에서는 앱을 사용하는 고객의 관점에서 제3자 결제 처리 흐름을 설명합니다.

고객 측 SAQ A 제3자 결제 처리 흐름
고객 측 SAQ A 제3자 결제 처리 흐름

고객이 개발자의 결제 양식에 액세스할 때, 앱은 결제 대행업체가 호스팅하는 <iframe>을 제공합니다. 개발자 앱은 교차 출처 리소스 공유 제한에 따라 <iframe>의 콘텐츠에 액세스하거나 이를 모니터링할 수 없습니다. 고객이 자신의 결제 카드 정보를 제출하면 결제 대행업체가 카드를 승인하거나 거부한 다음 고객을 다시 개발자 앱으로 보냅니다. 그러면 개발자 앱은 결제 대행업체로부터 받은 트랜잭션 응답을 확인하고 이에 따라 작업을 수행합니다. 개발자 앱은 어떠한 결제 카드 정보도 액세스하거나 처리하지 않습니다.

SAQ A-EP

이 섹션에서는 앱을 사용하는 고객의 관점에서 앞에서 설명한 것과 동일한 내부 결제 처리 흐름을 설명합니다.

고객 측 SAQ A-EP 제3자 결제 처리 흐름
고객 측 SAQ A-EP 제3자 결제 처리 흐름

고객이 개발자 결제 양식의 URL에 액세스하면 사이트는 개발자 결제 앱에서 호스팅하는 양식을 표시합니다. 고객이 자신의 결제 카드 정보를 제출하면 양식이 결제 대행업체에 직접 전달됩니다. 대행업체는 카드를 승인하거나 거부한 후 고객을 다시 개발자 앱으로 보냅니다. 그러면 앱이 결제 대행업체로부터 받은 거래 응답을 확인하고 이에 따라 작업을 수행합니다. 고객이 제3자 결제 대행업체를 보지 못할 수 있지만, 개발자 앱은 서버 측에서 어떠한 결제 카드 정보도 액세스하지 않았습니다.

SAQ D

이 섹션에서는 앱을 사용하는 고객의 관점에서 내부 결제 처리 흐름을 설명합니다.

고객 측 SAQ D 제3자 결제 처리 흐름
고객 측 SAQ D 제3자 결제 처리 흐름

고객이 개발자의 결제 양식 URL에 액세스하면 HTTPS 부하 분산기를 통해 양식에 안전하게 라우팅됩니다. 고객이 자신의 결제 카드 정보를 제출하면 개발자의 결제 처리 앱이 이 정보를 제3자 결제 프로세서로 안전하게 전송합니다. 제3자 결제 프로세서는 카드를 승인 또는 거절한 후 개발자의 결제 처리 앱으로 응답을 반환합니다.

결제 처리 내부 흐름

SAQ A 및 A-EP

이 섹션에서는 앱을 실행하는 서버의 관점에서 결제 처리 흐름을 설명합니다.

SAQ A 및 SAQ A-EP 내부 흐름
SAQ A 및 SAQ A-EP 내부 흐름

개발자의 결제 처리 앱은 제3자 결제 대행업체가 반환한 응답을 수신하고 파싱한 다음 응답 데이터 일부 또는 전부를 핵심 앱으로 보냅니다. 이 시점에서 개발자의 결제 처리 앱은 트랜잭션이 완료됩니다. 핵심 앱은 고객 알림 작업을 처리합니다.

SAQ D

이 섹션에서는 앱을 실행하는 서버의 관점에서 내부 결제 처리 흐름을 설명합니다.

SAQ D 내부 흐름
SAQ D 내부 흐름

결제 처리 앱은 고객이 제출한 결제 카드 정보를 확인한 후 백엔드 API를 통해 이를 결제 대행업체로 보냅니다. 대행업체가 청구를 시도하고 트랜잭션 세부정보로 응답합니다. 개발자 앱이 응답을 수신하고 처리한 다음 응답 데이터의 일부 또는 전부를 핵심 앱으로 보냅니다. 이 시점에서 개발자의 결제 처리 앱은 트랜잭션이 완료됩니다. 핵심 앱은 고객 알림 작업 및 제품 제공 작업을 처리합니다.

모니터링 및 로깅 데이터 흐름

모니터링 및 로깅 흐름은 다음과 같이 설계됩니다.

모니터링 및 로깅 흐름
모니터링 및 로깅 흐름

결제 처리 환경 설정

이 섹션에서는 결제 처리 환경을 설정하는 방법을 설명합니다. 설정에는 다음이 포함됩니다.

  • 프로덕션 환경에서 결제 처리 환경을 격리하기 위해 새로운 Google Cloud 계정을 만듭니다.
  • 해당 환경에 대한 액세스를 제한합니다.
  • 가상 리소스를 설정합니다.
  • 앱 서버를 설정하기 위해 사용할 기본 Linux 이미지를 디자인합니다.
  • 보안 패키지 관리 솔루션을 구현합니다.

새 계정 설정

액세스 제한 및 규정 준수 감사를 단순화하기 위해 개발자의 표준 프로덕션 환경 및 모든 개발/QA 환경으로부터 완전히 격리된 프로덕션 품질의 결제 처리 환경을 만듭니다(요구 사항 6.4.1). 격리를 위해 핵심 프로덕션 환경 계정과는 별도로 Google Cloud 계정을 만들고 사용합니다. ID 및 액세스 관리(IAM) 구성 경험이 있는 사용자는 범위 내 작업에 대해 별도의 프로젝트를 사용해서 동일한 격리 수준을 달성할 수 있습니다.

환경 액세스 제한

결제 시스템 코드를 배포하거나 결제 시스템 머신을 관리하는 개별 사용자에게만 결제 처리 환경 액세스 권한을 허용합니다(섹션 7.1 및 요구 사항 8.1.1). 이러한 방식을 최소 권한의 원칙이라고 부릅니다. IAM 역할을 사용해서 액세스 권한을 제한합니다. 가능한 모든 경우에 역할을 사용하고, 예상 작업을 수행하는 데 필요한 권한만 부여하고, 서비스에 대한 완전한 루트 액세스 권한이 합법적으로 요구되는 구성원에게만 소유자 역할을 부여하는 것이 좋습니다. 자세한 내용은 IAM 보안 가이드를 참조하세요.

모든 관리되는 서비스에 대한 자동화된 액세스에는 서비스 계정이 사용됩니다. 서비스 계정은 앱 인증 및 승인을 관리하는 방법을 제공하여 앱 관리 수명 주기를 단순화합니다. 이러한 계정은 공통 ID를 갖는 비슷한 앱 및 기능으로 가상 머신 인스턴스를 그룹화할 수 있는 유연하지만 안전한 방식을 제공합니다. IAM 역할 및 VPC 방화벽 규칙을 통해 서비스 계정 수준에서 보안 및 액세스 제어를 강화할 수 있습니다.

폴더에 적용하는 IAM 규칙은 해당 폴더에 포함된 모든 항목으로 상속됩니다. 기본 권한은 모두 거부(요구 사항 7.2.3)이며, 개발자가 적용하는 모든 규칙은 권한을 추가만 합니다.

요구사항 8.2.3에서는 사용자 비밀번호에 대한 몇 가지 기본 규칙을 제공합니다. NIST(미국 국립 표준 기술 연구소)는 NIST SP800-63B의 섹션 5.1.1에서 보안 비밀번호를 위한 보다 안전한 규칙 모음을 정의하고 있습니다. Google은 가능한 모든 경우에 NIST 디지털 ID 가이드라인을 따를 것을 권장합니다.

PCI DSS SAQ D 섹션 12.7에서는 개발자의 범위 내 환경에 대한 액세스 권한이 있는 개별 사용자에게 해당 환경에 대한 액세스 권한을 부여하기 전 지역 법률에 따라 백그라운드 검사를 시행할 것을 요구합니다. 규정 준수 위반 위험을 줄이기 위해서는 개발자의 규정 준수 유형에 관계없이 이러한 범죄 이력 조사 및 관련 조사를 수행할 것을 고려하는 것이 좋습니다.

네트워크 보안

개발자의 결제 처리 앱 네트워크에 대한 인바운드 및 아웃바운드 트래픽을 보호하기 위해서는 다음을 생성해야 합니다.

  • Compute Engine 방화벽 규칙
  • Compute Engine VPN(가상 비공개 네트워크) 터널
  • Compute Engine HTTPS 부하 분산기

VPC를 만드는 경우 추가 네트워크 보안 계층에 Cloud NAT를 권장합니다. Compute Engine 및 GKE 인스턴스의 네트워크를 보호하는 데 사용할 수 있는 여러 강력한 옵션이 있습니다.

방화벽 규칙 만들기

방화벽 규칙을 사용하여 각 Compute Engine 인스턴스에 대한 인바운드 트래픽을 제한합니다(요구 사항 1.2.1 및 1.3.2). 다음 3개의 출처에서 시작된 인바운드 트래픽만 허용합니다.

  • 공개 HTTPS - 고객이 개발자의 결제 페이지에 연결할 수 있어야 합니다.
  • 개발자 앱 네트워크 - 개발자의 결제 처리 앱이 제3자 결제 프로세서로부터의 응답을 수신할 수 있어야 합니다.
  • 개발자의 회사 내부 네트워크 - 감사 및 관리 목적으로 해당 인스턴스에 개발자가 액세스할 수 있어야 합니다.

개별 인스턴스의 방화벽 규칙을 사용하여 아웃바운드 트래픽을 제한합니다. 이러한 규칙은 iptables를 사용하여 또는 보다 포괄적으로는 VPC 방화벽 규칙 및 네트워크 태그를 사용해서 로컬로 구현할 수 있습니다. 개발자의 결제 양식에서 제3자 결제 프로세서로 전송되는 아웃바운드 트래픽만 허용합니다. 이 연결은 HTTPS만 사용해야 합니다. 아래의 방화벽 규칙 로깅 섹션을 참조하여 작업을 테스트하세요.

Cloud DNS는 비공개 DNS 영역을 제공하므로 민감한 네트워크 토폴로지 데이터의 공개 유출 가능성 없이 CDE 내에 호스트를 안전하게 명명할 수 있습니다.

다음과 같이 트래픽을 제한합니다.

소스 대상 포트 방향 및 이유
공개 부하 분산기 제3자 결제 양식 tcp:443 인바운드
결제 처리 앱에 대한 공개 액세스 권한입니다.
제3자 결제 양식 제3자 결제 대행업체 tcp:443 아웃바운드
AUTH 요청을 결제 서비스 제공업체에 전달
제3자 결제 대행업체 개발자의 결제 처리 앱 tcp:5480 인바운드
결제 시스템에서 오는 AUTH 요청 수락(카드 소지자 데이터를 포함하지 않음)
개발자 회사의 사무실 네트워크 vpn-gateway tcp:8000 인바운드
로그 및 개발 머신에 액세스하기 위한 결제 처리 환경 액세스

또한 다음 트래픽은 개발자의 결제 처리 앱 내부 네트워크에서 안전하게 수행됩니다.

소스 대상 포트 이유
카드 양식 PCI 프록시 tcp:5480 결제 수단 토큰에 대한 암호화된 카드 데이터 교환
모든 호스트 Google NTP 서버 udp:123 시간 동기화
VPN 게이트웨이 모든 호스트 tcp:22 SSH(보안 셸) 연결

보안 VPN 터널 설정

Compute Engine은 개발자의 온프레미스 환경과 개발자의 결제 처리 환경 사이의 보안 VPN 터널을 설정하기 위해 사용할 수 있는 VPN 서비스를 제공합니다(섹션 2.3 및 4.1).

HTTPS 부하 분산기 만들기

Compute Engine HTTP(S) 부하 분산기를 만들면 들어오는 고객 트래픽이 안전한지 확인하는 데 도움이 될 수 있습니다(섹션 2.3 및 4.1). HTTPS 부하 분산기를 만들려면 다음이 필요합니다.

  • 결제 처리 양식에 사용되는 웹 사이트의 하위 도메인(예: payments.your-domain-name.com)
  • 하위 도메인에 대해 등록된 유효하고 서명된 SSL 인증서

웹 등록기관 도메인 구성 인터페이스에서 해당 DNS 설정을 확인하여 도메인이 유효한지 확인하세요.

기본 Linux 이미지 만들기

PCI DSS에는 호환되는 결제 처리 아키텍처에 속하는 머신을 설정하는 방법을 설명하는 요구 사항이 포함되어 있습니다. 이러한 요구사항은 여러 방법으로 구현할 수 있지만, 가장 쉬운 방법은 다음과 같습니다.

  1. 개발자의 결제 처리 앱의 범위 내에 있는 각 서버에 설치해야 하는 소프트웨어 및 라이브러리 목록을 만듭니다. 시스템에 불필요한 취약점이 발생하지 않도록 하려면 앱을 실행하는 데 필요한 최소한의 소프트웨어와 라이브러리만 포함합니다(요구사항 2.2.2). 후보에는 Cloud SDK, 언어별 런타임 및 라이브러리 또는 웹 서버가 포함될 수 있습니다.

  2. Compute Engine 사전 구성된 운영체제 이미지 중 하나를 사용하는 Compute Engine 인스턴스를 만듭니다.

  3. 위에서 개발자가 목록으로 작성한 라이브러리 및 소프트웨어를 설치합니다.

  4. ntp를 설치하고 구성하여 시스템 시계를 동기화된 상태로 유지합니다. 서버 시계를 NTP(네트워크 시간 프로토콜)로 관리하면 로그에 포함된 시간 기록의 무결성을 보장할 수 있습니다(섹션 10.4).

  5. 이미지가 안전한 Compute Engine 이미지를 만들기 위한 권장사항을 따르는지 확인합니다(섹션 2.2 전체).

  6. 기본 이미지를 구성한 후 이미지에서 커스텀 Compute Engine 디스크 이미지를 만듭니다. 이 이미지는 가상 머신 인스턴스를 만들 때 기본 Linux 이미지로 사용할 수 있습니다.

보안 패키지 관리 사용

패키지 관리는 보안이 강화된 호스팅 환경의 핵심 구성요소입니다. 섹션 2.2에 따라 업계에서 허용되는 강화 표준을 구현해야 합니다. Google의 컨테이너 최적화 OS를 사용하지 않는 한 RPM, Yum 또는 Apt와 같은 패키지 관리자가 설치되었을 수 있습니다. 개발자 앱은 NPM, PyPi 또는 Composer와 같은 고유 프로그래밍 언어별 패키지 관리자를 사용할 수 있으며, 처음 실행할 때 종속 항목을 다운로드할 수 있습니다.

앱이 인터넷에서 업데이트를 가져올 수 있는 경우, 업데이트 소스를 잠재적인 보안 위험 요소로 취급해야 합니다. 공개적으로 호스팅되는 패키지에 악의적으로 포함된 공급 측 또는 업스트림 공격이 점점 더 일반화되고 있습니다. 악의적인 코드가 포함된 업데이트를 SSH에 설치했을 때의 결과를 상상해보세요.

패키지에 대한 안전 수신자 목록을 만들고 해당 패키지가 목록과 일치하는지 확인하면 공급 측 공격 위험을 줄일 수 있습니다. 사용되는 각 패키지에 대해서는 테스트 및 승인된 버전 번호 목록을 유지합니다. 해당 해시 또는 서명과 함께 버전 번호를 기록해두세요. 앱을 설치하거나 업데이트할 때는 먼저 패키지 관리자가 해시 또는 서명을 검증했는지 확인해야 합니다.

대부분의 패키지 관리 시스템에서는 비공개 호스팅이 허용됩니다. 가능한 경우에는 개발자의 고유 비공개 패키지 관리 서버를 시작하고 테스트 및 승인된 소프트웨어만 호스팅해야 합니다. 패키지 관리자는 업데이트를 받기 위해 다른 서버에 연결할 수 없도록 잠금을 설정해야 합니다.

이상적으로, 앱 빌드 프로세스는 모든 패키지를 가져오고 검증한 후 컨테이너에 필요한 모든 것이 포함된 커스텀 디스크 이미지 버전을 만듭니다. 이렇게 하면 설치 프로그램 지연 없이 시작 및 확장될 수 있으며, 출시 시에 임의의 오류가 발생할 가능성이 줄어듭니다. 또한 단순히 해당 이미지를 시작하여 프로덕션 상태와 동일하게 앱의 이전 버전을 다시 방문하면 진단과 포렌식에 유용하게 활용할 수 있습니다.

배포 및 구성

이제는 기본 이미지로부터 인스턴스 배포 및 구성을 설정합니다.

환경 배포

PCI DSS 요구 사항을 충족하기 위해서는 매번 올바른 앱을 배포하는지, 앱을 안전하게 배포하는지, 배포 중 다른 소프트웨어 패키지를 설치하지는 않는지 확인해야 합니다. 배포 프로세스를 단순화하기 위해 Cloud Deployment Manager를 사용하여 자동화된 앱 배포를 생성하는 것을 고려해 보세요.

Deployment Manager를 사용하면 방화벽 규칙, 게이트웨이, 부하 분산기, 인스턴스를 비롯하여 전체 결제 처리 환경을 기술할 수 있습니다. 또한 Deployment Manager는 각 앱 환경의 생성 과정을 보여주는 감사 추적을 구성하고 앱 환경을 개선 및 수정할 때 해당 환경의 버전을 관리하는 데 도움이 됩니다.

자동화된 배포에서는 배포 중인 소프트웨어의 무결성(타사 소프트웨어 또는 자체 개발 소프트웨어인지 여부)을 확인해야 합니다. 패키지가 설치될 때 각 패키지에 대해 자동화된 해시를 실행하여 소프트웨어를 확인할 수 있습니다. 해시가 확인된 후에는 자동화된 테스트 프레임워크를 사용해서 보안 및 다른 테스트를 실행하고, 테스트가 통과했는지 확인할 수 있습니다.

마지막으로 Compute Engine 인스턴스를 배포할 때 인스턴스가 실패할 경우의 복구 계획을 디자인합니다. 허용 가능한 다운타임 기간이 충분히 길면 수동 복구 계획으로도 충분할 수 있지만, 그렇지 않으면 자동화된 복구 계획을 디자인해야 합니다. 자세한 내용은 재해 복구 계획 가이드, 강력한 시스템 설계, 확장 가능하고 복원력이 우수한 웹 앱 빌드를 참조하세요.

환경 구성

인스턴스가 배포된 다음에는 올바르게 구성되었는지 확인합니다. 필요에 따라 각 인스턴스 기본 이미지 위에 추가 소프트웨어 및 라이브러리를 설치합니다. 수동 구성의 복잡성, 오버헤드, 전반적인 위험을 방지하기 위해 Skaffold, Chef, Puppet, Ansible 또는 Salt와 같은 자동화된 구성 관리 도구를 사용합니다.

업스트림 소스에 대한 공격망 공격이 점점 더 큰 문제가 되고 있기 때문에, 기본 Linux 이미지를 사용하는 것 외에도 Grafeas API와 같은 도구를 사용해서 업스트림 코드를 감사해야 할 수 있습니다.

Forseti Security 구현

Forseti Security는 Google Cloud 환경의 보안을 개선할 수 있는 커뮤니티 중심의 오픈소스 도구 모음입니다. 모듈식 아키텍처를 사용하여 개별 구성요소를 구현할 수 있으며, 그 중 몇 개는 PCI DSS 내 특정 요구 사항을 해결할 수 있습니다.

Inventory는 Google Cloud 리소스의 인벤토리 스냅샷을 만들므로 아키텍처 내역 레코드를 확보할 수 있습니다.

Scanner는 Forseti Inventory에서 수집한 정보를 사용하여 Google Cloud 리소스에 대한 역할 기반 액세스 정책을 정기적으로 비교합니다. Scanner는 다음과 같이 규칙을 적용하여 Google Cloud 리소스를 감사합니다.

  • 조직, 폴더, 프로젝트에 대한 ID 및 액세스 관리(IAM) 정책
  • 버킷 ACL
  • BigQuery 데이터세트 ACL
  • Cloud SQL 인증 네트워크

Scanner를 사용하면 리소스에서 허용 또는 제외되거나 필수적인 사용자, 그룹, 도메인을 지정할 수 있으며 이러한 액세스 정책의 일관성을 유지할 수 있습니다. Scanner가 Scanner 규칙과 일치하지 않는 액세스 정책을 발견하면 해당 규칙 위반에 대한 정보를 Cloud SQL 또는 Cloud Storage에 저장할 수 있습니다. 이렇게 하면 안전하지 않거나 실수로 인한 변경을 방지할 수 있습니다.

Enforcer는 개발자가 만든 정책을 사용하여 Compute Engine 방화벽의 현재 상태를 지정된 상태와 비교합니다. Enforcer는 배치 모드에서 모든 관리형 프로젝트 또는 선택된 프로젝트 간에 정책을 비교하는 주문형 명령줄 도구입니다. Enforcer가 정책의 차이점을 발견하면 Google Cloud APIs를 사용하여 정책을 변경하고 결과 출력을 표시합니다.

Explain 부가기능 모듈은 IAM 정책에 대한 가시성을 제공합니다. Explain은 다음을 이해하는 데 도움이 될 수 있습니다.

  • 누가 어떤 리소스에 액세스할 수 있는지에 대한 정보와 사용자가 리소스와 상호작용할 수 있는 방법.
  • 특정 주체에게 특정 리소스에 대한 권한이 있는 이유 또는 권한이 없는 이유와 권한 유무를 수정하는 방법.
  • 권한을 부여하는 역할 및 최근 변경사항과 동기화되지 않은 역할.

구성이 완료되면 이메일 알림에서 Inventory 및 Scanner에 대한 이메일 알림을 전송할 수 있습니다.

변경할 수 없는 감사 로깅 구현

Logging은 여러 제품 간의 다양한 활동에 대해 감사 로그를 자동으로 생성합니다. 장기적으로 Cloud Storage 버킷 잠금(섹션 10.5)을 사용해서 변경할 수 없는 로그를 안전하게 저장할 수 있습니다. 버킷 잠금을 사용하면 몇 초에서 몇 년까지 지정한 기간 동안 모든 객체가 변경 및 삭제될 수 없도록 지정하는 정책을 설정할 수 있습니다. 사전 체험판 프로그램에 대한 액세스 권한이 필요한 경우 Google Cloud 담당자에게 문의하세요.

가상 사설 클라우드 흐름 로그 구현

VPC 흐름 로그 서비스는 가상 머신 인스턴스에서 전송 또는 수신되는 네트워크 흐름을 기록하도록 디자인되었습니다. 이러한 로그는 네트워크 모니터링(섹션 10.2), 포렌식(요구 사항 10.6.3), 실시간 보안 분석을 위해 사용할 수 있습니다.

Logging 에이전트 설치

서버에 iptables를 설정한 후 각 서버는 서버의 블록 저장소에 대한 모든 활동을 로깅합니다. 무료 할당량 및 데이터 전송 가격에 대한 세부정보는 Logging 가격 책정 페이지를 확인하세요. 이러한 로그를 보존하고 비정상 활동을 기준으로 알림을 생성하려면 각 서버에 Logging 에이전트를 설치하여 Logging 및 Monitoring에 이를 스트리밍합니다(요구사항 10.5.3).

침입 감지 시스템 통합

섹션 11.4에 설명된 결제 처리 환경의 보안을 보장하기 위해서는 잘못된 행위자가 시스템을 공격하려고 시도할 때 이를 알 수 있도록 IDS(침입 감지 시스템)를 사용합니다. 결제 처리 환경에 IDS를 배치하는 두 가지 방법은 모든 진입점에 IDS를 배치하는 방법과 모든 서버에 IDS를 설치하는 방법입니다.

환경 아키텍처의 복잡성을 줄이고 11.5를 간단하게 준수하기 위해서는 각 서버에 IDS를 설치합니다. 사용할 IDS 소프트웨어를 연구하고 선택한 후에는 각 서버의 설치 시작 스크립트에 IDS 설치를 포함합니다.

IDS 로그는 PCI DSS 규정 준수 범위에 포함되며, 보고, 알림, 감사를 위해 Logging 및 Monitoring에 전송해야 합니다.

Security Command Center 구현

Security Command Center(베타) 서비스는 보안팀이 비즈니스 손상 또는 손실을 입기 전에 데이터를 수집하고, 위협을 식별하고, 위협에 대응할 수 있도록 도와줍니다. 클라우드 리소스에 대한 위협을 빠르게 완화하고 전체 상태를 평가할 수 있도록 앱 및 데이터를 자세히 확인할 수 있습니다. Security Command Center는 클라우드 애셋 인벤토리를 조회 및 모니터링하고, 스토리지 시스템에서 민감한 정보를 검색하고, 일반적인 웹 취약점을 감지하고, 중요 리소스에 대한 액세스 권한을 검토할 수 있는 중앙화된 단일 대시보드를 제공합니다. 섹션 5 및 6.6을 포함한 여러 요구 사항을 준수할 수 있습니다.

앱 배포 자동화

구성 관리 도구를 빌드하여 앱의 최신 버전을 안전하게 검색하고 실행합니다. 위치가 안전하다면 앱을 Cloud Storage와 같은 모든 위치에서 검색할 수 있습니다.

위에 언급된 많은 구성 관리 도구에서 CI/CD(지속적 통합 및 배포) 워크플로가 지원됩니다. 이를 사용하면 자동화된 스캔(요구사항 11.2.3)을 수행하고 코드가 검토되었는지 보장할 수도 있습니다(요구사항 6.3.2).

구성 관리자 로그 캡처

구성 관리자를 설정할 때는 모든 설치 세부정보가 로깅되는지 확인합니다. 구성 프로세스를 완료한 후에는 Logging 및 Monitoring으로 로그가 제공되는지 확인합니다.

로깅 및 모니터링

섹션 10 아래의 PCI DSS 규정 준수를 확인하기 위해서는 결제 처리 환경에서 수행되는 모든 단계가 모니터링되고 기록되는지 확인해야 합니다. 모든 인스턴스의 서버 활동을 로깅하고, 모든 사용자 작업을 나중에 조사할 수 있어야 합니다.

액세스 투명성 사용 설정

액세스 투명성이라는 기능을 통해 Logging은 Google Cloud 관리자가 콘텐츠에 액세스할 때 거의 실시간 수준의 로그를 제공합니다. Cloud 감사 로그를 통해서도 관리자의 행동을 파악할 수 있습니다. 하지만 이 감사 추적은 대개 클라우드 공급자의 지원 또는 엔지니어링 팀이 개입한 작업은 제외합니다. 예를 들어 액세스 투명성 로깅을 사용하기 전에는 Google 지원에서 데이터 액세스가 필요한 티켓을 개설하더라도 이러한 활동이 Cloud 감사 로그에서 추적되지 않았습니다. 액세스 투명성은 이 문제를 해결해 지원 또는 엔지니어링 담당자의 타겟팅된 수동 액세스에 대해 실시간에 가까운 로그를 포착합니다.

Google은 최근 액세스 승인을 출시했습니다. (액세스 승인은 사전 체험판 출시 단계에 있습니다.) 액세스 투명성은 Google 지원 및 엔지니어링팀의 액세스에 대한 통계를 제공합니다. 액세스 승인은 데이터에 대한 액세스를 명시적으로 승인하거나 그러한 액세스가 발생하기 전 Google Cloud에 대한 구성을 명시적으로 승인할 수 있게 해줍니다. 자세한 내용을 보고 사전 체험판을 요청하려면 링크된 페이지를 참조하세요.

방화벽 규칙 로깅 사용

방화벽 규칙 로깅을 사용하면 개별 규칙 수준에서 로깅을 사용 설정할 수 있습니다. 개발자가 직접 만든 규칙에 해당하는 VPC 내 TCP 및 UDP 연결을 기록할 수 있습니다. 이는 네트워크 액세스를 감사하거나 네트워크가 승인되지 않은 방식으로 사용되고 있음을 미리 경고하는 데 유용할 수 있습니다.

VPC 서비스 제어 사용

VPC 서비스 제어(베타)를 사용하면 Cloud Storage 버킷, Cloud Bigtable 인스턴스, BigQuery 데이터세트와 같은 Google Cloud 리소스 주위에 보안 경계를 정의하여 VPC의 데이터를 통제하고 데이터 무단 반출 위험을 완화할 수 있습니다(요구사항 1.2.1 및 1.3.4). VPC 서비스 제어를 통해 Google Cloud의 완전 관리형 스토리지와 데이터 처리 기능을 활용하면서도 민감한 정보는 비공개로 유지할 수 있습니다. 자세한 내용은 사전 체험판을 참조하세요.

VPC 흐름 로그 설정

VPC 흐름 로그가 사용 설정된 카드 소지자 데이터 환경
VPC 흐름 로그가 사용 설정된 CDE

VPC 흐름 로그는 VM 인스턴스에서 전송 또는 수신되는 네트워크 트래픽 흐름을 기록합니다. 이 로그는 PCI DSS에서 모니터링, 감사, 포렌식, 실시간 보안 분석을 수행하는 데 유용합니다. 각 VPC 네트워크 서브넷에는 흐름 로그를 개별적으로 사용 설정하거나 중지할 수 있습니다. 범위 내 CDE에서 흐름 로그를 사용 설정만 하면 로그 데이터 양을 최소화할 수 있습니다.

송신 방화벽 규칙과 함께 흐름 로그를 사용하면 감사를 수행할 수 있고 우회하기 어려운 방식으로 아웃바운드 트래픽을 승인된 엔드포인트로 제한할 수 있습니다(요구 사항 1.2.1 및 1.3.4).

개별 HTTP 요청 로깅과 같이 흐름 로그가 제공할 수 있는 것보다 자세한 데이터가 필요한 경우 앱 또는 프록시 아웃바운드 요청에서 제어 기능을 구현할 수 있습니다. 이 작업은 액세스 로그를 Logging으로 전달하도록 구성된 개발자 고유의 역방향 프록시 서버를 통해 수행할 수 있습니다. Compute Engine에서 Squid 프록시 서버를 설정하는 방법에 대한 안내는 네트워크 프록시 설정을 참조하세요. 병목 현상을 방지하기 위해서는 최소한 2개 이상의 중복된 프록시 서버를 설정합니다.

내부 액세스 데이터 로깅

외부 위협을 로깅하는 것 외에도, 결제 처리 환경에 대해 관리자 권한이 있는 개별 사용자의 활동도 모니터링하고 로깅합니다(섹션 10.2). 이를 이해서는 셸 명령어를 로깅할 수 있습니다. 일부 오픈소스 도구는 셸 명령어를 감사하고 이를 로깅으로 전송할 수 있습니다. 이 태스크에는 일반적으로 OSSEC 또는 Tripwire가 사용됩니다.

Monitoring 알림 설정

결제 처리 환경에서 문제가 발생할 경우 알림을 전송하도록 Monitoring을 구성합니다(섹션 10.6). 알림에 환경, 감사, 내부 앱 이벤트가 포함되는지 확인합니다. 결제 처리 앱의 각 구성요소에 대한 잠재적인 위험 또는 공격 벡터를 기준으로 알림 전략을 만듭니다. 예를 들어 성공 여부에 관계없이 침입 시도가 IDS에서 감지된 경우 Monitoring 알림을 트리거합니다. 방화벽 규칙 로깅을 사용하여 특정 네트워크 정책 위반 시도에 따라 알림을 트리거할 수 있습니다.

BigQuery에 로그 스트리밍

Cloud Storage 및 BigQuery에 Logging 로그 스트리밍
Cloud Storage 및 BigQuery에 Logging 로그 스트리밍

필요한 경우 나중에 분석할 수 있도록 Logging 로그를 BigQuery로 내보낼 수 있습니다. BigQuery는 큰 데이터세트를 쿼리하도록 최적화되었기 때문에 대규모 로그 분석에 이상적인 도구입니다. Logging은 거의 실시간 분석이 필요한 로그도 BigQuery에 직접 로깅할 수 있습니다(요구사항 10.6.1).

기밀 데이터 삭제를 위해 Cloud Data Loss Prevention 사용

분석 또는 개발 목적과 같이 범위 내에 자체적으로 포함되지 않았지만 범위 내 앱에 포함된 데이터의 일부를 사용해야 할 경우가 많습니다. Cloud Data Loss Prevention을 사용하여 기밀 데이터가 삭제된 후에만 PCI 데이터에 대한 액세스 권한을 앱에 부여합니다(요구사항 6.4.3).

앱 보안

앱 보안을 위해서는 먼저 관리자 인터페이스를 평가해야 합니다. 또한 Cloud Key Management Service를 사용할 수도 있습니다.

관리자 인터페이스 평가

대부분의 전자 상거래 앱에는 고객 서비스 청구 포털과 같은 고유한 콘솔 이외의 관리자 인터페이스가 포함되어 있습니다. 이러한 도구는 강력한 액세스 제어 기능이 포함되어야 하며, 다중 요소 인증(섹션 8.3)을 사용하는 개별화된 액세스 권한을 포함하고, 감사 로깅을 사용해서 구현되어야 합니다(섹션 10.2).

개발자가 생성하는 모든 로그는 다음과 같은 질문에 답변할 수 있어야 합니다. 누가 무엇을 했는가? 작업을 수행한 위치는 어디인가? 작업 수행 시간은 언제인가? 섹션 2.3에 따라 이러한 도구에 대한 모든 액세스는 강력한 전송 암호화를 사용해야 합니다. 민감한 정보는 관리자 도구에 표시하기 전에 Cloud Data Loss Prevention을 사용하여 필터링합니다.

Cloud KMS(Key Management Service) 사용

Cloud KMS는 암호화 키를 관리할 수 있는 서비스입니다. AES-256, RSA 2048, RSA 3072, RSA 4096, EC P256, EC P384 암호화 키를 생성, 사용, 순환, 폐기할 수 있습니다. Cloud KMS를 사용하면 코드 또는 구성 파일에 저장된 일반 텍스트 비밀번호를 삭제하여 요구사항 3.5, 3.6, 6.3.1, 8.2의 규정 준수를 간소화할 수 있습니다.

환경 검증

환경이 구현된 후에는 프로덕션 트래픽이 통과되기 전에 환경을 검증해야 합니다.

  • Level 1 판매자인 경우에는 QSA(공인 보안 감정평가사)가 해당 환경을 검증해야 합니다. QSA는 PCI 보안 표준 위원회에서 PCI 환경을 검증하고 승인 표시를 제공하도록 승인된 회사 또는 개인입니다.
  • Level 2 판매자 이하인 경우에는 자체 평가 질문을 작성하여 해당 환경을 검증할 수 있습니다.

다음 단계