LINE, Kafka 종단 간 암호화로 데이터 보안 강화
LINE 메신저의 민감 데이터 보호를 위해 Kafka 클라이언트 간 종단 간 암호화(End-to-End Encryption) 도입 결정
기존 Kafka 보안 모델의 한계 극복을 위해 데이터 자체 보호 계층 추가 및 '심층 방어(Defence in Depth)' 전략 채택
DEK-KEK 이중 키 구조와 레코드 단위 암호화를 통해 성능 최적화 및 확장성 확보
평문 폴백(Plaintext Fallback) 및 점진적 배포로 무중단 마이그레이션 성공
Kafka 종단 간 암호화(E2EE)의 필요성
LINE 메신저는 매일 수십억 건의 메시지를 처리하며, 이 중에는 개인 정보와 같은 민감 데이터가 포함됩니다. 기존 Kafka의 전송 구간 암호화(TLS/SSL), 인증(Authentication), 인가(Authorization) 기능은 통신 채널과 접근 권한을 보호하지만, 브로커에 저장된 데이터 자체는 평문으로 존재합니다. 따라서 데이터 자체를 암호화하는 심층 방어(Defence in Depth) 전략의 일환으로, 프로듀서에서 컨슈머까지 데이터 페이로드를 암호화 상태로 유지하는 종단 간 암호화(End-to-End Encryption) 도입이 결정되었습니다. 이는 데이터 기밀성(Data Confidentiality)을 원천적으로 확보하기 위한 조치입니다.
DEK-KEK 이중 키 구조와 레코드 단위 암호화
메시지 페이로드 암호화에는 AES 대칭 키(DEK)를 사용하고, DEK 관리를 위해 ECC 비대칭 키(KEK)를 사용하는 DEK-KEK 구조를 채택했습니다. 대칭 키는 빠른 연산 속도로 대규모 트래픽 환경에서의 성능 최적화를 가능하게 하며, 비대칭 키는 키 관리의 유연성과 암호화/복호화 권한 분리를 제공합니다. 또한, Kafka의 표준 확장 포인트인 인터셉터(Interceptor)를 활용하기 위해 레코드 단위 암호화 방식을 선택하여, 기존 클라이언트 코드 수정 없이 안정적인 암호화 로직 적용이 가능했습니다. 이 구조는 컨슈머 수 증가에도 메시지 크기를 일정하게 유지하는 장점이 있습니다.
무중단 마이그레이션을 위한 평문 폴백(Plaintext Fallback)
암호화 도입 시 발생할 수 있는 데이터 유실 및 서비스 중단 리스크를 최소화하기 위해 평문 폴백(Plaintext Fallback) 전략을 구현했습니다. 컨슈머 디시리얼라이저(Deserializer)는 메시지 헤더의 메타데이터 유무를 감지하여 암호화 메시지와 평문 메시지를 구분 처리합니다. 이를 통해 컨슈머를 먼저 배포하여 안전성을 확보한 후, 프로듀서의 암호화 기능을 점진적으로 활성화하는 안정적인 마이그레이션 절차를 수행할 수 있었습니다. 동적 설정 기반의 점진적 배포를 통해 암호화 비율을 단계적으로 높이며 실시간 지표를 모니터링하여 위험을 관리했습니다.
공유 KEK(Shared KEK)를 통한 메시지 크기 최적화
다수의 컨슈머가 존재하는 Kafka 토픽에서 컨슈머별 고유 키를 사용하면 메시지 헤더 크기가 비례적으로 증가하여 성능 저하를 유발합니다. 이를 해결하기 위해 하나의 KEK를 여러 컨슈머가 공유하는 방식을 채택했습니다. 이로써 컨슈머 수와 무관하게 헤더 크기를 일정하게 유지할 수 있었으며, 이는 초당 100만 건 트래픽 환경에서 시스템 자원 소모량 급증을 방지하는 핵심 요인이 되었습니다. 다만, 공유 KEK의 보안 위험을 완화하기 위해 KMS 인가와 주기적인 키 교체 메커니즘을 함께 운영합니다.
무중단 키 교체 메커니즘
공유 KEK 구조의 보안 강화를 위해 주기적인 키 교체를 무중단으로 수행하는 메커니즘을 구현했습니다. 프로듀서와 컨슈머는 KMS를 주기적으로 폴링하여 신규 KEK를 감지합니다. 전환 기간 동안에는 기존 키와 신규 키가 공존하며, 프로듀서는 모든 등록된 공개 키로 DEK를 암호화하고 컨슈머는 자신의 비공개 키와 일치하는 항목을 선택해 복호화합니다. 이 과정을 통해 서비스 중단 없이 안전하게 키를 교체하고 보안 수준을 지속적으로 유지할 수 있습니다.
성능 테스트 결과 및 프로덕션 배포
실제 프로덕션 환경과 동일한 조건에서 진행된 벤치마크 테스트 결과, Kafka 종단 간 암호화 도입 후 CPU 사용량 증가는 프로듀서와 컨슈머 모두에서 1% 미만으로 나타났습니다. 이는 암호화 오버헤드가 매우 낮아 서버 증설 없이도 시스템 확장이 가능함을 의미합니다. 이러한 성능 검증을 바탕으로 약 2주간 점진적으로 암호화 비율을 100%까지 높였으며, 배포 기간 동안 암호화 관련 장애 알림은 단 한 건도 발생하지 않아 성공적인 적용을 완료했습니다.