사전 PCI DSS
표준

PCI DSS

gabury1고친 사람 github-actions[bot]

PCI DSS 는 카드 번호를 다루는 회사가 그 번호를 어떻게 지켜야 하는지 정해 줍니다. 지킬 일을 열두 개의 요구 사항으로 묶어 문서 하나에 적었습니다. 카드 결제를 받는 서비스는 이 요구를 지켰다고 증명해야 결제를 계속 받을 수 있습니다.

쉽고 빠른 이해

PCI DSS 는 카드 번호를 맡은 회사가 따르는 보안 규칙 모음입니다. 이를테면 카드 뒷면에 찍힌 짧은 확인 번호는 결제가 끝나면 지워야 합니다. 암호화해서 남겨 두는 것도 안 됩니다.

이게 없으면 카드 번호를 얼마나 잘 지키는지가 회사마다 제각각입니다. 한 곳이 뚫려 번호가 새면 피해는 카드 주인과 결제에 얽힌 회사들이 떠안습니다. 그래서 비자·마스터카드 같은 카드 브랜드들이 함께 기준선을 정해 두었습니다. 결제를 받는 곳이면 누구나 그 선을 넘어야 합니다.

지키는 일은 이렇게 돕니다.

  1. 카드 번호가 지나가거나 쌓이는 서버와 네트워크를 찾아 선을 긋습니다
  2. 그 선 안쪽의 시스템에 열두 요구 사항을 적용합니다. 암호화, 접근 막기, 로그 남기기 같은 일입니다
  3. 해마다 점검을 받거나 스스로 설문을 채워 지켰다는 것을 증명합니다

대가는 선 안쪽이 넓을수록 일이 불어난다는 것입니다. 카드 번호가 로그 한 줄에만 찍혀도 그 로그를 모으는 시스템까지 전부 규칙을 따라야 합니다. 그래서 많은 서비스가 카드 번호를 아예 안 다루도록 구조를 짭니다.

상세

이 절은 PCI DSS 가 무엇을 지키라고 하는지, 누가 그걸 요구하는지, 백엔드 코드에서는 어디에 닿는지를 차례로 봅니다. 예로는 온라인 쇼핑몰이 카드 결제를 받는 경우를 계속 씁니다.

이름과 만든 곳

PCI DSS 는 Payment Card Industry Data Security Standard 를 줄인 이름입니다. 우리말로는 결제 카드 산업 데이터 보안 표준이라고 옮깁니다. 카드를 발급하고 결제를 처리하는 업계 전체가 함께 쓰는 보안 기준이라는 뜻입니다.

PCI DSS 를 펴내는 곳은 PCI Security Standards Council 입니다. 줄여서 PCI SSC(Payment Card Industry Security Standards Council, 결제 카드 산업 보안 표준 위원회)라고 합니다. 비자·마스터카드 같은 카드 브랜드들이 함께 세운 단체입니다. 브랜드마다 보안 요구가 따로 있으면 가맹점이 여러 벌을 맞춰야 합니다. 그래서 요구를 한 문서로 모으려고 만들었습니다.

카드 브랜드는 비자·마스터카드처럼 자기 이름을 단 카드 결제망을 운영하는 회사입니다. 결제 요청은 이 결제망을 타고 오갑니다.

카드를 손님에게 직접 내주는 은행이나 금융사는 따로 있습니다. 이곳을 발급사라고 합니다. 결제를 해 줄지 말지는 카드를 내준 발급사가 정합니다.

가맹점은 카드 결제를 받는 가게나 서비스입니다. 쇼핑몰도 카드 결제를 받으면 가맹점입니다.

법이 아니라 계약

PCI DSS 는 나라가 만든 법이 아닙니다. 카드 결제망에 들어오려면 받아들여야 하는 계약 조건입니다. 가맹점은 매입사와 계약을 맺어야 카드 결제를 받을 수 있습니다. 매입사는 가맹점의 카드 결제를 카드 브랜드의 결제망에 실어 발급사에 청구하고, 대금을 받아 가맹점에 넘겨 주는 금융사입니다. 카드 브랜드는 매입사에게 PCI DSS 를 지키게 합니다. 매입사는 그 요구를 가맹점 계약에 넣습니다.

그래서 요구를 어겼을 때 오는 것도 형사 처벌이 아니라 계약상 불이익입니다. 위반이 드러나면 벌금을 물거나 카드 결제를 더는 못 받게 될 수 있습니다. PCI SSC 는 기준을 펴낼 뿐이고, 지켰는지 따져 불이익을 주는 쪽은 카드 브랜드와 매입사입니다.

지키는 데이터 두 종류

PCI DSS 가 지키는 것은 계정 데이터입니다. 카드 한 장에 딸린 정보 가운데 새면 부정 결제에 쓰일 수 있는 것들입니다. 계정 데이터는 두 무리로 나뉩니다. 저장해도 되지만 잘 지켜야 하는 것과, 결제가 끝나면 남겨 두면 안 되는 것입니다.

무리 담긴 것 결제가 끝난 뒤
카드 소지자 데이터 카드 번호 · 카드 주인 이름 · 유효 기간 · 서비스 코드 필요하면 저장해도 된다. 카드 번호는 읽을 수 없게 바꿔 둔다
민감 인증 데이터 마그네틱 띠나 칩에 담긴 트랙 데이터 전체 · 카드 인증 코드 · PIN(Personal Identification Number, 개인 식별 번호)과 PIN 블록 저장하면 안 된다. 암호화해도 안 된다

카드 번호는 카드 앞면에 찍힌 긴 번호입니다. 영문 문서와 코드에서는 이 번호를 PAN(Primary Account Number, 기본 계정 번호)으로 줄여 씁니다.

서비스 코드는 마그네틱 띠에 담긴 숫자 세 개짜리 값입니다. 이 카드를 어디서 어떻게 쓸 수 있는지를 알려 줍니다.

트랙 데이터는 마그네틱 띠나 칩에 기록된 원본 값 전체입니다. 카드를 단말기에 긁거나 꽂으면 이 값이 통째로 읽힙니다.

카드 인증 코드는 카드 앞면이나 뒷면에 찍힌 숫자 서너 개입니다. 온라인 결제처럼 카드를 직접 보여 줄 수 없을 때 카드를 손에 쥔 사람인지 확인하는 데 씁니다.

PIN 은 카드 주인만 아는 비밀번호입니다. PIN 블록은 그 PIN 을 암호화해 실어 나르는 덩어리입니다.

결제가 끝나면 지워야 하는 값

두 무리를 가르는 기준은 결제 승인입니다. 승인은 발급사가 「이 결제를 받아도 된다」고 답하는 단계입니다. 민감 인증 데이터는 승인을 받는 데만 씁니다. 승인이 끝나면 되살릴 수 없게 지워야 합니다.

이렇게까지 막는 까닭은 이 값들이 하는 일에 있습니다. 카드 인증 코드와 트랙 데이터는 「지금 카드를 가진 사람이 결제한다」는 증거입니다. 이 증거가 카드 번호와 함께 새면 훔친 사람이 카드 주인 행세를 할 수 있습니다. 증거는 한 번 쓰고 버려야 증거 노릇을 합니다.

쇼핑몰에서 자주 부딪히는 경우는 결제를 다시 시도하려고 카드 인증 코드를 데이터베이스에 남기고 싶어질 때입니다. PCI DSS 에서는 이것부터 위반입니다. 암호화해서 넣어도 마찬가지입니다.

그래서 다시 결제해야 하면 손님에게 코드를 다시 묻습니다. 아니면 카드 번호를 결제 대행사에 맡깁니다. 결제 대행사는 가맹점을 대신해 카드 결제를 처리해 주는 회사입니다.

결제 대행사는 카드 번호를 자기 쪽에 보관합니다. 가맹점에는 그 번호 대신 아무 뜻 없는 값인 토큰을 돌려줍니다. 진짜 값을 토큰으로 바꿔 두는 이 일을 토큰화라고 합니다. 다음 결제 때 가맹점은 토큰만 보내면 됩니다.

카드 번호를 읽을 수 없게 바꾸는 방법

카드 번호는 저장해도 됩니다. 대신 저장된 곳 어디에서든 그대로 읽히면 안 됩니다. 이 조건을 채우는 방법은 넷입니다.

방법 하는 일 되돌릴 수 있나
단방향 해시 카드 번호 전체를 강한 암호 기반 해시 함수에 넣어 나온 값만 저장한다 없다
트렁케이션 번호의 가운데를 잘라 내고 앞뒤 일부만 저장한다 없다
토큰 번호 대신 아무 뜻 없는 값을 저장한다. 진짜 번호와의 짝은 따로 지키는 곳에만 둔다 짝을 가진 곳만 할 수 있다
강한 암호화 번호를 암호화해 저장하고 키는 따로 관리한다 키를 가진 쪽만 할 수 있다

표의 첫 두 줄은 원래 번호로 못 돌아가는 방법입니다. 결제를 다시 해야 하는 서비스라면 뒤의 두 줄 가운데서 고릅니다. 앞에서 본 결제 대행사의 토큰이 셋째 줄 방식입니다. 진짜 번호와의 짝은 결제 대행사가 지킵니다.

같은 카드 번호를 해시한 값과 잘라 낸 값을 한 시스템에 함께 두면 둘을 맞춰 보며 원래 번호를 되살릴 수 있습니다. 잘라 낸 값에서 모르는 것은 가운데 숫자 몇 개뿐입니다. 빈 곳에 숫자를 차례로 넣어 해시해 보면, 저장된 해시값과 같아지는 조합이 원래 번호입니다. 그래서 이런 경우에는 두 값을 서로 잇지 못하게 막는 통제를 더 둬야 합니다.

화면에 보이는 카드 번호

저장이 아니라 화면에 보여 줄 때의 규칙은 따로 있습니다. 카드 번호를 보여 줄 때는 앞쪽의 발급사 식별 번호와 끝 숫자 넷까지만 보입니다. 발급사 식별 번호는 영문을 줄여 BIN(Bank Identification Number)이라고도 합니다. 카드 번호 앞쪽 숫자 여섯에서 여덟 개로, 어느 발급사가 내준 카드인지를 가리킵니다. 업무상 전체 번호를 봐야 하는 사람만 그보다 많이 볼 수 있습니다.

아래는 결제 테스트에 널리 쓰는 가짜 카드 번호를 가린 모습입니다. BIN 을 여섯 자리로 잡았습니다.

Java
String pan = "4111111111111111";

mask(pan)    // 411111******1111
last4(pan)   // ************1111

mask 는 허용되는 끝까지 보여 준 모양입니다. last4 는 마지막 숫자 넷만 남긴 모양입니다. 주문 내역 화면처럼 손님이 자기 카드를 알아보기만 하면 되는 곳에서는 대개 last4 쪽을 씁니다.

카드 데이터 환경과 범위

PCI DSS 를 적용하는 첫 일은 요구를 어느 시스템에 걸지 정하는 것입니다. 이 일을 범위를 정한다고 합니다. 범위의 한가운데에는 카드 데이터 환경이 있습니다. 영문 줄임말은 CDE(Cardholder Data Environment)입니다. 카드 데이터를 저장하거나 처리하거나 전송하는 시스템, 그리고 그 시스템과 막힘없이 연결된 시스템이 여기에 듭니다.

범위에 든 시스템은 열두 요구 사항을 전부 따라야 합니다. 그래서 범위가 넓을수록 지킬 일이 커집니다. 카드 번호가 애플리케이션 로그에 한 줄만 찍혀도 그 로그를 모으고 보관하는 시스템까지 범위에 들어옵니다.

범위를 줄이는 가장 널리 쓰는 방법은 카드 번호가 우리 서버를 지나가지 않게 하는 것입니다. 카드 번호 입력은 앞에서 본 결제 대행사의 결제창에서 받습니다. 우리 서버는 결제 대행사가 돌려준 토큰만 들고 다닙니다.

flowchart TD
    subgraph A["직접 받을 때 · 전부 범위 안"]
        A1["브라우저"] -->|카드 번호| A2["주문 서버"]
        A2 --> A3["주문 데이터베이스"]
        A2 --> A4["애플리케이션 로그"]
    end
    subgraph B["결제창을 빌릴 때 · 범위가 줄어든다"]
        B1["브라우저"] -->|카드 번호| B2["결제 대행사"]
        B2 -->|토큰| B3["주문 서버"]
        B3 --> B4["주문 데이터베이스 · 토큰만"]
    end
    A3 ~~~ B1

위쪽 그림은 주문 서버가 카드 번호를 직접 받는 경우입니다. 주문 서버와 주문 데이터베이스와 애플리케이션 로그가 모두 카드 번호를 다루므로 모두 범위 안입니다. 아래쪽 그림에서는 카드 번호가 브라우저에서 결제 대행사로 곧장 갑니다. 주문 서버와 주문 데이터베이스에는 토큰만 남습니다.

범위가 줄어도 0 이 되지는 않습니다. 결제창을 띄우는 우리 웹 페이지가 공격자 손에 바뀌면 손님이 가짜 결제창에 카드 번호를 넣게 될 수 있습니다. 그래서 결제창을 빌려 쓰는 가맹점에도 그 페이지를 지키는 요구가 조금 남습니다.

범위를 줄이는 또 하나의 방법은 네트워크 분할입니다. 카드 데이터 환경을 나머지 사내망과 방화벽으로 떼어 놓아, 나머지 시스템이 범위에 끌려 들어오지 않게 합니다.

열두 요구 사항

요구 사항은 열두 개이고, 목표 여섯 개 아래에 하나에서 셋씩 묶여 있습니다. 아래 표는 영문 제목을 우리말로 옮긴 것입니다.

목표 요구 사항
안전한 네트워크와 시스템을 세우고 유지한다 1 네트워크 보안 통제를 설치하고 유지한다 · 2 모든 시스템 구성 요소에 안전한 설정을 적용한다
계정 데이터를 지킨다 3 저장된 계정 데이터를 지킨다 · 4 공개망으로 보낼 때 강한 암호로 카드 소지자 데이터를 지킨다
취약점 관리 체계를 유지한다 5 모든 시스템과 네트워크를 악성 소프트웨어로부터 지킨다 · 6 안전한 시스템과 소프트웨어를 개발하고 유지한다
강한 접근 통제를 둔다 7 업무상 알아야 하는 사람만 시스템과 카드 소지자 데이터에 닿게 한다 · 8 사용자를 식별하고 접근을 인증한다 · 9 카드 소지자 데이터에 대한 물리적 접근을 막는다
네트워크를 꾸준히 감시하고 시험한다 10 시스템과 카드 소지자 데이터에 대한 모든 접근을 기록하고 감시한다 · 11 시스템과 네트워크의 보안을 정기적으로 시험한다
정보 보안 정책을 유지한다 12 조직의 정책과 프로그램으로 정보 보안을 뒷받침한다

앞에서 본 저장 금지와 가리기 규칙은 모두 3번 요구 사항에 들어 있습니다. 각 요구 사항 아래에는 3.3.1 처럼 번호가 붙은 세부 요구가 수십 개씩 달립니다. 점검은 이 세부 요구 하나하나에 대해 이루어집니다.

백엔드 코드에 닿는 요구

아래 표는 열두 개 가운데 서버를 짜는 사람이 자주 부딪히는 것만 추린 것입니다.

요구 서버 쪽에서 하는 일
3 저장된 데이터 보호 카드 인증 코드를 저장하지 않는다. 카드 번호는 해시·토큰·암호화 가운데 하나로 바꿔 저장한다
4 전송 중 보호 공개망으로 카드 데이터를 보낼 때 TLS(Transport Layer Security, 전송 계층 보안) 같은 강한 암호를 쓴다
6 안전한 개발 알려진 취약점을 고치고 코드 리뷰와 보안 시험을 거쳐 배포한다
7 필요한 사람만 접근 최소 권한으로 계정과 역할을 나눈다
8 식별과 인증 카드 데이터 환경에 들어가는 모든 접근에 다중 인증을 건다
10 기록과 감시 누가 언제 무엇에 접근했는지 감사 로그로 남기고 지켜본다

표의 10번은 보관 기간까지 정해 둡니다. 감사 로그는 적어도 12개월을 남깁니다. 그중 최근 3개월치는 바로 꺼내 분석할 수 있어야 합니다. 사고가 늦게 드러나도 거슬러 올라가 누가 무엇을 봤는지 따질 수 있게 하려는 것입니다.

로그를 남기라는 요구와 카드 번호를 숨기라는 요구는 한 줄의 로그에서 만납니다. 요청 본문을 그대로 찍는 디버그 로그는 카드 번호를 로그에 흘리는 대표적인 경로입니다. 카드 번호가 들어올 수 있는 필드는 로그에 쓰기 전에 가립니다.

11번은 바깥에서의 점검을 요구합니다. 인터넷 쪽에서 우리 시스템을 훑는 취약점 스캔을 석 달에 한 번 이상 돌려야 합니다. 이 외부 스캔은 PCI SSC 가 승인한 업체가 맡습니다. 이런 업체를 ASV(Approved Scanning Vendor, 승인 스캔 업체)라고 부릅니다.

지켰다는 것을 증명하는 법

PCI DSS 는 한 번 맞추고 끝나는 기준이 아닙니다. 가맹점은 해마다 지켰다는 것을 매입사에게 증명합니다. 증명 방법은 가맹점의 규모에 따라 둘로 갈립니다. 규모는 한 해 카드 거래 건수로 잽니다. 등급을 나누는 기준은 카드 브랜드가 정합니다.

거래가 많은 가맹점은 외부 평가자에게 점검을 받습니다. 이 평가자를 QSA(Qualified Security Assessor, 인증 보안 평가자)라고 부릅니다. 자격은 PCI SSC 가 줍니다. QSA 는 현장을 보고 세부 요구마다 지켰는지 판정해 준수 보고서를 씁니다.

거래가 적은 가맹점은 SAQ(Self-Assessment Questionnaire, 자체 평가 설문)를 스스로 채웁니다. SAQ 는 여러 종류가 있습니다. 가맹점이 카드 데이터를 얼마나 다루는지에 따라 고르는 설문이 달라집니다. 결제창을 전부 빌려 쓰는 가맹점의 설문은 짧습니다. 카드 번호를 직접 저장하는 가맹점의 설문은 요구 사항 전체를 다룹니다.

판

지금 쓰이는 판은 4.0.1 판입니다. 2022년에 나온 4.0 판이 그 전의 3.2.1 판을 대신했습니다. 4.0.1 판은 4.0 판을 손본 판입니다. 4.0.1 판은 오탈자와 문구를 고치고 일부 요구의 뜻을 또렷하게 다듬었습니다. 요구 사항을 더하거나 빼지는 않았습니다.

적용 대상

카드 번호를 저장하거나 처리하거나 전송하는 조직이면 PCI DSS 가 적용됩니다. 카드 번호를 직접 다루지 않아도 카드 데이터 환경의 보안에 영향을 줄 수 있는 조직도 들어갑니다. 가맹점뿐 아니라 결제 대행사, 호스팅 업체처럼 가맹점을 대신해 카드 데이터를 다루는 서비스 제공자도 대상입니다.

반대로 PCI DSS 는 카드 데이터만 봅니다. 주민등록번호나 의료 기록 같은 다른 개인정보는 이 기준의 관심 밖입니다. 그런 데이터는 나라별 개인정보 법이나 다른 보안 기준이 다룹니다.

관련 항목

PCI DSS 가 지키는 카드 데이터

PAN · 계정 데이터 · 카드 소지자 데이터 · 민감 인증 데이터 · 카드 인증 코드 · PIN · 마그네틱 띠 · BIN

PCI DSS 의 범위를 줄이는 수단

토큰화 · 토큰 볼트 · 결제 대행사 · 호스팅 결제창 · 네트워크 분할 · 트렁케이션 · 카드 데이터 환경

PCI DSS 요구 사항이 부르는 보안 통제

방화벽 · TLS · 암호화 · 해시 함수 · 키 관리 · 하드웨어 보안 모듈 · 다중 인증 · 접근 제어 · 최소 권한 · 감사 로그 · 취약점 스캔 · 침투 테스트 · 악성 소프트웨어 · 보안 설정 기준

PCI DSS 준수를 요구하고 평가하는 주체

PCI Security Standards Council · 카드 브랜드 · 발급사 · 매입사 · 가맹점 · 서비스 제공자 · QSA · ASV

PCI DSS 준수를 증명하는 문서

SAQ · 준수 보고서 · 준수 확인서 · 취약점 스캔 보고서

PCI SSC 가 함께 펴내는 다른 표준

PA-DSS · PCI Secure Software Standard · PCI PIN · PCI PTS · PCI 3DS

PCI DSS 와 나란히 서는 보안 규정과 인증

규정 준수 · GDPR · HIPAA · SOC 2 · ISO 27001 · ISMS-P

PCI DSS 가 속하는 상위 분야

보안 엔지니어링 · 정보 보안 · 결제 시스템 · 위험 관리

다른 이름: Payment Card Industry Data Security Standard · 결제 카드 산업 데이터 보안 표준 · PCI-DSS