Quelles permissions donner à un nouvel employé dans AWS (et lesquelles non)

Quelqu'un de nouveau entre dans l'entreprise et a besoin d'un « accès à AWS ». Le plus rapide est de créer un utilisateur, de lui donner AdministratorAccess et de passer à autre chose. C'est aussi ce qui transforme l'erreur d'un stagiaire, ou un mot de passe volé, en un compte vidé ou en une facture de plusieurs milliers d'euros. Presque toutes les mauvaises surprises avec AWS dans les petites entreprises commencent avec quelqu'un qui avait bien plus de permissions que nécessaire.

La règle est simple : chaque personne ne peut faire que ce dont elle a besoin pour son travail, et rien de plus. Cela s'appelle le moindre privilège et n'exige pas de s'y connaître en sécurité. Cela exige de réfléchir une minute à ce que va faire cette personne : regarder ? allumer et éteindre des machines ? créer et supprimer des choses ? Avec cette réponse, AWS a déjà les permissions prêtes et il n'y a qu'à les choisir.

Ce guide utilise des groupes au lieu de donner des permissions à chaque utilisateur un par un. C'est la différence entre décider une fois par fonction et décider à chaque fois que quelqu'un arrive.

Pas à pas

1. Décidez quelle fonction a la personne

   Avant de toucher à la console, répondez à une question : que doit faire cette personne dans AWS ? Pour une petite entreprise, presque tout rentre dans trois fonctions :

   • Voir : regarder l'état des machines, consulter la facture, lire les journaux. C'est ce dont a besoin la personne qui fait le support, celle qui tient les comptes ou un responsable qui veut « voir où ça en est ».
   • Opérer : en plus de voir, allumer, éteindre et redémarrer des machines, faire des instantanés, restaurer. C'est ce dont a besoin la personne qui gère le serveur au quotidien.
   • Administrer : créer et supprimer des machines, changer les réseaux, gérer les utilisateurs. Seules une ou deux personnes en ont besoin, et ce devraient être celles qui s'y connaissent le plus.

   Si vous hésitez entre deux, commencez par celle qui a le moins de permissions. Monter est un clic ; découvrir que quelqu'un a supprimé ce qu'il ne fallait pas, non.

2. Créez les trois groupes dans IAM

   Ouvrez IAM, menu de gauche Groupes d'utilisateurs, bouton Créer un groupe. Faites-en trois, avec des noms que n'importe qui comprend : ver, operar et administrar. En créant chaque groupe, dans le bloc Attacher des politiques d'autorisation, cherchez et cochez la politique qui lui revient :

   • Groupe ver : ReadOnlyAccess. Permet de consulter n'importe quel service sans rien changer. Si vous voulez seulement qu'ils voient la facture, il existe AWSBillingReadOnlyAccess, plus limitée.
   • Groupe operar : ReadOnlyAccess et en plus une politique à vous avec les actions de démarrer, arrêter et redémarrer (étape suivante). Pour Lightsail, il n'y a pas de politique gérée intermédiaire, donc c'est vous qui l'écrirez ; pour EC2, il n'y en a pas non plus qui se limite à allumer et éteindre.
   • Groupe administrar : PowerUserAccess, qui permet presque tout sauf gérer les utilisateurs et les permissions. Réservez AdministratorAccess à une seule personne, celle qui garde aussi le compte racine.

   Les groupes se créent une fois. Ensuite, donner accès à quelqu'un, c'est le mettre dans le bon groupe.

3. Écrivez la politique du groupe « operar »

   Dans IAM, Politiques, Créer une politique. Cliquez sur l'onglet JSON et collez ceci, qui permet d'allumer, d'éteindre et de redémarrer des machines Lightsail et EC2, et de faire des instantanés, mais pas de créer ni de supprimer des machines :

   {
     "Version": "2012-10-17",
     "Statement": [
       { "Effect": "Allow", "Action": [
           "lightsail:StartInstance", "lightsail:StopInstance", "lightsail:RebootInstance",
           "lightsail:CreateInstanceSnapshot",
           "ec2:StartInstances", "ec2:StopInstances", "ec2:RebootInstances",
           "ec2:CreateSnapshot"
         ], "Resource": "*" }
     ]
   }

   Cliquez sur Suivant, nommez-la operar-maquinas et créez-la. Ensuite, dans Groupes d'utilisateurs, entrez dans operar, onglet Autorisations, Ajouter des autorisations, Attacher des politiques, et cochez operar-maquinas.

   Remarquez qu'aucune action avec « Delete » ni « Terminate » n'apparaît. C'est la différence entre pouvoir éteindre une machine et pouvoir la faire disparaître. Si vous voulez en plus limiter à certaines machines, dans Resource vous pouvez mettre l'identifiant de chacune à la place de l'astérisque ; pour EC2 c'est simple, pour Lightsail il faut utiliser l'ARN de chaque instance.

4. Créez l'utilisateur et mettez-le dans un groupe

   IAM, Utilisateurs, Créer un utilisateur. Nom : celui de la personne (maria.lopez), jamais quelque chose de partagé comme soporte. Cochez Fournir aux utilisateurs l'accès à la console de gestion AWS, choisissez Je veux créer un utilisateur IAM et laissez coché que l'utilisateur doit changer son mot de passe à la prochaine connexion.

   Sur l'écran des permissions, choisissez Ajouter l'utilisateur au groupe et cochez seulement le groupe décidé à l'étape 1. N'attachez pas de politiques directement à l'utilisateur : dans six mois, personne ne se souviendra pourquoi il a cette permission isolée. Créez l'utilisateur et notez l'adresse de connexion (elle contient le numéro de votre compte) pour la lui envoyer avec le mot de passe temporaire par des canaux différents : l'adresse par e-mail, le mot de passe en personne ou par un message qui expire.

   Si la personne ne va pas utiliser de programmes qui parlent à AWS, ne créez pas de clés d'accès. On pourra les ajouter le jour où elles seront nécessaires.

5. Rendez la double authentification obligatoire

   Demandez à la personne, lors de sa première connexion, d'aller dans le menu de son nom, Informations d'identification de sécurité, et d'assigner un dispositif MFA avec l'application du téléphone. Mais ne le laissez pas à la bonne volonté : dans IAM, Politiques, créez une politique qui refuse tout sauf la configuration du MFA quand l'utilisateur n'est pas entré avec la double authentification, et attachez-la aux trois groupes. AWS la fournit en exemple dans sa documentation sous le nom « permettre aux utilisateurs de gérer leur propre MFA » ; copiez le JSON tel quel.

   L'effet : qui entre sans MFA ne voit que l'écran pour l'activer. Tout le reste apparaît bloqué jusqu'à ce qu'il le fasse. C'est la seule façon que tout le monde l'ait vraiment.

6. Vérifiez ce que personne ne doit avoir

   Avant de considérer l'arrivée comme terminée, repassez dans IAM, Utilisateurs, colonne des politiques attachées :

   • AdministratorAccess sur plus d'une ou deux personnes : c'est de trop. Personne qui ne fait qu'opérer des machines n'en a besoin.
   • IAMFullAccess chez quelqu'un qui ne gère pas les utilisateurs : avec cette permission, il peut s'en donner n'importe quelle autre.
   • Des permissions attachées directement à l'utilisateur au lieu de passer par les groupes : déplacez-les vers le groupe ou supprimez-les.
   • Des clés d'accès sur des utilisateurs de personnes qui ne programment rien.

   Si vous trouvez l'un de ces cas chez des utilisateurs anciens, profitez-en pour le corriger. C'est le moment où c'est le plus facile.

7. Préparez le départ dès le premier jour

   Le jour où quelqu'un part, son accès à AWS doit disparaître le jour même, avant qu'il ne rende l'ordinateur. Dans IAM, Utilisateurs, sélectionnez l'utilisateur : d'abord désactivez l'accès à la console et les clés d'accès (onglet Informations d'identification de sécurité), attendez une ou deux semaines pour vérifier que rien ne dépendait de cette personne, puis supprimez l'utilisateur.

   Notez-le dans la liste des tâches de départ avec l'e-mail et les clés du bureau. Et une fois par trimestre, téléchargez le Rapport d'informations d'identification d'IAM : il vous dit pour chaque utilisateur quand il s'est connecté pour la dernière fois, s'il a le MFA et si ses clés sont utilisées. Un utilisateur qui ne s'est pas connecté depuis trois mois est un utilisateur qui ne devrait probablement plus exister.

Ce qui peut mal tourner