암호화된 녹취의 이관: AES로 암호화된 과거 녹취를 합법적으로 복호화하고 해방하는 방법

암호화된 녹취는 왜 "되찾을 수 없는 데이터"가 되는가

컴플라이언스와 프라이버시 요건을 충족하기 위해 컨택센터와 금융 거래 녹취는 보관 시 AES로 암호화하는 것이 일반적이며, 그 자체는 전적으로 옳은 판단입니다. 문제는 몇 년 뒤에 드러납니다. 플랫폼이 폐기되고, 벤더 지원이 종료되고, 당시 암호화를 설정한 담당자는 퇴사했으며, 키 저장소는 서버와 함께 철거됩니다. 녹취 파일은 모두 남아 있는데 아무도 열 수 없습니다. 장부상으로는 녹취를 "보관"했지만, 정작 조회·감사·소송에서 요구받았을 때 제출하지 못한다면 보관하지 않은 것과 같습니다.

녹취는 어떻게 암호화되는가: 세 가지 대표적 키 모델

첫째는 전역 고정 키입니다. 시스템 전체가 하나 또는 소수의 AES 키를 사용하며, 키는 설정 파일, 데이터베이스 또는 전용 키 저장소에 보관됩니다. 둘째는 엔벨로프 암호화입니다. 녹취마다 무작위로 생성한 AES 세션 키로 암호화하고, 그 세션 키를 다시 RSA 키 쌍(보통 인증서 형태로 배포)으로 감싸 파일과 함께 저장합니다. 복호화하려면 먼저 개인키로 세션 키를 풀어야 하며, Genesys Interaction Recording 등이 이 방식입니다. 셋째는 외부 위탁으로, 키를 KMS나 HSM에 두고 플랫폼이 인터페이스로 호출하며 키 자체는 디스크에 기록되지 않습니다. 세 모델은 이관 난이도가 완전히 다르므로, 첫 단계는 언제나 어느 쪽에 해당하는지 판별하는 것입니다.

이관을 가로막는 것은 알고리즘이 아니라 키 거버넌스

AES는 공개 표준이며 알고리즘 자체가 장애가 된 적은 없습니다. 프로젝트를 실제로 멈추게 하는 것은 키 쪽의 현실입니다. 키가 플랫폼과 함께 폐기되어 당시 키 저장소의 백업을 찾을 수 없거나, 인증서가 만료되었거나, 개인키 암호를 아무도 기억하지 못하거나, 수명 주기 중 키를 교체해 시기마다 다른 키가 필요하거나, 키 ID가 이미 중단된 인덱스 DB에 기록되어 있거나, HSM이 벤더에 반납되었거나 영구 삭제된 경우입니다. 따라서 암호화된 녹취의 이관 프로젝트를 평가할 때 가장 먼저 확인할 것은 녹취가 몇 테라바이트인지가 아니라, **키 자료가 남아 있는지, 그리고 전체 기간을 포괄하는지**입니다.

분명한 선: 저희가 하는 일은 복호화이지 해독이 아닙니다

저희는 고객의 서면 승인과, 고객이 제공하는 키 자료(키 저장소, 인증서와 개인키, KMS/HSM 접근 권한 등)를 전제로 고객 자신의 녹취를 복호화합니다. 암호를 우회하거나 해독하는 작업은 제공하지도, 수임하지도 않습니다. 그것은 불법이며, 올바르게 구현된 AES에 대해서는 기술적으로도 현실적이지 않기 때문입니다. 데이터와 키를 보유한 주체는 고객이며, 저희가 제공하는 것은 그 둘을 정확히 맞추어 사용 가능한 형식으로 대량 복원하는 엔지니어링 역량입니다.

기술적으로 반드시 처리해야 할 사항

1. 암호문 경계 파악: 파일 전체를 암호화하는 구현도 있고, 오디오 페이로드만 암호화하고 헤더와 메타데이터 영역은 평문으로 두는 구현도 있습니다. 이를 잘못 판단하면 첫 바이트부터 어긋납니다.
2. IV / nonce 찾기: 초기화 벡터는 파일 헤더, 각 세그먼트 앞, 또는 키 ID와 일련번호로부터 유도될 수 있습니다.
3. 압축과 암호화의 순서 판별: 압축 후 암호화인지, 암호화 후 압축인지. 순서가 뒤바뀌면 결과는 잡음이 됩니다.
4. 세그먼트 암호화 처리: 긴 통화는 블록마다 독립된 IV로 암호화되는 경우가 많아, 올바른 순서로 블록 단위 복원이 필요합니다.
5. 키 식별자 매핑: 어떤 파일을 어떤 키로 암호화했는지는 보통 헤더나 인덱스 DB에 기록되며, 특히 키를 교체한 환경에서는 정확한 대응이 필수입니다.
6. 복호화 정확성 검증: 결과물은 유효한 오디오 비트스트림이어야 하며, 타당한 길이·채널 구성·파형으로 디코딩되어야 합니다. "오류가 나지 않았다"는 것은 성공의 증거가 아닙니다.

표준 진행 절차

1. 키 자료 점검: 키 저장소 / 인증서 / 개인키 / KMS가 사용 가능한지, 녹취 전체 기간을 포괄하는지 확인합니다.
2. 샘플 시험 복호화: 실제 녹취를 소량 가져와 청취 가능한 WAV까지 종단 간으로 복호화하고, 키·컨테이너·코덱·채널·메타데이터가 모두 정확한지 확인합니다.
3. 규모와 방식 확정: 총 데이터량, 보관 위치, 온프레미스 수행 여부, 납품 형식을 정합니다.
4. 일괄 복호화 및 변환: 복호화 → 컨테이너 해체 → 올바른 코덱으로 표준 WAV 변환 → 이중 채널 분리와 통화 메타데이터 보존.
5. 무결성 검증: 배치별로 파일 수, 길이, 채널 수, 샘플링 레이트를 대조하고 검증 보고서를 작성합니다.
6. 납품과 재보호: 아카이브를 평문으로 둘지 재암호화할지 고객과 함께 결정합니다.

해방한 뒤 다시 암호화해야 하는가

대부분의 고객은 "해야 한다, 다만 방식을 바꾸어"라고 답합니다. 과거 녹취가 갇힌 원인은 암호화 자체가 아니라, 키가 언젠가 수명을 다할 독자 플랫폼에 묶여 있었다는 점입니다. 이관 후 권장하는 형태는 오디오를 개방 형식(WAV)으로 보관하고, 암호화는 벤더 비종속 방식으로 바꾸는 것입니다. 스토리지 계층 암호화 또는 고객이 직접 관리하는 키를 사용하는 엔벨로프 암호화를 적용하고, 키는 고객 자신의 KMS/HSM에 보관하며 감사 가능한 키 백업과 교체 절차를 갖춥니다. 이렇게 하면 컴플라이언스를 충족하면서도 10년 뒤 같은 문제를 반복하지 않습니다. 전 과정은 고객 구내에서 수행할 수 있으며, 녹취 데이터가 네트워크 경계를 벗어나지 않습니다.

시작하는 방법

샘플 시험 복호화부터 시작하십시오. 기존 플랫폼과 버전, 알고 계신다면 암호화 방식, 키 자료가 현재 어디에 있는지를 알려주시고, 비식별화 가능한 샘플 파일과 해당 키를 제공해 주십시오. 며칠 내로 청취 가능한 복호화 결과와 기술 설명서를 회신드립니다. 프로젝트 전체의 실현 가능성을 판단하는 가장 빠르고 확실한 첫걸음입니다.