Pourquoi l'identité est centrale en cybersécurité moderne

En 2026, plus de 60 % des compromissions majeures commencent par un credential valide. Pas une faille zero-day dans un service exposé. Pas une vulnérabilité applicative. Un identifiant, un mot de passe, parfois un token OAuth, utilisés légitimement par un attaquant qui a obtenu ce qu'il lui fallait pour se présenter comme quelqu'un d'autre. Cette inversion - d'un périmètre réseau défendu par firewall à une défense centrée sur l'identité - est la transformation silencieuse mais fondamentale de la cybersécurité de la dernière décennie. Ce guide explique pourquoi, comment, et avec quelles conséquences pratiques.

1. La fin du périmètre réseau classique

1.1 Le modèle "château et douves" (années 1990-2010)

Pendant deux décennies, la défense cyber reposait sur un modèle géographique simple :

• Zone interne de confiance : le réseau d'entreprise, derrière le firewall.
• Zone externe hostile : Internet, les partenaires, les visiteurs.
• Point de contrôle unique : le firewall qui autorise ou refuse le passage.

Une fois un utilisateur ou un serveur "à l'intérieur" du périmètre, il bénéficiait d'une confiance implicite. Le mot de passe local suffisait, les communications internes n'étaient pas chiffrées, les services communiquaient librement entre eux.

Cette architecture a bien fonctionné pendant une époque où :

• 95 % des utilisateurs étaient au bureau.
• Les applications critiques tournaient dans le datacenter.
• Les données ne sortaient pas du réseau d'entreprise.
• Les BYOD et SaaS étaient marginaux.

1.2 Les 5 ruptures qui ont fait tomber le modèle

1.2.1 Le cloud public (AWS 2006, Azure 2010, GCP 2011)

Les workloads critiques migrent en dehors du datacenter. Le firewall corporate ne peut plus être "le mur de la citadelle" : les applications vivent chez des fournisseurs, accédées depuis n'importe quelle IP.

1.2.2 Le SaaS (Salesforce 1999, Office 365 2011, Google Workspace 2006)

Les données d'entreprise migrent vers des fournisseurs tiers. L'email, les documents, le CRM, le code (GitHub, GitLab.com), les tickets (Jira Cloud) : tout est accessible en dehors du périmètre. Un simple login + mot de passe suffit à y accéder.

1.2.3 Le mobile et BYOD

Smartphones personnels qui accèdent aux emails professionnels, tablettes, laptops personnels. Le device n'est plus contrôlé par l'IT. Le concept de "machine corporate + machine personnelle" se brouille.

1.2.4 Le télétravail massif (COVID-19, mars 2020)

La quasi-totalité des cadres se retrouve à travailler depuis chez elle, en permanence. Le VPN sature. Les applications SaaS prennent le relais. Le périmètre réseau devient une fiction.

1.2.5 La supply chain et les API

Les applications modernes sont des agrégations de dizaines de services tiers, APIs partenaires, intégrations SaaS. Le périmètre d'une application est distribué sur 50 domaines, 200 tokens, 100 secrets. Le firewall ne peut plus rien filtrer utilement.

1.3 Ce qui reste quand le périmètre s'efface

Un seul invariant survit à ces cinq ruptures : l'identité de l'utilisateur, du service ou du device. Peu importe d'où on vient, comment on est connecté, quel device on utilise : l'identité est la seule chose qui peut être authentifiée et autorisée.

C'est ce constat qui a donné naissance au slogan "Identity is the new perimeter", popularisé par Gartner et adopté par l'ensemble de l'industrie depuis 2015.

2. Les preuves par les attaques - identité au cœur des compromissions

Quelques cas emblématiques des 5 dernières années illustrent cette centralité.

2.1 SolarWinds / SUNBURST (2020)

L'attaquant (APT29 / NOBELIUM) compromet le processus de build de SolarWinds Orion et injecte une backdoor dans la mise à jour logicielle distribuée à 18 000 clients. Mais l'exploitation réelle dans les environnements victimes passe principalement par :

• Vol de certificats de signature d'assertion SAML (technique "Golden SAML").
• Création de comptes de service dans les tenants Azure AD compromis.
• Élévation de privilèges via ces identités forgées.

Le malware livré via la supply chain est une porte d'entrée, mais c'est la manipulation d'identités légitimes qui produit l'impact réel.

2.2 Colonial Pipeline (mai 2021)

Ransomware DarkSide. Point d'entrée : un compte VPN unique dont le mot de passe avait fuité dans une base publique et qui n'avait pas de MFA. Pipeline qui alimente 45 % de la côte Est US à l'arrêt pendant 6 jours. Rançon de 4,4 millions de dollars payée.

2.3 Lapsus$ (2021-2022) - Okta, Microsoft, Nvidia, Samsung, Uber

Groupe d'adolescents qui a compromis de grandes entreprises essentiellement via ingénierie sociale sur les support desks et les développeurs :

• Achat de credentials sur des marketplaces criminels.
• MFA fatigue (bombarder l'utilisateur de notifications jusqu'à acceptation).
• SIM swapping pour intercepter SMS OTP.
• Corruption d'employés (offres financières).

Aucune 0-day, aucune exploitation complexe : juste du vol d'identité à grande échelle.

2.4 Okta (janvier 2022 et octobre 2023)

Deux incidents chez le leader mondial de l'IAM cloud. En 2022, compromission d'un sous-traitant Sitel avec accès à un portail interne. En 2023, compromission du support Okta via un token de support volé, exposant les fichiers HAR (HTTP Archive) de 134 clients, dont des session tokens actifs. Ironie : le fournisseur d'identité est lui-même compromis via... une identité de support mal protégée.

2.5 Uber (septembre 2022)

Un attaquant Lapsus$ obtient le mot de passe d'un contractor Uber (via fuite ou phishing). Le contractor reçoit des notifications push MFA et finit par en accepter une par lassitude. L'attaquant explore le réseau interne, trouve un script PowerShell contenant un credential admin du PAM Thycotic, et de là accède à AWS, GCP, HackerOne, Slack et G Suite. Compromission totale en quelques heures.

2.6 Microsoft Storm-0558 (juin-juillet 2023)

Acteur étatique chinois qui compromet une clé de signature Microsoft (MSA consumer signing key), forge des tokens OAuth pour Exchange Online, et accède aux emails de 25 organisations, dont des agences fédérales américaines. Encore une fois : pas d'exploitation technique applicative, mais manipulation cryptographique d'identités.

2.7 Snowflake (juin 2024)

165 tenants Snowflake compromis via des credentials volés par infostealers sur des postes d'employés non protégés par MFA. Fuites massives chez AT&T, Ticketmaster, Santander, Advance Auto Parts. Snowflake corrige rapidement la politique par défaut en imposant MFA, mais le dommage est fait : centaines de millions d'enregistrements exfiltrés.

2.8 Conclusion du panorama

Les chiffres convergents 2024-2025 (Verizon DBIR, Mandiant M-Trends, CrowdStrike Global Threat Report) :

• 60 à 80 % des compromissions majeures commencent par un credential valide.
• 20 % des credentials utilisés sont acquis via infostealers et marketplaces criminels.
• Le coût moyen d'une compromission par identité est environ 35 % plus élevé que par autre vecteur (IBM Cost of a Data Breach 2024).

3. Les trois piliers de la sécurité par l'identité

Si l'identité est le nouveau périmètre, trois fonctions doivent être industrialisées.

3.1 Authentification (who are you)

Vérifier qu'une identité revendiquée correspond à la personne/service/device réels. Fondement : un ou plusieurs facteurs :

• Quelque chose que tu sais : mot de passe, code PIN. Faible en 2026.
• Quelque chose que tu possèdes : token physique (YubiKey), téléphone avec app Authenticator.
• Quelque chose que tu es : biométrie (empreinte, Face ID, Touch ID).
• Quelque chose que tu fais : patterns comportementaux (frappe, souris, géolocalisation).

La combinaison d'au moins 2 facteurs est le Multi-Factor Authentication (MFA), obligatoire sur tout ce qui a de la valeur en 2026.

Modernité de l'authentification :

• FIDO2 / WebAuthn : standard cryptographique qui remplace les mots de passe. La preuve d'identité est une signature cryptographique générée par une clé privée dans l'appareil, jamais transmise. Résistant au phishing par design.
• Passkeys : implémentation FIDO2 synchronisée (Apple iCloud Keychain, Google Password Manager, 1Password) qui remplace les mots de passe pour le grand public.
• Conditional Access : l'authentification s'adapte au contexte (IP, device, heure, risque).

3.2 Autorisation (what can you do)

Une fois authentifié, déterminer ce que l'identité a le droit de faire. Modèles :

• RBAC (Role-Based Access Control) : rôles explicites (admin, user, viewer). Simple à gérer, inflexible à grande échelle.
• ABAC (Attribute-Based Access Control) : politiques basées sur attributs multiples (département, sensibilité donnée, heure, device). Plus puissant, plus complexe.
• ReBAC (Relationship-Based Access Control) : permissions dérivées des relations entre entités (utilisé par Google Zanzibar, OpenFGA, SpiceDB). Idéal pour modèles de partage type Google Drive, Figma.
• Policy-as-Code : les politiques sont écrites en code versionné (OPA/Rego, AWS Cedar, Google Cedar), testé, déployé comme n'importe quel code.

La règle d'or : moindre privilège. Chaque identité n'a que les permissions strictement nécessaires, pas plus.

3.3 Accountability (what did you do)

Toute action doit être traçable à l'identité qui l'a produite. Moyens :

• Audit logs centralisés : tout événement d'authentification, d'autorisation, d'action sensible.
• SIEM avec corrélation d'identité : regrouper les événements par identité, pas seulement par IP/device.
• Identity Threat Detection & Response (ITDR) : catégorie émergente d'outils dédiés (Silverfort, Oort, Push Security, Spur, Varonis) qui détecte les anomalies d'identité (login impossible, privilège escaladé, comportement atypique).

Sans accountability, l'identité devient ingérable : impossible d'enquêter, impossible de corriger, impossible de produire des preuves réglementaires.

4. Zero Trust - le modèle architectural qui concrétise tout cela

4.1 NIST SP 800-207 (2020) - référence

Le NIST Special Publication 800-207 définit Zero Trust Architecture (ZTA) autour de 7 principes :

1. Toute ressource de données et de service est une ressource.
2. Toute communication est sécurisée, indépendamment de l'emplacement réseau.
3. L'accès aux ressources individuelles d'entreprise est accordé par session.
4. L'accès est déterminé par une politique dynamique basée sur identité, état, comportement et autres attributs.
5. L'entreprise surveille et mesure l'intégrité et la posture de sécurité de tous les actifs.
6. Toute authentification et autorisation est dynamique et strictement appliquée avant que l'accès soit accordé.
7. L'entreprise collecte autant d'informations que possible sur l'état actuel des actifs, l'infrastructure et les communications, pour améliorer la posture.

Traduction opérationnelle : never trust, always verify.

4.2 Les composants Zero Trust

• Policy Engine : décide qui peut accéder à quoi, quand.
• Policy Administrator : établit/coupe les connexions en fonction des décisions du PE.
• Policy Enforcement Point (PEP) : applique les décisions sur chaque connexion.
• Data sources : identité (IdP), device posture (MDM/EDR), logs, threat intel.

Cette architecture ne remplace pas le firewall ou l'antivirus : elle ajoute une couche d'autorisation contextuelle à chaque interaction.

4.3 De la théorie à la pratique

Un déploiement Zero Trust mature inclut :

• Identity Provider central : Okta, Azure AD/Entra ID, Ping, Auth0, Keycloak.
• MFA généralisé avec préférence FIDO2/passkeys.
• SSO pour toutes les applications via OIDC ou SAML.
• Conditional Access avec évaluation continue.
• Micro-segmentation réseau (optionnel mais complémentaire).
• PAM pour les privilèges élevés.
• CIEM pour les permissions cloud.
• ITDR pour la détection d'anomalies identitaires.

5. Les conséquences pratiques pour tout ingénieur

5.1 MFA n'est plus négociable

Tout compte ayant accès à des données ou services d'entreprise doit avoir MFA activée, avec préférence pour :

1. Clés FIDO2 hardware (YubiKey, Google Titan, Feitian) pour admins et profils à risque.
2. Passkeys synchronisées pour grand public.
3. Authenticator apps (Microsoft Authenticator, Okta Verify, Authy) avec push notification.
4. SMS OTP : à bannir sauf marchés grand public sans alternative (SIM swap, interception).

Depuis 2024, de plus en plus de fournisseurs SaaS (AWS, GCP, Microsoft, GitHub, Snowflake, Cloudflare) imposent MFA par défaut pour les comptes admin.

5.2 SSO centralisé obligatoire

Chaque application SaaS, chaque service interne, chaque infrastructure doit s'authentifier via un IdP central (OIDC ou SAML). Bénéfices :

• Désactivation d'un user = désactivation de tous ses accès en un clic.
• Politique MFA homogène.
• Audit trail centralisé.
• Joiner/Mover/Leaver (JML) automatisé.

5.3 Least privilege by default

Plus aucune identité ne reçoit de privilèges par défaut larges. Chaque permission est :

• Explicitement accordée.
• Justifiée (ticket, demande RH).
• Revue périodiquement (access recertification).
• Retirée automatiquement si inutilisée au-delà d'un seuil.

Outils : SailPoint, Saviynt, Omada pour IGA enterprise. Approches plus légères : Google Access Approval, AWS Access Analyzer, scripts + pull requests pour les orgs plus petites.

5.4 Privileged Access Management (PAM)

Les identités à privilèges élevés (admin domaine, root production, database admin, break-glass) nécessitent une protection renforcée :

• Vault des credentials (CyberArk, HashiCorp Vault, Delinea, Teleport).
• Sessions éphémères : pas de credential long-lived stocké dans les clients.
• Just-in-time access : demande + approbation + activation temporaire.
• Session recording pour audit.
• MFA additionnel avant élévation.

5.5 CIEM (Cloud Infrastructure Entitlement Management)

Dans un environnement cloud, les permissions IAM s'accumulent vite : AWS accorde typiquement 5 000 à 50 000 permissions possibles pour un rôle. Plus de 95 % ne sont jamais utilisées. Le CIEM (Wiz, Orca, Ermetic, Sonrai) modélise les permissions effectives dans un graphe et aide à réduire la surface.

5.6 ITDR - la nouvelle catégorie

Identity Threat Detection and Response : outils qui surveillent les événements d'identité pour détecter les comportements anormaux. Cas d'usage :

• Login impossible (Paris à 10h, Tokyo à 10h05).
• MFA fatigue bombing détecté.
• Session token réutilisé depuis une IP différente.
• Création de nouveau compte admin en dehors des heures.
• Ajout d'OAuth app par un user non autorisé.

Catégorie émergente 2022+, encore peu mature mais en explosion chez les éditeurs (Silverfort, Crowdstrike Falcon Identity Protection, Microsoft Defender for Identity, Okta ITP).

5.7 Identité machine et workload

L'identité ne concerne pas que les humains. Les workloads cloud, les microservices, les pipelines CI/CD, les agents AI ont aussi une identité. Standards émergents :

• SPIFFE/SPIRE : identité workload portable inter-cloud.
• Workload Identity Federation (GCP, Azure, AWS IRSA) : identité liée à la plateforme.
• mTLS automatique (Istio, Linkerd, Consul) : authentification mutuelle entre services.
• Sigstore keyless signing : identité d'un pipeline CI signe les artefacts sans clé privée.

6. L'économie de l'identité en cybersécurité

6.1 Coût des compromissions

Selon IBM Cost of a Data Breach 2024 :

• Coût moyen global d'une compromission : 4,88 millions USD (+10 % vs 2023).
• Coût moyen quand le vecteur est un credential volé : 4,81 millions USD.
• Coût additionnel si MFA n'était pas en place sur le compte compromis : environ 25 % supplémentaires.

6.2 Régulations qui imposent l'IAM moderne

• RGPD (EU) : traçabilité des accès aux données personnelles, droit d'accès, droit à l'oubli.
• NIS 2 (EU, transposée France 2024) : obligations de sécurité incluant MFA pour entités essentielles.
• DORA (EU finance, janvier 2025) : exigences strictes sur IAM pour secteur financier.
• CNIL : recommandations IAM pour prestataires santé, collectivités.
• Executive Order 14028 (US, 2021) : MFA phishing-resistant obligatoire pour agences fédérales d'ici 2024.
• Cyber Resilience Act (EU, applicable 2027) : exigences pour produits avec éléments numériques.

6.3 Marché IAM

• Marché global IAM estimé à 27 milliards USD en 2026, croissance 13-15 % par an.
• Leaders : Microsoft Entra ID (ex-Azure AD), Okta, Ping Identity, SailPoint, CyberArk.
• Catégories en forte croissance : PAM (12 % CAGR), ITDR (30 % CAGR), CIEM (25 % CAGR), Passkeys adoption.

7. Le paysage professionnel IAM

7.1 Métiers qui montent

• Ingénieur IAM : implémentation et maintenance des mécanismes d'authentification/autorisation. 50-80 k€ France selon expérience.
• Architecte Zero Trust : design de l'architecture identité-centrée. 80-120 k€.
• PAM Engineer : spécialiste des outils type CyberArk, Delinea, BeyondTrust. 55-85 k€.
• Active Directory Security Specialist : sécurité de l'AD hérité et de la transition vers Entra ID. 60-95 k€.
• IGA consultant : déploiement SailPoint/Saviynt/Omada. 55-90 k€.
• CIEM architect : sécurité des permissions cloud. 75-110 k€.

Voir métier ingénieur IAM pour le détail.

7.2 Compétences clés

• Protocoles : OIDC (tokens JWT, flows), OAuth 2.0 (authorization code + PKCE), SAML 2.0 (assertions XML), SCIM, FIDO2/WebAuthn.
• Plateformes : Okta, Azure AD/Entra ID, Auth0, Keycloak, Ping, ForgeRock.
• AD/Kerberos : internals, attaques (Pass-the-Hash, Kerberoasting, DCSync, Golden Ticket).
• Cloud IAM : AWS IAM + IAM Identity Center, GCP IAM, Azure RBAC + PIM.
• Programmation : Python, Go pour automation ; PowerShell pour AD ; REST APIs.
• Sécurité offensive appliquée à l'identité : Mimikatz, Rubeus, BloodHound, Impacket, Kerbrute.

7.3 Formations et certifications

• Microsoft SC-300 : Identity and Access Administrator.
• Okta Certified Professional / Administrator / Consultant.
• CyberArk Defender / Sentry.
• SailPoint IdentityIQ Engineer.
• SANS SEC530 : Defensible Security Architecture (inclut IAM).
• CCIE Security (Cisco) pour volet réseau + identité.

8. Pièges classiques dans la transition identité-centrée

8.1 MFA SMS considéré comme suffisant

SMS OTP est vulnérable au SIM swapping et à l'interception SS7. Les attaques observées en production depuis 2020 démontrent qu'il faut viser FIDO2 pour les admins et authenticator apps pour le reste, avec SMS uniquement en fallback low-risk.

8.2 SSO sans MFA

Déployer SSO sans imposer MFA sur l'IdP crée un single point of failure : un credential volé = accès à toutes les applications fédérées.

8.3 Pas de rupture sur les legacy

Les applications legacy (non-OIDC, non-SAML) continuent à utiliser login/password stocké localement. Tant qu'il y a ces îlots, l'architecture Zero Trust est compromise.

8.4 Privilèges permanents

Laisser des privilèges admin permanents aux équipes IT/DevOps. JIT (Just-In-Time) via PAM ou Azure PIM doit devenir la norme.

8.5 Comptes de service partagés

Services partagés par plusieurs équipes avec credentials long-lived = aucune accountability, rotation impossible. Chaque service doit avoir sa propre identité workload.

8.6 Confiance au device managé implicite

"L'utilisateur est sur un laptop managé, on lui fait confiance" : erreur. Le device peut être compromis (malware, infostealer). Zero Trust exige vérification continue, pas confiance initiale.

9. Démarrer la transition vers une sécurité identité-centrée

Pour une organisation qui part d'un modèle périmètre classique, parcours réaliste sur 18-24 mois.

Phase 1 (mois 1-3) - visibilité et MFA

• Inventaire complet des comptes, comptes privilégiés, comptes orphelins.
• MFA généralisée via l'IdP principal (tous les admins d'abord, tous les users ensuite).
• FIDO2 keys pour profils à risque.
• Désactivation des méthodes MFA faibles (email, sécurité questions).

Phase 2 (mois 4-9) - SSO et rationalisation

• Migration de toutes les applications SaaS vers SSO (OIDC/SAML) via IdP.
• Fédération avec cloud providers (AWS SSO, Azure AD, GCP).
• Joiner/Mover/Leaver automatisé via SCIM.
• Élimination progressive des comptes locaux.

Phase 3 (mois 10-15) - Privilèges et gouvernance

• Déploiement PAM pour comptes admin critiques.
• Just-in-time access sur privilèges production.
• Access recertification trimestrielle.
• CIEM sur les clouds publics.

Phase 4 (mois 16-24) - Zero Trust étendu

• Conditional access avec évaluation continue (device, IP, comportement).
• Passkeys en remplacement progressif des mots de passe.
• ITDR pour détection d'anomalies identitaires.
• Workload identity (IRSA, Workload Identity Federation, SPIFFE).
• Mesure de la maturité (Zero Trust Maturity Model CISA).

10. Verdict et posture Zeroday

L'identité n'est pas un enjeu parmi d'autres en cybersécurité : c'est l'enjeu central à partir duquel tous les autres se jouent. Une architecture identité mature rend plus difficiles le ransomware, l'exfiltration, la compromission supply chain, l'attaque par les tiers. Inversement, une architecture identité faible rend inutiles tous les autres investissements : WAF, SIEM, EDR, CNAPP tombent quand un admin se fait voler ses credentials et son MFA SMS.

Pour un professionnel qui se forme : investir en IAM est structurellement rentable. Les compétences IAM sont rares, transférables entre industries, en demande croissante. Les profils IAM seniors gagnent plus que les profils DevSecOps seniors équivalents sur le marché français 2026, pour une raison simple : la pénurie est plus forte.

Pour une organisation : les ressources investies en identité produisent les meilleurs retours sécuritaires actuellement mesurables. Ce n'est pas un investissement à mettre en priorité 3. C'est la priorité 1, toujours.

Pour approfondir concrètement : IAM expliqué simplement pour le volet cloud, qu'est-ce qu'un ingénieur IAM pour le parcours métier, gestion de session sécurisée pour la couche applicative, sécurité des workloads cloud pour l'articulation workload identity. La catégorie IAM & Identité Zeroday se construit autour de ce pilier : chaque article ultérieur approfondit un des angles mentionnés ici.