[MinIO] MinIO Key Encryption Service(KES)

MinIO KES(Key Encryption Service)

MinIO Key Encryption Service (KES)는 고성능 애플리케이션을 위한 stateless한 분산 키 관리 시스템이다. KES는 컨테이너 기반(Kubernetes)의 현대적인 애플리케이션과 중앙 집중식 키 관리 서비스(KMS) 간의 연결 역할을 한다.

KES 작업 순서

1. 애플리케이션은 TLS(Transport Layer Security) 프로토콜을 통해 KES 서버에 접근
2. 애플리케이션은 KES 서버 API를 사용하여 새로운 암호화 키를 생성하는 등의 작업을 수행한다.
3. KES는 암호화 키를 포함한 모든 상태 정보가 저장되어 있는 KMS와 통신한다.
4. 하지만, 만일 상태를 가지지 않는 작업인 암호화, 복호화, 키 파생 등과 같은 작업은, KMS와의 통신 필요 없이, KES가 직접 처리하여 효율적인 키 관리를 수행한다.

KES Architecture

MinIO KES는 대규모 작업부하를 처리하기 위해 확장 가능한 아키텍처를 제공한다.

Kubernetes는 Horizontal Pod Autoscaler(HPA)와 같은 자동 스케일링 기능을 통해 현재 작업 부하에 기반하여 자동으로 리소스를 추가하거나 제공한다. 그러나 암호화 키를 보호하기 위해 설계된 하드웨어 보안 장치일 경우엔 자동 스케일링이 어려울 수 있다.

반면, KES는 애플리케이션과 KMS를 분리하여, 모든 애플리케이션 요청을 독자적으로 처리하고, 암호화키 생성/삭제 시에만 KMS와 통신하여 KMS에 대한 부하를 크게 줄여준다.

이러한 아키텍처를 통해 KES는 애플리케이션과 KMS 간의 상호 의존성을 줄이고, 수평으로 확장 가능한 솔루션을 제공하여 대규모 작업 부하를 처리할 수 있다.

KES Access Control

KES는 클라이언트의 요청에 인증 및 권한을 부여하기 위해 mTLS 인증(mutual TLS authentication)을 사용한다.

mTLS는 상호 인증 및 권한 부여를 위해 클라이언트와 서버 간의 상호 인증을 수행하는 TLS(Transport Layer Security) 프로토콜의 한 형태이다. KES에서 mTLS를 사용함으로써 클라이언트는 KES 서버에 대한 신뢰성 있는 인증을 받고, 서버는 클라이언트의 신원을 확인하여 요청을 승인하거나 거부할 수 있다.

인증(Authentication)

클라이언트와 서버는 상대에게 자신의 x.509 인증서와 해당 인증서에 대한 개인키를 보여주어 인증 절차를 진행한다. 서버는 클라이언트 인증서가 유효하고 인증된 경우에만 연결을 허용한다.

이를 통해 mTLS를 사용한 인증은 클라이언트 및 서버 상의 상호 신뢰성을 확인하고 인증된 연결을 수립하는데 사용한다.

테스트 및 초기 개발시

테스트나 초기 개발 시에는 신뢰되지 않거나 자체 서명된 인증서를 사용할 수 있으며, 이를 위해 kes server --auth 옵션을 사용하여 KES 서버를 시작할 수 있다. 이는 보안 인증서가 아닌 인증서를 사용하여 mTLS를 수행할 수 있는 유연성을 제공한다. 그러나 MinIO는 운영 환경에서는 신뢰할 수 있는 인증서만 허용하는 것을 강력히 권장한다.

권한(Authorization)

KES는 정책 기반의 접근 제어(Policy-Based Access Control, PBAC)를 사용하여 특정 클라이언트가 수행할 수 있는 작업을 결정한다. 각 정책은 하나 이상의 신원(identity)으로 구성되며, 각 신원은 클라이언트와 서버의 x.509 인증서 SHA-256 해시값으로 확인할 수 있다. 서버는 다음 조건이 참인 경우에만 클라이언트가 요청한 작업을 수행할 수 있도록 허용한다

• KES 서버에 해당 클라이언트 신원을 포함하는 정책이 존재
• 정책이 요청한 작업을 명시적으로 허용

만약 KES 서버에 해당하는 정책이 존재하지 않거나, 정책이 요청한 작업을 명시적으로 허용하지 않는 경우, KES 서버는 클라이언트의 요청을 거부한다.

KES Policies

KES 서버 정책은 어떤 리소스에서 어떤 API 작업이 허용되거나 거부되는지 정의하는 일련의 규칙을 정의하여, 클라이언트의 요청을 허용할지 여부를 결정한다.

일반적으로 정책의 패턴은 아래와 같은 형식이다.

/<API-version>/<API>/<operation>/[<argument0>/<argument1>/...]

만일 거부 패턴이 일치하거나, 허용 패턴이 일치하지 않으면 prohibited by policy 오류와 함께 요청을 거부한다.

allow, deny

아래 정책 yaml 파일 중 일부 예시를 보자.

policy:
  my-policy:
    allow:
    - /v1/metrics
    - /v1/key/create/my-key
    - /v1/key/generate/my-key*
    - /v1/key/decrypt/my-key*
    deny:
    - /v1/key/*/my-key-internal*

이 코드는 “my-policy”라는 이름의 정책이 정의되어 있다. 이 정책은 allow 규칙 4개와 deny 규칙 1개를 정의하고 있다.

먼저 deny 규칙이 처리된다.

my-key-internal라는 접두사를 가진 모든 키에 대한 key API(key/*/)를 금지하는 deny 규칙이 정의 되어 있다. 예로 /v1/key/create/my-key-internal, /v1/key/generate/my-key-internal, /v1/key/generate/my-key-internal2와 같은 요청은 거부된다.

deny 규칙 처리 후, allow 규칙에 따라 요청을 평가한다.

우선 /v1/key/create/my-key는 my-key라는 이름의 키를 생성하는 요청을 허용한다. 하지만 my-key2와 같은 다른 문자 조합으로 키 생성은 정책에 의해 금지된 오류로 반환한다.

/v1/key/generate/my-key*와 /v1/key/decrypt/my-key*는 사용자가 새로운 데이터 암호화 키(DEK)를 생성하거나, 암호화된 DEK를 복호화하는 요청을 할 경우, my-key라는 접두사를 가진 모든 키를 허용한다. 예로, /v1/key/generate/my-key 또는 /v1/key/generate/my-key2는 허용하지만, /v1/key/generate/key-to-generate1은 거부한다.

paths, identities

아래처럼 paths를 통해 API작업을 허용하는지 명시할 수도 있다. 또한 identites를 통해 특정 클라이언트에만 권한을 부여할 수도 있다. 아래 예시인 “minio-sse”라는 이름의 정책은 MinIO 서버 측 암호화(MinIO Server-Side Encryption)를 지원하기 위한 API 엔드포인트가 기술되어 있다.

policy:
   minio-sse:
      paths:
      - /v1/key/create/*
      - /v1/key/generate/*
      - /v1/key/decrypt/*
      - /v1/key/delete/*
      identities:
      - <SHA-256 HASH>

• policy.policyname.paths는 minio-sse 정책이 접근 권한을 부여하는 API 엔드포인트 이다.
• policy.policyname.identities는 클라이언트의 x.509 인증서 SHA-256 해시값이다.

정책과 identities는 1:N 관계를 가지며, 한 정책에는 여러 identities를 포함시킬 수 있다. 그러나 하나의 identities는 한 번에 최대 하나의 정책과 연결될 수 있다.

KES 서버는 2가지 정책 구성 방법을 제공한다.

• KES 구성 파일을 통한 정책 영구 적용
• kes policy 또는 kes identity를 통한 KES 서버의 일시적인 정책 생성

kes policy 또는 kes identity를 사용하여 생성하거나 수정한 정책은 KES 서버를 다시 시작하면 사라지게 된다.

Integrations KMS

MinIO KES 공식문서에 나와있는 통합 지원 KMS는 아래와 같다.

• AWS Secrets Manager: 아마존 웹 서비스(AWS)의 키 관리 서비스로, 암호화 키와 다른 보안 자원을 안전하게 저장하고 관리하는 데 사용.
• Azure Key Vault: 마이크로소프트 Azure의 키 관리 서비스로, 보안 키, 암호 및 인증서와 같은 중요한 정보를 안전하게 저장하고 액세스할 수 있도록 지원.
• Fortanix SDKMS: Fortanix의 Secure Data Kit Management System(SDKMS)로, 클라우드 및 온프레미스 환경에서 키와 암호를 안전하게 저장하고 관리하는 데 사용.
• Google Cloud Secret Manager: Google Cloud의 키 관리 서비스로, 암호화 키, API 토큰 및 기타 비밀 정보를 안전하게 저장하고 액세스할 수 있도록 지원.
• Hashicorp Vault Keystore: Hashicorp Vault는 오픈 소스의 보안 키 저장소로, 다양한 비밀 정보 및 암호화 키를 안전하게 저장하고 액세스할 수 있도록 지원.
• Thales CipherTrust Manager (formerly Gemalto KeySecure): Thales의 CipherTrust Manager는 키 및 암호 관리 시스템으로, 다양한 암호화 솔루션과 통합하여 키 라이프사이클 및 보안 요구 사항을 관리.

MinIO KES에 대한 더 자세한 설명은 공식문서를 참고하기 바란다.