봉인(sealing) 모범 사례

이 문서는 프로덕션 Vault 클러스터의 봉인 해제(unsealing)를 위한 개념, 옵션, 고려 사항을 설명합니다. Vault의 Reference Architecture와 Deployment Guide를 기반으로 일반적인 Vault 사용 사례를 위한 패턴을 제공합니다.

출처: 문서

본문

Vault 봉인 해제

Deployment Guide에 따라 Vault를 설치하고 구성하면 Vault는 sealed 상태로 시작합니다. Vault는 항상 sealed 상태로 시작하므로 첫 번째 결정 지점은 봉인 해제를 처리하기 위한 구현 전략입니다. 봉인 해제는 Vault가 모든 데이터를 암호화하는 데 사용하는 데이터 암호화 키를 Vault root 키로 복호화하는 과정입니다. 명백한 보안상의 이유로 Vault는 root 키를 보관하지도 알지도 못하므로, 봉인 해제 과정의 기능은 root 키를 Vault에 제시하는 것입니다.

Vault Community Edition은 대부분의 주요 클라우드 공급자에 대해 Shamir와 cloud auto-unseal 방법을 지원합니다. Vault Enterprise는 또한 하드웨어 보안 모듈(HSM) 봉인 해제도 제공합니다.

봉인 해제 전략을 결정할 때 고려해야 할 사항이 몇 가지 있습니다.

팁 Vault 봉인의 배후 개념과 이유에 대해 더 알아보려면 seal/unseal 문서를 참고하세요.

운영자 오버헤드

기본 봉인 해제 방법은 Shamir의 Secret Sharing 알고리즘을 사용해 키를 shard로 분할하여 단일 root 키가 없도록 합니다. 이 방법은 Vault 봉인 해제에 여러 운영자(각자 고유한 키를 가진)가 참여해야 하므로 Enterprise 솔루션에는 적합하지 않을 수 있습니다.

이 방법을 사용한다면 다음과 같은 추가 운영 프로세스를 마련할 것을 권장합니다:

모든 운영자가 대응할 수 있도록 분기별 봉인 해제 훈련(unseal drills).
키 shard를 안전한 위치에 보관하고 개인 암호화로 추가 암호화. Vault는 init 명령에서 unseal 키와 root 토큰을 PGP 암호화하는 플래그를 제공합니다.
키 보유자의 키 접근을 엔터프라이즈 사용자 수명 주기 관리와 연결해 인력 변경에 대응.

클라우드 공급자

Vault 구현이 퍼블릭 클라우드에 있거나 접근할 수 있다면 보안 Key Management Service(KMS)에 접근할 수 있을 수 있으며, Vault는 이를 활용해 root 키를 저장하고 거기서 검색할 수 있습니다. 이 옵션은 사용하기 쉽지만 퍼블릭 클라우드 접근에 의존합니다.

이 방법을 사용할 때의 고려 사항:

보안 정책: 보안 정책이 시크릿을 퍼블릭 클라우드에 저장하는 것을 허용합니까?
비즈니스 연속성: 일부 기업은 비즈니스 연속성 이유로 공급업체 의존에 대한 정책이 있을 수 있습니다.
키 저장소를 읽는 데 필요한 클라우드 공급자 접근 키에 대한 추가 보안을 마련해야 합니다.

HSM 접근

HSM에 접근할 수 있다면 Vault는 seal 스탠자의 pkcs11 구성 블록을 사용해 root 키를 저장하고 검색하는 방법을 제공합니다. 이 방법은 시크릿 관리 인프라의 모든 부분이 비즈니스 통제 하에 있다는 점에서 상당한 보안을 제공하지만, 다른 고려 사항도 있습니다:

보안 정책이 HSM에 대한 접근과 보안을 관리해야 합니다.
Vault가 HSM에 접근하는 데 필요한 HSM PIN에 대한 추가 보안을 마련해야 합니다.

클라우드 공급자 auto-unseal

주요 클라우드 공급자는 암호화 키 관리 시스템을 제공하며, Vault는 이를 사용해 봉인 해제 작업에 root 키를 제공할 수 있습니다.

AWS KMS
Azure Key Vault
GCP Cloud KMS
AliCloud KMS
OCI KMS

이 모든 클라우드 공급자 auto-unseal 방법의 상위 수준 원칙은 동일합니다. root 키를 shard로 분할해 안전하게 배포하는 대신, root 키를 클라우드 공급자의 키 관리 플랫폼에서 생성하고 저장합니다. Vault는 시작 시 이 키를 검색해 자동으로 봉인 해제하도록 구성됩니다.

클라우드 공급자로 auto-unseal을 사용하는 것은 공급자에 대한 신뢰에 관한 보안적 함의가 있습니다.

AWS KMS를 auto-unseal에 사용

AWS를 사용할 때 AWS Key Management Service가 시작 시 Vault 클러스터에 root 키를 저장하고 제공할 수 있습니다. 두 단계가 있습니다:

AWS KMS 키 생성
Vault가 이 키를 읽고 복호화할 수 있도록 구성

첫 번째 단계에서는 평소 AWS 인프라와 서비스를 프로비저닝하는 방식으로 AWS KMS 키를 생성할 수 있습니다. 결과는 키 ID를 가진 키입니다. 모범 사례는 이 키를 관리하기 위한 최소한의 접근만 허용하고 Vault만 접근할 수 있게 하는 것입니다. 또한 KMS 키에 대한 CloudTrail audit 로그를 활성화하고 다른 무엇도 이 키에 접근을 시도하지 않는지 검증해야 합니다. AWS KMS에서는 자체 키 자료로 키를 생성하거나 AWS가 이를 제공하도록(기본 방법) 할 수 있습니다.

두 번째 단계는 키 ID와 키의 AWS 리전을 seal 스탠자 안의 Vault 구성 파일에 추가하는 것입니다. Vault는 기본적으로 us-east-1에서 키를 찾지만, 키가 이 리전에 있더라도 region 키/값을 추가하는 것이 좋은 관행입니다.

KMS 키에 대한 접근이 기본적으로 제한되어 있으므로 Vault가 접근할 수 있게 허용해야 하며, Vault를 실행하는 EC2 인스턴스의 Instance Profile로 이를 할 수 있습니다. 모범 사례는 Vault를 자체 인스턴스에서 실행하고 다른 서비스를 함께 호스팅하지 않는 것입니다. Instance Profile에는 kms:Encrypt, kms:Decrypt, kms:DescribeKey 정책을 가진 역할이 필요합니다. 이 정책을 Policy JSON의 Resources 섹션에 있는 단일 암호화 키 arn에 연결하세요.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["kms:Encrypt", "kms:Decrypt", "kms:DescribeKey"],
      "Resource": ["${kms_arn}"]
    }
  ]
}

HSM으로 Vault 봉인 해제

하드웨어 HSM 또는 클라우드 KMS로 Vault를 봉인 해제할 수도 있습니다. 봉인 해제 방법은 unseal 문서의 HSM 섹션에 문서화된 KMS 사용과 유사합니다. SafenetAT의 유용한 워크스루 동영상이나 HashiCorp의 AWS HSM 사용 교육 동영상을 볼 수 있습니다. AWS는 CloudHSM과 KMS를 모두 제공하며 Securing and Managing secrets with HashiCorp Vault에 대한 상위 수준 가이드도 제공합니다.

복구 키(Recovery keys)

HSM이나 클라우드 제공 외부 키로 봉인하는 동안 Vault를 초기화하면 여러 개의 복구 키가 반환됩니다. 이 키들은 새 root 키 생성 같은 고권한 작업에 여전히 필요합니다. HSM 문서의 한 섹션에서 복구 키를 다룹니다.

봉인 방법 변경

seal migration을 사용해 봉인 방법을 변경할 수 있습니다.

참고 자료

Reference Architecture는 권장되는 프로덕션 Vault 클러스터 아키텍처를 다룹니다.
Deployment Guide는 프로덕션 사용을 위해 Vault를 설치하고 구성하는 방법을 다룹니다.
Recommended Pattern - Vault Centralized Secrets Management
K/V Secrets Engine은 Vault의 구성된 물리 스토리지 안에 정적 시크릿을 저장하는 데 사용됩니다.
Auth Methods는 사용자와 머신을 Vault로 인증하는 데 사용됩니다.
Auto unseal 튜토리얼
Consul Template은 Vault에 저장된 정적 시크릿에 접근해 이를 필요로 하는 애플리케이션과 서비스에 제공하는 데 사용됩니다.

봉인(sealing) 모범 사례