Otorisasi SaaS multi-penyewa dan kontrol akses API: Opsi implementasi dan praktik terbaik - AWS Bimbingan Preskriptif

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Otorisasi SaaS multi-penyewa dan kontrol akses API: Opsi implementasi dan praktik terbaik

Tabby Ward, Thomas Davis, Gideon Landeman, dan Tomas Riha, Amazon Web Services ()AWS

Mei 2024 (riwayat dokumen)

Otorisasi dan kontrol akses API merupakan tantangan bagi banyak aplikasi perangkat lunak—khususnya, untuk aplikasi multi-tenant software as a service (SaaS). Kompleksitas ini terbukti ketika Anda mempertimbangkan proliferasi API layanan mikro yang harus diamankan dan sejumlah besar kondisi akses yang muncul dari penyewa yang berbeda, karakteristik pengguna, dan status aplikasi. Untuk mengatasi masalah ini secara efektif, solusi harus menerapkan kontrol akses di banyak API yang disajikan oleh layanan mikro, lapisan Backend for Frontend (BFF), dan komponen lain dari aplikasi SaaS multi-penyewa. Pendekatan ini harus disertai dengan mekanisme yang mampu membuat keputusan akses yang kompleks berdasarkan banyak faktor dan atribut.

Secara tradisional, kontrol akses API dan otorisasi ditangani oleh logika kustom dalam kode aplikasi. Pendekatan ini rawan kesalahan dan tidak aman, karena pengembang yang memiliki akses ke kode ini dapat secara tidak sengaja atau sengaja mengubah logika otorisasi, yang dapat mengakibatkan akses tidak sah. Mengaudit keputusan yang dibuat oleh logika kustom dalam kode aplikasi itu sulit, karena auditor harus membenamkan diri dalam logika khusus untuk menentukan efektivitasnya dalam menegakkan standar tertentu. Selain itu, kontrol akses API umumnya tidak diperlukan, karena tidak ada banyak API yang harus diamankan. Pergeseran paradigma dalam desain aplikasi untuk mendukung layanan mikro dan arsitektur berorientasi layanan telah meningkatkan jumlah API yang harus menggunakan bentuk otorisasi dan kontrol akses. Selain itu, kebutuhan untuk mempertahankan akses berbasis penyewa dalam aplikasi SaaS multi-penyewa menghadirkan tantangan otorisasi tambahan untuk mempertahankan penyewaan. Praktik terbaik yang diuraikan dalam panduan ini memberikan beberapa manfaat:

  • Logika otorisasi dapat dipusatkan dan ditulis dalam bahasa deklaratif tingkat tinggi yang tidak spesifik untuk bahasa pemrograman apa pun.

  • Logika otorisasi diabstraksikan dari kode aplikasi dan dapat diterapkan sebagai pola berulang untuk semua API dalam aplikasi.

  • Abstraksi mencegah perubahan yang tidak disengaja oleh pengembang ke logika otorisasi.

  • Integrasi ke dalam aplikasi SaaS konsisten dan sederhana.

  • Abstraksi mencegah kebutuhan untuk menulis logika otorisasi khusus untuk setiap titik akhir API.

  • Audit disederhanakan, karena auditor tidak perlu lagi meninjau kode untuk menentukan izin.

  • Pendekatan yang diuraikan dalam panduan ini mendukung penggunaan paradigma kontrol akses ganda tergantung pada persyaratan organisasi.

  • Pendekatan otorisasi dan kontrol akses ini menyediakan cara sederhana dan mudah untuk mempertahankan isolasi data penyewa di lapisan API dalam aplikasi SaaS.

  • Praktik terbaik memberikan pendekatan yang konsisten untuk penyewa orientasi dan offboarding sehubungan dengan otorisasi.

  • Pendekatan ini menawarkan model penerapan otorisasi yang berbeda (dikumpulkan atau silo), yang memiliki kelebihan dan kekurangan, seperti yang dibahas dalam panduan ini.

Hasil bisnis yang ditargetkan

Panduan preskriptif ini menjelaskan pola desain berulang untuk otorisasi dan kontrol akses API yang dapat diimplementasikan untuk aplikasi SaaS multi-penyewa. Panduan ini ditujukan untuk tim mana pun yang mengembangkan aplikasi dengan persyaratan otorisasi yang kompleks atau kebutuhan kontrol akses API yang ketat. Arsitektur merinci pembuatan titik keputusan kebijakan (PDP) atau mesin kebijakan dan integrasi poin penegakan kebijakan (PEP) dalam API. Dua opsi khusus untuk membuat PDP dibahas: menggunakan Izin Terverifikasi Amazon dengan SDK Cedar dan menggunakan Open Policy Agent (OPA) dengan bahasa kebijakan Rego. Panduan ini juga membahas pengambilan keputusan akses berdasarkan model kontrol akses berbasis atribut (ABAC) atau model kontrol akses berbasis peran (RBAC), atau kombinasi dari kedua model. Kami menyarankan Anda menggunakan pola dan konsep desain yang disediakan dalam panduan ini untuk menginformasikan dan menstandarisasi implementasi otorisasi dan kontrol akses API Anda dalam aplikasi SaaS multi-penyewa. Panduan ini membantu mencapai hasil bisnis berikut:

  • Arsitektur otorisasi API standar untuk aplikasi SaaS multi-penyewa — Arsitektur ini membedakan antara tiga komponen: titik administrasi kebijakan (PAP) tempat kebijakan disimpan dan dikelola, titik keputusan kebijakan (PDP) di mana kebijakan tersebut dievaluasi untuk mencapai keputusan otorisasi, dan titik penegakan kebijakan (PEP) yang memberlakukan keputusan tersebut. Layanan otorisasi yang dihosting, Izin Terverifikasi, berfungsi sebagai PAP dan PDP. Atau, Anda dapat membangun PDP Anda sendiri dengan menggunakan mesin open source seperti Cedar atau OPA.

  • Pemisahan logika otorisasi dari aplikasi — Logika otorisasi, ketika disematkan dalam kode aplikasi atau diimplementasikan melalui mekanisme penegakan ad hoc, dapat mengalami perubahan yang tidak disengaja atau berbahaya yang menyebabkan akses data lintas penyewa yang tidak disengaja atau pelanggaran keamanan lainnya. Untuk membantu mengurangi kemungkinan ini, Anda dapat menggunakan PAP, seperti Izin Terverifikasi, untuk menyimpan kebijakan otorisasi secara independen dari kode aplikasi, dan untuk menerapkan tata kelola yang kuat untuk pengelolaan kebijakan tersebut. Kebijakan dapat dipertahankan secara terpusat dalam bahasa deklaratif tingkat tinggi, yang membuat pemeliharaan logika otorisasi jauh lebih sederhana daripada ketika Anda menyematkan kebijakan di beberapa bagian kode aplikasi. Pendekatan ini juga memastikan bahwa pembaruan diterapkan secara konsisten.

  • Pendekatan fleksibel untuk model kontrol akses — Kontrol akses berbasis peran (RBAC), kontrol akses berbasis atribut (ABAC), atau kombinasi kedua model adalah pendekatan yang valid untuk kontrol akses. Model-model ini berusaha memenuhi persyaratan otorisasi untuk bisnis dengan menggunakan pendekatan yang berbeda. Panduan ini membandingkan dan membedakan model-model ini untuk membantu Anda memilih model yang sesuai untuk organisasi Anda. Panduan ini juga membahas bagaimana model ini berlaku untuk bahasa kebijakan otorisasi yang berbeda, seperti OPA/Rego dan Cedar. Arsitektur yang dibahas dalam panduan ini memungkinkan salah satu atau kedua model untuk diadopsi dengan sukses.

  • Kontrol akses API yang ketat — Panduan ini menyediakan metode untuk mengamankan API secara konsisten dan meluas dalam aplikasi dengan sedikit usaha. Ini sangat berharga untuk arsitektur aplikasi berorientasi layanan atau layanan mikro yang umumnya menggunakan sejumlah besar API untuk memfasilitasi komunikasi intra-aplikasi. Kontrol akses API yang ketat membantu meningkatkan keamanan aplikasi dan membuatnya kurang rentan terhadap serangan atau eksploitasi.

Isolasi penyewa dan otorisasi multi-penyewa

Panduan ini mengacu pada konsep isolasi penyewa dan otorisasi multi-penyewa. Isolasi penyewa mengacu pada mekanisme eksplisit yang Anda gunakan dalam sistem SaaS untuk memastikan bahwa sumber daya setiap penyewa, bahkan ketika mereka beroperasi pada infrastruktur bersama, terisolasi. Otorisasi multi-penyewa mengacu pada otorisasi tindakan masuk dan mencegahnya diterapkan pada penyewa yang salah. Pengguna hipotetis dapat diautentikasi dan diotorisasi, dan masih mengakses sumber daya penyewa lain. Otentikasi dan otorisasi tidak akan memblokir akses ini—Anda perlu menerapkan isolasi penyewa untuk mencapai tujuan ini. Untuk diskusi yang lebih luas tentang perbedaan antara kedua konsep ini, lihat bagian isolasi Penyewa dari whitepaper Dasar-Dasar Arsitektur SaaS.