Azure Key Vault란 무엇인가: Secret, Key, Certificate 관리

Azure Key Vault는 애플리케이션에서 사용하는 비밀(Secret), 암호화 키(Key), 인증서(Certificate)를 중앙에서 안전하게 저장하고 관리하는 서비스입니다. 코드나 설정 파일에 민감 정보를 직접 넣는 대신, Key Vault에 저장하고 접근 권한을 통제하는 것이 핵심 패턴입니다.

핵심 요약

• Azure Key Vault는 Secret, Key, Certificate 세 종류의 객체를 관리하는 보안 서비스입니다.
• 접근 제어는 RBAC(data plane)과 Management Plane(control plane)으로 분리됩니다.
• Standard 티어는 소프트웨어 기반 키를, Premium 티어는 HSM(하드웨어 보안 모듈) 기반 키를 지원합니다.
• Soft Delete(기본 활성화)로 실수로 삭제한 객체를 7~90일 내에 복구할 수 있습니다.
• 비용은 트랜잭션 단위(10,000건당 $0.03)로 과금되며, Vault 자체 생성은 무료입니다.

1. 왜 Key Vault가 필요한가

웹 애플리케이션 하나를 운영한다고 가정합니다. 이 앱은 다음 정보를 사용합니다.

• 데이터베이스 연결 문자열
• 외부 API 키
• TLS 인증서
• 데이터 암호화를 위한 AES 키

이런 민감 정보를 코드에 하드코딩하거나 환경 변수에 평문으로 저장하면 다음 문제가 발생합니다.

• Git 저장소에 Secret이 커밋되어 외부 노출 위험이 생깁니다.
• 키를 교체(rotate)할 때 모든 배포를 다시 해야 합니다.
• 누가 언제 어떤 Secret에 접근했는지 추적할 수 없습니다.
• 팀원 전체가 모든 Secret에 접근할 수 있어 최소 권한 원칙을 지킬 수 없습니다.

Azure Key Vault는 이 문제들을 해결합니다. 민감 정보를 중앙 저장소에 넣고, 접근 권한을 세분화하고, 모든 접근을 감사 로그로 기록합니다. 애플리케이션은 Key Vault에서 필요한 순간에 Secret을 가져오므로, 코드에는 민감 정보가 남지 않습니다.

2. Azure Key Vault 아키텍처

Azure Key Vault 구조

Azure Key Vault는 두 가지 유형의 컨테이너를 제공합니다.

유형	설명	사용 사례
Vault	Secret, Key, Certificate를 모두 저장하는 범용 컨테이너	대부분의 애플리케이션
Managed HSM Pool	HSM 전용 키 관리 (단일 테넌트 전용 하드웨어)	규정 준수 요구사항이 높은 금융/공공 분야

대부분의 경우 Vault를 사용합니다. Managed HSM은 FIPS 140-3 Level 3 인증이 필요하거나 전용 HSM 하드웨어가 요구되는 환경에서 검토합니다.

2.1 두 가지 Plane

Key Vault에 대한 접근은 두 가지 평면(plane)으로 분리됩니다.

Plane	역할	예시 작업
Management Plane (Control Plane)	Vault 자체를 관리	Vault 생성/삭제, 접근 정책 구성, 방화벽 설정
Data Plane	Vault 안의 객체를 조작	Secret 읽기/쓰기, Key로 암호화/복호화, 인증서 발급

이 분리가 중요한 이유는 "Vault를 관리하는 권한"과 "Vault 안의 데이터에 접근하는 권한"이 독립적이기 때문입니다. 인프라 관리자에게는 Management Plane 권한을 주되 Data Plane 권한은 주지 않으면, Vault 설정은 관리하면서도 실제 Secret 값은 볼 수 없습니다.

Security Note
Vault에 대한 Contributor 역할(Management Plane)을 가진 사용자라도, Data Plane 권한이 별도로 부여되지 않으면 Secret 값을 읽을 수 없습니다. 이 분리를 이해하지 못하면 "권한을 줬는데 접근이 안 됩니다"라는 문제를 겪게 됩니다.

3. 세 가지 객체: Secret, Key, Certificate

Azure Key Vault 세 가지 객체

Key Vault에 저장할 수 있는 객체는 세 종류입니다. 각각 용도와 동작 방식이 다릅니다.

3.1 Secret

Secret은 임의의 문자열 값을 저장하는 가장 단순한 객체입니다.

항목	내용
저장 대상	연결 문자열, API 키, 비밀번호, 토큰 등
최대 크기	25KB
버전 관리	자동 (새 값을 저장하면 새 버전 생성)
만료일 설정	가능 (만료되면 읽기 차단)

Secret은 Key Vault에서 가장 많이 사용되는 객체입니다. 애플리케이션이 데이터베이스에 접속할 때 필요한 연결 문자열, 외부 SaaS API 호출에 필요한 API 키, OAuth 클라이언트 시크릿 같은 값이 여기에 해당합니다.

# Secret 생성
az keyvault secret set \
  --vault-name "my-app-kv" \
  --name "db-connection-string" \
  --value "Server=mydb.database.windows.net;Database=prod;..."

# Secret 읽기 (최신 버전)
az keyvault secret show \
  --vault-name "my-app-kv" \
  --name "db-connection-string" \
  --query "value" -o tsv

Tip
Secret의 만료일(expiry)을 설정하면 만료 후 해당 Secret을 가져올 수 없게 됩니다. 이 기능을 활용해 정기적인 키 교체(rotation)를 강제할 수 있습니다. Azure Event Grid와 연동하면 만료 30일 전에 알림을 받아 자동 교체 워크플로를 구성할 수 있습니다.

3.2 Key

Key는 암호화 작업(encrypt, decrypt, sign, verify, wrap, unwrap)에 사용되는 암호화 키입니다.

항목	내용
용도	데이터 암호화/복호화, 디지털 서명, 키 래핑
지원 알고리즘	RSA (2048, 3072, 4096비트), EC (P-256, P-384, P-521, secp256k1)
보호 수준	Software-protected (Standard 티어) 또는 HSM-protected (Premium 티어)
핵심 특징	키가 Key Vault 밖으로 나가지 않음 (암호화 연산을 Vault 내부에서 수행)

Key의 가장 중요한 특징은 키 소재(key material)가 Vault 밖으로 내보내지지 않는다는 점입니다. 애플리케이션이 데이터를 암호화하고 싶으면, 데이터를 Key Vault에 보내서 Vault 안에서 암호화한 결과를 받습니다. 키 자체를 다운로드해서 로컬에서 암호화하는 것이 아닙니다.

# RSA 2048비트 소프트웨어 키 생성
az keyvault key create \
  --vault-name "my-app-kv" \
  --name "data-encryption-key" \
  --kty RSA \
  --size 2048

# 키로 데이터 암호화 (Vault 내부에서 수행)
az keyvault key encrypt \
  --vault-name "my-app-kv" \
  --name "data-encryption-key" \
  --algorithm RSA-OAEP \
  --value "base64-encoded-plaintext"

주의
대용량 데이터를 직접 Key Vault Key로 암호화하면 안 됩니다. RSA는 키 크기보다 작은 데이터만 직접 암호화할 수 있습니다. 실무에서는 Envelope Encryption(봉투 암호화) 패턴을 사용합니다. 대칭 키(DEK)로 데이터를 암호화하고, 그 대칭 키를 Key Vault의 RSA 키(KEK)로 래핑(wrap)하는 방식입니다.

3.3 Certificate

Certificate는 TLS/SSL 인증서를 관리하는 객체입니다. 내부적으로 Key와 Secret을 모두 활용합니다.

항목	내용
용도	TLS/SSL 인증서 발급, 갱신, 배포
지원 CA	DigiCert, GlobalSign 또는 Self-signed
자동 갱신	가능 (만료 전 지정 일수에 자동 갱신)
내부 구조	Certificate 생성 시 같은 이름의 Key + Secret이 자동 생성됨

Certificate 객체를 생성하면 Key Vault가 내부적으로 세 가지를 만듭니다.

1. Key: 인증서의 공개키/개인키 쌍
2. Secret: PFX 또는 PEM 형식의 인증서 전체 (개인키 포함)
3. Certificate: 메타데이터와 갱신 정책

이 구조 덕분에 인증서의 개인키가 필요한 서비스는 Secret으로 가져오고, 공개키 기반 서명/검증이 필요한 서비스는 Key로 접근할 수 있습니다.

# 자체 서명(self-signed) 인증서 생성
az keyvault certificate create \
  --vault-name "my-app-kv" \
  --name "my-tls-cert" \
  --policy "$(az keyvault certificate get-default-policy)"

4. 접근 제어: RBAC vs Access Policy

Azure Key Vault 접근 제어 모델

Key Vault의 Data Plane 접근을 제어하는 방법은 두 가지입니다.

모델	설명	권장 여부
Azure RBAC	Azure 역할 기반 접근 제어 (Scope 기반)	권장 (신규 Vault 기본값)
Vault Access Policy	Vault 단위로 주체별 권한을 직접 설정	레거시 (기존 Vault 호환)

4.1 Azure RBAC 방식 (권장)

Azure RBAC를 Data Plane에도 적용하는 방식입니다. Key Vault 전용 built-in 역할이 제공됩니다.

역할	권한
Key Vault Administrator	Secret, Key, Certificate 모든 작업 (관리 + 데이터)
Key Vault Secrets Officer	Secret CRUD (생성/읽기/수정/삭제)
Key Vault Secrets User	Secret 읽기만
Key Vault Crypto Officer	Key CRUD + 암호화 작업
Key Vault Crypto User	Key로 암호화/복호화만
Key Vault Certificates Officer	Certificate CRUD
Key Vault Reader	메타데이터 조회만 (값은 못 읽음)

RBAC 방식을 선택하면 Key Vault도 다른 Azure 리소스와 동일한 방식으로 권한을 관리할 수 있습니다. Scope를 개별 Key/Secret까지 좁힐 수도 있어 세밀한 제어가 가능합니다.

# 애플리케이션의 Managed Identity에 Secret 읽기 권한만 부여
az role assignment create \
  --assignee "<managed-identity-object-id>" \
  --role "Key Vault Secrets User" \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-prod/providers/Microsoft.KeyVault/vaults/my-app-kv"

4.2 Vault Access Policy 방식 (레거시)

Vault 단위로 각 주체(사용자, 앱, 서비스)에게 Secret/Key/Certificate 각각의 세부 권한(get, list, set, delete 등)을 직접 지정합니다. Vault 하나에 최대 1,024개 Access Policy를 설정할 수 있습니다.

# Access Policy로 앱에 Secret get 권한 부여
az keyvault set-policy \
  --name "my-app-kv" \
  --object-id "<app-object-id>" \
  --secret-permissions get list

Tip
신규 Key Vault를 만들 때는 Azure RBAC 방식을 선택하는 것이 좋습니다. RBAC는 Scope 상속, 조건부 접근(ABAC), PIM(Just-In-Time)과 연동이 되므로 장기적으로 관리가 용이합니다. Access Policy는 Vault 단위로만 관리되어 세밀한 범위 지정이 어렵습니다.

5. 네트워크 보안

Key Vault는 기본적으로 공용 인터넷에서 접근 가능합니다. 운영 환경에서는 네트워크 접근을 제한해야 합니다.

방법	설명
방화벽 규칙	허용된 IP/CIDR만 접근 가능
VNet Service Endpoint	특정 VNet의 Subnet에서만 접근 허용
Private Endpoint	VNet 내부 Private IP로 Key Vault에 접근 (인터넷 노출 차단)
Trusted Services 예외	Azure Backup, Azure SQL 등 신뢰할 수 있는 Microsoft 서비스는 방화벽 우회 허용

# 방화벽 활성화 + 특정 VNet만 허용
az keyvault update \
  --name "my-app-kv" \
  --default-action Deny

az keyvault network-rule add \
  --name "my-app-kv" \
  --vnet-name "vnet-prod" \
  --subnet "subnet-app"

Security Note
운영 환경에서는 Private Endpoint를 사용해 Key Vault 트래픽이 Microsoft 백본 네트워크만 통과하도록 구성하는 것이 좋습니다. Public 접근을 완전히 차단하면 인터넷에서 Vault URL을 알더라도 접근 자체가 불가능합니다.

6. Soft Delete와 Purge Protection

Azure Key Vault Soft Delete 동작 흐름

Key Vault는 실수로 삭제한 객체를 복구할 수 있는 보호 메커니즘을 제공합니다.

6.1 Soft Delete

Soft Delete가 활성화되면, 삭제된 객체(Secret, Key, Certificate)와 Vault 자체가 즉시 파괴되지 않고 "삭제됨(deleted)" 상태로 보존됩니다.

설정	내용
기본 상태	활성화 (신규 Vault에서 비활성화 불가)
보존 기간	7~90일 (기본값 90일, 생성 시 설정)
복구 가능	보존 기간 내 언제든 복구 가능
영구 삭제(Purge)	보존 기간 만료 시 자동 또는 수동 Purge

6.2 Purge Protection

Purge Protection을 켜면 보존 기간이 끝나기 전에는 누구도(관리자 포함) 영구 삭제할 수 없습니다.

Soft Delete만	Soft Delete + Purge Protection
삭제된 객체를 복구 가능	삭제된 객체를 복구 가능
Purge 권한이 있으면 즉시 영구 삭제 가능	보존 기간 만료 전까지 영구 삭제 불가
실수 복구용	악의적 삭제 방어까지 포함

주의
Purge Protection은 한 번 켜면 끌 수 없습니다. Azure SQL TDE(Transparent Data Encryption)나 Azure Disk Encryption처럼 Key Vault Key에 의존하는 서비스를 사용할 때는 Purge Protection을 반드시 켜야 합니다. 키가 영구 삭제되면 암호화된 데이터를 복구할 수 없기 때문입니다.

7. 실무 사용 사례

사례 1: 웹 애플리케이션의 Secret 중앙 관리

App Service 위에서 동작하는 웹 앱이 DB 연결 문자열, Redis 접속 정보, 외부 API 키를 사용합니다.

설계 방식:

1. App Service에 System-assigned Managed Identity를 활성화합니다.
2. Key Vault에 Key Vault Secrets User 역할을 해당 Managed Identity에 부여합니다.
3. App Service의 Application Settings에서 Key Vault Reference 구문을 사용합니다.

# App Service Application Settings에서 Key Vault Reference 사용
DB_CONNECTION_STRING=@Microsoft.KeyVault(SecretUri=https://my-app-kv.vault.azure.net/secrets/db-connection-string/)

이 방식의 장점:

• 코드에 Secret이 없으므로 Git에 노출될 위험이 없습니다.
• Secret 교체 시 Key Vault 값만 바꾸면 앱이 다음 참조 시 새 값을 가져옵니다.
• Managed Identity를 사용하므로 별도 자격 증명(client secret)을 관리할 필요가 없습니다.

사례 2: 데이터 암호화를 위한 Envelope Encryption

고객 데이터를 Storage Account에 저장할 때 추가 암호화 계층이 필요한 상황입니다.

설계 방식:

1. Key Vault에 RSA 키(KEK, Key Encryption Key)를 생성합니다.
2. 애플리케이션은 로컬에서 AES 대칭 키(DEK, Data Encryption Key)를 생성합니다.
3. DEK로 데이터를 암호화합니다.
4. DEK를 Key Vault의 KEK로 wrap(래핑)합니다.
5. 암호화된 데이터 + 래핑된 DEK를 함께 저장합니다.

복호화 시에는 래핑된 DEK를 Key Vault에 보내 unwrap하고, 복원된 DEK로 데이터를 복호화합니다. KEK는 Key Vault 밖으로 나가지 않으므로 키 유출 위험이 줄어듭니다.

사례 3: AKS에서 Key Vault Secret 사용

Kubernetes Pod에서 Key Vault의 Secret을 사용해야 하는 상황입니다.

설계 방식:

Azure Key Vault Provider for Secrets Store CSI Driver를 사용합니다.

1. AKS 클러스터에서 CSI Driver 애드온을 활성화합니다.
2. SecretProviderClass 리소스로 가져올 Secret을 정의합니다.
3. Pod의 Volume으로 마운트하면 Secret이 파일로 주입됩니다.

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kv-secrets
spec:
  provider: azure
  parameters:
    keyvaultName: "my-app-kv"
    objects: |
      array:
        - |
          objectName: db-connection-string
          objectType: secret
    tenantId: "<tenant-id>"

이 방식은 Kubernetes Secret에 민감 정보를 etcd에 저장하는 대신, 실행 시점에 Key Vault에서 직접 가져오므로 보안 수준이 높습니다.

8. 비용 구조

Key Vault는 종량제(pay-as-you-go)로 과금됩니다. Vault 자체 생성은 무료이며, 객체에 대한 연산(operation) 횟수와 키 유형에 따라 비용이 발생합니다.

항목	Standard 티어	Premium 티어
Secret 연산	$0.03 / 10,000 트랜잭션	$0.03 / 10,000 트랜잭션
Software Key 연산 (RSA 2048)	$0.03 / 10,000 트랜잭션	$0.03 / 10,000 트랜잭션
Software Key 연산 (RSA 3072+, ECC)	$0.15 / 10,000 트랜잭션	$0.15 / 10,000 트랜잭션
HSM Key (RSA 2048)	지원 안 함	$1/키/월 + $0.03 / 10,000 트랜잭션
Certificate 갱신	$3 / 갱신 요청	$3 / 갱신 요청
Certificate 기타 연산	$0.03 / 10,000 트랜잭션	$0.03 / 10,000 트랜잭션
자동 키 교체	$1 / 예약된 교체	$1 / 예약된 교체
Managed HSM Pool	N/A	$3.20/시간 (별도 리소스)

Tip
대부분의 애플리케이션에서 Key Vault 비용은 월 $1 미만입니다. Secret을 읽는 빈도가 높더라도 10,000건당 $0.03이므로, 하루 10만 건을 읽어도 월 $0.90 수준입니다. 비용보다는 보안과 운영 편의성이 Key Vault 도입의 주요 이유입니다.

Standard vs Premium 선택 기준

기준	Standard	Premium
키 보호 수준	소프트웨어 (FIPS 140 Level 1)	HSM (FIPS 140-3 Level 3)
HSM Key 사용	불가	가능
비용	낮음	HSM Key당 월 $1 추가
사용 사례	일반 애플리케이션	규정 준수, 금융, 공공 기관

대부분의 경우 Standard 티어로 충분합니다. HSM 기반 키가 필요한 경우는 규정(예: PCI DSS, 금융감독원 규정)이 하드웨어 기반 키 보호를 명시적으로 요구할 때입니다.

9. 서비스 제한(Throttling)

Key Vault는 Vault당, 리전당 트랜잭션 제한이 있습니다.

작업 유형	10초당 최대 트랜잭션
Secret 연산 (GET)	4,000
RSA 2048 Software Key	4,000
RSA 2048 HSM Key	2,000
RSA 3072/4096 HSM Key	500
ECC HSM Key (P-256)	2,000
기타 모든 트랜잭션	4,000

제한을 초과하면 HTTP 429(Too Many Requests) 응답을 받습니다. 클라이언트 SDK는 기본적으로 지수 백오프(exponential backoff)로 재시도합니다.

주의
마이크로서비스 아키텍처에서 모든 서비스가 하나의 Key Vault에 동시에 접근하면 throttling에 걸릴 수 있습니다. 이 경우 Secret 값을 메모리에 캐싱하거나(TTL 설정 필수), 서비스별로 Vault를 분리하는 것을 검토할 수 있습니다. 다만 캐싱 시 Secret 교체 반영이 지연될 수 있으므로 trade-off를 인식해야 합니다.

10. 다른 클라우드 서비스와 비교

기준	Azure Key Vault	AWS Secrets Manager	AWS KMS	GCP Secret Manager
Secret 관리	✓	✓	✗	✓
암호화 키 관리	✓	✗	✓	✗ (Cloud KMS 별도)
인증서 관리	✓	✗ (ACM 별도)	✗	✗ (Certificate Manager 별도)
자동 교체	Event Grid 연동	Lambda 연동 내장	자동 교체 지원	자동 교체 지원
HSM 지원	Premium / Managed HSM	CloudHSM 별도	Custom Key Store	Cloud HSM 별도

Azure Key Vault의 차별점은 Secret, Key, Certificate를 하나의 서비스에서 통합 관리한다는 점입니다. AWS에서는 Secrets Manager(Secret) + KMS(Key) + ACM(Certificate)로 분산되어 있어 각각 별도로 설정해야 합니다.

11. 자주 하는 실수

1. Management Plane과 Data Plane 권한을 혼동하는 것: Vault에 대한 Contributor 역할을 줘도 Secret 값을 읽을 수 없습니다. Data Plane 역할(Key Vault Secrets User 등)을 별도로 부여해야 합니다.
2. 네트워크 제한 없이 Vault를 생성하는 것: 기본값은 공용 인터넷에서 접근 가능입니다. 운영 환경에서는 방화벽 규칙이나 Private Endpoint로 접근을 제한해야 합니다.
3. Purge Protection을 켜지 않고 중요한 키를 저장하는 것: 키에 의존하는 서비스(Azure SQL TDE, Disk Encryption)가 있다면 Purge Protection을 반드시 켜야 합니다. 키가 영구 삭제되면 데이터 복구가 불가능합니다.
4. Secret 교체 계획 없이 운영하는 것: Secret에 만료일을 설정하지 않으면 동일한 값이 수년간 사용됩니다. Event Grid 알림 + 자동 교체 로직을 구성하거나, 최소한 만료일을 설정해 교체 주기를 인식해야 합니다.
5. 하나의 Vault에 모든 환경의 Secret을 넣는 것: dev, staging, prod Secret을 한 Vault에 넣으면 접근 제어가 복잡해집니다. 환경별(또는 애플리케이션별)로 Vault를 분리하는 것이 운영상 안전합니다.

12. 정리

• Azure Key Vault는 Secret(비밀 값), Key(암호화 키), Certificate(인증서)를 중앙에서 관리하는 서비스입니다.
• Management Plane(Vault 관리)과 Data Plane(객체 접근) 권한이 분리되어 있어 최소 권한 원칙을 적용할 수 있습니다.
• 접근 제어는 Azure RBAC 방식을 권장하며, Managed Identity와 조합하면 자격 증명 없이 안전하게 접근할 수 있습니다.
• Soft Delete(기본 활성화)와 Purge Protection으로 실수 및 악의적 삭제로부터 보호됩니다.
• 비용은 트랜잭션 기반으로 대부분의 워크로드에서 매우 낮으며, 보안과 운영 편의성이 도입의 주요 이유입니다.

참고 문서

• Azure 공식 문서: Azure Key Vault 기본 개념
• Azure 공식 문서: Keys, Secrets, Certificates 개요
• Azure 공식 문서: Key Vault에 대한 접근 보안
• Azure 공식 문서: Key Vault Soft Delete 개요
• Azure 공식 문서: Key Vault 서비스 제한
• Azure 공식 문서: Key Vault 가격 책정