#Backend

유저챗 개인정보 마스킹 개발기

유저챗 개인정보 마스킹 개발기
01

Summary

고객이 입력한 주민번호와 카드번호를 저장 전 자동 마스킹하는 채널톡의 안전한 보안 파이프라인 구축기

ReDoS 공격 차단부터 성능 예산 관리까지, 메시지 저장 지연 없이 개인정보를 암호화하는 아키텍처 노하우

본 아티클은 채널톡이 상담 내 개인정보를 안전하게 보호하기 위해 저장 직전 단일 파이프라인에서 마스킹을 수행하는 기능을 설계하고 최적화한 과정을 다룹니다. 성능 예산 내에서 실시간 트래픽을 처리하기 위해 정규식 엔진을 re2j로 교체해 ReDoS 위험을 제거하고, 메시지 길이 제한을 통해 선형적 지연 시간 증가를 관리한 실무적인 해결책을 상세히 제시합니다.

  • 01저장 후 조회가 아닌 저장 직전(Pre-storage) 단일 경로 마스킹으로 모든 다운스트림 유출 위험 차단
  • 02Luhn 알고리즘 및 발급사 BIN 조회를 결합해 카드번호 오탐율 최소화
  • 03JVM 백트래킹 엔진을 선형 시간 복잡도의 re2j 엔진으로 교체하여 ReDoS(정규식 거부 공격) 원천 차단
  • 04실측 데이터 기반의 성능 예산 수립 및 99%의 메시지가 영향받지 않도록 입력 길이 상한 임계치 설정
  • 05정규식 매칭 구간 병합(Merge) 방식을 통한 규칙 충돌 제어

RECOMMENDATION

고객 민감 정보를 취급하면서 대용량 분산 메시지 처리가 필요한 보안 및 백엔드 개발자들에게 정규식 성능 튜닝 및 안전한 파이프라인 설계 전략으로 강력히 추천합니다.

The Problem

채널톡 고객 상담 대화 중 주민등록번호나 카드번호 등 민감한 개인정보가 그대로 유입되어 DB에 저장됨에 따라, 보안 리스크 증가 및 엔터프라이즈 고객사의 도입 장벽으로 작용하고 실무자들이 수동으로 데이터를 삭제해야 하는 번거로움이 발생했습니다.

The Solution

데이터 저장 직전 파이프라인 단 한 곳에서 자동으로 개인정보를 식별 및 마스킹하도록 설계했으며, 카드번호 유효성 검증(Luhn 알고리즘 및 BIN 조회)을 적용하고, ReDoS 방지를 위해 백트래킹을 하지 않는 RE2(re2j) 엔진으로 교체하고 대용량 메시지 유입에 대비한 입력 길이 상한선을 적용했습니다.

The Result

원문 저장 시점의 차단으로 다운스트림 유출 경로를 원천 차단했으며, ReDoS 테스트에서 기존 JDK 엔진 대비 지연 시간을 0.1ms 수준으로 대폭 낮춰 안전성을 확보하고 성능 영향 없이 엔터프라이즈 고객 유치를 원활하게 만들었습니다.

Trade-off

저장 단계에서 영구 마스킹 처리되므로 오탐으로 잘못 지워진 값은 원본 확인 및 복구가 불가능하며, 성능(지연 시간) 유지를 위해 대용량 메시지에는 마스킹 길이 제한을 적용함에 따라 일부 초대형 메시지의 우회 가능성이 존재합니다.

03

Key Concepts

Concept · 01

RE2 (re2j)

구글이 개발한 정규식 엔진으로, 백트래킹(Backtracking)을 사용하지 않는 결정적 유한 오토마타(DFA/NFA) 방식을 사용하여 입력 크기에 선형인 시간 복잡도를 보장하는 엔진입니다.

  • 기존 java.util.regex의 백트래킹으로 인한 지수적 시간 초과 문제를 방지하기 위해 도입
  • 악의적인 정규식 패턴(ReDoS) 테스트 환경에서 5초 이상 멈추던 연산을 0.1ms 수준의 일정한 속도로 처리 완료
Concept · 02

ReDoS (Regular Expression Denial of Service)

잘못 작성되거나 복잡한 정규식 패턴에 특정 문자열이 입력되었을 때, 백트래킹 조합 수가 지수적으로 증가하여 CPU 자원을 고갈시키고 시스템을 마비시키는 서비스 거부 공격 기법입니다.

  • 커스텀 정규식 등록 기능을 개방함에 따라 발생할 수 있는 보안 취약점이자 서버 정지 위험으로 지목됨
  • 백트래킹 없는 엔진 사용 및 문자열 입력 길이 상한 임계치를 통해 선제적으로 방어
Concept · 03

Luhn Algorithm (룬 알고리즘)

신용카드 번호나 식별 번호 등의 입력 오류를 감지하기 위해 널리 사용되는 체크섬 공식으로, 수식 연산을 통해 해당 숫자가 유효한 규칙성을 갖추고 있는지 검증합니다.

  • 단순 16자리 숫자 나열을 신용카드 번호로 무조건 오인하지 않도록 1차 패턴 매칭 후 2차 유효성 검증용으로 활용