보안 모델
보안 모델 (Security model)
Vault의 특성과 관리하는 데이터의 기밀성 때문에 Vault 보안 모델은 매우 중요합니다. Vault 보안 모델의 전반적인 목표는 기밀성(confidentiality), 무결성(integrity), 가용성(availability), 책임성(accountability), 인증(authentication)을 제공하는 것입니다.
출처: 문서
본문
이것은 저장 중(at rest) 데이터와 전송 중(in transit) 데이터가 도청이나 변조로부터 안전해야 함을 의미합니다. 클라이언트는 데이터에 접근하거나 정책을 수정하도록 적절히 인증되고 인가되어야 합니다. 모든 상호작용은 감사 가능하고 원래 엔티티까지 고유하게 추적되어야 하며, 시스템은 접근 제어를 우회하려는 의도적인 시도에 대해 견고해야 합니다.
위협 모델 (Threat model)
다음은 Vault 위협 모델의 다양한 부분입니다:
- Vault 통신 도청 — Vault와의 클라이언트 통신뿐 아니라 Vault에서 스토리지 백엔드로, 또는 Vault 클러스터 노드 간 통신도 도청으로부터 안전해야 합니다.
- 저장 중 또는 전송 중 데이터 변조 — 모든 변조는 감지 가능해야 하며 Vault가 해당 트랜잭션 처리를 중단하게 해야 합니다.
- 인증이나 인가 없는 데이터 또는 제어 접근 — 모든 요청은 적용 가능한 보안 정책이 선행되어야 합니다.
- 책임성 없는 데이터 또는 제어 접근 — 감사 로깅이 활성화되면 클라이언트가 시크릿 자료를 받기 전에 요청과 응답이 로깅되어야 합니다.
- 저장된 시크릿의 기밀성 — Vault에서 나가 스토리지 백엔드에 저장되는 모든 데이터는 도청으로부터 안전해야 합니다. 실제로 모든 저장 중 데이터는 암호화되어야 함을 의미합니다.
- 장애 상황에서 시크릿 자료의 가용성 — Vault는 가용성 손실을 피하기 위해 고가용성 구성으로 실행되는 것을 지원합니다.
다음은 Vault 위협 모델의 일부로 간주되지 않습니다:
- 스토리지 백엔드의 임의 제어로부터 보호 — 스토리지 백엔드에 대해 임의 작업을 수행할 수 있는 공격자는 보호하기 어렵거나 불가능한 다양한 방식으로 보안을 훼손할 수 있습니다. 예를 들어 공격자는 스토리지 백엔드의 모든 내용을 삭제하거나 손상시켜 Vault에 대한 완전한 데이터 손실을 일으킬 수 있습니다. 읽기를 제어하는 능력은 공격자가 잘 알려진 상태로 스냅샷을 만들고, 이득이 된다면 상태 변경을 롤백할 수 있게 합니다.
- 시크릿 자료 존재의 유출로부터 보호 — 스토리지 백엔드에서 읽을 수 있는 공격자는 시크릿이 기밀로 유지되더라도 시크릿 자료가 존재하고 저장되어 있음을 관찰할 수 있습니다.
- 실행 중인 Vault의 메모리 분석으로부터 보호 — 공격자가 실행 중인 Vault 인스턴스의 메모리 상태를 검사할 수 있다면 데이터의 기밀이 손상될 수 있습니다.
- Vault가 사용하는 외부 시스템이나 서비스의 결함으로부터 보호 — 일부 인증 메서드나 시크릿 엔진은 민감한 작업을 Vault 외부의 시스템에 위임합니다. 공격자가 이러한 외부 시스템의 자격 증명을 손상시키거나 취약점을 악용하면 데이터의 기밀성이나 무결성이 손상될 수 있습니다.
- 기본 호스트의 악성 플러그인 또는 코드 실행으로부터 보호 — 공격자가 기본 호스트에서 코드 실행이나 쓰기 권한을 얻으면 데이터의 기밀성이나 무결성이 손상될 수 있습니다.
- Vault에 접근하는 클라이언트나 시스템의 결함으로부터 보호 — 공격자가 Vault 클라이언트(예: 시스템, 브라우저)를 손상시키고 이 클라이언트의 Vault 자격 증명을 얻으면, 이 클라이언트와 연결된 권한 수준으로 Vault에 접근할 수 있습니다.
- Vault 관리자가 취약하거나 악성인 구성 데이터를 제공하는 것으로부터 보호 — Vault의 관리 엔드포인트(예: 시크릿 엔진 구성)나 Vault 구성 파일에 구성 값으로 제공되는 모든 데이터는 검증되어야 합니다. 공격자가 Vault 구성에 쓸 수 있다면 데이터의 기밀성이나 무결성이 손상될 수 있습니다.
외부 위협 개요 (External threat overview)
Vault 아키텍처는 세 가지 뚜렷한 시스템으로 구성됩니다:
- 클라이언트 (Client) — API를 통해 Vault와 통신합니다.
- 서버 (Server) — API를 제공하고 요청을 처리합니다.
- 스토리지 백엔드 (Storage backend) — 서버가 데이터를 읽고 쓰는 데 사용합니다.
Vault 클라이언트와 서버 사이에는 상호 신뢰가 없습니다. 클라이언트는 TLS를 사용해 서버의 신원을 검증하고 안전한 통신 채널을 설정합니다. 서버는 모든 요청에 대해 클라이언트가 클라이언트 토큰을 제공할 것을 요구하며, 그 토큰은 클라이언트를 식별하는 데 사용됩니다. 토큰을 제공하지 않는 클라이언트는 로그인 요청만 할 수 있습니다.
클러스터 내의 Vault 인스턴스 간 모든 서버-서버 트래픽(즉, 고가용성, Enterprise 복제, 인터그레이티드 스토리지)은 상호 인증된 TLS를 사용해 전송 중 데이터의 기밀성과 무결성을 보장합니다. 노드는 봉인 해제 챌린지이나 일회용 활성화 토큰으로 클러스터에 가입하기 전에 인증됩니다.
Vault가 사용하는 스토리지 백엔드도 설계상 신뢰되지 않습니다. Vault는 백엔드에 대한 모든 요청에 보안 장벽(security barrier)을 사용합니다. 보안 장벽은 96비트 nonce가 있는 GCM(Galois Counter Mode)에서 256비트 AES(AES) 암호를 사용해 Vault를 떠나는 모든 데이터를 자동으로 암호화합니다. nonce는 모든 암호화 객체마다 무작위로 생성됩니다. 보안 장벽에서 데이터를 읽을 때 GCM 인증 태그는 복호화 과정에서 검증되어 변조를 감지합니다.
사용되는 백엔드에 따라 Vault는 추가 보안 계층을 제공하기 위해 백엔드와 TLS로 통신할 수 있습니다. 파일 백엔드 같은 경우에는 적용되지 않습니다. 스토리지 백엔드는 신뢰되지 않으므로, 백엔드와의 통신이 가로채어져도 도청자는 암호화된 데이터에만 접근하게 됩니다.
내부 위협 개요 (Internal threat overview)
Vault 시스템 내에서 중요한 보안 관심사는 공격자가 인가받지 않은 시크릿 자료에 접근하려 시도하는 것입니다. 공격자가 이미 Vault에 어느 정도 접근이 허용되어 있고 인증할 수 있다면 이것은 내부 위협입니다.
클라이언트가 처음 Vault에 인증하면 auth 메서드가 클라이언트의 신원을 검증하고 연결된 ACL 정책 목록을 반환하는 데 사용됩니다. 이 연결은 Vault 운영자가 사전에 구성합니다. 예를 들어 "engineering" 팀의 GitHub 사용자가 "engineering" 및 "ops" Vault 정책에 매핑될 수 있습니다. 그러면 Vault는 무작위로 생성된 직렬화 값인 클라이언트 토큰을 생성해 정책 목록에 매핑합니다. 이 클라이언트 토큰은 그 후 클라이언트에 반환됩니다.
각 요청에서 클라이언트는 이 토큰을 제공합니다. Vault는 그 토큰을 사용해 토큰이 유효하고 폐기되거나 만료되지 않았는지 확인하고, 연결된 정책에 기반해 ACL을 생성합니다. Vault는 엄격한 기본 거부(default deny) 적용 전략을 사용합니다. 즉, 연결된 정책이 특정 동작을 허용하지 않는 한 거부됩니다. 각 정책은 Vault의 경로에 부여된 접근 수준을 지정합니다. 정책이 병합될 때(클라이언트에 여러 정책이 연결된 경우) 허용된 가장 높은 접근 수준이 사용됩니다. 예를 들어 "engineering" 정책이 "eng/" 경로에 대한 읽기/업데이트 접근을 허용하고 "ops" 정책이 "ops/" 경로에 대한 읽기 접근을 허용하면, 사용자는 그 둘의 합집합을 얻습니다. 정책은 가장 구체적으로 정의된 정책으로 일치되며, 정확히 일치하거나 가장 긴 접두사 일치 glob 패턴일 수 있습니다. 자세한 내용은 Policy Syntax를 참고하세요.
특정 작업은 Vault에 내장된 특별한 정책인 "root" 사용자에게만 허용됩니다. 이것은 Unix 시스템의 root 사용자나 Windows의 관리자 개념과 비슷합니다. 클라이언트에 root 토큰이 제공되거나 root 정책과 연결된 경우, Vault는 "sudo" 권한의 개념을 지원합니다. 정책의 일부로 사용자에게 특정 경로에 대한 "sudo" 권한을 부여할 수 있어, Vault에 대한 전역 root 접근을 부여하지 않고도 보안에 민감한 작업을 계속 수행할 수 있습니다.
마지막으로 Vault는 Shamir's Secret Sharing 기법으로 봉인 해제에 투인원칙(Two-person rule)을 사용하는 것을 지원합니다. Vault가 시작되면 봉인된 상태로 시작합니다. 이것은 스토리지 백엔드에서 읽고 쓰는 데 필요한 암호화 키가 아직 알려지지 않았음을 의미합니다. 봉인 해제 과정은 암호화 키를 검색할 수 있도록 root 키를 제공해야 합니다. root 키 분배의 위험은, 접근할 수 있는 악성 공격자 한 명이 전체 Vault를 복호화할 수 있다는 것입니다. 대신 Shamir 기법은 root 키를 여러 공유(share) 또는 부분으로 나눌 수 있게 해줍니다. 공유 수와 필요한 임계값은 구성 가능하지만, 기본적으로 Vault는 5개 공유를 생성하며 그중 아무 3개를 제공해야 root 키를 재구성할 수 있습니다.
비밀 공유 기법을 사용함으로써 root 키 보유자에게 절대적인 신뢰를 두지 않아도 되며 root 키를 저장하지 않아도 됩니다. root 키는 공유를 재구성함으로써만 검색할 수 있습니다. 공유는 Vault에 어떤 요청을 하는 데도 쓸 수 없고 봉인 해제에만 사용할 수 있습니다. 일단 봉인 해제되면 모든 요청에 표준 ACL 메커니즘이 사용됩니다.
비유를 들자면, 은행은 금고(vault) 안에 보안 금고함(security deposit box)을 둡니다. 각 보안 금고함에는 열쇠가 있고, 금고 문에는 조합과 열쇠가 모두 있습니다. 금고는 강철과 콘크리트로 둘러싸여 있어 문이 유일한 실용적인 입구입니다. Vault에 대한 비유는 암호 시스템이 데이터를 보호하는 강철과 콘크리트라는 것입니다. 콘크리트를 뚫거나 암호화 키를 무차별 대입할 수는 있겠지만, 엄청난 시간이 걸립니다. 은행 금고를 여는 데는 열쇠와 조합이라는 두 가지 요소가 필요합니다. 마찬가지로 Vault도 root 키를 재구성하려면 여러 공유를 제공해야 합니다. 일단 봉인 해제되면 각 보안 금고함은 여전히 소유자가 열쇠를 제공해야 하며, 마찬가지로 Vault ACL 시스템이 저장된 모든 시크릿을 보호합니다.