Comptes SaaS partagés : un risque de conformité

Un compte SaaS partagé est un risque de conformité car une seule connexion correspond à plusieurs personnes au lieu d'une, ce qui casse la piste d'audit exigée à la fois par SOC 2, ISO 27001 et la plupart des contrats de licence éditeur. Si un identifiant de support, une place dans un outil de design ou un compte de réseau social est utilisé par plus d'une personne, vous ne pouvez plus répondre à la question de qui a fait quoi et quand, et cet écart suffit à faire échouer un test de contrôle ou à annuler une clause de licence par utilisateur nommé.

Qu'est-ce qu'un compte SaaS partagé ?

Trois schémas couvrent l'essentiel de ce qu'on trouve en audit. Un identifiant de rôle, comme support@ ou social@, conçu dès le départ pour qu'une équipe l'utilise ensemble. Un compte nommé unique dont le mot de passe vit dans un document partagé ou un coffre de gestionnaire de mots de passe accessible à toute l'équipe. Et un identifiant de prestataire ou d'agence qui a survécu à la fin du contrat et qu'on continue de transmettre à la personne suivante. Le premier est intentionnel et parfois inévitable. Les deux autres s'accumulent en silence et sont les premiers qu'un auditeur trouve, car ils portent toujours le nom d'une personne alors que plusieurs les utilisent.

Pourquoi les identifiants partagés créent-ils un risque de conformité ?

Tout référentiel de contrôle d'accès repose sur la même hypothèse : un identifiant, une personne responsable. Casser ce lien fait échouer trois choses en même temps. Vous ne pouvez plus prouver qui a effectué une action dans l'outil, ce qu'un auditeur demande lors du test d'un contrôle d'accès. Vous ne pouvez plus retirer l'accès à une seule personne sans bloquer tous ceux qui partagent l'identifiant, ce qui transforme un départ en événement collectif au lieu d'un simple retrait. Et vous ne pouvez plus montrer une correspondance propre entre personnes et licences, exactement ce que vérifie en premier un audit éditeur ou une négociation de renouvellement.

L'écart apparaît le plus vite au départ d'un salarié. Lisez le guide pour trouver les licences SaaS inutilisées pour l'audit qui repère les partants ayant gardé l'accès ; un compte partagé est le seul cas que cet audit ne peut pas corriger seul, car retirer la personne ne retire pas l'identifiant.

Quelles normes l'interdisent réellement ?

Deux référentiels reviennent dans presque tous les audits d'entreprise SaaS, et les deux traitent un compte partagé comme un constat plutôt qu'une préférence.

Aucun des trois n'interdit un compte de rôle en soi. Ils exigent qu'il ait un responsable nommé et une raison documentée d'exister, ce que la plupart des entreprises omettent.

Comment trouver les comptes partagés que vous avez déjà ?

Un export par outil, le même point de départ que tout audit de licences : sortir la liste des utilisateurs de chaque console d'administration et signaler tout identifiant dont le nom n'est pas une personne. Un identifiant au nom d'une équipe, d'un rôle, d'un produit ou d'un mot générique est le premier filtre. Le second filtre est plus difficile et attrape davantage : tout compte nommé dont le titulaire a quitté l'entreprise depuis plus d'un mois alors que l'identifiant reste actif est très souvent réutilisé par la personne suivante ayant besoin de l'accès, plutôt que réellement clôturé.

Dans l'espace de démonstration d'InventorIA, chacune des 24 licences est rattachée à une personne nommée plutôt qu'à un rôle, exactement la correspondance que vérifie un auditeur et celle qu'un identifiant partagé casse dès qu'il apparaît dans cette liste.

Comment supprimer un identifiant partagé sans casser le flux de travail ?

• Remplacez par des postes nommés là où la licence le permet. La plupart des éditeurs vendant au poste supportent aussi plusieurs utilisateurs nommés sur un même plan ; l'identifiant partagé était souvent un raccourci, pas une nécessité.
• Utilisez un accès délégué plutôt qu'un compte de rôle. Les outils avec SSO ou SCIM permettent de donner à un groupe de personnes l'accès à une boîte ou un canal partagé sans mot de passe partagé.
• Conservez l'exception, mais nommez un responsable. Certains comptes doivent réellement rester des comptes de rôle, comme l'identifiant d'une page de statut. Donnez-lui un responsable nommé, faites tourner l'identifiant quand ce responsable change, et documentez la raison de l'exception.
• Consignez la décision. Un auditeur accepte bien plus facilement une exception documentée qu'une exception non documentée qu'il trouve lui-même.

Que dire aux auditeurs quand il en reste un ?

N'attendez pas que l'audit le trouve. Listez tout identifiant partagé ou de rôle connu avant le début de la revue, avec la raison métier de son existence, son responsable, et la date de dernière rotation de l'identifiant. Cette liste suffit généralement à transformer un constat en exception acceptée, car elle montre que le contrôle existe même là où l'identifiant est partagé. Le guide du taux d'utilisation des licences couvre le chiffre postes-contre-personnes que les auditeurs demandent ensuite, et la détection du shadow IT couvre les outils jamais enregistrés comme comptes d'entreprise, le même écart un cran plus haut. Un registre qui rattache chaque licence à une seule personne nommée, avec les exceptions signalées volontairement, transforme cela d'une course avant audit en réponse de cinq minutes. Ouvrez la démo en direct pour voir les postes rattachés à des personnes nommées, ou commencez avec vos propres outils.

Questions fréquentes

Un compte SaaS partagé est-il toujours une violation de conformité ?

Pas automatiquement. Des référentiels comme SOC 2 et ISO 27001 acceptent les comptes de rôle s'ils ont un responsable nommé, une raison documentée et un processus de rotation et de revue. Un identifiant partagé non suivi et sans responsable est la version qui échoue à l'audit.

Un identifiant partagé casse-t-il un contrat de licence au poste ?

Souvent oui. La plupart des contrats au poste définissent un poste comme une personne nommée. Plusieurs personnes partageant les identifiants d'un même poste constitue un usage que la licence ne couvre pas, ce qu'un audit éditeur peut signaler comme un manquement.

Comment trouver les comptes partagés dans nos outils SaaS ?

Exportez la liste des utilisateurs de chaque console d'administration et signalez tout identifiant au nom d'un rôle, d'une équipe ou d'un produit plutôt que d'une personne, puis vérifiez les comptes nommés dont le titulaire a quitté l'entreprise mais dont l'identifiant reste actif.

Quelle est la différence entre un compte partagé et un compte de service ?

Un compte de service authentifie une intégration ou un script, pas une personne, et n'a normalement aucune connexion interactive. Un compte partagé est un identifiant humain utilisé par plusieurs personnes, le schéma que les auditeurs signalent.

Le SSO peut-il supprimer le besoin d'identifiants partagés ?

Dans la plupart des cas, oui. Le SSO et le SCIM permettent à plusieurs personnes d'accéder à une boîte, un canal ou un outil partagé via leur propre identité plutôt qu'un mot de passe commun, ce qui rétablit la correspondance un-à-un que les auditeurs recherchent.