Les fondamentaux

IAM : gestion des identités et des accès

Se connecter à la console AWS

Dès votre arrivée dans la console, IAM devient votre point d’ancrage en matière de sécurité. Vous modélisez d’abord les entités : les utilisateurs représentent les personnes ou applications nécessitant un accès direct, tandis que les rôles correspondent à des identités temporaires que l’on « endosse » pour exécuter une tâche précise, sans stocker de clés longue durée. Plutôt que d’attribuer arbitrairement des droits d’administrateur, vous créez des politiques JSON qui spécifient exactement les actions autorisées, par exemple parcourir un bucket S3 ou démarrer une instance EC2 et vous associez ces politiques aux groupes d’utilisateurs ou aux rôles adaptés.

Pour renforcer la protection, vous privilégiez systématiquement les clés d’accès temporaires délivrées par AWS STS, qui en lieu et place des clés IAM à longue durée de vie : ces jetons ne restent valables que quelques minutes ou quelques heures seulement. Vous imposerez également le MFA sur les comptes sensibles, notamment le root et tous...

AWS Organizations et SCP : organiser plusieurs comptes efficacement

À mesure que votre usage d’AWS grandit, concentrer tous vos projets dans un seul compte finit par devenir ingérable. Entre les environnements de développement, de test, de production et les services transverses tels que la journalisation ou la sécurité, il devient impossible de séparer clairement qui dépense quoi et qui accède à quelles ressources. C’est pourquoi AWS met à disposition AWS Organizations, un service qui vous permet de regrouper plusieurs comptes sous une même entité, chacune structurée par des Unités Organisationnelles (OU) et protégée par des Service Control Policies (SCP). Le schéma ci-après illustre la mise en place typique : un compte de management en haut, suivi des OU « Development », « Test » et « Production », chacune hébergeant plusieurs comptes enfants, et chaque OU soumise à une SCP spécifique.

Infrastructure as Code : pourquoi automatiser plutôt que cliquer

À la naissance d’AWS, la création d’un serveur web demandait à peine plus qu’un clic sur « Launch Instance » dans la console. Cette simplicité, en apparence libératrice, cache un piège : dès que l’on répète l’opération dans trois régions, cinq environnements et une dizaine de comptes, la console se transforme en labyrinthe. On oublie un tag « Owner » ici, on ouvre inopinément le port 22 au monde-là, et l’on se retrouve sans moyen simple de refaire à l’identique ce que l’on vient de déployer à la main. C’est pour briser ce cycle que l’Infrastructure as Code, ou IaC, a vu le jour. L’idée est de prendre les « clics » que nous effectuons dans l’interface graphique, de les transformer en fichiers texte décrivant l’état voulu de l’infrastructure, puis de confier à un moteur d’orchestration le soin de matérialiser cet état.

Une définition d’IaC tient en trois points : d’abord, chaque ressource (VPC, bucket S3, rôle IAM, cluster EKS) existe sous la forme d’une déclaration lisible, versionnable et comparable d’une version à l’autre (un simple diff suffit à visualiser les modifications) comme n’importe quel fichier source. Ensuite, tout déploiement se fait selon le modèle « plan / apply » : on compare le monde désiré (décrit dans le code) au monde réel, et l’outil génère la liste des changements nécessaires avant de les appliquer. Enfin, toute...

Sécurité et conformité : établir des bases solides

Après avoir décrit votre infrastructure en code et distribué vos ressources dans plusieurs comptes bien gouvernés, il reste à verrouiller l’ensemble : c’est la mission de la sécurité et de la conformité. Sur AWS, ces deux sujets se nourrissent l’un de l’autre : la conformité impose un niveau de sécurité mesurable ; la sécurité fournit les preuves nécessaires à vos audits. L’objectif n’est pas seulement de cocher des cases SOC 2 ou ISO 27001, mais d’empêcher un incident avant qu’il ne se transforme en crise de confiance.