실제 결제 경계를 그리세요
제품 페이지에서 확인 페이지까지 구매자 경로를 지도화하세요. 카드 입력 지점, 리디렉트, 프레임, 스크립트, API, 플러그인, 태그 관리자, 콘텐츠 전송 네트워크, 그리고 그 단계에 영향을 줄 수 있는 관리자 계정을 표시하세요. 관련 로그, 지원 도구, 분석도 포함하세요. 이는 공급자나 평가자에게 제공할 시작 기록이며 준수 여부를 단정하는 문서는 아닙니다.
각 결제 페이지 요소를 제공하는 도메인을 기록하세요. PCI SSC는 SAQ A 자격을 얻으려면 모든 결제 페이지 요소가 오직 PCI DSS 준수 서비스 제공자에서만 유래(origin)해야 하며 상인(merchant) 사이트에서 유래하면 안 된다고 말합니다. SAQ A-EP의 경우 각 요소는 상인 또는 그러한 제공자에서 유래할 수 있지만 다른 출처에서 오면 안 됩니다. 다른 모든 기준은 여전히 적용됩니다.
저장소(repository)만 보면 태그 관리자 주입과 플랫폼 설정을 놓칠 수 있습니다. 정상적인 체크아웃 브라우저 세션에서 스크립트, 프레임, 도메인, 헤더를 검토하세요.
로그, 분석, 지원 워크플로에서 결제 필드를 검사하세요. 테스트 티켓이나 공유 증거에 실제 카드 데이터를 절대 사용하지 마세요.
설명 가능한 결제 모델로 노출을 줄이세요
실무적으로 가능하면 PCI DSS를 준수하는 제공자가 카드 데이터를 수집하도록 통합을 설계하고 귀사 애플리케이션이 수신하거나 저장하지 않도록 하세요. 공급자 호스팅 리디렉트가 맞춤 폼(custom form)보다 더 단순한 경우가 많지만, 임베디드 필드와 iframe도 귀사 사이트가 결제에 영향을 미칠 수 있게 합니다. ‘호스팅’이라는 레이블에 의존하지 말고 실제 통합 방식을 문서화하세요.
주요 계정번호(PAN), 보안 코드, 체크아웃 오류 스크린샷, 또는 복사한 결제 세부정보는 승인된 설계가 요구하지 않는 한 보관하지 마세요. 암호화는 데이터를 보호하지만 PCI SSC는 일반적으로 암호화만으로 환경을 범위 밖으로 만들지 않는다고 경고합니다. 토큰, 키, 웹훅, 환불, 책임 처리 방식을 공급자와 자격 있는 리뷰어와 확인하세요.
통합 가이드, 책임 분담 정보, 관련 준수 문서, 변경 통지 프로세스를 아키텍처 기록과 함께 보관하세요.
마케팅 실험, 리플레이 도구, 채팅 위젯, 선택적 라이브러리를 이름 있는 소유자와 이들이 접근할 수 있는 내용을 검토 없이 추가하지 마세요.
스크립트, 태그, 헤더를 통제하세요
타사 브라우저 코드는 통제되지 않은 변경, 임의 코드 실행, 타당성 없는 제3자 노출을 도입할 수 있습니다. 각 스크립트의 도메인, 목적, 소유자, 승인, 로드 위치를 포함한 체크아웃 재고(inventory)를 유지하세요. 소스 트리 파일뿐 아니라 태그 관리자 규칙과 공급자가 로드하는 코드도 포함하세요.
PCI SSC는 승인된 스크립트, 무결성, 변조 감지, 보안 영향이 있는 HTTP 헤더에 초점을 맞춥니다. 기준선을 승인하고, 변경을 제한하고, 차이를 감지해 조사하세요. Content Security Policy(CSP)는 리소스 출처를 제한할 수 있습니다. 적절한 경우 시행 전에 report-only(보고 전용) 모드로 테스트하세요. CSP는 심층 방어(defense in depth)이며 안전한 코딩이나 코드 리뷰를 대체하지 않습니다.
Subresource Integrity(SRI)는 외부 스크립트 변경을 거부할 수 있지만 교차 출처 구성(cross-origin configuration)과 호환되어야 하고 공급자 업데이트 후 깨질 수 있습니다.
퍼블리싱 역할을 제한하고 강력한 인증을 요구하며 커스텀 코드 기능을 검토하고 감사 추적을 유지하세요.
접근을 제한하고 체크아웃 변경을 복구 가능하게 만드세요
일반 콘텐츠 게시와 체크아웃 코드, 결제 공급자 관리, 호스팅, DNS, 태그 관리를 분리하세요. 이름 있는 계정, 최소 권한, 다중요소 인증(MFA)을 사용하고 역할 변경 후 접근을 검토해 전 직원, 공급업체, 대행사의 이전 권한을 제거하세요. 정확한 PCI DSS 적용 여부는 환경에 따라 달라지지만 공유 권한과 상시 권한을 줄이면 위험이 감소합니다.
체크아웃에 대해 릴리스 프로세스를 사용하세요: 이름 있는 소유자, 리뷰, 가능한 경우 테스트, 롤백 방법, 릴리스 후 브라우저 점검. 성공 및 실패 경로, 리디렉트, 모바일 동작을 테스트하세요. Status Is UP는 출시 준비성, 성능 최적화, 롤백 계획을 사전적으로 지원하지만 PCI DSS 준수를 결정하지는 않습니다.
자격 증명, 백업 코드, 롤백 지침은 승인된 접근 통제 시스템에 보관하고 절대 티켓, 스크린샷, 공개 저장소에 두지 마세요.
릴리스 후 브라우저에서 보이는 스크립트, 도메인, 헤더를 승인된 재고와 비교하세요.
스택을 업데이트하고 결과를 검증하세요
체크아웃에 영향을 주는 커머스 플랫폼, 플러그인, 테마, 서버 구성요소, 라이브러리, 결제 SDK, 태그 템플릿, 서비스의 재고를 유지하세요. 중요 공급업체 공지를 구독하세요. NIST는 패치 관리를 업데이트 식별, 우선순위 지정, 획득, 설치, 검증으로 설명합니다. 변경을 기록하고 결제 여정을 테스트하며 배포된 내용을 확인하세요.
고위험 이슈에 대한 긴급 경로와 일상 변경을 위한 유지관리 창(maintenance window)을 설정하세요. 노출된 체크아웃 컴포넌트를 우선시하되, 프로덕션에 무작정 패치해 결제를 망가뜨리지 마세요. 테스트된 롤백 접근과 공급자 릴리스 지침을 사용하세요. 오래된 구성요소에 대한 소유자가 불명확하면 해결해야 할 위험입니다.
권고문, 위험 결정, 테스트 결과, 배포 기록, 최종 검증을 함께 보관하세요.
증거를 보관하고 자격 있는 도움을 받으세요
다이어그램, 공급자 책임 정보, SAQ 적격성 근거, 스크립트 및 헤더 재고, 접근 검토, 승인, 테스트 결과, 변경 및 공급업체 연락처를 통제된 위치에 보관하세요. 아키텍처, 소유권, 스크립트, 공급자가 변경될 때 갱신하세요. 증거는 카드 데이터, 비밀(secrets), 고객 기록을 노출하지 않으면서 권한 있는 리뷰어가 이해하기 쉽게 해야 합니다.
적용 가능한 검증 기대치는 귀사의 인수사(acquirer) 또는 결제 브랜드가 설정합니다. PCI SSC는 Qualified Security Assessors(QSAs)를 PCI DSS 평가를 수행할 자격이 있는 독립 조직으로, Approved Scanning Vendors(ASVs)를 적용 요구사항 하의 자격 있는 외부 스캐닝 제공자로 식별합니다. 맞춤형 체크아웃, 범위 불명확, 의심스러운 침해, 또는 SAQ 선택이 필요할 때 자격 있는 도움을 구하세요.
체크아웃 모델, 기술 소유자, 에스컬레이션 연락처, 마지막 검토 날짜, 증거 링크를 함께 보관하세요.