AWS KMS 알아보기

Key Management Service

암호화에는 반드시 키가 필요합니다. 그런데 이 키를 어디에 보관하고 계신가요?

소스코드에 하드코딩하거나 서버 파일 시스템에 저장하는 방법은 간단하지만, 서버가 뚫리는 순간 키도 함께 유출됩니다. 암호화를 아무리 잘 해두었어도 키가 유출되면 아무 의미가 없습니다. 결국 "키를 안전하게 보관하는 것" 자체가 하나의 문제가 됩니다.

AWS Key Management Service(KMS)는 이 문제를 해결하기 위한 서비스입니다. 키 자체를 AWS의 전용 하드웨어 보안 모듈(HSM)에 보관하고, 필요할 때만 암호화/복호화 요청을 보내는 방식으로 동작합니다. KMS의 HSM은 FIPS 140-3 Level 3 인증을 받은 장비이며, KMS 키의 원본 키 재료(key material)는 이 HSM 밖으로 절대 나가지 않습니다.

봉투 암호화

KMS의 핵심 아이디어는 "키로 키를 감싸는" 봉투 암호화(Envelope Encryption)입니다.

KMS 키(마스터 키)로 직접 데이터를 암호화하는 것이 아니라, 데이터 키를 별도로 생성한 뒤 그 데이터 키로 실제 데이터를 암호화하고, 데이터 키 자체는 KMS 키로 암호화하여 보관하는 구조입니다. 이름 그대로, 봉투 안에 봉투가 들어있는 셈입니다.

암호화 과정

1. KMS에 GenerateDataKey를 요청하면, KMS는 평문 데이터 키와 암호화된 데이터 키 두 가지를 반환합니다.

2. 애플리케이션은 평문 데이터 키로 데이터를 암호화합니다.

3. 암호화가 끝나면 평문 데이터 키를 메모리에서 즉시 삭제합니다.

4. 이후에는 암호화된 데이터 키와 암호화된 데이터만 저장합니다.

복호화 과정

1. 저장해둔 암호화된 데이터 키를 KMS에 보냅니다.

2. KMS가 이를 복호화하여 평문 데이터 키를 반환합니다.

3. 이 평문 데이터 키로 데이터를 복호화합니다.

4. 복호화가 끝나면 다시 평문 데이터 키를 삭제합니다.

async function decryptFile(inputPath, outputPath) {
  const data = fs.readFileSync(inputPath);

  // 1. 저장된 파일에서 암호화된 데이터 키, IV, 암호문 분리
  const encryptedDataKey = data.subarray(0, 184);   // CiphertextBlob 길이
  const iv = data.subarray(184, 200);
  const encrypted = data.subarray(200);

  // 2. KMS에 암호화된 데이터 키의 복호화 요청
  const { Plaintext } = await kms.decrypt({
    CiphertextBlob: encryptedDataKey,
  }).promise();

  // 3. 복호화된 데이터 키로 파일 복호화
  const decipher = crypto.createDecipheriv('aes-256-cbc', Plaintext, iv);
  const decrypted = Buffer.concat([decipher.update(encrypted), decipher.final()]);

  // 4. 평문 데이터 키 메모리에서 제거
  Plaintext.fill(0);

  fs.writeFileSync(outputPath, decrypted);
}

이 구조에서 애플리케이션은 마스터 키의 원본을 전혀 알 수 없습니다. KMS에는 데이터 키의 생성과 복호화 요청만 보낼 뿐, 실제 데이터의 암복호화는 로컬에서 수행됩니다.

따라서 서버가 해킹되어 암호화된 데이터 키와 암호화된 데이터가 모두 유출되더라도, KMS 키에 대한 IAM 권한이 없으면 복호화가 불가능합니다.

KMS 키의 종류

KMS 키는 관리 주체에 따라 세 가지로 나뉩니다. 이들은 제어 수준이 높을수록 높은 비용이 발생하고, 편의성이 높을수록 제어 범위가 줄어드는 트레이드오프를 갖습니다.

고객 관리형 키 (Customer Managed Key)

사용자가 직접 생성하고 관리하는 키입니다. 키 정책, IAM 정책, 권한 부여(Grant) 등을 통해 완전한 제어가 가능하며, 활성화/비활성화, 자동 회전 설정, 삭제 예약 등을 할 수 있습니다. CloudTrail을 통한 사용 감사도 가능합니다. 월별 요금과 사용량 기반 요금이 발생합니다.

AWS 관리형 키 (AWS Managed Key)

AWS 서비스가 사용자 계정에 자동으로 생성하는 키입니다. `alias/aws/s3`, `alias/aws/ebs`와 같이 `aws/` 접두사가 붙은 별칭을 가집니다. 속성 변경이 불가능하고, 해당 AWS 서비스의 컨텍스트에서만 사용할 수 있습니다. 연 1회 자동 회전이 필수이며, 월별 요금은 없고 사용 요금만 발생합니다.

AWS 소유 키 (AWS Owned Key)

AWS 서비스가 내부적으로 소유하고 관리하는 다중 계정용 키입니다. 사용자 계정에 존재하지 않으며, 메타데이터 조회나 감사가 불가능합니다. 완전 무료이며 별도의 설정 없이 기본적으로 사용됩니다.

저장 데이터 암호화 (Encryption at Rest)

S3나 RDS 같은 서비스에서 KMS를 통한 암호화는 저장 데이터 암호화(Encryption at Rest), 즉 스토리지 레벨의 암호화를 의미합니다. 데이터가 디스크에 쓰여지는 시점에 암호화되고, 읽을 때 자동으로 복호화됩니다. 애플리케이션 입장에서는 투명(transparent)하게 동작하여 별도의 암호화 코드가 필요 없습니다.

S3의 경우

객체를 업로드하면 S3가 내부적으로 KMS에 데이터 키를 요청하여 암호화하고, 다운로드할 때는 KMS에 복호화를 요청하여 평문 데이터를 반환합니다. 암호화된 데이터 키는 S3 객체의 메타데이터에 함께 저장되므로, 다운로드 시 S3가 이를 꺼내어 KMS에 복호화를 요청하는 과정이 자동으로 이루어집니다.

RDS의 경우

KMS 암호화를 활성화하면 DB 인스턴스의 EBS 볼륨, 자동 백업, 스냅샷, Read Replica, 로그가 모두 디스크 레벨에서 암호화됩니다. DB 엔진 내부의 쿼리 결과나 메모리 상의 데이터가 암호화되는 것이 아니라, 물리적 스토리지에 기록되는 데이터가 암호화되는 것입니다.

한 가지 주의할 점은, RDS 인스턴스에 적용된 KMS 키는 직접 변경할 수 없다는 것입니다. 변경이 필요한 경우 스냅샷을 생성한 뒤 새 KMS 키로 복사하고, 해당 스냅샷에서 새 인스턴스를 복원하는 방식을 사용해야 합니다.

방어 범위

이러한 저장 데이터 암호화는 디스크 탈취, EBS 스냅샷 유출 등 물리적 접근 위협으로부터 데이터를 보호합니다. 다만 다음과 같은 위협은 방어 범위에 포함되지 않습니다.

- IAM 권한이 있는 사용자의 정상적인 데이터 조회

- SQL Injection 같은 애플리케이션 레벨 공격

- 네트워크 도청 (이는 TLS가 담당)

저장 데이터 암호화만으로 모든 보안 위협이 해결되는 것이 아니라는 점을 인식하는 것이 중요합니다.

CloudTrail을 통한 감사

CloudTrail은 AWS 계정 생성 시 자동으로 활성화되며, KMS에 대한 관리 이벤트(CreateKey, ScheduleKeyDeletion 등)는 별도 설정 없이 기본적으로 90일간 기록됩니다. AWS 콘솔의 CloudTrail 이벤트 기록에서 이벤트 소스를 `kms.amazonaws.com`으로 필터링하면 조회할 수 있습니다.

다만 Encrypt, Decrypt , GenerateDataKey같은 데이터 이벤트는 기본적으로 콘솔의 이벤트 기록에 표시되지 않습니다. S3 다운로드마다 Decrypt가 호출되는 것처럼, 이런 작업은 빈도가 매우 높을 수 있기 때문입니다. 데이터 이벤트까지 기록하려면 CloudTrail 추적을 별도로 생성하고 KMS 데이터 이벤트 로깅을 활성화해야 합니다. 이 경우 S3 저장 비용과 CloudTrail 데이터 이벤트 요금이 추가로 발생합니다.

키 자동 회전

KMS 키의 자동 회전은 암호화 알고리즘을 바꾸는 것이 아니라, 키 재료만 새 것으로 교체하는 것입니다.

키 ID는 그대로 유지되며, 새로 암호화할 때는 최신 키 재료를 사용하고, 기존 데이터를 복호화할 때는 해당 데이터를 암호화했던 시점의 키 재료를 KMS가 자동으로 선택합니다. 따라서 자동 회전을 활성화하더라도 애플리케이션 코드를 변경할 필요가 없습니다.

"키가 회전되면 과거 데이터를 못 읽는 거 아닌가?"라는 걱정은 하지 않아도 됩니다. KMS가 과거 키 재료를 모두 보관하고 있으며, 복호화 시 어떤 키 재료를 사용해야 하는지를 자동으로 판단합니다.