Les fondamentaux du cloud computing
La gestion des identités et des accès (IAM)
Comment le cloud confirme qui vous êtes, décide ce que vous avez le droit de faire, et les pratiques, rôles, moindre privilège et MFA, qui empêchent un identifiant volé de devenir une compromission totale du compte.
- Distinguer l'authentification de l'autorisation et expliquer pourquoi une plateforme cloud vérifie les deux à chaque requête
- Comparer les utilisateurs IAM, les groupes et les rôles, et identifier quand utiliser chacun
- Appliquer le principe du moindre privilège à un scénario de politique d'accès
- Expliquer pourquoi les identifiants temporaires d'un rôle sont préférés aux clés d'accès à long terme
- Identifier l'authentification multifacteur comme une défense contre le vol d'identifiants, pas contre la faiblesse d'un mot de passe
Un mot de passe pour tout un compte
Une PME donne le mot de passe du compte root AWS à toute son équipe technique, pour que personne n'attende après le service informatique pour obtenir un accès. Pendant des mois, rien ne se passe mal. Puis un ordinateur portable, avec ce mot de passe enregistré dans le navigateur, disparaît d'un café. Quiconque le récupère peut désormais lancer des instances, lire chaque fichier stocké, supprimer chaque sauvegarde et modifier les informations de facturation, parce que l'utilisateur racine ne connaît aucune limite.
La gestion des identités et des accès existe pour réduire ce scénario à presque rien. Au lieu d'un seul identifiant partagé et tout-puissant, IAM permet à une équipe de donner à chaque personne et à chaque application sa propre identité, limitée exactement à ce dont elle a besoin. Un ordinateur volé n'expose alors plus qu'une tranche étroite du compte, jamais la totalité.
Utilisateur racine, utilisateurs IAM et rôles
Chaque compte AWS démarre avec un seul utilisateur racine, créé automatiquement, avec un accès total à tout. La documentation d'AWS est directe sur ce point : ne l'utilisez jamais pour les tâches courantes, mettez ses identifiants de côté, et créez d'autres identités pour le travail réel.
Deux de ces identités comptent le plus. Un utilisateur IAM est une identité durable, en général celle d'une personne ou d'une application qui a besoin d'un accès permanent, avec des identifiants qui restent valides jusqu'à ce que quelqu'un les fasse tourner ou les révoque. Un rôle fonctionne autrement : c'est une identité sans identifiants propres, assumée temporairement par un utilisateur, une application ou un service AWS, qui reçoit des identifiants de courte durée expirant automatiquement. Les pratiques actuelles poussent fortement vers les rôles, justement parce qu'il n'y a rien de durable à faire fuiter.
Deux vérifications distinctes : authentification puis autorisation
Un développeur se connecte avec un mot de passe et un code MFA, puis demande à lancer une nouvelle machine virtuelle. AWS effectue deux vérifications distinctes, dans cet ordre, jamais une seule vérification combinée.
D'abord l'authentification : ce mot de passe et ce code MFA correspondent-ils à une identité réelle, reconnue par ce compte ? Si oui, l'identité est confirmée. Ensuite, séparément, l'autorisation : la politique attachée à cette identité confirmée autorise-t-elle réellement le lancement d'une instance ? Un utilisateur peut réussir parfaitement l'authentification, avec un mot de passe correct et un code MFA valide, et se voir quand même refuser l'action à l'étape d'autorisation si sa politique ne l'accorde pas. Les deux vérifications protègent contre des échecs différents : un mot de passe volé met en échec l'authentification, tandis qu'une politique trop large met en échec l'autorisation, même quand l'authentification fonctionne exactement comme prévu.
Le principe du moindre privilège
Imaginez qu'un développeur n'a besoin de lire des fichiers que dans un seul bucket de rapports, rien d'autre. Une politique de moindre privilège accorde exactement cela : l'action s3:GetObject, limitée à ce seul bucket, pas plus. Comparez avec une politique large qui accorde un accès complet à S3 « pour être tranquille » : si les identifiants de ce rôle sont un jour détournés, la politique étroite limite les dégâts à la lecture d'un seul bucket, tandis que la politique large livre tous les buckets du compte.
Le moindre privilège est une direction à suivre, pas un réglage fait une fois pour toutes. AWS recommande de commencer avec une politique gérée un peu large pendant qu'une équipe explore ce dont une nouvelle charge de travail a réellement besoin, puis de la resserrer à mesure que les habitudes d'usage se précisent, à l'aide d'outils qui analysent l'activité réelle pour générer une politique plus stricte automatiquement. Les équipes qui ne reviennent jamais sur cette première politique large sont celles qu'un audit finit par pointer du doigt.
La frontière entre groupes et rôles
Ces deux notions se confondent parce que toutes deux permettent à plus d'une entité de partager des permissions, mais elles résolvent des problèmes différents.
| Groupe IAM | Rôle IAM | |
|---|---|---|
| Ce que c'est | Une collection d'utilisateurs IAM | Une identité à part entière |
| Qui l'utilise | Plusieurs personnes, en permanence | Une personne, une application ou un service, temporairement |
| Identifiants | Ceux de chaque utilisateur membre | Des identifiants temporaires, générés à l'assomption |
| Cas typique | Toute une équipe data reçoit les mêmes politiques | Une fonction Lambda accède à un bucket S3 |
Posez-vous la question que le scénario pose réellement : « accorder les mêmes permissions permanentes à plusieurs personnes » pointe vers un groupe ; « laisser cette application ou cette personne agir temporairement comme une identité précise » pointe vers un rôle.
Idée reçue : un mot de passe fort suffit
Il est tentant de croire qu'un mot de passe long et unique protège suffisamment un compte. Ce n'est pas le cas : les mots de passe se font hameçonner, se réutilisent sur des sites piratés, ou se font capturer par un logiciel malveillant, quelle que soit leur force. Le MFA comble cet écart en exigeant un second facteur, que le titulaire du compte possède ou génère, et qu'un mot de passe volé seul ne peut pas satisfaire. AWS recommande spécifiquement un MFA résistant au hameçonnage, comme une clé de sécurité physique ou un passkey, plutôt qu'un code à usage unique envoyé par SMS, puisque même ce code peut parfois être intercepté ou son processus détourné.
Repères d'examen : associer le scénario à l'outil
| L'énoncé mentionne... | Pointe vers |
|---|---|
| « Assumé temporairement », « sans identifiants durables », « utilisé par une application ou un service » | Un rôle IAM |
| « Accorder les mêmes permissions à toute une équipe » | Un groupe IAM |
| « Permissions minimales nécessaires à une tâche » | Le moindre privilège |
| « Second facteur », « même si le mot de passe est compromis » | L'authentification multifacteur |
| « L'outil du fournisseur ne peut pas assumer de rôle », « système historique », « accès programmatique hors AWS » | Une clé d'accès à long terme, en dernier recours |
Où cela vous mène
L'identité est la ligne du tableau de responsabilité partagée qui ne passe jamais au fournisseur, et IAM est l'outillage qui vous permet de vraiment la posséder : confirmer qui demande avec l'authentification, décider ce qu'il peut faire avec l'autorisation, et garder les deux étroits grâce au moindre privilège et aux rôles plutôt qu'à des identifiants permanents et tout-puissants. Savoir qui a le droit de toucher vos données règle la moitié du problème. La leçon suivante couvre ce qui protège ces données même si quelqu'un franchit malgré tout chacune de ces vérifications : le chiffrement.