MongoDB Atlas 로 PCI DSS 채택 가속화

PCI DSS의 모습과 계층 분할 위치

PCI 보안 표준 협의회는 PCI DSS를 유지 관리하고 제어 목표 아래에 그룹화된 요구 사항 설정하다 를 구성합니다.

공유 책임 모델에서는 이러한 요구 사항이 이러한 계층으로 분할 .

• 인프라 계층(제공자 책임): 물리적 보안, 네트워크 제어, 플랫폼 패치 및 기본 저장 의 미사용 데이터 암호화 로 구성됩니다. MongoDB Cloud는 PCI DSS 인증 서비스 제공자 이며,QSA인 Coalfire Systems의 검증을 받았습니다. MongoDB Cloud의 CHD 환경의 경우, QSA는 MongoDB 보안 센터 통해 요청 시 제공되는 MongoDB Cloud AOC를 사용할 수 있습니다. 이 사전 검증된 계층은 고객이 기본 인프라를 다시 감사할 필요가 없습니다.

• 애플리케이션 계층(고객의 책임): 제품이 CHD를 저장, 보호, 쿼리, 마스킹 및 감사하는 방법과 정보를 읽을 수 있는 사용자로 구성됩니다. 이 계층은 고객의 설계 결정으로 남아 있습니다.

그림 1. PCI DSS 분담 계층 모델

클릭하여 확대

PSP 프로젝트 애플리케이션 계층을 채웁니다. 이는 참조 아키텍처와 설정하다 의 권장사항 으로 구성됩니다. MongoDB 사용하여 애플리케이션 계층을 저장된 데이터를 보호하고, 액세스 제한하고, 데이터를 모니터링 , 감사 범위를 줄이기 위한 PCI DSS 제어 목표에 맞추는 방법을 보여줍니다. 이 프로젝트 PCI DSS 채택을 가속화하기 위한 점 됩니다.

아키텍처 제안

PSP 프로젝트 PCI DSS에 부합하는 PSP 플랫폼입니다. MongoDB Atlas 의 결제 라이프사이클(카드 결제 및 권한 부여, 자동 사기 점수 산정, 다중 계층 분석가 조사)을 실행합니다. 분석가가 명확한 설계 철학을 가지고 암호화됨 데이터를 검색 할 수 있는 방법을 보여줍니다.

모든 것을 암호화합니다. 무엇이든 쿼리하세요. 키는 사용자의 것입니다.

Atlas 에서 상속된 인프라 계층(그림 1 참조)을 사용하면 나머지 작업은 애플리케이션 계층에서 이루어집니다. Atlas 이 작업을 지원 위해 Queryable Encryption 중심으로 다양한 기능을 제공합니다. 전체 기능 설정하다 는 MongoDB 기능 섹션에 나열되어 있습니다.

Queryable Encryption 에 중점을 둡니다.

기존의 접근 방식에서는 필드 일반 텍스트로 유지하여 검색할 수 있도록 하거나( 데이터베이스 액세스 있는 모든 사람이 읽을 수 있음), 보호되도록 암호화됨 (더 이상 검색할 수 없음) 보호합니다. Queryable Encryption 지원하는 쿼리 유형에 대해 해당 중 하나를 제거합니다.

그림 2. MongoDB 암호화 아키텍처: Queryable Encryption, 키 관리 및 데이터 보호 계층

클릭하여 확대

동등성 검색 가능 필드 의 경우 흐름은 다음과 같이 진행됩니다.

• 운전자 필드의 DEK를 사용하여 클라이언트 사이드에서 검색 값을 암호화합니다.

• 서버 해당 암호화됨 값을 암호화됨 인덱스 와 일치시킵니다. 암호문을 암호문과 비교하고 필드 를 해독하지 않습니다.

• 일치하는 문서가 애플리케이션 프로세스 로 반환되면 운전자 메모리의 대상 필드를 해독합니다. MongoDB Atlas BSON 바이너리 하위 유형 06로 보관되는 암호 텍스트만 저장하고 처리합니다. 결과적으로 전체 클러스터 액세스 가진 데이터베이스 관리자는 불투명 바이트만 볼 수 있습니다.

PSP 프로젝트 의 구체적인 효과는 사기 분석가 암호화됨 이메일, 전화 또는 계정 참조를 통해 고객을 검색하고 기록 다시 가져오는 반면 일반 텍스트 값은 Atlas 도달하지 않는다는 것입니다. 이 역량 CDE를 확장하는 대량 암호 해독 없이 민감한 PII를 미사용 상태로 암호화됨 값에 따라 사용할 수 있도록 유지합니다.

보호는 필요하지만 검색 필요하지 않은 필드는 검색 불가 모드 사용하며, 승인되고 에스컬레이션된 요청 에 대해서만 해독됩니다. 데이터 모델 섹션에서는 모드와 해당 모드가 보호하는 필드를 모두 다룹니다.

애플리케이션 계층을 위한 MongoDB 기능

PSP 프로젝트 여러 MongoDB 와 Atlas 기능을 결합합니다. 각각은 PCI DSS 애플리케이션 계층 작업의 특정 부분에 매핑됩니다.

인접 사용 사례

안정적인 API 경계, 필드 수준 Queryable Encryption 및 액세스 계층별 DEK 모델을 포함한 이 솔루션의 핵심 원칙은 다른 사용 사례에 적용될 수 있습니다.

• 개방형 금융: 고객이 승인한 필드(예: PSD2 및 소비자 데이터 권한)로 제3자를 제한하는 동의 범위의 데이터 액세스 .

• 의료: HIPAA에 따라 보호되는 건강 정보입니다.

• 보험 및 자산: GDPR 에 따라 정부 식별자 및 금융 계정 데이터를 처리하는 플랫폼입니다.

아키텍처 구성 요소

이 아키텍처는 다음 구성 요소를 사용합니다:

• PSP 대시보드 (프론트엔드): 프레젠테이션 계층. 데이터베이스 와 직접 통신하지 않습니다. 체크아웃 시 PAN을 토큰화하여 전체 PAN이 PSP 코어에 의해 전송되거나 저장되지 않도록 합니다.

• PSP API 게이트웨이(백엔드): 단일 진입 점 이자 보호된 필드를 해독할 수 있는 유일한 구성 요소입니다. Queryable Encryption 클라이언트 보유하고 호출자의 역할 해결하며 요청 에 따라 올바른 키 계층 선택합니다. 사용자 인터페이스, 서비스 계정 및 통합을 포함한 모든 호출자는 동일한 API 통과하며 동일한 RBAC 및 키 규칙의 적용을 받습니다.

• Queryable Encryption 사용하는 MongoDB Atlas (M 이상):10 06모든 보호 필드 에 대해 암호 텍스트(이진 하위 유형)만 저장합니다. 전체 클러스터 액세스 있는 데이터베이스 관리자는 불투명 바이트를 볼 수 있습니다. TLS 은 1.3 전송 중인 모든 데이터를 보호합니다. PSP 프로젝트 프로덕션에서 지원되는 동등성 검색 에 의존합니다.

• AWS KMS : 데이터 암호화 키를 래핑하고 래핑 해제하는 CMK 보유합니다. CMK KMS 에 유지되며 MongoDB 이에 액세스 할 수 없습니다. 로컬 키 제공자 데모의 오프라인 대체 수단으로 사용할 수 있습니다.

쿼리 유형 및 프로젝트 적용 방법

MongoDB Queryable Encryption 서버 암호 텍스트를 쿼리 수 있도록 하면서 필드 클라이언트 사이드 암호화됨 유지합니다. PSP 프로젝트 다음과 같은 쿼리 유형을 사용합니다.

• 동등성(프로덕션): PCI DSS 범위 조회 키에 대한 검색 가능 모드 입니다. 운전자 쿼리 값을 암호화하고 암호화됨 인덱스 와 비교하여 서버 필드 를 해독하지 않도록 합니다. 이 기능 사용하면 사기 분석가 일반 텍스트를 노출하지 않고도 이메일 , 전화 또는 계정 참조를 통해 기록 찾을 수 있습니다.

• 쿼리 없음(검색 전용): 거주지 주소, 정부 식별자 및 원시 게이트웨이 페이로드를 포함하여 가장 민감한 필드에 대한 검색 불가능 모드 입니다. 권한이 부여된 클라이언트 이러한 필드를 JIT(Just-In-Time)로만 해독합니다.

• 범위(프로덕션): 금액 범위 별 필터링과 같은 값 밴드 조회에 사용됩니다. 금액을 암호화됨 로 유지합니다.

• 접두사, 접미사 및 하위 문자열(공개 미리 보기): 암호화됨 ID 필드에 대한 KYC 스타일 부분 일치 조회에 대해 시연되었습니다.

아래 PCI DSS 범위 카드 및 PII 필드의 경우 액세스 설계는 다음 범주로 축소됩니다.

가능한 경우 카드 소지자 데이터를 범위에서 벗어나는 디자인 선택은 다음과 같습니다.

• PAN 토큰화: 애플리케이션 전체 PAN을 대리 tok_<uuid> 토큰으로 대체하고 표시 목적으로 마지막 4자리만 유지합니다.

• 제로 SAD 캡처: 엔드포인트는 CVV 또는 핀과 같은 SAD를 캡처하지 않습니다.

세분화 및 토큰화를 통한 범위 축소

일반적인 PCI DSS 관행은 카드 소지자 데이터가 필요하지 않은 시스템에 카드 소지자 데이터를 보관하지 않으므로 대부분의 플랫폼이 CDE에 속하지 않습니다. 이러한 기술은 CDE를 시스템의 나머지 부분과 격리하는 세분화와 프라이머리 계정 번호를 전용 토큰화 볼트에 보관된 대리 토큰으로 대체하는 토큰화 적용 . 세분화는 PCI DSS 요구 사항은 아니지만 시스템을 범위에서 벗어나게 하고 평가 비용 절감합니다. 사용하는 경우 문서화하고, 정당화하고, 유효성을 검사해야 합니다.

PSP 프로젝트 이러한 기술을 데이터 계층에 적용합니다.

• 전체 PAN은 PSP 코어에 상주하지 않습니다: 코어는 서로게이트 토큰,BIN 및 마지막 4자리만 저장합니다. 대부분의 플랫폼은 카드 소지자 데이터를 전달하지 않으며 범위를 벗어납니다. 전체 PAN은 프로덕션 외부에 있는 카드 발급사 하위 시스템에 속합니다. 데모에서는 교체 가능한 내장 발급자 모듈이 역할을 하며 PAN을 QE:equality로 암호화됨 격리된 자체 볼트에 저장합니다. 이 필드 해독하지 않고도 정확한 조회 및 중복 감지를 위해 일치시킬 수 있습니다.

• PII는 중앙 집중식입니다: 이메일 또는 전화와 같은 ID13 필드는 계약, 카드 및 트랜잭션 기록을 참조하는 단일 BIAN SD- 당사자 컬렉션 에 있습니다. 데이터 주체 삭제 요청 한 곳에서 보호하고 프로세스 .

• 민감한 필드는 별도의 키 계층 뒤에 있습니다. QE:none 필드는 검색 가능한 QE:equality 필드와 다른 데이터 암호화 키 계층 사용하므로 민감한 데이터와 민감하지 않은 데이터 간의 경계는 키에 의해 적용됩니다.

이는 인증이 아닌 참조 패턴 입니다. CDE 정의와 해당 유효성 검사 여전히 고객의 책임이며 평가자는 확인해야 합니다.

애플리케이션 코드가 아닌 액세스 제어 적용 키

암호화 계층을 DEK 백으로 분리합니다.

• 조회 계층: QE:equality 인증된 모든 분석가 역할이 검색 위해 키를 사용할 수 있습니다.

• 민감한 계층: QE:none 키는 유효하고 수명이 짧은 에스컬레이션 토큰을 보유한 레벨 2 조사자와 읽기 전용 보안 감사자만 사용할 수 있습니다.

• 디자인 핵심: 레벨 1 클라이언트의 암호화된 필드 맵에서 민감한 키를 생략하므로 운전자 해당 필드를 해독할 수 없고 암호 텍스트로 반환합니다. 여기서 필드 수준 액세스 제어는 애플리케이션 코드의 프로젝션 아닌 암호화이므로 쿼리 버그를 통해 우발적인 유출 위험을 줄입니다. 분석가 사례를 에스컬레이션하고 레벨 2 조사관이 승인하면 조사관은 해당 요청 에 대해 민감한 계층 클라이언트 풀을 활성화하는 에스컬레이션 토큰을 받습니다.