Definire le autorizzazioni basate su attributi con l'autorizzazione ABAC - AWS Identity and Access Management

Definire le autorizzazioni basate su attributi con l'autorizzazione ABAC

Il controllo degli accessi basato su attributi (ABAC) è una strategia di autorizzazione che definisce le autorizzazioni in base agli attributi. AWS chiama questi attributi tag. È possibile collegare dei tag alle risorse IAM, tra cui le entità IAM (utenti o ruoli IAM), e alle risorse AWS. È possibile creare una singola policy ABAC o un piccolo insieme di policy per i principali IAM. Queste policy ABAC possono essere definite affinché autorizzino le operazioni quando il tag dell'entità corrisponde al tag della risorsa. Il sistema di attributi di ABAC che fornisce sia un contesto utente elevato che un controllo degli accessi granulare. Poiché ABAC è basato sugli attributi, può eseguire autorizzazioni dinamiche per dati o applicazioni che concedono o revocano l'accesso in tempo reale. La strategia ABAC è utile in ambienti soggetti a una rapida scalabilità e in situazioni in cui la gestione delle policy di identità o delle risorse è diventata complessa.

Ad esempio, è possibile creare tre ruoli IAM con la chiave di tag access-project. Impostare il valore del tag del primo ruolo IAM su Heart, del secondo su Star e del terzo su Lightning. È quindi possibile utilizzare una singola policy che consenta l'accesso quando il ruolo IAM e la risorsa AWS sono contrassegnati con lo stesso valore del tag access-project. Per un tutorial dettagliato che illustra come utilizzare ABAC in AWS, consulta Tutorial IAM: Definizione delle autorizzazioni per accedere alle risorse AWS in base ai tag. Per ulteriori informazioni sui servizi a supporto di ABAC, consulta Servizi AWS che funzionano con IAM.

Questo diagramma illustra che i tag applicati a un principale devono corrispondere ai tag applicati a una risorsa affinché all'utente vengano concesse le autorizzazioni per l'uso della risorsa. I tag devono essere applicati a gruppi IAM, gruppi di risorse, singoli utenti e singole risorse.

Confronto di ABAC con il modello RBAC tradizionale

Il modello di autorizzazione tradizionale utilizzato in IAM è chiamato controllo degli accessi basato su ruoli (RBAC). RBAC definisce le autorizzazioni in base alle mansioni lavorative o al ruolo di una persona, che è diverso da un ruolo IAM. IAM include policy gestite per le funzioni processo che allineano le autorizzazioni a una funzione di processo in un modello RBAC.

In IAM, è possibile implementare RBAC creando diverse policy per diverse mansioni lavorative. Quindi è possibile collegare le policy alle identità (utenti, gruppi o ruoli IAM). Come best practice si suggerisce di concedere le autorizzazioni minime necessarie per la mansione lavorativa. Ciò si traduce in un accesso con privilegi minimi. Ogni policy relativa alla funzione lavorativa elenca le risorse specifiche a cui possono accedere le identità assegnate a tale policy. Lo svantaggio di utilizzare il modello RBAC tradizionale è che, nel momento in cui gli utenti aggiungono nuove risorse, per consentire l'accesso a esse è necessario aggiornare le policy.

Ad esempio, si supponga di disporre di tre progetti denominati Heart, Star e Lightning, su cui lavorano i dipendenti. Si crea un ruolo IAM per ogni progetto. È quindi possibile collegare le policy a ciascun ruolo IAM per definire le risorse a cui può accedere chiunque sia autorizzato ad assumere il ruolo IAM. Se un dipendente cambia mansione all'interno dell'azienda, è necessario assegnargli un ruolo IAM differente. Le persone o i programmi possono essere assegnati a più di un ruolo IAM. Tuttavia, il progetto Star potrebbe richiedere risorse aggiuntive, ad esempio un nuovo container Amazon EC2. In tal caso, è necessario aggiornare la policy collegata al ruolo Star IAM per specificare la nuova risorsa del container. In caso contrario, i membri del progetto Star non potranno accedere al nuovo container.

Questo diagramma illustra che il controllo degli accessi basato sui ruoli richiede che a ciascuna identità venga assegnata una policy specifica basata sulla funzione lavorativa per accedere a risorse diverse.
Il modello ABAC offre i seguenti vantaggi rispetto al modello RBAC tradizionale:
  • Le autorizzazioni ABAC si ridimensionano con l'innovazione. Non è più necessario che un amministratore aggiorni le policy esistenti per consentire l'accesso a nuove risorse. Ad esempio, si supponga di aver progettato la strategia ABAC con il tag access-project. Uno sviluppatore utilizza il ruolo IAM con il tag access-project = Heart. Quando le persone del progetto Heart hanno bisogno di risorse Amazon EC2 aggiuntive, lo sviluppatore può creare nuove istanze Amazon EC2 con il tag access-project = Heart. In questo modo chiunque partecipi al progetto Heart può avviare e arrestare tali istanze perché i rispettivi valori di tag corrispondono.

  • ABAC richiede meno policy. Poiché non è necessario creare policy diverse per diverse mansioni lavorative, è necessario creare meno policy. Tali policy sono più facili da gestire.

  • Utilizzando ABAC, i team possono rispondere in modo dinamico ai cambiamenti e alla crescita. Poiché le autorizzazioni per le nuove risorse vengono concesse automaticamente in base agli attributi, non è necessario assegnare manualmente le policy alle identità. Ad esempio, se la propria azienda supporta già i progetti Heart e Star utilizzando ABAC, è facile aggiungere un nuovo progetto Lightning. Un amministratore IAM crea un nuovo ruolo con il tag access-project = Lightning. Non è necessario modificare la policy per supportare un nuovo progetto. Chiunque disponga delle autorizzazioni per assumere il ruolo IAM può creare e visualizzare istanze a cui è stato assegnato il tag access-project = Lightning. Un altro scenario si verifica quando un membro del team passa dal progetto Heart al progetto Lightning. Per fornire ai membri del team l'accesso al progetto Lightning, l'amministratore IAM li assegna a un ruolo IAM diverso. Non è necessario modificare le policy di autorizzazione.

  • Utilizzando la strategia ABAC e possibile definire autorizzazioni con un maggior livello di granularità. Quando si creano le policy, è consigliabile concedere i privilegi minimi. Utilizzando l'approccio RBAC tradizionale, è necessario scrivere una policy che consenta l'accesso a specifiche risorse. Tuttavia, quando si utilizza ABAC, è possibile consentire operazioni su tutte le risorse, ma solo se il tag della risorsa corrisponde al tag del principale.

  • Con ABAC è possibile utilizzare gli attributi dei dipendenti memorizzati nella directory aziendale. È possibile configurare il provider di identità SAML o OIDC per passare i tag di sessione a IAM. Quando i dipendenti si federano in AWS, IAM applica i loro attributi al rispettivo principale risultante. È quindi possibile utilizzare ABAC per consentire o negare le autorizzazioni sulla base di tali attributi.

Per un tutorial dettagliato che illustra come utilizzare ABAC in AWS, consulta Tutorial IAM: Definizione delle autorizzazioni per accedere alle risorse AWS in base ai tag.