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

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à.

Definire le autorizzazioni basate su attributi con l'autorizzazione ABAC

Il controllo degli accessi basato sugli attributi (ABAC) è una strategia di autorizzazione che definisce le autorizzazioni in base agli attributi. AWS chiama questi attributi tag. Puoi allegare tag alle risorse IAM, incluse le entità IAM (utenti IAM o ruoli IAM) e alle AWS risorse. È 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. Puoi quindi utilizzare un'unica policy che consenta l'accesso quando il ruolo IAM e la AWS risorsa hanno il valore del tagaccess-project. Per un tutorial dettagliato che illustra come utilizzare ABAC in AWS, consulta Tutorial IAM: definisci le autorizzazioni per accedere alle AWS risorse in base ai tag. Per ulteriori informazioni sui servizi a supporto di ABAC, consulta AWS servizi 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 Star progetto potrebbe richiedere risorse aggiuntive, come un nuovo EC2 container Amazon. 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 coinvolte nel Heart progetto necessitano di EC2 risorse Amazon aggiuntive, lo sviluppatore può creare nuove EC2 istanze Amazon con il Heart tag access-project =. 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 tuoi dipendenti si uniscono AWS, IAM applica i loro attributi al principale risultante. È quindi possibile utilizzare ABAC per consentire o negare le autorizzazioni sulla base di tali attributi.

Per un tutorial dettagliato che dimostra come utilizzare ABAC in AWS, vedi. Tutorial IAM: definisci le autorizzazioni per accedere alle AWS risorse in base ai tag