작업 완료 · 2024
바이너리 로그 스크램블링
전달 파일이 그대로 읽히지 않도록 binlog 헤더에 난독화를 적용한 초기 보호 단계입니다.
기간2024
소속래브라도랩스(LabradorLabs)
역할데이터 엔지니어
Binary LogReplication스크램블링
작업 요약
난독화 적용 · 후속 정식 암호화와 구분
동기화 파일에 난독화를 먼저 적용했습니다
스크램블링은 완성된 보안 설계라기보다, 고객사로 나가는 변경 로그가 그대로 노출되는 위험을 먼저 줄인 단계였습니다. 운영 중인 동기화 경로를 크게 바꾸지 않고 적용할 수 있는 방법을 택했습니다.
이후 정식 암호화로 전환했습니다. 이 페이지는 그 이전의 난독화 적용 단계를 다룹니다.
배경
제품 데이터는 primary → replica(분산) → 고객사 on-premise 로 바이너리 로그 기반 동기화로 전파됩니다. 바이너리 로그는 모든 데이터 변경을 담는 매개체라, 전송 중 내용이 그대로 노출되는 것을 막을 필요가 있었습니다.
한 일
- 전송되는 바이너리 로그를 스크램블링해 동기화 중 로그 내용이 평문으로 읽히지 않도록 1차 보호 적용
- primary → replica → 고객사 전송 경로 전반에서 스크램블된 로그가 정상 복원·반영되도록 동기화 파이프라인 검증
- 기존 동기화와 호환되도록 무중단으로 적용
결과
파일 난독화동기화 경로에서 바이너리 로그가 그대로 읽히지 않도록 난독화 적용
고객사 요구 대응엔터프라이즈 환경의 데이터 보호 요구에 1차 대응
후속 암호화 전환이후 바이너리 로그 기반 데이터 동기화 체계에서 정식 암호화로 발전
역할
데이터 엔지니어로서 스크램블링 적용과 동기화 경로 복원 검증을 단독으로 수행했습니다. 운영·고객사 환경 모두에 영향을 주는 변경이라 호환성과 무중단 적용을 우선했습니다.
같은 해 MySQL 8.0→8.4 LTS 업그레이드, DB 아키텍처 인스턴스 분리와 함께 진행한 DB 플랫폼 개선 작업의 일부. 전송 데이터의 정식 암호화는 후속 데이터 동기화 개선에서 별도로 도입.
바이너리 로그 동기화 시리즈 ① — 이어지는 작업: ② 모니터링·로그 수집기 · ③ 암호화 전환 · ④ 고객사 동기화 모니터링 v2