Zero Trust pour les accès des prestataires
- Accueil
- Identités, accès & habilitations
- Gérer les accès externes des prestataires
- Zero Trust pour les accès des prestataires
Zero Trust pour les accès des prestataires
Section intitulée « Zero Trust pour les accès des prestataires »Un prestataire n’est pas un utilisateur interne temporairement moins bien connu : c’est une frontière organisationnelle avec des intérêts, des outils et une chaîne de responsabilité distincts. La recommandation est nette : accorder un accès nominatif, borné dans le temps, limité à une tâche et techniquement révocable, puis refuser toute exception durable déguisée en urgence opérationnelle.
Confier un accès à un prestataire ressemble à remettre les clés d’un atelier pour une réparation précise. La bonne pratique n’est pas de donner le trousseau général avec une promesse de le rendre, mais de remettre un moyen d’entrer limité au lieu et au moment nécessaires.
→ Lire l’explication complète de la marmotte
Clauses de sécurité et contrôle technique associé
Section intitulée « Clauses de sécurité et contrôle technique associé »Une clause de sécurité doit créer une obligation vérifiable, pas collectionner des mots rassurants. « Le sous-traitant applique les meilleures pratiques » ne produit ni journal exploitable, ni compte désactivé, ni preuve de revue. C’est du papier peint contractuel, très décoratif jusqu’à l’incident.
Le contrat doit exiger au minimum les éléments suivants :
- l’utilisation d’identités nominatives, interdites de partage, y compris pour les équipes de support du prestataire ;
- une authentification multifacteur, c’est-à-dire au moins deux preuves distinctes d’identité, pour tout accès d’administration ou distant ;
- l’interdiction des comptes locaux permanents et des accès génériques, sauf compte de secours documenté, scellé et contrôlé ;
- un accès accordé pour une durée définie, avec date d’expiration technique non modifiable par le prestataire ;
- une re-certification périodique par le responsable interne de la ressource, au moins trimestrielle pour les accès privilégiés ;
- une notification d’incident sous délai contraint, par exemple quatre heures après qualification d’un accès non autorisé, d’une compromission d’identité ou d’une indisponibilité affectant le service ;
- la conservation et la transmission des journaux d’accès, de session et d’actions d’administration selon une durée contractuelle compatible avec les investigations ;
- un droit d’audit portant sur les contrôles pertinents, les preuves de revues, les journaux et le dispositif de révocation ;
- l’obligation de déclarer tout sous-traitant ultérieur ayant accès aux données, aux systèmes ou aux secrets d’administration.
Le délai de notification doit définir le point de départ. Exiger une alerte « sans délai » ne signifie rien quand l’incident dort dans une boîte partagée un week-end. Le contrat doit distinguer la détection, la qualification, l’information initiale et le rapport complet. Une notification initiale peut être incomplète, mais elle doit fournir le périmètre connu, les identités concernées, les mesures de confinement et un canal de coordination.
Le droit d’audit mérite la même précision. Auditer « les mesures de sécurité » est trop large pour être exercé et trop vague pour être opposable. Mieux vaut exiger des éléments ciblés : export des comptes actifs, preuve de désactivation à la fin d’une mission, traces d’authentification multifacteur, configuration des passerelles, résultats de tests de révocation, comptes rendus de re-certification et liste des sous-traitants ultérieurs. Le contrat gouverne la relation ; le contrôle technique gouverne le paquet réseau et le jeton d’accès. Confondre les deux revient à demander à un PDF de bloquer une connexion.
La clause ne protège donc rien par elle-même. Elle permet d’exiger, d’auditer et de sanctionner après un écart. La prévention dépend d’un fournisseur d’identité, d’une politique d’accès conditionnel, d’une segmentation réseau et d’une journalisation centralisée. Les principes d’identités et contrôle d’accès doivent s’appliquer à une identité externe avec davantage de contraintes, pas avec moins de rigueur parce qu’une facture existe.
Identités externes, durée de vie et re-certification
Section intitulée « Identités externes, durée de vie et re-certification »Un compte prestataire doit être rattaché à une personne physique, à une organisation fournisseur, à un sponsor interne et à une mission. Sans ces quatre attributs, la désactivation automatique devient impraticable et la revue d’accès ressemble à une chasse archéologique dans un tableur. Vingt ans de gestion d’identités apprennent que le compte « temporaire » le plus ancien est souvent celui qui possède le plus de droits.
La source d’autorité doit être explicitement choisie. Deux modèles existent :
- fédérer l’identité du prestataire depuis son propre annuaire, avec une relation de confiance limitée ;
- créer une identité invitée dans l’annuaire interne, avec cycle de vie piloté par le sponsor.
La fédération réduit la création de comptes locaux et permet au prestataire de gérer son authentification. Elle échoue dès que son annuaire ne fournit ni assurance suffisante sur l’authentification, ni signal de départ d’un salarié, ni journal exploitable. L’identité invitée donne plus de contrôle sur les politiques, les journaux et l’expiration, mais impose la gestion des doublons et du cycle de vie. Le choix dépend donc de la capacité à vérifier les garanties du fournisseur d’identité externe, pas de la qualité de sa plaquette commerciale.
L’accès juste-à-temps doit être privilégié pour les privilèges d’administration. Le droit n’est activé qu’après approbation, pour une durée courte, avec motif et ticket de changement liés à la demande. Un accès permanent peut rester acceptable pour une activité quotidienne stable, mais seulement si une re-certification formelle valide périodiquement le besoin. La re-certification ne doit pas demander « conserver cet accès ? » à un gestionnaire noyé sous cent lignes. Elle doit présenter la mission, les ressources, les derniers usages et la date de fin prévue. Sans signal d’usage, on certifie surtout l’inertie.
L’expiration doit être imposée par le système d’identité et propagée aux groupes, aux certificats et aux autorisations applicatives. Désactiver un compte dans l’annuaire ne coupe pas forcément une session déjà établie, un jeton d’accès encore valide ou une clé déposée sur un équipement. La révocation doit donc déclencher l’invalidation des sessions, le retrait des appartenances et la suppression des secrets associés. Les sujets de segmentation et de contrôle des flux complètent ce dispositif dans la page sur le filtrage, la segmentation et le Zero Trust.
Ce mécanisme ne garantit pas que la personne autorisée agit correctement, que son poste est sain ou que le prestataire ne photographie pas un écran. Il réduit le périmètre et la durée de l’exposition. La prévention de l’exfiltration exige en complément une classification des données, des restrictions de copie, une supervision des sessions et, pour les environnements les plus sensibles, un poste d’administration contrôlé.
Télémaintenance des environnements industriels et sensibles
Section intitulée « Télémaintenance des environnements industriels et sensibles »L’accès distant à un environnement industriel, à une zone de production ou à un système sensible ne doit jamais terminer directement sur l’équipement cible. Une connexion de télémaintenance exige une passerelle dédiée, placée dans une zone intermédiaire, et non une règle de pare-feu ouverte entre Internet et le réseau industriel. Le protocole est peut-être chiffré ; l’ouverture reste une ouverture. Le chiffrement n’a jamais transformé un port exposé en jugement architectural.
La passerelle doit authentifier l’intervenant avec authentification multifacteur, vérifier l’état du poste lorsque cela est possible, ouvrir uniquement les protocoles nécessaires, puis enregistrer la session. Pour les accès graphiques ou en ligne de commande, l’enregistrement doit inclure la vidéo ou la transcription des commandes. Pour les protocoles industriels, l’enregistrement réseau et les journaux de commandes doivent être prévus lorsque le protocole le permet.
La session est liée à une autorisation de travail : équipement ciblé, fenêtre temporelle, motif, approbateur et prestataire. À la fin de cette fenêtre, la passerelle coupe la session, même si une console est restée ouverte. Laisser le prestataire décider de la fermeture revient à confier le disjoncteur au câble qui chauffe.
La séparation réseau doit empêcher la passerelle d’atteindre les segments non requis. Une passerelle de télémaintenance n’est pas un bastion polyvalent donnant accès à toutes les zones « pour faciliter le support ». Autoriser seulement les flux documentés vers les actifs nécessaires, par ports, adresses et sens de communication. Les flux de retour, les services de résolution de noms, les mises à jour et les outils de transfert de fichiers doivent être inventoriés : ce sont les oubliés habituels qui deviennent des tunnels permanents.
Prévoir aussi la coupure d’urgence. Une commande opérationnelle doit suspendre immédiatement les accès du prestataire, invalider les sessions actives et empêcher toute nouvelle connexion. Cette coupure doit être testée, journalisée et disponible hors des horaires ouvrés. Une procédure qui nécessite trois validations humaines avant de bloquer une compromission est un formulaire d’observation de sinistre.
Exemple de politique d’accès temporaire reproductible
Section intitulée « Exemple de politique d’accès temporaire reproductible »L’exemple suivant utilise Microsoft Graph PowerShell pour créer une appartenance temporaire à un groupe d’accès. Il suppose que le module Microsoft.Graph.Groups est installé, que l’opérateur dispose de l’autorisation GroupMember.ReadWrite.All et que le groupe cible ne confère pas à lui seul un privilège d’administration non supervisé.
# Se connecter avec un compte d'administration dédié et authentification multifacteur.Connect-MgGraph -Scopes "GroupMember.ReadWrite.All"
# Remplacer les identifiants par ceux de l'invité et du groupe applicatif ciblé.$userId = "11111111-1111-1111-1111-111111111111"$groupId = "22222222-2222-2222-2222-222222222222"
# Ajouter l'identité externe au seul groupe prévu pour la mission.New-MgGroupMemberByRef -GroupId $groupId -BodyParameter @{ "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$userId"}
# La suppression doit être planifiée par un workflow d'expiration,# pas laissée à un rappel manuel dans un calendrier.Remove-MgGroupMemberByRef -GroupId $groupId -DirectoryObjectId $userIdCe script montre l’opération d’ajout et de retrait, pas une gestion complète de la durée. En production, l’ajout doit provenir d’une demande approuvée, créer une date d’expiration non contournable et écrire un événement vers la supervision. Une tâche planifiée qui retire un membre sans vérifier l’approbation, le motif et l’état d’une intervention peut couper une maintenance critique. À l’inverse, une expiration seulement documentée dans un ticket ne coupe rien du tout, ce qui est très reposant pour le ticket et beaucoup moins pour le réseau.
Les secrets d’accès à la passerelle, les certificats clients et les clés d’interface de programmation doivent être stockés dans un coffre dédié, jamais dans le ticket d’intervention. Leur rotation doit être indépendante de la durée de la mission. La sauvegarde de la configuration de passerelle doit inclure les règles, les journaux de configuration et les certificats nécessaires à la reprise, mais exclure les secrets exportables lorsque leur restauration créerait une duplication de clés.
🐝 Ce qui arrive si on s’en passe
Section intitulée « 🐝 Ce qui arrive si on s’en passe »Sans ce dispositif, la porte de la ruche reste ouverte sur l’extérieur et personne ne note qui entre. Un compte partagé entre plusieurs intervenants rend l’imputabilité nulle : une action destructrice ne peut être rattachée à une personne, ce qui bloque autant la qualification d’incident que toute suite contractuelle ou assurantielle. L’investigation dépend alors des journaux du prestataire, fournis quand il le veut et dans le format qu’il choisit. Une mission terminée laisse des jetons, des clés et des sessions vivants, réutilisables des mois plus tard sans nouvelle authentification. Un sous-traitant de rang deux non déclaré hérite du même chemin sans qu’aucune revue ne le voie. Enfin, sans fenêtre d’intervention ni coupure testée, la reprise après compromission impose de couper l’intégralité des accès externes, y compris ceux dont dépend la production.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »Lorsqu’une entreprise fait intervenir une autre entreprise, elle doit d’abord désigner une personne responsable en interne et préciser le travail demandé. Chaque intervenant reçoit une identité à son nom, liée à son employeur, à une mission et à une date de fin. Cette identité demande plusieurs preuves avant d’ouvrir une session, par exemple un mot de passe et une validation sur un appareil enregistré.
Les droits ne donnent accès qu’aux outils et aux machines nécessaires. Pour une réparation ponctuelle, les droits peuvent être activés après validation puis retirés automatiquement à l’heure prévue. Une vérification régulière confirme que chaque accès existe encore pour une raison précise. Si personne ne le confirme, l’accès est supprimé.
Pour intervenir à distance sur une installation sensible, le prestataire passe par un point d’entrée réservé. Cette entrée vérifie son identité, limite les destinations accessibles et enregistre ce qui se passe pendant l’intervention. À la fin, elle ferme la session. En cas de problème, l’équipe interne doit pouvoir couper immédiatement tous les accès externes.
Le contrat oblige le prestataire à respecter ces règles, à prévenir rapidement en cas d’incident et à fournir des preuves. Mais le contrat ne bloque aucune connexion. Les systèmes techniques doivent appliquer les durées, les autorisations, les coupures et les enregistrements. Si une identité est volée ou si un poste est infecté, la limitation des droits et la surveillance réduisent les dégâts sans les rendre impossibles.
À lire aussi
- Gérer les accès externes des prestatairesConcevoir des accès externes, portails partenaires et fédérations inter-entreprises sans perdre la visibilité sur les identités tierces et la responsabilité des autorisations.
- Authentifier une API B2B hors annuaire interneChoisir, exploiter et révoquer les mécanismes d’authentification et d’autorisation pour les flux EDI et API B2B entre organisations.
- Clauses de sécurité pour contrat fournisseurDéfinir des clauses de sécurité vérifiables dans un contrat fournisseur.
- Assurance cyber couverture et exclusions de contratAssurance cyber : ce qu’elle couvre, ce qu’elle exclut et les exigences techniques qui conditionnent l’indemnisation.
Pages voisines
La citent
- Chaîne d'alimentation et refroidissement d'un datacenter
- Faille Target 2013, alertes FireEye ignorées et segmentation
- RDP exposé sur Internet : risques, durcissement et détection
Zero Trust pour les accès des prestataires
Elle cite
