Accès distant des prestataires du secteur public : guide

Un accès distant prestataire dans le secteur public doit prendre fin lorsque le travail autorisé se termine. Une date d’expiration sur un compte ne suffit pas. L’institution doit connaître la personne connectée, le service qu’elle peut modifier, les sessions encore actives et le responsable capable de retirer l’accès sans interrompre les opérations essentielles.

Un contrat peut durer plusieurs années alors qu’un technicien intervient pendant quatre-vingt-dix minutes. Ce sont deux autorisations distinctes. Le processus proposé transforme chaque intervention en créneau doté d’un responsable, de limites observables et d’une clôture vérifiable. Son exemple municipal est fictif et ne décrit ni architecture cliente ni résultat mesuré.

Suivre tout le chemin avant d’approuver le compte

Cartographiez le trajet du poste du technicien jusqu’à l’opération finale : fournisseur d’identité du prestataire, authentification de la collectivité, VPN ou courtier d’accès, bastion et rôle d’administration applicatif. Une clé API créée dans l’application peut ouvrir un autre chemin avec une durée différente.

Pour chaque étape, identifiez qui accorde l’accès, qui le retire et quelle preuve démontre ce retrait. Le prestataire peut désactiver l’identité de son salarié sans contrôler un jeton délivré par la collectivité. Inversement, celle-ci peut fermer un chemin réseau tandis qu’une session d’administration cloud distincte reste utilisable.

Séparez maintenance interactive et connexions automatisées. Une intégration nocturne nécessite une identité de service et un cycle de gestion des secrets ; elle ne doit pas emprunter le compte d’un technicien. Ce mélange complique le départ urgent d’un salarié, car retirer ses droits risque d’interrompre la production.

Placez les dépendances métier à côté du chemin. Le plan de sécurité réseau des collectivités montre comment attribuer les responsabilités et vérifier la continuité. La décision devient précise : quelle partie de ce service cette personne peut-elle atteindre pendant cette intervention ?

Définir un créneau applicable par l’exploitant

Les questions d’assurance fournisseurs du NCSC invitent à examiner limitation, contrôle et surveillance des accès, accords de support distant et journalisation des sessions. La fiche suivante traduit ces questions en proposition de transmission opérationnelle entre institution et prestataire.

Changement : mise à jour du connecteur de collecte des déchets
Responsable métier et suppléant : contacts de la collectivité
Technicien : identité individuelle vérifiée
Objectif : modifier la configuration et vérifier la transmission
Début/fin : date explicite, horaires UTC et affichage local
Cibles : interface d’administration approuvée uniquement
Actions : configuration et vérification d’un traitement fictif
Transfert : dépôt de paquets approuvé
Arrêt : responsable de permanence ou directeur d’incident
Clôture : administrateur d’accès identifié
Preuves : session terminée, rôle temporaire retiré,
         secrets délivrés recensés, tentative refusée

Ajoutez les conditions du poste et d’authentification réellement vérifiables. « Poste sécurisé » est trop vague pour accepter ou refuser une connexion. Précisez source de preuve, fraîcheur attendue et conduite à tenir lorsque l’information manque.

Cette fiche ne remplace pas les conditions contractuelles ou juridiques. Vérifiez que le contrat prévoit notifications, changements d’intervenants, approbation des sous-traitants et remise des preuves. Sinon, l’équipe technique risque de devoir imposer des conditions auxquelles le fournisseur n’a jamais consenti.

Définissez les prolongations. Un retard n’étend pas silencieusement l’autorisation initiale. Le responsable métier ou son suppléant habilité choisit poursuite, réduction du périmètre ou rétablissement précédent. Enregistrez la nouvelle échéance et vérifiez sa transmission au mécanisme de contrôle.

Préparer personne, poste et procédure de retrait

Vérifiez le technicien auprès d’un contact fournisseur établi auparavant. N’acceptez pas une nouvelle identité ou un numéro de téléphone simplement parce qu’ils figurent dans une demande urgente. Vérifiez si l’intervenant appartient au cocontractant ou à un sous-traitant soumis à approbation.

Attribuez une identité individuelle pour le travail prévu. Séparez rôles élevés et collaboration ordinaire, puis appliquez la politique d’authentification de l’institution. Pour les accès privilégiés, privilégiez une authentification résistante au phishing lorsque l’architecture le permet. Toute exception comporte responsable et échéance.

Avant activation, demandez comment le prestataire signalera départ, changement de fonction ou perte du poste. Désignez destinataire et responsable du traitement. Une revue annuelle ne convient pas à une permission dépendant de la situation actuelle d’une personne.

Testez la procédure de retrait avec une identité de test dès l’intégration. Découvrir à la fin d’une intervention réelle que les sessions applicatives restent actives oblige la collectivité à négocier une faiblesse après l’ouverture de l’accès.

Les logiciels compromis et dépendances fournisseurs relèvent plus largement de l’évaluation des risques de chaîne d’approvisionnement. Ce processus traite les droits des personnes réalisant une intervention autorisée sur un service.

Limiter séparément le chemin et les permissions cibles

Un technicien pouvant atteindre un serveur doit conserver uniquement les privilèges applicatifs nécessaires. Connectivité, droits du système d’exploitation et rôles applicatifs correspondent à des décisions distinctes. Documentez ces niveaux et le contrôle empêchant l’accès aux services sans rapport avec l’intervention.

Le guide ANSSI d’administration sécurisée, version 3.0, recommande une chaîne d’accès dédiée aux administrateurs tiers et des comptes d’accès et d’administration dédiés. Adaptez l’architecture aux systèmes concernés : un document d’assurance fournisseur ne remplace pas les contrôles appliqués dans l’institution.

Évaluez VPN ou ZTNA sur le chemin réel. Le guide de mise en œuvre ZTNA du NCSC maintient explicitement la nécessité du cloisonnement réseau local. Les décisions d’accès ZTNA et les contrôles des mouvements entre segments internes répondent à des fonctions différentes.

Examinez les cibles accessibles depuis connecteur ou bastion, les transferts permis et la possibilité d’installer un autre outil de téléassistance. Pour l’intervention, approuvez les canaux nécessaires et empêchez les alternatives inexpliquées. Un raccourci temporaire de dépannage pourrait survivre au créneau initial.

Une intervention municipale, de la demande à la clôture

Une collectivité fictive remplace la configuration du connecteur qui transmet les tournées au prestataire de collecte des déchets. Le technicien doit modifier cette configuration et vérifier la réception d’un planning fictif. Il n’a besoin ni des recettes, ni des dossiers habitants, ni de l’annuaire d’identité.

Le responsable métier réserve quatre-vingt-dix minutes après l’export opérationnel. La fiche indique date, horaires UTC et équivalent local pour éviter l’ambiguïté du changement d’heure. La collectivité conserve la configuration précédente et confirme que les agents disposent du planning existant si la mise à jour échoue.

Avant l’ouverture, un test confirme que le technicien ne peut établir sa session d’administration. L’administrateur active ensuite rôle et chemin approuvés. Le technicien utilise l’identité et le poste convenus ; l’observateur vérifie la présence de la session dans les journaux attendus.

Pendant l’intervention, le technicien modifie la configuration et transmet le planning de test identifié. Le métier confirme réception et suppression de ce dossier. Un contrôle autorisé vers une cible de test indépendante vérifie que le chemin prestataire ne traverse pas la frontière des recettes. Une cible indisponible ne prouve pas un refus de sécurité.

Si le planning fictif échoue, le responsable décide du retour arrière ou d’une prolongation approuvée avant l’échéance. Un diagnostic incomplet n’accorde pas automatiquement davantage de droits. Toute cible supplémentaire nécessite justification et permission nouvelles.

À la clôture, l’administrateur termine la session distante, retire le rôle temporaire et recense les secrets délivrés pendant l’opération. L’observateur vérifie le refus avec la même identité de test et documente le sort de la session déjà établie. La collectivité confirme ensuite le bon fonctionnement de l’export réel.

Réservez une partie du créneau à cette transmission. Si les quatre-vingt-dix minutes sont entièrement consacrées à la modification, la clôture devient une opération réalisée après expiration de l’accord. Fixez le moment où le technicien cesse les changements et commence la vérification, avec une marge suffisante pour le retour arrière. Cette marge dépend de l’opération et de ses étapes de récupération. Inscrivez-la dans la fiche plutôt que d’appliquer un pourcentage universel. Le responsable de permanence doit connaître ce point d’arrêt avant le début du travail.

Recensez également les éléments prévus pour fonctionner plus tard. Un export approuvé peut continuer après la déconnexion du technicien, mais une nouvelle tâche planifiée, un agent de téléassistance ou une clé API nécessite objectif et responsable. Indiquez s’il s’agit d’une dépendance permanente validée par la collectivité ou d’un élément temporaire à supprimer. Terminer la session visible n’explique pas ces changements en arrière-plan. Avant la réception, demandez au responsable applicatif de comparer leur configuration à la fiche de changement. Tout contrôle incomplet reste une action ouverte, avec personne désignée et échéance, plutôt qu’une case déclarée terminée faute de temps.

Révoquer les états qui survivent à la connexion initiale

Construisez la liste de clôture à partir des technologies présentes : session réseau, bastion, session applicative, rôle temporaire, mécanisme de renouvellement, clé API et secret local introduit. Tous les systèmes ne comportent pas tous ces éléments. Recherchez ce qui permet encore une opération après la modification de l’autorisation principale.

Pour chacun, identifiez la terminaison ou l’invalidation disponible. Vérifiez si retirer un rôle affecte immédiatement une session ou seulement sa prochaine vérification d’autorisation. Déterminez si la déconnexion du navigateur laisse fonctionner un jeton indépendant. Deux produits peuvent réagir différemment au même événement d’identité.

Si la terminaison immédiate est impossible, consignez durée résiduelle maximale et confinement testé : retrait du chemin réseau précis ou désactivation de la fonction cible, par exemple. Évaluez leurs conséquences métier avant de compter sur ces mesures. Réduire la durée des futurs jetons ne révoque pas un secret déjà délivré sous une autre politique.

Vérifiez la clôture par une tentative sûre et autorisée nécessitant la permission retirée. Testez l’accès existant autant qu’une nouvelle connexion. Conservez la preuve d’échec sans enregistrer valeurs des jetons ni mots de passe. « Le prestataire s’est déconnecté » n’équivaut pas à une preuve institutionnelle du retrait des droits.

Renouvelez les secrets exposés ou concernés par la procédure approuvée, après vérification des applications qui les utilisent. Une rotation indiscriminée de secrets partagés peut interrompre d’autres services. Leur inventaire permet un retrait précis et évite de casser une intégration sans rapport avec l’intervenant.

Consignez également les limites découvertes pendant ce contrôle. Si une application ne permet qu’une expiration différée, le responsable doit connaître la durée réelle avant le prochain créneau. Une mention « accès fermé » sans cette réserve rendrait le dossier trompeur et empêcherait une décision informée sur l’intervention suivante.

Prévoir un accès d’urgence qui reste exceptionnel

Rédigez la procédure avant un appel nocturne. Définissez l’interruption justifiant son activation, l’approbateur et la vérification du demandeur lorsque l’identité habituelle est indisponible. Nommez un suppléant pour éviter qu’une seule absence entraîne une exception improvisée.

Limitez le chemin à l’opération de rétablissement. Lorsque possible, une seconde personne habilitée observe l’usage ou le vérifie rapidement. Si l’outil de tickets est indisponible, gardez une trace indépendante puis réconciliez-la ensuite. L’urgence conserve une échéance et un responsable de clôture.

Exercez cette procédure sans perturber la production. Confirmez que contacts, identifiants conservés, poste et cible fonctionnent dans la panne envisagée. Un compte de secours dépendant du mécanisme d’authentification défaillant ne remplit pas son rôle.

Après utilisation, examinez la défaillance du chemin normal, rapprochez les modifications privilégiées et supprimez les autorisations temporaires. Des recours répétés au secours pour un même service nécessitent une décision d’architecture, plutôt qu’une normalisation du contournement.

Garder des preuves utiles sans exposer l’investigation

Le dossier d’audit relie approbation, activité et clôture. Conservez identité, cible, dates, décisions pertinentes, référence du changement et résultats de vérification. Si des sessions sont enregistrées, définissez finalité, accès et conservation avec les responsables compétents. Une capture vidéo peut contenir informations d’habitants et identifiants.

Face à une activité inattendue, préservez les événements originaux et suivez la méthode de corrélation IP, DNS et processus. Une sortie fournisseur partagée identifie une infrastructure, pas nécessairement la personne responsable. Une vérification de réputation ajoute un renseignement daté sans certifier l’identité.

N’envoyez pas d’URL de session, de nom interne ou de lien signé dans un scanner public. Le guide OPSEC des analystes explique comment une investigation peut divulguer les éléments qu’elle cherche à examiner.

Pour une première évaluation IsMalicious, l’institution peut choisir l’un de ses domaines publics ou une IP publique lui appartenant et consulter le rapport d’indicateur. Si les renseignements alimentent ensuite un contrôle existant, définissez qui interprète les correspondances et qui approuve les restrictions affectant le prestataire. Une réputation favorable ne doit jamais rouvrir une permission fermée.

À la fin du contrat, rapprochez le registre complet avec le responsable métier : personnes, routes, rôles applicatifs et secrets automatisés. Terminez le transfert de service nécessaire avant de retirer les dépendances, puis conservez les preuves selon la politique approuvée. La dernière facture du fournisseur ne prouve pas la fin de ses accès techniques.