Ciao a tutti e bentornati.
Ora nel video di oggi parleremo dell'architettura dell'account di identità.
Quindi al giorno d'oggi nella maggior parte delle organizzazioni che vedrai, ci sono due tipi principali di architettura
che sono generalmente molto comuni.
Il primo è l'architettura dell'account di identità e il secondo si basa sul single sign on
e quindi è importante per noi comprenderli.
E nel video di oggi, il nostro obiettivo principale sarà l'architettura dell'account di identità.
Quindi non solo questo è importante dal punto di vista dell'esame, ma è importante anche dal punto di vista
della produzione.
Ora, prima di andare avanti e comprendere più in dettaglio questo tipo di architettura, è
importante per noi fare un passo indietro per capire qual era il tipo di architettura che
le organizzazioni generalmente utilizzavano nei primi giorni quando stava guadagnando terreno .
Quindi durante i primi tempi avresti visto che la maggior parte delle organizzazioni aveva un unico account.
Quindi tutte le risorse, tutti i server creati erano solo nell'account singolo.
Quindi in questi casi la gestione era molto semplice e ogni utente che aveva bisogno di accedere a un account diverso aveva un
unico set di nome utente e password e un unico set di accesso e chiave segreta.
E in genere accadeva che questo conto fosse diviso.
C'era una divisione basata sulla regione.
Una regione è stata utilizzata per l'ambiente di sviluppo, la seconda regione è stata utilizzata per l'ambiente di produzione.
Quindi gli sviluppatori hanno avuto accesso a una regione dell'ambiente di sviluppo e il team di sicurezza del team ha avuto
accesso sia allo sviluppo che alla produzione.
Quindi questo era generalmente molto comune nei primi giorni.
E infatti al giorno d'oggi in molte delle piccole startup vedrai ancora un tale tipo di
architettura comunemente usata.
Ora, quando le organizzazioni diventano grandi e hanno centinaia di server, un'architettura basata su un singolo account non è
molto adatta e devi anche stare molto attento nelle tue policy IAM.
Ad esempio, hai aggiunto un nuovo sviluppatore al tuo account e per errore gli hai concesso l'accesso
all'istanza facile, ma hai dimenticato di specificare la condizione della regione dell'ambiente di sviluppo.
Quindi ora quello che accadrà è che lo sviluppatore avrà accesso sia alle regioni di sviluppo
che a quelle di produzione qui.
Quindi anche questo crea una serie di sfide e devi stare abbastanza attento all'interno delle tue policy
IAM e quindi quando la tua organizzazione diventa grande è importante avere un'architettura migliore con
un migliore isolamento.
Quindi un'architettura migliore che generalmente vedrai essere ampiamente utilizzata al giorno d'oggi è un account individuale
per funzione.
Quindi devi tenere conto dell'account dell'ambiente di sviluppo per la gestione temporanea di un account per la produzione.
Quindi, nel caso in cui lo sviluppatore desideri accedere al luogo in cui desidera eseguire dei test, può ottenere
l'accesso all'ambiente di sviluppo.
Ora, anche se questo è un grande tipo di architettura, si presenta con la sua sfida.
Una delle sfide principali che vedrai è che ogni utente avrà un diverso set di
nome utente e password per ogni account e un diverso set di accesso e chiave segreta per ogni account.
Quindi, ad esempio, supponiamo che un team di sicurezza ora un team di sicurezza dovrà monitorare tutti e tre gli
account.
Quindi un membro del team di sicurezza vuole accedere all'account di sviluppo.
Avrà il proprio nome utente e password se desidera eseguire alcune operazioni tramite un diverso set di accesso
e sono richieste chiavi segrete.
Quindi, quando ne hai, diciamo, 100, molte organizzazioni hanno centinaia di account.
Quindi, in questi casi, avere 100 username e password differenti, 100 accessi e chiavi segrete
differenti è molto difficile da gestire.
Quindi, per superare questo, hai un'architettura di account di identità.
Quindi, ciò che accade in un'architettura basata su account di identità è che tutti gli utenti IAM sono archiviati in un account di
database centrale a cui puoi fare riferimento come account di identità.
Puoi fare riferimento come account centrale o puoi anche dare un nome diverso.
Quindi, se vedi nel diagramma nell'account di identità, tutti gli utenti IAM vengono archiviati e
crei una configurazione in modo tale che gli utenti dell'account di identità possano accedere all'ambiente di
sviluppo, possono accedere direttamente all'ambiente di produzione senza avere un insieme separato di credenziali.
Quindi, ancora una volta, non è che qualsiasi utente possa accedere per sviluppare un'introduzione.
Tutto dipende dalla politica che aggiungi a livello di utente.
Può accedere allo sviluppo, accedere alla produzione o entrambi.
Quindi questa è l'idea di base dell'account di identità.
Viene utilizzato un solo set di credenziali.
Non vengono creati nome utente e password separati per ciascuno degli account.
Quindi, con questo set di base, andiamo avanti e facciamo una rapida demo.
Ora per la demo di oggi, ho due schede aperte e in ogni passaggio abbiamo un account separato.
Quindi in quella scheda, numero uno, se vedi si parla di identità.
Quindi questo è l'account di identità e la scheda numero due è indicata come produzione.
Quindi questo è un.
Conto introduttivo.
No.
Nell'account di identità vedrai che un utente di Alice ha effettuato l'accesso.
Supponiamo ora che l'utente Alice desideri accedere all'account di produzione.
Ora, in questo caso, come stiamo discutendo, poiché abbiamo un'architettura di base dell'account di
identità, l'utente ALICE non dovrà essere creato nell'account di produzione se l'autorizzazione di accesso è presente, l'utente
alice può accedere direttamente all'account di produzione.
Quindi dall'account di identità ciò che l'utente Alice può fare, può fornire il collegamento di accesso se vedi che sta
firmando il collegamento associato all'account di produzione e viene fornito anche il numero dell'account di produzione
e termina con quattro, sette, sei tre.
Quindi, non appena l'utente ALICE aggiunge questo, appare la configurazione di base del ruolo di cambio e tutto ciò che deve essere
fatto è cambiare ruolo.
E ora vedi che l'utente Alice ha effettuato l'accesso all'account di produzione.
Puoi anche vedere da qui che hai visto la produzione di trattino seguito dal
numero di conto e se guardi nel numero di conto finisce con quattro, sette, sei tre e
se guardi in una seconda scheda appartenente all'account di produzione, anche questo finisce con quattro, sette, sei tre.
Supponiamo ora che l'utente Alice abbia completato il lavoro appropriato nell'account di produzione.
Quindi l'utente Alice può andare avanti e tornare indietro e ora Alice torna all'account di identità.
E in seguito diciamo che l'utente di Alice vuole fare dei test nell'account di sviluppo in modo simile a
come era passata all'account di produzione.
L'approccio resta simile.
Ora un'altra cosa.
Dal momento che Alice è passata all'account di produzione, se vuole farlo di nuovo, la storia del
ruolo resta qui.
Quindi tutto ciò che deve fare è cliccare sulla produzione.
Quindi, non appena l'utente fa clic, torna all'account di produzione.
Tutto bene.
Quindi spero che a una panoramica di alto livello tu abbia compreso l'architettura dell'account di identità.
Quindi, indipendentemente da quanti account ci sono, hai 100 account, 200 account, ecc. Non importa.
Tutto quello che devi fare è dare accesso all'utente nell'account di identità in modo che l'utente
possa accedere all'account di identità e da qui possa accedere a tutti gli altri account a
seconda dell'autorizzazione che l'utente ha.
Ora, a una panoramica di alto livello, se si discute dell'architettura pratica, ci sono tre
passaggi generalmente richiesti.
Il primo è che l'utente deve essere creato nell'account.
Un account non è altro che l'account di identità.
Il secondo è che devi anche creare un ruolo per più account nell'account.
B Diciamo quindi che l'utente Alice ha effettuato l'accesso all'account di produzione.
Ora, qual è l'accesso che avrà l'utente Alice?
Avrà accesso a un tre?
Avrà accesso all'istanza E due e così via?
Quindi tutte queste cose sono definite in questo specifico ruolo di account incrociato.
E il terzo è consentire agli utenti di passare al ruolo dell'account B.
Quindi dai il permesso all'utente nell'account di identità in modo che possa passare allo sviluppo, alla produzione o
a qualsiasi altro account a seconda delle autorizzazioni orali.
Quindi questi suggerimenti possono essere facilmente compresi con questa architettura pratica.
Hai un account di identità.
Tutti gli utenti IAM sono presenti, hai un account incrociato, un ruolo IAM in ciascuno degli account in cui
desideri che gli utenti si connettano direttamente tramite l'account di identità e quindi gli utenti possono eseguire l'operazione di
ruolo per connettersi a questo account specifico.
Ora vedrai nell'account b che hai un'autorizzazione per il bucket S3 nell'account.
C Hai il permesso di istanze facili.
Quindi, se un utente ha effettuato l'accesso all'account C, l'utente avrà accesso solo a E due e nessun altro servizio.
Quindi lascia che ti mostri rapidamente anche questo.
Ora nel resoconto della produzione, apriamo rapidamente l'IAM e qui dentro ho un ruolo di produzione di
trattino C.
Quindi, se avresti notato che questo utente ha utilizzato questo ruolo che è la produzione di trattini C.
Ora, qual è il permesso che ha questo ruolo?
L'unica autorizzazione allegata è l'accesso di sola lettura S3.
Quindi, se l'utente Alice prova ad aprire il servizio facile da qui, vedrai immediatamente che ricevi un errore.
Quindi l'unica autorizzazione che Alice ha è l'accesso S3.
Quindi, se provi ad aprire l'S3.
Vedi, tutti i secchi appaiono nella griglia del guerriero.
Quindi questa è la panoramica di alto livello sull'architettura dell'account di identità.
E nel prossimo video andremo avanti e lo esamineremo da un punto di vista pratico in modo che la nostra comprensione
sia solida e chiara.
Quindi con questo si concluderà il video di oggi.