🙋♀️ : 사용자의 카드정보를 저장해서 다음에 결제할 때 간편하게 결제할 수 있도록 하고싶은데 프론트엔드에서 카드정보 받아서 빌링키 발급받고 DB에 저장해서 다음 결제 요청할 때 쓰면 안되나?
➡️ NO! 카드정보를 직접 받는 순간 보안 책임이 한꺼번에 늘어난다
🙋♀️ : 무슨 보안 책임???
우선 결제구현시 필요한 것
전송 구간 보호
브라우저 -> 서버로 카드정보가 이동하는 길 자체를 안전하게 지키는 것.
예를들어 사용자가 카드번호를 입력했는데 그 값이 서버로 갈 때 암호화가 약하거나, 잘못된 TLS 설정이 있거나, HTTP로 새어나가면 중간에 가로채이거나 변조될 수 있음.
🙋♀️TLS가 뭐지
➡️ Transport Layer Security. 인터넷에서 데이터를 안전하게 주고받게 해주는 보안 규칙.
내 브라우저와 상대서버에서 데이터가 왔다갔다 할 때 아이디,비밀번호,카드번호 같은걸 암호화해서 보냄.
또한 보내는 도중에 누가 데이터를 슬쩍 조작하는걸 막아주고, 내가 접속한 서버가 진짜 그 사이트 서버인지 확인하는데 도움을 줌.
HTTP 가 엽서라면 HTTPS(HTTP + TLS)는 봉인된 등기우편.
🙋♀️TLS설정이 잘못되는 경우가 뭐임?
➡️ 암호화 방식이나 인증방식이 약해서 중간에 엿보거나, 가짜 서버로 속이거나, 보안 수준이 낮아지는 상태.
예 : 낡은 프로토콜 버전을 허용하는 경우 ( TLS 1.0이나 1.1을 아직 열어두는 것)
약한 암호 스위트(cipher suite)를 허용하는 경우 (암호화는 하는데 너무 약한 자물쇠를 쓰는 것)
인증서 검증이 제대로 안되는 경우 (클라이언트가 서버 인증서를 검증하지 않거나, 호스트명 검증을 빼먹거나, 신뢰할 수 없는 인증서를 그냥 통과시키는 경우), HTTP를 완전히 막지 않은 경우
=> 카드 등록 페이지가 https://로 열리긴 하는데, 서버가 TLS 1.0도 허용하고, 어떤 서브도메인은 http로도 접속되고, HSTS도 없고, api 클라이언트는 인증서 검증을 느슨하게 해둔 경우
🙋♀️ HSTS가 뭐지
➡️ ‘이 사이트는 무조건 https로만 접속해’라고 브라우저에 강하게 알려주는 규칙. HTTP Strict Transport Security.
사이트가 https를 지원해도 사용자가 처음에 http://로 들어오면 잠깐이라도 안전하지않은 연결이 될 수 있기때문에 필요.
HTTPS만 있는 사이트 : 경비원이 ‘다음부터는 정문으로 와주세요’라고 말함
HSTS 있는 사이트 : 방문객 명단에 ‘이 집은 무조건 정문만 사용’이라고 미리 적혀 있음
헤더는 보통 이런 식으로 내려감 :
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadmax-age=31536000 : 1년동안 이 사이트는 HTTPS만 쓰겠다고 기억
includeSubDomains : 서브도메인도 같이 적용(api.example.com같은거)
preload : 아예 처음부터 ‘이 도메인은 HTTPS 전용’ 목록에 넣을 수 있게하는 용도. (첫 방문이어도 HTTP로 안가게)
(Preload가 없으면 첫 HTTP요청의 순간이 생기는데, 이때 공격자가 개입하는걸 SSL stripping 공격이라고 함)
그래서 보통 HTTPS/TLS를 제대로 강제하고, 약한 설정을 막고, 브라우저가 항상 안전한 연결만 쓰게 만드는게 중요함.
OWASP도 TLS를 제대로 구성하면 전송 중 정보의 기밀성과 무결성을 보호할 수 있다고 설명함
🙋♀️ OWASP가 뭐지
➡️ Open Worldwide Application Security Project, 웹사이트나 앱을 더 안전하게 만들기 위한 보안 가이드, 문서, 체크리스트 만드는 곳. 개발자가 보안 구현할 때 참고하는 실전가이드/베스트 프랙티스 모음집)
저장 금지 정책
카드정보를 아예 안 저장하거나 꼭 필요한 최소만 잠깐 다루고 바로 버리는 규칙.
특히 CVC같은 민감 인증 데이터는 결제후 저장이 금지되어있음. PCI SSC도 카드 검증값(CVC/CVV)은 카드온파일이나 정기결제 목적이라도 저장이 금지된다고 안내하고 있음. 또 불필요한 카드데이터는 보관 기간을 최소화하고 주기적으로 제거해야한다고 함.
(*PCI SSC : 카드 결제 보안 규칙을 만드는 공식 조직. Payment Card Industry Security Standards Council)
🙋♀️ 빌링키로 카드정보 받을 수 있으면 안전한거 아냐?
➡️ NO! 안전한 구조는 아래와 같음 :
프론트 → PG → 카드 등록
↓
빌링키 발급
↓
우리 서버 저장
↓
결제할 때 빌링키로 요청카드정보를 ‘받는 순간’ 다시 위험해짐. 카드정보가 우리 시스템을 절대 지나가지 않는 구조가 안전한거임
로그 마스킹
에러로그, 콘솔 로그, APM, 모니터링 툴 같은데 카드정보가 그대로 찍히지 않게 가리는 것.
DB를 안 털어도 로그만 봐도 정보가 샐 수 있음
접근 통제
누가 카드 관련 정보나 시스템에 접근할 수 있는지 최소한으로 제한하는 것.
예를들어 운영자/개발자/협력업체/서버 계정 중에서 정말 필요한 사람만 접근하게 해야하고, 공용 계정 남발하면 안되고, 누가 언제 접근했는지도 추적 가능해야함. PCI DSS는 사용자 식별과 인증, 접근 권한 제한 같은 요구사항을 핵심으로 두고 있음.
🙋♀️PCI DSS가 뭐지
➡️ 카드정보를 안전하게 다루기 위한 보안 표준. Payment Card Industry Data Security Standard.
카드데이터 보호(카드번호 암호화/CVC 저장금지/최소한만 저장), 안전한 네트워크(방화벽, TLS, 내부망 분리), 접근 통제, 취약점 관리(보안 업데이트, 취약점 점검, 악성코드 방지), 모니터링&로그 등을 요구함
취약점 점검
해커가 들어올 구멍이 없는지 계속 검사하는 것.
예를 들면 입력값 검증이 약해서 우회 가능한지, 오래된 라이브러리 취약점 있는지, TLS 설정이 약한지, 관리자 페이지 접근 통제가 허술한지, 로그/에러 페이지에 민감정보 노출되는지
🙋♀️여기서 관리자페이지가 정확히 뭔데?
➡️ 우리 회사 어드민 사이트, 운영툴, 백오피스, CS용 회원 조회 화면, 결제내역 조회 화면, 카드 등록 상태 조회 화면, 정기결제 관리 화면, 실패 결제 재시도 화면, 로그 조회 페이지, 관리자 API Swagger / Internal admin API등 카드정보나 빌링키, 결제 상태를 볼 수 있는 내부 화면 전부를 의미함)
PCI DSS 대응
PCI DSS는 카드정보를 따라야할 결제 보안 표준.
카드회원 데이터나 민감 인증 데이터를 저장,처ㄹㅣ,전송하는 모든 엔터티가 PCI DSS범위에 들어간다고 설명함.
그래서 서비스가 카드번호/CVC를 직접 받는 순간, 보안표준준수 대상이 될 수 있음.
🙋♀️보안 표준 준수 대상이 되면 뭔데? 뭐 인증 받아야함?
➡️ ㅇㅇ
- PCI DSS 준수 대상이 되면 보안검사 + 증명 해야함
- 우리 서비스는 카드정보 안전하게 다룹니다, 를 문서 + 점검으로 공식적으로 증명해야 함
- SAQ(Self Assessment Questionnaire)를 직접 체크해서 제출하고
- ASV 스캔(외부 취약점 검사)를 분기별로 해야하고
- QSA 심사 (보안전문가가 직접 와서 점검하는거) 해야함
- 카드 정보 직접 받는데 이걸 안하면 ‘규정 위반 상태로 운영중인 서비스’됨
- 사고나면 지옥됨 (카드결제 차단, 벌금(패널티), 손해배상, 개인정보보호법/전자금융거래법 위반, 집단소송 등 난리남)
좋은 구조는?
[프론트]
↓
PG UI
↓
[PG 서버]
↓ (빌링키)
[우리 서버]
↓
결제 요청 (빌링키)
↓
[PG]우리는 카드번호를 단 한번도 몰라야 됨
1단계 : 카드 등록
유저 → PG 카드등록 UI → PG → 빌링키 발급 → 우리 서버 저장
핵심 ! 카드 입력 UI는 PG가 제공.
🔪 절대 하면 안되는거 :
- 우리 input에서 카드 번호 입력받기
- CVC받기
- 서버로 카드 보내기
2단계 : 결제 요청
우리 서버 → PG → billingKey로 결제 요청
3단계 : 관리자페이지
🔪 절대 하면 안돼 : 카드번호 전체 보여주기, CVC 보여주기
🐻❄️ 이렇게만 해야함 : ** ** **** 1234, 카드사, 결제 상태
보안 체크리스트
전송 : HTTPS만 사용 / HSTS 적용
저장 : billingKey만 저장 / 민감정보 저장 금지
로그 : request body에 카드정보 없음 / billingKey도 일부 마스킹
권한 : 관리자 접근 제한 / CS도 최소 정보만 조회
인프라 : 최신 TLS(1.2이상) / 취약점 스캔
