Mã hoá và giải mã dữ liệu

Hướng dẫn này mô tả cách hoạt động của quy trình mã hoá và giải mã bằng Google Workspace Client-side Encryption API.

Bạn phải đưa mọi dịch vụ Nhà cung cấp dịch vụ danh tính (IdP) mà người dùng sử dụng để chia sẻ tệp được mã hoá vào danh sách cho phép. Thông thường, bạn có thể tìm thấy thông tin cần thiết về nhà cung cấp danh tính trong tệp .well-known có sẵn công khai của họ; nếu không, hãy liên hệ với quản trị viên Google Workspace của tổ chức để biết thông tin về nhà cung cấp danh tính của họ.

Mã hoá dữ liệu

Khi người dùng Google Workspace yêu cầu lưu hoặc lưu trữ dữ liệu được mã hoá phía máy khách (CSE), Google Workspace sẽ gửi yêu cầu wrap đến URL điểm cuối của Dịch vụ danh sách kiểm soát quyền truy cập vào khoá (KACLS) để mã hoá. Ngoài các bước kiểm tra bảo mật không bắt buộc, chẳng hạn như các bước kiểm tra dựa trên yêu cầu JWT và ranh giới, KACLS của bạn phải thực hiện các bước sau:

  1. Xác thực người dùng yêu cầu.

    • Xác thực cả mã thông báo xác thực và mã thông báo uỷ quyền.
    • Kiểm tra để đảm bảo mã thông báo uỷ quyền và xác thực là của cùng một người dùng bằng cách so khớp không phân biệt chữ hoa chữ thường đối với các yêu cầu về email.
    • Khi mã xác thực chứa yêu cầu google_email không bắt buộc, bạn phải so sánh mã này với yêu cầu về email trong mã uỷ quyền bằng cách sử dụng phương pháp không phân biệt chữ hoa chữ thường. Không sử dụng yêu cầu về email trong mã thông báo xác thực cho hoạt động so sánh này.
    • Trong trường hợp mã thông báo xác thực thiếu yêu cầu google_email không bắt buộc, bạn nên so sánh yêu cầu email trong mã thông báo xác thực với yêu cầu email trong mã thông báo uỷ quyền bằng phương thức không phân biệt chữ hoa chữ thường.
    • Trong trường hợp Google cấp mã thông báo uỷ quyền cho một email không được liên kết với Tài khoản Google, thì phải có xác nhận quyền sở hữu email_type. Đây là một phần quan trọng của tính năng Quyền truy cập của khách, cung cấp thông tin có giá trị cho KACLS để thực thi các biện pháp bảo mật bổ sung đối với người dùng bên ngoài.
      • Sau đây là một số ví dụ về cách KACLS có thể sử dụng thông tin này:
      • Để áp đặt các yêu cầu bổ sung về việc ghi nhật ký.
      • Để hạn chế nhà phát hành mã thông báo xác thực đối với một IdP khách chuyên dụng.
      • Để yêu cầu các xác nhận quyền sở hữu bổ sung trên mã thông báo xác thực.
      • Nếu khách hàng chưa định cấu hình Quyền truy cập của khách, thì tất cả các yêu cầu mà email_type được đặt thành google-visitor hoặc customer-idp đều có thể bị từ chối. Các yêu cầu có email_type là google hoặc có email_type chưa đặt sẽ tiếp tục được chấp nhận.
    • Khi mã xác thực chứa khai báo delegated_to không bắt buộc, mã này cũng phải chứa khai báo resource_name và hai khai báo này phải được so sánh với khai báo delegated_to và resource_name trong mã uỷ quyền. Bạn nên so sánh các delegated_to theo cách không phân biệt chữ hoa chữ thường và resource_name trong mã thông báo phải khớp với resource_name của thao tác.
    • Kiểm tra để đảm bảo rằng thông báo xác nhận quyền sở hữu role trong mã thông báo uỷ quyền là writer hoặc upgrader.
    • Kiểm tra để đảm bảo rằng yêu cầu kacls_url trong mã thông báo uỷ quyền khớp với URL KACLS hiện tại. Quy trình kiểm tra này cho phép phát hiện các máy chủ trung gian tiềm ẩn do người nội bộ hoặc quản trị viên miền giả mạo định cấu hình.
    • Thực hiện kiểm tra ranh giới bằng cả xác thực và uỷ quyền.

  2. Mã hoá các phần sau bằng một thuật toán mã hoá đã xác thực:

    • Khoá mã hoá dữ liệu (DEK)
    • Giá trị resource_name và perimeter_id trong mã thông báo uỷ quyền
    • Mọi dữ liệu nhạy cảm bổ sung

  3. Ghi lại thao tác, bao gồm cả người dùng bắt nguồn thao tác đó, resource_name và lý do được truyền trong yêu cầu.

  4. Trả về một đối tượng nhị phân không trong suốt để Google Workspace lưu trữ cùng với đối tượng được mã hoá và gửi nguyên trạng trong mọi thao tác mở khoá tiếp theo. Hoặc phân phát một phản hồi lỗi có cấu trúc.

    • Đối tượng nhị phân phải chứa bản sao duy nhất của DEK đã mã hoá, dữ liệu cụ thể về việc triển khai có thể được lưu trữ trong đó.

Giải mã dữ liệu

Khi người dùng Google Workspace yêu cầu mở dữ liệu được mã hoá phía máy khách (CSE), Google Workspace sẽ gửi yêu cầu unwrap đến URL điểm cuối KACLS của bạn để giải mã. Ngoài các bước kiểm tra bảo mật không bắt buộc, chẳng hạn như các bước kiểm tra dựa trên phạm vi và JWT, KACLS của bạn phải thực hiện các bước sau:

  1. Xác thực người dùng yêu cầu.

    • Xác thực cả mã thông báo xác thực và mã thông báo uỷ quyền.
    • Kiểm tra để đảm bảo mã thông báo uỷ quyền và xác thực là của cùng một người dùng bằng cách so khớp không phân biệt chữ hoa chữ thường đối với các yêu cầu về email.
    • Khi mã xác thực chứa yêu cầu google_email không bắt buộc, bạn phải so sánh mã này với yêu cầu về email trong mã uỷ quyền bằng cách sử dụng phương pháp không phân biệt chữ hoa chữ thường. Không sử dụng yêu cầu về email trong mã thông báo xác thực cho hoạt động so sánh này.
    • Trong trường hợp mã thông báo xác thực thiếu yêu cầu google_email không bắt buộc, bạn nên so sánh yêu cầu email trong mã thông báo xác thực với yêu cầu email trong mã thông báo uỷ quyền bằng phương thức không phân biệt chữ hoa chữ thường.
    • Trong trường hợp Google cấp mã thông báo uỷ quyền cho một email không được liên kết với Tài khoản Google, thì phải có xác nhận quyền sở hữu email_type. Đây là một phần quan trọng của tính năng Quyền truy cập của khách, cung cấp thông tin có giá trị cho KACLS để thực thi các biện pháp bảo mật bổ sung đối với người dùng bên ngoài.
      • Sau đây là một số ví dụ về cách KACLS có thể sử dụng thông tin này:
      • Để áp đặt các yêu cầu bổ sung về việc ghi nhật ký.
      • Để hạn chế nhà phát hành mã thông báo xác thực đối với một IdP khách chuyên dụng.
      • Để yêu cầu các xác nhận quyền sở hữu bổ sung trên mã thông báo xác thực.
      • Nếu khách hàng chưa định cấu hình Quyền truy cập của khách, thì tất cả các yêu cầu mà email_type được đặt thành google-visitor hoặc customer-idp đều có thể bị từ chối. Các yêu cầu có email_type là google hoặc có email_type chưa đặt sẽ tiếp tục được chấp nhận.
    • Khi mã xác thực chứa khai báo delegated_to không bắt buộc, mã này cũng phải chứa khai báo resource_name và hai khai báo này phải được so sánh với khai báo delegated_to và resource_name trong mã uỷ quyền. Bạn nên so sánh các delegated_to theo cách không phân biệt chữ hoa chữ thường và resource_name trong mã thông báo phải khớp với resource_name của thao tác.
    • Kiểm tra để đảm bảo rằng thông báo xác nhận quyền sở hữu role trong mã thông báo uỷ quyền là reader hoặc writer.
    • Kiểm tra để đảm bảo rằng yêu cầu kacls_url trong mã thông báo uỷ quyền khớp với URL KACLS hiện tại. Điều này cho phép phát hiện các máy chủ trung gian tiềm ẩn do người nội bộ hoặc quản trị viên miền giả mạo định cấu hình.

  2. Giải mã các phần sau bằng một thuật toán mã hoá đã xác thực:

    • Khoá mã hoá dữ liệu (DEK)
    • Giá trị resource_name và perimeter_id trong mã thông báo uỷ quyền
    • Mọi dữ liệu nhạy cảm bổ sung

  3. Kiểm tra để đảm bảo resource_name trong mã thông báo uỷ quyền và blob đã giải mã khớp nhau.

  4. Thực hiện kiểm tra ranh giới bằng cả xác thực và uỷ quyền.

  5. Ghi lại thao tác, bao gồm cả người dùng bắt nguồn thao tác đó, resource_name và lý do được truyền trong yêu cầu.

  6. Trả về DEK chưa được gỡ bao bọc hoặc phản hồi lỗi có cấu trúc.