Mengenkripsi & mendekripsi data

Panduan ini menjelaskan cara kerja enkripsi dan dekripsi menggunakan Google Workspace Client-side Encryption API.

Anda harus memasukkan layanan Penyedia Identitas (IdP) yang digunakan oleh pengguna yang berbagi file terenkripsi ke dalam daftar yang diizinkan. Anda biasanya dapat menemukan detail IdP yang diperlukan di file .well-known yang tersedia secara publik; jika tidak, hubungi administrator Google Workspace organisasi untuk mengetahui detail IdP mereka.

Mengenkripsi data

Saat pengguna Google Workspace meminta untuk menyimpan atau menyimpan data terenkripsi sisi klien (CSE), Google Workspace akan mengirimkan permintaan wrap ke URL endpoint Layanan Daftar Kontrol Akses Kunci (KACLS) Anda untuk enkripsi. Selain pemeriksaan keamanan opsional, seperti pemeriksaan berbasis klaim JWT dan perimeter, KACLS Anda harus melakukan langkah-langkah berikut:

  1. Memvalidasi pengguna yang meminta.

    • Validasi token autentikasi dan token otorisasi.
    • Periksa apakah token otorisasi dan autentikasi ditujukan untuk pengguna yang sama dengan mencocokkan klaim email secara tidak peka huruf besar/kecil.
    • Jika token autentikasi berisi klaim google_email opsional, klaim tersebut harus dibandingkan dengan klaim email dalam token otorisasi menggunakan pendekatan yang tidak peka huruf besar/kecil. Jangan gunakan klaim email dalam token autentikasi untuk perbandingan ini.
    • Dalam skenario saat token autentikasi tidak memiliki klaim google_email opsional, klaim email dalam token autentikasi harus dibandingkan dengan klaim email dalam token otorisasi, menggunakan metode yang tidak peka huruf besar/kecil.
    • Dalam skenario saat Google mengeluarkan token otorisasi untuk email yang tidak terkait dengan Akun Google, klaim email_type harus ada. Hal ini merupakan bagian penting dari fitur Akses Tamu, yang memberikan informasi berharga bagi KACLS untuk menerapkan langkah-langkah keamanan tambahan pada pengguna eksternal.
      • Beberapa contoh cara KACLS dapat menggunakan informasi ini antara lain:
      • Untuk menerapkan persyaratan logging tambahan.
      • Untuk membatasi penerbit token autentikasi ke IdP Tamu khusus.
      • Untuk mewajibkan klaim tambahan pada token autentikasi.
      • Jika pelanggan belum mengonfigurasi Akses Tamu, semua permintaan dengan email_type disetel ke google-visitor atau customer-idp dapat ditolak. Permintaan dengan email_type google atau dengan email_type yang tidak ditetapkan harus terus diterima.
    • Jika token autentikasi berisi klaim delegated_to opsional, token tersebut juga harus berisi klaim resource_name, dan kedua klaim ini harus dibandingkan dengan klaim delegated_to dan resource_name dalam token otorisasi. Klaim delegated_to harus dibandingkan menggunakan pendekatan yang tidak peka huruf besar/kecil, dan resource_name dalam token harus cocok dengan resource_name operasi.
    • Pastikan klaim role dalam token otorisasi adalah writer atau upgrader.
    • Pastikan klaim kacls_url di token otorisasi cocok dengan URL KACLS saat ini. Pemeriksaan ini memungkinkan deteksi potensi server man-in-the-middle yang dikonfigurasi oleh orang dalam atau administrator domain jahat.
    • Lakukan pemeriksaan perimeter menggunakan klaim otorisasi dan autentikasi.

  2. Enkripsi bagian berikut menggunakan algoritma enkripsi yang diautentikasi:

    • Kunci Enkripsi Data (DEK)
    • Nilai resource_name dan perimeter_id dari token otorisasi
    • Data sensitif tambahan

  3. Mencatat operasi, termasuk pengguna yang memulainya, resource_name, dan alasan yang diteruskan dalam permintaan.

  4. Mengembalikan objek biner buram untuk disimpan oleh Google Workspace bersama dengan objek terenkripsi dan dikirim apa adanya dalam operasi pembukaan kunci berikutnya. Atau, sajikan respons error terstruktur.

    • Objek biner harus berisi satu-satunya salinan DEK terenkripsi, dan data khusus penerapan dapat disimpan di dalamnya.

Mendekripsi data

Saat pengguna Google Workspace meminta untuk membuka data terenkripsi sisi klien (CSE), Google Workspace akan mengirim permintaan unwrap ke URL endpoint KACLS Anda untuk dekripsi. Selain pemeriksaan keamanan opsional, seperti pemeriksaan berbasis klaim JWT dan perimeter, KACLS Anda harus melakukan langkah-langkah berikut:

  1. Memvalidasi pengguna yang meminta.

    • Validasi token autentikasi dan token otorisasi.
    • Periksa apakah token otorisasi dan autentikasi ditujukan untuk pengguna yang sama dengan mencocokkan klaim email secara tidak peka huruf besar/kecil.
    • Jika token autentikasi berisi klaim google_email opsional, klaim tersebut harus dibandingkan dengan klaim email dalam token otorisasi menggunakan pendekatan yang tidak peka huruf besar/kecil. Jangan gunakan klaim email dalam token autentikasi untuk perbandingan ini.
    • Dalam skenario saat token autentikasi tidak memiliki klaim google_email opsional, klaim email dalam token autentikasi harus dibandingkan dengan klaim email dalam token otorisasi, menggunakan metode yang tidak peka huruf besar/kecil.
    • Dalam skenario saat Google mengeluarkan token otorisasi untuk email yang tidak terkait dengan Akun Google, klaim email_type harus ada. Hal ini merupakan bagian penting dari fitur Akses Tamu, yang memberikan informasi berharga bagi KACLS untuk menerapkan langkah-langkah keamanan tambahan pada pengguna eksternal.
      • Beberapa contoh cara KACLS dapat menggunakan informasi ini antara lain:
      • Untuk menerapkan persyaratan logging tambahan.
      • Untuk membatasi penerbit token autentikasi ke IdP Tamu khusus.
      • Untuk mewajibkan klaim tambahan pada token autentikasi.
      • Jika pelanggan belum mengonfigurasi Akses Tamu, semua permintaan dengan email_type disetel ke google-visitor atau customer-idp dapat ditolak. Permintaan dengan email_type google atau dengan email_type yang tidak ditetapkan harus terus diterima.
    • Jika token autentikasi berisi klaim delegated_to opsional, token tersebut juga harus berisi klaim resource_name, dan kedua klaim ini harus dibandingkan dengan klaim delegated_to dan resource_name dalam token otorisasi. Klaim delegated_to harus dibandingkan menggunakan pendekatan yang tidak peka huruf besar/kecil, dan resource_name dalam token harus cocok dengan resource_name operasi.
    • Pastikan klaim role dalam token otorisasi adalah reader atau writer.
    • Pastikan klaim kacls_url di token otorisasi cocok dengan URL KACLS saat ini. Hal ini memungkinkan deteksi potensi server man-in-the-middle yang dikonfigurasi oleh orang dalam atau administrator domain jahat.

  2. Dekripsi bagian berikut menggunakan algoritma enkripsi yang diautentikasi:

    • Kunci Enkripsi Data (DEK)
    • Nilai resource_name dan perimeter_id dari token otorisasi
    • Data sensitif tambahan

  3. Pastikan resource_name dalam token otorisasi dan blob yang didekripsi cocok.

  4. Lakukan pemeriksaan perimeter menggunakan klaim autentikasi dan otorisasi.

  5. Mencatat operasi, termasuk pengguna yang memulainya, resource_name, dan alasan yang diteruskan dalam permintaan.

  6. Menampilkan DEK yang telah dibuka atau respons error terstruktur.