Panduan ini menjelaskan cara kerja enkripsi dan dekripsi menggunakan Client-side Encryption API Google Workspace.
Anda harus mengizinkan layanan Penyedia Identitas (IdP) yang digunakan oleh pengguna yang berbagi file terenkripsi. 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 KACLS Anda untuk enkripsi. Selain pemeriksaan keamanan opsional, seperti pemeriksaan berbasis klaim perimeter dan JWT, KACLS Anda harus melakukan langkah-langkah berikut:
Validasi pengguna yang meminta.
- Validasi token autentikasi dan token otorisasi.
- Periksa apakah token otorisasi dan autentikasi ditujukan untuk pengguna yang sama dengan melakukan pencocokan yang tidak peka huruf besar/kecil pada klaim email.
- 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. - Jika 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 mencakup:
- Untuk memberlakukan 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
yang menetapkan
email_type
kegoogle-visitor
ataucustomer-idp
dapat ditolak. Permintaan denganemail_type
sebesargoogle
atau denganemail_type
yang tidak ditetapkan akan terus diterima.
- Periksa apakah klaim
role
dalam token otorisasi adalah "writer" atau "upgrader". - Pastikan klaim
kacls_url
dalam 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 autentikasi dan otorisasi.
Enkripsikan bagian berikut menggunakan algoritma enkripsi yang diautentikasi:
- Kunci Enkripsi Data (DEK)
- Nilai
resource_name
danperimeter_id
dari token otorisasi - Data sensitif lainnya
Catat operasi ke dalam log, termasuk pengguna yang menjadi asalnya,
resource_name
, dan alasan yang diteruskan dalam permintaan.Menampilkan objek biner buram untuk disimpan oleh Google Workspace bersama objek terenkripsi dan dikirim apa adanya dalam operasi pembukaan kunci selanjutnya. Atau, tayangkan balasan error terstruktur.
- Objek biner harus berisi satu-satunya salinan DEK yang dienkripsi, dan data khusus implementasi dapat disimpan di dalamnya.
Mendekripsi data
Saat pengguna Google Workspace meminta untuk membuka data yang dienkripsi sisi klien (CSE),
Google Workspace akan mengirimkan permintaan unwrap
ke URL endpoint KACLS Anda untuk didekripsi. Selain pemeriksaan keamanan opsional, seperti pemeriksaan berbasis klaim perimeter dan JWT, KACLS Anda harus melakukan langkah-langkah berikut:
Validasi pengguna yang meminta.
- Validasi token autentikasi dan token otorisasi.
- Periksa apakah token otorisasi dan autentikasi ditujukan untuk pengguna yang sama dengan melakukan pencocokan yang tidak peka huruf besar/kecil pada klaim email.
- 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. - Jika 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 mencakup:
- Untuk memberlakukan 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
yang menetapkan
email_type
kegoogle-visitor
ataucustomer-idp
dapat ditolak. Permintaan denganemail_type
sebesargoogle
atau denganemail_type
yang tidak ditetapkan akan terus diterima.
- Pastikan klaim
role
dalam token otorisasi adalah "reader" atau "writer". - Pastikan klaim
kacls_url
dalam 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 {i>rogue<i}.
Dekripsi bagian berikut menggunakan algoritma enkripsi yang diautentikasi:
- Kunci Enkripsi Data (DEK)
- Nilai
resource_name
danperimeter_id
dari token otorisasi - Data sensitif lainnya
Pastikan
resource_name
dalam token otorisasi dan blob yang didekripsi cocok.Lakukan pemeriksaan perimeter menggunakan klaim autentikasi dan otorisasi.
Catat operasi ke dalam log, termasuk pengguna yang menjadi asalnya,
resource_name
, dan alasan yang diteruskan dalam permintaan.Tampilkan DEK yang belum digabungkan atau balasan error terstruktur.