운영계 DB 암호키를 데이터에서 분리해야 하는 이유

최근 한 운영계 데이터베이스에서 암호화 키 분리(암호키 분리) 작업을 준비하면서, 이번엔 한 발 물러서서 “왜 이런 걸 하는 걸까”를 처음부터 다시 정리해봤다. 결론은 한 문장으로 좁혀졌다. 데이터를 아무리 잘 암호화해도, 키가 데이터 옆에 있다면 그 암호화는 보안이 아니라 보여주기용에 가깝다는 것.

운영계 DB의 암호키 분리는 처음 보는 사람에게는 “열쇠를 어딘가 다른 데 보관하자”는 소박한 이야기처럼 들린다. 그런데 막상 설계하려고 보니 생각보다 신경 쓸 지점이 많았다. 이번 글은 그 과정에서 정리한 내용을 블로그에 남겨두고 싶었다.

암호화의 의미는 “키가 어디 있느냐”로 갈린다

DB 암호화를 도입했다고 해서 그 자체로 안전해지는 건 아니다. 암호화의 안전성을 결정하는 기준은 흔히 “데이터와 키를 분리해 관리하는가”다.

간단한 구축 사례에서 흔히 저지르는 실수가 있다. 암호화 키를 DB 서버 내부의 설정 파일이나 소스 코드에 그대로 넣어두는 것이다. 그 경우 공격자가 데이터베이스 파일(혹은 서버)을 통째로 탈취하면 데이터와 키를 한 번에 가져가게 된다. 암호화를 했는데 풀리는 키까지 같이 준 꼴이라, 사실상 암호화를 안 한 것과 다름없다.

따라서 키는 되도록 데이터와 물리적으로 분리된 별도의 위치(키 관리 서버, KMS 등)에서 관리한다. 보안 업계에서 “암호화 키 관리는 키의 수명주기를 따라 인가된 사람만 접근할 수 있도록 관리하는 기법”이라고 부르는 이유이기도 하다.

마스터키와 데이터키, 그리고 복잡해지는 복구 시나리오

운영계에서 키를 분리한다는 것은 단순히 “키 파일을 다른 폴더에 옮긴다”는 일이 아니다. 대부분 이중 구조로 설계한다.

• 데이터 암호화 키(DEK): 실제 데이터를 암호화/복호화하는 키
• 마스터 키(KEK): DEK를 다시 암호화해 보관하는 상위 키

DEK는 마스터 키로 감싸서 저장하고, 마스터 키를 별도의 안전한 위치에 보관한다. 이렇게 하면 키 하나가 유출돼도 바로 데이터가 노출되지는 않는다. 다만 그 대가로 키 관리가 시스템 하나를 운영하는 일이 된다. 키의 생성·교체·폐기라는 수명주기를 관리해야 하고, 백업과 복원 절차에도 키가 얽힌다.

여기서 가장 어려운 지점은 장애 상황이다. 운영계 DB 암호키 분리를 준비하면서 문득 떠오른 게, 약 3년 전에 내가 겪었던 오라클 시스템 장애 복기였다. 그때처럼 시스템이 멈추는 상황에서, “복원하려면 마스터 키가 필요한데 그 키를 어디에도 열어볼 수 없다면” 모두가 얼어붙는 시나리오가 성립한다. 키를 단단히 숨겨두기만 하면 되는 게 아니라, 정작 필요할 때 꺼내 쓸 수 있도록 키 백업·복구 절차까지 함께 설계해야 하는 이유다.

정리: “멈추지 않는다”가 아니라 “멈추면 복구 가능한가”를 묻자

암호키 분리 작업을 준비하며 내가 얻은 교훈은 이것이다. 운영계 보안 설계는 “시스템이 멈추지 않는다”를 전제로 하지 말고, “멈췄을 때 복구할 수 있는가”를 전제로 해야 한다는 것이다. 암호화 키를 데이터에서 분리하는 것도, 키를 안전하게 보관하는 것도, 결국 그 복구 가능성의 한 조각이다.

운영 중인 시스템은 언제든 멈출 수 있다. 그 전제 위에서라면, 키를 어디에 어떻게 두는지도 자연스럽게 설계 기준이 생긴다.

이 글은 업무에서 실제 검토 중인 설계 내용이 아닌, 공개 가능한 보안 원칙 수준에서 정리한 개인 기록입니다.