Procedure consigliate per la progettazione di un modello di autorizzazione

Mentre ti prepari a utilizzare il servizio Amazon Verified Permissions all'interno di un'applicazione software, può essere difficile passare immediatamente alla stesura di dichiarazioni politiche come primo passo. Sarebbe come iniziare lo sviluppo di altre parti di un'applicazione scrivendo SQL dichiarazioni o API specifiche prima di decidere completamente cosa fare l'applicazione. Dovreste invece iniziare con un'esperienza utente, acquisendo una chiara comprensione di ciò che gli utenti finali dovrebbero vedere quando gestiscono le autorizzazioni nell'interfaccia utente dell'applicazione. Quindi, lavorate a ritroso da quell'esperienza per arrivare a un approccio di implementazione.

Mentre svolgi questo lavoro, ti ritroverai a porre domande come:

• Quali sono le mie risorse? Hanno relazioni tra loro? Ad esempio, i file si trovano all'interno di una cartella?

• Quali azioni possono eseguire i responsabili su ciascuna risorsa?

• In che modo i dirigenti acquisiscono tali autorizzazioni?

• Vuoi che i tuoi utenti finali possano scegliere tra autorizzazioni predefinite come «Amministratore», «Operatore» o «ReadOnly», o devono creare dichiarazioni politiche ad hoc? O entrambe le cose?

• Le autorizzazioni devono essere ereditate da più risorse, ad esempio i file che ereditano le autorizzazioni da una cartella principale?

• Quali tipi di query sono necessarie per rendere l'esperienza utente? Ad esempio, è necessario elencare tutte le risorse a cui un principale può accedere per visualizzare la home page di quell'utente?

• Gli utenti possono impedire accidentalmente l'accesso alle proprie risorse? È necessario evitarlo?

Il risultato finale di questo esercizio è denominato modello di autorizzazione; definisce i principi, le risorse, le azioni e il modo in cui interagiscono tra loro. La produzione di questo modello non richiede una conoscenza esclusiva di Cedar o del servizio Verified Permissions. Si tratta invece innanzitutto di un esercizio di progettazione dell'esperienza utente, molto simile a qualsiasi altro, e può manifestarsi in artefatti come prototipi di interfaccia, diagrammi logici e una descrizione generale di come le autorizzazioni influenzano ciò che gli utenti vedono nel prodotto. Cedar è progettato per essere sufficientemente flessibile da soddisfare i clienti secondo un modello, anziché forzare il modello a piegarsi in modo innaturale per conformarsi all'implementazione di Cedar. Di conseguenza, acquisire una comprensione approfondita dell'esperienza utente desiderata è il modo migliore per arrivare a un modello ottimale.

Questa sezione fornisce indicazioni generali su come affrontare l'esercizio di progettazione, gli aspetti a cui prestare attenzione e una raccolta di best practice per utilizzare con successo le autorizzazioni verificate.

Oltre alle linee guida qui presentate, ricordatevi di prendere in considerazione le migliori pratiche contenute nella guida di riferimento linguistica Cedar Policy Language.

Non esiste un modello canonico «corretto»

Quando si progetta un modello di autorizzazione, non esiste un'unica risposta corretta. Applicazioni diverse possono utilizzare efficacemente modelli di autorizzazione diversi per concetti simili, e questo va bene. Si consideri ad esempio la rappresentazione del file system di un computer. Quando create un file in un sistema operativo simile a Unix, questo non eredita automaticamente le autorizzazioni dalla cartella principale. Al contrario, in molti altri sistemi operativi e nella maggior parte dei servizi di condivisione di file online, i file ereditano le autorizzazioni dalla cartella principale. Entrambe le scelte sono valide a seconda delle circostanze per cui l'applicazione è ottimizzata.

La correttezza di una soluzione di autorizzazione non è assoluta, ma deve essere vista in termini di come offre l'esperienza che i clienti desiderano e se protegge le loro risorse nel modo in cui si aspettano. Se il tuo modello di autorizzazione soddisfa questo obiettivo, allora ha successo.

Ecco perché iniziare la progettazione con l'esperienza utente desiderata è il prerequisito più utile per la creazione di un modello di autorizzazione efficace.

Concentratevi sulle vostre risorse oltre API che sulle operazioni

Nella maggior parte delle applicazioni rivolte ai consumatori, le autorizzazioni sono modellate in base alle risorse supportate dall'applicazione. Ad esempio, un'applicazione per la condivisione di file potrebbe rappresentare le autorizzazioni come azioni che possono essere eseguite su un file o una cartella. Si tratta di un modello valido e semplice che astrae l'implementazione sottostante e le operazioni di backend. API

Al contrario, altri tipi di applicazioni, in particolare i servizi web, spesso progettano le autorizzazioni in base alle operazioni stesseAPI. Ad esempio, se un servizio Web fornisce un API nomecreateThing(), il modello di autorizzazione potrebbe definire un'autorizzazione corrispondente o un nome action in Cedar. createThing Funziona in molte situazioni e semplifica la comprensione delle autorizzazioni. Per richiamare l'createThingoperazione, è necessaria l'autorizzazione all'createThingazione. Sembra semplice, vero?

Scoprirai che la procedura introduttiva nella console Autorizzazioni verificate include la possibilità di creare risorse e azioni direttamente da unAPI. Questa è una base utile: una mappatura diretta tra il tuo archivio delle politiche e API quello per cui autorizza.

Tuttavia, questo approccio API incentrato può essere tutt'altro che ottimale, perché APIs funge semplicemente da indicatore di ciò che i clienti stanno realmente cercando di proteggere: i dati e le risorse sottostanti. Se più utenti APIs controllano l'accesso alle stesse risorse, può essere difficile per gli amministratori ragionare sui percorsi verso tali risorse e gestire l'accesso di conseguenza.

Ad esempio, si consideri una rubrica di utenti che contiene i membri di un'organizzazione. Gli utenti possono essere organizzati in gruppi e uno degli obiettivi di sicurezza è vietare l'individuazione dell'appartenenza ai gruppi da parte di soggetti non autorizzati. Il servizio che gestisce questo elenco utenti prevede due operazioni: API

• listMembersOfGroup

• listGroupMembershipsForUser

I clienti possono utilizzare una di queste operazioni per scoprire l'appartenenza al gruppo. Pertanto, l'amministratore delle autorizzazioni deve ricordarsi di coordinare l'accesso a entrambe le operazioni. Ciò si complica ulteriormente se in seguito si sceglie di aggiungere una nuova API operazione per risolvere casi d'uso aggiuntivi, come i seguenti.

• isUserInGroups(una novità API per verificare rapidamente se un utente appartiene a uno o più gruppi)

Dal punto di vista della sicurezza, questo API apre un terzo percorso per scoprire l'appartenenza ai gruppi, interrompendo le autorizzazioni accuratamente predisposte dell'amministratore.

Ti consigliamo di ignorare la API semantica e concentrarti invece sui dati e sulle risorse sottostanti e sulle relative operazioni di associazione. L'applicazione di questo approccio all'esempio dell'appartenenza a un gruppo porterebbe a un'autorizzazione astratta, ad esempioviewGroupMembership, che ciascuna delle tre API operazioni deve consultare.

APINome	Autorizzazioni
listMembersOfGroup	richiede viewGroupMembership l'autorizzazione per il gruppo
listGroupMembershipsForUser	richiede viewGroupMembership l'autorizzazione dell'utente
isUserInGroups	richiede viewGroupMembership l'autorizzazione dell'utente

Definendo quest'unica autorizzazione, l'amministratore controlla con successo l'accesso alla scoperta delle appartenenze ai gruppi, ora e per sempre. Come compromesso, ogni API operazione deve ora documentare le eventuali diverse autorizzazioni richieste e l'amministratore deve consultare questa documentazione durante la creazione delle autorizzazioni. Questo può essere un compromesso valido se necessario per soddisfare i requisiti di sicurezza.

L'autorizzazione composta è normale

L'autorizzazione composta si verifica quando un'attività di un singolo utente, ad esempio fare clic su un pulsante nell'interfaccia dell'applicazione, richiede più query di autorizzazione individuali per determinare se tale attività è consentita. Ad esempio, lo spostamento di un file in una nuova directory in un file system potrebbe richiedere tre diverse autorizzazioni: la possibilità di eliminare un file dalla directory di origine, la possibilità di aggiungere un file alla directory di destinazione ed eventualmente la possibilità di toccare il file stesso (a seconda dell'applicazione).

Se non conosci la progettazione di un modello di autorizzazione, potresti pensare che ogni decisione di autorizzazione debba essere risolvibile in un'unica richiesta di autorizzazione. Ma ciò può portare a modelli eccessivamente complessi e dichiarazioni politiche complicate. In pratica, l'utilizzo di autorizzazioni composte può essere utile per aiutarvi a produrre un modello di autorizzazione più semplice. Una misura di un modello di autorizzazione ben progettato è che, quando le singole azioni sono sufficientemente scomposte, le operazioni composte, come lo spostamento di un file, possono essere rappresentate da un'aggregazione intuitiva di primitive.

Un'altra situazione in cui si verifica l'autorizzazione composta è quando più parti sono coinvolte nel processo di concessione di un'autorizzazione. Prendi in considerazione un elenco organizzativo in cui gli utenti possono essere membri di gruppi. Un approccio semplice consiste nel concedere al proprietario del gruppo il permesso di aggiungere chiunque. Tuttavia, cosa succede se desideri che i tuoi utenti acconsentano innanzitutto all'aggiunta? Ciò introduce un accordo di stretta di mano in cui sia l'utente che il gruppo devono acconsentire all'appartenenza. A tale scopo, è possibile introdurre un'altra autorizzazione associata all'utente e specificare se l'utente può essere aggiunto a qualsiasi gruppo o a un gruppo particolare. Quando un chiamante tenta successivamente di aggiungere membri a un gruppo, l'applicazione deve applicare entrambe le autorizzazioni: che il chiamante sia autorizzato ad aggiungere membri al gruppo specificato e che il singolo utente aggiunto disponga delle autorizzazioni necessarie. Quando esistono gli handshake N -way, è comune osservare richieste di autorizzazione N composte per far rispettare ogni parte dell'accordo.

Se vi trovate di fronte a un problema di progettazione in cui sono coinvolte più risorse e non è chiaro come modellare le autorizzazioni, può essere un segno che avete uno scenario di autorizzazione composto. In questo caso, è possibile trovare una soluzione scomponendo l'operazione in più controlli di autorizzazione individuali.

Considerazioni sulla multi-tenancy

Potresti voler sviluppare applicazioni che possano essere utilizzate da più clienti, aziende che utilizzano la tua applicazione o tenant, e integrarle con Amazon Verified Permissions. Prima di sviluppare il modello di autorizzazione, sviluppa una strategia multi-tenant. Puoi gestire le policy dei tuoi clienti in un unico archivio di policy condiviso o assegnare a ciascuno un archivio di policy per tenant.

1. Un archivio di politiche condiviso

   Tutti gli inquilini condividono un unico archivio di politiche. L'applicazione invia tutte le richieste di autorizzazione all'archivio delle politiche condiviso.

2. Archivio delle politiche per tenant

   Ogni inquilino dispone di un archivio di polizze dedicato. L'applicazione interrogherà diversi archivi di policy per una decisione di autorizzazione, a seconda del tenant che effettua la richiesta.

Nessuna delle due strategie crea un volume relativamente più elevato di richieste di autorizzazione che potrebbero avere un impatto sulla fattura. AWS Quindi, come dovresti progettare il tuo approccio? Le seguenti sono condizioni comuni che potrebbero contribuire alla strategia di autorizzazione multi-tenant con Autorizzazioni Verificate.

Isolamento delle politiche degli inquilini

L'isolamento delle politiche di ciascun inquilino dagli altri è importante per proteggere i dati degli inquilini. Quando ogni inquilino ha il proprio archivio delle polizze, ognuno ha il proprio set isolato di politiche.

Flusso di autorizzazione

È possibile identificare un tenant che effettua una richiesta di autorizzazione inserendo un Policy Store ID nella richiesta, utilizzando archivi di policy specifici per tenant. Con un policy store condiviso, tutte le richieste utilizzano lo stesso ID del policy store.

Gestione dei modelli e degli schemi

I modelli di policy e uno schema di policy store aggiungono un livello di sovraccarico di progettazione e manutenzione in ogni archivio delle politiche.

Gestione delle politiche globali

Potresti voler applicare alcune politiche globali a ogni inquilino. Il livello di spese generali per la gestione delle politiche globali varia tra i modelli di archivio delle politiche condivisi e quelli per tenant.

Disimbarco da parte degli inquilini

Alcuni inquilini apporteranno al tuo schema e alle tue politiche elementi specifici per il loro caso. Quando un inquilino non è più attivo nell'organizzazione e desiderate rimuovere i suoi dati, il livello di impegno richiesto varia a seconda del suo livello di isolamento dagli altri inquilini.

Quote di risorse di servizio

Verified Permissions prevede quote di risorse e percentuali di richieste che potrebbero influire sulla decisione relativa alla locazione multipla. Per ulteriori informazioni sulle quote, consulta Quote per le risorse.

Confronto tra archivi di policy condivisi e archivi di policy per tenant

Ogni considerazione richiede il proprio livello di impegno in termini di tempo e risorse in modelli di archivio delle politiche condivisi e pertinenti.

Considerazione	Livello di impegno in un archivio di policy condiviso	Livello di impegno negli archivi di policy relativi ai singoli inquilini
Isolamento delle politiche degli inquilini	Medio.È necessario includere gli identificatori degli inquilini nelle politiche e nelle richieste di autorizzazione.	Basso. L'isolamento è un comportamento predefinito. Le politiche specifiche degli inquilini sono inaccessibili agli altri inquilini.
Flusso di autorizzazione	Basso. Tutte le interrogazioni hanno come target un archivio di policy.	Medio. Deve mantenere le mappature tra ogni tenant e il relativo ID dell'archivio delle politiche.
Modelli e gestione degli schemi	Basso. Deve far funzionare uno schema per tutti gli inquilini.	Alto. Gli schemi e i modelli potrebbero essere meno complessi singolarmente, ma le modifiche richiedono maggiore coordinamento e complessità.
Gestione delle politiche globali	Bassa. Tutte le politiche sono globali e possono essere aggiornate centralmente.	Alto. È necessario aggiungere politiche globali a ciascun archivio di polizze in fase di onboarding. Replica gli aggiornamenti delle policy globali tra molti archivi di policy.
Disimbarco da parte di un inquilino	Medio. È necessario identificare ed eliminare solo le politiche specifiche del tenant.	Basso. Eliminare l'archivio delle politiche.
Quote di risorse di servizio	Alto. I tenant condividono le quote di risorse che influiscono sugli archivi delle politiche, come la dimensione dello schema, la dimensione dei criteri per risorsa e le fonti di identità per l'archivio delle politiche.	Basso. Ogni inquilino dispone di quote di risorse dedicate.

Come scegliere

Ogni applicazione multi-tenant è diversa. Confrontate attentamente i due approcci e le relative considerazioni prima di prendere una decisione architettonica.

Se l'applicazione non richiede policy specifiche per i tenant e utilizza un'unica fonte di identità, un archivio di policy condiviso per tutti i tenant è probabilmente la soluzione più efficace. Ciò si traduce in un flusso di autorizzazione più semplice e nella gestione delle policy globali. L'eliminazione di un tenant utilizzando un archivio di policy condiviso richiede meno sforzi perché l'applicazione non deve eliminare le politiche specifiche del tenant.

Tuttavia, se l'applicazione richiede molte policy specifiche per il tenant o utilizza più fonti di identità, è probabile che gli archivi di policy per tenant siano i più efficaci. È possibile controllare l'accesso alle politiche dei tenant con politiche che concedono autorizzazioni per tenant a IAM ciascun archivio di politiche. L'esclusione di un tenant comporta l'eliminazione del relativo archivio delle politiche; in un shared-policy-store ambiente, è necessario trovare ed eliminare le politiche specifiche del tenant.

Quando possibile, compila l'ambito della policy

L'ambito della politica è la parte di una dichiarazione politica di Cedar dopo le forbid parole chiave permit o e tra le parentesi di apertura.

Ti consigliamo di compilare i valori ogni volta che è possibile. principal resource Ciò consente alle autorizzazioni verificate di indicizzare le politiche per un recupero più efficiente e quindi di migliorare le prestazioni. Se devi concedere le stesse autorizzazioni a molti principali o risorse diversi, ti consigliamo di utilizzare un modello di policy e di collegarlo a ciascuna coppia di principali/risorse.

Evita di creare un'unica politica di grandi dimensioni che contenga elenchi di principi e risorse in una clausola. when In questo modo potresti incorrere in limiti di scalabilità o sfide operative. Ad esempio, per aggiungere o rimuovere un singolo utente da un elenco di grandi dimensioni all'interno di una policy, è necessario leggere l'intera policy, modificare l'elenco, scrivere la nuova policy per intero e gestire gli errori di concorrenza se un amministratore sovrascrive le modifiche di un altro. Al contrario, utilizzando molte autorizzazioni dettagliate, aggiungere o rimuovere un utente è semplice come aggiungere o rimuovere la singola politica che lo riguarda.

Ogni risorsa vive in un contenitore

Quando si progetta un modello di autorizzazione, ogni azione deve essere associata a una particolare risorsa. Con un'azione come questaviewFile, la risorsa a cui è possibile applicarla è intuitiva: un singolo file o forse una raccolta di file all'interno di una cartella. Tuttavia, un'operazione come questa createFile è meno intuitiva. Quando si modella la capacità di creare un file, a quale risorsa si applica? Non può essere il file stesso, perché il file non esiste ancora.

Questo è un esempio del problema generalizzato della creazione di risorse. La creazione di risorse è un problema di avvio. Deve esserci un modo per consentire a qualcosa di avere il permesso di creare risorse anche quando non esistono ancora risorse. La soluzione è riconoscere che ogni risorsa deve esistere all'interno di un contenitore ed è il contenitore stesso a fungere da punto di ancoraggio per le autorizzazioni. Ad esempio, se nel sistema esiste già una cartella, la possibilità di creare un file può essere modellata come un'autorizzazione per quella cartella, poiché quella è la posizione in cui sono necessarie le autorizzazioni per creare un'istanza della nuova risorsa.

permit (
    principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d",
    action == Action::"createFile",
    resource == Folder::"c863f89b-461f-4fc2-b638-e5fa5f79a48b"
);

Ma cosa succede se non esiste alcuna cartella? Forse si tratta di un account cliente nuovo di zecca in un'applicazione in cui non esistono ancora risorse. In questa situazione, esiste ancora un contesto che può essere compreso in modo intuitivo chiedendo: dove può il cliente creare nuovi file? Non vuoi che siano in grado di creare file all'interno di un account cliente casuale. Piuttosto, esiste un contesto implicito: il confine dell'account del cliente. Pertanto, l'account stesso rappresenta il contenitore per la creazione di risorse e questo può essere modellato in modo esplicito in una politica simile all'esempio seguente.

// Grants permission to create files within an account,
// or within any sub-folder inside the account.
permit (
    principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d",
    action == Action::"createFile",
    resource in Account::"c863f89b-461f-4fc2-b638-e5fa5f79a48b"
);

Tuttavia, cosa succede se non esistono nemmeno account? Potresti scegliere di progettare il flusso di lavoro di registrazione dei clienti in modo che crei nuovi account nel sistema. In tal caso, avrai bisogno di un contenitore che contenga il confine più esterno entro il quale il processo può creare gli account. Questo contenitore a livello di radice rappresenta il sistema nel suo insieme e potrebbe avere un nome simile a «root di sistema». Tuttavia, la decisione se è necessario e come chiamarlo spetta all'utente, proprietario dell'applicazione.

Per questa applicazione di esempio, la gerarchia dei contenitori risultante apparirebbe quindi come segue:

Questo è un esempio di gerarchia. Anche altre sono valide. La cosa da ricordare è che la creazione di risorse avviene sempre nel contesto di un contenitore di risorse. Questi contenitori possono essere impliciti, come i limiti di un account, e può essere facile trascurarli. Durante la progettazione del modello di autorizzazione, assicuratevi di prendere nota di questi presupposti impliciti in modo che possano essere documentati e rappresentati formalmente nel modello di autorizzazione.

Separate i principali dai contenitori di risorse

Quando si progetta una gerarchia di risorse, una delle inclinazioni più comuni, in particolare per le applicazioni rivolte ai consumatori, è quella di utilizzare l'identità utente del cliente come contenitore per le risorse all'interno di un account cliente.

Ti consigliamo di considerare questa strategia come un anti-pattern. Questo perché c'è una tendenza naturale nelle applicazioni più ricche a delegare l'accesso ad altri utenti. Ad esempio, potresti scegliere di introdurre account «familiari», in cui altri utenti possono condividere le risorse dell'account. Analogamente, i clienti aziendali a volte desiderano designare più membri della forza lavoro come operatori di parti dell'account. Potrebbe inoltre essere necessario trasferire la proprietà di un account a un altro utente o unire le risorse di più account.

Quando un'identità utente viene utilizzata come contenitore di risorse per un account, gli scenari precedenti diventano più difficili da realizzare. Ancora più allarmante, se ad altri viene concesso l'accesso al contenitore dell'account con questo approccio, potrebbe inavvertitamente essere autorizzato a modificare l'identità dell'utente stesso, ad esempio cambiando l'e-mail o le credenziali di accesso di Jane.

Pertanto, quando possibile, un approccio più resiliente consiste nel separare i principali dai contenitori di risorse e modellare la connessione tra di essi utilizzando concetti come «autorizzazioni di amministratore» o «proprietà».

Se disponi di un'applicazione esistente che non è in grado di perseguire questo modello disaccoppiato, ti consigliamo di imitarlo il più possibile durante la progettazione di un modello di autorizzazione. Ad esempio, un'applicazione che possiede un solo concetto denominato Customer che incapsula l'identità dell'utente, le credenziali di accesso e le risorse di cui è proprietaria, potrebbe mapparlo a un modello di autorizzazione che contiene un'entità logica per Customer Identity (contenente nome, e-mail, ecc.) e un'entità logica separata per Customer Resources oCustomer Account, che funge da nodo principale per tutte le risorse di cui è proprietaria. Entrambe le entità possono condividere la stessa cosaId, ma con un'entità diversa. Type

Utilizzo di attributi o modelli per rappresentare le relazioni

Esistono due modi principali per esprimere le relazioni tra le risorse. Il momento in cui utilizzare l'una o l'altra dipende dal fatto che la relazione sia già memorizzata o meno nel database dell'applicazione e utilizzata per altri motivi, come la conformità. Se lo è, adotta l'approccio basato sugli attributi. In caso contrario, adotta l'approccio basato su modelli.

Relazioni basate sugli attributi

Gli attributi possono essere utilizzati come input per la decisione di autorizzazione per rappresentare una relazione tra un principale e una o più risorse.

Questo modello è appropriato quando la relazione viene tracciata e gestita per scopi che vanno oltre la semplice gestione delle autorizzazioni. Ad esempio, la registrazione del titolare principale del conto è necessaria per la conformità finanziaria alle regole Know Your Customer. Le autorizzazioni derivano da queste relazioni. I dati sulla relazione vengono gestiti all'esterno del sistema di autorizzazione e recuperati come input quando si prende una decisione di autorizzazione.

L'esempio seguente mostra come potrebbe essere rappresentata una relazione tra un utente Alice e una serie di account di cui è il principale titolare dell'account:

// Using a user attribute to represent the primary account holder relationship 
{
  "id": "df82e4ad-949e-44cb-8acf-2d1acda71798",
  "name": "alice",  
  "email": "[e-mail]",  
  "primaryOnAccounts": [
    "Account::\"c943927f-d803-4f40-9a53-7740272cb969\"",
    "Account::\"b8ee140c-fa09-46c3-992e-099438930894\""
  ]
}

E, successivamente, utilizzando l'attributo all'interno di una politica:

// Derived relationship permissions
  permit (
    principal,
    action in Action::"primaryAccountHolderActions",
    resource
  )when {
    resource in principal.primaryOnAccounts
  };

Al contrario, la stessa relazione potrebbe essere rappresentata come un attributo sulla risorsa chiamata primaryAccountHolders che contiene un insieme di utenti.

Se esistono più tipi di relazione tra i principali e le risorse, questi devono essere modellati come attributi diversi. Ad esempio, se gli account possono avere anche firmatari autorizzati e queste persone dispongono di autorizzazioni diverse sull'account, questo verrà rappresentato come un attributo diverso.

Nel caso precedente, Alice potrebbe anche essere un firmatario autorizzato su un terzo account. L'esempio seguente mostra come ciò potrebbe essere rappresentato:

// Using user attributes to represent the primary account holder and authorized signatory relationships 
{
  "id": "df82e4ad-949e-44cb-8acf-2d1acda71798",
  "name": "alice",  
  "email": "[e-mail]",  
  "primaryOnAccounts": [
    "Account::\"c943927f-d803-4f40-9a53-7740272cb969\"",
    "Account::\"b8ee140c-fa09-46c3-992e-099438930894\""
  ],
  "authorizedSignatoryOnAccounts": [
    "Account::\"661817a9-d478-4096-943d-4ef1e082d19a\""
  ]
}

Le seguenti sono le politiche corrispondenti:

// Derived relationship permissions

  permit (
    principal,
    action in Action::"primaryAccountHolderActions",
    resource
  )when {
    resource in principal.primaryOnAccounts
  };
  permit (
    principal,
    action in Action::"authorizedSignatoryActions",
    resource
  )when {
    resource in principal.authorizedSignatoryOnAccounts
  };

Relazioni basate su modelli

Se la relazione tra le risorse esiste esclusivamente ai fini della gestione delle autorizzazioni, è opportuno archiviare questa relazione come una politica o un modello collegato al modello. Puoi anche pensare a questi modelli come a ruoli assegnati a una risorsa specifica.

Ad esempio, in un sistema di gestione dei documenti, il proprietario del documento può scegliere di concedere l'autorizzazione a un altro utente per contribuire al documento. Alice Bob Ciò stabilisce una relazione di collaboratore tra Bob e il documento di Alice. L'unico scopo di questa relazione è concedere il permesso di modificare e commentare il documento, e quindi questa relazione può essere rappresentata come modello. In questi casi l'approccio consigliato consiste nel creare un modello per ogni tipo di relazione. Negli esempi seguenti sono presenti due tipi di relazione e quindi due modelli. Contributor Reviewer

I seguenti modelli possono essere utilizzati per creare politiche collegate ai modelli per singoli utenti.

  // Managed relationship permissions - Contributor template
  permit (
    principal == ?principal,  
    action in Action::"DocumentContributorActions",
    resource in ?resource
  );
    
  // Managed relationship permissions - Reviewer template
  permit (
    principal == ?principal,  
    action in Action::"DocumentReviewerActions",
    resource in ?resource
  );

I seguenti modelli possono essere utilizzati per creare politiche collegate ai modelli per gruppi di utenti. L'unica differenza rispetto ai modelli per singoli utenti è l'uso dell'inoperatore anziché di. ==

  // Managed relationship permissions - Contributor template
  permit (
    principal in ?principal,  
    action in Action::"DocumentContributorActions",
    resource in ?resource
  );

  // Managed relationship permissions - Reviewer template
  permit (
    principal in ?principal,  
    action in Action::"DocumentReviewerActions",
    resource in ?resource
  );

È quindi possibile utilizzare questi modelli per creare politiche, come le seguenti, che rappresentano le autorizzazioni relative alle relazioni gestite ogni volta che viene concesso l'accesso a un documento.

  //Managed relationship permissions
  permit (
    principal in User::"df82e4ad-949e-44cb-8acf-2d1acda71798",  
    action in Action::"DocumentContributorActions",
    resource in Document::"c943927f-d803-4f40-9a53-7740272cb969"
  );

  permit (
    principal in UserGroup::"df82e4ad-949e-44cb-8acf-2d1acda71798",
    action in Action::"DocumentReviewerActions",
    resource == Document::"661817a9-d478-4096-943d-4ef1e082d19a"
  );

  permit (
    principal in User::"df82e4ad-949e-44cb-8acf-2d1acda71798",
    action in Action::"DocumentContributorActions",
    resource in Folder::"b8ee140c-fa09-46c3-992e-099438930894"
  );

Amazon Verified Permissions è in grado di gestire in modo efficiente molte policy individuali e dettagliate durante la valutazione delle autorizzazioni e modellare le cose in questo modo significa che Verified Permissions mantiene un registro di controllo completo di tutte le decisioni di autorizzazione. AWS CloudTrail

Preferisci le autorizzazioni granulari nel modello e le autorizzazioni aggregate nell'interfaccia utente

Una strategia che i progettisti spesso rimpiangono in seguito consiste nel progettare un modello di autorizzazione con azioni molto ampie, come ad esempio «and»Write, Read e rendersi conto in seguito che sono necessarie azioni più dettagliate. L'esigenza di una maggiore granularità può essere determinata dal feedback dei clienti per controlli di accesso più granulari o dai revisori di conformità e sicurezza che incoraggiano le autorizzazioni con privilegi minimi.

Se le autorizzazioni granulari non sono definite in anticipo, può essere necessaria una conversione complicata per modificare il codice dell'applicazione e le istruzioni politiche in autorizzazioni più dettagliate per l'utente. Ad esempio, il codice dell'applicazione che in precedenza autorizzava un'azione granulare del corso dovrà essere modificato per utilizzare le azioni granulari. Inoltre, le politiche dovranno essere aggiornate per riflettere la migrazione:

permit (
    principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d",
    // action  ==  Action::"read",              -- coarse-grained permission -- commented out
    action in [                       //        -- finer grained permissions
        Action::"listFolderContents", 
        Action::"viewFile"
    ],
    resource in Account::"c863f89b-461f-4fc2-b638-e5fa5f79a48b"
);

Per evitare questa migrazione costosa, è meglio definire in anticipo autorizzazioni granulari. Tuttavia, ciò può comportare un compromesso se gli utenti finali sono successivamente costretti a comprendere un numero maggiore di autorizzazioni granulari, soprattutto se la maggior parte dei clienti sarebbe soddisfatta di controlli dettagliati come e. Read Write Per ottenere il meglio da entrambi i mondi, puoi raggruppare le autorizzazioni granulari in raccolte predefinite, ad esempio utilizzando meccanismi come modelli di policy o gruppi di azioni. Read Write Utilizzando questo approccio, i clienti vedono solo le autorizzazioni granulari del corso. Ma dietro le quinte, hai reso la tua applicazione a prova di futuro modellando le autorizzazioni granulari del corso come una raccolta di azioni granulari. Quando i clienti o i revisori lo richiedono, le autorizzazioni granulari possono essere esposte.

Prendi in considerazione altri motivi per richiedere l'autorizzazione

Di solito associamo i controlli di autorizzazione alle richieste degli utenti. Il controllo è un modo per determinare se l'utente è autorizzato a eseguire tale richiesta. Tuttavia, è possibile utilizzare i dati di autorizzazione anche per influenzare la progettazione dell'interfaccia dell'applicazione. Ad esempio, potreste voler visualizzare una schermata iniziale che mostri un elenco delle sole risorse a cui l'utente finale può accedere. Quando si visualizzano i dettagli di una risorsa, è possibile che l'interfaccia mostri solo le operazioni che l'utente può eseguire su quella risorsa.

Queste situazioni possono introdurre dei compromessi nel modello di autorizzazione. Ad esempio, il forte affidamento sulle politiche di controllo degli accessi (ABAC) basate sugli attributi può rendere più difficile rispondere rapidamente alla domanda «chi ha accesso a cosa?» Questo perché per rispondere a questa domanda è necessario esaminare ogni regola rispetto a ogni principale e risorsa per determinare se esiste una corrispondenza. Di conseguenza, un prodotto che deve essere ottimizzato per elencare solo le risorse accessibili dall'utente potrebbe scegliere di utilizzare un modello di controllo degli accessi () basato sui ruoli. RBAC In questo modoRBAC, può essere più semplice eseguire iterazioni su tutte le politiche associate a un utente per determinare l'accesso alle risorse.