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à.
# Implementazione di un PDP utilizzando Amazon Verified Permissions
Amazon Verified Permissions è un servizio di gestione e autorizzazione scalabile e granulare delle autorizzazioni che puoi utilizzare per implementare un punto decisionale sulle politiche (PDP). In quanto motore di policy, può aiutare l'applicazione a verificare le azioni degli utenti in tempo reale ed evidenziare le autorizzazioni eccessivamente privilegiate o non valide. Aiuta gli sviluppatori a creare applicazioni più sicure più rapidamente esternalizzando le autorizzazioni e centralizzando la gestione e l'amministrazione delle policy. Separando la logica di autorizzazione dalla logica dell'applicazione, Verified Permissions supporta il disaccoppiamento delle politiche.
[Utilizzando le autorizzazioni verificate per implementare un PDP e implementando i privilegi minimi e la verifica continua all'interno delle applicazioni, gli sviluppatori possono allineare l'accesso alle applicazioni ai principi Zero Trust.](https://aws.amazon.com/security/zero-trust/) Inoltre, i team di sicurezza e controllo possono analizzare e verificare meglio chi ha accesso a quali risorse all'interno di un'applicazione. Verified Permissions utilizza [Cedar](https://www.cedarpolicy.com/en), un linguaggio di policy open source creato appositamente e incentrato sulla sicurezza, per definire controlli di accesso basati su policy basati sul controllo degli accessi basato sui ruoli (RBAC) e sul controllo degli accessi basato sugli attributi (ABAC) per un controllo degli accessi più granulare e sensibile al contesto.
Verified Permissions offre alcune funzioni utili per le applicazioni SaaS, come la possibilità di abilitare l'autorizzazione multi-tenant utilizzando più provider di identità come Amazon Cognito, Google e Facebook. Un'altra funzionalità di Autorizzazioni verificate particolarmente utile per le applicazioni SaaS è il supporto per ruoli personalizzati su base per-tenant. Se state progettando un sistema di gestione delle relazioni con i clienti (CRM), un tenant potrebbe definire la granularità dell'accesso in base alle opportunità di vendita sulla base di un particolare insieme di criteri. Un altro inquilino potrebbe avere un'altra definizione. I sistemi di autorizzazioni alla base di Verified Permissions possono supportare queste variazioni, il che lo rende un ottimo candidato per i casi d'uso SaaS. Verified Permissions supporta anche la possibilità di scrivere policy che si applicano a tutti i tenant, quindi è semplice applicare policy guardrail per impedire accessi non autorizzati come provider SaaS.
![\[Utilizzo di Amazon Verified Permissions per implementare un PDP\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp.png)
**Perché usare le autorizzazioni verificate?**
Utilizza le autorizzazioni verificate con un provider di identità come [Amazon](https://aws.amazon.com/cognito/) Cognito per una soluzione di gestione degli accessi più dinamica e basata su policy per le tue applicazioni. Puoi creare applicazioni che aiutano gli utenti a condividere informazioni e collaborare mantenendo la sicurezza, la riservatezza e la privacy dei loro dati. Verified Permissions aiuta a ridurre i costi operativi fornendovi un sistema di autorizzazione dettagliato per imporre l'accesso in base ai ruoli e agli attributi delle vostre identità e risorse. Puoi definire il tuo modello di policy, creare e archiviare le policy in una posizione centrale e valutare le richieste di accesso in millisecondi.
In Autorizzazioni verificate, puoi esprimere le autorizzazioni utilizzando un linguaggio dichiarativo semplice e leggibile dall'uomo chiamato Cedar. Le politiche scritte in Cedar possono essere condivise tra i team indipendentemente dal linguaggio di programmazione utilizzato dall'applicazione di ciascun team.
**Cosa considerare quando si utilizzano le autorizzazioni verificate**
In Autorizzazioni verificate, puoi creare politiche e automatizzarle come parte del provisioning. È inoltre possibile creare policy in fase di esecuzione come parte della logica dell'applicazione. Come best practice, è consigliabile utilizzare una pipeline di integrazione e distribuzione continua (CI/CD) per amministrare, modificare e tenere traccia delle versioni delle policy quando si creano le policy come parte dell'onboarding e del provisioning dei tenant. In alternativa, un'applicazione può amministrare, modificare e tenere traccia delle versioni delle policy; tuttavia, la logica dell'applicazione non esegue intrinsecamente questa funzionalità. Per supportare queste funzionalità nell'applicazione, è necessario progettare esplicitamente l'applicazione in modo da implementare questa funzionalità.
Se è necessario fornire dati esterni provenienti da altre fonti per prendere una decisione di autorizzazione, tali dati devono essere recuperati e forniti a Verified Permissions come parte della richiesta di autorizzazione. Il contesto, le entità e gli attributi aggiuntivi non vengono recuperati per impostazione predefinita con questo servizio.
# Panoramica su Cedar
Cedar è un linguaggio di controllo degli accessi flessibile, estensibile e scalabile basato su policy che aiuta gli sviluppatori a esprimere le autorizzazioni delle applicazioni come politiche. Gli amministratori e gli sviluppatori possono definire politiche che consentono o vietano agli utenti di agire sulle risorse delle applicazioni. È possibile allegare più politiche a una singola risorsa. Quando un utente dell'applicazione tenta di eseguire un'azione su una risorsa, l'applicazione richiede l'autorizzazione al motore di policy Cedar. Cedar valuta le politiche applicabili e restituisce una `ALLOW` decisione or. `DENY` Cedar supporta le regole di autorizzazione per qualsiasi tipo di principale e risorsa, consente il controllo degli accessi basato sui ruoli (RBAC) e il controllo degli accessi basato sugli attributi (ABAC) e supporta l'analisi tramite strumenti di ragionamento automatizzati.
Cedar consente di separare la logica aziendale dalla logica di autorizzazione. Quando si effettuano richieste dal codice dell'applicazione, si chiama il motore di autorizzazione di Cedar per determinare se la richiesta è autorizzata. Se è autorizzata (la decisione è`ALLOW`), l'applicazione può eseguire l'operazione richiesta. Se non è autorizzata (la decisione è`DENY`), l'applicazione può restituire un messaggio di errore. Le caratteristiche principali di Cedar includono:
+ **Espressività**: Cedar è stato progettato appositamente per supportare i casi d'uso delle autorizzazioni ed è stato sviluppato pensando alla leggibilità umana.
+ **Prestazioni**: Cedar supporta le politiche di indicizzazione per un recupero rapido e fornisce una valutazione in tempo reale rapida e scalabile con latenza limitata.
+ **Analisi**: Cedar supporta strumenti di analisi in grado di ottimizzare le politiche e verificare il modello di sicurezza.
Per ulteriori informazioni, consultate il sito Web di [Cedar.](https://www.cedarpolicy.com/)
# Esempio 1: ABAC di base con autorizzazioni verificate e Cedar
In questo scenario di esempio, Amazon Verified Permissions viene utilizzato per determinare a quali utenti è consentito accedere alle informazioni in un microservizio Payroll fittizio. Questa sezione include frammenti di codice Cedar per dimostrare come utilizzare Cedar per prendere decisioni sul controllo degli accessi. Questi esempi non intendono fornire un'esplorazione completa delle funzionalità fornite da Cedar e Verified Permissions. [Per una panoramica più completa di Cedar, consulta la documentazione di Cedar.](https://docs.cedarpolicy.com/)
Nel diagramma seguente, vorremmo applicare due regole aziendali generali associate al `viewSalary` `GET` metodo: i dipendenti possono visualizzare il *proprio stipendio e i dipendenti possono visualizzare *lo stipendio di chiunque faccia* loro* capo. È possibile applicare queste regole aziendali utilizzando le politiche di autorizzazione verificate.
![\[Esempio di implementazione ABAC di base con Amazon Verified Permissions e Cedar per implementare un PDP\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-1.png)
*I dipendenti possono visualizzare il proprio stipendio.*
In Cedar, il costrutto di base è un'*entità*, che rappresenta un principale, un'azione o una risorsa. Per effettuare una richiesta di autorizzazione e avviare una valutazione con una politica di autorizzazioni verificate, è necessario fornire un *responsabile,* un'*azione*, una *risorsa* e un *elenco* di entità.
+ Il principal (`principal`) è l'utente o il ruolo registrato.
+ L'azione (`action`) è l'operazione che viene valutata dalla richiesta.
+ La risorsa (`resource`) è il componente a cui l'azione accede.
+ L'elenco delle entità (`entityList`) contiene tutte le entità richieste necessarie per valutare la richiesta.
Per soddisfare la regola aziendale, *i dipendenti possono visualizzare il proprio stipendio*, è possibile fornire una politica di autorizzazioni verificate come la seguente.
```
permit (
principal,
action == Action::"viewSalary",
resource
)
when {
principal == resource.owner
};
```
Questa politica valuta `ALLOW` se la risorsa `Action` is `viewSalary` e la risorsa inclusa nella richiesta hanno un proprietario dell'attributo uguale al principale. Ad esempio, se Bob è l'utente connesso che ha richiesto il rapporto sullo stipendio ed è anche il proprietario del rapporto sullo stipendio, la politica restituisce lo stesso. `ALLOW`
La seguente richiesta di autorizzazione viene inviata a Verified Permissions per essere valutata in base alla politica di esempio. In questo esempio, Bob è l'utente connesso che effettua la richiesta. `viewSalary` Pertanto, Bob è il principale del tipo `Employee` di entità. L'azione che Bob sta cercando di eseguire è `viewSalary,` e la risorsa che `viewSalary` verrà visualizzata è `Salary-Bob` del tipo`Salary`. Per valutare se Bob può visualizzare la `Salary-Bob` risorsa, è necessario fornire una struttura di entità che colleghi il tipo `Employee` con un valore pari a `Bob` (principale) all'attributo proprietario della risorsa che ha il tipo`Salary`. Fornisci questa struttura in un formato`entityList`, in cui gli attributi associati a `Salary` includono un proprietario, che specifica e `entityIdentifier` che contiene il tipo `Employee` e il valore`Bob`. Verified Permissions confronta quanto `principal` fornito nella richiesta di autorizzazione con l'`owner`attributo associato alla `Salary` risorsa per prendere una decisione.
```
{
"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": {}
}
]
}
}
```
La richiesta di autorizzazione a Verified Permissions restituisce quanto segue come output, dove l'attributo `decision` è o. `ALLOW` `DENY`
```
{
"determiningPolicies":
[
{
"determiningPolicyId": "PAYROLLAPP_POLICYSTOREID"
}
],
"decision": "ALLOW",
"errors": []
}
```
In questo caso, poiché Bob stava cercando di visualizzare il proprio stipendio, la richiesta di autorizzazione inviata a Verified Permissions corrisponde a. `ALLOW` Tuttavia, il nostro obiettivo era utilizzare le autorizzazioni verificate per applicare due regole aziendali. Anche la regola aziendale che afferma quanto segue dovrebbe essere vera:
*I dipendenti possono visualizzare lo stipendio di chiunque risponda a loro.*
Per soddisfare questa regola aziendale, puoi fornire un'altra politica. La seguente politica valuta `ALLOW` se l'azione è `viewSalary` e se la risorsa nella richiesta ha un attributo `owner.manager` uguale al principale. Ad esempio, se Alice è l'utente connesso che ha richiesto il rapporto sullo stipendio e Alice è la responsabile del proprietario del rapporto, la politica restituisce lo stesso risultato. `ALLOW`
```
permit (
principal,
action == Action::"viewSalary",
resource
)
when {
principal == resource.owner.manager
};
```
La seguente richiesta di autorizzazione viene inviata a Verified Permissions per essere valutata in base alla politica di esempio. In questo esempio, Alice è l'utente connesso che effettua la richiesta. `viewSalary` Quindi Alice è la principale e l'entità è del tipo`Employee`. L'azione che Alice sta cercando di eseguire è`viewSalary`, e la risorsa che `viewSalary` verrà visualizzata è del tipo `Salary` con un valore di`Salary-Bob`. Per valutare se Alice può visualizzare la `Salary-Bob` risorsa, è necessario fornire una struttura di entità che colleghi il tipo `Employee` con un valore pari `Alice` all'`manager`attributo, che deve quindi essere associato all'`owner`attributo del tipo `Salary` con un valore di`Salary-Bob`. Fornite questa struttura in un formato`entityList`, in cui gli attributi associati a `Salary` includono un proprietario, che specifica e `entityIdentifier` che contiene il tipo `Employee` e il valore`Bob`. Verified Permissions controlla innanzitutto l'`owner`attributo, che restituisce il tipo `Employee` e il valore. `Bob` Quindi, Verified Permissions valuta l'`manager`attributo a cui è associato `Employee` e lo confronta con il principale fornito per prendere una decisione di autorizzazione. In questo caso, la decisione è `ALLOW` dovuta al fatto che `resource.owner.manager` gli attributi `principal ` and sono equivalenti.
```
{
"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": []
}
]
}
}
```
Finora, in questo esempio, abbiamo fornito le due regole aziendali associate al `viewSalary` metodo, vale a dire che *i dipendenti possono visualizzare il proprio stipendio* e *i dipendenti possono visualizzare lo stipendio di chiunque risponda a loro*, utilizzando le autorizzazioni verificate come politiche per soddisfare le condizioni di ogni regola aziendale in modo indipendente. Puoi anche utilizzare un'unica politica di autorizzazioni verificate per soddisfare le condizioni di entrambe le regole aziendali:
*I dipendenti possono visualizzare il proprio stipendio e quello di chiunque risponda a loro.*
Quando si utilizza la richiesta di autorizzazione precedente, la seguente politica valuta `ALLOW` se l'azione è `viewSalary` e se la risorsa inclusa nella richiesta ha un attributo `owner.manager` uguale a o un attributo `owner` uguale a. `principal` `principal`
```
permit (
principal,
action == PayrollApp::Action::"viewSalary",
resource
)
when {
principal == resource.owner.manager ||
principal == resource.owner
};
```
Ad esempio, se Alice è l'utente connesso che richiede il rapporto sullo stipendio e se Alice è la responsabile del proprietario o la proprietaria del rapporto, la politica restituisce tale rapporto. `ALLOW`
[Per ulteriori informazioni sull'utilizzo degli operatori logici con le politiche Cedar, consultate la documentazione di Cedar.](https://docs.cedarpolicy.com/policies/syntax-operators.html)
# Esempio 2: RBAC di base con autorizzazioni verificate e Cedar
Questo esempio utilizza Verified Permissions e Cedar per dimostrare l'RBAC di base. Come accennato in precedenza, il costrutto base di Cedar è un'entità. Gli sviluppatori definiscono le proprie entità e possono facoltativamente creare relazioni tra le entità. L'esempio seguente include tre tipi di entità: `Users``Roles`, e`Problems`. `Students`e `Teachers` possono essere considerate entità del tipo `Role,` e ciascuna `User` può essere associata a zero o a uno qualsiasi dei`Roles`.
![\[Esempio di implementazione RBAC di base con Amazon Verified Permissions e Cedar per implementare un PDP\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-2.png)
In Cedar, queste relazioni vengono espresse collegando il a come elemento principale. `Role` `Student` `User` `Bob` Questa associazione raggruppa logicamente tutti gli utenti studenti in un unico gruppo. [Per ulteriori informazioni sul raggruppamento in Cedar, consulta la documentazione di Cedar.](https://docs.cedarpolicy.com/overview/terminology.html#term-group)
La seguente politica valuta la decisione relativa all'azione `ALLOW` `submitProblem,` per tutti i principali collegati al gruppo logico del tipo. `Students` `Role`
```
permit (
principal in ElearningApp::Role::"Students",
action == ElearningApp::Action::"submitProblem",
resource
);
```
La seguente politica si riferisce alla decisione `ALLOW` relativa all'azione `submitProblem` o `answerProblem` a tutti i principali collegati al gruppo `Teachers` logico del tipo. `Role`
```
permit (
principal in ElearningApp::Role::"Teachers",
action in [
ElearningApp::Action::"submitProblem",
ElearningApp::Action::"answerProblem"
],
resource
);
```
Per valutare le richieste con queste politiche, il motore di valutazione deve sapere se il principale a cui si fa riferimento nella richiesta di autorizzazione fa parte del gruppo appropriato. Pertanto, l'applicazione deve trasmettere le informazioni pertinenti sull'appartenenza al gruppo al motore di valutazione come parte della richiesta di autorizzazione. Ciò avviene tramite la `entities` proprietà, che consente di fornire al motore di valutazione Cedar i dati sugli attributi e sull'appartenenza al gruppo per il principale e la risorsa coinvolte nella chiamata di autorizzazione. Nel codice seguente, l'appartenenza al gruppo viene indicata definendo `User::"Bob"` come la chiamata `Role::"Students"` di un genitore.
```
{
"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": []
}
]
}
}
```
In questo esempio, Bob è l'utente connesso che effettua la `answerProblem` richiesta. Pertanto, Bob è il principale e l'entità è del tipo`User`. L'azione che Bob sta cercando di eseguire è`answerProblem`. Per valutare se Bob è in grado di eseguire l'`answerProblem`azione, è necessario fornire una struttura di entità che colleghi l'entità `User` con un valore di `Bob` e le assegni l'appartenenza al gruppo elencando un'entità principale come`Role::"Students"`. Poiché le entità del gruppo di utenti `Role::"Students"` sono autorizzate solo a eseguire l'azione`submitProblem`, questa richiesta di autorizzazione restituisce un risultato positivo. `DENY`
D'altra parte, se il tipo `User` che ha un valore pari a `Alice` e fa parte del gruppo `Role::"Teachers"` tenta di eseguire l'`answerProblem`azione, la richiesta di autorizzazione restituisce lo stesso risultato`ALLOW`, poiché la politica impone che i responsabili del gruppo `Role::"Teachers"` siano autorizzati a eseguire l'azione `answerProblem` su tutte le risorse. Il codice seguente mostra questo tipo di richiesta di autorizzazione che restituisce a. `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": []
}
]
}
}
```
# Esempio 3: controllo degli accessi multi-tenant con RBAC
Per approfondire il precedente esempio RBAC, è possibile espandere i requisiti per includere la multi-tenancy SaaS, che è un requisito comune per i provider SaaS. Nelle soluzioni multi-tenant, l'accesso alle risorse viene sempre fornito per conto di un determinato tenant. Cioè, gli utenti del Tenant A non possono visualizzare i dati del Tenant B, anche se tali dati sono collocati logicamente o fisicamente in un sistema. L'esempio seguente illustra come implementare l'isolamento dei tenant utilizzando più [archivi di policy per le autorizzazioni verificate](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-stores.html) e come utilizzare i ruoli utente per definire le autorizzazioni all'interno del tenant.
L'utilizzo del modello di progettazione Per Tenant Policy Store è una best practice per mantenere l'isolamento dei tenant durante l'implementazione del controllo degli accessi con autorizzazioni verificate. In questo scenario, le richieste degli utenti Tenant A e Tenant B vengono verificate in archivi di policy separati e, rispettivamente. `DATAMICROSERVICE_POLICYSTORE_A` `DATAMICROSERVICE_POLICYSTORE_B` Per ulteriori informazioni sulle considerazioni sulla progettazione delle autorizzazioni verificate per applicazioni SaaS multi-tenant, consulta la sezione Considerazioni sulla progettazione multi-tenant [delle autorizzazioni verificate](avp-design-considerations.md).
![\[Esempio di controllo degli accessi multi-tenant con RBAC, Amazon Verified Permissions e Cedar\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-3.png)
La seguente policy si trova nel Policy Store. `DATAMICROSERVICE_POLICYSTORE_A` Verifica che il principale faccia parte del gruppo `allAccessRole` di tipi. `Role` In questo caso, il committente sarà autorizzato a eseguire le `updateData` azioni `viewData` e su tutte le risorse associate al Tenant A.
```
permit (
principal in MultitenantApp::Role::"allAccessRole",
action in [
MultitenantApp::Action::"viewData",
MultitenantApp::Action::"updateData"
],
resource
);
```
Le seguenti politiche si trovano nell'archivio delle `DATAMICROSERVICE_POLICYSTORE_B` politiche. La prima policy verifica che il principale faccia parte del `updateDataRole` gruppo di tipi. `Role` Supponendo che sia così, autorizza i mandanti a eseguire l'`updateData`azione sulle risorse associate al Tenant B.
```
permit (
principal in MultitenantApp::Role::"updateDataRole",
action == MultitenantApp::Action::"updateData",
resource
);
```
Questa seconda politica impone che i committenti che fanno parte del `viewDataRole` gruppo di tipo `Role` siano autorizzati a eseguire l'`viewData`azione sulle risorse associate al Tenant B.
```
permit (
principal in MultitenantApp::Role::"viewDataRole",
action == MultitenantApp::Action::"viewData",
resource
);
```
La richiesta di autorizzazione effettuata dal Tenant A deve essere inviata al `DATAMICROSERVICE_POLICYSTORE_A` policy store e verificata in base alle politiche che appartengono a tale archivio. In questo caso, viene verificata in base alla prima politica discussa in precedenza come parte di questo esempio. In questa richiesta di autorizzazione, il principale di tipo `User` con valore di `Alice` richiede di eseguire l'`viewData`azione. Il principale appartiene al gruppo `allAccessRole` di tipi`Role`. Alice sta cercando di eseguire l'`viewData`azione sulla `SampleData` risorsa. Poiché Alice ha il `allAccessRole` ruolo, questa valutazione porta a una `ALLOW` decisione.
```
{
"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": []
}
]
}
}
```
Se, invece, visualizzi una richiesta fatta dal Tenant B da`User Bob`, vedrai qualcosa come la seguente richiesta di autorizzazione. La richiesta viene inviata al `DATAMICROSERVICE_POLICYSTORE_B` policy store perché proviene dal Tenant B. In questa richiesta, il principale `Bob` desidera eseguire l'azione `updateData` sulla risorsa. `SampleData` Tuttavia, non `Bob` fa parte di un gruppo che ha accesso all'azione `updateData` su quella risorsa. Pertanto, la richiesta dà luogo a una `DENY` decisione.
```
{
"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": []
}
]
}
}
```
In questo terzo esempio, `User Alice ` tenta di eseguire l'`viewData`azione sulla risorsa`SampleData`. Questa richiesta viene indirizzata al `DATAMICROSERVICE_POLICYSTORE_A` policy store perché il responsabile `Alice` appartiene al Tenant A. `Alice` fa parte del gruppo `allAccessRole` del tipo`Role`, che le consente di eseguire l'`viewData`azione sulle risorse. Pertanto, la richiesta dà luogo a una `ALLOW` decisione.
```
{
"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": []
}
]
}
}
```
# Esempio 4: controllo degli accessi multi-tenant con RBAC e ABAC
Per migliorare l'esempio RBAC della sezione precedente, è possibile aggiungere attributi agli utenti per creare un approccio ibrido RBAC-ABAC per il controllo degli accessi multi-tenant. Questo esempio include gli stessi ruoli dell'esempio precedente, ma aggiunge l'attributo user e il parametro context. `account_lockout_flag` `uses_mfa` L'esempio adotta inoltre un approccio diverso all'implementazione del controllo degli accessi multi-tenant utilizzando sia RBAC che ABAC e utilizza un archivio di politiche condiviso anziché un archivio di politiche diverso per ogni tenant.
![\[Esempio di controllo degli accessi multi-tenant con RBAC, ABAC, Amazon Verified Permissions e Cedar\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-4.png)
Questo esempio rappresenta una soluzione SaaS multi-tenant in cui è necessario fornire decisioni di autorizzazione per il Tenant A e il Tenant B, in modo simile all'esempio precedente.
Per implementare la funzionalità di blocco degli utenti, l'esempio aggiunge l'attributo `account_lockout_flag` all'`User`entità principale nella richiesta di autorizzazione. Questo flag blocca l'accesso dell'utente al sistema e assegna `DENY` tutti i privilegi all'utente bloccato. L'`account_lockout_flag`attributo è associato all'`User`entità ed è valido `User` fino a quando il flag non viene revocato attivamente in più sessioni. L'esempio utilizza la `when` condizione per valutare`account_lockout_flag`.
L'esempio aggiunge anche dettagli sulla richiesta e sulla sessione. Le informazioni di contesto specificano che la sessione è stata autenticata utilizzando l'autenticazione a più fattori. Per implementare questa convalida, l'esempio utilizza la `when` condizione per valutare il `uses_mfa` flag come parte del campo di contesto. Per ulteriori informazioni sulle migliori pratiche per l'aggiunta di contesto, consulta la documentazione [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
};
```
Questa politica impedisce l'accesso alle risorse a meno che la risorsa non sia nello stesso gruppo dell'attributo del `Tenant` principale richiedente. Questo approccio per mantenere l'isolamento dei tenant è denominato approccio *One Shared Multi-Tenant* Policy Store. Per ulteriori informazioni sulle considerazioni sulla progettazione delle autorizzazioni verificate per applicazioni SaaS multi-tenant, consulta la sezione Considerazioni sulla progettazione multi-tenant [delle autorizzazioni verificate](avp-design-considerations.md).
La politica garantisce inoltre che il preside sia membro e limita le azioni a e. `allAccessRole` `viewData` `updateData` Inoltre, questa politica verifica che lo `account_lockout_flag` sia `false` e che il valore di contesto `uses_mfa` valuti a. `true`
Analogamente, la seguente politica garantisce che sia il principale che la risorsa siano associati allo stesso tenant, impedendo l'accesso tra tenant. Questa politica garantisce inoltre che il preside sia membro di `viewDataRole` e limita le azioni a. `viewData` Inoltre, verifica che il valore `account_lockout_flag` è `false` e che il valore di contesto di sia uguale a`uses_mfa`. `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
};
```
La terza politica è simile alla precedente. La politica richiede che la risorsa sia un membro del gruppo che corrisponde all'entità rappresentata da`principal.Tenant`. Ciò garantisce che sia il principale che la risorsa siano associati al Tenant B, il che impedisce l'accesso tra tenant. Questa politica garantisce che il committente sia membro di `updateDataRole` e limita le azioni a. `updateData` Inoltre, questo criterio verifica che il valore di `account_lockout_flag` is `false` e il valore di contesto `uses_mfa` valuti a. `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
};
```
La seguente richiesta di autorizzazione viene valutata in base alle tre politiche illustrate in precedenza in questa sezione. In questa richiesta di autorizzazione, il principale di tipo `User` e con valore di `Alice` effettua una `updateData` richiesta con il ruolo`allAccessRole`. `Alice`ha l'attributo `Tenant` il cui valore è`Tenant::"TenantA"`. L'azione `Alice` che si sta tentando di eseguire è `updateData,` e la risorsa a cui verrà applicata è `SampleData` del tipo`Data`. `SampleData`ha `TenantA` come entità principale.
In base alla prima politica nell'archivio delle `` politiche, `Alice` può eseguire l'`updateData`azione sulla risorsa, presupponendo che siano soddisfatte le condizioni nella `when` clausola della politica. La prima condizione richiede l'`principal.Tenant`attributo su cui eseguire la valutazione. `TenantA` La seconda condizione richiede che l'`account_lockout_flag`attributo principale sia`false`. L'ultima condizione richiede che `uses_mfa` il contesto sia`true`. Poiché tutte e tre le condizioni sono soddisfatte, la richiesta restituisce una `ALLOW` decisione.
```
{
"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"
}
]
}
]
}
}
```
# Esempio 5: filtraggio dell'interfaccia utente con autorizzazioni verificate e Cedar
Puoi anche utilizzare le autorizzazioni verificate per implementare il filtraggio RBAC degli elementi dell'interfaccia utente in base ad azioni autorizzate. Ciò è estremamente utile per le applicazioni con elementi dell'interfaccia utente sensibili al contesto che potrebbero essere associati a utenti o tenant specifici nel caso di un'applicazione SaaS multi-tenant.
Nell'esempio seguente, `Users` non `Role` `viewer` sono autorizzati a eseguire aggiornamenti. Per questi utenti, l'interfaccia utente non dovrebbe visualizzare alcun pulsante di aggiornamento.
![\[Esempio di filtraggio dell'interfaccia utente con Amazon Verified Permissions e Cedar\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-5.png)
In questo esempio, un'applicazione Web a pagina singola ha quattro pulsanti. I pulsanti visibili dipendono dall'`Role`utente che ha attualmente effettuato l'accesso all'applicazione. Quando l'applicazione Web a pagina singola esegue il rendering dell'interfaccia utente, richiede le autorizzazioni verificate per determinare quali azioni l'utente è autorizzato a eseguire, quindi genera i pulsanti in base alla decisione di autorizzazione.
La seguente politica specifica che il tipo `Role` con un valore di `viewer` può visualizzare sia gli utenti che i dati. Una decisione di `ALLOW` autorizzazione per questa politica richiede un'`viewUsers`azione `viewData` o e richiede inoltre che una risorsa sia associata al tipo `Data` o`Users`. Una `ALLOW` decisione consente all'interfaccia utente di visualizzare due pulsanti: `viewDataButton` e`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"]
};
```
La seguente politica specifica che il tipo `Role` con un valore di `viewerDataOnly` può solo visualizzare i dati. Una decisione di `ALLOW` autorizzazione per questa politica richiede un'`viewData`azione e richiede anche l'associazione di una risorsa al tipo`Data`. Una `ALLOW` decisione consente all'interfaccia utente di eseguire il rendering del pulsante`viewDataButton`.
```
permit (
principal in GuiApp::Role::"viewerDataOnly",
action in [GuiApp::Action::"viewData"],
resource in [GuiApp::Type::"Data"]
);
```
La seguente politica specifica che il tipo `Role` con un valore di `admin` può modificare e visualizzare dati e utenti. Una decisione di `ALLOW` autorizzazione per questa politica richiede un'azione di `updateData` `updateUsers``viewUsers`, `viewData,` o e richiede inoltre che una risorsa sia associata al tipo `Data` o`Users`. Una `ALLOW` decisione consente all'interfaccia utente di visualizzare tutti e quattro i pulsanti:`updateDataButton`, `updateUsersButton``viewDataButton`, e`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"]
};
```