이 가이드에서는 Google Cloud에서 업무용으로 결제 카드 산업 데이터 보안 표준(PCI DSS)을 구현하는 방법에 대해 설명합니다. 이 가이드에서는 PCI SSC 클라우드 컴퓨팅 지침(PDF)에서 더 나아가 이 표준의 배경과 클라우드 기반 규정 준수에서 개발자의 역할을 설명하고, PCI DSS를 사용하여 결제 처리 앱을 설계, 배포, 구성하기 위한 안내를 제공합니다. 또한 이 튜토리얼에서는 앱 모니터링, 로깅, 검증 방법도 설명합니다.
이 문서는 해당하는 경우 PCI DSS 4.0 요구사항을 다룹니다.
PCI 보안 표준 위원회에서 작성된 PCI 데이터 보안 표준은 결제 카드(신용카드 및 체크카드 포함) 정보를 처리하는 기업을 위한 정보 보안 표준입니다. PCI 보안 표준 위원회에는 모든 주요 결제 카드 회사가 포함되어 있습니다. Visa, MasterCard, Discover, American Express, JCB, UnionPay를 사용하는 기업은 PCI DSS를 준수해야 하며, 그렇지 않으면 벌금 또는 제재를 받을 수 있습니다.
PCI DSS에는 결제 정보를 개인적으로 수집하는 판매자부터 결제 처리를 완전히 아웃소싱하는 판매자까지 여러 판매자 유형에 대한 분류가 포함되어 있습니다. 이 가이드에서는 SAQ A, SAQ A-EP, SAQ D 판매자 유형을 다룹니다.
목표
- 결제 처리 앱 아키텍처를 검토합니다.
- 결제 처리 환경을 설정합니다.
- 앱 서버를 배포하고 구성합니다.
- 로깅 및 모니터링을 설정합니다.
- 결제 처리 환경을 검증합니다.
정의
이 가이드에서는 여러 가지 고유한 용어가 사용됩니다. 가장 일반적인 몇 가지 용어는 다음과 같습니다. 자세한 내용은 PCI DSS 용어를 참조하세요.
CDE: Cardholder Data Environment(카드 소지자 데이터 환경)의 약어입니다. 이 약어는 결제 계좌 번호 또는 카드와 관련된 모든 개인 식별 정보를 포함하여 카드 소유주 데이터를 저장하거나 전송하는 앱의 모든 부분을 나타냅니다.
보완 통제: 적법한 기술 또는 문서화된 비즈니스 제약조건으로 인해 항목이 명시한 요구사항을 명시적으로 충족할 수 없는 경우에 고려할 수 있는 대안 솔루션입니다. 항목은 이러한 다른 제어를 구현할 때 요구사항과 관련된 위험을 충분히 완화해야 합니다. 보완 통제 사용에 대한 지침은 PCI DSS 요구사항 및 보안 평가 절차의 부록 B 및 C를 참조하세요.
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 4.0 호환 서비스 제공업체이기 때문에 개발자의 업체 수준이 무엇이든 PCI DSS 규정 준수를 지원할 수 있습니다. 규정 준수 확인 섹션에서는 Google에서 지원되는 범위를 설명합니다.
다른 기본적인 변수는 개발자의 SAQ 유형입니다. SAQ에는 개발자가 자가 진단을 받을 수 있는 경우 PCI DSS를 준수하기 위해 해결해야 하는 기준이 설명되어 있습니다. 개발자의 SAQ 유형은 개발자의 앱 아키텍처 및 개발자가 결제 카드 데이터를 처리하는 정확한 방식에 따라 결정됩니다. 클라우드 환경에서 대부분의 판매자는 다음 중 하나에 해당합니다.
| SAQ 유형 | 설명 |
|---|---|
| A | 결제 카드 처리를 제3자 사이트로 완전히 아웃소싱하는 판매자입니다. 고객은 도메인(<iframe> 웹 양식을 통한 도메인 포함)을 떠나 결제를 완료한 다음 개발자의 앱으로 돌아옵니다.즉, 회사는 고객 카드 데이터에 어떤 방식으로든 접근할 수 없습니다. |
| A-EP | 결제 처리를 제3자 제공업체로 아웃소싱하지만 결제 과정 중 어느 지점에서든 고객 카드 데이터에 액세스할 수 있는 판매자입니다. 카드 데이터에 액세스할 수 있는 판매자에는 제3자 결제 페이지에 포함된 JavaScript 또는 CSS와 같은 판매자가 통제하는 페이지 요소가 포함됩니다. 즉, 결제 처리 앱이 카드 데이터를 클라이언트 측의 대행업체로 전달하거나 프로세서가 개발자에 의해 호스팅되는 모든 콘텐츠를 렌더링합니다. |
| D | 온라인 결제를 수락하며, SAQ A 또는 SAQ A-EP 자격이 없는 판매자입니다. 이 유형에는 토큰화에 관계없이 자체 서버에서 결제 대행업체 API를 호출하는 모든 판매자가 포함됩니다. 즉, 개발자가 SAQ A 또는 SAQ A-EP가 아니라면 SAQ D에 해당합니다. SAQ D는 판매자와 서비스 제공업체로 구분됩니다. 서비스 제공업체는 이 문서에서 다루지 않으며, 여기에서 언급되는 모든 SAQ D는 PCI DSS에 정의된 판매자를 의미합니다. |
규정 준수 지원
Google은 Google 서버에 저장되는 정보의 보안을 위해 다양한 기술과 프로세스를 사용합니다. Google은 Google에서 관리하는 Google Cloud 기술 및 인프라에 적용되는 PCI DSS 요구사항을 독립적으로 검증했습니다. 규정 준수 보고서 관리자에서 Google의 PCI DSS 규정 준수 보고서를 다운로드할 수 있습니다. Google은 판매자에게 Google 인프라에서 실행되는 컴퓨팅 인스턴스를 제어할 수 있는 권한을 제공하지만, 판매자가 Google Cloud에 배포하는 운영체제, 패키지 또는 앱의 보안을 제어하지는 않습니다. 배포하는 운영체제 패키지 및 앱에 대한 PCI DSS 요구사항과 아키텍처에 필요한 기타 맞춤설정을 준수하는 것은 개발자의 책임입니다.
Google Cloud는 Level 1 서비스 제공업체에 대해 설정된 PCI DSS 요구사항 및 모든 적용 가능한 서비스 제공업체 요구사항을 따릅니다. Google Cloud 공유 책임 규정에는 PCI DSS의 규정 준수 의무가 기술되어 있습니다. 이 책임 규정은 PCI DSS 규정을 준수하고 고유한 PCI DSS 감사를 수행할 때 유용하게 사용될 수 있습니다.
제품 안내
이 섹션에는 PCI DSS 환경에 사용되는 아키텍처에서 일반적으로 사용되는 Google Cloud 서비스에 대한 안내가 포함되어 있습니다.
App Engine
App Engine 인그레스 방화벽 규칙 및 이그레스 트래픽 제어를 사용합니다.
Cloud Run
Cloud Run 인그레스 설정, VPC 서비스 제어, VPC 커넥터의 이그레스 제어를 사용합니다. 필요한 경우 고정 아웃바운드 IP 주소를 구성하세요.
Cloud Functions
Cloud Functions 인그레스 및 이그레스 네트워크 설정을 사용합니다.
Cloud Logging
Cloud Logging은 상호작용을 로깅합니다.
Cloud Monitoring
Cloud Monitoring은 상호작용을 모니터링합니다.
Google Kubernetes Engine
PCI DSS 환경에 Google Kubernetes Engine을 사용하는 방법은 GKE에서 PCI DSS 규정 준수를 참조하세요.
Cloud Storage
요구 사항 3.5에 따라 저장되는 기본 계정 번호(PAN)가 안전하게 보호됩니다. Google은 저장 데이터 암호화를 자동으로 제공하지만, 이 규칙에서 요구되는 단방향 해시, 잘라내기 또는 토큰화를 자동으로 수행하지 않습니다.
아키텍처 예시
이 섹션에서는 SAQ A, SAQ A-EP, SAQ D를 준수하는 환경을 구현하기 위한 접근 방법을 보여줍니다.
아키텍처 개요
SAQ A
SAQ A는 가장 기본적인 결제 처리 아키텍처입니다. 제3자에 의해 결제가 처리되고, 카드 데이터는 판매자 앱 또는 페이지에서 액세스되지 않습니다.
대략적인 결제 처리 흐름은 다음과 같습니다.
고객이 자신의 옵션을 선택하고 체크아웃을 진행합니다.
체크아웃 앱이 고객을 제3자 결제 대행업체로 리디렉션합니다.
고객이 제3자 결제 대행업체가 소유하고 유지 관리하는 결제 양식에 자신의 결제 카드 정보를 입력합니다.
제3자 결제 대행업체가 결제 카드 정보를 확인한 후 해당 카드에 비용을 부과하거나 카드를 거절합니다.
트랜잭션을 처리한 후 제3자 결제 대행업체가 트랜잭션 세부정보와 함께 고객을 다시 판매자 앱으로 보냅니다.
판매자 앱이 트랜잭션 확인을 위해 결제 대행업체에 확인 요청을 보냅니다.
결제 대행업체가 트랜잭션 세부정보를 확인하고 응답합니다.
SAQ A-EP
SAQ A-EP 결제 처리 아키텍처는 Compute Engine 가상 머신 인스턴스에서 실행되는 결제 처리 앱을 중심으로 합니다. 이러한 인스턴스는 보안 비공개 네트워크에 있으며, 보안 채널을 사용해서 네트워크 외부에 있는 서비스와 통신합니다.
대략적인 결제 처리 흐름은 다음과 같습니다.
고객이 개발자 회사에서 소유하고 유지 관리하는 결제 양식에 자신의 결제 카드 정보를 입력합니다.
고객이 자신의 정보를 제출하면 해당 양식 정보가 제3자 결제 대행업체에 안전하게 전달됩니다.
제3자 대행업체가 결제 카드 정보를 확인한 후 해당 카드에 비용을 부과하거나 카드를 거절합니다.
결제 대행업체가 개발자의 결제 앱으로 응답을 다시 보낸 후, 결제 앱이 메시지를 개발자의 핵심 앱으로 전달합니다.
이러한 모든 상호작용은 Cloud Logging 및 Cloud Monitoring을 통해 로깅되고 모니터링됩니다.
SAQ D
SAQ D 결제 처리 아키텍처는 Compute Engine 가상 머신 인스턴스에서 실행되는 결제 처리 앱을 중심으로 합니다. 이러한 인스턴스는 보안 비공개 네트워크에 있으며, 보안 채널을 사용해서 네트워크 외부에 있는 서비스와 통신합니다.
대략적인 결제 처리 흐름은 다음과 같습니다.
고객이 개발자 회사에서 소유하고 유지 관리하는 결제 양식에 자신의 결제 카드 정보를 입력합니다.
고객이 자신의 정보를 제출하면 개발자의 결제 앱이 양식 정보를 수신합니다.
결제 앱이 결제 정보를 검증하고 백엔드 API를 통해 제3자 결제 대행업체로 이를 안전하게 전달합니다.
제3자 결제 대행업체가 결제 카드 정보를 확인한 후 해당 카드에 비용을 부과하거나 카드를 거절합니다.
결제 대행업체가 개발자의 결제 앱으로 응답을 다시 보낸 후, 결제 앱이 메시지를 개발자의 핵심 앱으로 전달합니다.
이러한 모든 트랜잭션은 Logging 및 Monitoring을 통해 로깅되고 모니터링됩니다.
고객 측 결제 처리 흐름
SAQ A
이 섹션에서는 앱을 사용하는 고객의 관점에서 제3자 결제 처리 흐름을 설명합니다.
고객이 개발자의 결제 양식에 액세스할 때, 앱은 결제 대행업체가 호스팅하는 <iframe>을 제공합니다. 개발자 앱은 교차 출처 리소스 공유 제한에 따라 <iframe>의 콘텐츠에 액세스하거나 이를 모니터링할 수 없습니다.
고객이 자신의 결제 카드 정보를 제출하면 결제 대행업체가 카드를 승인하거나 거부한 다음 고객을 다시 개발자 앱으로 보냅니다. 그러면 개발자 앱은 결제 대행업체로부터 받은 트랜잭션 응답을 확인하고 이에 따라 작업을 수행합니다. 개발자 앱은 어떠한 결제 카드 정보도 액세스하거나 처리하지 않습니다.
SAQ A-EP
이 섹션에서는 앱을 사용하는 고객의 관점에서 앞에서 설명한 것과 동일한 내부 결제 처리 흐름을 설명합니다.
고객이 개발자 결제 양식의 URL에 액세스하면 사이트는 개발자 결제 앱에서 호스팅하는 양식을 표시합니다. 고객이 자신의 결제 카드 정보를 제출하면 양식이 결제 대행업체에 직접 전달됩니다. 대행업체는 카드를 승인하거나 거부한 후 고객을 다시 개발자 앱으로 보냅니다. 그러면 앱이 결제 대행업체로부터 받은 거래 응답을 확인하고 이에 따라 작업을 수행합니다. 고객이 제3자 결제 대행업체를 보지 못할 수 있지만, 개발자 앱은 서버 측에서 어떠한 결제 카드 정보도 액세스하지 않았습니다.
SAQ D
이 섹션에서는 앱을 사용하는 고객의 관점에서 내부 결제 처리 흐름을 설명합니다.
고객이 개발자의 결제 양식 URL에 액세스하면 HTTPS 부하 분산기를 통해 양식에 안전하게 라우팅됩니다. 고객이 자신의 결제 카드 정보를 제출하면 개발자의 결제 처리 앱이 이 정보를 제3자 결제 대행업체로 안전하게 전송합니다. 제3자 결제 대행업체는 카드를 승인 또는 거절한 후 개발자의 결제 처리 앱으로 응답을 반환합니다.
결제 처리 내부 흐름
SAQ A 및 A-EP
이 섹션에서는 앱을 실행하는 서버의 관점에서 결제 처리 흐름을 설명합니다.
개발자의 결제 처리 앱은 제3자 결제 대행업체가 반환한 응답을 수신하고 파싱한 다음 응답 데이터 일부 또는 전부를 핵심 앱으로 보냅니다. 이 시점에서 개발자의 결제 처리 앱은 트랜잭션이 완료됩니다. 핵심 앱은 고객 알림 작업을 처리합니다.
SAQ D
이 섹션에서는 앱을 실행하는 서버의 관점에서 내부 결제 처리 흐름을 설명합니다.
결제 처리 앱은 고객이 제출한 결제 카드 정보를 확인한 후 백엔드 API를 통해 이를 결제 대행업체로 보냅니다. 대행업체가 청구를 시도하고 트랜잭션 세부정보로 응답합니다. 개발자 앱이 응답을 수신하고 처리한 다음 응답 데이터의 일부 또는 전부를 핵심 앱으로 보냅니다. 이 시점에서 개발자의 결제 처리 앱은 트랜잭션이 완료됩니다. 핵심 앱은 고객 알림 작업 및 제품 제공 작업을 처리합니다.
모니터링 및 로깅 데이터 흐름
모니터링 및 로깅 흐름은 다음과 같이 설계됩니다.
결제 처리 환경 설정
이 섹션에서는 결제 처리 환경을 설정하는 방법을 설명합니다. 설정에는 다음이 포함됩니다.
- 프로덕션 환경에서 결제 처리 환경을 격리하기 위해 새로운 Google Cloud 계정을 만듭니다.
- 해당 환경에 대한 액세스를 제한합니다.
- 가상 리소스를 설정합니다.
- 앱 서버를 설정하기 위해 사용할 기본 Linux 이미지를 디자인합니다.
- 보안 패키지 관리 솔루션을 구현합니다.
새 계정 설정
액세스 제한 및 규정 준수 감사를 단순화하기 위해 개발자의 표준 프로덕션 환경 및 모든 개발 및 QA 환경으로부터 완전히 격리된 프로덕션 품질의 결제 처리 환경을 만듭니다(요구 사항 6.5.3). 격리를 위해 핵심 프로덕션 환경 계정과는 별도로 Google Cloud 계정을 만들고 사용합니다. ID 및 액세스 관리(IAM) 구성 경험이 있는 사용자는 범위 내 작업에 대해 별도의 프로젝트를 사용해서 동일한 격리 수준을 달성할 수 있습니다.
환경 액세스 제한
결제 시스템 코드를 배포하거나 결제 시스템 머신을 관리하는 개별 사용자에게만 결제 처리 환경 액세스 권한을 허용합니다(섹션 7.2 및 요구 사항 8.2.1). 이러한 방식을 최소 권한의 원칙이라고 부릅니다. IAM 역할을 사용해서 액세스 권한을 제한합니다. 가능한 모든 경우에 역할을 사용하고, 예상 작업을 수행하는 데 필요한 권한만 부여하고, 서비스에 대한 완전한 루트 액세스 권한이 합법적으로 요구되는 주 구성원에게만 소유자 역할을 부여하는 것이 좋습니다. 자세한 내용은 IAM 보안 가이드를 참조하세요.
모든 관리되는 서비스에 대한 자동화된 액세스에는 서비스 계정이 사용됩니다. 서비스 계정은 앱 인증 및 승인을 관리하는 방법을 제공하여 앱 관리 수명 주기를 단순화합니다. 이러한 계정은 공통 ID를 갖는 비슷한 앱 및 기능으로 가상 머신 인스턴스를 그룹화할 수 있는 유연하지만 안전한 방식을 제공합니다. IAM 역할 및 VPC 방화벽 규칙을 통해 서비스 계정 수준에서 보안 및 액세스 제어를 강화할 수 있습니다.
폴더에 적용하는 IAM 규칙은 해당 폴더에 포함된 모든 항목으로 상속됩니다. 기본 권한은 모두 거부(요구 사항 7.2.3)이며, 개발자가 적용하는 모든 규칙은 권한을 추가만 합니다.
요구사항 8.3.6에서는 사용자 비밀번호에 대한 몇 가지 기본 규칙을 제공합니다. NIST(미국 국립 표준 기술 연구소)는 NIST SP800-63B의 섹션 5.1.1에서 보안 비밀번호를 위한 보다 안전한 규칙 모음을 정의하고 있습니다. Google은 가능한 모든 경우에 NIST 디지털 ID 가이드라인을 따를 것을 권장합니다.
PCI DSS SAQ D 섹션 12.7에서는 개발자의 범위 내 환경에 대한 액세스 권한이 있는 개별 사용자에게 해당 환경에 대한 액세스 권한을 부여하기 전 지역 법률에 따라 백그라운드 검사를 시행할 것을 요구합니다. 규정 준수 위반 위험을 줄이기 위해서는 개발자의 규정 준수 유형에 관계없이 이러한 범죄 이력 조사 및 관련 조사를 수행할 것을 고려하는 것이 좋습니다.
네트워크 보안
개발자의 결제 처리 앱 네트워크에 대한 인바운드 및 아웃바운드 트래픽을 보호하기 위해서는 다음을 생성해야 합니다.
- Cloud 차세대 방화벽 정책 또는 Compute Engine 방화벽 규칙
- Cloud VPN 터널
- 외부 애플리케이션 부하 분산기
또한 VPC를 만드는 경우 추가 네트워크 보안 계층에 Cloud NAT를 권장합니다. Compute Engine 및 GKE 인스턴스의 네트워크를 보호하는 데 사용할 수 있는 여러 강력한 옵션이 있습니다.
방화벽 규칙 만들기
Cloud 차세대 방화벽 정책 또는 VPC 방화벽 규칙을 사용하여 각 Compute Engine 인스턴스에 대한 인바운드 트래픽을 제한합니다(요구사항 1.3 및 1.4). 다음 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 터널 설정
Cloud VPN을 사용하여 온프레미스 환경과 개발자의 결제 처리 환경 간에 보안 VPN 터널을 설정할 수 있습니다(섹션 2.2.7 및 4.2).
외부 애플리케이션 부하 분산기 만들기
외부 애플리케이션 부하 분산기를 만들면 들어오는 고객 트래픽이 안전한지 확인하는 데 도움이 될 수 있습니다(섹션 2.2.7 및 4.2). 외부 애플리케이션 부하 분산기를 만들려면 다음이 필요합니다.
- 결제 처리 양식에 사용되는 웹 사이트의 하위 도메인(예:
payments.your-domain-name.com) - 하위 도메인에 대해 등록된 유효하고 서명된 SSL 인증서
웹 등록기관 도메인 구성 인터페이스에서 해당 DNS 설정을 확인하여 도메인이 유효한지 확인하세요.
기본 Linux 이미지 만들기
PCI DSS에는 호환되는 결제 처리 아키텍처에 속하는 머신을 설정하는 방법을 설명하는 요구 사항이 포함되어 있습니다. 이러한 요구사항은 여러 방법으로 구현할 수 있지만, 가장 쉬운 방법은 다음과 같습니다.
개발자의 결제 대행 앱의 범위 내에 있는 각 서버에 설치해야 하는 소프트웨어 및 라이브러리 목록을 만듭니다. 시스템에 불필요한 취약점이 발생하지 않도록 하려면 앱을 실행하는 데 필요한 최소한의 소프트웨어와 라이브러리만 포함합니다(요구사항 2.2.4). 후보에는 Google Cloud CLI, 언어별 런타임 및 라이브러리 또는 웹 서버가 포함될 수 있습니다.
Compute Engine 사전 구성된 운영체제 이미지 중 하나를 사용하는 Compute Engine 인스턴스를 만듭니다.
위에서 개발자가 목록으로 작성한 라이브러리 및 소프트웨어를 설치합니다.
ntp를 설치하고 구성하여 시스템 시계를 동기화된 상태로 유지합니다. 서버 시계를 NTP(네트워크 시간 프로토콜)로 관리하면 로그에 포함된 시간 기록의 무결성을 보장할 수 있습니다(섹션 10.6).이미지가 안전한 Compute Engine 이미지를 만들기 위한 권장사항을 따르는지 확인합니다(섹션 2.2 전체).
기본 이미지를 구성한 후 이미지에서 커스텀 Compute Engine 디스크 이미지를 만듭니다. 이 이미지는 가상 머신 인스턴스를 만들 때 기본 Linux 이미지로 사용할 수 있습니다.
보안 패키지 관리 사용
패키지 관리는 보안이 강화된 호스팅 환경의 핵심 구성요소입니다. 섹션 2.2에 따라 업계에서 허용되는 강화 표준을 구현해야 합니다. Google의 Container-Optimized OS를 사용하지 않는 한 RPM, Yum 또는 Apt와 같은 패키지 관리자가 설치되었을 수 있습니다. 개발자 앱은 NPM, PyPi 또는 Composer와 같은 고유 프로그래밍 언어별 패키지 관리자를 사용할 수 있으며, 처음 실행할 때 종속 항목을 다운로드할 수 있습니다.
앱이 인터넷에서 업데이트를 가져올 수 있는 경우, 업데이트 소스를 잠재적인 보안 위험 요소로 취급해야 합니다. 공개적으로 호스팅되는 패키지에 악의적으로 포함된 공급 측 또는 업스트림 공격이 점점 더 일반화되고 있습니다. 악의적인 코드가 포함된 업데이트를 SSH에 설치했을 때의 결과를 상상해보세요.
패키지에 대한 안전 수신자 목록을 만들고 해당 패키지가 목록과 일치하는지 확인하면 공급 측 공격 위험을 줄일 수 있습니다. 사용되는 각 패키지에 대해서는 테스트 및 승인된 버전 번호 목록을 유지합니다. 해당 해시 또는 서명과 함께 버전 번호를 기록해두세요. 앱을 설치하거나 업데이트할 때는 먼저 패키지 관리자가 해시 또는 서명을 검증했는지 확인해야 합니다.
대부분의 패키지 관리 시스템에서는 비공개 호스팅이 허용됩니다. 가능한 경우에는 개발자의 고유 비공개 패키지 관리 서버를 시작하고 테스트 및 승인된 소프트웨어만 호스팅해야 합니다. 패키지 관리자는 업데이트를 받기 위해 다른 서버에 연결할 수 없도록 잠금을 설정해야 합니다.
이상적으로, 앱 빌드 프로세스는 모든 패키지를 가져오고 검증한 후 컨테이너에 필요한 모든 것이 포함된 커스텀 디스크 이미지 버전을 만듭니다. 이렇게 하면 설치 프로그램 지연 없이 시작 및 확장될 수 있으며, 출시 시에 임의의 오류가 발생할 가능성이 줄어듭니다. 또한 해당 이미지를 시작하여 프로덕션 상태와 동일하게 앱의 이전 버전을 다시 방문하면 진단과 포렌식에 유용하게 활용할 수 있습니다.
배포 및 구성
이제는 기본 이미지로부터 인스턴스 배포 및 구성을 설정합니다.
환경 배포
PCI DSS 요구 사항을 충족하기 위해서는 매번 올바른 앱을 배포하는지, 앱을 안전하게 배포하는지, 배포 중 다른 소프트웨어 패키지를 설치하지는 않는지 확인해야 합니다. 배포 프로세스를 단순화하기 위해 Terraform을 사용하여 앱 배포를 자동화하는 것에 대하여 고려해 보세요. Terraform을 사용하면 방화벽 규칙, 게이트웨이, 부하 분산기, 코드 내 인스턴스 등 전체 결제 처리 환경을 설명할 수 있습니다.
자동화된 배포에서는 배포 중인 소프트웨어의 무결성(타사 소프트웨어 또는 자체 개발 소프트웨어인지 여부)을 확인해야 합니다. 패키지가 설치될 때 각 패키지에 대해 자동화된 해시를 실행하여 소프트웨어를 확인할 수 있습니다. 해시가 확인된 후에는 자동화된 테스트 프레임워크를 사용해서 보안 및 다른 테스트를 실행하고, 테스트가 통과했는지 확인할 수 있습니다.
마지막으로 Compute Engine 인스턴스를 배포할 때 인스턴스가 실패할 경우의 복구 계획을 디자인합니다. 허용 가능한 다운타임 기간이 충분히 길면 수동 복구 계획으로도 충분할 수 있지만, 그렇지 않으면 자동화된 복구 계획을 디자인해야 합니다. 자세한 내용은 재해 복구 계획 가이드, 강력한 시스템 설계, 확장 가능하고 복원력이 우수한 웹 앱 빌드를 참조하세요.
환경 구성
인스턴스가 배포된 다음에는 올바르게 구성되었는지 확인합니다. 필요에 따라 각 인스턴스 기본 이미지 위에 추가 소프트웨어 및 라이브러리를 설치합니다. 수동 구성의 복잡성, 오버헤드, 전반적인 위험을 방지하기 위해 Skaffold, Chef, Puppet, Ansible 또는 Salt와 같은 자동화된 구성 관리 도구를 사용합니다.
변경할 수 없는 감사 로깅 구현
Logging은 여러 제품 간의 다양한 활동에 대해 감사 로그를 자동으로 생성합니다. 장기적으로 Cloud Storage 버킷 잠금(섹션 10.3)을 사용해서 변경할 수 없는 로그를 안전하게 저장할 수 있습니다. 버킷 잠금을 사용하면 몇 초에서 몇 년까지 지정한 기간 동안 모든 객체가 변경 및 삭제될 수 없도록 지정하는 정책을 설정할 수 있습니다.
Virtual Private Cloud 흐름 로그 구현
VPC 흐름 로그 서비스는 가상 머신 인스턴스에서 전송 또는 수신되는 네트워크 흐름을 기록하도록 디자인되었습니다. 이러한 로그는 네트워크 모니터링, 포렌식, 실시간 보안 분석(섹션 10.2)에 사용할 수 있습니다.
Logging 에이전트 설치
서버에 iptables를 설정한 후 각 서버는 서버의 블록 스토리지에 대한 모든 활동을 로깅합니다. 무료 할당량 및 데이터 전송 가격에 대한 세부정보는 Logging 가격 책정 페이지를 확인하세요. 이러한 로그를 보존하고 의심스러운 활동을 기준으로 알림을 생성하려면 각 서버에 Logging 에이전트를 설치하여 Logging 및 Monitoring에 이를 스트리밍합니다(섹션 10.3).
침입 감지 시스템 통합
섹션 11.5에 설명된 결제 대행 환경의 보안을 보장하기 위해서는 잘못된 행위자가 시스템을 공격하려고 시도할 때 이를 알 수 있도록 IDS(침입 감지 시스템)를 사용합니다. 결제 처리 환경에 IDS를 배치하는 두 가지 방법은 모든 진입점에 IDS를 배치하는 방법과 모든 서버에 IDS를 설치하는 방법입니다.
환경 아키텍처의 복잡성을 줄이고 11.5를 간단하게 준수하기 위해서는 각 서버에 IDS를 설치합니다. 사용할 IDS 소프트웨어를 연구하고 선택한 후에는 각 서버의 설치 시작 스크립트에 IDS 설치를 포함합니다.
침입 감지 서비스인 Cloud Intrusion Detection System(Cloud IDS)은 네트워크에 대한 침입, 멀웨어, 스파이웨어, 명령 및 제어 공격과 관련된 위협 감지를 제공합니다. Cloud IDS에서는 North-South 트래픽과 East-West 트래픽을 모두 포함해 네트워크 트래픽을 완전히 파악할 수 있으므로 VM 간 통신을 모니터링하여 측면 이동을 감지할 수 있습니다. 또한 Cloud IDS를 사용하여 요구사항 11.5를 간단하게 준수할 수 있습니다.
IDS 로그는 PCI DSS 규정 준수 범위에 포함되며, 보고, 알림, 감사를 위해 Logging 및 Monitoring에 전송해야 합니다.
Security Command Center 구현
Security Command Center는 보안팀이 비즈니스 손상 또는 손실을 입기 전에 데이터를 수집하고, 위협을 식별하고, 위협에 대응할 수 있도록 도와줍니다. 클라우드 리소스에 대한 위협을 빠르게 완화하고 전체 상태를 평가할 수 있도록 앱 및 데이터를 자세히 확인할 수 있습니다. Security Command Center는 클라우드 애셋 인벤토리를 조회 및 모니터링하고, 스토리지 시스템에서 민감한 정보를 검색하고, 일반적인 웹 취약점을 감지하고, 중요 리소스에 대한 액세스 권한을 검토할 수 있는 중앙화된 단일 대시보드를 제공합니다. 섹션 5 및 6.4를 포함한 여러 요구 사항을 준수할 수 있습니다.
앱 배포 자동화
구성 관리 도구를 빌드하여 앱의 최신 버전을 안전하게 검색하고 실행합니다. 위치가 안전하다면 앱을 Cloud Storage와 같은 모든 위치에서 검색할 수 있습니다.
앞에서 언급한 많은 구성 관리 도구에서 CI/CD(지속적 통합 및 배포) 워크플로가 지원됩니다. 이를 사용하면 자동화된 스캔(섹션 11.3)을 수행하고 코드가 검토되도록 보장할 수도 있습니다(요구사항 6.2.3).
구성 관리자 로그 캡처
구성 관리자를 설정할 때는 모든 설치 세부정보가 로깅되는지 확인합니다. 구성 프로세스를 완료한 후에는 Logging 및 Monitoring으로 로그가 제공되는지 확인합니다.
로깅 및 모니터링
섹션 10 아래의 PCI DSS 규정 준수를 확인하기 위해서는 결제 처리 환경에서 수행되는 모든 단계가 모니터링되고 기록되는지 확인해야 합니다. 모든 인스턴스의 서버 활동을 로깅하고, 모든 사용자 작업을 나중에 조사할 수 있어야 합니다.
액세스 투명성 사용 설정
액세스 투명성을 통해 이제 Logging에서 Google Cloud 관리자가 콘텐츠에 액세스할 때 거의 실시간 수준의 로그를 제공합니다. Cloud 감사 로그를 통해서도 관리자의 행동을 파악할 수 있습니다. 하지만 이 감사 추적은 대개 클라우드 공급자의 지원 또는 엔지니어링 팀이 개입한 작업은 제외합니다. 예를 들어 액세스 승인 로깅을 사용하기 전에는 Google 지원에서 데이터 액세스가 필요한 티켓을 개설하더라도 이러한 활동이 Cloud 감사 로그에서 추적되지 않았습니다. 액세스 승인은 이 문제를 해결해 지원 또는 엔지니어링 담당자의 타겟팅된 수동 액세스에 대해 실시간에 가까운 로그를 포착합니다.
액세스 승인을 사용하면 데이터에 대한 액세스를 명시적으로 승인하거나 그러한 액세스가 발생하기 전 Google Cloud에 대한 구성을 명시적으로 승인할 수 있습니다. 액세스 승인은 Google 지원 및 엔지니어링팀의 액세스에 대한 통계도 제공합니다.
방화벽 규칙 로깅 사용
방화벽 규칙 로깅을 사용하면 개별 규칙 수준에서 로깅을 사용 설정할 수 있습니다. 개발자가 직접 만든 규칙에 해당하는 VPC 내 TCP 및 UDP 연결을 기록할 수 있습니다. 이는 네트워크 액세스를 감사하거나 네트워크가 승인되지 않은 방식으로 사용되고 있음을 미리 경고하는 데 유용할 수 있습니다.
VPC 서비스 제어 사용
VPC 서비스 제어를 사용하면 Cloud Storage 버킷, Bigtable 인스턴스, BigQuery 데이터세트와 같은 Google Cloud 리소스 주위에 보안 경계를 정의하여 VPC 네트워크의 데이터를 통제하고 데이터 무단 반출 위험을 완화할 수 있습니다(요구사항 1.3.1 및 1.3.2). VPC 서비스 제어를 통해 Google Cloud의 완전 관리형 스토리지와 데이터 처리 기능을 활용하면서도 민감한 정보는 비공개로 유지할 수 있습니다.
VPC 흐름 로그 설정
VPC 흐름 로그는 VM 인스턴스에서 전송 또는 수신되는 네트워크 트래픽 흐름을 기록합니다. 이 로그는 PCI DSS에서 모니터링, 감사, 포렌식, 실시간 보안 분석을 수행하는 데 유용합니다. 각 VPC 네트워크 서브넷에는 흐름 로그를 개별적으로 사용 설정하거나 중지할 수 있습니다. 범위 내 CDE에서 흐름 로그를 사용 설정만 하면 로그 데이터 양을 최소화할 수 있습니다. 이그레스 방화벽 규칙과 함께 흐름 로그를 사용하면 감사를 수행할 수 있고 우회하기 어려운 방식으로 아웃바운드 트래픽을 승인된 엔드포인트로 제한할 수 있습니다(요구 사항 1.2.1 및 1.3.4).
다음 다이어그램은 VPC 흐름 로그가 VM 인스턴스에서 전송되거나 수신되는 네트워크 트래픽 흐름을 기록하는 방법을 보여줍니다.
개별 HTTP 요청 로깅과 같이 흐름 로그가 제공할 수 있는 것보다 자세한 데이터가 필요한 경우 앱 또는 프록시 아웃바운드 요청에서 제어 기능을 구현할 수 있습니다. 이 작업은 액세스 로그를 Logging으로 전달하도록 구성된 개발자 고유의 역방향 프록시 서버를 통해 수행할 수 있습니다. Compute Engine에서 Squid 프록시 서버를 설정하는 방법에 대한 안내는 네트워크 프록시 설정을 참조하세요. 병목 현상을 방지하기 위해서는 최소한 2개 이상의 중복된 프록시 서버를 설정합니다.
내부 액세스 데이터 로깅
외부 위협을 로깅하는 것 외에도, 결제 처리 환경에 대해 관리자 권한이 있는 개별 사용자의 활동도 모니터링하고 로깅합니다(섹션 10.2). 이를 이해서는 셸 명령어를 로깅할 수 있습니다. 일부 오픈소스 도구는 셸 명령어를 감사하고 이를 로깅으로 전송할 수 있습니다. 이 태스크에는 일반적으로 OSSEC 또는 Tripwire가 사용됩니다.
Monitoring 알림 설정
결제 처리 환경에서 문제가 발생할 경우 알림을 전송하도록 Monitoring을 구성합니다(섹션 10.6). 알림에 환경, 감사, 내부 앱 이벤트가 포함되는지 확인합니다. 결제 처리 앱의 각 구성요소에 대한 잠재적인 위험 또는 공격 벡터를 기준으로 알림 전략을 만듭니다. 예를 들어 성공 여부에 관계없이 침입 시도가 IDS에서 감지된 경우 Monitoring 알림을 트리거합니다. 방화벽 규칙 로깅을 사용하여 특정 네트워크 정책 위반 시도에 따라 알림을 트리거할 수 있습니다.
BigQuery에 로그 스트리밍
선택적으로 나중에 분석할 수 있도록 Logging 로그를 BigQuery로 라우팅할 수 있습니다. 자세한 내용은 라우팅 및 스토리지 개요: 싱크를 참조하세요. BigQuery는 큰 데이터 세트를 쿼리하도록 최적화되었기 때문에 대규모 로그 분석에 이상적인 도구입니다. Logging은 거의 실시간 분석이 필요한 로그도 BigQuery에 직접 로깅할 수 있습니다(요구사항 10.4.1).
Sensitive Data Protection을 사용한 데이터 삭제
분석 또는 개발 목적과 같이 범위 내에 자체적으로 포함되지 않았지만 범위 내 앱에 포함된 데이터의 일부를 사용해야 할 경우가 많습니다. Sensitive Data Protection을 사용하여 기밀 데이터가 삭제된 후에만 PCI 데이터에 대한 액세스 권한을 앱에 부여합니다(요구사항 6.5.1).
앱 보안
앱 보안을 위해서는 먼저 관리자 인터페이스를 평가해야 합니다. 또한 Cloud Key Management Service를 사용할 수도 있습니다.
관리자 인터페이스 평가
대부분의 전자 상거래 앱에는 고객 서비스 청구 포털과 같은 콘솔 이외의 관리자 인터페이스가 포함되어 있습니다. 이러한 도구는 강력한 액세스 제어 기능이 포함되어야 하며, 다중 요소 인증(섹션 8.4)을 사용하는 개별화된 액세스 권한을 포함하고, 감사 로깅을 사용해서 구현되어야 합니다(섹션 10.2).
개발자가 생성하는 모든 로그는 다음과 같은 질문에 답변할 수 있어야 합니다. 누가 무엇을 했는가? 작업을 수행한 위치는 어디인가? 작업 수행 시간은 언제인가? 섹션 2.2.7에 따라 이러한 도구에 대한 모든 액세스는 강력한 전송 암호화를 사용해야 합니다. 민감한 정보를 관리자 도구에 표시하기 전에 Sensitive Data Protection를 사용하여 이를 필터링합니다.
Cloud Key Management Service(Cloud KMS) 사용
Cloud KMS는 암호화 키를 관리할 수 있는 서비스입니다. AES-256, RSA 2048, RSA 3072, RSA 4096, EC P256, EC P384 암호화 키를 생성, 사용, 순환, 폐기할 수 있습니다. Cloud KMS를 사용하면 코드 또는 구성 파일에 저장된 일반 텍스트 비밀번호를 삭제하여 섹션 2.2.2, 3.6, 3.7, 8.2의 규정 준수를 간소화할 수 있습니다.
환경 검증
환경이 구현된 후에는 프로덕션 트래픽이 통과되기 전에 환경을 검증해야 합니다.
- Level 1 판매자인 경우에는 QSA(공인 보안 감정평가사)가 해당 환경을 검증해야 합니다. QSA는 PCI 보안 표준 위원회에서 PCI 환경을 검증하고 승인 표시를 제공하도록 승인된 회사 또는 개인입니다.
- Level 2 판매자 이하인 경우에는 자체 평가 질문을 작성하여 해당 환경을 검증할 수 있습니다.
다음 단계
- PCI DSS 문서 라이브러리
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기