DATA LIFECYCLE / PRACTICAL DESIGN

저장부터 삭제까지,
데이터가 가는 곳을 관리하세요.

암호화한 주소가 평문 로그나 검색 인덱스에 남으면 어떨까요? 삭제한 데이터가 백업에서 되살아나면요? 보호는 금고 밖까지 이어져야 합니다.

업무 기록과 개인정보를 분리하세요.

판매 업무에서는 대리 ID, 주문, 상품, 배송 상태를 업무 시스템에 둡니다. 이름, 주소, 전화번호는 금고에 저장합니다. 허용된 배송 흐름은 필요한 항목만 조회합니다.

주문 시스템: 주문 ID / 대리 ID / 상품 / 배송 상태
데이터 금고: 대리 ID에 연결된 암호화 이름, 주소, 전화번호
배송: 허용 기간에 필요한 필드만 조회

분리 저장은 주문 DB 탈취 시 주소의 직접 노출을 줄입니다. 다만 주문 이력과 대리 ID도 다른 정보와 결합하면 개인을 식별할 수 있습니다. 대리 ID가 익명성을 보장하지는 않습니다.

이 절의 검색 인덱스·파트너 삭제 알림·복구 불가능한 키 삭제는 설계 예시입니다. 현재 주소 API는 검색, 자동 파트너 삭제 알림, 백업 즉시 물리 삭제를 제공하지 않습니다. 실제 범위는 도입 가이드에서 확인하세요. 사용 및 도입 가이드

무작위 nonce를 사용하면 같은 이메일도 다른 암호문이 되어 일반적인 완전 일치 검색이 불가능합니다. 대리 ID나 주문 ID를 우선 사용하세요. 개인정보 매칭이 필요하면 별도 검색 인덱스를 설계합니다.

정해진 규칙으로 이메일을 정규화하고 테넌트·필드별 검색 키로 HMAC을 계산합니다. 조회 시 같은 계산을 수행하고 권한 확인 후 원본을 검증합니다. 인덱스 값은 매칭용이며 복호화 가능한 암호문이 아닙니다.

일반 해시는 후보 이메일이나 전화번호를 추측할 수 있습니다. HMAC도 키가 탈취되면 추측이 가능합니다. 반복 값과 빈도는 드러납니다. 검색 API의 대량 질의를 제한하세요.

부분 문자열, 접두사, 범위 검색은 추가 정보를 노출하고 처리 비용을 늘릴 수 있습니다. 기능, 정보 누출, 성능을 함께 평가하세요. 검색 키를 교체할 때는 인덱스도 다시 만들어야 합니다.

화면에서 지우는 것만으로는 부족합니다. 조회를 차단한 뒤 원본, 인덱스, 캐시, 복제본, 파트너 데이터를 처리합니다. 백업 보유 기간과 복구 동작도 기록합니다.

암호학적 삭제는 필요한 키를 복구 불가능하게 만듭니다. 전용 키와 함께 백업, 래핑된 키, 캐시, 복구 가능한 서비스 복사본을 제거해야 합니다. 공유 키를 파기하면 다른 사용자에게도 영향을 줍니다.

되돌릴 수 있는 키 비활성화는 영구 삭제가 아닙니다. 이미 조회된 평문이나 다른 키로 암호화된 복사본도 지우지 못합니다. 접근 차단, 활성 데이터 삭제, 백업 만료를 별도로 추적합니다.

어제의 백업을 복구하면 오늘 삭제한 주소가 돌아올 수 있습니다. 격리 환경에서 복구하고 삭제 기록과 현재 권한 취소를 다시 적용한 뒤 검증하고 접근을 재개합니다. 삭제 기록을 그 오래된 백업에만 보관해서는 안 됩니다.

RPO: 허용 가능한 데이터 손실 시간: 15분 목표라면 최근 업데이트가 최대 15분까지 손실될 수 있다는 뜻입니다. 실제 복제, 백업, 테스트 결과를 확인하세요.
RTO: 서비스 복구 시간: 2시간 목표에는 DB 복구뿐 아니라 키, 권한, 삭제 재적용, 검증이 포함됩니다. 이 수치는 예시이며 서비스 보장이 아닙니다.
복구 점검: 유효한 데이터의 복호화, 삭제 데이터의 조회 차단, 오래된 토큰 거부, 키 장애 시 정보 노출 없는 처리 중단을 확인합니다.
감사 증거: 행위자, 대상 참조, 시간, 결과, 키 버전을 기록합니다. 개인정보나 원본 토큰을 로그에 복사하지 않습니다.

데이터 위치, 복호화 권한, 검색 시 정보 노출, 삭제 상태, 복구 시험 결과를 검토하여 저장·이용·폐기 전반의 보호를 평가합니다.