Le zero trust, fondation de l'IAM moderne
Le modèle de sécurité zero trust part d'un constat simple : le périmètre réseau traditionnel (« à l'intérieur, on fait confiance ; à l'extérieur, on se méfie ») ne fonctionne plus dans un environnement cloud où les utilisateurs, les appareils et les services communiquent depuis n'importe où.
Ne jamais faire confiance par défaut
Aucun utilisateur, appareil ou service n'est considéré comme fiable simplement parce qu'il se trouve à l'intérieur du réseau de l'organisation. Chaque demande d'accès est traitée comme si elle provenait d'un réseau non fiable, quelle que soit son origine.
Vérifier systématiquement
Chaque accès est authentifié et autorisé individuellement, en tenant compte du contexte (identité, appareil, localisation, comportement), plutôt qu'une seule fois à l'entrée du réseau.
Supposer la compromission
L'architecture est conçue en partant du principe qu'une compromission a déjà eu lieu quelque part, ce qui pousse à segmenter les accès et à limiter les mouvements latéraux possibles pour un attaquant qui aurait déjà obtenu un premier accès.
Le zero trust n'est pas un produit qu'on installe, mais une approche qui structure la conception de l'ensemble des accès. Les outils IAM des grands fournisseurs cloud permettent de l'implémenter, mais l'architecture d'accès elle-même doit être pensée dans cette logique dès le départ.
Le moindre privilège : un cycle continu, pas un état ponctuel
Le principe du moindre privilège consiste à n'accorder à chaque identité que les permissions strictement nécessaires à son usage réel, ni plus ni moins. Simple à énoncer, il est rarement maintenu dans la durée sans processus dédié.
Analyser l'usage réel plutôt que l'usage supposé
Les outils d'analyse d'accès proposés par les grands fournisseurs (comme les analyseurs de permissions IAM) comparent les droits accordés à l'usage effectivement constaté, révélant systématiquement un écart important entre ce qui est accordé et ce qui est réellement utilisé.
L'accès juste-à-temps (JIT), l'évolution logique du moindre privilège
Plutôt que d'accorder des droits permanents (« standing access »), l'accès juste-à-temps élimine les droits en permanence actifs et ne les accorde que pour la durée réelle du besoin, avec une demande explicite et généralement une validation. Cette approche réduit mécaniquement la fenêtre d'exposition en cas de compromission d'un compte.
RBAC et ABAC : deux logiques différentes, souvent complémentaires
Choisir entre RBAC et ABAC est l'un des arbitrages les plus fréquents pour une équipe qui structure sa gouvernance des accès — et la bonne réponse est souvent « les deux », pas l'un contre l'autre.
RBAC : des permissions attachées à un rôle
Le contrôle d'accès basé sur les rôles (Role-Based Access Control) attache les permissions à un rôle prédéfini (par exemple « administrateur base de données »), puis assigne ce rôle aux identités concernées. Simple à comprendre et à auditer, particulièrement adapté aux structures organisationnelles stables.
ABAC : des permissions calculées à partir d'attributs
Le contrôle d'accès basé sur les attributs (Attribute-Based Access Control) calcule dynamiquement les permissions à partir d'attributs contextuels (département, niveau de sensibilité de la donnée, localisation, heure de la journée). Plus flexible que le RBAC, mais aussi plus complexe à concevoir et à auditer.
Combiner les deux dans une organisation mature
En pratique, de nombreuses organisations combinent RBAC pour la structure générale des accès (stable, prévisible) et ABAC pour des règles contextuelles fines (temporaires, conditionnelles) — plutôt que de choisir un modèle unique pour l'ensemble de l'organisation.
Un exemple pour fixer les idées
Une équipe finance peut se voir attribuer un rôle RBAC « Analyste Finance » donnant accès aux outils de reporting standards. Une règle ABAC vient ensuite restreindre dynamiquement l'accès à certains rapports sensibles selon la localisation de connexion ou l'heure de la journée — le rôle définit le périmètre général, l'attribut affine la décision au cas par cas.
Les identités non-humaines dépassent désormais les identités humaines
Comptes de service, rôles attribués aux pipelines CI/CD, fonctions serverless, agents automatisés : dans la plupart des environnements cloud modernes, ces identités non-humaines (NHI) sont aujourd'hui plus nombreuses que les comptes utilisateurs humains — et souvent moins bien gouvernées.
Pourquoi les identités non-humaines sont un angle mort fréquent
Contrairement à un compte utilisateur, une identité non-humaine ne se connecte pas manuellement, ne change pas d'humeur, n'oublie pas son mot de passe — ce qui la rend moins visible dans les processus de revue d'accès classiques, alors qu'elle dispose souvent de permissions très larges pour fonctionner correctement.
Appliquer les mêmes principes qu'aux identités humaines
La bonne pratique consiste à appliquer aux identités non-humaines les mêmes exigences qu'aux comptes humains : cycle de vie explicite (création, revue, désactivation), rotation régulière des identifiants et clés, et application stricte du principe du moindre privilège — plutôt que de les laisser hors du périmètre de gouvernance habituel.
Dans les environnements cloud modernes fortement automatisés (CI/CD, orchestration de conteneurs, fonctions serverless), il n'est plus rare que les identités non-humaines représentent la majorité des identités actives — un changement d'échelle qui rend une gouvernance manuelle traditionnelle rapidement intenable.
Les garde-fous globaux, au-delà des permissions individuelles
Dans un environnement multicloud ou à grande échelle, la gouvernance IAM ne peut pas reposer uniquement sur la configuration fine de chaque permission individuelle — elle nécessite des garde-fous globaux qui s'appliquent uniformément, y compris aux comptes les plus privilégiés.
Des exemples concrets chez les grands fournisseurs
Chez AWS, les politiques de contrôle de service (Service Control Policies) permettent d'empêcher toute identité, y compris le compte racine, de désactiver la journalisation d'audit ou de supprimer certains contrôles de sécurité. Chez Google Cloud, les politiques d'organisation permettent de désactiver globalement certaines pratiques risquées, comme la création de clés de comptes de service, au niveau de l'ensemble de l'organisation plutôt que projet par projet.
Le défi de la cohérence entre fournisseurs
Chaque fournisseur cloud a sa propre terminologie et ses propres mécanismes de gouvernance — traduire une même politique de sécurité de façon cohérente à travers plusieurs fournisseurs reste l'un des défis les plus concrets de la gouvernance multicloud, largement documenté comme tel dans les organisations qui opèrent sur plusieurs plateformes.
Vers une gouvernance formalisée (IGA)
Cette complexité pousse de plus en plus d'organisations vers une démarche d'Identity Governance and Administration (IGA) : un ensemble structuré de processus et d'outils couvrant le cycle de vie complet des identités, la visibilité continue sur les accès accordés, et la détection proactive des anomalies — une évolution vers une discipline formalisée, plutôt qu'un ensemble de contrôles ponctuels et dispersés.
Vers une authentification sans mot de passe pour les comptes à privilèges
L'authentification multifacteur reste une base indispensable, mais les organisations les plus avancées en matière d'IAM évoluent désormais vers des méthodes d'authentification plus robustes que le simple couple mot de passe + code temporaire.
- FIDO2 et clés d'accès (passkeys), qui éliminent le mot de passe lui-même comme vecteur d'attaque plutôt que de simplement le renforcer
- Authentification par certificat pour les accès techniques et les identités non-humaines
- Clés de sécurité matérielles pour les comptes à privilèges les plus critiques
- Authentification contextuelle, qui ajuste le niveau de vérification requis selon la localisation, l'appareil et le comportement observé
Les pièges les plus courants en gouvernance IAM
Trois erreurs reviennent régulièrement dans les organisations qui peinent à structurer leur gouvernance IAM.
Des revues d'accès trop rares ou inexistantes
Sans revue régulière, les permissions accumulées au fil des changements de poste, des projets terminés et des départs non traités créent un écart croissant entre les droits accordés et les besoins réels — un terrain propice à l'exploitation en cas de compromission.
Oublier les identités non-humaines dans la gouvernance
Traiter la gouvernance IAM comme un sujet concernant uniquement les comptes utilisateurs humains laisse un angle mort de plus en plus large, à mesure que l'automatisation se généralise dans les environnements cloud.
Des rôles RBAC définis trop largement par simplicité
Créer des rôles génériques trop permissifs pour éviter la complexité de rôles plus fins va directement à l'encontre du principe du moindre privilège — la simplicité de gestion à court terme se paie en surface d'exposition à moyen terme.
Une politique de gouvernance IAM documentée mais jamais auditée en conditions réelles ne protège pas davantage qu'une politique inexistante. La gouvernance se prouve par des contrôles effectifs et réguliers, pas par la documentation seule.
Un domaine central des certifications d'entrée et avancées
L'IAM et la gouvernance figurent systématiquement parmi les domaines les plus densément testés des certifications cloud, dès le niveau d'entrée — Azure Fundamentals, Google Cloud Digital Leader et AWS Cloud Practitioner couvrent tous les trois la gestion des identités et des accès, un socle indispensable avant d'aborder des certifications plus avancées sur ce sujet spécifique.
Pour aller plus loin
- ArticleResponsabilité partagée dans le cloud
- ArticleIaaS, PaaS, SaaS : les 3 modèles de service cloud
- ArticleFinOps : comprendre et maîtriser les coûts du cloud
- ArticleAWS vs Azure vs Google Cloud
- ArticleCloud souverain, portabilité et réversibilité
- GuideComprendre Azure Fundamentals
- GuideArchitecture Azure : arbitrages, data, IA
Questions fréquentes
Quelle est la différence entre le zero trust et le modèle de responsabilité partagée ?
Le modèle de responsabilité partagée définit qui — fournisseur ou client — est responsable de chaque couche de sécurité. Le zero trust est une approche architecturale que le client applique à sa propre part de responsabilité, en particulier à la gestion des identités et des accès.
Le moindre privilège est-il une action ponctuelle ou un processus continu ?
C'est un processus continu. Les permissions accordées ont tendance à s'accumuler avec le temps si elles ne sont pas régulièrement révisées, ce qui rend une simple mise en conformité initiale insuffisante sans revue périodique.
Faut-il choisir entre RBAC et ABAC ?
Pas nécessairement. De nombreuses organisations matures combinent RBAC pour la structure générale des accès et ABAC pour des règles contextuelles plus fines, plutôt que d'imposer un modèle unique à l'ensemble de leurs besoins.
Qu'est-ce qu'une identité non-humaine (NHI) ?
Une identité non-humaine est un compte ou un rôle utilisé par un système plutôt qu'une personne : compte de service, rôle attribué à un pipeline CI/CD, identité d'une fonction serverless. Elles sont aujourd'hui souvent plus nombreuses que les comptes humains dans les environnements cloud automatisés.
Pourquoi les identités non-humaines sont-elles plus risquées à gouverner ?
Parce qu'elles échappent souvent aux processus de revue d'accès classiques conçus pour des utilisateurs humains, tout en disposant fréquemment de permissions larges nécessaires à leur fonctionnement automatisé — un angle mort qui grandit avec le niveau d'automatisation de l'organisation.
Qu'est-ce que l'accès juste-à-temps (JIT) ?
L'accès juste-à-temps accorde des permissions uniquement pour la durée réelle du besoin, plutôt que de façon permanente. Il élimine les droits en permanence actifs (« standing access »), réduisant la fenêtre d'exposition en cas de compromission d'un compte.
Comment un garde-fou global diffère-t-il d'une permission individuelle ?
Une permission individuelle s'applique à une identité précise. Un garde-fou global (comme une politique de contrôle de service AWS ou une politique d'organisation Google Cloud) s'applique uniformément à l'ensemble d'un compte ou d'une organisation, y compris aux identités les plus privilégiées, empêchant certaines actions quelle que soit l'identité qui les tente.
Le mot de passe et le MFA classique sont-ils dépassés en 2026 ?
Pas dépassés, mais de plus en plus complétés voire remplacés pour les comptes à privilèges par des méthodes plus robustes comme FIDO2 et les clés d'accès (passkeys), qui suppriment le mot de passe lui-même comme point de vulnérabilité plutôt que de simplement ajouter une couche de vérification supplémentaire.
La gouvernance IAM est-elle uniquement un sujet de sécurité ?
Non. C'est aussi un sujet de conformité réglementaire, d'efficacité opérationnelle (accès accordés rapidement aux bonnes personnes) et de gestion des coûts (licences et permissions inutilisées). La gouvernance IAM structurée sert plusieurs objectifs simultanément.
Faut-il connaître ces concepts pour une certification cloud ?
Oui, la gestion des identités et des accès fait partie des domaines les plus densément testés des certifications d'entrée Azure Fundamentals, Google Cloud Digital Leader et AWS Cloud Practitioner, et constitue le socle de certifications plus avancées spécifiquement centrées sur la sécurité.