« Écrire MFA dans une politique prouve que l’accès est protégé. »
Une exigence déclarée n’établit ni l’enrôlement, ni l’application, ni la résistance au contournement, ni la gestion des sessions.
01Observe les quatre contextes
column -s, -t "$lab/source/authentication/privileged-auth-policy.csv"SORIA Distribution distingue :
- compte quotidien humain ;
- compte administratif humain ;
- compte de service non interactif ;
- compte d’urgence à double contrôle.
Une politique identique pour tous mélangerait des usages incompatibles.
02Fixe l’exigence cible
Pour l’administration humaine :
identité administrative nommée
facteur renforcé représenté
session limitée et attribuable
chemin d'administration approuvé
exception documentée si preuve absentePour les services :
aucun login interactif
référence de secret ou identité de workload
propriétaire et périmètre
rotation et révocationPour l’urgence : double responsabilité, durée maximale, alerte, expiration et revue post-usage.
03Manipule la revue
column -s, -t "$lab/output/authentication-review.csv"Le champ proof_state=declared entraîne WITH_ACTIONS. Le lab refuse de transformer une phrase de politique en preuve d’application.
04Teste positivement
Le test positif vérifie que la ligne privileged-admin contient une exigence MFA ou une exception explicite. Il vérifie également que la ligne service interdit l’interactif.
Ce test contrôle la complétude du dossier de décision.
05Teste négativement
Une identité de service interactive est interdite dans l’état cible. Une fixture négative avec un compte de service orphelin ou interactif doit être rejetée.
Le résultat de référence inclut :
Negative test blocked: orphan service accountLe même principe s’applique à une exception sans propriétaire, expiration ni action.
06Préserve la fonction
Renforcer l’authentification ne doit pas rendre l’administration impossible. Le test fonctionnel vérifie qu’un chemin autorisé reste représenté pour l’application, l’annuaire et le réseau.
La disponibilité d’un compte d’urgence ne justifie pas son usage quotidien.
07Prépare le retour et la révocation
Avant une modification réelle :
administrateurs de test identifiés
accès de secours contrôlé
précheck d'enrôlement
critère d'arrêt
procédure de récupération
révocation des anciennes méthodes
preuve après changementLe rollback ne doit pas réactiver un facteur compromis. Il peut restaurer une méthode de secours préautorisée pendant une fenêtre bornée.
08Conserve les limites
La CI ne tente aucune authentification et ne prouve pas :
MFA réellement exigé
résistance au phishing
session réellement limitée
authentification SSO ou PAM configurée
alerte d'urgence réellement émiseL’artefact attendu est authentication-review.csv avec les exceptions et actions restantes.
Rédige quatre exigences d’authentification
Pour chaque type de compte, indique méthode cible, usage interactif, preuve attendue, test négatif, conséquence fonctionnelle, secours, révocation et limite.
✓À retenir
Une politique d’authentification n’est validée que lorsque son application, son usage fonctionnel et ses voies de secours sont prouvés dans le périmètre autorisé.