데이터 암호화 및 복호화

이 가이드에서는 Google Workspace Client-side Encryption 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_typegoogle-visitor 또는 customer-idp로 설정된 모든 요청이 거부될 수 있습니다. email_typegoogle이거나 email_type가 설정되지 않은 요청은 계속 수락되어야 합니다.
    • 승인 토큰의 role 클레임이 'writer' 또는 'upgrader'인지 확인합니다.
    • 승인 토큰의 kacls_url 클레임이 현재 KACLS URL과 일치하는지 확인합니다. 이 검사를 통해 내부자 또는 불량 도메인 관리자가 구성한 잠재적인 중간자 서버를 감지할 수 있습니다.
    • 인증 및 승인 클레임을 모두 사용하여 경계 검사를 수행합니다.
  2. 인증된 암호화 알고리즘을 사용하여 다음 부분을 암호화합니다.

    • 데이터 암호화 키 (DEK)
    • 승인 토큰의 resource_nameperimeter_id
    • 추가적인 민감한 정보
  3. 작업을 시작한 사용자, resource_name, 요청에 전달된 이유를 포함하여 작업을 로깅합니다.

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

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

데이터 복호화

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

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

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

    • 데이터 암호화 키 (DEK)
    • 승인 토큰의 resource_nameperimeter_id
    • 추가적인 민감한 정보
  3. 승인 토큰의 resource_name와 복호화된 blob이 일치하는지 확인합니다.

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

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

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