Gérer les accès externes des prestataires

Un accès tiers n’est pas un compte interne avec une adresse électronique différente. Dès qu’un prestataire délègue une tâche à un sous-traitant, la chaîne de responsabilité, l’identité réelle et la révocation deviennent des problèmes d’architecture, pas des cases dans un portail fournisseur. La règle à retenir est brutale : l’organisation qui expose une ressource conserve la responsabilité de l’accès, même si l’authentification vient d’ailleurs.

→ Lire l’explication complète de la marmotte

Responsabilité des identités tierces et sous-traitance en cascade

Le compromis central est net : déléguer l’authentification réduit la gestion de comptes locaux, mais transfère une partie de la décision de sécurité à une organisation dont on ne maîtrise ni le recrutement, ni les postes, ni la révocation. Cette délégation ne doit jamais devenir une délégation de responsabilité. Un fournisseur d’identité externe atteste qu’une personne s’est connectée selon ses règles, pas qu’elle doit accéder aux données exposées.

Toute relation externe doit être modélisée par trois objets distincts :

L’organisation contractante, responsable de la prestation.
La personne physique ou le compte de charge de travail, sujet réel de l’accès.
Le mandat d’accès, limité par une ressource, une action, une durée et un périmètre.

Mélanger ces objets produit le classique compte [email protected], partagé entre cinq personnes et immortel par omission. Ce compte résiste très bien aux audits parce qu’il ne raconte rien. Il résiste moins bien à une compromission.

Pour chaque sous-traitant déclaré ou découvert, conserver une relation de parrainage : organisation interne -> prestataire principal -> sous-traitant -> identité. Une identité sans sponsor interne, sans propriétaire métier et sans date de fin doit être refusée par défaut. Le partenaire principal peut administrer ses collaborateurs, mais il ne doit pas pouvoir créer une chaîne de sous-traitance silencieuse dans le système cible.

Cette exigence doit apparaître dans le flux technique. L’attribut d’organisation fourni par un partenaire ne suffit pas : il est déclaratif et souvent stable bien après le départ d’un salarié. Le système cible doit associer l’identité fédérée à un enregistrement local de mandat, avec un identifiant immuable du partenaire, un propriétaire interne et une échéance. On obtient ainsi une révocation indépendante de l’annuaire du partenaire.

Les contrôles de gouvernance ne remplacent pas ce mécanisme. Une clause impose une obligation, elle ne ferme pas une session et ne retire pas un jeton. Les principes de gouvernance servent à attribuer la responsabilité, mais l’application doit pouvoir bloquer l’accès même lorsque le circuit contractuel dort dans un classeur numérique.

Fédération inter-entreprises et confiance transitive

La fédération permet à un fournisseur de services, ou SP (Service Provider), de s’appuyer sur un fournisseur d’identité, ou IdP (Identity Provider), détenu par le partenaire. Avec OpenID Connect, ou OIDC (OpenID Connect), le SP reçoit un jeton signé contenant une identité et des attributs. Avec Security Assertion Markup Language, ou SAML, il reçoit une assertion signée. Le protocole transporte une preuve, pas une politique de sécurité universelle.

La recommandation est de limiter la fédération à un saut : un SP interne doit établir une confiance explicite avec l’IdP du partenaire direct, jamais avec une fédération ouverte où chaque membre peut introduire un autre émetteur. La confiance transitive est séduisante sur un schéma d’architecture, surtout entre deux rectangles aux couleurs pastel. En production, elle rend l’origine effective de l’identité difficile à vérifier et la révocation presque folklorique.

Refuser les assertions dont l’émetteur, l’audience, le destinataire, la durée et l’identifiant de client ne correspondent pas exactement à la relation déclarée. Pour OIDC, valider au minimum iss, aud, exp, nbf, la signature et l’algorithme attendu. Ne jamais accepter un algorithme annoncé par le jeton sans liste locale d’algorithmes autorisés. Pour SAML, vérifier la signature de l’assertion ou de la réponse selon le profil imposé, la condition AudienceRestriction, Recipient, InResponseTo et la fenêtre temporelle.

Un IdP externe doit être classé par niveau d’assurance. Ce niveau dépend notamment de l’authentification multifacteur, de la résistance au hameçonnage, de la protection des postes et de la vitesse de désactivation des comptes. Un jeton OIDC signé avec une authentification par mot de passe seul ne devient pas résistant au hameçonnage parce qu’il traverse une frontière d’entreprise. La cryptographie signe l’affirmation, elle ne transforme pas l’affirmation en vérité.

Pour les accès d’administration, imposer une authentification multifacteur résistante au hameçonnage, par exemple une clé de sécurité fondée sur WebAuthn (Web Authentication). Si le partenaire ne peut pas la fournir, créer une identité locale administrée avec un second facteur contrôlé côté ressource. C’est plus coûteux, mais le coût reste inférieur à celui d’un compte administrateur dont la sécurité dépend d’une politique inconnue.

Le canal entre organisations doit utiliser Transport Layer Security, ou TLS, avec validation stricte des certificats. L’authentification mutuelle par certificat, ou mTLS (mutual TLS), ajoute une identité de système utile pour les échanges machine à machine, mais elle ne remplace pas l’identité humaine derrière une opération sensible. Les limites de TLS restent décrites dans la sécurisation des canaux.

Portails partenaires, EDI et API B2B

Un portail partenaire doit séparer l’authentification de l’autorisation. L’authentification répond à « qui a présenté une preuve acceptable ? ». L’autorisation répond à « quelle action ce sujet peut-il exercer sur quelle ressource ? ». Réutiliser le groupe partner-users comme politique métier est une dette technique avec une date d’expiration inconnue, donc généralement oubliée.

Pour les utilisateurs humains, préférer OIDC avec un client par portail et, lorsque la relation le justifie, une connexion fédérée par partenaire. Mapper les attributs externes vers des rôles locaux étroits. Ne pas consommer directement des groupes arbitraires du partenaire : leur sémantique, leur cycle de vie et leur contrôle de changement échappent au SP. Un attribut externe department=finance n’autorise rien tant qu’une règle locale versionnée ne le traduit pas vers une permission.

Pour l’EDI (Electronic Data Interchange) et les interfaces API (Application Programming Interface) B2B, distinguer le système appelant de l’organisation propriétaire. OAuth 2.0 permet d’émettre un jeton d’accès pour un client machine, mais le flux client_credentials ne porte pas un utilisateur. Il faut donc journaliser l’organisation, le client technique, la clé ou le certificat utilisé, l’audience ciblée et l’autorisation évaluée.

Éviter les clés API statiques sans expiration. Elles ne peuvent pas porter une audience fiable, sont rarement liées à une identité de machine vérifiable et finissent copiées dans une variable de pipeline nommée FINAL_FINAL_OK. Préférer un certificat mTLS ou une authentification OAuth 2.0 par clé privée, avec jetons courts, audience unique et portées limitées. Une portée api.read couvrant toutes les filiales et tous les dossiers n’est pas une portée, c’est une permission globale avec un chapeau.

Exemple de validation d’un jeton OIDC partenaire

Le service ne doit accepter qu’un émetteur explicitement approuvé et lier le sujet externe à un mandat local actif. L’exemple suivant utilise curl et jq, outils disponibles sur la plupart des distributions Linux. Il montre la partie de contrôle métier après validation cryptographique réalisée par une bibliothèque OIDC maintenue, jamais par un découpage maison du jeton.

# Le middleware OIDC a déjà validé signature, iss, aud, exp et nonce.
# PARTNER_SUBJECT est le claim "sub" stable fourni par l'IdP partenaire.
# Le mandat local impose un sponsor, une échéance et un périmètre applicatif.

curl --fail --silent \
  "https://iam-interne.example/api/mandats?issuer=https%3A%2F%2Fidp.partenaire.example&subject=${PARTNER_SUBJECT}" \
| jq -e '
    .status == "active"
    and .expires_at > now
    and .sponsor_id != null
    and (.permissions | index("orders:read"))
  ' >/dev/null

# Refuser la requête si le mandat est absent, expiré ou insuffisant.
# Ne pas déduire l'autorisation du seul domaine de messagerie.

L’identifiant sub OIDC doit être pairwise ou unique par relation lorsque le partenaire le permet. Un identifiant public réutilisé entre plusieurs SP facilite la corrélation des activités par des parties qui n’en ont pas besoin. La minimisation des attributs n’est pas un exercice de style : moins d’attributs reçus signifie moins de données à protéger et moins de règles fragiles.

Révocation, supervision et reprise des accès externes

La révocation est le point où les architectures de fédération racontent le plus d’histoires optimistes. Révoquer un compte chez le partenaire ne révoque pas un jeton déjà émis. Révoquer un certificat ne coupe pas nécessairement une session établie. Désactiver un mandat local doit donc être contrôlé à chaque décision sensible, ou accompagné de jetons très courts et d’une liste de révocation distribuée avec une latence connue.

Fixer des durées maximales : quelques minutes pour un jeton d’accès exposant une API sensible, une durée de session bornée pour un portail, et une réauthentification pour les opérations d’administration ou d’export massif. Les jetons de rafraîchissement doivent être rotatifs, liés au client et invalidables par partenaire. Sans cela, une désactivation devient une promesse dépendante de l’expiration naturelle.

Journaliser au format structuré : identifiant interne de mandat, émetteur fédéré, sujet externe, organisation, client OAuth 2.0, empreinte de certificat mTLS, ressource, décision et motif du refus. Ne pas journaliser le jeton brut, les assertions SAML complètes ni les secrets. Un journal qui contient des jetons est une collection de doubles de clés, avec une interface de recherche.

La supervision doit détecter les nouveaux émetteurs, les changements de clés de signature, les authentifications hors des plages déclarées, les refus répétés et les privilèges jamais utilisés. Une rotation de clé de signature d’IdP exige un jeu de clés publié avant bascule, une fenêtre de recouvrement bornée et une alerte sur toute clé inconnue. Accepter automatiquement toute nouvelle clé récupérée depuis une URL de métadonnées non surveillée revient à externaliser la liste des émetteurs autorisés.

Sauvegarder les mappings locaux, les mandats, les configurations de confiance, les empreintes de certificats et les journaux d’audit selon leur durée de conservation. Restaurer l’IdP sans restaurer les révocations et les mandats réactive des accès que l’incident avait précisément supprimés. Les exigences de continuité doivent donc inclure un test de restauration avec un partenaire désactivé.

🐝 Ce qui arrive si on s’en passe

Sans mandats locaux ni parrainage explicite, un incident chez un partenaire ne peut pas être circonscrit : rien ne permet de dire quelles ressources ont été atteintes, par quelle organisation, ni pendant combien de temps, ce qui rend toute notification et toute mise en cause contractuelle approximatives. La réaction se réduit alors à une mesure grossière, couper l’intégralité de la fédération, ce qui interrompt aussi les partenaires sains. Les comptes partagés et les clés sans expiration survivent aux fins de mission et redeviennent des points d’entrée utilisables des mois plus tard, sans propriétaire interne pour les remarquer. La revue périodique perd son objet, puisqu’un accès sans échéance ni sponsor ne peut être ni justifié ni retiré. Enfin, une restauration de sauvegarde réintroduit des accès dont la suppression n’a jamais été tracée ailleurs que dans l’annuaire d’un tiers.

🦫 Explication de la marmotte 🍫

Quand une entreprise extérieure doit accéder à un service, il faut d’abord identifier son entreprise, les personnes ou programmes qui agiront, et la personne interne responsable de cet accès. Chaque accès reçoit une date de fin, des droits limités et une trace permettant de savoir pourquoi il existe.

L’entreprise extérieure peut prouver l’identité de ses salariés avec son propre système de connexion. Le service interne vérifie alors que cette preuve vient bien de l’entreprise attendue, qu’elle n’est pas expirée et qu’elle concerne ce service précis. Cette preuve ne donne pas automatiquement tous les droits. Le service consulte aussi sa propre liste d’autorisations pour vérifier que la personne possède encore un mandat actif.

Pour les échanges entre logiciels, le même principe s’applique. Le logiciel doit prouver quelle organisation le contrôle et ne reçoit qu’un droit limité à une action donnée. Une clé permanente partagée dans un fichier ne permet pas de retirer vite l’accès ni de savoir quelle machine l’a utilisée.

Quand une personne quitte le partenaire, le partenaire doit couper son compte, mais le service interne doit aussi désactiver son mandat. Les preuves déjà émises peuvent rester valables jusqu’à leur expiration. Des durées courtes, des contrôles fréquents et des journaux détaillés réduisent cette période. Si un partenaire délègue à son tour, chaque nouveau niveau doit être déclaré et approuvé, sinon l’accès est refusé.

Pages voisines

La citent

Gérer les accès externes des prestataires

Elle cite

Gérer les accès externes des prestataires

Gérer les accès externes des prestataires

Responsabilité des identités tierces et sous-traitance en cascade

Fédération inter-entreprises et confiance transitive

Portails partenaires, EDI et API B2B

Exemple de validation d’un jeton OIDC partenaire

Révocation, supervision et reprise des accès externes

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines