Rôles, permissions, identités et groupes : comment utiliser AWS en toute sécurité et sans avoir peur de se tromper ?

Quelle est la première chose à faire dès qu’on ouvre un compte AWS ?

Tu as sûrement pensé à créer cette instance EC2 (machines virtuelles) pour monter un serveur web ou déployer ton application dans un container avec ECS (gestion de containers).

Désolé de te décevoir, mais il y a une étape moins glamour à faire avant : définir quelles personnes de notre organisation peuvent accéder à quelles ressources à l’intérieur du compte AWS.

Autrement dit, on doit se mettre dans la peau d’un agent de sécurité, qui tient le registre des accès et des permissions dont disposent les membres de l’organisation.

Dans ce guide, on va apprendre à définir ces permissions et mettre en place une politique de sécurité propre et scalable dès le départ. On y va !

Pourquoi une politique de contrôle d’accès est-elle nécessaire ?

La réponse est sans doute évidente quand il s’agit d’une organisation avec des dizaines de développeurs et d’applications qui interagissent avec nos services dans le cloud. Mais le contrôle d’accès est aussi nécessaire pour des projets en solo, pour deux raisons :

1. Il est très possible que ton projet soit le résultat de la combinaison de nombreux services au sein d’AWS (stockage, calcul, bases de données, networking, etc.). Ces services vont interagir entre eux, donc il est recommandé que des permissions soient associées à chaque service.

Par exemple, on peut exécuter un processus sur une instance EC2 qui lit les fichiers déposés sur S3, leur applique une transformation, puis insère des données dans une base RDS. Dans ce cas, notre instance EC2 doit avoir des permissions de lecture sur S3 et des permissions d’écriture sur RDS. Si ces permissions ne sont pas correctement configurées, tout le processus décrit ci-dessus ne s’exécutera pas correctement.

2. La scalabilité. Si ton projet a du succès (et j’espère que oui), il sera inévitable que plus de personnes mettent la main sur le compte AWS. Le cas échéant, il deviendra indispensable d’avoir une bonne politique de permissions.

En reprenant l’exemple précédent, tu auras sûrement un administrateur de base de données qui aura évidemment besoin d’accès à RDS. Cependant, cette personne n’a pas forcément besoin de permissions sur EC2 (si on continue à utiliser ce service) ni sur S3.

Service IAM

Dans AWS, il existe un service pour tout. Parmi eux, il y en a un dédié à l’administration des permissions au sein du compte. Bienvenue à IAM (Identity and Access Management).

Pour le comprendre, il faut d’abord expliquer les entités qui composent IAM :

• Politique : c’est un ensemble de permissions qui définissent ce qu’on peut faire ou non sur chaque service d’AWS.
• Utilisateur : c’est une entité créée dans AWS pour représenter la personne ou l’application qu’on utilise pour interagir avec les services AWS.
• Groupe : c’est un ensemble d’utilisateurs.
• Rôle : un rôle est un ensemble de politiques qu’on peut assigner à un utilisateur (personne ou application) ou à un service.

Passons à l’action

Maintenant qu’on comprend les principaux concepts du service IAM, voyons comment créer un utilisateur et lui assigner des permissions spécifiques pour travailler uniquement sur certains services. C’est parti !

Création d’un utilisateur IAM

Pour commencer, on doit être connecté en tant qu’utilisateur root, c’est-à-dire le « propriétaire » du compte AWS.

Avant d’avancer, tu te demandes sûrement pourquoi créer un autre utilisateur et ne pas travailler directement avec le root ?

La réponse est simple : pour éviter de faire une bêtise. Rappelons-nous que l’utilisateur root a la permission de faire absolument TOUT dans le compte AWS. Et comme disait l’oncle Ben, « un grand pouvoir implique de grandes responsabilités ».

L’utilisateur root pourrait tranquillement supprimer des processus, éteindre des instances, effacer des buckets entiers avec des données importantes, entre autres choses.

C’est pour cela qu’il est recommandé de créer des utilisateurs avec moins de privilèges et d’opérer avec eux au lieu d’utiliser le root. Ce dernier ne doit être employé que pour des cas ponctuels.

Cela dit, on va se connecter à AWS avec notre compte root et chercher le service IAM.

Ici, on observe les 4 acteurs mentionnés précédemment : groupes, utilisateurs, rôles et politiques. Sur ce compte en particulier, 4 êtres humains travaillent (moi inclus) et chacun a 1 utilisateur. Cela signifie que quand je me mets à travailler sur le compte AWS, je le fais avec mon utilisateur (Dario) et non avec le root. Jetons un œil aux utilisateurs :

On voit que tous les utilisateurs appartiennent à un groupe nommé Admins. Dans cet exercice, on va créer un autre utilisateur nommé Emilia et on l’ajoutera à un nouveau groupe qui sera Developers.

On commence par cliquer sur le bouton « Ajouter des utilisateurs ».

Ensuite, la fenêtre suivante apparaît :

On y complète avec le nom souhaité (Emilia par exemple).

On voit qu’il faut sélectionner le type d’identifiants AWS. Voyons à quoi sert chacun :

• Le premier sert pour des utilisateurs applicatifs (en clair, une application) et se compose d’un identifiant (clé d’accès) et d’un mot de passe (clé d’accès secrète). Cela signifie que quand l’application aura besoin d’accéder à des services de notre compte AWS, elle devra « se connecter » avec ces identifiants.
• Le second est la méthode d’authentification classique composée d’un identifiant et d’un mot de passe qu’on utilise nous, les humains, pour accéder à n’importe quel service. Comme on crée un nouvel utilisateur qui sera un humain, on choisira la deuxième option. On doit aussi y générer le mot de passe.

On peut le définir nous-mêmes à la main ou laisser AWS le générer automatiquement. Enfin, si on clique sur l’option « Exiger la réinitialisation du mot de passe », on peut faire en sorte que lorsque l’utilisateur se connecte, il soit forcé de changer ce mot de passe qu’on a choisi (TRÈS recommandé).

L’étape suivante consiste à choisir le groupe pour notre nouvel utilisateur. On peut choisir un groupe existant ou en créer un nouveau.

Comme on l’a dit précédemment, on va créer un nouveau groupe nommé Developers. On clique sur Créer un groupe.

Une nouvelle fenêtre s’ouvre où on nous demande le nom du groupe et les politiques qu’on veut associer à ce groupe. Rappelons que ces politiques (ou ensemble de permissions) sont celles qui auront un impact sur les utilisateurs de ce groupe.

Bien qu’on puisse créer nos propres politiques personnalisées (sujet pour un autre tutoriel), on va pour l’instant utiliser les politiques « toutes faites » que nous fournit IAM. Pour des raisons pratiques, on va faire comme si ce groupe travaillait uniquement sur le service EC2. On lui assignera donc la politique AmazonEC2FullAccess. On sélectionne et on clique sur Créer un groupe.

Félicitations ! Tu as créé un groupe personnalisé avec ses permissions respectives pour travailler dans AWS.

L’étape suivante de ce tutoriel concerne les étiquettes : une fonctionnalité qui permet de stocker des informations supplémentaires sur l’utilisateur au format clé-valeur. Quelques exemples :

• email: emilia@deployr.ai
• role: backend_dev
• team: data_platform

Ici on te laisse utiliser ta créativité et définir les étiquettes que tu veux.

La dernière étape de ce tutoriel (enfin) est simplement de réviser les étapes précédentes et de cliquer sur Créer un utilisateur.

Félicitations ! Tu as créé un nouvel utilisateur pour ton organisation de manière sécurisée et propre.

Conclusion

Dans ce tutoriel, on a appris à créer et administrer des utilisateurs de manière sécurisée pour notre compte AWS grâce au service IAM.

Ce qu’on vient de faire peut être reproduit et complexifié autant qu’on le veut ou que l’organisation l’exige. Cependant, le simple fait de suivre ces étapes est largement suffisant pour démarrer.