권장 패턴

다음 모범 사례를 구현해 흔한 안티 패턴을 피함으로써 Vault 환경이 효과적으로 작동하도록 유지하세요.

출처: 문서

본문

설명 적용 가능한 Vault 에디션
기본 임대 시간 조정 전체
정확한 클라이언트 수를 위한 identity 엔티티 사용 Enterprise, HCP
IOPS 증가 Enterprise, Community
재해 복구 활성화 Enterprise
재해 복구 테스트 Enterprise
업그레이드 주기 개선 Enterprise, Community
업그레이드 전 테스트 Enterprise, Community
감사 장치 로그 로테이션 Enterprise, Community
한계와 최대값 모니터링 Enterprise, Community
메트릭 모니터링 Enterprise, Community
사용량 기준선 수립 Enterprise, Community
root 토큰 사용 최소화 전체
필요할 때 rekey 전체

기본 임대 시간 조정 (Adjust the default lease time)

Vault의 기본 임대 시간은 32일 또는 768시간입니다. 이 시간은 재인증이나 갱신 같은 일부 작업을 허용합니다. 자세한 내용은 임대 문서를 참고하세요.

권장 패턴: 필요에 맞게 임대 TTL 값을 조정하세요. Vault는 임대가 만료될 때까지 임대를 메모리에 보관합니다. 유스케이스가 허용하는 한 TTL을 최대한 짧게 유지할 것을 권장합니다.

  • Auth tune
  • Secrets tune

참고: TTL을 조정해도 이미 발급된 토큰에는 소급해서 영향을 주지 않습니다. TTL 조정 후에는 새 토큰을 발급해야 합니다.

안티 패턴 문제: 기본 time-to-live(TTL)를 변경하지 않고 임대를 생성하면 임대는 기본 임대 시간이 끝날 때까지 Vault에 남아 있습니다. Vault가 임대를 메모리에 저장하므로, 인프라와 사용 가능한 시스템 메모리에 따라 기본 또는 긴 TTL을 사용하면 성능 문제가 발생할 수 있습니다.

정확한 클라이언트 수를 위한 identity 엔티티 사용 (Use identity entities for accurate client count)

각 Vault 클라이언트는 Vault 서버에 활성화된 인증 메서드로 여러 계정을 가질 수 있습니다.

엔티티

권장 패턴: 각 토큰은 클라이언트 수에 추가되고, 각 고유 인증은 토큰을 발급하므로, identity 엔티티를 사용해 각 로그인을 단일 identity에 연결하는 별칭(alias)을 만들어야 합니다.

  • Client count
  • Vault identity concepts
  • Vault Identity secrets engine
  • Identity: Entities and groups tutorial

안티 패턴 문제: identity 엔티티를 사용하지 않으면 사용자의 엔티티와 연결되지 않은 다른 인증 메서드를 사용할 때 각 새 클라이언트가 별도의 identity로 계산됩니다.

IOPS 증가 (Increase IOPS)

IOPS(초당 입출력 작업 수)는 Vault 클러스터 구성원의 성능을 측정합니다. Vault는 컴퓨팅 요구 사항보다 스토리지 백엔드의 IO 한계에 의해 제약을 받습니다.

권장 패턴: Vault 서버의 하드웨어 크기 조정과 네트워크 고려 사항에 HashiCorp 참조 지침을 사용하세요.

  • Vault with Integrated storage reference architecture
  • Performance tuning
  • Transform secrets engine

참고: 클라이언트 수에 따라 Transform(Enterprise)과 Transit 시크릿 엔진은 리소스 집약적일 수 있습니다.

안티 패턴 문제: 제한된 IOPS는 Vault 성능을 크게 저하시킬 수 있습니다.

재해 복구 활성화 (Enable disaster recovery)

HashiCorp Vault의 고가용성(HA) 인터그레이티드 스토리지(Raft) 백엔드는 클러스터 구성원 간의 클러스터 내 데이터 복제를 제공합니다. 인터그레이티드 스토리지는 Vault에 수평 확장성과 내결함성을 제공하지만 전체 클러스터에 대한 백업은 제공하지 않습니다. 프로덕션 환경에 재해 복구를 활용하지 않으면 조직의 Recovery Point Objective(RPO)와 Recovery Time Objective(RTO)에 부정적인 영향을 미칩니다.

권장 패턴: 클러스터 전체의 문제(예: 네트워크 연결)에 대해 Vault Enterprise DR(Disaster Recovery) 복제는 모든 프라이머리 클러스터 데이터를 포함하는 웜 대기(warm standby) 클러스터를 제공합니다. DR 클러스터는 읽기나 쓰기를 처리하지 않지만, 필요할 때 프라이머리 클러스터를 대체하도록 승격할 수 있습니다.

  • Disaster recovery replication setup
  • Disaster recovery (DR) replication
  • DR replication API documentation

또한 데이터 손상을 보호하기 위해 주기적으로 데이터 스냅샷을 만드는 것도 권장합니다.

  • Vault data backup standard procedure
  • Automated integrated storage snapshots
  • /sys/storage/raft/snapshot-auto

안티 패턴 문제: 재해 복구를 활성화하지 않고 치명적인 장애가 발생하면, 환경에서 Vault 클라이언트를 서비스하지 못하는 것과 관련된 더 긴 가동 중지 시간과 비용을 겪게 됩니다.

재해 복구 테스트 (Test disaster recovery)

재해 복구(DR) 솔루션은 전체 재해 복구 계획의 핵심 부분입니다. Vault 재해 복구 솔루션을 설계하고 구성하는 것은 첫 단계일 뿐입니다. DR 솔루션을 검증하지 않으면 조직의 Recovery Point Objective(RPO)와 Recovery Time Objective(RTO)에 부정적인 영향을 미칠 수 있으므로 DR 솔루션을 검증해야 합니다.

권장 패턴: Vault의 DR 복제 모드는 프라이머리 클러스터에 치명적인 장애가 발생한 경우 장애 조치(failover)를 위한 웜 대기를 제공합니다. 장애 조치와 장애 복구(failback) 절차를 완료해 재해 복구 복제 클러스터를 주기적으로 테스트해야 합니다.

  • Vault disaster recovery replication failover and failback tutorial
  • Vault Enterprise replication
  • Monitoring Vault replication

스냅샷에서 Vault 클러스터를 복원하는 표준 운영 절차도 수립해야 합니다. DR 상황 이후의 복원 방법은 데이터 손상이나 사보타주에 대응하기 위한 것이며, DR 복제가 이를 항상 보호하지는 못할 수 있습니다.

  • Standard procedure for restoring a Vault cluster

안티 패턴 문제: 재해 복구 솔루션을 테스트하지 않으면 주요 이해 관계자가 재해 복구 계획을 효과적으로 수행할 수 있다는 확신을 갖지 못할 것입니다. DR 솔루션을 테스트하는 것은 정전 중 시스템을 복구하는 데 대한 불확실성을 제거하는 데도 도움이 됩니다.

업그레이드 주기 개선 (Improve upgrade cadence)

여유가 있을 때마다 Vault를 업그레이드하는 것이 쉬울 수 있지만, 빈번한 업그레이드 주기가 없으면 Vault 성능과 보안에 영향을 줄 수 있습니다.

권장 패턴: Vault의 최신 버전으로 업그레이드할 것을 권장합니다. Vault GitHub 저장소의 릴리스를 구독하거나 HashiCorp Vault discuss의 알림을 통해 새 Vault 버전이 릴리스될 때 알 수 있습니다.

  • Vault upgrade guides
  • Vault feature deprecation notice and plans

안티 패턴 문제: 정기적인 업그레이드 주기를 유지하지 않으면 Vault 환경이 핵심 기능이나 개선 사항을 놓칠 수 있습니다.

  • CHANGELOG에 문서화된 버그나 취약점에 대한 패치 누락.
  • 워크플로를 개선할 새 기능 부재.
  • 최신 문서 대신 버전별 문서를 사용해야 함.
  • 일부 교육 리소스가 특정 최소 Vault 버전을 요구함.
  • 최신 바이너리를 설치하기 전에 중간 버전을 사용하는 단계적 접근이 필요한 업데이트.

업그레이드 전 테스트 (Test before upgrades)

프로덕션에 배포하기 전에 샌드박스 환경에서 Vault를 테스트할 것을 권장합니다. 프로덕션에서 즉시 업그레이드하는 것이 더 빠를 수 있지만, 테스트는 호환성 문제를 식별하는 데 도움이 됩니다.

권장 패턴: 프로덕션에서 업그레이드하기 전에 샌드박스 환경에서 새 Vault 버전을 테스트하고 업그레이드 문서를 따르세요. 표준 업그레이드 절차에 테스트 단계를 추가할 것을 권장합니다.

  • Vault upgrade standard procedure
  • Upgrading Vault

안티 패턴 문제: 프로덕션 업그레이드 전에 적절한 테스트가 없으면 호환성과 성능 문제가 발생할 위험이 있습니다.

경고: 이는 프로덕션 Vault 환경의 가동 중지나 성능 저하로 이어질 수 있습니다.

감사 장치 로그 로테이션 (Rotate audit device logs)

Vault의 감사(audit) 장치는 모든 클라이언트 요청과 서버 응답의 상세 로그를 유지합니다. 감사 장치 로그를 로테이션 없이 계속 실행하면 파일시스템 저장 공간이 고갈되어 감사 장치가 차단될 수 있습니다.

권장 패턴: 감사 로그를 주기적으로 점검하고 로테이션하세요.

  • Blocked audit devices tutorial
  • Blocked audit devices

안티 패턴 문제: 감사 장치가 기록할 수 없으면 Vault는 요청에 응답하지 않습니다. 감사 장치 로그를 시간이 지나면서 유지·로테이션하지 않으면 감사 장치가 로컬 저장 공간을 고갈시킬 수 있습니다.

메트릭 모니터링 (Monitor metrics)

Vault 운영 로그와 Vault UI의 데이터만 신뢰하면 클러스터 성능의 일부만 볼 수 있습니다.

권장 패턴: 지속적인 모니터링은 조직이 작은 문제를 감지하고 신속히 해결할 수 있게 해줍니다. 반응적(reactive) 모니터링에서 사전 예방적(proactive) 모니터링으로 전환하면 시스템 장애 예방에 도움이 됩니다. Vault 클러스터 활동을 모니터링하는 데 도움이 되는 여러 출력(감사 로그, 운영 로그, 텔레메트리 데이터)이 있습니다. 이 데이터는 집계, 검사, 알림 기능을 위해 SIEM(보안 정보 및 이벤트 관리) 도구와 함께 작동할 수 있습니다.

  • Telemetry
  • Telemetry metrics reference

모니터링 솔루션 추가:

  • Audit device logs and incident response with elasticsearch
  • Monitor telemetry & audit device log data
  • Monitor telemetry with Prometheus & Grafana

참고: Vault는 기본적으로 standard output과 standard error에 로그를 기록하며, systemd journal이 자동으로 캡처합니다. 또한 Vault에 운영 로그 쓰기를 파일로 리디렉션하도록 지시할 수도 있습니다.

안티 패턴 문제: 클러스터 활동에 대한 부분적인 통찰력만 있으면 비즈니스가 반응적 상태에 머물게 될 수 있습니다.

사용량 기준선 수립 (Establish usage baseline)

기준선은 현재 사용률과 임계값에 대한 통찰력을 제공합니다. 텔레메트리 메트릭은 특히 시간이 지나며 모니터링할 때 가치가 있습니다. 텔레메트리 메트릭으로 클러스터 활동의 기준선을 수집하고, 알림으로 비정상 활동을 알릴 수 있습니다.

권장 패턴: 텔레메트리 정보는 Vault에서 다양한 메트릭 집계 솔루션으로 직접 스트리밍되어 집계와 검사를 위해 저장될 수도 있습니다.

  • Vault client usage
  • Diagnose server issues

안티 패턴 문제: 이 문제는 모니터 메트릭 권장 패턴과 밀접한 관련이 있습니다. 텔레메트리 데이터는 짧은 기간만 메모리에 보관됩니다.

root 토큰 사용 최소화 (Minimize root token use)

Vault 서버를 초기화하면 모든 Vault 기능에 걸쳐 루트 수준 접근 권한을 주는 초기 root 토큰이 발급됩니다.

권장 패턴: 환경에서 Vault를 초기화한 후 root 토큰을 폐기할 것을 권장합니다. 사용자가 상승된 접근 권한을 요구하면, Vault의 필요한 경로에 적절한 capabilities를 부여하는 접근 제어 목록 정책을 생성하세요. 운영에 root 토큰이 필요하면 폐기하기 전에 가능한 한 짧은 시간만 보관하세요.

  • Generate root tokens tutorial
  • Root tokens
  • Vault policies

안티 패턴 문제: root 토큰은 Vault 내의 모든 작업을 수행할 수 있고 만료되지 않습니다. 제한 없는 접근은 사용자에게 모든 Vault 작업과 경로에 대해 필요한 것보다 높은 권한을 줄 수 있습니다. root 토큰을 공유하거나 제공하는 것은 보안 위험을 초래합니다.

필요할 때 rekey (Rekey when necessary)

Vault는 봉인 해제 키를 이해 관계자에게 분배합니다. 초기화 설정에 따라 Vault를 봉인 해제하는 데 키의 쿼럼이 필요합니다.

권장 패턴: Vault는 rekey를 지원하므로, 필요할 때 rekey하는 워크플로를 수립해야 합니다.

  • Rekeying & rotating Vault
  • Operator rekey

안티 패턴 문제: 여러 이해 관계자가 조직을 떠나면 봉인 해제 쿼럼을 충족하는 데 필요한 키 공유를 갖지 못할 위험이 있으며, 이는 Vault를 봉인 해제하는 능력이 상실되는 결과를 초래할 수 있습니다.

더 알아보기 (Learn more)