software

신뢰하지 말고 검증하라: Google Cloud에서 엔드‑투‑엔드 기밀 애플리케이션 구축

발행: (2026년 1월 6일 오전 11:56 GMT+9)
21 min read
원문: Google Developers Blog

Source: Google Developers Blog

DEC. 9, 2025

오늘날 데이터 중심의 세상에서는 민감한 데이터 카테고리에 의존하는 귀중한 인사이트가 많이 있습니다—개인 맞춤 서비스를 위한 개인 식별 정보(PII) 처리, 파트너와의 기밀 데이터셋 협업, 혹은 민감한 재무 정보 분석 등 말이죠. 데이터 휴식 상태나 전송 중이 아니라 처리 중에도 보호해야 한다는 요구가 중요한 비즈니스 요구사항이 되었습니다.

디스크에 저장된 데이터‑at‑rest와 네트워크를 통한 데이터‑in‑transit에 대한 암호화는 잘 알려진 문제이지만, “데이터‑in‑use” 문제는 종종 간과됩니다. 여기서 Confidential Computing이 등장해, 데이터가 처리되는 동안에도 하드웨어 수준의 보호를 제공합니다.

이 글에서는 Google Cloud의 Confidential Space를 활용해 조직이 엔드‑투‑엔드 기밀 서비스를 구축할 수 있는 방법을 보여줍니다. 최종 사용자가 검증된 코드가 보안이 강화된 하드웨어 격리 환경 내부에서만 실행되어 자신의 민감한 데이터가 오직 처리된다는 암호학적 보증을 얻을 수 있는 방식을, 확장 가능하고 로드 밸런싱된 아키텍처로 배포된 서비스에서도 어떻게 구현할 수 있는지 설명합니다.

규모에서 신뢰와 기밀성의 도전

현대적인 확장 가능한 클라우드 환경에서 기밀 서비스를 운영하는 데는 두 가지 주요 과제가 있습니다:

  1. 신뢰와 투명성
    고객은 자신의 데이터를 처리하는 코드의 프라이버시 속성을 검증할 수 있는 방법이 필요합니다. 전체 애플리케이션을 오픈소스로 공개하면 이 문제를 해결할 수 있지만, 귀중한 지적 재산, 독점 알고리즘, 혹은 민감한 AI 모델을 보호해야 하는 기업에게는 불가능합니다.
    운영자는 가치를 지니는 소스 코드를 공개하지 않고도 서비스가 기밀함을 어떻게 증명할 수 있을까요?

  2. 확장성
    현대 클라우드 애플리케이션은 복원력과 확장성을 위해 설계되며, 일반적으로 로드 밸런서 뒤에서 여러 서비스 인스턴스를 실행합니다.

    • 로드 밸런서에서 TLS를 종료하면 키 관리가 간소화되지만, 로드 밸런서에서 평문 데이터를 검사 및 라우팅하기 위해 노출하게 되어 종단 간 기밀성이 깨지고 신뢰 컴퓨팅 베이스(TCB)가 확대됩니다.
    • 각 백엔드 서버에서 TLS를 종료하면 모든 인스턴스에 TLS 개인 키를 안전하게 배포해야 하며, 이 키들이 워크로드의 공격 표면에 포함됩니다.

Source: …

Google Cloud Confidential Space와 Oak Functions로 신뢰 고정하기

솔루션은 강력하고 하드웨어로 강제된 기반인 Google Cloud Confidential Space에서 시작됩니다. 이는 최첨단 기밀 컴퓨팅 하드웨어 위에 구축된 강화된 신뢰 실행 환경(TEE)입니다. 코드와 데이터를 다음으로부터 보호하는 하드웨어 격리 메모리 엔클레이브를 생성합니다:

  • 호스트 OS,
  • 다른 테넌트,
  • 클라우드 제공자,
  • 심지어 클라우드 프로젝트 소유자까지.

이 환경이 제공하는 핵심 원시 기능은 **인증(attestation)**입니다: 환경의 무결성과 내부에서 실행되는 모든 Open Container Initiative(OCI) 컨테이너의 신원을 증명하는 플랫폼 서명 보고서입니다.

전체 워크로드 투명성이 불가능할 때(예: 독점 코드), 우리는 Oak Functions 라는 검증 가능한 사설 샌드박스 안에서 애플리케이션 로직을 컨테이너화하여 실행합니다. 이 샌드박스는 비즈니스 로직 코드가 다음을 수행하지 못하도록 방지합니다:

  • TEE 외부에 로그를 남기거나 데이터를 저장하는 행위,
  • 임의의 네트워크 연결을 생성하는 행위,
  • 명시적으로 허용되고 제어된 인터페이스를 통해서만 신뢰할 수 없는 호스트와 상호 작용하는 행위.

결과: 사용자의 신뢰는 잘 정의된 오픈소스 샌드박스(누구나 재현 가능하게 빌드할 수 있음)와 샌드박스 개발자의 보증에 앵커링되며, 실행되는 구체적인 로직에 의존하지 않습니다. 이는 신뢰 스토리를 단순화합니다: 사용자는 복잡한 맞춤형 애플리케이션 대신 작고 투명한 Oak Functions 컨테이너 이미지만 검증하면 됩니다.

인증된 엔드‑투‑엔드 암호화(Oak Session)로 신뢰 구축

로드‑밸런싱 경로를 통해 신뢰할 수 있는 연결을 가능하게 하려면 표준 네트워크‑레벨 TLS 위에 애플리케이션‑레벨 암호화를 겹칩니다. 이를 위해 **Oak Session**을 사용합니다. Oak Session은 엔드‑투‑엔드 암호화 세션 프로토콜을 구현한 오픈‑소스 라이브러리로, 로드 밸런서와 같은 신뢰할 수 없는 중간자를 거쳐도 인클레이브 내부의 애플리케이션 로직과 직접 보안 채널을 구축합니다.

Oak Session의 주요 특징

  • 중첩된 엔드‑투‑엔드 암호화 채널 – 외부 TLS 연결 안에 암호화 채널을 열어, 기밀 워크로드와 직접 통신합니다. 외부 TLS 연결이 로드 밸런서에서 종료되더라도 내부 데이터는 보호됩니다.
  • Noise 프로토콜 프레임워크 – 중첩 채널에 TLS를 사용할 수도 있지만, Oak Functions는 유연성과 강력한 암호학적 보장을 제공하는 Noise 프레임워크를 선택했습니다.

작동 방식(고수준 흐름)

  1. 인증(Attestation) – Confidential Space 인스턴스가 기대하는 Oak Functions 컨테이너가 실행 중임을 증명하는 인증 문서를 생성합니다.
  2. 검증(Verification) – 클라이언트는 인증서(서명, 측정값 등)를 검증하여 변조되지 않은 진정한 인클레이브와 통신하고 있음을 확인합니다.
  3. 세션 설정(Session Establishment) – Oak Session(Noise)을 사용해 클라이언트와 인클레이브가 상호 키 교환을 수행하고, 인클레이브와 클라이언트만 알 수 있는 대칭 암호화 키를 생성합니다.
  4. 데이터 전송(Data Transfer) – 모든 페이로드는 이 세션 키로 암호화되어, 외부 TLS 연결이 로드 밸런서에서 종료되더라도 기밀성과 무결성을 보장합니다.

모두 합쳐서

다음 요소들을 결합하여:

  • Google Cloud Confidential Space – 하드웨어 기반 격리 및 증명 제공
  • Oak Functions – 최소한의 오픈소스, 재현 가능한 샌드박스
  • Oak Session – 중첩된 종단 간 암호화

확장 가능하고 기밀성을 보장하는 서비스를 구현합니다. 이 서비스는:

  • 데이터 프라이버시를 전체 수명 주기(저장, 전송, 사용 중) 동안 보장합니다.
  • 고객이 기밀성 보장을 검증할 수 있게 하면서도 자체 코드를 노출하지 않습니다.
  • 로드 밸런서를 포함해도 TCB를 확장하지 않고 로드 밸런싱된 배포를 지원합니다.

References

Secure Channel Protocols Based on Diffie‑Hellman

Noise의 주요 장점은 전체 TLS 스택에 비해 단순함이라는 점입니다. Noise 핸드쉐이크와 그 결과로 생성되는 암호화 채널 구현은 약 2.5 K LOC이며, BoringSSL은 1.2 M LOC에 달합니다. 이렇게 작은 코드 규모는 검증 가능한 암호 원시 요소 집합을 제공하여 올바르게 구현하고 검증하기가 더 쉽습니다.

Attestation

신뢰할 수 있는 실행 플랫폼 환경은 하드웨어 격리 메모리 엔클레이브 내에서 실행되는 워크로드의 무결성과 신원을 확인하는 서명된 보고서를 제공합니다. Oak Session은 주장(assertion)을 교환하고 검증할 수 있는 조합 가능한 프레임워크입니다. Confidential Space의 경우, 주장은 다음으로 구성됩니다:

  • 바인딩 검증 키 (공개 키).
  • 중첩 암호화 핸드셰이크에서 파생된 세션 토큰의 서명. 이 서명은 바인딩 검증 키로 검증할 수 있습니다 (Session Binding 아래 참고).
  • Attestation JSON Web Token (JWT) 로, Google Cloud Attestation 서비스에 의해 서명되었습니다. JWT는 많은 클레임 중 eat_nonce 필드에 검증 키의 지문을 포함합니다.

JWT 자체만으로도 플랫폼의 신원, 파라미터(시스템 이미지, 환경 구성 등) 및 워크로드 자체를 확인하는 첫 번째 단계가 됩니다. 그러나 JWT만으로는 충분하지 않습니다—악의적인 운영자가 이를 탈취해 다른 워크로드에서 재생할 수 있기 때문입니다. 바인딩 키와 세션 토큰이 이를 방지하여 전체적인 신뢰성을 완성합니다.

Session Binding

이 중요한 단계는 보안 채널을 인증 JWT에 연결합니다.

  1. 핸드쉐이크 중에 양측은 고유한 세션 토큰을 도출하며, 이는 세션의 암호학적 정체성에 바인딩됩니다.
  2. 엔클레이브는 이 토큰에 개인 바인딩 키로 서명합니다. 이 키는 검증 키의 지문을 포함함으로써 인증 주장에 암호학적으로 연결됩니다.
  3. 이 서명을 검증함으로써 클라이언트는 핸드쉐이크를 수행한 엔터티가 하드웨어에 의해 인증된 정확히 동일한 엔터티임을 확인하게 되며, 오래되었거나 무효인 인증을 사용해 새로운 악의적인 세션을 부트스트랩하는 MITM 및 재생 공격을 방지합니다.

우리 예시에서는 Noise 핸드쉐이크 트랜스크립트의 해시를 사용합니다.
TLS 채널의 경우, 세션 토큰은 Exported Key Material (EKM)을 기반으로 생성될 수 있습니다.

세션 토큰을 JWT eat_nonce에 직접 넣을 수도 있지만, 이렇게 하면 연결당 하나의 인증이 필요하게 되어 지연이 증가하고 프로젝트당 5 QPS의 기본 할당량(쿼터 세부 정보)을 소모하게 됩니다. 바인딩 키를 도입하면 JWT 요청을 핵심 서비스 흐름과 분리할 수 있습니다.

신뢰 구축

아래는 플랫폼 설정 및 워크로드 아이덴티티를 보여주는 JWT 토큰의 발췌입니다. OCI 레지스트리와 이미지 다이제스트가 포함되어 있음을 확인하세요.

{
  "aud": "oak://session/attestation",
  "iss": "https://confidentialcomputing.googleapis.com",
  "sub": "https://www.googleapis.com/compute/v1/projects/oak-functions/zones/us-west1-b/instances/oak_functions",
  "eat_nonce": "d3ee341dbbf8986b11e14db61bece35c02a18943ac6bbcd3868cb00676210fa4",
  "submods": {
    "container": {
      "image_reference": "europe-west1-docker.pkg.dev/oak-examples/c0n741n3r-1m4635/echo_enclave_app:latest",
      "image_digest": "sha256:2f81b55712a288bc4cefe6d56d00501ca1c15b98d49cb0c404370cae5f61021a"
    }
  }
}

검증 단계

  1. JWT 검증 – 서명과 만료 날짜를 확인합니다.
  2. 바인딩 검증 키를 eat_nonce 필드의 지문과 일치시키세요.
  3. 바인딩 검증 키를 사용하여 세션 토큰 서명을 검증합니다.
  4. JWT에 포함된 플랫폼 설정 및 파라미터가 예상 값과 일치하는지 확인합니다.
  5. 컨테이너 필드가 예상 값과 일치하는지 검증합니다.

이 단계들을 모두 완료하면 클라이언트는 플랫폼, 그 구성 및 워크로드에 대한 신뢰를 확립하게 됩니다.

Source: …

예상 컨테이너 정체성 관리

Oak Functions는 재현 가능한 빌드가 가능하므로, 클라이언트가 OCI 이미지를 로컬에서 빌드하고 그 다이제스트를 JWT에 포함된 다이제스트와 비교할 수 있습니다. 하지만 Oak Functions는 주기적으로 릴리스되기 때문에, 매번 이미지를 재빌드하고 검증하는 것은 비현실적입니다.

고전적인 소프트웨어 엔지니어링 해결책은 간접화(indirection) 입니다:

  • 신뢰할 수 있는 OCI 레지스트리 및 리포지토리에서만 Oak 팀이 퍼블리시할 수 있는 OCI 이미지라면 모두 신뢰합니다.
  • 이 접근 방식은 이미지 출처에 대한 인증(endorsement) 역할을 합니다.

보다 고급 인증 메커니즘(예: 서명된 provenance 진술)은 이 기본 모델 위에 추가될 수 있지만, 핵심 아이디어는 변하지 않습니다: 클라이언트는 특정 이미지 다이제스트가 아니라 레지스트리‑리포지토리 쌍을 신뢰함으로써 검증을 단순화하면서 보안을 유지합니다.

Cosign 서명 및 provenance 진술 – 잘 알려진 예시로 **Cosign**이 있으며, 이는 **Confidential Space에서 네이티브 지원**됩니다.

Source: …

결론: 신뢰할 수 있는 기밀 컴퓨팅과 그 너머로 가는 길

Google Cloud의 기밀 컴퓨팅 아키텍처와 Project Oak에서 개발한 기술은 조직에 두 가지 장점을 제공합니다: 표준적이고 확장 가능한 인프라와 검증 가능한 종단 간 데이터 기밀성. 아래 다이어그램은 채널이 열릴 때까지 주요 구성 요소와 그들 간의 상호 작용 순서를 보여줍니다.

Oak session diagram

Google Cloud는 Project Oak의 오픈소스 보안 도구와 협력하여 표준적이고 확장 가능한 클라우드 아키텍처 내에서 가장 민감한 사용 중 데이터(​data‑in‑use​)를 보호하는 완전한 솔루션을 제공합니다.

다음 단계: 안전한 생성 AI와 에이전트 경험 강화

논의된 원칙을 통해 안전한 데이터 협업을 통해 새로운 비즈니스 기회를 열고, 고객 및 규제 기관에 보안·프라이버시 상태에 대한 암호학적·감사 가능한 증명을 제공할 수 있습니다—제공자의 워크로드가 지적 재산권 문제(예: AI, 의료, 유전체 연구) 때문에 독점적으로 유지되어야 할 경우에도 마찬가지입니다.

기업이 생성 AI를 점점 더 많이 도입함에 따라, 독점 모델, 민감한 프롬프트, AI 에이전트가 처리하는 기밀 데이터를 보호하는 것이 최우선 과제가 됩니다. Confidential Space에서 GPU 사용 이 가능해지면서 Google Cloud는 까다로운 AI 워크로드에도 하드웨어 보호를 확장합니다.

AI 에이전트가 귀사의 기밀 기업 데이터를 처리해 인사이트를 제공한다고 상상해 보세요.
Confidential Space와 GPU를 활용한 오픈소스 모델(예: Gemma), Oak Functions, Oak Session을 결합하면 프롬프트와 응답을 안전하게 보호하면서 강력하고 검증 가능한 보안·프라이버시를 갖춘 에이전트 경험을 구축할 수 있습니다. 이 프레임워크는 고위험 엔터프라이즈 환경에서 GenAI를 배포하는 데 필요한 신뢰를 제공합니다.

행동 촉구

Back to Blog

관련 글

더 보기 »