Interconnexions avec les partenaires : la porte qu’on n’audite jamais

Une interconnexion partenaire est une extension de votre périmètre chez quelqu’un dont vous ne maîtrisez pas la sécurité. C’est aussi, dans la plupart des organisations, la partie du réseau la moins revue.

Elle a souvent été mise en place il y a des années, par des personnes parties depuis, pour un besoin qui a évolué.

Ce qu’on trouve en auditant

Les constats se répètent d’une mission à l’autre :

• Des liaisons dont plus personne ne sait à quoi elles servent, maintenues « au cas où ».
• Des règles de filtrage bien plus larges que le besoin — un réseau entier autorisé là où deux serveurs suffiraient.
• Des partenaires qui accèdent depuis leur propre réseau, sans qu’on sache qui exactement.
• Des liaisons contractuellement terminées mais techniquement actives.
• Aucune journalisation spécifique des flux traversants.

Chacun de ces points transforme la compromission du partenaire en incident chez vous — c’est le mécanisme décrit dans la sécurité de la chaîne d’approvisionnement.

Les trois formes d’interconnexion

La liaison réseau

La plus ancienne et la plus risquée, parce qu’elle raisonne en termes de réseaux et non de services. Le partenaire est « dans » votre réseau, avec tout ce que cela implique en cas de compromission chez lui.

Le principe correct est de la traiter comme une zone à part entière : segment dédié, filtrage explicite vers les seuls services nécessaires, aucune route par défaut. Voir la segmentation.

L’échange de fichiers

Dépôts partagés, transferts automatisés. Le risque principal n’est pas l’intrusion mais le contenu : un fichier déposé par un partenaire compromis entre dans votre système sans contrôle.

Deux mesures : analyse systématique des contenus déposés, et cloisonnement de la zone d’échange — le serveur qui reçoit ne doit pas être celui qui traite.

L’interface applicative

La forme moderne et la mieux maîtrisable, à condition de traiter l’authentification entre services et le contrôle d’accès au niveau de l’objet — voir les erreurs récurrentes sur les API.

C’est vers cette forme qu’il faut migrer les liaisons réseau historiques quand c’est possible : elle expose un service, pas un réseau.

Le principe directeur

Un partenaire n’accède pas à votre réseau ; il accède à un service, depuis une origine identifiée, pour une durée déterminée, avec traçabilité.

C’est la même logique que pour les accès distants, appliquée à une entité plutôt qu’à une personne.

Cela suppose quatre choses :

1. Une zone dédiée pour les échanges partenaires, cloisonnée du reste.
2. Des flux explicitement autorisés, service par service, jamais par plage de réseau.
3. Des identités nominatives lorsque des personnes du partenaire accèdent — pas un compte partagé « partenaire X ».
4. Une journalisation dédiée, conservée séparément.

Le volet contractuel

Une interconnexion sans convention écrite est une zone de responsabilité indéterminée. Les points à couvrir, en complément des clauses de sécurité habituelles :

• Le périmètre technique : quels systèmes, quels flux, quels protocoles. Annexé et mis à jour.
• Les exigences de sécurité du partenaire sur son propre périmètre.
• La notification d’incident réciproque, avec délai — si votre partenaire est compromis, vous devez le savoir en heures, pas en semaines.
• Le droit de suspendre la liaison unilatéralement en cas de suspicion, sans engager votre responsabilité contractuelle. Cette clause est essentielle et souvent absente : sans elle, couper devient une décision juridiquement risquée au pire moment.
• La fin de la liaison : qui prévient qui, dans quel délai, et qui vérifie la fermeture effective.

La revue périodique

C’est ce qui manque presque toujours. Une revue annuelle, pour chaque interconnexion :

1. Le besoin métier existe-t-il encore ?
2. Les flux autorisés correspondent-ils aux flux réellement utilisés ? Les compteurs répondent.
3. Les comptes du partenaire sont-ils encore actifs, et les personnes toujours en poste chez lui ?
4. Le contrat est-il en cours de validité ?
5. Quand la liaison a-t-elle été testée en conditions de coupure ?

La deuxième question est la plus productive : elle révèle systématiquement des autorisations obsolètes qu’on peut retirer sans risque, et réduit la surface à peu de frais.

Le scénario à préparer

Votre partenaire vous annonce un vendredi soir qu’il subit une compromission. Que faites-vous ?

Trois décisions doivent être préparées à froid :

• Qui peut couper la liaison, immédiatement, sans validation supplémentaire. Sans mandat écrit, on perd des heures — voir ce que la détection ne décide pas.
• Quel impact métier la coupure produit, et qui l’assume.
• Comment on vérifie si quelque chose est déjà passé — d’où l’importance de la journalisation dédiée.

Ce scénario mérite d’être joué en exercice de crise : il est plausible, il implique le métier, et il révèle immédiatement si la chaîne de décision existe.

Les cinq vérifications

1. Combien d’interconnexions actives avez-vous, et la liste est-elle à jour ?
2. Chacune est-elle couverte par une convention écrite en cours de validité ?
3. Les flux autorisés correspondent-ils aux flux utilisés ?
4. Les accès partenaires sont-ils nominatifs et journalisés à part ?
5. Qui peut couper, et en combien de temps ?

La première question met souvent en difficulté : la liste tenue par le réseau, celle des achats et celle des métiers ne coïncident jamais.

Sources

• ISO/IEC 27002:2022, mesures 5.19 à 5.23, 8.21 et 8.22
• ANSSI — recommandations relatives à l’interconnexion de systèmes d’information
• Directive (UE) 2022/2555 (NIS 2), article 21.2 d)

Aller plus loin

La revue et la reprise de ces architectures relèvent de nos missions de sécurité réseau et d’orchestration des politiques de filtrage. Le volet contractuel se traite en gouvernance, risques et conformité.