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. Quindi, procedi 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? Come sono organizzate? Ad esempio, i file si trovano all'interno di una cartella?

• L'organizzazione delle risorse ha un ruolo nel modello di autorizzazioni?

• 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 entrambi?

• I ruoli sono globali o circoscritti? Ad esempio, un «operatore» è limitato a un singolo tenant o «operatore» significa operatore nell'intera applicazione?

• 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 prima di tutto 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 influiscono su ciò che gli utenti possono fare 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.

Per contribuire a rispondere alle domande e giungere a un modello ottimale, procedi come segue:

• Consulta i modelli di progettazione di Cedar nella Guida di riferimento al linguaggio delle politiche Cedar.

• Prendi in considerazione le migliori pratiche nella Guida di riferimento al linguaggio delle politiche Cedar.

• Considerate le migliori pratiche incluse in questa pagina.

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, le autorizzazioni sono modellate in base alle risorse supportate. 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, man mano che sviluppate ulteriormente il modello, questo approccio API incentrato potrebbe non essere adatto alle applicazioni con modelli di autorizzazione molto granulari, 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 concentrarti 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 astrattaviewGroupMembership, ad esempio, 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.

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 tuo 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. Per ulteriori informazioni, consulta Considerazioni sulla progettazione multi-tenant di Amazon Verified Permissions in Prescriptive Guidance.AWS

1. Un archivio di policy 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 avrà un grande impatto sulla AWS bolletta. Quindi, come dovresti progettare il tuo approccio? Le seguenti sono condizioni comuni che potrebbero contribuire alla vostra strategia di autorizzazione multi-tenant Verified Permissions.

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

Quando l'applicazione dispone di più archivi di policy, i modelli di policy e uno schema di policy store aggiungono un livello di sovraccarico di progettazione e manutenzione in ogni archivio di policy.

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	Alto. È 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.