SSO, SCIM et journaux d’audit pour un assistant IA d’entreprise

Un abonnement entreprise à un assistant d’intelligence artificielle (IA) n’apporte de sécurité que si l’identité des utilisateurs est pilotée par l’annuaire de l’organisation, du premier jour au départ. Sans authentification unique imposée, sans provisionnement automatique et sans journaux exportés, l’espace entreprise n’est qu’un compte payé en commun. Le sujet ici : l’authentification unique (SSO, Single Sign-On), le provisionnement SCIM (System for Cross-domain Identity Management), les journaux d’audit, la rétention et le départ des salariés.

→ Lire l’explication complète de la marmotte

SSO imposé et domaine vérifié : fermer les comptes parallèles

Le SSO se branche sur le fournisseur d’identité (IdP, Identity Provider) de l’organisation en SAML 2.0 (Security Assertion Markup Language) ou en OIDC (OpenID Connect). Deux prérequis conditionnent son efficacité, et leur disponibilité varie selon les offres (à vérifier dans la console d’administration) :

La vérification du domaine, en général par un enregistrement DNS (Domain Name System) de type TXT. Elle permet, selon les produits, de rattacher à l’espace entreprise les comptes déjà créés avec une adresse de l’organisation, au lieu de laisser vivre des comptes individuels à côté.
L’imposition du SSO, qui désactive la connexion par mot de passe. Tant qu’un mot de passe local reste possible, la double authentification et l’accès conditionnel (conformité du poste, localisation) configurés dans l’IdP ne s’appliquent pas, et un départ ne coupe rien.

Un piège d’exploitation revient toujours : désactiver un compte dans l’IdP empêche les nouvelles connexions, pas les sessions déjà ouvertes. Les applications mobiles, en particulier, gardent des sessions longues. La durée de session côté fournisseur et l’existence d’une révocation forcée se vérifient avant de compter sur le SSO pour un départ conflictuel.

Position : domaine vérifié et SSO imposé sont des prérequis, pas des options. Le compromis assumé : une panne de l’IdP rend l’assistant indisponible. Un compte d’administration de secours hors SSO, unique, protégé par une authentification forte et surveillé, couvre ce cas sans rouvrir la porte à tout le monde. Le SSO a au moins une vertu rare dans le secteur : il n’a jamais été vendu comme une IA.

Provisionnement SCIM et départ des salariés

Le SSO seul, avec création de compte à la première connexion, crée des comptes mais ne les supprime jamais. SCIM 2.0 (RFC, Request for Comments, 7643 pour le schéma, RFC 7644 pour le protocole) fait pousser par l’IdP les créations, les modifications et les désactivations, et rattache les rôles aux groupes de l’annuaire. Sans lui, l’espace accumule des comptes orphelins, payés et actifs.

Le départ se décompose en deux temps. Désactiver d’abord : l’accès est coupé, les données restent disponibles pour une transmission ou une conservation à des fins juridiques. Supprimer ensuite, selon la durée de rétention décidée. Entre les deux se posent les questions que la plupart des procédures oublient : que deviennent les conversations du partant, ses assistants personnalisés, ses liens de partage encore actifs, ses connecteurs autorisés ? Les possibilités de transfert de propriété varient selon les produits ; elles se testent sur un compte fictif avant le premier départ réel.

Le jeton SCIM lui-même est un secret à haut privilège : un jeton porteur capable de créer des comptes, voire des administrateurs selon le produit. Il se stocke dans le coffre à secrets de l’IdP, sa régénération figure parmi les événements surveillés, et sa rotation se planifie comme celle de n’importe quel identifiant de service.

Journaux d’audit et rétention de l’espace entreprise

Les journaux d’audit de l’espace consignent en général les connexions, les actions d’administration, les changements de réglages et, selon les offres, les partages, les exports et les autorisations de connecteurs. Le contenu des conversations passe, quand il est accessible, par une interface de conformité distincte. La rétention des journaux dans la console est limitée ; leur export vers le SIEM (Security Information and Event Management) est la seule façon de mener une enquête qui remonte au-delà.

Détections à écrire en priorité : création de lien de partage public, export massif, ajout d’un administrateur, modification des réglages SSO ou SCIM, régénération du jeton SCIM, connexion ne passant pas par l’IdP.

La rétention des conversations est le second arbitrage. Une rétention courte réduit ce qu’un compte compromis ou une fuite expose ; elle détruit aussi la matière d’une enquête et peut entrer en conflit avec une obligation de conservation. Position : aligner la rétention du contenu sur celle de la messagerie de l’organisation, et conserver les journaux d’audit plus longtemps que le contenu, puisqu’ils répondent à la question « qui a fait quoi » sans exposer ce qui a été écrit. La rétention des données côté fournisseur, hors de l’espace administré, relève d’une page à part, tout comme les comptes personnels non déclarés.

Ce que ce dispositif ne garantit pas : il ne voit rien de ce qui se passe hors de l’espace entreprise, et un journal indique qu’un export a eu lieu, pas où le fichier est allé ensuite. Les principes de gestion du cycle de vie des identités relèvent de Identités, accès et habilitations, la supervision de Menaces, détection et réponse.

Exemple : désactiver un compte par SCIM

L’IdP fait normalement ce travail ; l’appel manuel sert à tester le connecteur et à couper un accès en urgence. Point d’entrée et jeton sont fournis par la console d’administration de l’assistant.

# Point d'entrée SCIM de l'espace (fourni par la console d'administration)
SCIM="https://scim.fournisseur.example/scim/v2"
# Jeton porteur lu depuis un fichier protégé, jamais en clair dans le script
TOKEN="$(cat /run/secrets/scim_token)"

# 1) Retrouver l'identifiant SCIM du compte à partir de l'adresse (filtre RFC 7644)
ID="$(curl -s -G "$SCIM/Users" -H "Authorization: Bearer $TOKEN" \
      --data-urlencode 'filter=userName eq "j.martin@exemple.fr"' \
      | jq -r '.Resources[0].id')"

# 2) Désactiver le compte (active=false) : accès coupé, données conservées
curl -s -X PATCH "$SCIM/Users/$ID" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/scim+json" \
  -d '{"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
       "Operations":[{"op":"replace","path":"active","value":false}]}' \
  | jq '{id, userName, active}'

La réponse doit renvoyer active: false. Reste à vérifier, une fois pour toutes sur un compte de test, qu’une session déjà ouverte est bien coupée par cette désactivation.

🐝 Ce qui arrive si on s’en passe

Sans SSO imposé, chaque compte de l’assistant garde un mot de passe propre, hors de portée de l’IdP. Ce mot de passe est exposé au bourrage d’identifiants : un couple adresse et mot de passe réutilisé, issu d’une fuite sur un autre service, suffit pour ouvrir le compte, et ni la double authentification ni l’accès conditionnel de l’annuaire ne s’interposent. L’attaquant obtient alors l’historique complet des conversations de l’utilisateur, souvent riche en contexte interne, et la connexion n’apparaît pas dans les journaux de l’IdP, là où l’équipe de détection surveille les authentifications.

🦫 Explication de la marmotte 🍫

Quand une entreprise paie un assistant en ligne pour ses salariés, elle doit contrôler qui peut s’y connecter. La première règle est l’authentification unique : le salarié se connecte avec le compte de l’entreprise, vérifié par le service d’identité maison, et non avec un mot de passe créé à part. Tant qu’un mot de passe à part reste possible, l’entreprise ne peut pas bloquer ce compte quand la personne s’en va. La deuxième règle est la synchronisation automatique des comptes : l’annuaire de l’entreprise crée le compte à l’arrivée et le désactive au départ, sans attendre qu’un administrateur y pense. Désactiver n’efface rien : l’accès est coupé, mais les discussions restent disponibles pour être transmises ou conservées, puis effacées plus tard. Attention, une connexion déjà ouverte, par exemple sur un téléphone, peut continuer un moment : il faut le tester. La troisième règle est l’enregistrement des événements : connexions, changements de réglages, partages, exportations. Ces enregistrements sont copiés vers l’outil de surveillance de l’entreprise, qui les garde plus longtemps que le contenu des discussions et signale les actions suspectes.

Pages voisines

La citent

SSO, SCIM et journaux d'audit pour un assistant IA d'entreprise

Elle cite