Politique Mots de Passe ISO 27001 : Modèle Word [NIST + ANSSI]

La politique de mots de passe est l'un des documents de sécurité les plus connus et les plus mal rédigés des organisations. Pendant des années, la doctrine dominante imposait des mots de passe complexes (majuscules, chiffres, caractères spéciaux) avec rotation obligatoire tous les 90 jours — une approche que les recommandations actuelles du NIST (SP 800-63B) et de l'ANSSI ont profondément remise en question. Les recherches montrent que cette approche "complexité + rotation forcée" conduit les utilisateurs à choisir des mots de passe faibles mais mémorables (P@ssw0rd1, P@ssw0rd2...) ou à les noter physiquement, ce qui réduit paradoxalement la sécurité. Le contrôle A.5.17 d'ISO/IEC 27001:2022 (Authentication information) et le contrôle A.8.5 (Secure authentication) encadrent les exigences d'authentification. La doctrine moderne repose sur trois piliers : longueur plutôt que complexité (14 caractères minimum, frases de passe recommandées), rotation conditionnelle uniquement en cas de suspicion de compromission (pas systématique), et authentification multi-facteurs (MFA) comme priorité absolue pour les accès sensibles. Ce modèle Word, développé par Ayi NEDJIMI, consultant cybersécurité Lead Implementer ISO 27001, intègre ces évolutions doctrinales tout en restant conforme aux exigences ISO 27001:2022, et couvre les règles différenciées par profil d'utilisateur : comptes standards, comptes administrateurs, comptes à privilèges, comptes de service, et comptes invités. La politique de mots de passe s'articule avec la politique de gestion des accès logiques et la charte d'utilisation du SI pour former un dispositif cohérent d'authentification et de contrôle d'accès.

Contexte réglementaire et normatif

ISO/IEC 27001:2022 — Contrôles A.5.17 et A.8.5

Le contrôle A.5.17 (Authentication information) impose de gérer les informations d'authentification secrètes (mots de passe, tokens, clés) selon un processus formel, incluant la distribution sécurisée des mots de passe initiaux, l'obligation pour les utilisateurs de changer le mot de passe à la première connexion, et l'interdiction de noter les mots de passe. Le contrôle A.8.5 (Secure authentication) impose que les systèmes d'authentification contrôlent l'accès selon une politique définie, n'affichent pas les mots de passe à l'écran, ne transmettent pas les mots de passe en clair, stockent les mots de passe de manière sécurisée (hachage avec sel), et bloquent les comptes après un nombre défini de tentatives échouées.

NIST SP 800-63B — Digital Identity Guidelines (Authenticator et Lifecycle)

Le NIST Special Publication 800-63B est la référence internationale pour les bonnes pratiques d'authentification. Sa révision de 2017 (et les mises à jour ultérieures) a introduit des changements majeurs par rapport aux anciennes recommandations : longueur minimum de 8 caractères (mais 14+ recommandé), vérification contre les listes de mots de passe compromis (Have I Been Pwned, dictionnaires communs), suppression de la rotation périodique obligatoire au profit d'une rotation conditionnelle (uniquement en cas de suspicion de compromission), et autorisation de tous les caractères Unicode pour les mots de passe. La révision 2024 du NIST SP 800-63B renforce encore ces recommandations, notamment en imposant une longueur minimum de 15 caractères pour les comptes gouvernementaux.

Recommandations ANSSI — Guide "Recommandations relatives à l'authentification multicanal"

L'ANSSI recommande dans ses guides de 2021 et 2022 une politique d'authentification basée sur la robustesse des mots de passe (passphrase de 4-5 mots, ou mot de passe d'au moins 14 caractères avec complexité) et le déploiement du MFA pour tous les accès distants et privilégiés. L'ANSSI considère que le MFA réduit de plus de 99% le risque de compromission par phishing et force brute, et recommande sa généralisation progressive à tous les comptes (pas uniquement les admins).

Structure détaillée de la politique de mots de passe

Section 1 — Principes généraux et philosophie

Rappel des fondements de la politique : priorisation de la longueur sur la complexité arbitraire, rotation conditionnelle plutôt que périodique, MFA comme mesure de sécurité complémentaire prioritaire, et sensibilisation des utilisateurs à l'usage d'un gestionnaire de mots de passe. Cette section donne le contexte aux utilisateurs et facilite l'adhésion en expliquant le "pourquoi" des règles.

Section 2 — Règles par profil d'utilisateur

Les règles de mots de passe doivent être différenciées selon le profil : compte standard (collaborateur), compte administrateur (IT/réseau), compte à privilèges élevés (DBA, sécurité, architecture), compte de service (application/automatisation), et compte invité/temporaire. Plus les privilèges sont élevés, plus les exigences de robustesse et de MFA sont strictes.

Section 3 — Stockage et transmission des mots de passe

Exigences techniques pour le stockage et la transmission : hachage obligatoire avec bcrypt/Argon2id/PBKDF2 (pas de stockage en clair ou avec MD5/SHA-1), transmission uniquement sur des canaux chiffrés (HTTPS/TLS), interdiction de transmettre les mots de passe dans des emails non chiffrés, et utilisation d'un gestionnaire de mots de passe d'entreprise recommandée (Bitwarden for Business, CyberArk, Keepass Team).

Section 4 — Gestion du cycle de vie

Procédures pour chaque événement : création d'un compte (mot de passe temporaire sécurisé à usage unique, obligation de changement à la première connexion), réinitialisation de mot de passe oublié (procédure sécurisée, vérification d'identité préalable), suspicion de compromission (rotation immédiate, notification SSI), départ d'un collaborateur (désactivation immédiate, rotation des mots de passe partagés).

Tableau des règles par profil d'utilisateur

Guide d'utilisation étape par étape

1. Auditer les règles actuelles vs recommandations NIST/ANSSI : avant de mettre à jour la politique, auditez les règles en place dans vos systèmes d'authentification (Active Directory, Azure AD/Entra ID, applications métier). Identifiez les règles obsolètes (rotation à 90 jours systématique, complexité sans longueur minimum, etc.) et les écarts avec les recommandations actuelles.
2. Déployer un gestionnaire de mots de passe d'entreprise : la principale résistance à l'adoption d'une politique de mots de passe robuste est la difficulté de mémoriser des mots de passe longs. Un gestionnaire de mots de passe d'entreprise (Bitwarden Teams, 1Password Business, CyberArk) résout ce problème en permettant des mots de passe uniques et forts pour chaque compte. Le déploiement d'un gestionnaire de mots de passe est souvent la mesure préliminaire la plus importante avant d'augmenter les exigences de longueur.
3. Déployer le MFA pour les comptes prioritaires : commencez par déployer le MFA sur les comptes les plus sensibles (admins IT, RSSI, direction, accès distants) avant de l'étendre progressivement à tous les collaborateurs. Les technologies MFA recommandées : TOTP (Google Authenticator, Authy) pour un déploiement simple, clés hardware FIDO2/WebAuthn (YubiKey, clé FIDO2) pour les comptes à très hauts privilèges, et notifications push (Microsoft Authenticator, Duo) pour le confort utilisateur.
4. Mettre en place une liste noire de mots de passe : bloquez les mots de passe communs et compromis grâce à des outils de filtrage (Azure AD Password Protection, Have I Been Pwned API, ou des listes de mots de passe compromis comme rockyou.txt). Cette mesure est souvent plus efficace que les règles de complexité arbitraires.
5. Former les utilisateurs à la nouvelle doctrine : la transition vers une politique "longueur + gestionnaire + MFA" nécessite une communication pédagogique. Expliquez aux utilisateurs pourquoi les anciennes règles étaient contre-productives et comment un gestionnaire de mots de passe leur simplifie la vie tout en renforçant la sécurité.
6. Mettre en place une surveillance des compromissions : abonnez-vous à des services d'alerte de compromission (Have I Been Pwned, services d'intelligence sur les credential dumps) pour être notifié si des identifiants de votre organisation apparaissent dans des fuites de données. Ces alertes déclenchent la rotation des mots de passe concernés.

Points de vigilance pour l'audit de certification

1. Politique de rotation tous les 90 jours encore en place : une rotation systématique à 90 jours sans MFA est une pratique considérée comme contreproductive par les référentiels actuels (NIST SP 800-63B, ANSSI). Un auditeur de certification ISO 27001 peut soulever une observation sur une politique obsolète. Remédiation : mettez à jour la politique pour une rotation conditionnelle et concentrez les efforts sur le déploiement du MFA.
2. Mots de passe partagés entre plusieurs utilisateurs : les comptes partagés (ex. : compte "admin" connu de 5 personnes) rendent l'imputabilité impossible et représentent un risque élevé. Remédiation : supprimez tous les comptes partagés, créez des comptes nominatifs, et utilisez un PAM (Privileged Access Management) pour les accès à hauts privilèges.
3. Mots de passe de comptes de service en clair dans les configs : c'est une pratique très répandue et très risquée. Les mots de passe de comptes de service stockés en clair dans des fichiers de configuration (scripts, fichiers .env, répertoires applicatifs) sont facilement extraits lors d'une compromission. Remédiation : utilisez un outil de gestion des secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) pour injecter les secrets en mémoire au moment de l'exécution.
4. Absence de blocage sur nombre de tentatives échouées : si vos systèmes n'implémentent pas de mécanisme de blocage (ou de ralentissement — rate limiting) après X tentatives échouées, ils sont vulnérables aux attaques par force brute. Remédiation : configurez le blocage de compte après 5 à 10 tentatives échouées (avec déblocage sécurisé) et les alertes SIEM correspondantes.

Questions fréquentes

Faut-il encore imposer une complexité minimale (majuscules, chiffres, caractères spéciaux) ?

La question est plus nuancée qu'il n'y paraît. Le NIST SP 800-63B de 2017 a supprimé l'obligation de complexité arbitraire, au profit de la longueur. Les raisons : les règles de complexité (au moins 1 majuscule, 1 chiffre, 1 spécial) conduisent à des schémas prévisibles (P@ssw0rd1!) que les attaquants connaissent et intègrent dans leurs listes d'attaque. Un mot de passe de 14 caractères minuscules aléatoires est cryptographiquement plus fort qu'un mot de passe de 8 caractères avec tous les types de caractères requis. La doctrine actuelle recommande : longueur minimum 14+ caractères (ou passphrase de 4-5 mots), vérification contre les listes de mots compromis et courants, et si des règles de complexité sont maintenues pour des raisons organisationnelles, qu'elles ne réduisent pas la longueur minimum. En pratique, pour des raisons d'acceptabilité utilisateur et d'intégration avec les systèmes existants (Active Directory Group Policy), beaucoup d'organisations maintiennent des règles de complexité en combinaison avec une longueur augmentée.

Le MFA peut-il remplacer une politique de mots de passe ?

Le MFA ne remplace pas la politique de mots de passe — les deux sont complémentaires. Le MFA réduit considérablement (de plus de 99% selon Microsoft) le risque de compromission par phishing et force brute sur le mot de passe. Mais si le MFA tombe en panne ou n'est pas disponible, le mot de passe reste le dernier rempart. De plus, certains systèmes ne supportent pas encore le MFA (systèmes legacy, services automatisés, API). Pour ces systèmes, la politique de mots de passe reste la seule protection. En pratique, une organisation mature déploie MFA pour tous les accès sensibles ET maintient une politique de mots de passe robuste pour tous les comptes. Le MFA sur des mots de passe très faibles reste vulnérable aux attaques avancées (MFA bypass, SIM swapping, attaques d'ingénierie sociale ciblées).

Comment gérer les mots de passe des comptes de service ?

Les comptes de service (comptes applicatifs, comptes d'automatisation, service accounts Active Directory) sont souvent les comptes les moins bien gérés dans les organisations : leur mot de passe n'est jamais changé, souvent stocké en clair dans des scripts, et difficile à faire tourner sans risquer de casser des services en production. La bonne pratique moderne est de ne plus utiliser de mots de passe pour les comptes de service, mais plutôt : des Managed Service Accounts (MSA ou gMSA dans Active Directory) pour les services Windows — leur mot de passe est géré automatiquement par Active Directory, des Service Principal et Workload Identity pour les services cloud (Azure, AWS, GCP) — authentification sans mot de passe basée sur des certificats ou des identités managées, un gestionnaire de secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) pour les applications qui ont besoin de credentials — les secrets sont injectés en mémoire au démarrage sans être stockés en clair dans les configurations. Pour les systèmes legacy qui ne supportent pas ces alternatives, utilisez des mots de passe longs (32+ caractères), aléatoires, stockés dans un PAM (CyberArk, Delinea), avec rotation automatisée régulière.

Comment accompagner le déploiement du MFA sans dégrader l'expérience utilisateur ?

La résistance au MFA est souvent liée à la perception d'une complexité accrue. Plusieurs approches permettent de faciliter l'adoption. Choisissez une solution MFA adaptée à l'usage : les notifications push (Microsoft Authenticator, Duo Push) sont plus fluides que la saisie manuelle d'un code TOTP pour les usages bureautiques courants. Implémentez des exemptions conditionnelles pour réduire la friction : depuis l'IP du bureau connue, le MFA n'est demandé qu'une fois par semaine ; depuis un pays ou une IP inconnue, le MFA est toujours demandé. Utilisez le Conditional Access (Azure AD/Entra ID) ou des politiques Zero Trust pour adapter le niveau d'authentification au risque évalué du contexte de connexion. Formez les utilisateurs avec un tutoriel clair d'inscription au MFA, et prévoyez une procédure simple de récupération en cas de perte du device d'authentification. Déployez progressivement, en commençant par les directions les plus sensibles, et communiquez sur la date de généralisation à tous avec un délai suffisant.

Pour aller plus loin

• Politique de gestion des accès logiques ISO 27001 (A.5.15-18)
• Charte d'utilisation du SI — Modèle ISO 27001
• Politique de cryptographie ISO 27001 (A.8.24) — Algorithmes ANSSI
• Politique de télétravail et BYOD ISO 27001
• Notre service d'accompagnement ISO 27001 complet

Gestion des exceptions et cas particuliers dans la politique de mots de passe ISO 27001

Toute politique de mots de passe, aussi rigoureuse soit-elle, doit prévoir un cadre formel de gestion des exceptions. Dans le contexte de la conformité ISO 27001, l'annexe A.9 impose une approche documentée et traçable de chaque dérogation accordée. Ignorer cette dimension revient à créer des failles systémiques qui fragilisent l'ensemble du système de management de la sécurité de l'information.

Les comptes de service constituent le premier cas particulier incontournable. Contrairement aux comptes utilisateurs, les comptes de service ne peuvent pas toujours bénéficier d'une rotation automatique des mots de passe sans risquer d'interrompre des processus critiques. La bonne pratique consiste à documenter précisément chaque compte de service, à appliquer des mots de passe d'une longueur minimale de 25 caractères, à stocker ces secrets dans un coffre-fort dédié comme HashiCorp Vault ou CyberArk, et à mettre en œuvre une surveillance renforcée des connexions associées.

Les comptes d'urgence (break-glass accounts) représentent un deuxième cas sensible. Ces comptes administrateurs de dernier recours doivent exister, mais leur gestion doit répondre à des exigences strictes : enveloppe scellée physique, procédure d'ouverture en double contrôle, notification immédiate du RSSI à chaque utilisation, et audit systématique après emploi. L'ISO 27001 exige que ces procédures soient testées au minimum une fois par an lors des exercices de continuité d'activité.

La question de l'authentification multifacteur s'articule directement avec la politique de mots de passe. Une organisation mature sous ISO 27001 devrait progressivement réduire la complexité exigée pour les mots de passe au profit d'un MFA robuste, conformément aux recommandations NIST SP 800-63B qui ont abandonné les exigences de complexité arbitraire en 2017. Cette évolution doit être formellement documentée dans la politique et justifiée dans le traitement des risques.

Indicateurs de performance et amélioration continue de la politique de mots de passe

La politique de mots de passe ne vit pas en isolation : elle s'inscrit dans un ensemble de contrôles compensatoires à orchestrer. Le verrouillage des comptes après un nombre défini de tentatives échouées protège contre les attaques par force brute, mais doit être calibré pour éviter des dénis de service involontaires sur les comptes critiques. La durée de verrouillage est un paramètre de risque à documenter explicitement dans la politique.

Le monitoring des comportements d'authentification anormaux complète efficacement la politique. Des outils SIEM configurés pour alerter sur les connexions hors des plages horaires habituelles, les tentatives depuis des géolocalisations inhabituelles, ou les séquences d'échecs répétés permettent de détecter en temps réel des tentatives de compromission. Ces alertes doivent être intégrées dans les procédures de réponse aux incidents du SMSI.

Pour mesurer l'efficacité de la politique, les indicateurs clés de performance recommandés incluent : le taux de comptes avec mots de passe expirés, le délai moyen de remédiation après détection d'un mot de passe compromis, le pourcentage de comptes avec MFA activé sur les accès privilégiés, et le nombre d'exceptions actives avec justification documentée. Ces métriques alimentent directement les revues de direction imposées par l'ISO 27001 et démontrent l'amélioration continue du contrôle.

La politique doit intégrer une procédure claire de réponse aux signalements de compromission. Lorsqu'un utilisateur suspecte que son mot de passe a été divulgué, la procédure de réinitialisation d'urgence doit être accessible rapidement, documentée dans la politique, et testée lors des exercices de sensibilisation annuels. La traçabilité de ces signalements constitue une preuve d'amélioration continue précieuse lors des audits de certification ISO 27001.