사실 카드 소유자 데이터를 다루면 PCI DSS v4.0.1은 선택사항이 아닙니다. PCI DSS v4.0.1은 한 가지 요구사항으로 귀결됩니다: 다른 모든 것으로부터의 인프라 수준 격리입니다.
참고: PCI Security Standards Council
요구사항 매핑
| PCI DSS 요구사항 | 설명 | Rediacc 기능 |
|---|---|---|
| 요구사항 1, 네트워크 보안 제어 | 네트워크 보안 제어 설치 및 유지 | 저장소별 iptables 규칙이 모든 교차 저장소 트래픽을 차단합니다. 각 저장소는 자체 루프백 IP 서브넷(/26)을 갖습니다. |
| 요구사항 2, 보안 구성 | 모든 시스템 구성요소에 보안 구성 적용 | Rediaccfile 라이프사이클 훅이 결정론적이고 재현 가능한 구성을 강제합니다. 기본 자격증명 없음. LUKS 키는 운영자가 생성합니다. |
| 요구사항 3, 저장된 계정 데이터 보호 | 암호화를 통한 저장 계정 데이터 보호 | 모든 저장소 볼륨에 LUKS2 AES-256 암호화 적용. 암호화는 선택이 아닌 필수입니다. LUKS 키 파기를 통한 암호화적 삭제 지원. |
| 요구사항 4, 전송 중 데이터 보호 | 전송 중 카드 소유자 데이터를 강력한 암호화로 보호 | 모든 원격 작업은 SSH를 통해 이루어집니다. 백업 전송은 종단간 암호화됩니다. 비암호화 데이터 경로 없음. |
| 요구사항 6, 보안 개발 | 보안 시스템 및 소프트웨어 개발 및 유지 | CoW 클로닝으로 프로덕션 카드 소유자 데이터를 개발 네트워크에 노출하지 않고 격리된 테스트 환경을 생성합니다. 포크-테스트-승격 워크플로우. |
| 요구사항 7, 접근 제한 | 비즈니스 필요에 따른 시스템 구성요소 및 카드 소유자 데이터 접근 제한 | 저장소별 Docker 데몬 소켓. 한 저장소에 대한 접근이 다른 저장소에 대한 접근을 부여하지 않습니다. SSH 키 기반 인증. |
| 요구사항 8, 사용자 식별 및 인증 | 사용자 식별 및 시스템 구성요소 접근 인증 | SSH 키 인증. IP 바인딩 및 범위 지정 권한이 있는 API 토큰. 2단계 인증(TOTP). |
| 요구사항 9, 물리적 접근 제한 | 카드 소유자 데이터에 대한 물리적 접근 제한 | 자체 호스팅: 물리적 보안은 직접 관리 하에 있습니다. LUKS 암호화로 도난된 드라이브를 판독 불가 상태로 만듭니다. |
| 요구사항 10, 로깅 및 모니터링 | 시스템 구성요소 및 카드 소유자 데이터에 대한 모든 접근 로깅 및 모니터링 | 70개 이상의 이벤트 유형(인증, API 토큰, 설정, 라이선스, 머신 작업). 사용자, 팀, 유형, 날짜별 필터링이 가능한 관리자 대시보드 및 포털. 프로그래매틱 내보내기를 위한 rdc audit CLI. 머신 작업도 심층 방어를 위해 시스템 로그에 기록됩니다. |
| 요구사항 12, 조직 정책 | 조직 정책 및 프로그램으로 정보 보안 지원 | 자체 호스팅으로 제3자 프로세서 범위 제거(요구사항 12.8). PCI DSS 준수 경계 축소. |
네트워크 분리
PCI DSS는 분리를 강하게 요구합니다. 실무에서 부족한 격리 위에 iptables 규칙을 겹겹이 쌓는 팀들을 많이 봅니다. 이 방법은 작동하지 않습니다. 감사를 통과하는 팀들은 분리가 아키텍처에 내장되어 있습니다. Rediacc는 기본적으로 이를 제공합니다:
- 각 저장소는
/var/run/rediacc/docker-<networkId>.sock에서 자체 Docker 데몬으로 실행됩니다 - 저장소는 격리된 루프백 IP 서브넷을 갖습니다(127.0.x.x/26, 네트워크당 61개의 사용 가능한 IP)
- renet이 적용하는 iptables 규칙이 모든 교차 데몬 트래픽을 차단합니다
- 서로 다른 저장소의 컨테이너는 네트워크 수준에서 통신할 수 없습니다
결제 처리 저장소는 자체 Docker 데몬과 자체 루프백 서브넷에서 실행되며, 같은 머신의 다른 모든 애플리케이션과 네트워크 수준에서 격리됩니다. 추가 방화벽 규칙을 작성할 필요가 없습니다.
범위 축소
자체 호스팅 Rediacc는 준수 범위를 축소합니다. 네트워크 분리를 수동으로 구성할 필요가 없습니다. 이는 설계상 자동입니다. 이 부분의 문서화는 아직 개선되어야 하지만, 격리는 견고합니다.
- 카드 소유자 데이터 흐름에 제3자 클라우드 제공업체 없음
- 요구사항 12.8(제3자 서비스 제공업체)에 따라 평가할 SaaS 벤더 없음
- 물리적 보안 제어는 직접 관리 하에 있음
- 암호화 키는 운영자의 로컬 구성에만 저장됨
제재 사례
대부분의 PCI 감사 실패는 두 가지 중 하나로 귀결됩니다: 제대로 격리되지 않은 분리 또는 실제 공격에 대해 테스트되지 않은 암호화입니다.
- Heartland Payment Systems(2008년): 공격자가 부실한 네트워크 분리로 인해 48개 데이터베이스에 걸쳐 측면 이동하여 1억 3천만 개의 카드 번호를 노출했습니다. 총 비용은 2억 달러를 초과했습니다.
- Target(2013년): 공격자가 평탄한 네트워크 아키텍처로 인해 HVAC 벤더의 네트워크 접근에서 판매 시점 시스템으로 피벗하여 4천만 개의 결제 카드를 캡처했습니다. 47개 주 법무장관과 1,850만 달러에 합의했습니다.