Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Menerapkan PDP dengan menggunakan Izin Terverifikasi Amazon
Izin Terverifikasi Amazon adalah layanan pengelolaan izin dan otorisasi yang dapat diskalakan dan berbutir halus yang dapat Anda gunakan untuk menerapkan titik keputusan kebijakan (PDP). Sebagai mesin kebijakan, ini dapat membantu aplikasi Anda memverifikasi tindakan pengguna secara real time dan menyoroti izin yang terlalu istimewa atau tidak valid. Ini membantu pengembang Anda membangun aplikasi yang lebih aman lebih cepat dengan mengeksternalisasi otorisasi dan memusatkan manajemen dan administrasi kebijakan. Dengan memisahkan logika otorisasi dari logika aplikasi, Izin Terverifikasi mendukung decoupling kebijakan.
[Dengan menggunakan Izin Terverifikasi untuk menerapkan PDP dan menerapkan hak istimewa paling sedikit dan verifikasi berkelanjutan dalam aplikasi, pengembang dapat menyelaraskan akses aplikasi mereka dengan prinsip Zero Trust.](https://aws.amazon.com/security/zero-trust/) Selain itu, tim keamanan dan audit dapat menganalisis dan mengaudit dengan lebih baik siapa yang memiliki akses ke sumber daya mana dalam suatu aplikasi. Izin Terverifikasi menggunakan [Cedar](https://www.cedarpolicy.com/en), yang merupakan bahasa kebijakan sumber terbuka yang dibuat khusus dan mengutamakan keamanan, untuk menentukan kontrol akses berbasis kebijakan berdasarkan kontrol akses berbasis peran (RBAC) dan kontrol akses berbasis atribut (ABAC) untuk kontrol akses yang lebih terperinci dan sadar konteks.
Izin Terverifikasi menyediakan beberapa fitur berguna untuk aplikasi SaaS, seperti kemampuan untuk mengaktifkan otorisasi multi-penyewa dengan menggunakan beberapa penyedia identitas seperti Amazon Cognito, Google, dan Facebook. Fitur Izin Terverifikasi lainnya yang sangat membantu untuk aplikasi SaaS adalah dukungan untuk peran khusus berdasarkan per-penyewa. Jika Anda merancang sistem manajemen hubungan pelanggan (CRM), satu penyewa mungkin menentukan perincian akses dengan peluang penjualan berdasarkan satu set kriteria tertentu. Penyewa lain mungkin memiliki definisi lain. Sistem izin yang mendasari dalam Izin Terverifikasi dapat mendukung variasi ini, yang menjadikannya kandidat yang sangat baik untuk kasus penggunaan SaaS. Izin Terverifikasi juga mendukung kemampuan untuk menulis kebijakan yang berlaku untuk semua penyewa, sehingga sangat mudah untuk menerapkan kebijakan pagar pembatas untuk mencegah akses tidak sah sebagai penyedia SaaS.
![\[Menggunakan Izin Terverifikasi Amazon untuk mengimplementasikan PDP\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp.png)
**Mengapa menggunakan Izin Terverifikasi?**
Gunakan Izin Terverifikasi dengan penyedia identitas seperti [Amazon](https://aws.amazon.com/cognito/) Cognito untuk solusi manajemen akses berbasis kebijakan yang lebih dinamis untuk aplikasi Anda. Anda dapat membangun aplikasi yang membantu pengguna berbagi informasi dan berkolaborasi sambil menjaga keamanan, kerahasiaan, dan privasi data mereka. Izin Terverifikasi membantu mengurangi biaya operasional dengan memberi Anda sistem otorisasi berbutir halus untuk menegakkan akses berdasarkan peran dan atribut identitas dan sumber daya Anda. Anda dapat menentukan model kebijakan, membuat dan menyimpan kebijakan di lokasi pusat, dan mengevaluasi permintaan akses dalam milidetik.
Di Izin Terverifikasi, Anda dapat mengekspresikan izin dengan menggunakan bahasa deklaratif sederhana yang dapat dibaca manusia yang disebut Cedar. Kebijakan yang ditulis dalam Cedar dapat dibagikan di seluruh tim terlepas dari bahasa pemrograman yang digunakan oleh aplikasi masing-masing tim.
**Apa yang harus dipertimbangkan saat Anda menggunakan Izin Terverifikasi**
Di Izin Terverifikasi, Anda dapat membuat kebijakan dan mengotomatiskannya sebagai bagian dari penyediaan. Anda juga dapat membuat kebijakan saat runtime sebagai bagian dari logika aplikasi. Sebagai praktik terbaik, Anda harus menggunakan pipeline integrasi berkelanjutan dan penerapan berkelanjutan (CI/CD) untuk mengelola, memodifikasi, dan melacak versi kebijakan saat membuat kebijakan sebagai bagian dari orientasi dan penyediaan penyewa. Atau, aplikasi dapat mengelola, memodifikasi, dan melacak versi kebijakan; namun, logika aplikasi tidak secara inheren menjalankan fungsi ini. Untuk mendukung kemampuan ini dalam aplikasi Anda, Anda harus secara eksplisit merancang aplikasi Anda untuk mengimplementasikan fungsi ini.
Jika diperlukan untuk menyediakan data eksternal dari sumber lain untuk mencapai keputusan otorisasi, data ini harus diambil dan diberikan kepada Izin Terverifikasi sebagai bagian dari permintaan otorisasi. Konteks, entitas, dan atribut tambahan tidak diambil secara default dengan layanan ini.
# Ikhtisar cedar
Cedar adalah bahasa kontrol akses berbasis kebijakan yang fleksibel, dapat diperluas, dan dapat diskalakan yang membantu pengembang mengekspresikan izin aplikasi sebagai kebijakan. Administrator dan pengembang dapat menentukan kebijakan yang mengizinkan atau melarang pengguna untuk bertindak atas sumber daya aplikasi. Beberapa kebijakan dapat dilampirkan ke satu sumber daya. Saat pengguna aplikasi Anda mencoba melakukan tindakan pada sumber daya, aplikasi Anda meminta otorisasi dari mesin kebijakan Cedar. Cedar mengevaluasi kebijakan yang berlaku dan mengembalikan keputusan `ALLOW` atau`DENY`. Cedar mendukung aturan otorisasi untuk semua jenis prinsipal dan sumber daya, memungkinkan kontrol akses berbasis peran (RBAC) dan kontrol akses berbasis atribut (ABAC), dan mendukung analisis melalui alat penalaran otomatis.
Cedar memungkinkan Anda memisahkan logika bisnis Anda dari logika otorisasi. Ketika Anda membuat permintaan dari kode aplikasi Anda, Anda memanggil mesin otorisasi Cedar untuk menentukan apakah permintaan tersebut diotorisasi. Jika diotorisasi (keputusannya`ALLOW`), aplikasi Anda dapat melakukan operasi yang diminta. Jika tidak diotorisasi (keputusannya`DENY`), aplikasi Anda dapat mengembalikan pesan kesalahan. Fitur utama Cedar meliputi:
+ **Ekspresif** - Cedar dibuat khusus untuk mendukung kasus penggunaan otorisasi dan dikembangkan dengan mempertimbangkan keterbacaan manusia.
+ **Kinerja** — Cedar mendukung kebijakan pengindeksan untuk pengambilan cepat, dan menyediakan evaluasi real-time yang cepat dan terukur dengan latensi terbatas.
+ **Analisis** — Cedar mendukung alat analisis yang dapat mengoptimalkan kebijakan Anda dan memverifikasi model keamanan Anda.
Untuk informasi lebih lanjut, lihat situs [web Cedar](https://www.cedarpolicy.com/).
# Contoh 1: ABAC Dasar dengan Izin Terverifikasi dan Cedar
Dalam skenario contoh ini, Izin Terverifikasi Amazon digunakan untuk menentukan pengguna mana yang diizinkan mengakses informasi dalam layanan mikro Payroll fiksi. Bagian ini mencakup cuplikan kode Cedar untuk menunjukkan bagaimana Anda dapat menggunakan Cedar untuk membuat keputusan kontrol akses. Contoh-contoh ini tidak dimaksudkan untuk memberikan eksplorasi penuh atas kemampuan yang disediakan oleh Cedar dan Izin Terverifikasi. Untuk ikhtisar Cedar yang lebih menyeluruh, lihat dokumentasi [Cedar](https://docs.cedarpolicy.com/).
Dalam diagram berikut, kami ingin menegakkan dua aturan bisnis umum yang terkait dengan `viewSalary` `GET` metode ini: *Karyawan dapat melihat gaji mereka sendiri* dan *Karyawan dapat melihat gaji siapa saja yang melapor kepada mereka*. Anda dapat menerapkan aturan bisnis ini dengan menggunakan kebijakan Izin Terverifikasi.
![\[Contoh implementasi ABAC dasar dengan Izin Terverifikasi Amazon dan Cedar untuk mengimplementasikan PDP\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-1.png)
*Karyawan dapat melihat gaji mereka sendiri.*
Dalam Cedar, konstruksi dasar adalah *entitas*, yang mewakili prinsip, tindakan, atau sumber daya. Untuk membuat permintaan otorisasi dan memulai evaluasi dengan kebijakan Izin Terverifikasi, Anda perlu memberikan *prinsipal,* *tindakan*, *sumber daya,* dan *daftar entitas*.
+ Principal (`principal`) adalah pengguna atau peran yang masuk.
+ Action (`action`) adalah operasi yang dievaluasi oleh permintaan.
+ Resource (`resource`) adalah komponen yang diakses oleh tindakan.
+ Daftar entitas (`entityList`) berisi semua entitas yang diperlukan untuk mengevaluasi permintaan.
Untuk memenuhi aturan bisnis *Karyawan dapat melihat gaji mereka sendiri*, Anda dapat memberikan kebijakan Izin Terverifikasi seperti berikut ini.
```
permit (
principal,
action == Action::"viewSalary",
resource
)
when {
principal == resource.owner
};
```
Kebijakan ini mengevaluasi `ALLOW` apakah `Action` is `viewSalary` dan sumber daya dalam permintaan memiliki pemilik atribut yang sama dengan prinsipal. Misalnya, jika Bob adalah pengguna yang masuk yang meminta laporan gaji dan juga pemilik laporan gaji, kebijakan akan mengevaluasi`ALLOW`.
Permintaan otorisasi berikut diserahkan ke Izin Terverifikasi untuk dievaluasi oleh kebijakan sampel. Dalam contoh ini, Bob adalah pengguna yang masuk yang membuat `viewSalary` permintaan. Oleh karena itu, Bob adalah prinsipal dari tipe entitas`Employee`. Tindakan yang coba dilakukan Bob adalah `viewSalary,` dan sumber daya yang `viewSalary` akan ditampilkan adalah `Salary-Bob` dengan jenisnya`Salary`. Untuk mengevaluasi apakah Bob dapat melihat `Salary-Bob` sumber daya, Anda perlu menyediakan struktur entitas yang menghubungkan tipe `Employee` dengan nilai `Bob` (prinsipal) ke atribut pemilik sumber daya yang memiliki tipe`Salary`. Anda menyediakan struktur ini di`entityList`, di mana atribut yang terkait dengan `Salary` menyertakan pemilik, yang menentukan `entityIdentifier` yang berisi tipe `Employee` dan nilai`Bob`. Izin Terverifikasi membandingkan yang `principal` disediakan dalam permintaan otorisasi dengan `owner` atribut yang terkait dengan `Salary` sumber daya untuk membuat keputusan.
```
{
"policyStoreId": "PAYROLLAPP_POLICYSTOREID",
"principal": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
},
"action": {
"actionType": "PayrollApp::Action",
"actionId": "viewSalary"
},
"resource": {
"entityType": "PayrollApp::Salary",
"entityId": "Salary-Bob"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "PayrollApp::Salary",
"entityId": "Salary-Bob"
},
"attributes": {
"owner": {
"entityIdentifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
}
}
}
},
{
"identifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
},
"attributes": {}
}
]
}
}
```
Permintaan otorisasi untuk Izin Terverifikasi mengembalikan berikut ini sebagai output, di mana atributnya `decision` adalah salah satu atau`ALLOW`. `DENY`
```
{
"determiningPolicies":
[
{
"determiningPolicyId": "PAYROLLAPP_POLICYSTOREID"
}
],
"decision": "ALLOW",
"errors": []
}
```
Dalam hal ini, karena Bob mencoba melihat gajinya sendiri, permintaan otorisasi yang dikirim ke Izin Terverifikasi mengevaluasi. `ALLOW` Namun, tujuan kami adalah menggunakan Izin Terverifikasi untuk menegakkan dua aturan bisnis. Aturan bisnis yang menyatakan hal-hal berikut juga harus benar:
*Karyawan dapat melihat gaji siapa saja yang melapor kepada mereka.*
Untuk memenuhi aturan bisnis ini, Anda dapat memberikan kebijakan lain. Kebijakan berikut mengevaluasi `ALLOW` apakah tindakan tersebut `viewSalary` dan sumber daya dalam permintaan memiliki atribut `owner.manager` yang sama dengan prinsipal. Misalnya, jika Alice adalah pengguna yang masuk yang meminta laporan gaji dan Alice adalah manajer pemilik laporan, kebijakan tersebut akan dievaluasi. `ALLOW`
```
permit (
principal,
action == Action::"viewSalary",
resource
)
when {
principal == resource.owner.manager
};
```
Permintaan otorisasi berikut diserahkan ke Izin Terverifikasi untuk dievaluasi oleh kebijakan sampel. Dalam contoh ini, Alice adalah pengguna yang masuk yang membuat `viewSalary` permintaan. Oleh karena itu Alice adalah kepala sekolah dan entitas adalah tipe`Employee`. Tindakan yang Alice coba lakukan adalah`viewSalary`, dan sumber daya yang `viewSalary` akan ditampilkan adalah tipe `Salary` dengan nilai. `Salary-Bob` Untuk mengevaluasi apakah Alice dapat melihat `Salary-Bob` sumber daya, Anda perlu menyediakan struktur entitas yang menghubungkan tipe `Employee` dengan nilai `manager` atribut, yang kemudian harus dikaitkan dengan `owner` atribut tipe `Salary` dengan nilai`Salary-Bob`. `Alice` Anda menyediakan struktur ini di`entityList`, di mana atribut yang terkait dengan `Salary` menyertakan pemilik, yang menentukan `entityIdentifier` yang berisi tipe `Employee` dan nilai`Bob`. Izin Terverifikasi terlebih dahulu memeriksa `owner` atribut, yang mengevaluasi tipe `Employee` dan nilainya. `Bob` Kemudian, Izin Terverifikasi mengevaluasi `manager` atribut yang terkait dengan `Employee` dan membandingkannya dengan prinsipal yang disediakan untuk membuat keputusan otorisasi. Dalam hal ini, keputusannya adalah `ALLOW` karena `resource.owner.manager` atribut `principal ` dan setara.
```
{
"policyStoreId": "PAYROLLAPP_POLICYSTOREID",
"principal": {
"entityType": "PayrollApp::Employee",
"entityId": "Alice"
},
"action": {
"actionType": "PayrollApp::Action",
"actionId": "viewSalary"
},
"resource": {
"entityType": "PayrollApp::Salary",
"entityId": "Salary-Bob"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Alice"
},
"attributes": {
"manager": {
"entityIdentifier": {
"entityType": "PayrollApp::Employee",
"entityId": "None"
}
}
},
"parents": []
},
{
"identifier": {
"entityType": "PayrollApp::Salary",
"entityId": "Salary-Bob"
},
"attributes": {
"owner": {
"entityIdentifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
}
}
},
"parents": []
},
{
"identifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
},
"attributes": {
"manager": {
"entityIdentifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Alice"
}
}
},
"parents": []
}
]
}
}
```
Sejauh ini dalam contoh ini, kami memberikan dua aturan bisnis yang terkait dengan `viewSalary` metode ini, *Karyawan dapat melihat gaji mereka sendiri* dan *Karyawan dapat melihat gaji siapa saja yang melapor kepada mereka*, ke Izin Terverifikasi sebagai kebijakan untuk memenuhi ketentuan masing-masing aturan bisnis secara independen. Anda juga dapat menggunakan satu kebijakan Izin Terverifikasi untuk memenuhi ketentuan kedua aturan bisnis:
*Karyawan dapat melihat gaji mereka sendiri dan gaji siapa saja yang melapor kepada mereka.*
Bila Anda menggunakan permintaan otorisasi sebelumnya, kebijakan berikut akan mengevaluasi `ALLOW` apakah tindakan tersebut `viewSalary` dan sumber daya dalam permintaan memiliki atribut `owner.manager` yang sama dengan`principal`, atau atribut `owner` yang sama dengan. `principal`
```
permit (
principal,
action == PayrollApp::Action::"viewSalary",
resource
)
when {
principal == resource.owner.manager ||
principal == resource.owner
};
```
Misalnya, jika Alice adalah pengguna yang masuk yang meminta laporan gaji, dan jika Alice adalah manajer pemilik atau pemilik laporan, maka kebijakan tersebut akan dievaluasi. `ALLOW`
Untuk informasi selengkapnya tentang menggunakan operator logis dengan kebijakan Cedar, lihat dokumentasi [Cedar](https://docs.cedarpolicy.com/policies/syntax-operators.html).
# Contoh 2: RBAC Dasar dengan Izin Terverifikasi dan Cedar
Contoh ini menggunakan Izin Terverifikasi dan Cedar untuk mendemonstrasikan RBAC dasar. Seperti disebutkan sebelumnya, konstruksi dasar Cedar adalah entitas. Pengembang mendefinisikan entitas mereka sendiri dan secara opsional dapat membuat hubungan antar entitas. Contoh berikut mencakup tiga jenis entitas:`Users`,`Roles`, dan`Problems`. `Students`dan `Teachers` dapat dianggap entitas dari jenis `Role,` dan masing-masing `User` dapat dikaitkan dengan nol atau salah satu`Roles`.
![\[Contoh implementasi RBAC dasar dengan Izin Terverifikasi Amazon dan Cedar untuk mengimplementasikan PDP\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-2.png)
Di Cedar, hubungan ini diekspresikan dengan menghubungkan `Role` `Student` ke `User` `Bob` sebagai induknya. Asosiasi ini secara logis mengelompokkan semua pengguna siswa dalam satu kelompok. Untuk informasi lebih lanjut tentang pengelompokan di Cedar, lihat dokumentasi [Cedar](https://docs.cedarpolicy.com/overview/terminology.html#term-group).
Kebijakan berikut mengevaluasi keputusan untuk tindakan `ALLOW` `submitProblem,` untuk semua kepala sekolah yang terkait dengan kelompok `Students` logis dari jenis tersebut. `Role`
```
permit (
principal in ElearningApp::Role::"Students",
action == ElearningApp::Action::"submitProblem",
resource
);
```
Kebijakan berikut mengevaluasi keputusan `ALLOW` untuk tindakan `submitProblem` atau`answerProblem`, untuk semua prinsip yang terkait dengan kelompok `Teachers` logis dari jenis tersebut. `Role`
```
permit (
principal in ElearningApp::Role::"Teachers",
action in [
ElearningApp::Action::"submitProblem",
ElearningApp::Action::"answerProblem"
],
resource
);
```
Untuk mengevaluasi permintaan dengan kebijakan ini, mesin evaluasi perlu mengetahui apakah prinsipal yang dirujuk dalam permintaan otorisasi adalah anggota kelompok yang sesuai. Oleh karena itu, aplikasi harus meneruskan informasi keanggotaan grup yang relevan ke mesin evaluasi sebagai bagian dari permintaan otorisasi. Ini dilakukan melalui `entities` properti, yang memungkinkan Anda untuk menyediakan mesin evaluasi Cedar dengan atribut dan data keanggotaan grup untuk kepala sekolah dan sumber daya yang terlibat dalam panggilan otorisasi. Dalam kode berikut, keanggotaan grup ditunjukkan dengan mendefinisikan `User::"Bob"` sebagai orang tua yang dipanggil`Role::"Students"`.
```
{
"policyStoreId": "ELEARNING_POLICYSTOREID",
"principal": {
"entityType": "ElearningApp::User",
"entityId": "Bob"
},
"action": {
"actionType": "ElearningApp::Action",
"actionId": "answerProblem"
},
"resource": {
"entityType": "ElearningApp::Problem",
"entityId": "SomeProblem"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "ElearningApp::User",
"entityId": "Bob"
},
"attributes": {},
"parents": [
{
"entityType": "ElearningApp::Role",
"entityId": "Students"
}
]
},
{
"identifier": {
"entityType": "ElearningApp::Problem",
"entityId": "SomeProblem"
},
"attributes": {},
"parents": []
}
]
}
}
```
Dalam contoh ini, Bob adalah pengguna yang masuk yang membuat `answerProblem` permintaan. Oleh karena itu, Bob adalah prinsipal dan entitas adalah tipe`User`. Tindakan yang Bob coba lakukan adalah`answerProblem`. Untuk mengevaluasi apakah Bob dapat melakukan `answerProblem` tindakan, Anda perlu menyediakan struktur entitas yang menghubungkan entitas `User` dengan nilai `Bob` dan menetapkan keanggotaan grupnya dengan mencantumkan entitas induk sebagai`Role::"Students"`. Karena entitas dalam grup pengguna hanya `Role::"Students"` diizinkan untuk melakukan tindakan`submitProblem`, permintaan otorisasi ini akan dievaluasi. `DENY`
Di sisi lain, jika tipe `User` yang memiliki nilai `Alice` dan merupakan bagian dari grup `Role::"Teachers"` mencoba melakukan `answerProblem` tindakan, permintaan otorisasi mengevaluasi`ALLOW`, karena kebijakan menentukan bahwa kepala sekolah dalam grup `Role::"Teachers"` diizinkan untuk melakukan tindakan pada semua sumber daya. `answerProblem` Kode berikut menunjukkan jenis permintaan otorisasi yang mengevaluasi. `ALLOW`
```
{
"policyStoreId": "ELEARNING_POLICYSTOREID",
"principal": {
"entityType": "ElearningApp::User",
"entityId": "Alice"
},
"action": {
"actionType": "ElearningApp::Action",
"actionId": "answerProblem"
},
"resource": {
"entityType": "ElearningApp::Problem",
"entityId": "SomeProblem"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "ElearningApp::User",
"entityId": "Alice"
},
"attributes": {},
"parents": [
{
"entityType": "ElearningApp::Role",
"entityId": "Teachers"
}
]
},
{
"identifier": {
"entityType": "ElearningApp::Problem",
"entityId": "SomeProblem"
},
"attributes": {},
"parents": []
}
]
}
}
```
# Contoh 3: Kontrol akses multi-penyewa dengan RBAC
Untuk menguraikan contoh RBAC sebelumnya, Anda dapat memperluas persyaratan Anda untuk memasukkan multi-tenancy SaaS, yang merupakan persyaratan umum untuk penyedia SaaS. Dalam solusi multi-penyewa, akses sumber daya selalu disediakan atas nama penyewa tertentu. Artinya, pengguna Tenant A tidak dapat melihat data Tenant B, bahkan jika data tersebut secara logis atau fisik ditempatkan dalam suatu sistem. Contoh berikut menggambarkan bagaimana Anda dapat menerapkan isolasi penyewa dengan menggunakan beberapa [penyimpanan kebijakan Izin Terverifikasi, dan bagaimana Anda dapat menggunakan peran pengguna untuk menentukan izin](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-stores.html) dalam penyewa.
Menggunakan pola desain Toko Kebijakan Per Penyewa adalah praktik terbaik untuk mempertahankan isolasi penyewa sambil menerapkan kontrol akses dengan Izin Terverifikasi. Dalam skenario ini, permintaan pengguna Penyewa A dan Penyewa B diverifikasi terhadap penyimpanan kebijakan terpisah, `DATAMICROSERVICE_POLICYSTORE_A` dan`DATAMICROSERVICE_POLICYSTORE_B`, masing-masing. Untuk informasi selengkapnya tentang pertimbangan desain Izin Terverifikasi untuk aplikasi SaaS multi-penyewa, lihat [bagian pertimbangan desain multi-penyewa Izin Terverifikasi](avp-design-considerations.md).
![\[Contoh kontrol akses multi-tenant dengan RBAC, Izin Terverifikasi Amazon, dan Cedar\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-3.png)
Kebijakan berikut berada di toko `DATAMICROSERVICE_POLICYSTORE_A` kebijakan. Ini memverifikasi bahwa kepala sekolah akan menjadi bagian dari kelompok `allAccessRole` tipe`Role`. Dalam hal ini, kepala sekolah akan diizinkan untuk melakukan `viewData` dan `updateData` tindakan pada semua sumber daya yang terkait dengan Penyewa A.
```
permit (
principal in MultitenantApp::Role::"allAccessRole",
action in [
MultitenantApp::Action::"viewData",
MultitenantApp::Action::"updateData"
],
resource
);
```
Kebijakan berikut berada di toko `DATAMICROSERVICE_POLICYSTORE_B` kebijakan. Kebijakan pertama memverifikasi bahwa prinsipal adalah bagian dari `updateDataRole` kelompok tipe`Role`. Dengan asumsi demikian, ia memberikan izin kepada kepala sekolah untuk melakukan `updateData` tindakan pada sumber daya yang terkait dengan Penyewa B.
```
permit (
principal in MultitenantApp::Role::"updateDataRole",
action == MultitenantApp::Action::"updateData",
resource
);
```
Kebijakan kedua ini mengamanatkan bahwa kepala sekolah yang merupakan bagian dari `viewDataRole` kelompok tipe `Role` harus diizinkan untuk melakukan `viewData` tindakan terhadap sumber daya yang terkait dengan Penyewa B.
```
permit (
principal in MultitenantApp::Role::"viewDataRole",
action == MultitenantApp::Action::"viewData",
resource
);
```
Permintaan otorisasi yang dibuat dari Penyewa A perlu dikirim ke toko `DATAMICROSERVICE_POLICYSTORE_A` kebijakan dan diverifikasi oleh kebijakan milik toko tersebut. Dalam hal ini, ini diverifikasi oleh kebijakan pertama yang dibahas sebelumnya sebagai bagian dari contoh ini. Dalam permintaan otorisasi ini, prinsipal tipe `User` dengan nilai `Alice` meminta untuk melakukan tindakan. `viewData` Kepala sekolah termasuk dalam kelompok `allAccessRole` tipe`Role`. Alice sedang mencoba untuk melakukan `viewData` tindakan pada `SampleData` sumber daya. Karena Alice memiliki `allAccessRole` peran, evaluasi ini menghasilkan `ALLOW` keputusan.
```
{
"policyStoreId": "DATAMICROSERVICE_POLICYSTORE_A",
"principal": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"action": {
"actionType": "MultitenantApp::Action",
"actionId": "viewData"
},
"resource": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"attributes": {},
"parents": [
{
"entityType": "MultitenantApp::Role",
"entityId": "allAccessRole"
}
]
},
{
"identifier": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"attributes": {},
"parents": []
}
]
}
}
```
Jika, sebaliknya, Anda melihat permintaan yang dibuat dari Penyewa B oleh`User Bob`, Anda akan melihat sesuatu seperti permintaan otorisasi berikut. Permintaan dikirim ke toko `DATAMICROSERVICE_POLICYSTORE_B` kebijakan karena berasal dari Penyewa B. Dalam permintaan ini, kepala sekolah `Bob` ingin melakukan tindakan `updateData` pada sumber daya. `SampleData` Namun, `Bob` bukan bagian dari grup yang memiliki akses ke tindakan `updateData` pada sumber daya itu. Oleh karena itu, permintaan menghasilkan `DENY` keputusan.
```
{
"policyStoreId": "DATAMICROSERVICE_POLICYSTORE_B",
"principal": {
"entityType": "MultitenantApp::User",
"entityId": "Bob"
},
"action": {
"actionType": "MultitenantApp::Action",
"actionId": "updateData"
},
"resource": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "MultitenantApp::User",
"entityId": "Bob"
},
"attributes": {},
"parents": [
{
"entityType": "MultitenantApp::Role",
"entityId": "viewDataRole"
}
]
},
{
"identifier": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"attributes": {},
"parents": []
}
]
}
}
```
Dalam contoh ketiga ini, `User Alice ` cobalah untuk melakukan `viewData` tindakan pada sumber daya`SampleData`. Permintaan ini diarahkan ke toko `DATAMICROSERVICE_POLICYSTORE_A` kebijakan karena kepala sekolah `Alice` milik Penyewa A. `Alice` adalah bagian `allAccessRole` dari kelompok tipe`Role`, yang memungkinkannya untuk melakukan `viewData` tindakan pada sumber daya. Dengan demikian, permintaan menghasilkan `ALLOW` keputusan.
```
{
"policyStoreId": "DATAMICROSERVICE_POLICYSTORE_A",
"principal": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"action": {
"actionType": "MultitenantApp::Action",
"actionId": "viewData"
},
"resource": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"attributes": {},
"parents": [
{
"entityType": "MultitenantApp::Role",
"entityId": "allAccessRole"
}
]
},
{
"identifier": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"attributes": {},
"parents": []
}
]
}
}
```
# Contoh 4: Kontrol akses multi-tenant dengan RBAC dan ABAC
Untuk menyempurnakan contoh RBAC di bagian sebelumnya, Anda dapat menambahkan atribut ke pengguna untuk membuat pendekatan hybrid RBAC-ABAC untuk kontrol akses multi-tenant. Contoh ini mencakup peran yang sama dari contoh sebelumnya, tetapi menambahkan atribut pengguna `account_lockout_flag` dan parameter konteks`uses_mfa`. Contoh ini juga mengambil pendekatan yang berbeda untuk menerapkan kontrol akses multi-penyewa dengan menggunakan RBAC dan ABAC, dan menggunakan satu penyimpanan kebijakan bersama alih-alih penyimpanan kebijakan yang berbeda untuk setiap penyewa.
![\[Contoh kontrol akses multi-penyewa dengan RBAC, ABAC, Izin Terverifikasi Amazon, dan Cedar\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-4.png)
Contoh ini mewakili solusi SaaS multi-penyewa di mana Anda perlu memberikan keputusan otorisasi untuk Penyewa A dan Penyewa B, mirip dengan contoh sebelumnya.
Untuk mengimplementasikan fitur kunci pengguna, contoh menambahkan atribut `account_lockout_flag` ke prinsipal `User` entitas dalam permintaan otorisasi. Bendera ini mengunci akses pengguna ke sistem dan akan `DENY` semua hak istimewa bagi pengguna yang terkunci. `account_lockout_flag`Atribut dikaitkan dengan `User` entitas dan berlaku untuk `User` sampai flag dicabut secara aktif di beberapa sesi. Contoh menggunakan `when` kondisi untuk mengevaluasi`account_lockout_flag`.
Contoh ini juga menambahkan detail tentang permintaan dan sesi. Informasi konteks menentukan bahwa sesi telah diautentikasi dengan menggunakan otentikasi multi-faktor. Untuk mengimplementasikan validasi ini, contoh menggunakan `when` kondisi untuk mengevaluasi `uses_mfa` bendera sebagai bagian dari bidang konteks. Untuk informasi selengkapnya tentang praktik terbaik untuk menambahkan konteks, lihat [dokumentasi Cedar](https://docs.cedarpolicy.com/auth/entities-syntax.html).
```
permit (
principal in MultitenantApp::Role::"allAccessRole",
action in [
MultitenantApp::Action::"viewData",
MultitenantApp::Action::"updateData"
],
resource
)
when {
principal.account_lockout_flag == false &&
context.uses_mfa == true &&
resource in principal.Tenant
};
```
Kebijakan ini mencegah akses ke sumber daya kecuali sumber daya berada dalam grup yang sama dengan `Tenant` atribut prinsipal yang meminta. Pendekatan untuk mempertahankan isolasi penyewa ini disebut sebagai pendekatan *One Shared Multi-Tenant Policy Store*. Untuk informasi selengkapnya tentang pertimbangan desain Izin Terverifikasi untuk aplikasi SaaS multi-penyewa, lihat [bagian pertimbangan desain multi-penyewa Izin Terverifikasi](avp-design-considerations.md).
Kebijakan ini juga memastikan bahwa kepala sekolah adalah anggota `allAccessRole` dan membatasi tindakan untuk `viewData` dan`updateData`. Selain itu, kebijakan ini memverifikasi `account_lockout_flag` itu `false` dan bahwa nilai konteks untuk `uses_mfa` mengevaluasi. `true`
Demikian pula, kebijakan berikut memastikan bahwa prinsipal dan sumber daya terkait dengan penyewa yang sama, yang mencegah akses lintas penyewa. Kebijakan ini juga memastikan bahwa kepala sekolah adalah anggota `viewDataRole` dan membatasi tindakan untuk`viewData`. Selain itu, ini memverifikasi bahwa `account_lockout_flag` adalah `false` dan bahwa nilai konteks untuk `uses_mfa` dievaluasi. `true`
```
permit (
principal in MultitenantApp::Role::"viewDataRole",
action == MultitenantApp::Action::"viewData",
resource
)
when {
principal.account_lockout_flag == false &&
context.uses_mfa == true &&
resource in principal.Tenant
};
```
Kebijakan ketiga mirip dengan yang sebelumnya. Kebijakan mengharuskan sumber daya untuk menjadi anggota grup yang sesuai dengan entitas yang diwakili oleh`principal.Tenant`. Ini memastikan bahwa prinsipal dan sumber daya terkait dengan Penyewa B, yang mencegah akses lintas penyewa. Kebijakan ini memastikan bahwa kepala sekolah adalah anggota `updateDataRole` dan membatasi tindakan untuk`updateData`. Selain itu, kebijakan ini memverifikasi bahwa `account_lockout_flag` adalah `false` dan bahwa nilai konteks untuk `uses_mfa` dievaluasi. `true`
```
permit (
principal in MultitenantApp::Role::"updateDataRole",
action == MultitenantApp::Action::"updateData",
resource
)
when {
principal.account_lockout_flag == false &&
context.uses_mfa == true &&
resource in principal.Tenant
};
```
Permintaan otorisasi berikut dievaluasi oleh tiga kebijakan yang dibahas sebelumnya di bagian ini. Dalam permintaan otorisasi ini, kepala sekolah tipe `User` dan dengan nilai `Alice` membuat `updateData` permintaan dengan peran `allAccessRole` tersebut. `Alice`memiliki atribut `Tenant` yang nilainya`Tenant::"TenantA"`. Tindakan `Alice` yang coba dilakukan adalah `updateData,` dan sumber daya yang akan diterapkan adalah `SampleData` dari jenisnya`Data`. `SampleData`memiliki `TenantA` sebagai entitas induk.
Menurut kebijakan pertama di toko `` kebijakan, `Alice` dapat melakukan `updateData` tindakan pada sumber daya, dengan asumsi bahwa kondisi dalam `when` klausul kebijakan terpenuhi. Kondisi pertama membutuhkan `principal.Tenant` atribut untuk dievaluasi`TenantA`. Kondisi kedua membutuhkan atribut kepala sekolah `account_lockout_flag` untuk menjadi`false`. Kondisi akhir membutuhkan konteksnya `uses_mfa``true`. Karena ketiga kondisi terpenuhi, permintaan mengembalikan `ALLOW` keputusan.
```
{
"policyStoreId": "DATAMICROSERVICE_POLICYSTORE",
"principal": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"action": {
"actionType": "MultitenantApp::Action",
"actionId": "updateData"
},
"resource": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"context": {
"contextMap": {
"uses_mfa": {
"boolean": true
}
}
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"attributes": {
{
"account_lockout_flag": {
"boolean": false
},
"Tenant": {
"entityIdentifier": {
"entityType":"MultitenantApp::Tenant",
"entityId":"TenantA"
}
}
}
},
"parents": [
{
"entityType": "MultitenantApp::Role",
"entityId": "allAccessRole"
}
]
},
{
"identifier": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"attributes": {},
"parents": [
{
"entityType": "MultitenantApp::Tenant",
"entityId": "TenantA"
}
]
}
]
}
}
```
# Contoh 5: Pemfilteran UI dengan Izin Terverifikasi dan Cedar
Anda juga dapat menggunakan Izin Terverifikasi untuk menerapkan pemfilteran RBAC elemen UI berdasarkan tindakan yang diotorisasi. Ini sangat berharga untuk aplikasi yang memiliki elemen UI peka konteks yang mungkin terkait dengan pengguna atau penyewa tertentu dalam kasus aplikasi SaaS multi-penyewa.
Dalam contoh berikut, `Users` dari tidak `Role` `viewer` diizinkan untuk melakukan pembaruan. Untuk pengguna ini, UI tidak boleh membuat tombol pembaruan apa pun.
![\[Contoh pemfilteran UI dengan Izin Terverifikasi Amazon dan Cedar\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-5.png)
Dalam contoh ini, aplikasi web satu halaman memiliki empat tombol. Tombol mana yang terlihat tergantung pada `Role` pengguna yang saat ini masuk ke aplikasi. Saat aplikasi web satu halaman merender UI, ia menanyakan Izin Terverifikasi untuk menentukan tindakan mana yang diizinkan oleh pengguna untuk dilakukan, dan kemudian menghasilkan tombol berdasarkan keputusan otorisasi.
Kebijakan berikut menetapkan bahwa tipe `Role` dengan nilai `viewer` dapat menampilkan pengguna dan data. Keputusan `ALLOW` otorisasi untuk kebijakan ini memerlukan `viewUsers` tindakan `viewData` atau, dan juga memerlukan sumber daya untuk dikaitkan dengan jenis `Data` atau`Users`. `ALLOW`Keputusan memungkinkan UI untuk membuat dua tombol: `viewDataButton` dan`viewUsersButton`.
```
permit (
principal in GuiAPP::Role::"viewer",
action in [GuiAPP::Action::"viewData", GuiAPP::Action::"viewUsers"],
resource
)
when {
resource in [GuiAPP::Type::"Data", GuiAPP::Type::"Users"]
};
```
Kebijakan berikut menetapkan bahwa tipe `Role` dengan nilai hanya `viewerDataOnly` dapat menampilkan data. Keputusan `ALLOW` otorisasi untuk kebijakan ini memerlukan `viewData` tindakan, dan juga memerlukan sumber daya untuk dikaitkan dengan jenisnya`Data`. `ALLOW`Keputusan memungkinkan UI untuk merender tombol`viewDataButton`.
```
permit (
principal in GuiApp::Role::"viewerDataOnly",
action in [GuiApp::Action::"viewData"],
resource in [GuiApp::Type::"Data"]
);
```
Kebijakan berikut menetapkan bahwa tipe `Role` dengan nilai `admin` dapat mengedit dan menampilkan data dan pengguna. Keputusan `ALLOW` otorisasi untuk kebijakan ini memerlukan tindakan`updateData`,, `viewData,` atau `updateUsers``viewUsers`, dan juga memerlukan sumber daya untuk dikaitkan dengan jenis `Data` atau`Users`. `ALLOW`Keputusan memungkinkan UI untuk merender keempat tombol:`updateDataButton`,, `updateUsersButton``viewDataButton`, dan`viewUsersButton`.
```
permit (
principal in GuiApp::Role::"admin",
action in [
GuiApp::Action::"updateData",
GuiApp::Action::"updateUsers",
GuiApp::Action::"viewData",
GuiApp::Action::"viewUsers"
],
resource
)
when {
resource in [GuiApp::Type::"Data", GuiApp::Type::"Users"]
};
```