사내에서 사용하고 있는 KMS(Key Management System)의 EOS(End of Support)가 가까워지면서 KMS 대체 시스템 도입을 고민하고 있습니다.

암호화 키뿐만 아니라 시크릿(Secret) 정보의 관리와 접근 통제 체계까지 함께 강화할 수 있는 방법을 찾는 것이 최종 목표입니다. 특정 업체에 기술적으로 종속되지 않으면서 비용 부담을 줄일 수 있는 대안을 찾고 있었고, 무료로 사용할 수 있는 소스 공개 기반 소프트웨어도 함께 검토해보기로 했습니다.

고민하는 과정에서 우연히 HashiCorp Vault를 알게 되었습니다.

HashiCorp Vault

Vault는 시크릿 관리, PKI, 동적 자격 증명, 암호화 서비스 등 다양한 기능을 제공하는 통합 보안 플랫폼입니다.

처음 접했을 때는 어렵고 복잡하게 느껴졌지만, KMS를 대체할 수 있는 가능성이 있는지 더 자세히 알아보기로 했습니다.

1. KMS(Key Management System)와 Vault의 차이

처음에는 막연하게 “Vault를 이용하면 KMS를 대체할 수 있지 않을까?”라는 생각을 가지고 접근했습니다.

하지만 KMS와 Vault는 관리 대상과 제공하는 기능에 차이가 있었습니다.

1.1. KMS

KMS는 암호화에 사용되는 키를 생성하고 안전하게 보관하며 관리하는 시스템입니다.

암호화 키가 유출될 경우 암호화된 데이터도 함께 노출될 수 있기 때문에, 키는 데이터와 분리하여 별도로 관리하는 것이 중요합니다.

애플리케이션에서 암호화 키를 직접 보관할 경우 유출 위험이 있습니다. 그래서 키는 애플리케이션과 분리된 KMS와 같은 외부 시스템에 보관하는 방식이 권장됩니다.

특히 최근에는 애플리케이션 내부에서 직접 암호화 연산을 수행하지 않고, KMS를 통해 암·복호화를 수행하는 방식(암호화 연산 외부화)도 널리 사용되고 있습니다.

일반적으로 KMS는 다음과 같은 기능을 제공합니다.

KMS의 주요 기능

  • 암호화 키 생성 및 저장
  • 암·복호화 기능 제공(암호화 연산 외부화)
  • 키 접근 제어
  • 키 회전(Key Rotation)

KMS의 핵심 역할은 암호화 키를 안전하게 생성·보관·통제하는 것입니다.

1.2. Vault

Vault를 활용하면 KMS와 비슷한 방식으로 암호화 키를 관리할 수 있습니다. 하지만 Vault는 암호화 키뿐만 아니라 더 넓은 범위의 시크릿을 관리하기 위한 보안 기능을 제공합니다.

시크릿은 외부에 노출될 경우 보안 사고로 이어질 수 있기 때문에 안전하게 관리하고 통제할 필요가 있습니다.

아래와 같은 민감 정보들이 시크릿에 해당됩니다.

  • 암호화 키
  • API Key
  • DB 계정 정보
  • 토큰(Token)
  • 인증서(Certificate)

즉, KMS가 암호화 키 관리에 초점을 맞춘 시스템이라면 Vault는 암호화 키를 포함한 다양한 시크릿을 통합적으로 관리하기 위한 플랫폼이라고 볼 수 있습니다.

Vault의 주요 기능

  • 암호화 키 및 다양한 시크릿 관리
  • 동적 시크릿 생성 및 자동 폐기
  • 접근 제어 및 인증

Vault의 핵심 역할은 암호화 키를 포함한 다양한 시크릿을 하나의 플랫폼에서 통합적으로 관리하는 것입니다.

1.3. KMS vs Vault 비교

구분 KMS Vault
주요 목적 암호화 키 생명주기 관리 시크릿과 암호화 기능 통합 관리
관리 대상 주로 암호화 키 암호화 키, API Key, 계정, 토큰, 인증서 등
암·복호화 기능 제품에 따라 제공 Transit Secrets Engine으로 제공
접근 제어 키와 암호화 기능 중심 인증 방식과 정책을 이용한 경로 기반 제어
기능 범위 암호화 키 관리 중심 다양한 시크릿 및 보안 기능으로 확장 가능
구성 범위 제품과 사용 방식에 따라 다름 활용 기능이 많을수록 구성이 복잡해질 수 있음
적합한 용도 암호화 키의 생성·보관·통제 시크릿 관리와 암호화 기능의 통합 운영

👉 KMS → 암호화 키를 안전하게 관리하기 위한 시스템

👉 Vault → 암호화 키를 포함한 다양한 시크릿을 통합적으로 관리하기 위한 플랫폼

비교해보면 Vault는 단순히 KMS를 대체하기 위한 도구라기보다는 통합 보안 플랫폼에 가깝습니다.

Vault의 시크릿 관리 기능과 암·복호화 기능을 활용해 현재 사용 중인 KMS의 역할을 어느 수준까지 대체할 수 있을지 더 자세히 살펴보기로 했습니다.

2. HashiCorp Vault 설치와 실행

지금까지 Vault와 KMS와의 차이를 개념적으로 살펴봤습니다. 이제 직접 설치해서 동작 방식을 확인해보도록 하겠습니다.

아직 Vault에 대해서 깊이 있는 학습이 되어 있는 상태는 아니었습니다. 그래서 우선 가장 간단하게 테스트해볼 수 있도록 개발 모드(dev mode)로 Vault를 실행했습니다.

2.1. Vault 이미지 준비와 컨테이너 실행

아래 명령으로 최신 HashiCorp Vault의 Docker 이미지를 가져왔습니다.

$ sudo docker pull hashicorp/vault:latest

그리고 복잡한 초기 설정을 생략하고 바로 테스트가 가능하도록 개발 모드로 구성해서 컨테이너를 실행했습니다.

$ sudo docker run --cap-add=IPC_LOCK -d \
> -p 8200:8200 \
> --name vault \
> -e "VAULT_DEV_ROOT_TOKEN_ID=root" \
> -e "VAULT_DEV_LISTEN_ADDRESS=0.0.0.0:8200" \
> hashicorp/vault

아래는 컨테이너 실행에 사용한 주요 옵션에 대한 설명입니다.

  • --cap-add=IPC_LOCK: Vault는 메모리에 저장된 민감한 정보가 디스크로 스왑되는 것을 방지하기 위해 메모리를 잠그는 기능(mlock)을 제공합니다. 이 기능을 사용할 수 있도록 권한을 부여하는 설정입니다. 실습 환경에서는 필수는 아니지만 운영 환경에서는 보안 강화를 위해 사용하는 것이 권장됩니다.

  • -e VAULT_DEV_ROOT_TOKEN_ID=root: Vault의 dev 개발 모드에서는 root 토큰이 자동으로 생성됩니다. 해당 root 토큰 값을 환경변수에 직접 지정하는 옵션입니다. 이 설정을 사용하면 로그인 시 사용할 토큰을 미리 알고 있기 때문에 실습이 훨씬 간편해집니다.

  • -e VAULT_DEV_LISTEN_ADDRESS=0.0.0.0:8200: Vault 서버가 어떤 주소와 포트에서 요청을 받을지 지정하는 설정입니다. (0.0.0.0 → 모든 네트워크 인터페이스에서 접근 가능, 8200 → Vault 기본 포트)

2.2. 개발 모드(dev mode)

개발 모드는 Vault를 빠르게 테스트할 수 있도록 제공되며, 다음과 같은 특징이 있습니다.

  • 초기화(init) 과정 없이 바로 사용 가능
  • 자동으로 root 토큰 생성
  • 데이터가 메모리에 저장됨 (재시작 시 초기화)
  • TLS 없이 HTTP로 동작

즉, 실습과 테스트를 위한 간편 실행 모드입니다.

HashiCorp Vault의 공식 Docker 이미지는 별도의 실행 명령을 지정하지 않으면 메모리 기반의 개발 모드로 실행됩니다. 개발 모드는 테스트를 위한 실행 방식이므로 운영 환경에서는 반드시 서버 모드(server mode)로 실행해야 합니다.

개발 모드와 서버 모드의 차이는 다음과 같습니다.

항목 개발 모드 서버 모드
초기화(init) 실행 시 자동 처리 관리자가 직접 수행
Seal 해제 Unsealed 상태로 시작 시작 또는 재시작 후 필요
저장소 메모리 Integrated Storage 또는 외부 스토리지
데이터 유지 재시작 시 삭제 영구 저장 가능
TLS 기본적으로 비활성화 운영 환경에서 사용 권장
용도 개발 및 기능 실습 운영 환경

2.3. Vault 상태 확인

Vault는 CLI를 통해 동작 상태를 확인하거나 설정 작업을 수행할 수 있습니다. 하지만 Docker로 실행한 경우에는 호스트 환경에는 Vault CLI가 존재하지 않습니다.

그래서 아래 명령으로 컨테이너 내부에 접속해서 CLI를 사용했습니다.

$ sudo docker exec -it vault sh

Vault의 동작 상태를 확인하는 CLI 명령은 다음과 같습니다.

/ # vault status

하지만 CLI 명령을 실행하면 아래와 같은 오류가 발생했습니다.

WARNING! VAULT_ADDR and -address unset. Defaulting to https://127.0.0.1:8200.
Error checking seal status: Get "https://127.0.0.1:8200/v1/sys/seal-status": http: server gave HTTP response to HTTPS client

처음에는 Vault 서버가 정상적으로 실행되지 않은 것으로 생각했습니다. 하지만 실제 원인은 VAULT_ADDR가 설정되지 않아 Vault CLI가 기본 주소인 https://127.0.0.1:8200으로 접속을 시도했기 때문이었습니다.

개발 모드에서는 Vault 서버가 HTTP로 동작하지만, Vault CLI는 기본적으로 HTTPS로 접속을 시도합니다. 그래서 아래와 같이 환경변수를 추가적으로 설정했습니다.

/ # export VAULT_ADDR=http://127.0.0.1:8200

환경변수 설정 이후에, 다시 명령을 실행해서 정상적으로 응답이 수신되는 것을 확인할 수 있었습니다.

/ # vault status

Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    1
Threshold       1
Version         1.21.4
Build Date      2026-03-04T17:40:05Z
Storage Type    inmem
Cluster Name    vault-cluster-ebd273bd
Cluster ID      8db3a19c-718d-f4f6-16ea-325f4979fba7
HA Enabled      false

응답 결과를 보면 Initialized=true, Sealed=false로 표시됩니다. 이는 Vault가 초기화되어 있으며 Seal이 해제되어 요청을 처리할 수 있는 상태라는 의미입니다.

또한 Storage Type=inmem은 데이터를 메모리에 저장하고 있음을 의미하며, HA Enabled=false는 현재 단일 노드의 개발 모드로 실행되어 고가용성 기능이 활성화되지 않았음을 나타냅니다.

3. 다음 포스팅

이번 포스팅에서는 KMS와 Vault의 차이를 살펴보고, Docker를 이용해 Vault를 개발 모드로 실행한 뒤 CLI로 동작 상태를 확인했습니다.

아직 Vault가 제공하는 보안 기능을 본격적으로 사용해보지는 않았습니다. Vault는 시크릿 엔진(Secrets Engine) 단위로 기능을 제공하며, 필요한 기능을 선택적으로 활성화해 사용할 수 있습니다. 대표적으로 시크릿을 저장하고 관리하는 KV Secrets Engine과 암·복호화 연산을 수행하는 Transit Secrets Engine이 있습니다.

앞으로 각 엔진을 직접 사용해보면서 Vault가 기존 KMS의 역할을 어느 수준까지 대체할 수 있는지 확인해보려고 합니다. 다음 포스팅에서는 KV Secrets Engine을 이용해 암호화 키를 저장하고 조회하는 과정을 실습해보겠습니다.