Isolasi penyewa dengan model dokumen OPA

OPA menggunakan dokumen untuk membuat keputusan. Dokumen-dokumen ini dapat berisi data khusus penyewa, jadi Anda harus mempertimbangkan cara mempertahankan isolasi data penyewa. Dokumen OPA terdiri dari dokumen dasar dan dokumen virtual. Dokumen dasar berisi data dari dunia luar. Ini termasuk data yang diberikan kepada OPA secara langsung, data tentang permintaan OPA, dan data yang mungkin diteruskan ke OPA sebagai input. Dokumen virtual dihitung berdasarkan kebijakan dan mencakup kebijakan dan aturan OPA. Untuk informasi selengkapnya, lihat dokumentasi OPA.

Untuk merancang model dokumen di OPA untuk aplikasi multi-penyewa, Anda harus terlebih dahulu mempertimbangkan jenis dokumen dasar apa yang Anda perlukan untuk membuat keputusan di OPA. Jika dokumen dasar ini berisi data khusus penyewa, Anda harus mengambil tindakan untuk memastikan bahwa data ini tidak terpapar secara tidak sengaja ke akses lintas penyewa. Untungnya, dalam banyak kasus, data khusus penyewa tidak diperlukan untuk membuat keputusan di OPA. Contoh berikut menunjukkan model dokumen OPA hipotetis yang memungkinkan akses ke API berdasarkan penyewa mana yang memiliki API, dan apakah pengguna adalah anggota penyewa, seperti yang ditunjukkan dalam dokumen input.

Dalam pendekatan ini, OPA tidak memiliki akses ke data khusus penyewa kecuali untuk informasi tentang penyewa mana yang memiliki API. Dalam hal ini, tidak ada kekhawatiran atas OPA memfasilitasi akses lintas penyewa, karena satu-satunya informasi yang digunakan OPA untuk membuat keputusan akses adalah asosiasi pengguna dengan penyewa dan asosiasi penyewa dengan. APIs Anda dapat menerapkan jenis model dokumen OPA ini ke model SaaS silo, karena setiap penyewa akan memiliki kepemilikan sumber daya independen.

Namun, dalam banyak pendekatan otorisasi RBAC, ada potensi paparan informasi lintas penyewa. Dalam contoh berikut, model dokumen OPA hipotetis memungkinkan akses ke API berdasarkan apakah pengguna adalah anggota penyewa, dan apakah pengguna memiliki peran yang benar untuk mengakses API.

Model ini memperkenalkan risiko akses lintas penyewa, karena peran dan izin beberapa penyewa di data.tenant1.user_roles dan sekarang data.tenant2.user_roles harus dapat diakses oleh OPA untuk membuat keputusan otorisasi. Untuk menjaga isolasi penyewa dan privasi pemetaan peran, data ini tidak boleh berada dalam OPA. Data RBAC harus berada di sumber data eksternal seperti database. Selain itu, OPA tidak boleh digunakan untuk memetakan peran yang telah ditentukan ke izin tertentu, karena ini menyulitkan penyewa untuk menentukan peran dan izin mereka sendiri. Itu juga membuat logika otorisasi Anda kaku dan membutuhkan pembaruan konstan. Untuk panduan tentang cara memasukkan data RBAC dengan aman ke dalam proses pengambilan keputusan OPA, lihat bagian Rekomendasi untuk isolasi penyewa dan privasi data nanti dalam panduan ini.

Anda dapat dengan mudah mempertahankan isolasi penyewa di OPA dengan tidak menyimpan data khusus penyewa sebagai dokumen dasar asinkron. Dokumen dasar asinkron adalah data yang disimpan dalam memori dan dapat diperbarui secara berkala, di OPA. Dokumen dasar lainnya, seperti input OPA, diteruskan secara serempak dan hanya tersedia pada waktu pengambilan keputusan. Misalnya, memberikan data khusus penyewa sebagai bagian dari input OPA ke kueri tidak akan merupakan pelanggaran isolasi penyewa, karena data tersebut hanya tersedia secara sinkron selama proses pengambilan keputusan.