Onboarding sécurité : règles à retenir dès l’arrivée
Onboarding sécurité : règles à retenir dès l’arrivée
Section intitulée « Onboarding sécurité : règles à retenir dès l’arrivée »Un onboarding sécurité ne sert pas à faire réciter une charte ni à distribuer des autocollants sur le hameçonnage. Il doit permettre d’utiliser les accès confiés sans transformer chaque poste, compte ou secret en point d’entrée durable pour un attaquant.
→ Lire l’explication complète de la marmotte
L’identité est le périmètre de sécurité
Section intitulée « L’identité est le périmètre de sécurité »Le compte individuel est l’unité de responsabilité. Un compte partagé empêche d’attribuer une action, rend la révocation imprécise et transforme une enquête en concours de divination. Aucun accès de production, d’administration ou de lecture de données sensibles ne doit dépendre d’un identifiant collectif.
L’authentification multifacteur, ou MFA (Multi-Factor Authentication), doit protéger tout accès exposé à Internet et tout changement de privilège. Le mot de passe n’est qu’une preuve faible, réutilisable et hameçonnable. Un second facteur résistant au hameçonnage, comme une clé matérielle compatible avec WebAuthn (Web Authentication), lie l’authentification au vrai site et bloque les relais de codes à usage unique. Les codes reçus par message court restent une solution de repli, pas une cible d’architecture. Le vol de numéro de téléphone par transfert frauduleux existe, même si la présentation vendeur promet une sérénité couleur pastel.
Le compromis central est net : des contrôles d’identité plus contraignants ralentissent certaines tâches légitimes, mais ils évitent qu’un mot de passe divulgué devienne un accès durable. Il faut choisir la friction au moment de l’enrôlement, de la récupération et de l’élévation de privilège. La subir pendant une réponse à incident coûte davantage, avec une ambiance généralement moins propice à la réflexion.
Un compte à privilèges doit être distinct du compte quotidien. Lire des courriels, naviguer ou participer à une réunion avec une identité qui peut administrer une infrastructure multiplie les chemins d’attaque. L’élévation doit être ponctuelle, tracée et limitée à une durée définie. L’accès permanent administrateur est une exception formellement justifiée, pas une récompense de fidélité.
Les règles d’authentification détaillées sont développées dans l’architecture des identités et dans l’authentification des personnes et des services. L’onboarding doit au minimum indiquer où enrôler les facteurs, où conserver les codes de récupération et qui contacter lorsqu’un facteur est perdu.
Poste administré, réseau contrôlé et données locales
Section intitulée « Poste administré, réseau contrôlé et données locales »Un poste de travail n’est pas un terminal neutre. Il contient des jetons de session, des clés privées, des navigateurs authentifiés, des historiques et souvent des copies locales de données. Le chiffrement complet du disque protège surtout contre la perte ou le vol hors tension. Il ne protège pas une session ouverte, un logiciel malveillant exécuté avec les droits de l’utilisateur, ni une synchronisation vers un service tiers.
L’équipement utilisé pour les accès professionnels doit être administré : correctifs du système et des logiciels, verrouillage automatique, chiffrement du stockage, protection contre les logiciels malveillants et inventaire des versions. Une solution de gestion de terminaux permet d’imposer ces réglages, de retirer les certificats et d’effacer un appareil perdu si l’architecture le prévoit. Elle ne transforme pas un poste compromis en poste sain. Une alerte de conformité ignorée laisse précisément le poste le plus exposé hors du mécanisme de contrôle.
Les accès distants doivent passer par le chemin approuvé : réseau privé virtuel, ou VPN (Virtual Private Network), passerelle applicative ou accès conditionnel selon l’architecture. Connecter une machine personnelle à un réseau interne parce qu’elle « dépanne juste cinq minutes » introduit une dépendance non administrée. Cinq minutes est une unité de temps particulièrement populaire dans les rapports d’incident.
Les données doivent rester dans les espaces approuvés, avec une classification connue. Un export local, une archive non chiffrée ou une copie dans un espace personnel contourne la rétention, les sauvegardes et les restrictions d’accès. La synchronisation n’est pas une sauvegarde : elle propage aussi suppression, corruption et chiffrement malveillant. Les principes d’architecture et de protection des données sont reliés dans les sections fondations de sécurité et données.
Secrets, clés et jetons ne passent pas par la messagerie
Section intitulée « Secrets, clés et jetons ne passent pas par la messagerie »Un secret est toute valeur permettant d’obtenir un accès : mot de passe, jeton d’interface de programmation, ou API (Application Programming Interface), clé privée, certificat client, code de récupération ou fichier de configuration contenant une chaîne d’accès. La présence d’un secret dans un dépôt de code, un ticket, une conversation ou une capture d’écran doit être traitée comme une divulgation, même si le contenu est ensuite supprimé. Les historiques, caches, sauvegardes et index ont une mémoire plus tenace que les bonnes intentions.
Les secrets applicatifs doivent venir d’un gestionnaire de secrets, jamais d’une variable définie à la main dans une documentation ou d’un fichier versionné. Une application reçoit seulement le secret requis, pour une durée limitée lorsque le mécanisme le permet. Les clés privées non exportables restent dans un support prévu à cet effet, par exemple un HSM (Hardware Security Module), lorsque le niveau de risque le justifie. Un HSM ne rend pas une autorisation excessive acceptable : il protège la clé contre l’extraction, pas contre une commande valide signée par une identité compromise.
La rotation n’est pas une cérémonie trimestrielle. Elle est une capacité opérationnelle : identifier le propriétaire du secret, remplacer la valeur, déployer les consommateurs, révoquer l’ancienne et détecter les échecs. Un secret sans propriétaire ni date de révision est un secret abandonné en attente d’exploitation. Pour les certificats, la révocation ne coupe pas les sessions déjà établies et n’efface pas les copies privées. Le confinement exige donc aussi l’expiration courte, la fermeture des sessions et l’investigation des usages.
Les sauvegardes de configurations et de clés doivent être chiffrées, testées et accessibles selon un processus séparé. Une sauvegarde dont la restauration n’a jamais été testée est une hypothèse optimiste, ce qui est une façon élégante de dire qu’elle risque d’être décorative.
Hameçonnage, demandes urgentes et signalement
Section intitulée « Hameçonnage, demandes urgentes et signalement »Le hameçonnage vise désormais autant les sessions que les mots de passe. Un faux portail peut relayer une authentification, voler un cookie de navigateur ou pousser à approuver une demande MFA. Une demande reçue par courriel, messagerie ou téléphone ne devient pas légitime parce qu’elle contient le nom d’un responsable, un logo ou le mot « urgent » écrit trois fois.
Avant toute action sensible, confirmer la demande via un canal indépendant : annuaire interne, numéro connu, ticket existant ou conversation initiée depuis l’outil officiel. Ne pas utiliser le lien, le numéro ou la pièce jointe fournis par la demande elle-même. Ce contrôle paraît fastidieux jusqu’au jour où une fausse demande de paiement, de réinitialisation ou d’ajout d’administrateur arrive avec une grammaire impeccable. Les attaquants aussi ont accès aux correcteurs orthographiques, tragiquement.
Un signalement rapide vaut mieux qu’une analyse solitaire de deux heures. En cas de clic, de saisie de secret, d’installation douteuse, de perte de matériel ou d’approbation MFA non sollicitée, couper la connexion réseau si le poste semble contrôlé, puis utiliser le canal d’incident défini. Signaler n’est pas prouver une compromission. C’est déclencher la vérification des journaux, l’invalidation des sessions et la rotation éventuelle avant que l’attaquant n’établisse une persistance.
La supervision doit enregistrer au moins les connexions, changements de droits, créations de jetons, exportations de données et usages administratifs. Ces traces doivent être horodatées, protégées contre l’altération et conservées selon les contraintes applicables. Sans journaux exploitables, le retrait d’un accès ressemble à fermer les yeux très fort devant un tableau de bord.
Vérifier une distribution logicielle avant installation
Section intitulée « Vérifier une distribution logicielle avant installation »Installer un outil depuis un résultat de recherche ou une pièce jointe contourne le contrôle de provenance. Une somme de contrôle vérifie l’intégrité du fichier, mais seulement si la somme elle-même provient d’une source authentifiée. Une signature cryptographique ajoute l’identité du signataire, à condition d’avoir validé son empreinte de clé par un canal indépendant.
L’exemple suivant vérifie une archive publiée avec une somme SHA-256 (Secure Hash Algorithm 256 bits) et une signature GnuPG (GNU Privacy Guard). Il suppose que la clé publique du fournisseur a déjà été obtenue et vérifiée selon la procédure interne.
# Vérifier que l'archive correspond à la somme publiée.# Le fichier SHA256SUMS doit référencer exactement l'archive téléchargée.sha256sum --ignore-missing --check SHA256SUMS
# Vérifier que le manifeste de sommes est signé.# Comparer l'empreinte affichée à celle validée dans la documentation interne.gpg --verify SHA256SUMS.sig SHA256SUMSUne vérification réussie ne garantit pas que le logiciel est sans vulnérabilité, ni que son comportement convient à l’environnement. Elle établit seulement que le fichier correspond au manifeste signé par la clé vérifiée. Le reste dépend de la revue de version, des correctifs, des droits accordés et du cloisonnement réseau.
Accès, départs et exceptions traçables
Section intitulée « Accès, départs et exceptions traçables »Un accès doit avoir un propriétaire, une finalité, une portée et une date de revue. Le modèle du moindre privilège consiste à donner le droit minimal nécessaire à une tâche, pas à créer un parcours administratif assez pénible pour encourager les contournements. Quand deux équipes ont besoin d’un même droit, créer un groupe géré est préférable à l’ajout manuel de comptes dispersés.
Les exceptions temporaires doivent expirer automatiquement. Une exception sans expiration devient une règle de fait, puis une dépendance, puis une surprise lors d’un audit. Les droits d’urgence doivent être séparés, surveillés et testés avant l’urgence. Un compte de secours inaccessible parce que son unique détenteur est absent n’est pas un plan de reprise, c’est un accessoire de théâtre.
Le départ, la mobilité interne ou le changement de mission déclenchent la révocation des sessions, jetons, certificats, groupes, clés et équipements concernés. Désactiver le compte annuaire ne suffit pas si des jetons longue durée, des clés de déploiement ou des comptes locaux subsistent. Les mécanismes d’annuaire et les risques liés aux protocoles historiques sont détaillés dans la sécurité des services d’identité et le durcissement de NTLM.
🐝 Ce qui arrive si on s’en passe
Section intitulée « 🐝 Ce qui arrive si on s’en passe »Sans onboarding sécurité, les usages ne disparaissent pas : ils s’apprennent par imitation, et le premier contournement observé devient la norme locale. Les accès accordés à l’oral, hors demande tracée, n’apparaissent dans aucun inventaire, donc ne sont ni revus ni révoqués lors d’un changement de rôle. Le délai entre un clic douteux et son signalement s’allonge, parce que le canal d’incident n’est pas connu au moment où il faudrait l’utiliser : l’invalidation des sessions et la rotation des secrets arrivent après la persistance de l’attaquant, pas avant. Les journaux restent alimentés, mais deviennent difficiles à interpréter quand des comptes partagés ou des outils installés hors circuit brouillent l’attribution. Le coût se paie en reconstitution a posteriori, plus lente et moins fiable que la consigne donnée le premier jour.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »À l’arrivée, une personne reçoit un compte et des droits pour travailler. Ce compte doit être personnel afin que chaque action puisse être reliée à la bonne personne et retirée sans bloquer les autres. La connexion demande un mot de passe et une seconde preuve, par exemple une clé physique, car un mot de passe peut être volé ou recopié sur un faux site.
L’ordinateur utilisé doit être mis à jour, chiffré et géré par l’organisation. S’il est perdu, le chiffrement protège les fichiers lorsque l’appareil est éteint. Si un programme malveillant fonctionne pendant une session ouverte, ce chiffrement ne suffit plus : il faut signaler le problème pour couper les accès et examiner l’appareil.
Les mots de passe techniques, clés et codes de secours donnent accès à des services. Ils ne doivent jamais être collés dans un message, un document partagé ou un dépôt de code. Ils sont stockés dans un outil prévu pour cela, puis remplacés lorsqu’ils sont soupçonnés d’avoir été exposés.
Un message demandant une action urgente peut être faux, même s’il semble venir d’une personne connue. Il faut vérifier la demande par un autre moyen avant de cliquer, payer, installer ou modifier un accès. En cas d’erreur, signaler vite permet de fermer les sessions et de remplacer les secrets. Enfin, les droits doivent correspondre au travail réel et être retirés lors d’un changement de rôle ou d’un départ.
À lire aussi
- Mot de passe partagé en équipe et risques réelsLe mot de passe partagé oppose la continuité opérationnelle d'une équipe à la perte de traçabilité, de révocation et de contrôle.
- Pourquoi le phishing fonctionne malgré la formationL’ingénierie sociale exploite les contraintes humaines et organisationnelles que la formation seule ne neutralise pas.
- Comment dire non en comité de sécurité sans perdre sa crédibilitéDire non en comité de sécurité exige une décision traçable, fondée sur un risque mesuré et assortie d'une voie de sortie exploitable.
- Pourquoi un analyste SOC rate une alerte critiqueCharge cognitive en SOC : comprendre pourquoi une alerte critique échappe à l’analyste et comment concevoir une détection exploitable.
Pages voisines
La citent
- Pourquoi les postes juniors cyber disparaissent
- SSO, SCIM et journaux d'audit pour un assistant IA d'entreprise
- VPN, tunnels, bastions et interconnexions protégées
Onboarding sécurité : règles à retenir dès l’arrivée
Elle cite