분할 신뢰 암호화 도구 (STET)는 Google Cloud 내부자로부터 검증 가능하고 암호화 방식으로 보호되는 방식으로 Google Cloud 안팎에서 보안 키 데이터를 전송할 수 있는 배포 메커니즘을 제공합니다.
이는 두 개의 키 관리 시스템 (KMS)을 사용하여 이루어집니다. 하나는Google Cloud내부이고 다른 하나는 외부입니다. 하나의 KMS가 손상되더라도 두 번째 KMS가 데이터를 비공개로 유지하는 데 도움이 됩니다.
다음은 Cloud Storage로 전송되고 Compute Engine VM을 사용하여 계산되는 데이터와 관련된 일련의 예시입니다. 이 예에서는 보안 수준을 높여 STET가 보안 흐름에 어떻게 적용되는지 설명합니다.
1단계: Cloud Storage
Google Cloud로 데이터를 수집할 때 Cloud Storage를 사용하여 클라우드 워크로드에서 데이터를 사용할 수 있습니다. 온프레미스 컴퓨팅 환경의 데이터를 Cloud Storage 버킷에 업로드하고, 워크로드가 해당 버킷에 액세스할 수 있도록 권한을 부여하며, 워크로드 (또는 여러 워크로드)가 필요에 따라 해당 데이터를 소비할 수 있도록 할 수 있습니다. 이 전략을 이용하면 필요한 데이터를 보내기 위해 작업 부하에 직접 활성 연결을 만들어야 하는 복잡성을 피할 수 있습니다.
Cloud Storage는 항상 저장 데이터를 암호화합니다. 하지만 Cloud Storage가 사용자 대신 암호화를 수행하는 것을 신뢰하기 위해서는 암호화된 데이터 (암호문)를 만들기 위해 사용되는 암호화 키는 물론, 암호화 전 암호화되지 않은 데이터 (일반 텍스트)에 대한 액세스 권한을 반드시 부여해야 합니다. 위협 모델에 따라 Cloud Storage가 일반 텍스트에 대한 가시성을 얻을 수 없도록 이를 Cloud Storage로 전송하기 전 데이터를 암호화하는 것이 바람직할 수 있습니다.
수준 2: 클라이언트 측 암호화
클라이언트 측 암호화를 사용하면 Cloud Storage로 업로드되기 전 데이터를 암호화하고 워크로드에 다운로드된 다음에만 이를 복호화합니다. 따라서 Cloud Storage는 암호문에만 액세스하고 일반 텍스트에는 액세스하지 못합니다. Cloud Storage는 데이터를 저장하기 전 또 다른 암호화 계층을 추가하지만, 데이터의 기본 보호는 업로드 전에 수행되는 암호화입니다.
이 방법을 사용하면 이제 사용자는 데이터 복호화에 필요한 암호화 키에 대한 액세스 권한을 워크로드에 부여해야 합니다. 암호화 키를 사용하면 기존 암호화 레이어를 삭제하고 데이터에 대한 가시성을 확보할 수 있기 때문에 이것 자체는 잠재적으로 어려운 작업입니다.
수준 3: 외부 키 관리
이 키 관리 문제에 접근하는 일반적인 방법은 키를 보관하고 키에 대한 액세스를 관리하는 전용 키 관리 서비스(KMS)를 이용하는 것입니다. 각 암호화 또는 복호화 시도마다 KMS로 요청을 전송해야 합니다. KMS는 적절한 당사자만 데이터를 복호화할 수 있도록 다양한 기준에 따라 액세스 권한을 부여할 수 있습니다.
KMS 시스템은 암호화 키에 대한 액세스를 승인하기 전에 여러 요건을 충족할 것을 요구하지만 일반적으로 KMS에 설정된 정책과 일치하는 사용자 인증 정보가 필요합니다. 따라서 이 사용자 인증 정보를 보유한 모든 당사자는 암호화 키에 액세스하여 데이터를 복호화할 수 있습니다.
4단계: 컨피덴셜 컴퓨팅
컨피덴셜 VM 인스턴스는 메모리를 암호화한 상태로 실행되므로 사용 중 의도하지 않은 데이터 액세스에 대한 추가적인 보호를 누릴 수 있습니다. 많은 위협 모델에서 컨피덴셜 VM 인스턴스는 표준 인스턴스보다 신뢰도가 높기 때문에 민감한 워크로드에도 사용할 수 있습니다.
위협 모델이 컨피덴셜 컴퓨팅에 의존하는 경우 한 가지 문제는 컨피덴셜 VM 인스턴스에서 워크로드가 실행되는지 확인하는 것입니다. 원격 증명은 워크로드가 컨피덴셜 VM 인스턴스에서 실행 중임을 원격 당사자에게 증명하고 워크로드의 구성 및 환경에 대한 다른 여러 속성을 확인할 수 있는 방법입니다. 증명은 플랫폼에서 생성되므로 워크로드는 실제 환경을 반영하지 않는 거짓 증명을 만들 수 없습니다.
KMS는 키 액세스를 허용하기 전 이러한 증명을 요구하고 평가할 수 있습니다. 이러한 요구는 일반 사용자 인증 정보가 손상되더라도 의도된 워크로드만 데이터 복호화가 허용되도록 보장하는 데 도움이 됩니다.
수준 5: 분할 신뢰
단일 KMS를 사용할 때 이 KMS에는 암호화 키에 대한 단독 제어 권한이 부여됩니다. KMS 운영자가 암호화된 데이터의 암호문을 획득해야 한다면 이를 일반 텍스트로 복호화하기 위해 필요한 모든 것을 가져야 할 것입니다. KMS가 완전히 신뢰할 수 있는 항목에 의해 운영되는 경우에는 이러한 위험이 허용될 수 있지만 일부 위협 모델에 따라 KMS에서 일방적인 제어 권한을 삭제해야 할 필요가 있습니다.
STET를 사용하면 두 KMS 시스템 간에 이 신뢰를 분할할 수 있으며, 두 KMS 모두 데이터를 복호화할 수 있는 충분한 정보를 갖지 않습니다. 데이터를 복호화하려면 두 KMS 연산자(또한 암호문 액세스) 사이의 결탁이 필요합니다.
컨피덴셜 VM을 사용하는 경우 STET는 증명이 필요한 KMS에 저장된 키를 사용하여 데이터의 암호화와 복호화를 용이하게 합니다.
이 모두를 종합하면, STET는 데이터의 원본 작성자 (예: 온프레미스 시스템)와 데이터의 소비자 (예: 컨피덴셜 VM 인스턴스에서 실행되는 워크로드)만이 일반 텍스트 데이터에 액세스할 수 있는 유일한 항목이 되도록 돕습니다.
STET 사용에 관한 자세한 내용은 GitHub 저장소 및 빠른 시작 가이드를 참고하세요.
STET를 사용한 Confidential Space
Confidential Space를 사용하는 경우 STET는 Cloud KMS에 저장된 키 암호화 키 (KEK)에 액세스할 때 Confidential Space의 증명 토큰을 증명 증거로 사용할 수 있습니다.
STET는 워크로드의 Cloud KMS 키에 대한 액세스를 처리하고 Confidential Space를 사용하여 암호화 워크플로, 복호화 워크플로 또는 암호화 및 복호화 워크플로 모두에 대한 증명을 실행할 수 있도록 지원합니다.
워크로드 ID 풀 (WIP) 이름, Cloud KMS URI, 복호화 정보와 같은 정보가 포함된 STET 구성을 만들 수 있습니다. 그런 다음 STET는 이 정보를 사용하여 비공개 공간 설정에 통합합니다.
자세한 내용은 GitHub 저장소 및 기밀 정보 공간 통합 가이드를 참고하세요.