Ciao a tutti e bentornati.
Nel video di oggi parleremo del controllo degli accessi basato sugli attributi,
noto anche come IBAC.
Prima di iniziare l'apprendimento dell'ABC, è importante comprendere le basi dell'arte.
Ora, l'arabo sta per controllo degli accessi basato sui ruoli.
In questo tipo di approccio, la restrizione dell'accesso si basa sul ruolo della persona all'interno dell'organizzazione.
Ora, quando parliamo di IAM in un luogo, implementiamo il nostro retro creando diverse serie di politiche per diverse
serie di funzioni.
Ad esempio, si vede che ci sono due utenti e che ogni utente è associato a un criterio diverso.
Quindi, in primo luogo abbiamo la politica DevOps e in secondo luogo abbiamo la politica di sicurezza.
In base alle restrizioni o ai permessi aggiunti come parte del criterio, l'utente sarà in grado di eseguire
determinate funzioni.
Questo è l'approccio basato sulla schiena.
Ora, ci sono alcune sfide che potreste affrontare con questo approccio.
Quindi, andiamo avanti e approfondiamo l'argomento.
Supponiamo di avere questo account e che all'interno di questo account ci siano due ambienti diversi.
C'è un ambiente rosso e un ambiente verde.
E consideriamo che entrambi sono ambienti di produzione.
Ora, supponiamo di utilizzare un modello tipico basato su Outback e di avere un criterio centrale chiamato criterio
DevOps di accesso all'amministratore associato a questo account.
E avete un team DevOps a cui è associata questa politica.
A questo punto possiamo facilmente identificare che il team DevOps sarà in grado di eseguire tutte le funzioni sia sugli
ambienti rossi che su quelli verdi.
Ora, in genere nelle grandi organizzazioni si nota che anche all'interno del team DevOps, alcuni membri del team sono
responsabili di determinate parti dell'infrastruttura.
Supponiamo che questo team DevOps abbia dieci membri.
Cinque membri sono responsabili dell'ambiente rosso, cinque membri sono responsabili dell'ambiente verde.
Ora, in un approccio che prevede un criterio centrale come questo, tutti i dieci membri saranno
in grado di eseguire operazioni su tutti gli ambienti, cosa che non sempre si desidera.
In base a questa architettura, il team DevOps ha accesso sia all'ambiente rosso che a quello verde.
Ora, che cosa faranno le organizzazioni per segregare le cose?
Andranno avanti e creeranno due diverse serie di politiche.
Supponiamo di avere una politica numero uno per l'ambiente rosso, una numero due per l'ambiente verde,
e i cinque membri del team DevOps responsabili dell'ambiente rosso avranno questa politica DevOps
rossa e gli altri cinque membri avranno questa politica DevOps verde.
E in questa politica DevOps rossa, consentite solo le autorizzazioni sul rosso in verde, consentite solo le autorizzazioni sul
verde.
Questo tipo di architettura è quindi molto migliore rispetto alla precedente.
Tuttavia, in organizzazioni più grandi, diciamo quelle in cui ci sono 20 o 30 team diversi di DevOps o magari di amministratori
di sistema sviluppatori, ecc. In questo modo, dovrete creare un numero
sempre maggiore di criteri associati a ciascun gruppo di membri responsabili di un ambiente specifico.
Per evitarlo, si può ricorrere al controllo degli accessi basato sugli attributi, che può rivelarsi
un approccio migliore.
Ora, prima di parlare dell'APAC, rivediamo le basi degli attributi.
Quindi, a livello generale, gli attributi non sono altro che una coppia chiave-valore che si associa a un'entità
specifica.
Può essere un utente, può essere facile da istruire, ecc. Quindi in un luogo questi attributi sono chiamati tag.
È quindi semplice da capire.
Quando si parla di criteri basati sugli attributi, si ha un unico insieme di criteri.
Anche in questo caso, non c'è bisogno di una serie di criteri multipli e all'interno di questo criterio specifico ci sarà
un permesso primario, che è quello di consentire, ad esempio, la stella.
Quindi consente l'accesso all'ambiente in base all'attributo dell'utente.
A questo punto sappiamo che abbiamo un ambiente rosso e un ambiente verde
e associamo l'attributo a ciascun membro.
Quindi il membro DevOps ha l'attributo DevOps rosso.
Il membro due ha un attributo verde.
In questo tipo di politica, il membro DevOps uno avrà pieno accesso all'ambiente rosso e il membro
DevOps due avrà pieno accesso all'ambiente verde, principalmente a causa degli attributi
aggiunti a livello di utente e anche degli attributi aggiunti a livello di ambiente.
Con questo approccio, quindi, si avrà un minor numero di criteri, più facili da mantenere.
Tuttavia, uno degli aspetti più importanti e critici è quello delle etichette.
Quindi gli utenti, l'ambiente che si crea, tutti questi elementi devono essere etichettati.
Per quanto riguarda gli attributi di un utente IAM, in questa schermata è possibile vedere che ne abbiamo uno.
L'utente universitario 101 e l'utente associato a questo utente è un tag.
Questa etichetta è una squadra di colore verde.
Quindi, considerando che tutti i tag sono impostati correttamente e le politiche sono corrette, questo
membro sarà considerato anche come membro DevOps, poiché c'è un team di Green e sarà in grado di
accedere ed eseguire tutte le operazioni sull'ambiente verde.
Quindi, con questo set di base, procediamo a rivedere il controllo degli accessi basato sugli attributi con una panoramica di
alto livello.
E back è una strategia di autorizzazione che definisce il permesso in base agli attributi, e abbiamo
imparato che gli attributi sono tag in noi.
Ora, se guardate questo diagramma specifico, l'ho preso direttamente dalla documentazione, in modo che nel
caso in cui lo stiate esaminando diventi più facile da rivedere.
Si vede quindi che ci sono tre ambienti diversi.
Abbiamo il rosso, il giallo e il blu e ci sono diversi gruppi di utenti e di clienti e ad ogni utente e cliente
è associato un attributo specifico.
Quindi l'utente con l'attributo rosso sarà in grado di accedere alle risorse che hanno l'attributo rosso, quindi si può considerare
l'ambiente rosso, l'ambiente giallo, l'ambiente blu e così via.
Quindi, con questo set di base, procediamo con una rapida dimostrazione per capire come funzionano le cose.
Per il video di oggi, ho due EC, due istanze.
Uno fa parte dell'ambiente rosso.
La seconda è come parte dell'ambiente verde per l'istanza EC due, che è associata all'ambiente
rosso.
Se si guarda ai tag, il tema è il rosso.
Questa è l'etichetta importante.
E per l'ambiente verde, il team qui è verde.
Allo stesso modo, nell'ambito degli utenti IAM, si hanno due utenti: l'utente zero uno associato al team verde
e l'utente zero due associato al team rosso.
Se apriamo l'utente zero uno e guardiamo di nuovo i tag, c'è lo stesso tag team di verde
e per l'utente due, c'è un team di rosso.
L'idea di base è che se il tag associato all'utente corrisponde al tag associato alla risorsa, come l'istanza
EC due, allora l'utente sarà in grado di eseguire le operazioni definite nella
politica IAM.
Ora, in questa fase ho un gruppo comune chiamato gruppo DevOps e in questo gruppo ci sono
entrambi gli utenti aggiunti e se si guarda ai permessi, c'è un solo criterio associato.
Se esaminate questa politica, infatti, lasciate che la modifichi ora.
Se si esamina questo criterio, è possibile eseguire un'azione basata sull'avvio dell'istanza e sull'interruzione dell'istanza,
oltre ad avere una condizione specifica basata sul tag.
La chiave è quindi la squadra.
In pratica, ciò significa che se il team associato all'ambiente rosso EC due corrisponde a quello del team associato
all'utente IAM, allora l'utente sarà in grado di eseguire queste operazioni.
Proviamo ora rapidamente da un'altra finestra del browser.
Consentitemi di accedere rapidamente all'utente che fa parte del team verde.
Ora, se si va alla console EC due, passiamo alla regione appropriata.
Passiamo alle istanze.
Anche in questo caso, l'utente zero uno è associato a una squadra verde.
Ora, se l'utente tenta di fermare immediatamente l'istanza associata al team rosso,
si ottiene un errore simile.
Se l'utente prova a fermare l'istanza associata a un ambiente verde, si vede che funziona perfettamente.
Va bene.
Spero quindi che abbiate capito che una panoramica di alto livello su come un singolo criterio IAM basato sugli attributi
possa essere molto più scalabile in un ambiente più grande, considerando che le risorse sono etichettate correttamente.
Ora, prima di concludere, procediamo a rimuovere manualmente il tag associato al tema del verde nell'ambiente
verde.
Facile da.
Quindi rimuoverò questo tag specifico.
L'istanza è in fase di arresto, quindi aspettiamo un attimo.
Quindi, se aggiorniamo le istanze attualmente fermate dall'utente zero che aveva sia il permesso di fermare l'istanza
sia quello di avviarla, se questo utente tenta ora di avviare immediatamente l'istanza, si vedrà che l'errore
si è verificato principalmente perché i tag non corrispondono.
Per semplicità, ho allegato anche la schermata associata al criterio IAM.
Quindi, nel caso in cui si stiano rivedendo le diapositive, diventa molto più facile capire come
vengono configurati i criteri di sfondo.
Prima di concludere, parliamo dei vantaggi dell'airbag.
Il primo è che l'airbag richiede un minor numero di politiche, soprattutto perché non è necessario creare politiche
diverse per le varie funzioni lavorative.
È possibile creare un criterio centrale e, in base ai tag, gestire automaticamente le autorizzazioni.
In secondo luogo, i permessi possono essere facilmente concessi e revocati in base ai tag degli utenti, come abbiamo
visto quando abbiamo rimosso il tag associato all'istanza EC due il permesso di entrare.
Allo stesso modo, supponiamo che un utente dell'ambiente verde non lavori più nell'ambiente verde.
Gli sono state assegnate altre responsabilità.
A quel punto, tutto ciò che dovrete fare è rimuovere il tag verde dell'ambiente dall'utente IM e tutti i permessi
saranno eliminati.
La terza caratteristica principale è che i criteri di accesso basati sugli attributi si rivelano molto utili anche quando si dispone di
utenti di una directory aziendale come Active Directory e si desidera consentire o negare le autorizzazioni
alle risorse statunitensi.
Questa è la panoramica di alto livello.
E con questo si conclude il video di oggi.