Repères · Tous niveaux · Relecture documentaire : 2 octobre 2026. Les exemples sont génériques ; adapter les noms, versions et chemins avant toute modification.
Utiliser des comptes nominatifs pour les personnes et des comptes distincts pour les services. Attribuer seulement les droits nécessaires et conserver un inventaire de leurs propriétaires. Un compte partagé rend l’attribution des actions et le départ d’un collaborateur plus difficiles.
Un gestionnaire de mots de passe permet de générer des secrets longs et uniques. Protéger son accès, ses sauvegardes et ses moyens de récupération. Éviter la réutilisation du mot de passe de messagerie pour l’administration d’un serveur.
Activer l’authentification multifacteur sur les comptes critiques, en privilégiant les méthodes adaptées au risque et résistantes à l’hameçonnage lorsque disponibles. Conserver les codes de récupération hors du même appareil. Tester une procédure de secours avant de retirer l’ancienne méthode d’accès.
Pour SSH, préférer des clés individuelles protégées et limiter les comptes, sources et commandes lorsque l’usage le permet. Ne pas copier une clé privée d’administration dans tous les conteneurs. Un agent de collecte peut disposer d’une commande fixe au lieu d’un shell complet.
À la création : propriétaire, finalité, droits et date de révision. Lors d’un changement de fonction : retirer les anciens droits, pas seulement ajouter les nouveaux. Au départ ou à la perte d’un appareil : désactiver accès, sessions, clés et jetons concernés, puis vérifier les comptes indirects.
Les comptes de secours doivent être rares, surveillés et testés. Leur secret ne doit pas figurer dans le wiki ; le wiki peut indiquer quel coffre contient l’information et qui peut y accéder.
Validation : vérifier qu’un utilisateur ordinaire ne peut pas administrer, qu’un compte désactivé ne peut plus se connecter et que les événements d’accès critiques sont journalisés. Pour un service exposé, ajouter limitation des tentatives et alertes sans créer un mécanisme permettant à un tiers de verrouiller facilement tous les comptes.
Pour chaque compte, noter personne ou service, application, propriétaire, rôle, date de création, besoin, mécanisme MFA, expiration éventuelle et procédure de révocation. Le mot de passe, la clé privée et les codes de secours sont dans un coffre, jamais dans le tableau. Un compte de service doit avoir un responsable même si personne ne l’utilise interactuellement.
| Type | Usage | Restriction |
|---|---|---|
| Utilisateur quotidien | Travail courant | Pas administrateur permanent si inutile |
| Administrateur nominatif | Maintenance | Authentification forte, poste et réseau dédiés |
| Compte de service | Application ou automatisation | Ressources et commandes limitées |
| Jeton API | Intégration précise | Scope, expiration et révocation documentés |
| Compte de secours | Perte d’accès normal | Secret protégé et test périodique contrôlé |
Les groupes simplifient les droits mais doivent être relus dans leur ensemble. Une permission héritée d’un groupe peut rester active après retrait d’une permission directe. Tester avec un compte limité plutôt qu’un administrateur pour vérifier l’accès réel.
Utiliser des secrets longs, uniques et gérés par un coffre. Pour MFA, choisir le mécanisme pris en charge et approprié : une clé de sécurité résistante à l’hameçonnage peut offrir une protection différente d’un code recopié. Les notifications push doivent être approuvées seulement lorsqu’attendues.
Conserver une méthode de secours sans détruire le bénéfice du MFA. Vérifier que la perte du téléphone n’entraîne ni blocage permanent ni contournement trop facile. Ne pas laisser les codes de secours dans la même session compromise que le mot de passe. Un changement de rôle sensible exige une vérification de la demande par un canal fiable.
Créer une clé par poste ou usage, protéger sa clé privée et installer seulement la clé publique sur la cible autorisée. Vérifier l’identité du serveur lors de la première connexion par un canal indépendant. Un avertissement de changement de clé hôte peut signaler une réinstallation ou un problème de sécurité ; ne pas effacer automatiquement l’ancienne empreinte.
Limiter le compte, les commandes et la provenance selon l’usage. Une clé sans phrase de passe destinée à une automatisation nécessite des protections compensatoires adaptées. Supprimer une clé perdue sur toutes les cibles concernées et vérifier les accès résiduels.
À un départ ou changement de poste : retirer groupes, sessions, tokens, accès VPN, partages, applications et équipements selon le périmètre. Une désactivation dans un annuaire ne révoque pas toujours un token indépendant déjà émis. Vérifier les comptes locaux et les intégrations.
Organiser une revue : comptes inutilisés, privilèges excessifs, secrets anciens ou partagés, appareils inconnus et propriétaires manquants. Conserver la preuve de révocation et tester que l’ancien accès échoue. Le moindre privilège doit permettre le travail prévu ; des restrictions incomprises poussent souvent à créer des contournements.