Bonjour, tout le monde, et bienvenue à nouveau.
Dans la vidéo d'aujourd'hui, nous allons parler du contrôle d'accès basé sur les attributs,
également appelé IBAC.
Avant de commencer notre apprentissage de l'ABC, il est important que nous comprenions d'abord les bases de l'art.
Pour l'instant, l'arabe représente le contrôle d'accès basé sur le rôle.
Et dans ce type d'approche, la restriction d'accès est basée sur le rôle de la personne au sein de l'organisation.
Maintenant, lorsque nous discutons de l'IAM dans un endroit, nous mettons en œuvre notre retour en créant différents ensembles de politiques pour différents
ensembles de fonctions.
Par exemple, vous voyez qu'il y a deux utilisateurs et que chaque utilisateur est associé à une politique différente.
Nous avons donc d'abord la politique DevOps et ensuite la politique de sécurité.
Et en fonction des restrictions ou des autorisations que vous ajoutez dans le cadre de la politique, l'utilisateur sera en mesure d'exécuter
certaines fonctions.
C'est donc l'approche par le fond.
Cette approche comporte cependant certains défis que vous pouvez rencontrer.
Alors, allons-y et examinons-la.
Supposons donc que vous ayez ce compte et que dans ce compte vous ayez deux environnements différents.
Vous avez un environnement rouge et vous avez l'environnement vert.
Et considérons que ces deux environnements sont des environnements de production.
Maintenant, supposons que vous utilisez un modèle typique basé sur l'outback et que vous avez un appel de politique centrale
comme une politique DevOps d'accès admin qui est associée à ce compte.
Et vous avez une équipe DevOps à laquelle cette politique est associée.
À ce stade, nous pouvons facilement identifier que l'équipe DevOps sera en mesure d'exécuter toutes les fonctions sur
les environnements rouges et verts.
En général, dans les grandes organisations, vous verrez que même au sein de l'équipe DevOps, certains membres de l'équipe
sont responsables de certaines parties de l'infrastructure.
Supposons donc que cette équipe DevOps compte dix membres.
Cinq membres sont responsables de l'environnement rouge, cinq membres sont responsables de l'environnement vert.
Maintenant, dans une approche où vous avez une politique centrale comme celle-ci, tous les dix membres seront en mesure
d'effectuer des opérations sur tous les environnements et c'est quelque chose que vous ne voulez pas toujours.
Sur la base de cette architecture, l'équipe DevOps a donc accès aux environnements rouge et vert.
Maintenant, que vont faire les organisations pour séparer les choses ?
Ils vont aller de l'avant et créer deux ensembles différents de politiques.
Supposons que vous ayez une politique numéro un pour l'environnement rouge, numéro deux pour l'environnement
vert, et les cinq membres de l'équipe DevOps responsable de l'environnement rouge auront cette politique
DevOps rouge et les cinq autres membres auront cette politique DevOps verte.
Et dans cette politique DevOps rouge, vous n'autorisez que les permissions sur le rouge dans le vert, vous n'autorisez que les permissions sur
le vert.
Ce type d'architecture est donc bien meilleur que le précédent.
Cependant, dans les grandes organisations, disons celles où il y a 20 ou 30 équipes différentes de DevOps ou peut-être
des administrateurs système développeurs, etc. Dans ce cas, ce qu'il faut faire, c'est aller de l'avant
et créer de plus en plus d'ensembles de politiques associés à chaque groupe de membres responsables d'un environnement spécifique.
Et pour éviter cela, vous pouvez utiliser le contrôle d'accès basé sur les attributs, qui peut s'avérer être une approche
bien plus efficace.
Avant de parler de l'APAC, révisons les bases des attributs.
Ainsi, à un haut niveau, les attributs ne sont rien d'autre qu'une paire clé-valeur que vous associez à une
entité spécifique.
Il peut s'agir d'un utilisateur, d'une instance facile, etc. Dans un endroit, ces attributs sont appelés balises.
C'est donc simple à comprendre.
Maintenant, lorsque nous discutons de la politique basée sur les attributs, ce que vous allez faire, vous avez un seul ensemble de politique.
Encore une fois, il n'est pas nécessaire d'avoir plusieurs séries de politiques, et dans cette politique spécifique, il y
aura une permission principale, qui est d'autoriser, par exemple, les étoiles.
Autorisez donc tous les accès à l'environnement en fonction de l'attribut de l'utilisateur.
Maintenant, à ce stade, nous savons que vous avez un environnement rouge, vous avez un environnement
vert, et vous associez l'attribut à chacun des membres.
Donc le membre DevOps un a un attribut de DevOps rouge.
Le membre deux a un attribut vert.
Ainsi, dans ce type de politique, le membre DevOps un aura un accès complet à l'environnement rouge et le membre DevOps deux
aura un accès complet à l'environnement vert, principalement en raison des attributs que vous ajoutez au niveau
de l'utilisateur et également des attributs que vous ajoutez dans le cadre du niveau de l'environnement.
Ainsi, dans cette approche, vous aurez moins d'ensembles de politiques qui seront beaucoup plus faciles à maintenir.
Cependant, l'un des aspects les plus importants et les plus critiques est celui des étiquettes.
Ainsi, les utilisateurs, l'environnement que vous créez, tout cela doit être étiqueté.
En ce qui concerne les attributs d'un utilisateur IAM, vous pouvez voir que nous en avons un dans cette capture d'écran.
L'utilisateur du collège utilisateur 101 et associé à cet utilisateur est une étiquette.
Ce tag est l'équipe comme le vert.
Cela signifie donc typiquement que si toutes les balises sont correctement définies et que les politiques sont correctes,
ce membre sera également considéré comme le membre DevOps, puisqu'il y a une équipe verte et qu'il pourra accéder
et effectuer toutes les opérations sur l'environnement vert.
Donc, avec cet ensemble de base, allons-y et révisons le contrôle d'accès basé sur les attributs d'un point de
vue général.
E back est une stratégie d'autorisation qui définit la permission sur la base d'attributs, et nous avons
appris que les attributs sont des balises en nous.
Maintenant, si vous regardez ce diagramme spécifique, je l'ai repris directement de la documentation afin
que, si vous le parcourez, il soit plus facile de le réviser.
Vous voyez donc qu'il y a trois environnements différents.
Vous avez le rouge, le jaune et le bleu et il y a différents ensembles d'utilisateurs et de clients et, associé à chaque utilisateur
et client, il y a un attribut spécifique.
Ainsi, l'utilisateur avec l'attribut rouge sera en mesure d'accéder aux ressources qui ont l'attribut rouge à nouveau, donc vous pouvez considérer comme
environnement rouge, environnement jaune, environnement bleu et ainsi de suite.
Avec cette base, nous allons faire une démonstration rapide pour comprendre comment les choses fonctionnent.
Maintenant pour la vidéo d'aujourd'hui, j'ai deux CE, deux instances.
L'un d'entre eux fait partie de l'environnement rouge.
Deuxièmement, dans le cadre de l'environnement vert pour l'instance CE deux, qui est associée à l'environnement
rouge.
Si vous regardez dans les tags, le thème ici est le rouge.
C'est donc la balise importante.
Et pour l'environnement vert, l'équipe ici est verte.
De même, dans le cadre des utilisateurs IAM, vous avez deux utilisateurs : utilisateur zéro un associé à l'équipe verte, utilisateur
zéro deux associé à l'équipe rouge.
Si nous ouvrons l'utilisateur zéro un, si vous regardez à nouveau dans les tags, il y a une même équipe de tag de vert
et pour l'utilisateur deux, vous avez une équipe de rouge.
L'idée de base est donc que si l'étiquette associée à l'utilisateur correspond à l'étiquette associée à la ressource, comme
l'exemple EC two, l'utilisateur sera en mesure d'effectuer les opérations définies dans
la politique IAM.
Maintenant, à ce stade, j'ai un groupe commun appelé groupe DevOps, et dans ce groupe vous avez les deux utilisateurs
qui sont ajoutés et si vous regardez dans la permission, il y a seulement une politique qui est associée.
Si vous examinez cette politique, en fait, laissez-moi la modifier maintenant.
Si vous regardez cette politique, vous avez une action basée sur le démarrage et l'arrêt de l'instance qui est autorisée
et vous avez une condition spécifique basée sur la balise.
Donc, ici, la clé est l'équipe.
Cela signifie donc que si l'équipe associée à l'environnement rouge EC correspond à deux reprises à celle de l'équipe associée
à l'utilisateur IAM, l'utilisateur sera en mesure d'effectuer cet ensemble d'opérations.
Alors allons-y et essayons rapidement depuis une autre fenêtre de navigateur.
Je vais me connecter rapidement à l'utilisateur qui fait partie de l'équipe verte.
Maintenant, si vous allez sur la console EC two, passons à la région appropriée.
Passons aux instances.
Là encore, l'utilisateur zéro un est associé à une équipe verte.
Maintenant, si l'utilisateur essaie d'arrêter immédiatement l'instance associée à l'équipe rouge, vous voyez que vous avez
obtenu une erreur de manière similaire.
Si l'utilisateur essaie d'arrêter l'instance associée à un environnement vert, vous voyez qu'elle fonctionne parfaitement
bien.
Très bien.
J'espère qu'avec ceci vous avez compris qu'un aperçu de haut niveau sur la façon dont une politique IAM unique basée sur les attributs
peut être beaucoup plus évolutive dans un environnement plus large, en considérant que les ressources sont correctement étiquetées.
Maintenant, avant de conclure, allons-y et supprimons manuellement la balise associée au thème du vert dans
l'environnement vert.
Facile à.
Donc je vais juste enlever cette étiquette spécifique.
L'instance est en phase d'arrêt, alors attendons rapidement un moment.
Donc, si nous rafraîchissons les instances actuellement arrêtées par l'utilisateur zéro qui avait à la fois la permission d'arrêter
l'instance et de démarrer l'instance, si cet utilisateur essaie maintenant de démarrer l'instance immédiatement, vous voyez
que l'erreur s'est produite principalement parce que les étiquettes ne correspondent pas.
Maintenant, juste pour la simplicité, j'ai également joint la capture d'écran associée à la politique IAM.
Ainsi, si vous révisez les diapositives, il devient beaucoup plus facile de comprendre comment les
politiques d'arrière-plan sont configurées.
Avant de conclure, discutons des avantages de l'airbag.
La première est que l'airbag nécessite moins de politiques, principalement parce que vous ne devez pas créer des politiques
différentes pour chaque fonction.
Vous pouvez créer une politique centrale et, en fonction des balises, les autorisations peuvent être gérées automatiquement.
Deuxièmement, les autorisations peuvent facilement être accordées et révoquées sur la base des balises des utilisateurs, comme
nous l'avons vu lorsque nous supprimons la balise associée à l'instance CE deux la permission d'y entrer.
De même, disons qu'un utilisateur de l'environnement vert ne travaille plus sur l'environnement vert.
On lui a confié d'autres responsabilités.
Ensuite, tout ce que vous aurez à faire est de supprimer la balise verte de l'environnement de l'utilisateur IM et toutes les autorisations
disparaîtront.
Enfin, la politique d'accès basée sur les attributs s'avère également très utile lorsque les utilisateurs appartiennent à un
répertoire d'entreprise tel qu'Active Directory et que vous souhaitez autoriser ou refuser
l'accès aux ressources américaines.
Voilà pour l'aperçu général.
Et c'est ainsi que se termine la vidéo d'aujourd'hui.