Questions d'entretien Identity & Access Management

Non. Les trois catégories de facteurs d'authentification sont quelque chose que vous savez (mot de passe/PIN), quelque chose que vous avez (jeton/téléphone) et quelque chose que vous êtes (biométrie). Une empreinte digitale ou un scan facial relève de « quelque chose que vous êtes », un trait physique mesuré. Le piège : la biométrie n'est pas un secret et ne peut pas être renouvelée — si le gabarit de votre empreinte fuite, vous ne pouvez pas changer votre empreinte. C'est pourquoi la biométrie fonctionne mieux comme un facteur, déverrouillant souvent une clé locale, que comme remplacement autonome du mot de passe.

Non. Supprimer le cookie retire seulement l'identifiant de votre navigateur — l'enregistrement de session (ou un JWT encore valide) sur le serveur reste généralement utilisable jusqu'à son expiration ou son invalidation explicite. Un attaquant ayant déjà capturé le jeton peut continuer à l'utiliser. L'erreur prend le cookie pour la session elle-même ; ce n'est qu'un pointeur vers l'état côté serveur. La vraie déconnexion doit invalider la session côté serveur, ou révoquer et limiter la durée du jeton.

Non. La MFA élève fortement la barre, mais les facteurs OTP et push sont hameçonnables : les kits d'adversaire au milieu (ex. Evilginx) relaient la connexion et le code en temps réel, et la fatigue MFA / le push-bombing poussent l'utilisateur à approuver. Les codes capturés sont réutilisables dans leur courte fenêtre. L'erreur est « MFA = inhameçonnable » ; c'est le type de facteur qui compte. La MFA résistante au phishing — les passkeys FIDO2/WebAuthn liés à l'origine du site — est ce qui déjoue réellement cela.

Pas à lui seul. De nombreux systèmes maintiennent valides les sessions existantes et les jetons déjà émis après un changement de mot de passe — jetons OAuth de rafraîchissement, « mots de passe d'application », clés d'API et cookies persistants — si bien qu'un attaquant disposant d'une session active peut rester. La bonne réponse est de changer le mot de passe ET d'invalider toutes les sessions et jetons, révoquer les identifiants d'application, et auditer les appareils MFA et les paramètres de récupération. Croire qu'une réinitialisation seule éjecte l'attaquant est une erreur classique de réponse à incident.

Non. Un sel est une valeur aléatoire unique stockée juste à côté du hash ; son rôle est de faire en sorte que des mots de passe identiques produisent des hashes différents et de neutraliser les rainbow tables précalculées — pas de rester secret. Il est normal qu'un attaquant qui vole la base récupère aussi les sels. Ce qui protège réellement les mots de passe, c'est un hash lent et salé (bcrypt, scrypt, Argon2). Un « poivre » secret optionnel et séparé est un concept différent.

Une autonomie sans limites associée à l'accès aux outils, c'est l'« agence excessive » d'OWASP LLM : un modèle manipulé ou en erreur peut entreprendre des actions destructrices. Encadrez-le avec des outils au moindre privilège, exigez une confirmation humaine pour les opérations irréversibles, et gardez des permissions restreintes et auditées. Lui faire confiance ou lui donner les droits admin élargit le rayon d'impact, et masquer un bouton dans l'interface ne change rien à la capacité sous-jacente du modèle à appeler l'action.

Si la récupération extrait n'importe quel document indexé quelle que soit la personne qui interroge, le modèle restituera fidèlement des données que l'utilisateur ne devrait pas voir — c'est une faille d'autorisation, pas une hallucination. Imposez les permissions de l'utilisateur au niveau du document au moment de la récupération, pour que seuls les fragments autorisés entrent dans le contexte. Un prompt système plus long est contournable et n'implémente aucun contrôle d'accès, la température n'a aucun rapport, et un autre modèle présente la même faille.

Le stockage de mots de passe exige un hachage délibérément lent, salé et à coût mémoire élevé — bcrypt, scrypt ou Argon2 — pour que casser des hachages volés soit coûteux et que les rainbow tables ne s'appliquent pas. Un hachage rapide comme SHA-256 se brute-force trivialement à grande échelle ; le chiffrement réversible signifie qu'une seule compromission de clé expose tous les mots de passe d'un coup ; et le texte clair est indéfendable, quelle que soit la fermeture de la base. Choisissez Argon2id (ou bcrypt) avec un facteur de coût ajusté et un sel unique par utilisateur.

Les auditeurs vérifient des preuves, pas des intentions : présentez la politique de revue d'accès, des relevés datés de chaque revue avec la validation d'un approbateur, et la confirmation que les accès signalés ont bien été révoqués et vérifiés. Une confirmation verbale ne prouve rien de reproductible, une promesse de commencer le trimestre prochain montre que le contrôle ne fonctionnait pas pendant la période auditée, et un organigramme décrit des liens hiérarchiques, pas des décisions d'accès. Seuls les artefacts datés et attribuables démontrent que le contrôle a fonctionné comme prévu sur toute la période.

Le risque au départ, c'est l'accès résiduel ; le contrôle à vérifier est donc le déprovisionnement rapide de chaque voie d'accès — comptes d'annuaire, SSO, VPN, identifiants privilégiés et de service, et SaaS tiers — rapproché du processus arrivée/mobilité/départ (JML). Supposer que les RH gèrent tout sans vérification laisse des failles que personne ne possède. Garder le compte actif « au cas où il reviendrait » est un risque permanent et non surveillé. Désactiver seulement l'e-mail ignore les nombreux autres systèmes que la personne pourrait encore atteindre. L'enjeu est de vérifier que l'accès est réellement et totalement retiré, pas de présumer qu'il l'a été.

Urgence, autorité et contournement de la vérification sont une pression d'ingénierie sociale de manuel visant un compte à forte valeur. L'agent doit suivre le processus de vérification d'identité défini avant toute réinitialisation, et escalader s'il ne peut pas être satisfait. Réinitialiser à la demande, utiliser une « question de sécurité » devinable comme la couleur préférée, ou envoyer le nouveau mot de passe par e-mail à l'appelant remettent tous le contrôle du compte du dirigeant à un attaquant.

Les comptes de service inutilisés et sur-privilégiés sont des cibles de choix et une large surface d'attaque. Inventoriez-les, désactivez ou supprimez les inutilisés (en surveillant les casses), réduisez les survivants au moindre privilège et donnez à chacun un propriétaire et une revue récurrente. Les laisser est un risque permanent, leur accorder un accès admin global maximise le rayon d'impact, et tout consolider sur un compte partagé unique détruit le moindre privilège et la responsabilité.

Une redirection ouverte sur un flux d'authentification permet à un attaquant de forger un lien de connexion d'apparence fiable qui, après authentification, envoie l'utilisateur — et potentiellement un code d'autorisation ou un jeton — vers un domaine contrôlé par l'attaquant, permettant le détournement de compte et un phishing convaincant. Corrigez-le en allow-listant strictement les redirect URI exacts côté serveur et en rejetant tout le reste. Ce n'est ni cosmétique ni un problème de performance, et HTTPS n'aide pas car la destination de l'attaquant peut aussi être un site HTTPS valide.

LSASS stocke des identifiants et secrets en cache, donc un processus inattendu lisant sa mémoire est la signature d'un vol d'identifiants (par exemple un dump de type mimikatz). Triez le processus fautif et son parent, isolez l'hôte pour stopper le mouvement latéral, et renouvelez les identifiants susceptibles d'avoir été capturés — y compris les comptes privilégiés et de service. Cela n'a rien à voir avec le rendu graphique ou l'espace disque, et l'ignorer comme normal peut mener à une compromission de tout le domaine. Les distracteurs d'apparence anodine sont précisément la façon dont les analystes ratent une intrusion active.

Il s'agit d'un contrôle d'accès défaillant (IDOR) : le serveur ne vérifie pas que l'utilisateur authentifié a le droit d'accéder à l'objet demandé. La correction est une autorisation par objet appliquée côté serveur à chaque requête. Nettoyer le nombre n'établit pas la propriété. Chiffrer ou masquer l'ID relève de l'obscurité et reste devinable, divulgable ou rejouable. La méthode HTTP n'a aucun rapport avec l'autorisation. Vérifiez toujours le droit de l'appelant sur l'objet précis avant de le renvoyer.

Équilibrez utilisabilité et risque : imposez un accès conditionnel lié à la posture de l'appareil et isolez les données d'entreprise dans un conteneur géré (MAM/MDM) afin de les contrôler et de les effacer sélectivement sans prendre la main sur tout l'appareil personnel. Un accès illimité risque la fuite sur des terminaux non gérés, possiblement compromis. Une interdiction pure et simple pousse aux contournements non sûrs comme le transfert vers une messagerie personnelle. Et envoyer les données en pièces jointes les disperse de façon incontrôlable sur des appareils que vous ne récupérerez jamais.

La confiance fondée sur l'emplacement réseau signifie qu'un seul point d'appui à l'intérieur ouvre un large déplacement latéral — un identifiant VPN hameçonné et l'attaquant est « à l'intérieur ». Le zero trust supprime la confiance implicite : chaque accès est authentifié, autorisé et réévalué en continu selon l'identité et la posture de l'appareil, avec moindre privilège et segmentation (NIST SP 800-207). Un second VPN ou un VPN élargi ne fait qu'étendre le même problème de confiance plate, et faire confiance au LAN plutôt qu'au VPN répète l'erreur initiale.

Les secrets doivent vivre dans un magasin géré avec contrôle d'accès, audit et rotation, injectés au runtime — jamais versionnés. Utilisez un gestionnaire de secrets (AWS Secrets Manager, HashiCorp Vault) et retirez les valeurs versionnées de l'historique, puis faites-les tourner car elles doivent être considérées comme compromises. Le base64 est de l'encodage, pas une protection — n'importe qui peut le décoder. Un dépôt privé répand quand même le secret à tous ceux qui ont l'accès en clone, plus les systèmes CI et les forks. Le compiler dans le binaire ne fait que cacher un secret toujours trivial à extraire.

Une clé statique intégrée à une image fuit facilement et vit éternellement ; la solution consiste à éliminer entièrement l'identifiant à longue durée de vie : attachez un rôle IAM via un profil d'instance, qui fournit des identifiants temporaires automatiquement renouvelés sans rien d'intégré. Une rotation manuelle tous les 90 jours laisse quand même un secret à longue durée de vie dans l'AMI entre les rotations. Déplacer la clé vers une variable d'environnement ne la rend ni moins statique ni moins exposée. L'envoyer par e-mail à l'équipe ops répand l'exposition dans les boîtes mail et les archives.

Un rôle d'instance surprivilégié transforme la moindre faille applicative — notamment une SSRF atteignant le service de métadonnées d'instance — en prise de contrôle complète du compte, car l'attaquant hérite des identifiants du rôle. Remplacez le wildcard par les seules actions et ARN de ressources réellement utilisés par la charge de travail, et imposez IMDSv2 pour durcir le point de terminaison de métadonnées. Un VPC ne contraint en rien l'IAM. Une seule règle de refus relève du jeu de la taupe et laisse tout le reste autorisé. Un répartiteur de charge n'a aucun rapport avec la portée d'impact de l'identifiant.

Ce qui compte, c'est l'impact : un identifiant de service réutilisé ou surprivilégié qui débloque l'admin du domaine ou des systèmes critiques est le constat qui compte, alors testez la réutilisation et cartographiez les privilèges et le chemin de mouvement latéral. Casser d'abord tous les autres hashs est une perte de temps qui retarde l'essentiel. Changer le mot de passe du compte de service est destructeur, casse la production et alerte les défenseurs. Envoyer un identifiant actif en clair par e-mail est en soi une exposition et une mauvaise hygiène opérationnelle.

Les dirigeants sont précisément les comptes que veulent les attaquants (BEC, fraude au virement), donc les exempter inverse le modèle de risque. Résolvez la friction, pas le contrôle : déployez des passkeys/FIDO2 résistants au phishing, plus rapides que les codes. Céder à la dérogation détruit la crédibilité du programme et laisse vos comptes de plus grande valeur sans protection. Abandonner le projet MFA, c'est renoncer à un contrôle de premier ordre. L'activer en douce dans leur dos détruit la confiance et la responsabilité.

Moindre privilège plus accès juste-à-temps : accordez le minimum de permissions nécessaires, limité dans le temps et journalisé, pour que le débogage soit possible sans admin permanent devenant un risque durable et un angle mort d'audit. Un cluster-admin permanent viole le moindre privilège et élargit le rayon d'impact de toute compromission. Un refus total bloque le travail légitime et invite à des contournements parallèles risqués. Partager l'identifiant commun du compte de service admin détruit la responsabilité — les actions ne sont plus rattachables à une personne.

Considérez tout secret poussé comme grillé : révoquez-le et faites-le tourner d'abord, car les bots scrutent les commits publics en quelques secondes, puis examinez CloudTrail pour détecter un abus et purgez-le de l'historique. Supprimer le commit ne sert à rien — la clé est déjà clonée, forkée et mise en cache par des tiers. Rendre le dépôt privé laisse une clé déjà divulguée et active aux mains des attaquants. Ajouter le fichier au .gitignore ne change rien à un secret déjà commité.

Validez avant d'escalader. Les VPN d'entreprise, les proxys cloud (CASB ou IP de service M365) et les opérateurs mobiles produisent régulièrement de faux « voyages impossibles » ; vérifiez donc les IP de sortie, le résultat MFA et l'appareil/user-agent avant d'agir. Verrouiller à chaque déclenchement provoque de la fatigue d'alertes et érode la confiance des utilisateurs envers le SOC. Supposer que c'est toujours un faux positif laisse passer une vraie compromission de compte. Écrire au manager est lent et n'est pas un contrôle — les journaux répondent plus vite et plus sûrement.

Supposez le mot de passe déjà compromis : forcez une réinitialisation ET invalidez les sessions et jetons actifs du compte, car un simple reset n'évince pas un attaquant qui détient déjà une session active ou un jeton de rafraîchissement. Chassez ensuite les connexions anormales, les invites MFA, les règles de boîte mail et les autorisations OAuth créées pendant la fenêtre d'exposition. Supprimer l'e-mail ou dire à l'utilisateur de changer son mot de passe « la prochaine fois » laisse le compte grand ouvert. Un scan antivirus traite le malware sur le poste, pas les identifiants volés dans le cloud.

Le credential stuffing rejoue des paires identifiant:mot de passe connues issues de fuites tierces, en pariant sur la réutilisation des mots de passe — taux de réussite élevé par tentative, souvent réparti sur de nombreuses IP et machines pour paraître humain. Le password spraying essaie un ou deux mots de passe courants (comme Winter2026!) sur de nombreux comptes afin de rester sous les seuils de verrouillage. Le stuffing exploite la réutilisation ; le spraying exploite les mots de passe partagés faibles. La MFA déjoue les deux.

Sous Windows, les hashes des comptes locaux (NTLM) résident dans la ruche SAM sous C:\Windows\System32\config\SAM, protégée tant que l'OS tourne ; les identifiants vivants se trouvent dans la mémoire de LSASS, et les hashes de domaine sont dans NTDS.dit sur un contrôleur de domaine. Sous Linux, les hashes sont dans /etc/shadow (lisible uniquement par root), tandis que /etc/passwd contient les métadonnées de compte. Les attaquants les volent pour casser les mots de passe hors ligne ou faire du pass-the-hash.

SPF publie quelles IP peuvent envoyer du courrier pour un domaine. DKIM ajoute une signature cryptographique pour que le destinataire puisse vérifier que le message n'a pas été altéré et provient bien du domaine. DMARC relie les résultats SPF/DKIM à l'en-tête From: visible via l'« alignement », dit aux destinataires quoi faire en cas d'échec (none/quarantine/reject) et envoie des rapports. SPF et DKIM seuls ne protègent pas le From que voit l'utilisateur — c'est DMARC qui l'impose.

DAC permet au propriétaire des données d'accorder l'accès à sa discrétion ; MAC applique l'accès de façon centralisée via des étiquettes/habilitations et est non discrétionnaire ; RBAC accorde l'accès via des rôles métier ; ABAC évalue des attributs (utilisateur, ressource, environnement) au regard d'une politique pour des décisions fines et contextuelles.

La classification étiquette les données par sensibilité afin que l'organisation applique des contrôles proportionnés à la valeur et au risque, évitant à la fois la sous-protection et la surprotection coûteuse. Le propriétaire des données (un rôle métier) fixe la classification et accepte le risque, tandis que le dépositaire des données (souvent l'IT) met en œuvre et maintient les contrôles de protection.

La due diligence est l'investigation et la compréhension continues des risques (savoir ce qu'il faut faire), tandis que la due care consiste à prendre les mesures raisonnables qu'une personne prudente prendrait pour y répondre (le faire réellement). La diligence est la recherche et la supervision ; la care est la mise en œuvre et le maintien.

La gestion du cycle de vie des identités encadre un compte de sa création à sa fin : attribution à l'arrivée (joiner), ajustement des droits lors d'un changement de rôle (mover), et suppression rapide au départ (leaver), avec des revues d'accès périodiques tout au long. Les défaillances les plus courantes sont l'accumulation de privilèges chez les movers et les comptes orphelins issus de suppressions manquées.

Une politique est l'énoncé obligatoire de haut niveau de l'intention de la direction ; une norme est une règle obligatoire et spécifique qui applique la politique (par exemple AES-256) ; une procédure est le mode opératoire obligatoire étape par étape ; une ligne directrice est une recommandation facultative. Les politiques, normes et procédures sont obligatoires, tandis que les lignes directrices sont discrétionnaires.

L'analyse quantitative attribue des valeurs monétaires concrètes pour calculer la perte attendue ; l'analyse qualitative classe le risque sur des échelles relatives (élevé/moyen/faible) par jugement d'expert. La quantitative utilise SLE = valeur de l'actif x facteur d'exposition, ARO = occurrences attendues par an, et ALE = SLE x ARO pour exprimer la perte annuelle attendue en euros.

Vous pouvez atténuer (réduire la probabilité/l'impact avec des contrôles), transférer (déplacer l'impact financier via une assurance ou des contrats), éviter (cesser entièrement l'activité risquée) ou accepter (tolérer sciemment le risque résiduel). Le choix dépend de l'appétit pour le risque et d'une comparaison coûts-bénéfices au regard de la perte attendue du risque.

Un utilisateur est une identité à longue durée de vie avec des identifiants permanents ; un rôle est une identité sans identifiants permanents que tout principal de confiance peut assumer pour obtenir des jetons à courte durée de vie ; une politique est le document JSON qui accorde des permissions, attaché à l'un ou l'autre. Le moindre privilège consiste à préférer les rôles aux utilisateurs, à restreindre les politiques à des actions et ressources précises, et à n'accorder que ce dont une tâche a besoin — puis à réviser et élaguer au fil du temps.

IMDS est un point d'accès link-local (169.254.169.254) qui fournit à une instance ses métadonnées, dont les identifiants temporaires de son rôle IAM attaché. La SSRF peut tromper le serveur pour qu'il récupère cette URL et fasse fuiter ces identifiants. IMDSv2 exige un PUT pour obtenir un jeton de session à courte durée de vie, définit une limite de saut (hop limit) / TTL IP par défaut de 1, et rejette les requêtes avec certains en-têtes — si bien qu'un simple GET de SSRF ne peut plus l'atteindre.

Les erreurs classiques sont des ACL publiques ou des politiques de bucket autorisant un accès anonyme ou à tous les utilisateurs AWS, des principaux trop larges ou des actions avec wildcard, l'absence de chiffrement par défaut et l'absence de journalisation. On les évite en activant le Block Public Access au niveau du compte, en utilisant des politiques IAM/bucket selon le moindre privilège, en imposant le chiffrement par défaut et TLS, et en activant la journalisation des accès et des règles Config pour détecter les dérives.

Stockez les secrets dans un service géré dédié (Secrets Manager, Parameter Store, Vault), chiffrés avec une clé KMS, et accordez l'accès via des rôles IAM pour que les charges de travail les récupèrent à l'exécution avec des identifiants à courte durée de vie. N'intégrez jamais de secrets dans le code, les images de conteneurs ou des fichiers .env versionnés. Ajoutez une rotation automatique, des politiques de clé restreintes et une journalisation d'audit pour que chaque récupération soit traçable.

Le fournisseur sécurise le cloud lui-même — centres de données physiques, matériel, hyperviseur et services gérés qu'il exploite. Vous sécurisez ce que vous mettez dans le cloud — vos données, identités, configurations, l'application des correctifs OS le cas échéant, et les contrôles d'accès. La frontière exacte se déplace : avec l'IaaS vous possédez l'OS et au-dessus, avec le SaaS vous possédez surtout les données et l'accès.

La CI/CD est de grande valeur car elle détient les identifiants de déploiement et exécute du code non fiable. Les risques incluent les dépendances et actions de build compromises, les secrets divulgués ou trop larges, les actions tierces mutables, et les runners ou la confiance OIDC surprivilégiés. Réduisez-les avec des dépendances épinglées et vérifiées, une fédération OIDC à courte durée de vie au lieu de clés à longue durée de vie, le moindre privilège restreint à des dépôts/branches précis, des runners éphémères isolés, et des artefacts signés à provenance tracée (SLSA).

Un JWT comporte trois parties en base64url — en-tête, charge utile (revendications) et signature — réunies par des points. Le serveur signe l'en-tête et la charge utile avec un secret ou une clé privée, et vérifie cette signature à chaque requête pour faire confiance aux revendications sans état de session côté serveur. Pièges : accepter alg=none, la confusion de clés RS256 vers HS256, ne pas valider l'expiration/l'émetteur/l'audience, mettre des secrets dans la charge utile lisible, et l'absence de voie de révocation.

Kerberos repose sur un centre de distribution de clés (KDC) de confiance. Le client s'authentifie une fois auprès du serveur d'authentification et obtient un ticket d'octroi de tickets (TGT) chiffré avec la clé du KDC. Pour atteindre un service, il présente le TGT au service d'octroi de tickets et reçoit un ticket de service chiffré avec la clé de ce service. Le service le déchiffre et lui fait confiance. Les mots de passe ne traversent jamais le réseau, et les tickets ont une durée limitée.

L'application redirige l'utilisateur vers le serveur d'autorisation pour se connecter et consentir. Le serveur redirige avec un code d'autorisation de courte durée. Le backend de l'application échange ensuite ce code (plus son secret client) au point de terminaison de jeton contre un jeton d'accès, via un canal arrière de serveur à serveur. Cela garde les jetons hors du navigateur/de l'URL. Les clients publics ajoutent PKCE pour lier le code au demandeur initial.

Stockez les mots de passe avec une fonction de hachage de mots de passe délibérément lente, salée et adaptative — bcrypt, scrypt ou Argon2 — jamais un hachage générique rapide comme SHA-256 ou MD5. Les hachages rapides sont conçus pour la vitesse, donc des attaquants avec des GPU peuvent tester des milliards d'essais par seconde contre une base de données fuitée. Les hachages lents ont un facteur de travail ajustable (et un coût mémoire) qui rend chaque essai coûteux, gardant le brute force impraticable même après une fuite.

Le client construit une chaîne du certificat serveur (feuille) en remontant par une ou plusieurs autorités de certification intermédiaires jusqu'à une autorité racine de son magasin de confiance. Il vérifie la signature de chaque certificat avec la clé publique de l'émetteur suivant, contrôle les dates de validité, la correspondance du nom/nom d'hôte, l'usage de la clé et la révocation (CRL/OCSP). La confiance se termine à une racine auto-signée pré-approuvée ; la chaîne n'est valide que si chaque maillon est correct.

Un sel est une valeur aléatoire unique générée par utilisateur et combinée au mot de passe avant le hachage. Il garantit que des mots de passe identiques produisent des hachages différents et rend inutiles les attaques précalculées comme les tables arc-en-ciel, puisque l'attaquant aurait besoin d'une table distincte par sel. Les sels sont stockés à côté du hachage. Un poivre est une valeur secrète supplémentaire, la même pour tous les utilisateurs, conservée séparément (par exemple, dans la config de l'application ou un HSM) de sorte qu'une fuite de base de données seule ne suffise pas.

Le SSO centralise l'authentification chez un fournisseur d'identité (IdP). Quand un utilisateur visite un fournisseur de service (l'application), l'application redirige vers l'IdP ; l'utilisateur se connecte une fois, et l'IdP renvoie une assertion ou un jeton signé attestant son identité. SAML porte cela comme une assertion XML signée ; OIDC le porte comme un jeton d'identité JSON signé posé sur OAuth 2.0. L'application fait confiance à la signature de l'IdP plutôt que de gérer elle-même les mots de passe.

TOTP (mot de passe à usage unique basé sur le temps) combine un secret partagé, établi à l'enrôlement, avec l'heure courante divisée en fenêtres fixes (généralement 30 secondes). Il exécute HMAC sur le compteur de pas de temps avec le secret, puis tronque le résultat en un code à 6 chiffres. L'application et le serveur détiennent tous deux le même secret et la même horloge, donc ils calculent indépendamment le même code — aucun appel réseau nécessaire. Le code change à chaque fenêtre.

La triade CIA désigne les trois objectifs fondamentaux de la sécurité de l'information : la confidentialité (seules les parties autorisées peuvent lire les données), l'intégrité (les données ne sont pas modifiées sans autorisation) et la disponibilité (les utilisateurs autorisés accèdent aux systèmes quand ils en ont besoin). Presque chaque contrôle se rattache à un ou plusieurs de ces objectifs.

La défense en profondeur consiste à superposer plusieurs contrôles de sécurité indépendants afin que, si l'un échoue, les autres protègent encore l'actif. Elle suppose qu'aucun contrôle n'est parfait — par exemple en combinant pare-feu, segmentation réseau, protection des terminaux, MFA, moindre privilège et chiffrement, plutôt que de se fier au seul périmètre.

Le moindre privilège signifie que chaque utilisateur, processus et service ne reçoit que l'accès minimal requis pour sa tâche, et rien de plus. Cela limite le rayon d'impact d'un compte compromis, réduit le risque de menace interne et diminue la surface d'attaque. On l'applique via l'accès basé sur les rôles, des revues d'accès régulières et l'élévation juste-à-temps.

La MFA exige au moins deux facteurs d'authentification de catégories différentes — quelque chose que vous savez (mot de passe), quelque chose que vous possédez (téléphone/jeton), quelque chose que vous êtes (biométrie). Elle aide car un attaquant qui vole un facteur, comme un mot de passe, ne peut toujours pas se connecter sans les autres. La MFA résistante à l'hameçonnage comme FIDO2 est la plus forte.

L'hameçonnage est une ingénierie sociale qui pousse les gens à révéler des identifiants, envoyer de l'argent ou exécuter un malware, généralement via de faux e-mails ou sites. La défense est en couches : filtrage et authentification des e-mails (SPF/DKIM/DMARC), MFA pour limiter les dégâts d'identifiants volés, formation de sensibilisation, et un moyen simple de signaler les messages suspects.

L'UEBA (User and Entity Behaviour Analytics) construit des référentiels comportementaux pour les utilisateurs et les entités (hôtes, comptes de service, appareils) et utilise des statistiques ou l'apprentissage automatique pour scorer les écarts comme du risque. Elle excelle face aux menaces sans signature nette : identifiants compromis, abus interne et déplacement latéral — p. ex. un utilisateur accédant soudain à des systèmes qu'il ne touche jamais, à des heures inhabituelles, ou déplaçant des volumes de données anormaux. Elle complète la détection basée sur des règles plutôt que de la remplacer, et nécessite un ajustement pour éviter les faux positifs dus aux changements de comportement légitimes.

Les revues d'accès (recertification) sont des vérifications périodiques où un propriétaire responsable confirme que l'accès de chaque personne reste justifié, et révoque ce qui ne l'est pas. Elles constituent le filet de sécurité qui détecte la dérive de privilèges, les comptes orphelins et les droits accordés pour un projet terminé. Le contrôle ne fonctionne que si un propriétaire compétent — généralement le manager ou le propriétaire de la ressource — examine réellement l'accès au lieu de le valider machinalement, et si les révocations sont appliquées.

L'accès conditionnel fait dépendre la décision d'accès du contexte plutôt que d'une règle fixe. Il évalue des signaux — qui est l'utilisateur, la conformité de l'appareil, la localisation, l'application et un score de risque calculé par détection d'anomalies — et répond proportionnellement : autoriser, bloquer ou exiger un renforcement comme la MFA ou un appareil conforme. L'accès basé sur le risque est la variante dynamique où un signal de risque en temps réel pilote la politique.

La fédération d'identités établit une relation de confiance entre un fournisseur d'identité (IdP) qui authentifie les utilisateurs et des fournisseurs de services (parties de confiance) qui consomment cette authentification. L'IdP vérifie l'utilisateur et émet une assertion ou un jeton signé ; le fournisseur de services lui fait confiance au lieu de gérer ses propres identifiants. Cela permet le SSO inter-domaines et un contrôle centralisé, mais concentre le risque : compromettez l'IdP et vous compromettez tout ce qui lui fait confiance.

L'accès juste-à-temps accorde des privilèges élevés uniquement quand c'est nécessaire, pour une durée limitée, généralement avec approbation — puis ils expirent automatiquement, de sorte qu'il n'y a aucun privilège permanent à voler. Les comptes bris de glace sont l'exception délibérée : des comptes d'urgence très privilégiés, normalement dormants, verrouillés derrière des contrôles stricts et de fortes alertes, utilisés uniquement quand les chemins d'accès normaux échouent. Le JIT réduit la surface d'attaque quotidienne ; le bris de glace garantit que vous pouvez encore entrer en cas de crise.

Le NIST SP 800-63B moderne privilégie la longueur à la complexité : autoriser de longues phrases secrètes (au moins 8, en prendre en charge 64+), accepter tous les caractères y compris les espaces, et ne pas imposer de règles de composition comme « une majuscule, un symbole ». Filtrer les nouveaux mots de passe contre les listes de mots de passe compromis, abandonner l'expiration périodique obligatoire (renouveler uniquement en cas de preuve de compromission), et abandonner les « questions de sécurité » fondées sur la connaissance. Le but : des règles qui résistent aux vraies attaques au lieu d'agacer les utilisateurs vers des schémas prévisibles.

La MFA résistante au hameçonnage signifie que le second facteur ne peut pas être rejoué contre le vrai site même si l'utilisateur est trompé. Les passkeys FIDO2/WebAuthn y parviennent grâce à une cryptographie à clé publique liée à l'origine : l'authentificateur signe un défi lié au domaine du vrai site, de sorte qu'un identifiant capturé par un site sosie ou un attaquant-au-milieu est inutile. Les codes TOTP et les invites par notification restent hameçonnables car ils peuvent être relayés en temps réel.

Le PAM contrôle et surveille les comptes qui peuvent causer le plus de dégâts — administrateurs de domaine, root, comptes de service. Il met en coffre et fait tourner leurs identifiants pour qu'aucun secret ne soit partagé ou codé en dur, courtise les sessions pour que les administrateurs ne voient jamais le mot de passe brut, enregistre ce que font les utilisateurs privilégiés, et accorde idéalement l'élévation juste-à-temps plutôt qu'un accès permanent. L'objectif est de réduire le rayon d'impact des comptes que les attaquants convoitent le plus.

Le RBAC accorde des permissions via des rôles assignés aux utilisateurs — simple à raisonner mais sujet à l'explosion des rôles à mesure que les cas particuliers se multiplient. L'ABAC évalue des politiques sur les attributs de l'utilisateur, de la ressource, de l'action et de l'environnement, ce qui permet des décisions fines et contextuelles au prix de la complexité. La plupart des systèmes matures les combinent : des rôles pour les octrois grossiers, des attributs et des politiques pour les détails conditionnels.

SCIM (System for Cross-domain Identity Management) est une API REST/JSON et un schéma standard pour créer, mettre à jour et supprimer des comptes utilisateurs entre applications. Relié à un système RH ou à un IdP, il automatise le cycle de vie joiner-mover-leaver : les comptes et droits sont provisionnés à l'embauche, ajustés au changement de poste, et — surtout — déprovisionnés au départ, éliminant les comptes orphelins que les attaquants adorent.

Gardez les jetons d'accès à courte durée de vie (quelques minutes) pour qu'un jeton volé expire vite, et utilisez des jetons de rafraîchissement à plus longue durée pour obtenir de nouveaux jetons d'accès sans re-solliciter l'utilisateur. Faites tourner les refresh tokens à chaque utilisation et détectez la réutilisation d'un jeton consommé comme un signal de vol, en révoquant la chaîne. L'objectif est d'équilibrer la limitation de la fenêtre d'un jeton compromis sans forcer les utilisateurs à se réauthentifier sans cesse.

Le Zero Trust abandonne l'hypothèse selon laquelle être à l'intérieur du réseau vous rend digne de confiance. Chaque requête vers une ressource est authentifiée et autorisée pour elle-même — en vérifiant l'identité, l'état de santé de l'appareil et le contexte — par un point de décision de politique, accordant un accès au moindre privilège par session. Il n'y a pas de zone interne de confiance ; l'emplacement réseau d'une requête n'est qu'un signal, pas un laissez-passer.

Une analyse de risque identifie les actifs et leur valeur, les menaces et vulnérabilités qui pourraient les affecter, puis estime le risque comme une fonction de la vraisemblance et de l'impact. On peut la mener qualitativement (élevé/moyen/faible, rapide et subjectif) ou quantitativement (SLE × ARO = ALE, fondé sur des données mais plus difficile). Des référentiels comme NIST RMF et ISO 27005 lui donnent une structure, et la sortie alimente le traitement du risque : atténuer, transférer, éviter ou accepter.

Énumérez les privilèges du compte et les mauvaises configurations de l'hôte : privilèges de jeton comme SeImpersonate, chemins de service non entre guillemets, permissions de service faibles, AlwaysInstallElevated et identifiants stockés. Puis abusez du plus fiable — l'usurpation de jeton (attaques Potato) est une voie courante vers SYSTEM.

La défense en profondeur consiste à superposer plusieurs contrôles de sécurité indépendants pour que, si l'un échoue, les autres protègent encore l'actif. Aucun contrôle n'est supposé parfait, on empile donc des mesures préventives, de détection et de réponse sur les couches réseau, hôte, application et données.

Le moindre privilège signifie que chaque utilisateur, processus ou service ne reçoit que l'accès minimal nécessaire à sa tâche, et rien de plus. Cela réduit le rayon d'impact de toute compromission ou erreur. On l'applique avec l'accès basé sur les rôles, l'élévation juste-à-temps, des revues d'accès régulières et la suppression des droits administrateurs permanents.

Ne jamais coder en dur les secrets dans le code source ni les committer dans git. Les stocker dans un gestionnaire de secrets ou un coffre-fort dédié, les injecter à l'exécution, restreindre l'accès au moindre privilège, les faire tourner régulièrement, et préférer des identifiants dynamiques à courte durée de vie aux identifiants statiques persistants. Auditer chaque accès.

Imposer TLS partout, authentifier chaque requête (par exemple des jetons OAuth2/OIDC) et autoriser par objet pour que les utilisateurs n'atteignent que leurs propres données. Ajouter la validation des entrées, la limitation de débit et les quotas, la validation de schéma et une journalisation approfondie. La faille d'API la plus courante est l'autorisation au niveau objet défaillante, vérifiez donc la propriété à chaque accès à une ressource.

La segmentation divise un réseau en zones isolées pour qu'une intrusion dans l'une ne puisse pas atteindre librement les autres, limitant le mouvement latéral. Le zero trust va plus loin : il supprime entièrement la confiance implicite fondée sur l'emplacement réseau, en authentifiant et autorisant chaque requête où qu'elle provienne — la microsegmentation est l'un des moyens de l'implémenter.

La force brute cible un seul compte avec de nombreuses tentatives de mot de passe, on voit donc beaucoup d'échecs concentrés sur un même identifiant. Le password spray inverse la logique : un ou quelques mots de passe courants essayés sur de nombreux comptes, lentement et discrètement, de sorte que chaque compte ne voit que quelques échecs. Le signal de détection est le ratio comptes/échecs et le timing, pas le nombre brut d'échecs.

Le mouvement latéral, c'est un attaquant qui utilise un point d'appui pour atteindre d'autres systèmes. Les signes incluent des logons réseau inattendus (type 3) et RDP (type 10), l'accès aux partages admin comme C$ et ADMIN$, des outils d'exécution distante tels que PsExec, WMI et WinRM, des motifs de pass-the-hash, et un compte normalement local qui s'authentifie soudain sur de nombreux hôtes.

Confirmez que l'alerte est réelle avant d'agir : lisez ce qui s'est déclenché et pourquoi, puis enrichissez — qui est l'utilisateur, l'IP/géo/appareil source sont-ils attendus, est-ce un voyage impossible, y a-t-il eu des échecs antérieurs ? Classez en vrai ou faux positif, escaladez ou confinez si c'est réel (désactiver la session, forcer une réinitialisation MFA), et documentez tout pour que le prochain analyste puisse suivre votre raisonnement.

HTTP est sans état — chaque requête est indépendante et n'a aucune mémoire des précédentes. Les sessions ajoutent un état par-dessus : après la connexion, le serveur émet un identifiant que le navigateur stocke dans un cookie et rejoue à chaque requête. Les sessions côté serveur conservent l'état sur le serveur, indexé par un ID de session opaque ; les jetons sans état comme les JWT mettent un état signé dans le jeton lui-même afin que le serveur puisse vérifier sans stockage.