Skip to content

BYOK — AWS KMS와 고객 관리 키

BYOK의 아이디어는 "암호화 열쇠를 고객이 직접 관리한다"는 거예요. 그런데 열쇠를 어디에 두고 어떻게 회전·폐기할지, 열쇠만으론 부족해요. 실제로는 KMS(키 관리 서비스)가 그 열쇠의 수명을 안전하게 지켜줘요. AWS를 쓰는 환경이라면 AWS KMS가 그 역할을 맡는 대표적인 선택지입니다.

개요

AWS KMS는 암호화 키를 만들고, 저장하고, 쓰는 사람을 통제하고, 회전·폐기까지 관리하는 서비스예요. 핵심은 키를 AWS가 소유한 안전한 경계 안에서 떠나지 않게 하고, 우리는 "이 키로 이 데이터를 암호화/복호화해줘"라는 요청만 보낸다는 구조예요. 키 원문이 우리 애플리케이션 밖으로 나가지 않는 겁니다.

핵심 개념

고객 관리 키(CMK, Customer Master Key). AWS KMS에서는 키를 관리하는 단위를 KMS key라고 불러요. 이 키가 데이터 키를 감싸고(암호화), 쓰기·읽기 권한(IAM 정책)으로 통제돼요. BYOK 관점에서 이 키를 우리가 만드는 게 아니라 고객이 갖고 오거나 관리하게 만들 수 있어요.

고객 제공 키(bring your own key) vs 고객 관리 키. AWS KMS에는 두 가지 방향이 있어요. 하나는 고객이 자신의 키를 만들어 KMS에 가져오는 것(import), 다른 하나는 키 자체는 고객 계정의 KMS에 두고 우리가 그 키로 연산을 요청하는 방식이에요. 후자가 BYOK의 실질적 형태로, 키는 고객 계정에 남고 우리는 사용 요청만 보내죠.

키 정책으로 누가 쓸 수 있는지 통제해요. KMS 키에는 키 정책(key policy)이 붙어서, 그 키를 누가 마음대로 쓸 수 있는지를 정해요. 여기에 IAM 사용 조건을 함께 걸면 "이 역할만 이 키로 암호화할 수 있다"처럼 범위를 좁힐 수 있어요. BYOK에서 고객이 "우리(서비스 제공자)는 이 키를 이 연산에만 쓰게 하라"고 정책을 박아두면, 우리가 그 키로 마음대로 뭘 하지 못하게 되는 거죠.

키를 누가 만들어도 "연산은 KMS 안에서". 키를 우리가 만들었든 고객이 가져왔든, KMS 키를 이용한 암호화·복호화·서명은 전부 KMS 하드웨어 경계 안에서 일어나요. 그래서 키 원문이 애플리케이션 메모리나 로그, 디스크로 새어 나가는 경로 자체를 원천 차단합니다.

키 연산은 밖으로 나가지 않아요. KMS에 암호화 요청을 보내면, 데이터 키(또는 데이터)는 KMS 안에서 처리되고 키 원문은 절대 응답에 실려 나오지 않아요. 이렇게 "키를 손에 쥐지 않고도 암호화 연산은 쓸 수 있는" 안전 경계가 KMS의 핵심 가치예요.

Envelope encryption을 지원해요. 큰 데이터 전체를 KMS 키로 직접 암호화하면 느리고 비싸요. 그래서 실제 데이터는 임시 데이터 키로 암호화하고, 그 데이터 키를 KMS 키로 감싸는 구조를 써요. KMS는 이 "키를 감싸는 키" 구조(GenerateDataKey)를 지원해 성능과 보안을 함께 잡아요.

키 폐기 시 깊이 생각해요. KMS 키를 삭제하면(또는 고객이 키를 지우면) 그 키로 암호화된 데이터는 영구히 읽을 수 없게 돼요. 그래서 AWS KMS는 키 삭제에 유예 기간(기본 7일)을 두고 그 사이에 되돌릴 수 있게 해요.

실제 적용(데이터스케쳐스)

BYOK + On-premise를 선택한 고객에게는, 데이터는 고객 쪽에 두고 열쇠도 고객 키로 관리하는 배포를 염두에 둬요. 클라우드 환경(AWS)에서는 고객 계정의 KMS 키로 감싸는 방식(envelope encryption)을 쓰고, 우리 백엔드는 그 키로 연산을 요청하되 키 원문은 다루지 않도록 설계해요.

설계 시 챙길 지점은 키 회전(주기적으로 감싸는 키를 바꾸기), 키 폐기(고객이 키를 지우면 그 키로 암호화된 데이터는 읽을 수 없게 됨), 감사 로그(누가 언제 그 키를 사용했는지 CloudTrail)예요. 키를 잃으면 복호화할 방법이 없으니, 책임 경계를 계약(DPA)으로도 명확히 해둬야 해요.

더 알아보기