[Vault] Basic

1. Vault란?

• Secrets에 안전하게 접근할 수 있도록 하는 도구(tool)
  • Secrets : API key, PW, Certificates, 등... 내가 엄격하게 접근 제어하고자 하는 모든 것을 포함한다.
• Vault는 어떠한 Secrets에 대해서도 단일화된 인터페이스를 제공하며, 이 과정에서 엄격한 접근 제어 및 상세한 audit logging을 제공한다..

최근의 시스템들은 여러 종류의 Secrets(DB credential, 외부 서비스를 위한 API Key, 등...)을 필요로 한다.
누가 어떤 Secrets에 접근할 수 있는지 이해하는 것은 이미 매우 어려운 일이며, 특정 플랫폼에 종속되기도 쉽다.
나아가 Key Rolling을 추가하거나 저장소를 보호하고, 상세한 Audit logging을 제공하는 것은 
Custom Solution을 배제했을 때 사실상 불가능한 일에 가깝다. Vault는 이러한 수요를 해결하기 위해 도입될 수 있다!

 

2. Key features of Vault

2-1. Secure Secret Storage - 안전한 Secret 저장소

• 임의의 Key / Value Secret를 Vault에 저장할 수 있다.
• Vault는 이러한 Secrets를 저장소에 쓰기 전에 우선적으로 암호화하며, RAW 스토리지가 Data에 얻어내더라도 Secrets 내용에 접근할 수 없도록 한다.
• Vault는 물리적인 Disk이외에도 Consul이나, 다른 클라우드 스토리지와 통합되어 쓰기 작업을 수행할 수 있다.

2-2. Dynamic Secrets - 동적 Secrets

• Vault는 AWS나 SQL DB와 같은 경우,온디맨드 방식에 따른 Secret 생성이 가능하다.
• 예를 들어, App.이 S3 버킷에 접근할 필요가 있을 경우 :
  • App.은 Vault에게 접근을 위한 Credential을 요구한다.
  • Vault는 요구에 맞는 유효한 권한을 포함한 AWS Keypair를 생성한다.
  • App.은 Vault가 동적으로 생성한 AWS Keypair를 통해 일정 시간 동안 S3 버킷에 접근한다.
• 동적 Secret을 생성한 후, Vault는 lease 기간을 측정하여 자동으로 자신이 생성한 동적 Secrets를 폐기(revoke)한다.

2-3. Data Encryption - Data 암호화

• Vault는 Data를 저장하지 않더라도 암호화하거나 복호화할 수 있다.
• 이는 보안 담당자가 암호화 파라미터를 정의하고, 개발 담당자가 자신만의 암호화 방식을 설계할 필요 없이 암호화된 Data를 SQL과 같은 장소에 저장할 수 있도록 한다.

2-4. Leasing and Renewal - 임대 및 갱신

• Vault의 모든 Secrets은 그들과 관련된 'lease'를 갖는다.
• lease 기간이 끝나면, Vault는 자동으로 Secret을 폐기(revoke)한다.
• Client들은 필요에 따라 Built-in renew APIs(Vault에 내장된 갱신 API들)를 통해 lease 기간을 갱신할 수 있다.

2-5. Revocation - 폐기

• Vault는 Secret 폐기에 대해 내장된 기능을 제공한다.
• Vault는 단일 Secrets 뿐만 아니라, Secrets Tree를 폐기할 수도 있다.
  • Secrets Tree는 예를 들어, 특정 User에게만 읽기 권한이 있는 모든 Secrets나, 특정 유형의 모든 Secrets 등을 포함할 수 있다.
• 폐기 기능은 Key Rolling은 물론, 침입 상황 발생시 System Lock-down에도 큰 도움이 될 수 있다.

 

3. Use Case

• 일반적인 암호화 저장소
• 직원 Credential 저장소
• Script를 위한 API Key 생성
• Data 암호화

 

4. Vault 용어 정리

4-1. Barrier

• Barrier는 Vault를 감싸듯이 설계된 암호화 장벽이다.
• Vault와 스토리지 백엔드 사이에 흐르는 모든 data는 barrier를 통한다.
• Barrier는 암호화된 data만 밖으로 기록될 수 있도록 보장하며, 그 과정에서 data가 확인되고 복호화될 수 있도록 돕는다.
• Vault 내부에 접근하고자 할 때, Barrier는 Unsealed 상태가 되어야 한다.
  • Sealed : Vault가 Barrier에 의해 보호되는 상태
  • Unsealed : Vault의 Barrier가 해제되어 내부 data에 접근이 가능한 상태

4-2. Storage Backend

• 암호화된 data를 저장할 책임이 있는 저장소
• 스토리지는 Vault에 의해 신뢰되지 않음
  • Vault는 스토리지 백엔드에 의해 스토리지의 지속성(durability)만 제공될 것으로 기대
• 스토리지 백엔드는 Vault Server가 시작될 때 설정되어야만 함

4-3. Secrets

• Vault에 의해 반환 요소 중 암호화되어야할 요소를 일컫는 용어이다.
  • Vault로부터 반환되는 요소 중에는 시스템 설정이나 상태 정보, 정책 등도 있기 때문에, Vault의 모든 정보를 Secret이라고 표현하지는 않는다.
• Secrets는 언제나 Lease와 연관된다.
  • 이는 즉, Client는 Secret이 무한히 지속될 것이라고 생각해서는 안된다는 것!

4-4. Secrets Engine

• Secrets 관리에 책임을 갖는 주체
• kv와 같은 간단한 시크릿 엔진은 쿼리 발생시 적절한 Secret을 리턴
• 몇몇 시크릿 엔진은 쿼리된 시점마다 동적인 Secret을 생성하기 위한 정책 할당 기능을 지원
  • 예를 들어, MySQL 시크릿 엔진에 대해 web 정책을 할당했다고 하자.
  • 웹 서버가 web secret에 대해 읽기 작업(read)을 수행할 때마다 :
    • 일정 시간 동안만 사용이 가능하고, 제한된 권한을 갖는 MySQL User / PW 페어가 반환된다.
    • 웹 서버는 반환된 ID / PW 페어를 통해 MySQL에 접근한다.

4-5. Auth Method

• Vault에 연결된 사용자나 App.을 인증(Authentication)하기 위해 사용된다.
• 한 번 인증된 후에, auth method는 적용되어야 할 정책들 중 사용 가능한 목록을 반환한다.
• Vault는 인증된 사용자를 확인한 후, 이후의 요청에서 사용될 Client Token을 반환한다.
  • 예를 들어, userpass Auth method는 사용자 인증에 username / PW를 사용한다.
  • github auth method는 사용자에 대해 GitHub을 통한 인증을 허용한다.

 

참고 URL : https://www.vaultproject.io/docs/what-is-vault