데이터 암호화 및 복호화

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

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

데이터 암호화

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

  1. 요청하는 사용자를 검증합니다.

    • 인증 토큰과 승인 토큰을 모두 검증합니다.
    • 이메일 클레임에 대해 대소문자를 구분하지 않는 일치를 실행하여 승인 및 인증 토큰이 동일한 사용자를 위한 것인지 확인합니다.
    • 인증 토큰에 선택적 google_email 클레임이 포함된 경우 대소문자를 구분하지 않는 접근 방식을 사용하여 승인 토큰의 이메일 클레임과 비교해야 합니다. 이 비교를 위해 인증 토큰 내에서 이메일 클레임을 사용하지 마세요.
    • 인증 토큰에 선택적 google_email 클레임이 없는 시나리오에서는 인증 토큰 내의 이메일 클레임을 대소문자를 구분하지 않는 방법을 사용하여 승인 토큰의 이메일 클레임과 비교해야 합니다.
    • Google 계정과 연결되지 않은 이메일에 대해 Google에서 승인 토큰을 발급하는 시나리오에서는 email_type 클레임이 있어야 합니다. 이는 게스트 액세스 기능의 중요한 부분으로, KACLS가 외부 사용자에게 추가 보안 조치를 적용할 수 있는 유용한 정보를 제공합니다.
      • KACLS가 이 정보를 사용하는 방법의 예는 다음과 같습니다.
      • 추가 로깅 요구사항을 적용합니다.
      • 인증 토큰 발급자를 전용 게스트 IdP로 제한합니다.
      • 인증 토큰에 추가 클레임을 요구합니다.
      • 고객이 게스트 액세스를 구성하지 않은 경우 email_type가 google-visitor 또는 customer-idp로 설정된 모든 요청이 거부될 수 있습니다. email_type이 google이거나 email_type이 설정되지 않은 요청은 계속 허용되어야 합니다.
    • 인증 토큰에 선택사항인 delegated_to 클레임이 포함된 경우 resource_name 클레임도 포함되어야 하며, 이 두 클레임은 승인 토큰의 delegated_to 및 resource_name 클레임과 비교해야 합니다. delegated_to 클레임은 대소문자를 구분하지 않는 방식으로 비교해야 하며 토큰의 resource_name은 작업의 resource_name과 일치해야 합니다.
    • 승인 토큰의 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 요청을 전송합니다. 선택적 보안 검사(예: 경계 및 JWT 클레임 기반 검사) 외에도 KACLS는 다음 단계를 실행해야 합니다.

  1. 요청하는 사용자를 검증합니다.

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

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

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

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

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

  5. 작업을 기록합니다. 여기에는 작업을 시작한 사용자, resource_name, 요청에 전달된 이유가 포함됩니다.

  6. 래핑 해제된 DEK 또는 구조화된 오류 응답을 반환합니다.