IAM vous permet d'accorder un accès géré à vos ressources AWS à vos employés, aux services AWS et aux programmes exécutés sur des serveurs distants. Les groupes IAM sont un outil d'organisation utile qui vous permet de définir des autorisations pour plusieurs utilisateurs à la fois.

Outils d’organisation d’IAM

Tout d'abord, une brève description des différents outils d'IAM:

Les stratégies IAM regroupent les autorisations individuelles pour former un objet cohérent qui peut être appliqué aux utilisateurs, aux rôles et aux groupes. Par exemple, vous pouvez créer une stratégie qui autorise l'accès pour placer des objets dans un ensemble spécifique de compartiments S3.

Les utilisateurs IAM disposent de clés d'accès ou de mots de passe qui leur permettent d'accéder aux services AWS à partir de l'interface de ligne de commande, de l'API ou de la console de gestion. Cela permet aux employés de pouvoir accéder aux ressources AWS depuis l'extérieur de votre compte AWS. Ils peuvent avoir des stratégies attachées à leur compte, ce qui leur donne des autorisations.

Les rôles IAM sont similaires à ceux des utilisateurs, mais ne sont fournis avec aucune clé d'accès. Ceux-ci sont utilisés pour donner à d'autres services AWS l'autorisation d'utiliser vos ressources et ne donnent pas accès à l'API ou à la CLI à quiconque en dehors de votre compte. Par exemple, vous pouvez attribuer à une instance EC2 un rôle qui lui permet d'accéder à S3, et comme elle s'exécute déjà dans votre compte AWS, elle peut agir en tant que rôle sans nécessiter de clés d'accès.

AWS Organizations est un outil spécial qui vous permet de diviser votre compte AWS racine en quatre sous-comptes différents avec une facturation et un contrôle centralisés. Bien que techniquement sans rapport avec IAM, cela vous permet de séparer complètement les environnements de développement, de test, de préparation et de production, ce qui peut vous permettre d'accorder des autorisations IAM plus laxistes aux employés travaillant uniquement dans l'environnement de développement.

Les groupes IAM sont ce dont nous discuterons aujourd'hui. Cet outil vous permet d'attacher plusieurs stratégies à un groupe et d'ajouter des utilisateurs à ce groupe, qui recevront les mêmes stratégies que le groupe. C’est un excellent outil organisationnel et essentiel pour suivre plusieurs utilisateurs.

Comment travailler avec des groupes

Les groupes vous permettent de distinguer différentes catégories d'employés avec des autorisations différentes. Par exemple, disons que vous avez une équipe de développeurs de logiciels et une équipe d'ingénieurs QA. Les deux ont des exigences différentes et, à ce titre, ont besoin d'autorisations différentes. Les définir sur le groupe vous permet de configurer facilement de nouveaux employés avec accès ou de déplacer des utilisateurs entre les équipes lorsque le besoin s'en fait sentir.

Créez un nouveau groupe à partir de l'onglet "Groupes" du Console de gestion IAM.

Donnez-lui un nom et joignez les politiques que vous souhaitez. Les groupes peuvent être associés à un maximum de 10 règles. Vous souhaiterez donc probablement créer une ou deux règles personnalisées pour ce groupe. Vous pouvez également ajouter des politiques en ligne directement au groupe, mais nous vous conseillons d'utiliser une politique régulière pour que tout reste en ordre.

Cliquez sur "Créer", et c'est toute la configuration requise. Vous pouvez ajouter un nouvel utilisateur au groupe à partir de l'onglet "Utilisateurs" du groupe:

Ou, si vous automatisez votre processus d'intégration, vous pouvez le faire à partir de la ligne de commande avec:

aws iam add-user-to-group - nom-de-groupe  --Nom d'utilisateur 

Cela ajoutera les autorisations du groupe aux autorisations actuelles de l'utilisateur dans une catégorie distincte. Si vous supprimez l'utilisateur du groupe, les autorisations du groupe ne s'appliquent plus.

Vous ne pouvez pas créer de sous-groupes, mais les utilisateurs peuvent être inclus dans plusieurs groupes à la fois. Dans cet esprit, vous pouvez créer un groupe «Développeurs» qui attribue des autorisations de base et un groupe «Développeurs seniors» qui donne plus d'autorisations, puis les attribuer tous les deux à un employé pour leur donner les deux ensembles d'autorisations.

Les groupes ne remplacent pas les autorisations

Dans IAM, il est impossible pour une autorisation de "remplacer" une autre autorisation. Par défaut, tout est refusé implicitement et un utilisateur n'aura accès qu'aux services explicitement autorisés par une stratégie d'autorisations. Vous pouvez également choisir de nier explicitement autorisations à un utilisateur. Ces autorisations auront toujours la priorité sur toute autre autorisation, qu'elle provienne ou non d'un utilisateur ou d'un groupe.

Lorsque vous créez un groupe, toutes les autorisations des groupes interagissent avec les autorisations utilisateur de la même manière qu'elles le feraient si elles étaient directement associées à l'utilisateur. Il n'y a pas de hiérarchie.

Par exemple, nous allons créer un utilisateur test et joindre le AWSDenyAll politique directement à lui. Nous allons également créer un groupe, joindre le AdministrateurAccès l'autorisation à ce groupe et ajoutez l'utilisateur à ce groupe.

À partir du simulateur de stratégie IAM, tout apparaît comme explicitement refusé en raison de la présence du AWSDenyAll politique. Si nous changeons les choses et mettons la stratégie Refuser sur le groupe et la stratégie Autoriser directement sur l'utilisateur, la même chose se produit. Refuser remplacera toujours Autoriser.

Une forme plus utile de ceci est les limites des autorisations. Plutôt que de refuser explicitement tout ce que vous ne voulez pas qu’un utilisateur puisse faire même si le groupe le dit, vous pouvez à la place définir une stratégie comme limite d’autorisation. Cela prévaudra sur toutes les autres autorisations attachées à l'utilisateur, à la fois des groupes et directement, et n'autorisera rien que la limite des autorisations n'autorise également.

Cela fonctionne essentiellement comme un diagramme de Venn des autorisations et autorise uniquement les actions qui chevauchent à la fois les autorisations explicitement autorisées des stratégies attachées et la limite des autorisations.