Partage de données inter-organisations par API

Partager des données avec une autre organisation ne consiste pas à ouvrir une API (Application Programming Interface) derrière un jeton et à espérer que le contrat absorbera les erreurs d’architecture. Le compromis central est brutal : plus l’échange est riche et temps réel, plus la surface d’attaque, la dette d’exploitation et le coût de révocation augmentent. La recommandation est de publier des interfaces de données minimales, orientées finalité, avec une confiance limitée à chaque requête.

→ Lire l’explication complète de la marmotte

Contrat de données et responsabilité technique

Un contrat commercial ou de sous-traitance fixe des obligations entre personnes morales. Il ne constitue pas un contrôle d’accès. Une clause interdisant une réutilisation n’empêche ni une extraction massive, ni une copie locale, ni un compte de service compromis. Le contrat juridique doit donc être doublé d’un contrat de données : finalité, catégories de données, fréquence, fraîcheur attendue, rétention, règles de correction, identifiants, niveau de disponibilité et procédure de cessation.

Chaque champ exposé doit avoir un propriétaire fonctionnel et une justification. Un identifiant interne stable, une adresse électronique et une date de naissance ne portent pas le même risque de corrélation. Exposer les trois dans une même réponse transforme une API d’état en source de profilage. La minimisation doit s’appliquer au schéma, pas seulement aux filtres déclarés par le consommateur.

Le contrat de données doit définir les changements incompatibles : suppression d’un attribut, changement de sémantique, modification de format, réduction du périmètre de recherche ou nouvelle règle de filtrage. Une version d’API n’est pas un geste décoratif destiné à rassurer un comité. Elle sépare des engagements de compatibilité. Conserver indéfiniment /v1 parce qu’un partenaire « migrera bientôt » produit un musée de vulnérabilités avec authentification.

Prévoir explicitement la cessation : date de coupure, révocation des identités techniques, suppression ou anonymisation attestée côté consommateur, conservation des journaux et traitement des sauvegardes. Les sauvegardes ne deviennent pas magiquement compatibles avec une obligation de suppression parce qu’elles dorment sur bande. Elles imposent une politique de rétention documentée et vérifiable.

Les principes de minimisation, de classification et de traçabilité prolongent les règles présentées dans la section données. La conformité n’est pas une propriété du protocole : elle dépend du périmètre effectivement transmis, des accès accordés et de la capacité à démontrer ces faits.

API d’échange et confiance limitée

Une interface inter-organisations doit être conçue comme si le réseau partenaire, son poste d’administration et ses journaux applicatifs pouvaient être compromis. Cette hypothèse n’accuse personne, elle évite de faire reposer la sécurité sur une poignée de main commerciale et trois slides de zero trust.

Préférer une API de consultation ou de dépôt ciblé à une réplication générale de base de données. Une réplication donne au partenaire une copie durable, donc un périmètre de sécurité hors contrôle. Une API permet de limiter les objets, les champs, les droits, les cadences et de couper l’accès. Elle coûte davantage en disponibilité et en exploitation, mais ce coût est le prix de la révocation.

L’authentification d’un système doit combiner deux preuves distinctes :

un certificat client avec Transport Layer Security mutuel (mTLS), pour identifier le client technique au niveau de la connexion ;
un jeton OAuth 2.0 (Open Authorization), pour porter l’autorisation demandée, sa durée de vie et son audience ;
une autorisation côté ressource, qui vérifie que le partenaire identifié peut accéder à l’objet demandé.

Le mTLS ne remplace pas OAuth 2.0. Un certificat identifie une charge de travail, pas l’usage métier précis ni l’opération autorisée. OAuth 2.0 ne remplace pas le mTLS non plus : un jeton volé reste réutilisable jusqu’à son expiration si aucun mécanisme ne lie le jeton au certificat client. Pour des données sensibles, imposer des jetons liés au certificat, avec une preuve de possession, plutôt qu’un jeton porteur réutilisable. Un JSON Web Token (JWT) signé est pratique, mais sa portabilité est précisément son défaut quand il fuit.

Les jetons doivent porter une audience unique, des droits fins et une durée courte. Un droit read:customers est trop large si l’échange porte sur l’éligibilité à une prestation. Préférer eligibility:read avec une réponse réduite à la décision et à son horodatage. La meilleure donnée à protéger reste celle qui ne sort jamais. Ce principe survit très bien aux démonstrations de plateformes miracles.

Ne jamais accepter qu’un identifiant fourni dans l’URL suffise à établir le droit d’accès. Le contrôle doit lier le sujet du jeton, l’organisation partenaire, la finalité et la ressource demandée. Sans cela, modifier un identifiant devient une attaque d’autorisation par référence directe, parfois appelée IDOR (Insecure Direct Object Reference).

Exemple d’appel API avec mTLS et jeton borné

L’exemple suivant appelle une ressource d’éligibilité. Le serveur doit vérifier le certificat client, la signature du jeton, son audience, ses droits et le rattachement de l’identifiant demandé à l’organisation émettrice. La présence d’un jeton valide ne dispense aucune de ces vérifications.

# Variables injectées par un gestionnaire de secrets, jamais stockées dans le dépôt.
export API_BASE="https://api.partenaire.example"
export CLIENT_CERT="/run/secrets/partner-client.crt"
export CLIENT_KEY="/run/secrets/partner-client.key"
export ACCESS_TOKEN="$(cat /run/secrets/access-token)"

# Le certificat prouve l'identité technique du client.
# Le jeton borne l'opération, l'audience et sa durée de validité.
curl --fail --silent --show-error \
  --cert "$CLIENT_CERT" \
  --key "$CLIENT_KEY" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "Accept: application/json" \
  "$API_BASE/v1/eligibility/persons/8f14e45f-ea2c-4f31-a6fa-2f9bb6e4d7c1"

Le certificat client doit être émis par une autorité de certification dédiée aux partenaires, distincte de l’infrastructure de certificats interne. Une infrastructure de clés publiques et TLS mal segmentée transforme la compromission d’une autorité intermédiaire en droit d’entrée sur des services qui n’auraient jamais dû se connaître.

Éviter les clés privées exportables dans les conteneurs lorsque la plateforme peut utiliser un module cryptographique matériel. Un HSM et PKCS#11 réduit l’exposition de la clé, mais ne corrige ni une autorisation trop large ni un appel légitime effectué par une charge compromise. Un coffre-fort ne rend pas le contenu intelligent, il évite seulement qu’il se promène dans les dumps mémoire.

Surface d’attaque des échanges inter-organisations

Les attaques les plus fréquentes ne cassent pas TLS. Elles exploitent ce que l’API accepte après TLS : jeton rejoué, droit trop large, pagination non bornée, filtrage contournable, journal contenant des données sensibles, ou confusion entre environnements.

Le rejeu d’un jeton est limité par une durée de vie courte, une audience stricte et une liaison cryptographique au certificat client. La révocation d’un certificat ne coupe pas les sessions TLS déjà établies ni les jetons déjà émis. Il faut donc limiter la durée des connexions persistantes, vérifier l’état de révocation lorsque l’architecture le permet, et prévoir un mécanisme de désactivation immédiate du client côté serveur.

Les attaques d’énumération apparaissent quand les identifiants sont prédictibles ou quand l’API répond différemment selon l’existence d’une personne. Utiliser des identifiants opaques, limiter le débit par identité cliente et uniformiser les erreurs réduit la fuite. Un code 404 ou 403 n’est pas une barrière de confidentialité si les temps de réponse, la taille des réponses ou les messages d’erreur racontent le reste.

Les appels sortants vers des URL fournies par un partenaire exposent à la falsification de requête côté serveur, ou SSRF (Server-Side Request Forgery). N’autoriser que des hôtes explicitement déclarés, résoudre les noms dans un environnement contrôlé, bloquer les plages d’administration et interdire les redirections automatiques. Laisser un client HTTP suivre n’importe quelle redirection, c’est donner une boussole à un robot et appeler cela une stratégie réseau.

Les journaux doivent tracer l’identité cliente, le droit utilisé, la ressource logique, le résultat et un identifiant de corrélation. Ils ne doivent pas contenir de jeton, de certificat complet, de corps de réponse ni de secret. Centraliser ces événements dans un SIEM (Security Information and Event Management) permet de détecter les extractions atypiques, à condition de définir des seuils par partenaire et par opération. Sans base de comportement, une alerte sur « beaucoup de données » reste une philosophie de tableur.

Rotation, supervision et reprise des accès

Un échange inter-organisations dépend d’actifs qui expirent : certificats, clés de signature, secrets d’application, droits OAuth 2.0 et règles de réseau. Inventorier chaque actif avec son propriétaire, son usage, sa date d’expiration et sa procédure de renouvellement. Une alerte à 60, 30 et 7 jours est un minimum ; une rotation testée en environnement séparé est obligatoire avant toute échéance.

Publier les clés publiques de vérification via un JWKS (JSON Web Key Set) avec des identifiants de clés distincts. Le serveur consommateur doit accepter simultanément l’ancienne et la nouvelle clé pendant une fenêtre bornée, puis retirer l’ancienne. Changer une clé de signature sans chevauchement casse les jetons valides. Conserver l’ancienne indéfiniment casse l’objectif de rotation. La cryptographie adore les fenêtres de transition, les équipes d’exploitation un peu moins.

Tester au moins quatre défaillances : indisponibilité du fournisseur d’identité, certificat expiré, clé de signature inconnue et révocation d’urgence d’un partenaire. Pour chaque cas, définir le comportement métier : refus immédiat, mise en attente, réessai borné ou dégradation sans donnée. Ne jamais basculer automatiquement en accès anonyme lors d’un échec d’authentification. Cette idée revient régulièrement sous des noms créatifs ; elle reste une porte ouverte avec une étiquette résilience.

La sauvegarde doit couvrir les configurations, les listes d’autorisation, les journaux d’audit et les métadonnées de clés, pas les clés privées exportables si un module matériel les protège. Définir l’objectif de reprise et la perte de données maximale acceptable avant d’écrire l’automatisation. Restaurer une configuration périmée peut réactiver un partenaire révoqué, ce qui donne une reprise techniquement réussie et sécuritairement désastreuse.

🐝 Ce qui arrive si on s’en passe

Sans interface bornée ni contrat de données exécutable, l’échange retombe sur des exports de fichiers ou une réplication, et la donnée quitte définitivement le périmètre de celui qui la détient : plus rien n’est révocable, seulement effaçable sur promesse. En cas de fuite constatée chez un tiers, aucune attribution n’est possible : faute de droits fins et d’identités techniques distinctes par partenaire, il devient impossible de dire quel flux a servi, ni de couper un seul canal sans interrompre tous les autres. L’audit perd sa preuve : on ne peut plus démontrer quelles catégories de champs ont réellement circulé, à quelle cadence, ni depuis quand. La fin de relation ne s’instrumente plus, et la reprise après incident se fait à l’aveugle, sans périmètre à notifier ni volumétrie à qualifier.

🦫 Explication de la marmotte 🍫

Pour partager des données, deux organisations commencent par définir exactement quelles informations peuvent circuler, pourquoi elles sont demandées, combien de temps elles peuvent être gardées et ce qui se passe à la fin de la relation. Cette règle écrite ne suffit pas : le système doit empêcher l’accès à ce qui n’est pas autorisé.

L’organisation qui expose les données crée une porte informatique limitée à des demandes précises. L’autre organisation prouve l’identité de son logiciel avec un certificat numérique et reçoit une autorisation de courte durée pour une action donnée. Le serveur vérifie ensuite plusieurs points : le certificat est reconnu, l’autorisation n’est pas expirée, elle concerne bien ce serveur, elle permet l’action demandée et la donnée appartient bien au périmètre autorisé.

Les réponses doivent contenir seulement les informations nécessaires. Si une demande porte sur une décision, transmettre la décision plutôt qu’un dossier complet réduit les dégâts possibles. Le serveur enregistre qui a demandé quoi, quand et avec quel résultat, sans recopier les secrets ni les données personnelles dans les journaux.

Quand un certificat, une clé ou une autorisation est volé ou expire, l’accès doit pouvoir être bloqué rapidement. Les clés et certificats sont remplacés avant leur fin de validité. En cas de panne, le système refuse l’accès ou attend, selon une règle décidée à l’avance. Il ne doit jamais ouvrir l’accès parce que la vérification a échoué.

Pages voisines

La citent

Partage de données inter-organisations par API

Elle cite

Partage de données inter-organisations par API

Partage de données inter-organisations par API

Contrat de données et responsabilité technique

API d’échange et confiance limitée

Exemple d’appel API avec mTLS et jeton borné

Surface d’attaque des échanges inter-organisations

Rotation, supervision et reprise des accès

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines