TL;DR
Zero Trust 환경 구성을 위해서 필수적인 '비밀 관리', API를 통해 이 요구사항을 Programmatic하게 구현하고, 회사 내의 기존 시스템과 통합할 수 있는 시스템을 제공하는 것이 바로 HashiCorp 사의 Vault 입니다.
이번 시리즈에서는 중앙 집중적인 비밀 관리 솔루션이 왜 필요한지, Vault가 Zero Trust 요구사항을 달성하기 위해 어떠한 기능을 제공하는지, Vault의 아키텍처는 어떻게 구성되어 있는지, 프로덕션 환경에 Vault를 배포하기 위해서는 어떻게 해야 하는지, 마지막으로 Vault를 이용해 비즈니스 환경의 어떠한 요구사항들에 대응할 수 있을지 알아볼 것입니다.
Zero Trust와 중앙 집중적인 비밀 관리 솔루션
Zero Trust의 핵심 철학은 지속적인 인증 (Authentication), 인가 (Authorization), 감사 (Audit) 프로세스를 전체 비즈니스 프로세스와 시스템에 통합하는 것입니다.
시스템에 접근하는 사용자는 행위를 수행할 때마다, 본인이 올바른 권한을 가지고 있는지를 검증하고, 검증 기록을 모니터링 시스템에 전달하여 이상 상황이 발생하였을 때 그것을 빠르게 감지하고, 보안팀이 적절한 대응을 취할 수 있게 합니다. 이를 통해 침해 사고가 발생하였을 때의 영향 범위를 최소한으로 억누를 수 있게 됩니다.
이러한 인증 및 권한 관리 모델을 성공적으로 시스템에 통합하기 위해서는, 기존의 '사람이 매번 인증을 수행하는', 또는 '정해진 키를 저장해 두고 인증을 수행하는' 방법으로는 요구사항을 만족시킬 수 없습니다. 모든 시스템은 실행/운영 과정에서 동적으로 상호 인증을 위한 키 값을 가져올 수 있어야 하며, 개별 인증을 가지고 접근할 수 있는 시스템의 범위 또한 엄격하게 제한될 필요가 있습니다.
다시 말해, 사람의 개입 없이 중앙 집중적으로 '비밀 (Secret)'을 관리하고, 필요할 때 읽어올 수 있는 저장소가 필요한 것입니다.
Vault는 이러한 기능을 수행하기 위해 만들어진 솔루션입니다.
사례 공유: 애플리케이션 API 인증 키 관리
많은 조직에서 API를 통해 애플리케이션 간 데이터를 공유합니다. 아무에게나 통신 권한을 열어줄 수는 없으니 API Key 기반의 인증을 구성합니다. 그 API 키는 초기 개발 단계에서 발급되고, 소스코드 또는 설정 파일에 저장됩니다.
일단 애플리케이션이 배포되면, 개발자는 API 키의 존재를 잊어버립니다. 관리되지 않는 API 키는 여러 방법을 통해 유출될 수 있고, 인가되지 않은 사용자가 애플리케이션에 접근할 수 있는 경로가 될 수 있습니다.
API 키의 존재를 인지하고 있더라도, 유효기간을 설정하고 로테이션 하는 작업은 어렵습니다.
시스템마다 API 키가 어디에 저장되어 있는지를 파악해야 하고, 개별 시스템들이 어떤 API 키를 가지고 있는지 확인, 애플리케이션 동작에 최소한의 영향을 미치는 방법으로 변경해야 합니다. SSL 인증서 교체와 마찬가지로 큰 작업이 될 수 밖에 없습니다.
때로는 중요한 토큰 또는 키 값이 외부에 유출되는 사고가 일어나기도 합니다. 부주의한 개발자가 토큰 값을 공개 저장소에 업로드하여 보안 사고가 발생한 사건은 이미 여러 번 들어 보셨을 것입니다.
이런 사건들 말이죠...
최근 발생한 사고 중, Github Actions 패키지가 공격당한 사건의 경우, 그로 인해 많은 조직들의 내부 키/토큰 정보가 해커에게 유출되었고, 영향을 받은 조직들은 최대한 빨리 키와 토큰을 새로 발급해야 했습니다. 기존의 시스템으로는 이러한 사고 상황에 제 때 대응하는 것이 물리적으로 어렵습니다.
하지만 Vault를 사용하면 이러한 작업들을 중앙 집중적으로 처리할 수 있습니다.
- 애플리케이션은 AppRole 인증을 기반으로 유효기간이 정해진 토큰을 발급합니다.
- 토큰을 사용해 Secret Engine에 저장된 Secret (API 키/토큰 등)에 접근합니다
- API 키나 토큰이 유출되면, Secret Engine에 저장된 데이터를 변경하고, 재시작 등으로 애플리케이션이 새 값을 가져오게 합니다
이렇듯, 인증 데이터를 애플리케이션과 완전히 분리하는 것으로, 사람의 개입을 최소화하면서 조직의 보안 태세를 강화할 수 있습니다.
Vault의 기능
Vault는 크게 세 가지 기능을 제공합니다.
- 비밀 저장소 (Secret Engine)
- 사용자 인증 (AuthN)
- 사용자 권한 관리 (Policy)
Vault는 비밀 (Secret)을 Secret Engine을 이용해 안전하게 저장하고, 사용자/애플리케이션은 여러 인증 방법 (OIDC, LDAP, AppRole 등)을 통해 Vault 토큰을 발행합니다.
발행된 토큰은 할당된 Policy를 기반으로 저장된 Secret에 접근할 수 있는 권한을 할당받습니다.
Vault가 제공하는 기능은 이렇듯 매우 단순하지만, 이러한 기능들을 안전하고 신뢰성 있게 제공하기 위해 HashiCorp는 10년이 넘는 시간 동안 많은 엔지니어링 리소스를 투입했습니다.
단순한 설계 이념과 강력한 API 지원이 합쳐져 Vault는 다른 비밀 관리 솔루션이 따라올 수 없는 수준의 유연성을 제공합니다. 이러한 Vault만의 가치는 많은 기업들이 Vault를 자신들의 내부 시스템과 통합하게 하는 주요 동인이 되었습니다.
Vault의 아키텍처 디자인
출처: HashiCorp Vault - Internal Architecture (https://developer.hashicorp.com/vault/docs/internals/architecture)
Vault를 운영 환경에 도입하기 위해서는 Vault의 내부 아키텍처와 요구사항 그리고 제한사항을 이해하는 것이 중요합니다.
앞서 설명한 기능들을 구현하기 위해, Vault는 위와 같이 여러 모듈을 가지고 있습니다. 여기서는 중요 모듈들에 대해 간단히 알아볼 것입니다.
Secret Engine
기업의 비밀 (Secret)을 저장하는 저장소입니다. 현재 최신 버전 (v1.19) 기준, Vault는 다음과 같은 Secret Enigne을 지원합니다.
이 중에서, 이번 시리즈에서 예제로 사용할 Secret Engine은 다음과 같습니다.
- Key-Value 쌍
- PKI 인증서
- SSH (OTP/Key)
Vault의 버전이 올라가면서 지원되는 Secret Engine도 늘어나고 있으며, Vault의 모듈형 아키텍처가 이러한 유연성을 뒷받침하고 있습니다.
Path Routing
Vault를 처음 접하는 분들에게는 생소한 개념이겠지만, Vault는 URI의 경로 (Path)를 기준으로 권한을 제어합니다.
그러한 권한 제어 규칙을 Policy 라 부르며, 한 사용자 (Identity)는 여러 개의 Policy를 가질 수 있습니다.
실제 Path 기반 Policy의 적용 예는 아래와 같습니다.
Capability와 Secret Engine Mount / Path에 대해서는 이후 포스트에서 실제 예제를 기반으로 보다 자세히 알아보게 될 것입니다.
Auth Method
Vault는 Vault Token의 발급을 위한 여러 Auth Method를 지원하며, 일부 Auth Method는 CLI를 통해 활성화 해야 사용할 수 있습니다.
이 시리즈에서는 다음과 같은 Auth Method를 사용할 것입니다.
- AppRole
- LDAP
Vault의 애플리케이션 통합을 위해서는 AppRole이 자주 사용된다는 점을 기억해 두십시오.
각 Auth Method의 사용법과 제약 사항은 이후의 포스팅에서 예시와 함께 자세하게 다룰 것입니다.
Audit Broker / Audit Device
'감사' 라는 단어에서 예상할 수 있듯이, Vault의 토큰 발행 및 인증 기록을 로그 형태로 저장하는 서비스를 말합니다.
Vault는 고가용성과 침해 상황에서의 무결성 보장을 위해 3개 이상의 Audit Device를 사용할 것을 권고하며, Zero Trust 아키텍처 구현을 위해 반드시 사용해야 하는 구성요소입니다.
Vault Audit Device의 Best Practice 아키텍처와 구성 방법에 대해서는 이후 포스트에서 예제와 함께 자세하게 다룰 것입니다.
마치며
이것으로 HashiCorp Vault의 개념과 기본 기능/아키텍처 소개를 마칩니다.
다음 포스팅에서는 프로덕션 환경에 Vault를 배포하기 위한 레퍼런스 아키텍처를 소개하고, 실제로 고가용성 구성 기반의 Vault 클러스터를 배포하는 과정을 실제 예시와 함께 알아볼 것입니다.
최근 들어 0~1day 공격에 의한 보안 침해 사고가 연일 뉴스에 오르고 있습니다.
0-day 공격을 근본적으로 막는 것이 불가능한 이상, 빠른 인지/식별/격리/차단이 유일한 대응 방법이며, 기업 규모를 불문하고 Zero Trust 아키텍처를 구축하는 일에 있어 제 경험이 도움이 되기를 바랍니다.
