데이터 암호화 및 복호화

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

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

데이터 암호화

Google Workspace 사용자가 클라이언트 측에서 암호화된 내용을 저장하거나 저장하도록 요청하는 경우 (CSE) 데이터의 경우 Google Workspace에서 wrap를 전송합니다. KACLS 엔드포인트 URL에 요청을 보냅니다. 선택사항인 경계 및 JWT 클레임 기반 검사와 같은 보안 확인이 필요한 경우 KACLS는 다음 단계를 따르세요.

  1. 요청하는 사용자의 유효성을 검사합니다.

    • 두 가지 인증 토큰을 모두 검증합니다. 및 승인 토큰이 있습니다.
    • 다음과 같이 승인 및 인증 토큰이 동일한 사용자의 것인지 확인합니다. 이메일 클레임에서 대소문자를 구분하지 않는 일치를 수행합니다.
    • 인증 토큰에 선택적 google_email 클레임이 포함된 경우 인증 토큰의 이메일 클레임과 비교해야 합니다. 대소문자 구분 없는 방식을 사용합니다 이메일 소유권 주장을 이 비교를 위한 인증 토큰입니다.
    • 인증 토큰에 선택적 google_email 클레임, 인증 토큰 내의 이메일 클레임 인증 토큰의 이메일 클레임과 비교해야 합니다. 대소문자 구분 없는 메서드를 사용합니다.
    • Google이 Google 계정과 연결된 경우 email_type 클레임이 있어야 합니다. 이는 게스트 액세스 기능의 중요한 부분을 차지하며, KACLS에서 외부 IP 주소 및 있습니다.
      • 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에서 unwrap 요청을 전송함 KACLS 엔드포인트 URL에 있어야 합니다 선택적 보안 기능 KACLS는 경계 및 JWT 클레임 기반 검사와 같은 여러 검사를 다음 단계를 따르세요.

  1. 요청하는 사용자의 유효성을 검사합니다.

    • 두 가지 인증 토큰을 모두 검증합니다. 및 승인 토큰이 있습니다.
    • 다음과 같이 승인 및 인증 토큰이 동일한 사용자의 것인지 확인합니다. 이메일 클레임에서 대소문자를 구분하지 않는 일치를 수행합니다.
    • 인증 토큰에 선택적 google_email 클레임이 포함된 경우 인증 토큰의 이메일 클레임과 비교해야 합니다. 대소문자 구분 없는 방식을 사용합니다 이메일 소유권 주장을 이 비교를 위한 인증 토큰입니다.
    • 인증 토큰에 선택적 google_email 클레임, 인증 토큰 내의 이메일 클레임 인증 토큰의 이메일 클레임과 비교해야 합니다. 대소문자 구분 없는 메서드를 사용합니다.
    • Google이 Google 계정과 연결된 경우 email_type 클레임이 있어야 합니다. 이는 게스트 액세스 기능의 중요한 부분을 차지하며, KACLS에서 외부 IP 주소 및 있습니다.
      • KACLS에서 이 정보를 사용하는 방식의 예는 다음과 같습니다.
      • 추가 로깅 요구사항 적용
      • 인증 토큰 발급기관을 전용 게스트 IdP로 제한하기 위해
      • 인증 토큰에 대한 추가 클레임을 요구하기 위해
      • 고객이 게스트 액세스를 구성하지 않은 경우 모든 요청은 여기서 email_type은 google-visitor로 설정되거나 customer-idp는 다음과 같을 수 있습니다. 거부되었습니다. email_type가 google이거나 설정되지 않은 요청 email_type은(는) 계속 수락되어야 합니다.
    • 승인 토큰의 role 클레임이 'Reader'인지 확인합니다. 또는 'writer'.
    • 승인 토큰의 kacls_url 클레임이 현재 KACLS URL입니다. 이를 통해 잠재적인 중간자(Man-in-the-Middle)를 탐지하고 구성하지 않은 사용자를 대상으로 합니다.

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

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

  3. 승인 토큰 및 복호화된 blob의 resource_name를 확인하세요. 일치해야 합니다.

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

  5. 작업을 시작한 사용자, resource_name, 요청에 전달된 이유가 있습니다.

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

를 통해 개인정보처리방침을 정의할 수 있습니다.