태국 중앙은행 API 페이로드 암호화 규정
목차
수년간 “전송 중 데이터 암호화"는 한 가지를 의미했습니다. HTTPS를 붙이는 것. TLS는 로드밸런서에서 종료되고, 페이로드는 내부 네트워크를 평문으로 흘렀으며, 모두가 그것을 암호화라고 불렀습니다. 태국 중앙은행은 그 간극을 꾸준히 좁혀 왔고 방향은 분명합니다. 민감한 금융 데이터에는 전송 암호화만으로는 더 이상 충분하지 않다는 것입니다.
전송 암호화와 페이로드 암호화의 차이 #
TLS는 회선 위 두 지점 사이의 데이터를 보호합니다. 애플리케이션 내부의 데이터를 보호하지 않습니다. TLS가 리버스 프록시, API 게이트웨이, 로드밸런서에서 종료되는 순간 페이로드는 복호화되어 백엔드에 평문으로 전달됩니다.
그 평문은 당신이 원하지 않는 곳을 지나고 머뭅니다:
- 로그: 요청 본문을 성실하게 기록하는 게이트웨이가 전체 PAN과 계좌번호를 남깁니다.
- 서비스 메시와 내부 홉: 마이크로서비스 간 east-west 트래픽은 “네트워크가 신뢰된다"는 가정 아래 암호화되지 않는 경우가 많습니다.
- 메모리와 캐시: 메모리상 요청 객체, 디버그 덤프, APM 트레이스가 복호화된 페이로드를 보존할 수 있습니다.
- 옵저버빌리티 파이프라인: 팀과 서드파티로 span을 전달하는 metrics와 trace가 내용을 함께 옮깁니다.
애플리케이션 계층 페이로드 암호화는 메시지 자체를 암호화해 이 간극을 메웁니다. 몇 개의 홉을 거치든 인프라가 그것으로 무엇을 하든 보호가 유지됩니다.
표준이 권하는 것 #
페이로드 암호화의 메커니즘은 표준화되어 잘 알려져 있습니다:
- JSON Web Encryption(JWE)(RFC 7516): 구조화된 API 페이로드 암호화의 사실상 표준. 대칭 데이터 키를 비대칭 수신자 키로 감쌉니다.
- AES-256-GCM: 페이로드 본문의 authenticated encryption 주력으로 기밀성과 무결성을 함께 제공합니다.
- RSA-OAEP 또는 ECDH: 대칭 키를 전송 중과 저장 시 보호하는 키 캡슐화 계층.
패턴은 TLS 자체가 쓰는 것과 같습니다. 대량 데이터에는 빠른 대칭 암호, 이를 비대칭 키 교환으로 감싸는 방식이며, 차이는 메시지 수준에 적용되어 TLS 세션 이후에도 살아남는다는 점입니다.
BOT가 지금 이것을 밀어붙이는 이유 #
규제 기관의 논리는 낯설지 않습니다. 금융 API는 이제 태국 결제 생태계 전체의 결합조직입니다. 은행, PSP, 핀테크, 가맹점. 게이트웨이 설정 실수 하나로 로그 접근권이 있는 누구에게나 계좌 정보가 노출되어선 안 됩니다. 페이로드 암호화는 다층 방어 조치입니다. 전송 계층은 언젠가 반드시 검사·기록·침해당한다고 가정하고, 그 순간에 민감한 데이터가 읽히지 않도록 보장합니다.
이는 저장된 카드홀더 데이터 보호라는 PCI DSS 요구사항의 원리와 같은 맥락입니다. 어느 한 홉도 더 이상 신뢰하지 않는 순간, “네트워크가 안전하다"를 유일한 통제로 취급하는 일을 멈추게 됩니다.
엔지니어링 팀에 대한 실무적 함의 #
페이로드 암호화 도입은 설정 토글이 아닙니다. 다음을 의미합니다:
- 키 관리가 일급 관심사가 됩니다. 로테이션, 서명 키와 암호화 키의 분리, 보호된 키 저장소가 필요합니다.
- 게이트웨이와 로깅 변경: 요청 본문을 읽거나 기록하는 모든 구성 요소를 재평가해야 합니다. 미들웨어가 더 이상 본문을 읽을 수 없기 때문입니다.
- 계약 변경: 하위 소비자가 복호화할 수 있어야 하므로, 체인의 모든 당사자 간 키 분배와 버전 관리가 필요합니다.
- 테스트: 옵저버빌리티는 “페이로드 덤프"에서 “인증·인가 후 필요한 곳에서만 복호화"로 이동해야 합니다.
BOT의 관할권 안에서 운영된다면 이 중 선택 가능한 것은 없습니다. “관로를 암호화"에서 “메시지를 보호"로의 전환입니다.
저희 규제 컴플라이언스 서비스는 BOT 가이던스를 구체적 엔지니어링 요건으로 변환하고, API & 애플리케이션 보안 점검은 페이로드가 엔드투엔드로 실제 어떻게 보호되는지 검증합니다.