데이터 암호화 및 복호화

이 가이드에서는 Google Workspace 클라이언트 측 암호화 API를 사용하여 암호화 및 복호화가 작동하는 방식을 설명합니다.

암호화된 파일을 공유하는 사용자가 사용하는 모든 ID 공급업체 (IdP) 서비스를 허용 목록에 추가해야 합니다. 일반적으로 공개적으로 사용 가능한 .well-known 파일에서 필요한 IdP 세부정보를 찾을 수 있습니다. 그렇지 않은 경우 조직의 Google Workspace 관리자에게 IdP 세부정보를 문의하세요.

데이터 암호화

Google Workspace 사용자가 클라이언트 측 암호화(CSE) 데이터를 저장하거나 저장하도록 요청하면 Google Workspace는 암호화를 위해 KACLS 엔드포인트 URL에 wrap 요청을 전송합니다. KACLS는 경계 및 JWT 클레임 기반 검사와 같은 선택적 보안 검사 외에도 다음 단계를 실행해야 합니다.

  1. 요청한 사용자를 확인합니다.

    • 인증 토큰과 승인 토큰을 모두 확인합니다.
    • 이메일 소유권 주장에서 대소문자를 구분하지 않는 일치를 실행하여 승인 토큰과 인증 토큰이 동일한 사용자의 것인지 확인합니다.
    • 인증 토큰에 선택적 google_email 소유권 주장이 포함된 경우 대소문자를 구분하지 않는 접근 방식을 사용하여 승인 토큰의 이메일 소유권 주장과 비교해야 합니다. 이 비교에는 인증 토큰 내의 이메일 클레임을 사용하지 마세요.
    • 인증 토큰에 선택적 google_email 클레임이 없는 시나리오에서는 대소문자를 구분하지 않는 메서드를 사용하여 인증 토큰 내 이메일 클레임을 승인 토큰의 이메일 클레임과 비교해야 합니다.
    • Google 계정과 연결되지 않은 이메일에 대해 Google에서 승인 토큰을 발급하는 시나리오에서는 email_type 소유권 주장이 있어야 합니다. 이는 게스트 액세스 기능의 핵심적인 부분을 형성하며, KACLS가 외부 사용자에게 추가 보안 조치를 적용하는 데 중요한 정보를 제공합니다.
      • KACLS에서 이 정보를 사용하는 방법의 예는 다음과 같습니다.
      • 추가 로깅 요구사항을 적용합니다.
      • 인증 토큰 발급기관을 전용 게스트 IdP로 제한합니다.
      • 인증 토큰에 추가 클레임을 요구합니다.
      • 고객이 게스트 액세스를 구성하지 않은 경우 email_type가 google-visitor 또는 customer-idp로 설정된 모든 요청이 거부될 수 있습니다. email_type가 google이거나 email_type가 설정되지 않은 요청은 계속 수락되어야 합니다.
    • 승인 토큰의 role 클레임이 'writer' 또는 'upgrader'인지 확인합니다.
    • 승인 토큰의 kacls_url 클레임이 현재 KACLS URL과 일치하는지 확인합니다. 이 검사를 통해 내부자 또는 악의적인 도메인 관리자가 구성한 잠재적인 미들맨 서버를 감지할 수 있습니다.
    • 인증 및 승인 클레임을 모두 사용하여 경계 검사를 실행합니다.

  2. 인증된 암호화 알고리즘을 사용하여 다음 부분을 암호화합니다.

    • 데이터 암호화 키 (DEK)
    • 승인 토큰의 resource_name 및 perimeter_id 값
    • 추가 민감한 정보

  3. 작업을 시작한 사용자, resource_name, 요청에 전달된 이유를 포함하여 작업을 로깅합니다.

  4. Google Workspace에서 암호화된 객체와 함께 저장하고 후속 키 래핑 해제 작업에서 있는 그대로 전송할 불투명 바이너리 객체를 반환합니다. 또는 구조화된 오류 답장을 제공합니다.

    • 바이너리 객체는 암호화된 DEK의 유일한 사본을 포함해야 하며 구현별 데이터를 저장할 수 있습니다.

데이터 복호화

Google Workspace 사용자가 클라이언트 측 암호화 (CSE) 데이터를 열도록 요청하면 Google Workspace는 복호화를 위해 KACLS 엔드포인트 URL에 unwrap 요청을 전송합니다. KACLS는 경계 및 JWT 클레임 기반 확인과 같은 선택적 보안 확인 외에도 다음 단계를 실행해야 합니다.

  1. 요청한 사용자를 확인합니다.

    • 인증 토큰과 승인 토큰을 모두 확인합니다.
    • 이메일 소유권 주장에서 대소문자를 구분하지 않는 일치를 실행하여 승인 토큰과 인증 토큰이 동일한 사용자의 것인지 확인합니다.
    • 인증 토큰에 선택적 google_email 소유권 주장이 포함된 경우 대소문자를 구분하지 않는 접근 방식을 사용하여 승인 토큰의 이메일 소유권 주장과 비교해야 합니다. 이 비교에는 인증 토큰 내의 이메일 클레임을 사용하지 마세요.
    • 인증 토큰에 선택적 google_email 클레임이 없는 시나리오에서는 대소문자를 구분하지 않는 메서드를 사용하여 인증 토큰 내 이메일 클레임을 승인 토큰의 이메일 클레임과 비교해야 합니다.
    • Google 계정과 연결되지 않은 이메일에 대해 Google에서 승인 토큰을 발급하는 시나리오에서는 email_type 소유권 주장이 있어야 합니다. 이는 게스트 액세스 기능의 핵심적인 부분을 형성하며, KACLS가 외부 사용자에게 추가 보안 조치를 적용하는 데 중요한 정보를 제공합니다.
      • KACLS에서 이 정보를 사용하는 방법의 예는 다음과 같습니다.
      • 추가 로깅 요구사항을 적용합니다.
      • 인증 토큰 발급기관을 전용 게스트 IdP로 제한합니다.
      • 인증 토큰에 추가 클레임을 요구합니다.
      • 고객이 게스트 액세스를 구성하지 않은 경우 email_type가 google-visitor 또는 customer-idp로 설정된 모든 요청이 거부될 수 있습니다. email_type이 google이거나 email_type가 설정되지 않은 요청은 계속 수락되어야 합니다.
    • 승인 토큰의 role 클레임이 'reader' 또는 'writer'인지 확인합니다.
    • 승인 토큰의 kacls_url 클레임이 현재 KACLS URL과 일치하는지 확인합니다. 이를 통해 내부자 또는 악의적인 도메인 관리자가 구성한 잠재적인 미들맨 서버를 감지할 수 있습니다.

  2. 인증된 암호화 알고리즘을 사용하여 다음 부분을 복호화합니다.

    • 데이터 암호화 키 (DEK)
    • 승인 토큰의 resource_name 및 perimeter_id 값
    • 추가 민감한 정보

  3. 승인 토큰과 복호화된 블롭의 resource_name가 일치하는지 확인합니다.

  4. 인증 및 승인 클레임을 모두 사용하여 경계 검사를 실행합니다.

  5. 작업을 시작한 사용자, resource_name, 요청에 전달된 이유를 포함하여 작업을 로깅합니다.

  6. 래핑되지 않은 DEK 또는 구조화된 오류 답장을 반환합니다.