22 mars 2024
AWS IAM : Contrôle de l'accès aux ressources et services AWS
Pour cette entrée de blog, nous continuerons avec le même thème que dans le dernier, la sécurité sur Amazon Web Services, où nous avons donné plusieurs conseils pour l'utilisation des Security Groups d'AWS. Dans ce cas, nous parlerons d'un autre outil qu'Amazon Web Services met à notre disposition pour garantir la sécurité de notre infrastructure et de son contenu. Cette fois, nous parlerons d'AWS IAM (Identity and Access Management) qui, comme son nom l'indique, est un outil pour gérer l'accès des utilisateurs aux ressources d'Amazon Web Services. Et pour comprendre le grand potentiel de cet outil, nous devrons connaître plusieurs concepts tels que les utilisateurs, les groupes, les rôles et les politiques.
Caractéristiques des utilisateurs, groupes et rôles IAM
Les utilisateurs IAM
Ce sont des objets du compte qui permettent à un utilisateur individuel d'accéder à l'environnement AWS avec un ensemble de justificatifs. Les permissions peuvent être appliquées individuellement à un utilisateur, mais ce n'est pas recommandé, il est préférable de lier chaque utilisateur à un groupe IAM, et à ce groupe seront attribuées les permissions pour accéder aux ressources et objets d'AWS.
Les groupes IAM
Ce sont des objets qui permettent de gérer efficacement les permissions et l'accès à vos ressources sur AWS. Il est fortement recommandé d'utiliser des groupes IAM pour gérer les permissions et nécessaire dans le cas où il y a un nombre considérable d'utilisateurs ayant accès aux ressources AWS. Chaque groupe comprendra différents utilisateurs avec les mêmes permissions, dans le cas où les permissions ne sont pas explicitement attribuées directement aux utilisateurs. Utiliser des groupes IAM vous permet de bien organiser et de gagner du temps, car dans le cas où vous devez ajouter un nouvel utilisateur, l'attribution des permissions pour celui-ci sera une question de secondes puisque vous devrez simplement le lier au groupe correspondant. Une bonne pratique est de créer un groupe pour chaque département (Admins, Développeurs, etc.) car tous les membres de chaque groupe devront effectuer des tâches similaires dans l'environnement AWS.
Les rôles IAM
Ils ont des similitudes avec les groupes IAM bien qu'au lieu de fournir des permissions aux utilisateurs, les rôles servent à accorder des permissions aux instances lorsqu'elles sont créées. De cette manière, les applications qui s'exécutent sur une instance pourront utiliser ces justificatifs pour signer les requêtes, par exemple, une application qui a besoin d'accéder à un bucket S3.
Authentification Multifacteur
AWS IAM vous permet d'utiliser l'authentification multifactorielle (MFA) pour ajouter une couche de protection supplémentaire. Cela est recommandé pour les utilisateurs IAM ayant de nombreux privilèges. De cette manière, l'utilisateur, en plus de saisir son nom d'utilisateur et son mot de passe, devra effectuer une seconde authentification. Elle peut être générée par un logiciel ou par un matériel, que vous pouvez obtenir via AWS.
Politiques IAM
Les politiques IAM sont un document où sont énumérées les actions qu'un utilisateur, un groupe ou un rôle peut effectuer sur les ressources AWS. Voici quelques-unes des caractéristiques des politiques IAM :
- Ce sont des fichiers au format JSON.
- Par défaut, la permission est refusée (Deny by default)
- Dans le cas où il y a plusieurs politiques, les plus restrictives sont celles qui prévalent.
- L'ordre de priorité est le suivant :
- Premier Refus Explicite
- Deuxième Autorisation Explicite
- Refus Implicite Tiers
Le champ “Effect” est l'endroit où vous définissez s'il s'agit d'une politique de permettre ou de refuser, donc ce sont des politiques explicites, comme nous l'avons indiqué dans les caractéristiques, en cas de refus, il prévaudra sur toute autorisation qui aurait été créée.
Le champ “Action” est l'endroit où vous indiquez l'appel à l'API pour les ressources AWS. Dans ce champ, vous pouvez indiquer plusieurs actions qui doivent être séparées par une virgule. Vous pouvez également inclure toutes les actions possibles en écrivant *. Par exemple, si nous avons l'action suivante, nous indiquons qu'il sera possible de créer et de supprimer un bucket dans S3 :
“Action”:”s3:CreateBucket”,”s3:DeleteBucket”
Avec l'action suivante, nous savons que vous pourrez effectuer toute action sur S3 :
“Action”:”s3:*”
Dans le champ “Resource”, il est indiqué sur quelle ressource AWS la politique sera appliquée. Cet élément doit inclure plusieurs champs :
arn:partition:service:region:account-id:ressource
- Où “partition” est l'endroit où se trouve la ressource, il sera donc indiqué que c'est sur aws.
- En “service” sera indiqué le service mentionné, comme par exemple ec2, dynamodb ou s3.
- Pour “region”, nous indiquerons la région dans laquelle se trouve la ressource. Dans certains cas, aucune région spécifique ne sera indiquée.
- Dans le cas de “account-id”, l'ID de votre compte AWS sera mentionné, ce qui ne sera pas nécessaire pour certains services.
- Et le dernier champ est “resource” où il variera en fonction du service. Par exemple, si vous créez une politique pour S3, vous mentionnerez ici le bucket auquel vous souhaitez appliquer cette politique.
L'élément suivant “Condition” est facultatif et c'est là que seront indiquées les conditions à remplir pour que la politique s'applique.
11 pratiques recommandées pour une bonne utilisation du service IAM
Pour finir, nous vous laissons les recommandations suivantes d'Amazon Web Services :
- Créer des utilisateurs individuels pour chaque personne ayant accès aux ressources AWS.
- Gérer les permissions à travers des groupes.
- Accorder les permissions minimales à chaque groupe.
- Activer AWS CloudTrail pour extraire les logs de toutes les appels à l'API qui ont été effectués.
- Configurer une politique de mots de passe solides.
- Activer MFA (Authentification multifactorielle) pour les utilisateurs ayant des privilèges élevés.
- Utiliser les rôles IAM pour les instances EC2.
- Utiliser les rôles IAM pour l'accès partagé.
- Faire tourner les identifiants de sécurité régulièrement.
- Utiliser des conditions dans les politiques pour restreindre l'accès.
- Ne pas utiliser l'utilisateur root.
Share