Salut à tous et bienvenue.
Maintenant, dans la vidéo d'aujourd'hui, nous allons discuter de l'architecture du compte d'identité.
Ainsi, de nos jours, dans la plupart des organisations que vous verrez, il existe deux principaux types d'architecture
qui sont généralement très courants.
Le premier est l'architecture du compte d'identité, et le second est basé sur l'authentification unique et il
est donc important pour nous de les comprendre.
Et dans la vidéo d'aujourd'hui, notre objectif principal sera l'architecture du compte d'identité.
Donc, non seulement c'est important du point de vue de l'examen, mais c'est aussi important du point de vue de
la production.
Maintenant, avant d'aller de l'avant et de comprendre plus en détail ce type d'architecture, il
est important pour nous de prendre du recul pour comprendre quel était le type d'architecture que
les organisations utilisaient généralement au début, quand elle gagnait du terrain. .
Ainsi, au début, vous verriez que la plupart des organisations n'avaient qu'un seul compte.
Ainsi, toutes les ressources, tous les serveurs qui ont été créés se trouvaient dans le seul compte.
Ainsi, dans de tels cas, la gestion était très simple et chaque utilisateur qui avait besoin d'accéder à un compte diversifié disposait d'un seul
ensemble de nom d'utilisateur et de mot de passe et d'un seul ensemble d'accès et de clé secrète.
Et généralement, ce qui se passait, c'était que ce compte était divisé.
Il y avait une division basée sur la région.
Une région a été utilisée pour l'environnement de développement, la deuxième région a été utilisée pour l'environnement de production.
Ainsi, les développeurs avaient accès à une région d'environnement de développement et l'équipe de sécurité de l'équipe avait accès à la
fois au développement et à la production.
C'était donc généralement très courant au début.
Et en fait, de nos jours, dans de nombreuses petites startups, vous verrez encore ce type
d'architecture couramment utilisé.
Maintenant, lorsque les organisations deviennent grandes et qu'elles ont des centaines de serveurs, une architecture basée sur un seul compte n'est
pas très appropriée et vous devez également être très prudent dans vos politiques IAM.
Par exemple, vous avez ajouté un nouveau développeur à votre compte et par erreur vous lui avez donné accès
à l'instance facile, mais vous avez oublié de spécifier l'état de la région de l'environnement de développement.
Alors maintenant, ce qui va se passer, c'est que le développeur aura accès à la fois aux régions
de développement et de production ici.
Cela crée donc à nouveau un certain nombre de défis et vous devez être très prudent dans vos politiques IAM.
Par conséquent, lorsque votre organisation devient grande, il est important que vous disposiez d'une meilleure architecture avec
une meilleure isolation.
Ainsi, une meilleure architecture que vous verrez généralement largement utilisée de nos jours est le compte individuel
par fonction.
Vous devez donc tenir compte du compte d'environnement de développement pour créer un compte pour la production.
Ainsi, si le développeur souhaite accéder à l'endroit où il souhaite effectuer des tests, il peut accéder à
l'environnement de développement.
Bien qu'il s'agisse d'un excellent type d'architecture, il comporte son propre défi.
L'un des principaux défis que vous verrez est que chaque utilisateur aura un ensemble différent de nom
d'utilisateur et de mot de passe pour chaque compte et un ensemble différent d'accès et de clé secrète pour chaque compte.
Ainsi, par exemple, disons qu'une équipe de sécurité devra désormais surveiller l'ensemble de ces trois
comptes.
Ainsi, un membre de l'équipe de sécurité souhaite se connecter au compte de développement.
Il aura son propre nom d'utilisateur et mot de passe s'il veut effectuer certaines opérations via un jeu d'accès différent
et des clés secrètes sont nécessaires.
Ainsi, lorsque vous en avez, disons, 100, de nombreuses organisations ont des centaines de comptes.
Ainsi, dans de tels cas, avoir 100 noms d'utilisateur et mots de passe différents, 100 accès différents et une
clé secrète est très difficile à gérer.
Donc pour pallier à cela, vous disposez d'une architecture de compte d'identité.
Ainsi, ce qui se passe dans une architecture basée sur un compte d'identité, c'est que tous les utilisateurs IAM sont stockés dans un
compte de base de données central que vous pouvez appeler compte d'identité.
Vous pouvez faire référence à un compte central ou vous pouvez également donner un nom différent.
Donc, si vous voyez dans le diagramme du compte d'identité, tous les utilisateurs IAM sont stockés et que
vous créez une configuration de telle sorte que les utilisateurs du compte d'identité puissent se connecter à l'environnement de
développement, ils peuvent se connecter directement à l'environnement de production sans avoir un ensemble distinct d'informations d'identification.
Encore une fois, ce n'est pas que n'importe quel utilisateur peut se connecter pour développer une introduction.
Tout dépend de la stratégie que vous ajoutez au niveau de l'utilisateur.
Il peut soit se connecter au développement, soit se connecter à la production, soit les deux.
C'est donc l'idée de base du compte d'identité.
Un seul ensemble d'informations d'identification est utilisé.
Aucun nom d'utilisateur et mot de passe distincts ne sont créés pour chacun des comptes.
Donc, avec cet ensemble de base, allons-y et faisons une démonstration rapide.
Maintenant, pour la démo d'aujourd'hui, j'ai deux onglets ouverts et à chaque étape, nous avons un compte séparé.
Donc, dans cet onglet, numéro un, si vous le voyez, on parle d'identité.
Il s'agit donc du compte d'identité et l'onglet numéro deux est appelé une production.
C'est donc un.
Compte de présentation.
Non.
Dans le compte d'identité, vous verrez qu'un utilisateur d'Alice s'est connecté.
Supposons maintenant que l'utilisateur d'Alice souhaite accéder au compte de production.
Maintenant, dans ce cas, comme nous en discutons, puisque nous avons une architecture de base de
compte d'identité, l'utilisateur ALICE n'aura pas besoin d'être créé dans le compte de production si l'autorisation d'accès est là, l'utilisateur
alice peut se connecter directement au compte de production.
Ainsi, à partir du compte d'identité, ce que l'utilisateur d'Alice peut faire, elle peut fournir le lien de connexion si vous voyez qu'il s'agit d'un
lien de signature associé au compte de production et que le numéro de compte de production est également indiqué et
qu'il se termine par quatre, sept, six trois.
Ainsi, dès que l'utilisateur ALICE ajoute ceci, la configuration de base du rôle du commutateur apparaît et tout ce qui doit être fait est
le rôle du commutateur.
Et maintenant, vous voyez que l'utilisateur Alice s'est connecté au compte de production.
Vous pouvez même voir à partir d'ici que vous avez vu la production de traits d'union suivi
du numéro de compte et si vous regardez le numéro de compte, il se termine par quatre, sept, six trois
et si vous regardez dans un deuxième onglet appartenant au compte de production, cela se termine également avec quatre, sept, six trois.
Supposons maintenant que l'utilisateur d'Alice ait terminé le travail approprié dans le compte de production.
Ensuite, l'utilisateur d'Alice peut continuer et revenir en arrière et maintenant Alice est de retour au compte d'identité.
Et plus tard, disons que l'utilisateur d'Alice veut faire des tests dans le compte de développement similaire à la façon dont elle
est passée au compte de production.
L'approche reste similaire.
Maintenant encore une chose.
Depuis qu'Alice est passée au compte de production, si elle veut le refaire, l'historique des rôles reste
à être ici.
Il lui suffit donc de cliquer sur la production.
Ainsi dès que l'utilisateur clique, il revient sur le compte de production.
D'accord.
J'espère donc qu'à un niveau élevé, vous avez compris l'architecture du compte d'identité.
Donc, quel que soit le nombre de comptes, vous avez 100 comptes, 200 comptes, etc. Ce n'est pas important.
Tout ce que vous devez faire est de donner accès à l'utilisateur dans le compte d'identité afin que l'utilisateur
puisse se connecter au compte d'identité et à partir de là, il puisse se connecter à tous les autres comptes
en fonction de l'autorisation dont dispose l'utilisateur.
Maintenant, à un niveau élevé, si vous discutez de l'architecture pratique, trois étapes sont
généralement requises.
La première est que l'utilisateur doit être créé dans le compte.
Un compte n'est rien d'autre que le compte d'identité.
La seconde est que vous devez également créer un rôle intercompte dans le compte.
B Disons donc que l'utilisateur Alice s'est connecté au compte de production.
Maintenant, quel est l'accès dont disposera l'utilisateur Alice ?
Aura-t-elle accès à un trois ?
Aura-t-elle accès à l'instance E deux et ainsi de suite ?
Donc, toutes ces choses sont définies dans ce rôle spécifique entre comptes.
Et le troisième est que vous autorisez les utilisateurs à passer au rôle du compte B.
Vous donnez donc l'autorisation à l'utilisateur dans le compte d'identité afin qu'elle puisse passer au développement, à la production
ou à tout autre compte en fonction des autorisations orales.
Ainsi, ces pointeurs peuvent être facilement compris avec cette architecture pratique.
Vous avez un compte d'identité.
Tous les utilisateurs IAM sont présents, vous avez un compte croisé, un rôle IAM dans chacun des comptes où
vous souhaitez que les utilisateurs se connectent directement via le compte d'identité, puis les utilisateurs peuvent effectuer l'opération de rôle
pour se connecter à ce compte spécifique.
Vous verrez maintenant dans le compte b que vous disposez d'une autorisation de compartiment S3 dans le compte.
C Vous avez la permission de facile à instancier.
Ainsi, si un utilisateur s'est connecté au compte C, l'utilisateur n'aura accès qu'à E deux et à aucun autre service.
Alors permettez-moi de vous montrer cela aussi rapidement.
Maintenant dans le compte de la production, ouvrons rapidement l'IAM et ici j'ai un rôle de production de trait
d'union C.
Donc, si vous avez remarqué que cet utilisateur a utilisé ce rôle qui est la production de traits d'union C.
Maintenant, quelle est l'autorisation dont dispose ce rôle ?
La seule autorisation attachée est l'accès en lecture seule S3.
Donc, si l'utilisateur d'Alice essaie d'ouvrir le service facile ici, vous voyez immédiatement que vous obtenez une erreur.
Ainsi, la seule autorisation dont Alice dispose est l'accès S3.
Donc, si vous essayez d'ouvrir le S3.
Vous voyez, tous les seaux apparaissent sur la grille du guerrier.
Il s'agit donc de la vue d'ensemble de haut niveau sur l'architecture du compte d'identité.
Et dans la prochaine vidéo, nous allons aller de l'avant et l'examiner d'un point de vue pratique afin que notre compréhension
soit solide et claire.
Donc, avec cela se terminera la vidéo d'aujourd'hui.