A cosa serve ABAC AWS

Il controllo dell'accesso basato su attributi (ABAC) è una strategia di autorizzazione che definisce le autorizzazioni in base agli attributi. In AWS, questi attributi sono chiamati 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. La strategia ABAC è utile in ambienti soggetti a una rapida crescita e aiuta in situazioni in cui la gestione delle policy diventa impegnativa.

Ad esempio, puoi creare tre ruoli IAM con la chiave access-project tag. Imposta il valore del tag del primo ruolo IAM suHeart, il secondo su Star e il terzo suLightning. Puoi quindi utilizzare un'unica policy che consenta l'accesso quando il ruolo IAM e la risorsa sono etichettati con lo stesso valore peraccess-project. Per un tutorial dettagliato che dimostra come usare ABAC in AWS, vedi. 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.

Confronto di ABAC con il modello RBAC tradizionale

Il modello di autorizzazione tradizionale utilizzato in IAM è chiamato controllo dell'accesso basato sul ruolo (Role-Based Access Control, RBAC). RBAC definisce le autorizzazioni in base alle mansioni lavorative di una persona, note al di fuori di AWS come ruolo. All'interno AWS di un ruolo di solito si fa riferimento a un ruolo IAM, che è un'identità in IAM che puoi assumere. 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 colleghi le policy alle identità (utenti IAM, gruppi IAM o ruoli IAM). Come best practice si suggerisce di concedere le autorizzazioni minime necessarie per la mansione lavorativa. Questo approccio è noto come concessione dei privilegi minimi. Tale risultato si ottiene elencando le risorse specifiche a cui la mansione lavorativa può accedere. Lo svantaggio di utilizzare il modello RBAC tradizionale è che, nel momento in cui i dipendenti 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 colleghi 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 allegata al ruolo Star IAM per specificare la nuova risorsa del contenitore. In caso contrario, i membri del progetto Star non potranno accedere al nuovo container.

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 Heart tag access-project =. 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 cambiare e crescere rapidamente. Questo perché le autorizzazioni per le nuove risorse vengono concesse automaticamente in base agli attributi. 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 IAM con il Lightning tag access-project =. Non è necessario modificare la policy per supportare un nuovo progetto. Chiunque disponga delle autorizzazioni necessarie per assumere il ruolo IAM può creare e visualizzare le istanze contrassegnate con access-project =. Lightning Inoltre, un membro del team potrebbe passare dal progetto Heart al progetto Lightning. L'amministratore IAM assegna l'utente IAM 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 solo 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 dell'entità.

• Con ABAC è possibile utilizzare gli attributi dei dipendenti memorizzati nella directory aziendale. Puoi configurare il tuo provider SAML o OIDC a cui passare i tag di sessione. AWS Quando i tuoi dipendenti si uniscono in AWS, i loro attributi vengono applicati al responsabile risultante in. AWSÈ 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