Peut être l’avez-vous remarqué, mais depuis le début de ce cours nous avons créé des serveurs EC2, des bases de données, et même déposé des fichiers dans S3, grâce au seul compte créé au début.
Que se passe-t-il lorsque vous avez une équipe de 5 personnes qui doit administrer différents services AWS ? Quid d’une équipe de 1 000 personnes ?
Eh non, partager votre mot de passe n’est pas une solution viable, vous êtes avant tout le seul et unique administrateur !
Pour permettre à plusieurs équipes de manipuler chacune ses services et ressources de manière sécurisée, AWS a mis en place le service d’identification des gestion des accès (IAM).
IAM est le service central dans AWS responsable de l’identification et l’autorisation des utilisateurs, groupes et rôles. Avant d’autoriser une action sur une ressource, par exemple la création d’un bucket, AWS va interroger IAM pour s’assurer que l’action est bien permise. C’est le centre névralgique de la sécurité sur AWS.
Découvrons ce service en détail.
Prenez en main IAM
Pour accéder au service IAM, passez directement par la barre de recherche, maintenant que vous êtes plus familier avec la console AWS :
Vous arrivez sur le tableau de bord d’IAM, et là vous vous prenez un premier carton rouge sécurité !
Au secours, mais qu’est ce qu’ils veulent encore ? Et qu’est-ce qu’un utilisateur racine ?
L’utilisateur racine est attaché à l’e-mail que vous avez utilisé pour créer le compte AWS. Cet utilisateur dispose de tous les droits sur tous les services. Vous comprenez qu’AWS vous pousse à activer l’authentification double facteur (MFA) ! Vous savez, ces codes que vous recevez par SMS, des fois ?
Dans le menu à gauche, nous retrouvons de manière assez classique les menus du service IAM :
Trois menus sont particulièrement intéressants :
Utilisateurs : créer, gérer et supprimer les utilisateurs ayant accès aux services AWS.
Rôles : ce sont des entités qui disposent d’autorisations et qui peuvent être endossées par des ressources AWS. Par exemple, nous pouvons créer un rôle qui peut déposer des fichiers sur S3, autoriser une machine EC2 à l’endosser, et ainsi hériter de ses autorisations !
Politiques : ce sont les autorisations assignées à chaque utilisateur dans AWS. Un administrateur système par exemple doit pouvoir intervenir sur le service EC2, mais n’a pas vocation à modifier le système de facturation ou encore les buckets S3. Les autorisations permettent d’avoir cette granularité et encore plus, comme nous allons le voir.
Essayons à présent de créer notre premier utilisateur IAM.
Créez vos premiers utilisateurs
De la même manière que personne n'est censé utiliser le compte root sur une machine Linux, l’utilisation du compte racine sur AWS est à limiter au maximum. Nous allons donc créer un utilisateur dédié pour notre nouveau collègue, Bob !
Rendez-vous dans IAM, section "Utilisateurs". Cliquez sur "Ajouter des utilisateurs" :
Choisissez un nom d’utilisateur, par exemple Bob, puis sélectionnez le type d’accès que vous souhaitez lui accorder.
Nous allons opter pour un accès via la console de gestion AWS, la même que nous utilisons depuis le début. Cochez donc la case “Mot de passe”, et cliquez sur Suivant.
On vous demande ensuite de définir les droits d’accès de cet utilisateur. Supposons que Bob ait besoin de gérer tous les buckets dans le service S3.
Il existe déjà des autorisations prédéfinies par AWS qui permettent d’octroyer ce privilège. Cliquez sur “Attacher directement les stratégies existantes”, et cherchez “s3FullAccess”.
Sélectionnez la stratégie “AmazonS3FullAccess”. Ceci donnera à Bob le droit de tout faire sur S3 : créer des buckets, déposer des fichiers, les supprimer, etc.
Cliquez sur Suivant pour définir les balises. Cela permet de labelliser les utilisateurs si besoin. Vous pouvez laisser tel quel, puis cliquez sur Vérifications pour arriver à l’écran récapitulatif.
Si tout est OK, cliquez sur “Créer un utilisateur”.
Bravo, votre utilisateur est créé. Notez l’adresse de connexion à la console AWS. C’est ce qu’il faudra communiquer à Bob en plus du mot de passe, afin qu’il puisse accéder à votre console AWS.
Lors de sa première connexion, Bob sera invité à changer de mot de passe. Une fois sur la console, il pourra manipuler le service S3 dans votre compte AWS à sa guise.
Cependant, s’il essaie d’accéder à un autre service, EC2 par exemple, il recevra des erreurs.
C’est clairement mieux que de lui partager le compte root. On gagne en traçabilité des accès, on limite les accès de Bob à S3 (il ne pourra pas créer des serveurs, par exemple). Mais est-ce assez granulaire ?
Et si on voulait que Bob ne puisse lire que le bucket mateotestbucket, et pas le bucket monbucketsecret. Comment pourrait-on faire cela ?
La réponse est, vous l’aurez devinez, les politiques IAM.
Configurez les politiques IAM
Si vous allez dans le menu “Utilisateurs” du service IAM et que vous cliquez sur Bob, vous verrez qu’il dispose d’une politique IAM appelée “AmazonS3FullAccess” qui lui confère, à priori, tous les droits sur S3.
C’est ce que l’on appelle une politique “gérée par AWS”. Nous ne l’avons pas créée, elle est de base présente dans le compte, et permet de rapidement attribuer des droits aux utilisateurs.
Si vous cliquez dessus, vous verrez qu’elle donne accès à deux services : S3, et S3 Object Lambda que l’on va gentiment ignorer à ce stade :
Cliquez sur “S3” pour avoir l’ensemble des actions implicitement autorisées par cette politique :
Oui oui ce n’est pas une typo, il y a bien 128 actions possibles (à date) sur le service S3. EC2 en a quelque 400 de son côté, et ainsi de suite. Ne fermez pas la console IAM tout de suite. Vous verrez que dans la plupart des services, il existe 3-4 actions clés à connaître qui reviennent assez souvent.
Essayons de créer notre propre politique IAM qui limitera Bob aux seules actions de lecture sur Amazon S3. Il pourra lister les buckets, lire les fichiers, mais pas les créer.
Rendez-vous dans le menu “Politiques”, ignorez les centaines de politiques gérées par Amazon et cliquez sur “Créer une stratégie”.
Vous arrivez sur le menu de création d’une politique IAM.
Choisissez le service S3, puis cochez les niveaux d’accès “Liste” et “Lire”. Ces derniers attribuent implicitement les actions nécessaires pour lister les fichiers dans le bucket, les télécharger, et ainsi de suite.
On souhaite limiter l’accès à une seule ressource, en l’occurrence un bucket S3, donc déroulez le sous-menu “Ressources” et renseignez le nom du bucket (1) ainsi que les noms des objets (2).
Cliquez sur le bouton “Ajouter un ARN” dans la ressource “bucket”, puis renseignez le nom “mateotestbucket”.
Un ARN est un identifiant unique d’une ressource dans AWS.
Ensuite, cliquez sur le bouton “Ajouter un ARN” dans la ressource “Objets”, puis renseignez le nom “mateotestbucket” et cochez “Tout” les objets.
Bob pourra en effet lister et lire tous les objets du bucket mateotestbucket.
Cliquez sur “Suivant” jusqu’à arriver au menu de définition du nom de la politique.
On va l’appeler s3-mateotestbucket-lecture-seule. Cliquez ensuite sur “Créer une stratégie".
Voilà, notre stratégie personnalisée est créée. Elle n’est toujours pas en vigueur toutefois. Il faut l’attacher à l’utilisateur Bob.
Pour attacher cette politique à l’utilisateur, choisissez-la puis cliquez sur “Actions”, “Attacher”.
Cochez l’utilisateur Bob puis cliquez sur “Attacher une stratégie”.
Si vous vous rendez sur le menu “Utilisateurs” et que vous affichez le détail de l’utilisateur Bob, vous verrez la nouvelle politique s3-mateotestbucket-lecture-seule attachée :
Vous pouvez détacher l’ancienne politique AmazonS3FullAccess en cliquant sur la croix à droite, maintenant que vous avez créé une politique plus restrictive et adaptée aux fonctions de Bob.
Si Bob tente d’accéder à votre bucket monbucketsecret via la console S3, il verra le message d’erreur suivant :
En résumé
IAM est le service de gestion des identités et autorisations sur AWS.
L'utilisateur racine ne doit être utilisé que dans des cas exceptionnels (ex. : escalade au support).
Une politique IAM est un ensemble de permissions attachées à un utilisateur, un groupe ou un rôle, qui lui permettent d'effectuer certaines actions sur des services AWS.
Les politiques IAM prédéfinies par AWS permettent de limiter facilement les droits des utilisateurs. Toutefois, pour une meilleure précision et une meilleure sécurité, les politiques personnalisées sont plus adaptées.
Maintenant que nous savons comment protéger nos ressources sur AWS, nous avons toutes les clés en main pour aborder le sujet des droits d’accès sur S3.
