Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pertimbangan desain multi-penyewa Izin Terverifikasi Amazon
Ada beberapa opsi desain yang perlu dipertimbangkan saat Anda menerapkan otorisasi dengan menggunakan Izin Terverifikasi Amazon dalam solusi SaaS multi-penyewa. Sebelum menjelajahi opsi ini, mari kita perjelas perbedaan antara *isolasi* dan *otorisasi* dalam konteks SaaS multi-penyewa. [Mengisolasi](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html) penyewa mencegah data masuk dan keluar terpapar ke penyewa yang salah. Otorisasi memastikan bahwa pengguna memiliki izin untuk mengakses penyewa.
Di Izin Terverifikasi, kebijakan disimpan di toko kebijakan. Seperti yang dijelaskan dalam [dokumentasi Izin Terverifikasi](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/design-multi-tenancy-considerations.html), Anda dapat mengisolasi kebijakan penyewa dengan menggunakan penyimpanan kebijakan terpisah untuk setiap penyewa, atau mengizinkan penyewa untuk berbagi kebijakan dengan menggunakan satu penyimpanan kebijakan untuk semua penyewa. Bagian ini membahas keuntungan dan kerugian dari dua strategi isolasi ini, dan menjelaskan bagaimana mereka dapat digunakan dengan menggunakan model penyebaran berjenjang. Untuk konteks tambahan, lihat dokumentasi Izin Terverifikasi.
Meskipun kritisi yang dibahas di bagian ini berfokus pada Izin Terverifikasi, konsep umum berakar pada [pola pikir isolasi](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/isolation-mindset.html) dan panduan yang diberikannya. Aplikasi SaaS harus selalu mempertimbangkan [isolasi penyewa](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html) sebagai bagian dari desain mereka, dan prinsip umum isolasi ini mencakup Izin Terverifikasi dalam aplikasi SaaS. [Bagian ini juga mereferensikan model isolasi SaaS inti seperti model SaaS [silo dan model SaaS gabungan](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html).](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html) Untuk informasi tambahan, lihat [konsep isolasi inti](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/core-isolation-concepts.html) dalam Kerangka AWS Well-Architected, SaaS Lens.
Pertimbangan utama saat merancang solusi SaaS multi-penyewa adalah isolasi penyewa dan orientasi penyewa. Isolasi penyewa berdampak pada keamanan, privasi, ketahanan, dan kinerja. Orientasi penyewa memengaruhi proses operasional Anda karena berkaitan dengan overhead operasional dan observabilitas. Organizations yang melalui perjalanan SaaS atau menerapkan solusi multi-tenant harus selalu memprioritaskan bagaimana penyewaan akan ditangani oleh aplikasi SaaS. Meskipun solusi SaaS mungkin condong ke model isolasi tertentu, konsistensi tidak selalu diperlukan di seluruh solusi SaaS. Misalnya, model isolasi yang Anda pilih untuk komponen frontend aplikasi Anda mungkin tidak sama dengan model isolasi yang Anda pilih untuk layanan microservice atau otorisasi.
**Topics**
+ [Orientasi penyewa dan pendaftaran penyewa pengguna](avp-design-onboarding-registration.md)
+ [Toko kebijakan per penyewa](avp-design-per-tenant-store.md)
+ [Satu toko kebijakan multi-penyewa bersama](avp-design-shared-store.md)
+ [Model penyebaran berjenjang](avp-design-tiered.md)
# Orientasi penyewa dan pendaftaran penyewa pengguna
Aplikasi SaaS mengamati konsep [identitas SaaS dan mengikuti praktik terbaik umum untuk [mengikat identitas pengguna ke identitas penyewa](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/general-design-principles.html)](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/saas-identity.html). Binding melibatkan penyimpanan pengenal penyewa sebagai klaim atau atribut untuk pengguna di penyedia identitas. Ini mengalihkan tanggung jawab pemetaan identitas kepada penyewa dari setiap aplikasi ke proses pendaftaran pengguna. Setiap pengguna yang diautentikasi kemudian memiliki identitas penyewa yang benar sebagai bagian dari JSON Web Token (JWT).
Demikian pula, pemilihan penyimpanan kebijakan yang benar untuk permintaan otorisasi tidak boleh ditentukan oleh logika aplikasi. Untuk menentukan penyimpanan kebijakan mana yang harus digunakan permintaan otorisasi tertentu, pertahankan pemetaan pengguna ke toko kebijakan, atau penyewa ke toko kebijakan. Pemetaan ini biasanya disimpan di penyimpanan data seperti Amazon DynamoDB atau Amazon Relational Database Service (Amazon RDS) yang menjadi referensi aplikasi Anda. Anda juga dapat memberikan atau melengkapi pemetaan ini dengan data di penyedia identitas (iDP). Hubungan antara penyewa, pengguna, dan toko kebijakan kemudian biasanya diberikan kepada pengguna melalui JWT yang berisi semua hubungan yang diperlukan untuk permintaan otorisasi.
Contoh ini menunjukkan bagaimana JWT mungkin muncul untuk pengguna`Alice`, yang termasuk dalam penyewa `TenantA` dan menggunakan penyimpanan kebijakan dengan ID `ps-43214321` penyimpanan kebijakan untuk otorisasi.
```
{
"sub":"1234567890",
"name":"Alice",
"tenant":"TenantA",
"policyStoreId":"ps-43214321"
}
```
# Toko kebijakan per penyewa
Model desain toko kebijakan per-penyewa di Izin Terverifikasi Amazon mengaitkan setiap penyewa dalam aplikasi SaaS dengan toko kebijakannya sendiri. Model ini mirip dengan model isolasi [silo](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html) SaaS. Kedua model mengamanatkan penciptaan infrastruktur khusus penyewa dan memiliki manfaat dan kerugian yang sama. Manfaat utama dari pendekatan ini adalah isolasi penyewa yang diberlakukan infrastruktur, dukungan untuk model otorisasi unik berdasarkan per-penyewa, penghapusan masalah [tetangga yang bising](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/noisy-neighbor.html), dan pengurangan cakupan dampak kegagalan dalam pembaruan atau penerapan kebijakan. Kerugian dari pendekatan ini termasuk proses orientasi penyewa yang lebih kompleks, penerapan, dan operasi. Toko kebijakan per penyewa adalah pendekatan yang disarankan jika solusi memiliki kebijakan unik per penyewa.
Model toko kebijakan per-penyewa dapat memberikan pendekatan yang sangat silo untuk isolasi penyewa, jika aplikasi SaaS Anda memerlukannya. Anda juga dapat menggunakan model ini dengan [isolasi kolam](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html), tetapi implementasi Izin Terverifikasi Anda tidak akan berbagi manfaat standar dari model isolasi kolam yang lebih luas seperti manajemen dan operasi yang disederhanakan.
Di toko kebijakan per-penyewa, isolasi penyewa dicapai dengan memetakan pengenal toko kebijakan penyewa ke Identitas SaaS pengguna selama proses pendaftaran pengguna, seperti yang dibahas sebelumnya. Pendekatan ini sangat mengikat toko kebijakan penyewa dengan prinsipal pengguna dan menyediakan cara yang konsisten untuk berbagi pemetaan di seluruh solusi SaaS. Anda dapat memberikan pemetaan ke aplikasi SaaS dengan mempertahankannya sebagai bagian dari IDP atau dalam sumber data eksternal seperti DynamoDB. Ini juga memastikan bahwa kepala sekolah adalah bagian dari penyewa dan bahwa penyimpanan kebijakan penyewa digunakan.
Contoh ini menunjukkan bagaimana JWT yang berisi `policyStoreId` dan `tenant` pengguna diteruskan dari titik akhir API ke titik evaluasi kebijakan di AWS Lambda otorisasi, yang merutekan permintaan ke penyimpanan kebijakan yang benar.
![\[Model penyimpanan kebijakan per penyewa di Izin Terverifikasi Amazon\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-per-tenant.png)
Contoh kebijakan berikut menggambarkan paradigma desain toko kebijakan per penyewa. Pengguna `Alice` milik `TenantA.` The juga policyStoreId `store-a` dipetakan ke identitas penyewa `Alice,` dan memberlakukan penggunaan toko kebijakan yang benar. Ini memastikan bahwa kebijakan `TenantA` digunakan.
**catatan**
Model toko kebijakan per-penyewa mengisolasi kebijakan penyewa. Otorisasi memberlakukan tindakan yang diizinkan dilakukan pengguna pada data mereka. Sumber daya yang terlibat dalam aplikasi hipotetis apa pun yang menggunakan model ini harus diisolasi dengan menggunakan mekanisme isolasi lain, sebagaimana didefinisikan dalam [Kerangka AWS Well-Architected, dokumentasi Lensa SaaS](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/core-isolation-concepts.html).
Dalam kebijakan ini, `Alice` memiliki izin untuk melihat data semua sumber daya.
```
permit (
principal == MultiTenantApp::User::"Alice",
action == MultiTenantApp::Action::"viewData",
resource
);
```
Untuk membuat permintaan otorisasi dan memulai evaluasi dengan kebijakan Izin Terverifikasi, Anda harus memberikan ID penyimpanan kebijakan yang sesuai dengan ID unik yang dipetakan ke penyewa. `store-a`
```
{
"policyStoreId":"store-a",
"principal":{
"entityType":"MultiTenantApp::User",
"entityId":"Alice"
},
"action":{
"actionType":"MultiTenantApp::Action",
"actionId":"viewData"
},
"resource":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"entities":{
"entityList":[
[
{
"identifier":{
"entityType":"MultiTenantApp::User",
"entityId":"Alice"
},
"attributes":{},
"parents":[]
},
{
"identifier":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"attributes":{},
"parents":[]
}
]
]
}
}
```
Pengguna `Bob` milik Penyewa B, dan juga policyStoreId `store-b` dipetakan ke identitas penyewa`Bob`, yang memberlakukan penggunaan penyimpanan kebijakan yang benar. Ini memastikan bahwa kebijakan Penyewa B digunakan.
Dalam kebijakan ini, `Bob` memiliki izin untuk menyesuaikan data semua sumber daya. Dalam contoh ini, `customizeData` mungkin tindakan yang khusus hanya untuk Penyewa B, sehingga kebijakan akan unik untuk Penyewa B. Model penyimpanan kebijakan per-penyewa secara inheren mendukung kebijakan khusus berdasarkan per-penyewa.
```
permit (
principal == MultiTenantApp::User::"Bob",
action == MultiTenantApp::Action::"customizeData",
resource
);
```
Untuk membuat permintaan otorisasi dan memulai evaluasi dengan kebijakan Izin Terverifikasi, Anda harus memberikan ID penyimpanan kebijakan yang sesuai dengan ID unik yang dipetakan ke penyewa. `store-b`
```
{
"policyStoreId":"store-b",
"principal":{
"entityType":"MultiTenantApp::User",
"entityId":"Bob"
},
"action":{
"actionType":"MultiTenantApp::Action",
"actionId":"customizeData"
},
"resource":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"entities":{
"entityList":[
[
{
"identifier":{
"entityType":"MultiTenantApp::User",
"entityId":"Bob"
},
"attributes":{},
"parents":[]
},
{
"identifier":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"attributes":{},
"parents":[]
}
]
]
}
}
```
Dengan Izin Terverifikasi, dimungkinkan, tetapi tidak diperlukan, untuk mengintegrasikan iDP dengan toko kebijakan. Integrasi ini memungkinkan kebijakan untuk secara eksplisit merujuk prinsipal di toko identitas sebagai prinsipal kebijakan. [Untuk informasi selengkapnya tentang cara mengintegrasikan dengan Amazon Cognito sebagai iDP untuk Izin Terverifikasi, lihat dokumentasi Izin [Terverifikasi dan dokumentasi](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) Amazon Cognito.](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)
Saat mengintegrasikan penyimpanan kebijakan dengan iDP, Anda hanya dapat menggunakan satu [sumber identitas](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) per toko kebijakan. Misalnya, jika Anda memilih untuk mengintegrasikan Izin Terverifikasi dengan Amazon Cognito, Anda harus mencerminkan strategi yang digunakan untuk isolasi penyewa dari toko kebijakan Izin Terverifikasi dan kumpulan pengguna Amazon Cognito. Toko kebijakan dan kumpulan pengguna juga harus sama Akun AWS.
![\[Mengintegrasikan Izin Terverifikasi dengan Amazon Cognito dalam model desain per penyewa\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/cognito-per-tenant.png)
Pada tingkat operasional, toko kebijakan per penyewa memiliki keunggulan audit, karena Anda dapat dengan mudah menanyakan [aktivitas yang dicatat secara](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/monitoring-overview.html)AWS CloudTrail independen untuk setiap penyewa. Namun, kami tetap menyarankan agar Anda mencatat metrik khusus tambahan pada dimensi per-penyewa ke Amazon. CloudWatch
Pendekatan penyimpanan kebijakan per-penyewa juga memerlukan perhatian yang cermat terhadap dua kuota [Izin Terverifikasi untuk memastikan bahwa kuota](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/quotas.html) tersebut tidak mengganggu pengoperasian solusi SaaS Anda. Kuota ini adalah *toko Kebijakan per Wilayah per akun* dan *IsAuthorized permintaan per detik per Wilayah per akun*. Anda dapat meminta kenaikan untuk kedua kuota.
Untuk contoh lebih rinci tentang cara menerapkan model penyimpanan kebijakan per penyewa, lihat [kontrol akses SaaS AWS posting blog menggunakan Izin Terverifikasi Amazon dengan penyimpanan kebijakan per-penyewa](https://aws.amazon.com/blogs/security/saas-access-control-using-amazon-verified-permissions-with-a-per-tenant-policy-store/).
# Satu toko kebijakan multi-penyewa bersama
Model desain toko kebijakan multi-penyewa bersama menggunakan penyimpanan kebijakan multi-penyewa tunggal di Izin Terverifikasi Amazon untuk semua penyewa dalam solusi SaaS. Manfaat utama dari pendekatan ini adalah manajemen dan operasi yang disederhanakan, terutama karena Anda tidak perlu membuat toko kebijakan tambahan selama orientasi penyewa. Kerugian dari pendekatan ini termasuk peningkatan cakupan dampak dari kegagalan atau kesalahan dalam pembaruan atau penerapan kebijakan, dan paparan yang lebih besar terhadap efek tetangga yang [bising](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/noisy-neighbor.html). Selain itu, kami tidak merekomendasikan pendekatan ini jika solusi Anda memerlukan kebijakan unik untuk setiap penyewa. Dalam hal ini, gunakan model penyimpanan kebijakan per-penyewa sebagai gantinya untuk menjamin bahwa kebijakan penyewa yang benar digunakan.
[Pendekatan penyimpanan kebijakan multi-penyewa bersama mirip dengan model isolasi gabungan SaaS.](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html) Ini dapat memberikan pendekatan gabungan untuk isolasi penyewa, jika aplikasi SaaS Anda membutuhkannya. Anda juga dapat menggunakan model ini jika solusi SaaS Anda menerapkan [isolasi silo ke layanan mikro-nya](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html). Ketika Anda memilih model, Anda harus mengevaluasi persyaratan untuk isolasi data penyewa dan struktur kebijakan Izin Terverifikasi yang diperlukan untuk aplikasi SaaS secara independen.
Untuk menerapkan cara yang konsisten dalam membagikan pengenal penyewa di seluruh solusi SaaS Anda, adalah praktik yang baik untuk memetakan pengenal ke identitas SaaS pengguna selama pendaftaran pengguna, seperti yang dibahas sebelumnya. Anda dapat memberikan pemetaan ini ke aplikasi SaaS dengan mempertahankannya sebagai bagian dari IDP atau dalam sumber data eksternal seperti DynamoDB. Kami juga menyarankan Anda memetakan ID penyimpanan kebijakan bersama kepada pengguna. Meskipun ID tidak digunakan sebagai bagian dari isolasi penyewa, ini adalah praktik yang baik karena memfasilitasi perubahan di masa depan.
Contoh berikut menunjukkan bagaimana titik akhir API mengirimkan JWT untuk pengguna `Alice` dan`Bob`, yang termasuk dalam penyewa yang berbeda tetapi membagikan penyimpanan kebijakan dengan ID penyimpanan kebijakan untuk otorisasi. `store-multi-tenant` Karena semua penyewa berbagi satu toko kebijakan, Anda tidak perlu mempertahankan ID penyimpanan kebijakan dalam token atau database. Karena semua penyewa berbagi satu ID penyimpanan kebijakan, Anda dapat memberikan ID sebagai variabel lingkungan yang dapat digunakan aplikasi Anda untuk melakukan panggilan ke penyimpanan kebijakan.
![\[Model desain bersama Izin Terverifikasi\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-shared.png)
Contoh kebijakan berikut menggambarkan paradigma desain kebijakan multi-penyewa bersama. Dalam kebijakan ini, prinsipal `MultiTenantApp::User` yang memiliki induk `MultiTenantApp::Role` `Admin` memiliki izin untuk melihat data semua sumber daya.
```
permit (
principal in MultiTenantApp::Role::"Admin",
action == MultiTenantApp::Action::"viewData",
resource
);
```
Karena penyimpanan kebijakan tunggal sedang digunakan, penyimpanan kebijakan Izin Terverifikasi harus memastikan bahwa atribut penyewaan yang terkait dengan prinsipal cocok dengan atribut penyewaan yang terkait dengan sumber daya. Ini dapat dicapai dengan menyertakan kebijakan berikut di toko kebijakan, untuk memastikan bahwa semua permintaan otorisasi yang tidak memiliki atribut penyewaan yang cocok pada sumber daya dan prinsipal ditolak.
```
forbid(
principal,
action,
resource
)
unless {
resource.Tenant == principal.Tenant
};
```
Untuk permintaan otorisasi yang menggunakan model penyimpanan kebijakan multi-penyewa bersama, ID penyimpanan kebijakan adalah pengenal penyimpanan kebijakan bersama. Dalam permintaan berikut, akses `User` `Alice` diizinkan karena dia memiliki `Role` dari`Admin`, dan `Tenant` atribut yang terkait dengan sumber daya dan prinsipal keduanya`TenantA`.
```
{
"policyStoreId":"store-multi-tenant",
"principal":{
"entityType":"MultiTenantApp::User",
"entityId":"Alice"
},
"action":{
"actionType":"MultiTenantApp::Action",
"actionId":"viewData"
},
"resource":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"entities":{
"entityList":[
{
"identifier":{
"entityType":"MultiTenantApp::User",
"entityId":"Alice"
},
"attributes": {
{
"Tenant": {
"entityIdentifier": {
"entityType":"MultitenantApp::Tenant",
"entityId":"TenantA"
}
}
}
},
"parents":[
{
"entityType":"MultiTenantApp::Role",
"entityId":"Admin"
}
]
},
{
"identifier":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"attributes": {
{
"Tenant": {
"entityIdentifier": {
"entityType":"MultitenantApp::Tenant",
"entityId":"TenantA"
}
}
}
},
"parents":[]
}
]
}
}
```
Dengan Izin Terverifikasi, dimungkinkan, tetapi tidak diperlukan, untuk mengintegrasikan iDP dengan toko kebijakan. Integrasi ini memungkinkan kebijakan untuk secara eksplisit merujuk prinsipal di toko identitas sebagai prinsipal kebijakan. [Untuk informasi selengkapnya tentang cara mengintegrasikan dengan Amazon Cognito sebagai iDP untuk Izin Terverifikasi, lihat dokumentasi Izin [Terverifikasi dan dokumentasi](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) Amazon Cognito.](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)
Saat mengintegrasikan penyimpanan kebijakan dengan iDP, Anda hanya dapat menggunakan satu [sumber identitas](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) per toko kebijakan. Misalnya, jika Anda memilih untuk mengintegrasikan Izin Terverifikasi dengan Amazon Cognito, Anda harus mencerminkan strategi yang digunakan untuk isolasi penyewa dari toko kebijakan Izin Terverifikasi dan kumpulan pengguna Amazon Cognito. Toko kebijakan dan kumpulan pengguna juga harus sama Akun AWS.
![\[Mengintegrasikan Izin Terverifikasi dengan Amazon Cognito dalam model desain bersama\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/cognito-shared.png)
Dari perspektif operasional dan audit, model penyimpanan kebijakan multi-penyewa bersama memiliki kelemahan karena aktivitas yang [dicatat AWS CloudTrail memerlukan lebih banyak kueri yang terlibat untuk menyaring aktivitas](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/monitoring-overview.html) individu pada penyewa, karena setiap CloudTrail panggilan yang dicatat menggunakan penyimpanan kebijakan yang sama. Dalam skenario ini, akan sangat membantu untuk mencatat metrik khusus tambahan pada dimensi per-penyewa ke Amazon CloudWatch untuk memastikan tingkat pengamatan dan kemampuan audit yang sesuai.
Pendekatan penyimpanan kebijakan multi-penyewa bersama juga memerlukan perhatian yang cermat terhadap kuota [Izin Terverifikasi untuk memastikan bahwa kuota](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/quotas.html) tersebut tidak mengganggu pengoperasian solusi SaaS Anda. Secara khusus, kami menyarankan Anda memantau *IsAuthorized permintaan per detik per Wilayah per kuota akun* untuk memastikan bahwa batasannya tidak terlampaui. Anda dapat meminta kenaikan kuota ini.
# Model penyebaran berjenjang
Dengan membuat model penerapan berjenjang, Anda dapat mengisolasi penyewa “Tingkat Perusahaan” prioritas tinggi dari volume pelanggan “Tingkat Standar” yang berpotensi lebih tinggi. Dalam model ini, Anda dapat meluncurkan perubahan apa pun yang diterapkan pada kebijakan di toko kebijakan secara terpisah untuk setiap tingkat, yang mengisolasi setiap tingkat pelanggan dari perubahan yang dilakukan di luar tingkat mereka. Dalam model penerapan berjenjang, penyimpanan kebijakan biasanya dibuat sebagai bagian dari penyediaan infrastruktur awal untuk setiap tingkatan alih-alih diterapkan saat penyewa di-onboard.
Jika solusi Anda terutama menggunakan model isolasi gabungan, Anda mungkin memerlukan isolasi atau penyesuaian tambahan. Misalnya, Anda dapat membuat “Tingkat Premium” di mana setiap penyewa akan mendapatkan infrastruktur tingkat penyewa mereka sendiri, yang membuat model siloed dengan menerapkan instance gabungan dengan hanya satu penyewa. Ini bisa berupa infrastruktur “Premium Tier Tenant A” dan “Premium Tier Tenant B” yang benar-benar terpisah, termasuk toko kebijakan. Pendekatan ini menghasilkan model isolasi tersilo untuk pelanggan tingkat tertinggi.
Dalam model penerapan berjenjang, setiap toko kebijakan harus mengikuti model isolasi yang sama, meskipun diterapkan secara terpisah. Karena ada beberapa toko kebijakan yang digunakan, Anda perlu menerapkan cara yang konsisten untuk membagikan pengenal toko kebijakan yang terkait dengan penyewa di seluruh solusi SaaS. Seperti halnya model penyimpanan kebijakan per-penyewa, merupakan praktik yang baik untuk memetakan pengenal penyewa ke identitas SaaS pengguna selama pendaftaran pengguna.
Diagram berikut menunjukkan tiga tingkatan:`Standard Tier`,`Enterprise Tier`, dan`Premium Tier 1`. Setiap tingkatan dikerahkan secara terpisah di infrastrukturnya sendiri dan menggunakan satu penyimpanan kebijakan bersama di dalam tingkatan. Tingkatan Standar dan Perusahaan berisi banyak penyewa. `TenantA`dan `TenantB` berada di`Standard Tier`, dan `TenantC` dan `TenantD` berada di Tingkat Perusahaan.
`Premium Tier 1`hanya berisi`TenantP`, sehingga Anda dapat melayani penyewa premium seolah-olah solusinya memiliki model isolasi yang sepenuhnya tertutup dan menyediakan fitur seperti kebijakan yang disesuaikan. Orientasi pelanggan tingkat premium baru akan menghasilkan penciptaan `Premium Tier 2` infrastruktur.
**catatan**
Aplikasi, penerapan, dan orientasi penyewa di tingkat premium identik dengan tingkatan standar dan perusahaan. Satu-satunya perbedaan adalah alur kerja orientasi tingkat premium dimulai dengan penyediaan infrastruktur tingkat baru.
![\[Model penerapan berjenjang Izin Terverifikasi\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-tiered-deployment.png)