Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Considerazioni sulla progettazione multi-tenant di Amazon Verified Permissions
Esistono diverse opzioni di progettazione da considerare quando si implementa l'autorizzazione utilizzando Amazon Verified Permissions in una soluzione SaaS multi-tenant. Prima di esplorare queste opzioni, chiariamo la differenza tra *isolamento* e *autorizzazione* in un contesto SaaS multi-tenant. [L'isolamento di](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html) un tenant impedisce che i dati in entrata e in uscita vengano esposti al tenant sbagliato. L'autorizzazione garantisce che un utente disponga delle autorizzazioni per accedere a un tenant.
In Autorizzazioni verificate, le politiche vengono archiviate in un archivio di politiche. Come descritto nella [documentazione sulle autorizzazioni verificate](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/design-multi-tenancy-considerations.html), è possibile isolare le politiche dei tenant utilizzando un archivio di policy separato per ogni tenant oppure consentire ai tenant di condividere le politiche utilizzando un unico archivio di politiche per tutti i tenant. Questa sezione illustra i vantaggi e gli svantaggi di queste due strategie di isolamento e descrive come possono essere implementate utilizzando un modello di distribuzione a più livelli. Per un contesto aggiuntivo, consulta la documentazione sulle autorizzazioni verificate.
Sebbene i criteri discussi in questa sezione si concentrino sulle autorizzazioni verificate, i concetti generali sono radicati nella [mentalità dell'isolamento e nelle linee guida](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/isolation-mindset.html) che fornisce. Le applicazioni SaaS devono sempre considerare [l'isolamento dei tenant](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html) come parte della loro progettazione e questo principio generale di isolamento si estende all'inclusione delle autorizzazioni verificate in un'applicazione SaaS. [Questa sezione fa riferimento anche ai principali modelli di isolamento SaaS, come il modello SaaS in [silos e il modello SaaS](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html) in pool.](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html) Per ulteriori informazioni, consulta i [concetti di isolamento di base](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/core-isolation-concepts.html) in AWS Well-Architected Framework, SaaS Lens.
Le considerazioni chiave nella progettazione di soluzioni SaaS multi-tenant sono l'isolamento dei tenant e l'onboarding dei tenant. L'isolamento dei tenant influisce sulla sicurezza, sulla privacy, sulla resilienza e sulle prestazioni. L'onboarding dei tenant influisce sui processi operativi in relazione al sovraccarico operativo e all'osservabilità. Organizations che intraprendono un percorso SaaS o implementano soluzioni multi-tenant devono sempre dare la priorità al modo in cui la tenancy verrà gestita dall'applicazione SaaS. Sebbene una soluzione SaaS possa orientarsi verso un particolare modello di isolamento, la coerenza non è necessariamente richiesta nell'intera soluzione SaaS. Ad esempio, il modello di isolamento scelto per i componenti di frontend dell'applicazione potrebbe non essere lo stesso del modello di isolamento scelto per un microservizio o per i servizi di autorizzazione.
**Topics**
+ [Inserimento degli inquilini e registrazione degli inquilini come utenti](avp-design-onboarding-registration.md)
+ [Archivio delle politiche per tenant](avp-design-per-tenant-store.md)
+ [Un archivio di policy multi-tenant condiviso](avp-design-shared-store.md)
+ [Modello di implementazione a più livelli](avp-design-tiered.md)
# Inserimento degli inquilini e registrazione degli inquilini come utenti
Le applicazioni SaaS rispettano il concetto di [identità SaaS](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/saas-identity.html) e seguono la best practice generale di associare un'[identità utente a un'identità](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/general-design-principles.html) del tenant. L'associazione implica la memorizzazione di un identificatore del tenant come affermazione o attributo per l'utente nel provider di identità. Ciò sposta la responsabilità della mappatura delle identità dei tenant da ciascuna applicazione al processo di registrazione degli utenti. Ogni utente autenticato dispone quindi dell'identità del tenant corretta come parte del JSON Web Token (JWT).
Analogamente, la selezione del policy store corretto per una richiesta di autorizzazione non dovrebbe essere determinata dalla logica dell'applicazione. Per determinare quale archivio di policy deve essere utilizzato da una particolare richiesta di autorizzazione, gestite una mappatura degli utenti nei policy store o dei tenant nei policy store. Queste mappature vengono generalmente gestite in un archivio dati come Amazon DynamoDB o Amazon Relational Database Service (Amazon RDS) a cui fa riferimento l'applicazione. Puoi anche fornire o integrare queste mappature con i dati in un provider di identità (IdP). La relazione tra inquilini, utenti e archivi delle politiche viene quindi generalmente fornita a un utente tramite un JWT che contiene tutte le relazioni necessarie per una richiesta di autorizzazione.
Questo esempio mostra come potrebbe apparire il JWT per l'utente`Alice`, che appartiene al tenant `TenantA` e utilizza l'archivio delle politiche con l'ID dell'archivio delle politiche per l'autorizzazione. `ps-43214321`
```
{
"sub":"1234567890",
"name":"Alice",
"tenant":"TenantA",
"policyStoreId":"ps-43214321"
}
```
# Archivio delle politiche per tenant
Il modello di progettazione dell'archivio di policy per tenant in Amazon Verified Permissions associa ogni tenant di un'applicazione SaaS al proprio archivio di politiche. Questo modello è simile al modello di isolamento dei [silo](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html) SaaS. Entrambi i modelli richiedono la creazione di un'infrastruttura specifica per il locatario e presentano vantaggi e svantaggi simili. I vantaggi principali di questo approccio sono l'isolamento dei tenant basato sull'infrastruttura, il supporto per modelli di autorizzazione unici su base tenant, l'eliminazione dei problemi legati alla [rumorosità dei vicini e la riduzione dell'impatto in caso di errori negli aggiornamenti](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/noisy-neighbor.html) o nelle implementazioni delle politiche. Gli svantaggi di questo approccio includono processi, implementazioni e operazioni di onboarding dei tenant più complessi. L'archivio delle politiche per tenant è l'approccio consigliato se la soluzione dispone di policy uniche per tenant.
Il modello di archivio delle politiche per tenant può fornire un approccio altamente suddiviso in silos all'isolamento dei tenant, se l'applicazione SaaS lo richiede. È possibile utilizzare questo modello anche con l'[isolamento del pool](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html), ma l'implementazione delle autorizzazioni verificate non condividerà i vantaggi standard del più ampio modello di isolamento del pool, come la gestione e le operazioni semplificate.
In un archivio di policy per tenant, l'isolamento del tenant si ottiene mappando l'identificatore del policy store del tenant all'identità SaaS dell'utente durante il processo di registrazione dell'utente, come discusso in precedenza. Questo approccio lega fortemente l'archivio delle politiche del tenant all'utente principale e fornisce un modo coerente per condividere la mappatura nell'intera soluzione SaaS. Puoi fornire la mappatura a un'applicazione SaaS mantenendola come parte di un IdP o in un'origine dati esterna come DynamoDB. Ciò garantisce inoltre che il committente faccia parte del tenant e che venga utilizzato l'archivio delle politiche del tenant.
Questo esempio mostra come il JWT che contiene l'`policyStoreId`and `tenant` di un utente viene passato dall'endpoint di un'API al punto di valutazione delle politiche in un AWS Lambda autorizzatore, che indirizza la richiesta al policy store corretto.
![\[Modello di archivio delle politiche per tenant in Amazon Verified Permissions\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-per-tenant.png)
La seguente politica di esempio illustra il paradigma di progettazione del policy store per tenant. L'utente `Alice` appartiene a `TenantA.` The policyStoreId `store-a` viene inoltre mappato all'identità del tenant di `Alice,` e impone l'uso del policy store corretto. Ciò garantisce che vengano utilizzate le politiche di. `TenantA`
**Nota**
Il modello di archivio delle politiche per inquilino isola le politiche degli inquilini. L'autorizzazione impone le azioni che gli utenti sono autorizzati a eseguire sui propri dati. Le risorse coinvolte in qualsiasi applicazione ipotetica che utilizza questo modello devono essere isolate utilizzando altri meccanismi di isolamento, come definito nella documentazione di [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/core-isolation-concepts.html), SaaS Lens.
In questa politica, `Alice` dispone delle autorizzazioni per visualizzare i dati di tutte le risorse.
```
permit (
principal == MultiTenantApp::User::"Alice",
action == MultiTenantApp::Action::"viewData",
resource
);
```
Per effettuare una richiesta di autorizzazione e avviare una valutazione con una politica di autorizzazioni verificate, è necessario fornire l'ID dell'archivio delle politiche che corrisponde all'ID univoco mappato al tenant,. `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":[]
}
]
]
}
}
```
L'utente `Bob` appartiene al Tenant B ed policyStoreId `store-b` è inoltre mappato all'identità del tenant di`Bob`, il che impone l'uso del policy store corretto. Ciò garantisce che vengano utilizzate le politiche del Tenant B.
In questa politica, `Bob` dispone delle autorizzazioni per personalizzare i dati di tutte le risorse. In questo esempio, `customizeData` potrebbe trattarsi di un'azione specifica solo per il Tenant B, quindi la politica sarebbe unica per il Tenant B. Il modello di archivio delle politiche per tenant supporta intrinsecamente politiche personalizzate su base per tenant.
```
permit (
principal == MultiTenantApp::User::"Bob",
action == MultiTenantApp::Action::"customizeData",
resource
);
```
Per effettuare una richiesta di autorizzazione e avviare una valutazione con una politica di autorizzazioni verificate, è necessario fornire l'ID dell'archivio delle politiche che corrisponde all'ID univoco mappato al tenant,. `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":[]
}
]
]
}
}
```
Con Verified Permissions, è possibile, ma non necessario, integrare un IdP con un policy store. Questa integrazione consente alle politiche di fare esplicito riferimento al principale nell'archivio di identità come principale delle politiche. [Per ulteriori informazioni su come effettuare l'integrazione con Amazon Cognito come IdP per autorizzazioni verificate, consulta la documentazione sulle autorizzazioni verificate [e la documentazione](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) di Amazon Cognito.](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)
Quando si integra un policy store con un IdP, è possibile utilizzare solo una [fonte di identità](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) per policy store. Ad esempio, se scegli di integrare le autorizzazioni verificate con Amazon Cognito, devi rispecchiare la strategia utilizzata per l'isolamento dei tenant degli archivi di policy di Autorizzazioni verificate e dei pool di utenti di Amazon Cognito. Inoltre, gli archivi delle policy e i pool di utenti devono essere gli stessi. Account AWS
![\[Integrazione delle autorizzazioni verificate con Amazon Cognito in un modello di progettazione per tenant\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/cognito-per-tenant.png)
[A livello operativo, l'archivio delle politiche per tenant offre un vantaggio in termini di controllo, in quanto è possibile interrogare facilmente l'attività registrata in modo indipendente per ogni tenant.](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/monitoring-overview.html)AWS CloudTrail Tuttavia, ti consigliamo comunque di registrare metriche personalizzate aggiuntive su una dimensione per-tenant su Amazon. CloudWatch
L'approccio per-tenant policy store richiede inoltre un'attenzione particolare a due [quote di autorizzazioni verificate](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/quotas.html) per garantire che non interferiscano con le operazioni della soluzione SaaS. Queste quote sono *Policy store per regione per account e *IsAuthorized richieste* al secondo per regione per account*. Puoi richiedere aumenti per entrambe le quote.
Per un esempio più dettagliato di come implementare il modello per-tenant policy store, consulta il AWS post sul blog [Controllo degli accessi SaaS usando Amazon Verified Permissions with a per-tenant](https://aws.amazon.com/blogs/security/saas-access-control-using-amazon-verified-permissions-with-a-per-tenant-policy-store/) policy store.
# Un archivio di policy multi-tenant condiviso
Il modello di progettazione di un unico archivio di policy multi-tenant condiviso utilizza un unico archivio di policy multi-tenant in Amazon Verified Permissions per tutti i tenant della soluzione SaaS. Il vantaggio principale di questo approccio è la gestione e le operazioni semplificate, in particolare perché non è necessario creare archivi di policy aggiuntivi durante l'onboarding dei tenant. [Gli svantaggi di questo approccio includono una maggiore portata dell'impatto derivante da eventuali guasti o errori negli aggiornamenti o nelle implementazioni delle policy e una maggiore esposizione agli effetti rumorosi dei vicini.](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/noisy-neighbor.html) Inoltre, non consigliamo questo approccio se la soluzione richiede politiche uniche per ogni tenant. In questo caso, utilizza invece il modello di archivio delle politiche per tenant per garantire che vengano utilizzate le politiche del tenant corretto.
[L'approccio One shared multi-tenant policy store è simile al modello di isolamento in pool SaaS.](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html) Può fornire un approccio condiviso all'isolamento dei tenant, se l'applicazione SaaS lo richiede. Puoi utilizzare questo modello anche se la tua soluzione SaaS applica l'[isolamento in silos ai suoi microservizi](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html). Quando si sceglie un modello, è necessario valutare i requisiti per l'isolamento dei dati dei tenant e la struttura delle politiche di autorizzazione verificate necessarie per un'applicazione SaaS in modo indipendente.
Per applicare un modo coerente di condividere l'identificatore del tenant sull'intera soluzione SaaS, è buona norma mappare l'identificatore all'identità SaaS dell'utente durante la registrazione dell'utente, come discusso in precedenza. Puoi fornire questa mappatura a un'applicazione SaaS mantenendola come parte di un IdP o in un'origine dati esterna come DynamoDB. Si consiglia inoltre di mappare l'ID condiviso del policy store agli utenti. Sebbene l'ID non venga utilizzato come parte dell'isolamento degli inquilini, si tratta di una buona pratica perché facilita le modifiche future.
L'esempio seguente mostra come l'endpoint API invia un JWT agli utenti `Alice` che appartengono a tenant diversi ma condividono il policy store con l'ID del policy store per l'autorizzazione. `Bob` `store-multi-tenant` Poiché tutti i tenant condividono un unico archivio di politiche, non è necessario mantenere l'ID del policy store in un token o database. Poiché tutti i tenant condividono un unico ID del policy store, è possibile fornire l'ID come variabile di ambiente che l'applicazione può utilizzare per effettuare chiamate al policy store.
![\[Autorizzazioni verificate: modello di progettazione condiviso\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-shared.png)
La seguente policy di esempio illustra il paradigma di progettazione di policy multi-tenant condiviso. In questa politica, il principale `MultiTenantApp::User` che possiede il genitore `MultiTenantApp::Role` `Admin` dispone delle autorizzazioni per visualizzare i dati di tutte le risorse.
```
permit (
principal in MultiTenantApp::Role::"Admin",
action == MultiTenantApp::Action::"viewData",
resource
);
```
Poiché è in uso un unico archivio di politiche, l'archivio delle politiche Verified Permissions deve garantire che un attributo di tenancy associato al principale corrisponda all'attributo di tenancy associato alla risorsa. Ciò può essere ottenuto includendo la seguente policy nel policy store, per garantire che tutte le richieste di autorizzazione che non hanno attributi di tenancy corrispondenti sulla risorsa e sul principale vengano rifiutate.
```
forbid(
principal,
action,
resource
)
unless {
resource.Tenant == principal.Tenant
};
```
Per una richiesta di autorizzazione che utilizza un modello di policy store multi-tenant condiviso, l'ID del policy store è l'identificatore del policy store condiviso. Nella richiesta seguente, le `User` `Alice` è consentito l'accesso perché ha un `Role` of e `Admin` gli `Tenant` attributi associati alla risorsa e al principale sono entrambi. `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":[]
}
]
}
}
```
Con Verified Permissions, è possibile, ma non necessario, integrare un IdP con un policy store. Questa integrazione consente alle politiche di fare esplicito riferimento al principale nell'archivio di identità come principale delle politiche. [Per ulteriori informazioni su come effettuare l'integrazione con Amazon Cognito come IdP per autorizzazioni verificate, consulta la documentazione sulle autorizzazioni verificate [e la documentazione](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) di Amazon Cognito.](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)
Quando si integra un policy store con un IdP, è possibile utilizzare solo una [fonte di identità](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) per policy store. Ad esempio, se scegli di integrare le autorizzazioni verificate con Amazon Cognito, devi rispecchiare la strategia utilizzata per l'isolamento dei tenant degli archivi di policy di Autorizzazioni verificate e dei pool di utenti di Amazon Cognito. Inoltre, gli archivi delle policy e i pool di utenti devono essere gli stessi. Account AWS
![\[Integrazione delle autorizzazioni verificate con Amazon Cognito in un modello di progettazione condiviso\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/cognito-shared.png)
Dal punto di vista operativo e di controllo, il modello di archivio di policy multi-tenant condiviso presenta uno svantaggio in quanto l'attività [registrata AWS CloudTrail richiede un maggior numero di interrogazioni complesse per filtrare le singole attività](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/monitoring-overview.html) sul tenant, poiché ogni chiamata registrata utilizza lo stesso archivio di politiche. CloudTrail In questo scenario, è utile registrare su Amazon CloudWatch metriche personalizzate aggiuntive su una dimensione per-tenant per garantire un livello adeguato di osservabilità e capacità di controllo.
L'approccio «one shared multi-tenant policy store» richiede inoltre un'attenzione particolare alle [quote di autorizzazioni verificate](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/quotas.html) per garantire che non interferiscano con le operazioni della soluzione SaaS. In particolare, ti consigliamo di monitorare *IsAuthorized le richieste al secondo per regione per quota di account per* assicurarti che non vengano superati i limiti. Puoi richiedere un aumento di questa quota.
# Modello di implementazione a più livelli
Creando un modello di distribuzione a più livelli, puoi isolare i tenant «Enterprise Tier» ad alta priorità dal volume potenzialmente più elevato di clienti «Standard Tier». In questo modello, è possibile implementare tutte le modifiche implementate alle policy negli archivi delle policy separatamente per ogni livello, isolando così ogni livello di clienti dalle modifiche apportate al di fuori del proprio livello. Nel modello di implementazione a più livelli, gli archivi delle politiche vengono in genere creati come parte del provisioning iniziale dell'infrastruttura per ogni livello anziché essere implementati quando un tenant è integrato.
Se la soluzione utilizza principalmente un modello di isolamento in pool, potrebbe essere necessario un isolamento o una personalizzazione aggiuntivi. Ad esempio, è possibile creare un «livello Premium» in cui ogni tenant disporrebbe della propria infrastruttura a livello di tenant, il che crea un modello a silos implementando un'istanza in pool con un solo tenant. Ciò potrebbe assumere la forma di infrastrutture «Premium Tier Tenant A» e «Premium Tier Tenant B» completamente separate, compresi gli archivi delle polizze. Questo approccio si traduce in un modello di isolamento isolato per i clienti di più alto livello.
Nel modello di implementazione a più livelli, ogni archivio di politiche deve seguire lo stesso modello di isolamento, sebbene sia distribuito separatamente. Poiché vengono utilizzati più archivi di policy, è necessario applicare un modo coerente di condivisione dell'identificatore dell'archivio delle politiche associato al tenant nell'intera soluzione SaaS. Come per il modello di archivio delle politiche per tenant, è buona norma mappare l'identificatore del tenant all'identità SaaS dell'utente durante la registrazione dell'utente.
Il diagramma seguente mostra tre livelli:, e. `Standard Tier` `Enterprise Tier` `Premium Tier 1` Ogni livello viene distribuito separatamente nella propria infrastruttura e utilizza un archivio di policy condiviso all'interno del livello. I livelli Standard ed Enterprise contengono più tenant. `TenantA`e `TenantB` rientrano nel`Standard Tier`, `TenantC` e `TenantD` sono nel livello Enterprise.
`Premium Tier 1`contiene solo`TenantP`, in modo da poter servire il tenant premium come se la soluzione avesse un modello di isolamento completamente isolato e fornire funzionalità come politiche personalizzate. L'onboarding di un nuovo cliente di livello premium comporterebbe la creazione di un'infrastruttura. `Premium Tier 2`
**Nota**
L'applicazione, l'implementazione e l'onboarding dei tenant nel livello premium sono identici ai livelli standard ed enterprise. L'unica differenza è che il flusso di lavoro di onboarding di livello premium inizia con la fornitura di una nuova infrastruttura di livello.
![\[Autorizzazioni verificate: modello di distribuzione a più livelli\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-tiered-deployment.png)