Cloisonnement strict (gouvernance de la portée d'accès)
Restreignez les identifiants système aux utilisateurs approuvés via des groupes du fournisseur d'identité distant — la différence entre « cette intégration peut lire toutes les boîtes aux lettres du tenant » et « cette intégration peut uniquement lire les boîtes aux lettres de ces membres d'espace de travail ».
Les identifiants système (OAuth client_credentials) sont puissants par défaut. Une inscription d'application Microsoft 365 configurée pour la plateforme peut lire toutes les boîtes aux lettres, calendriers et sites SharePoint de votre tenant — il en va de même pour la plupart des fournisseurs cloud qui proposent des identifiants de type principal de service.
Le cloisonnement strict est le mécanisme de la plateforme pour restreindre cette portée. Une fois activé, un identifiant système est limité aux membres d'un groupe spécifique du fournisseur d'identité (ex. un groupe de sécurité Microsoft Entra ID), et la plateforme maintient ce groupe synchronisé avec la liste des membres de l'espace de travail concerné.
Le cloisonnement strict est optionnel, mais fortement recommandé pour tout identifiant système accordant un accès à l'ensemble du tenant. L'assistant de configuration en fait une configuration unique.
Quand l'utiliser
Utilisez le cloisonnement strict lorsque :
- L'intégration utilise un identifiant système (flux
client_credentials), pas OAuth par utilisateur. - La portée effective de l'identifiant est plus large que l'espace de travail qui l'utilise (ex. « tout Microsoft Graph » au lieu de « la boîte aux lettres de cet utilisateur »).
- Vous souhaitez que les modifications de l'appartenance à l'espace de travail se répercutent automatiquement dans le groupe de sécurité, sans synchronisation manuelle.
Vous n'avez pas besoin du cloisonnement strict pour les intégrations OAuth par utilisateur (chaque utilisateur s'authentifie lui-même), les intégrations par clé API limitées à une ressource spécifique, ou les identifiants système déjà à portée étroite chez le fournisseur.
Comment ça fonctionne
Espace de travail Groupe de sécurité IdP
┌──────────────────────┐ ┌──────────────────────┐
│ - Maya (membre) │ ◀────▶ │ - Maya │
│ - John (admin) │ sync │ - John │
│ - Sarah (owner) │ │ - Sarah │
└──────────────────────┘ └──────────────────────┘
│
│ contrôle au nom de qui
│ l'identifiant système
│ est autorisé à agir
▼
Identifiant système
(ex. inscription d'app M365)La plateforme synchronise les membres de l'espace de travail dans le groupe de sécurité. La politique d'accès de l'identifiant système chez le fournisseur (ex. RBAC pour les applications de Microsoft Graph) restreint l'identifiant à n'agir qu'au nom des membres de ce groupe.
Configuration
Le cloisonnement strict est configuré par identifiant d'espace de travail via l'Assistant de gouvernance sous Paramètres → Intégrations → Microsoft → Identifiants d'espace de travail → Configurer la gouvernance.
L'assistant s'ouvre avec un guide de configuration pour votre fournisseur d'identité. Actuellement, cela est supporté pour les Groupes de sécurité Microsoft Entra ID.
Suivez le guide de configuration. Il vous accompagne pour :
- Créer un Groupe de sécurité dans Entra ID (nommé par exemple
Scrydon — Workspace Alpha). - Attribuer l'accès de l'inscription d'application de l'identifiant système via RBAC pour les applications, limité au Groupe de sécurité.
- Copier l'Object ID du Groupe de sécurité pour l'étape suivante.
Collez l'Object ID du Groupe de sécurité dans l'assistant. L'assistant valide que :
- L'inscription d'application de l'identifiant système dispose des autorisations Graph requises (
Group.Read.Allau minimum ;GroupMember.ReadWrite.Allpour la synchronisation). - Le Groupe de sécurité est accessible.
- L'appartenance initiale est vide ou déjà alignée avec l'espace de travail.
Cliquez sur Synchroniser maintenant. La plateforme :
- Lit l'appartenance actuelle au Groupe de sécurité.
- La compare à la liste des membres de l'espace de travail.
- Calcule le delta — ajouts et suppressions.
- Appelle l'IdP pour appliquer le delta.
- Enregistre chaque mutation dans le journal d'audit sous forme d'événements
INTEGRATION_ENTITLEMENT_*.
Ouvrez l'IdP et confirmez que l'appartenance au Groupe de sécurité correspond à l'espace de travail. Depuis l'assistant, l'onglet Membres affiche la vue IdP en direct côte à côte avec la vue de l'espace de travail.
Après cette configuration unique, la plateforme maintient le groupe synchronisé automatiquement — voir ci-dessous.
Événements de synchronisation automatique
Après la configuration, la plateforme synchronise l'appartenance à chaque événement pertinent de l'espace de travail :
| Événement | Déclenche une sync ? | Ce qui se passe |
|---|---|---|
| Ajout d'un membre à l'espace de travail | Oui | Le nouveau membre est ajouté au Groupe de sécurité IdP |
| Suppression d'un membre de l'espace de travail | Oui | Le membre retiré est supprimé du Groupe de sécurité |
| Acceptation d'une invitation à l'espace de travail | Oui | Le nouveau membre est ajouté une fois l'acceptation terminée |
| Ajout d'une équipe à l'espace de travail | Oui | Tous les membres de l'équipe sont synchronisés |
| Suppression d'une équipe de l'espace de travail | Oui | Les membres de l'équipe peuvent perdre leur appartenance au Groupe de sécurité (conservée s'ils sont aussi membres directs) |
| Configuration du cloisonnement strict (définition de l'ID de portée) | Manuel | La synchronisation initiale est « Synchroniser maintenant » dans l'assistant — automatique après cela |
Correspondance identité utilisateur–fournisseur
La plateforme doit connaître l'identité de chaque utilisateur Scrydon chez le fournisseur (ex. l'Object ID de l'utilisateur Entra ID) pour l'ajouter au groupe ou l'en retirer. La correspondance est résolue dans cet ordre :
- Recherche par e-mail — la plateforme recherche l'utilisateur dans l'IdP par son adresse e-mail principale.
- Compte OAuth lié — si l'utilisateur a connecté son propre compte OAuth pour le même fournisseur, l'ID utilisateur côté fournisseur du compte lié est utilisé.
- Ignoré avec avertissement — les utilisateurs qui ne peuvent pas être mis en correspondance sont journalisés comme avertissements ; le reste de la synchronisation continue. Les utilisateurs non correspondants ont généralement besoin qu'un administrateur réconcilie l'état de la boîte aux lettres / du répertoire chez le fournisseur.
Le nombre d'utilisateurs non correspondants apparaît dans le panneau Statut de l'assistant et sur l'entrée du journal d'audit de chaque synchronisation.
Désactiver le cloisonnement strict
Pour retirer un identifiant du cloisonnement strict, ouvrez l'assistant et cliquez sur Désactiver la gouvernance. La plateforme :
- Arrête de synchroniser le Groupe de sécurité lors des événements de l'espace de travail.
- Laisse le Groupe de sécurité intact chez le fournisseur (vous pouvez le nettoyer manuellement).
- Rétablit la portée par défaut plus large de l'identifiant système.
La désactivation est elle-même un événement d'audit — INTEGRATION_ENTITLEMENT_DISABLED.
Dépannage
« Privilèges insuffisants » lors de la synchronisation initiale
Cause la plus courante : l'inscription d'application soutenant l'identifiant système ne dispose pas de l'autorisation Graph GroupMember.ReadWrite.All avec le consentement administrateur accordé. Corrigez-le dans Entra ID sous Inscriptions d'applications → Autorisations d'API.
Les utilisateurs continuent d'être ignorés comme « non correspondants »
L'e-mail utilisé par Scrydon (l'e-mail principal de l'utilisateur) ne correspond à aucun objet utilisateur dans Entra ID. Soit corrigez l'e-mail de l'utilisateur dans Scrydon, soit demandez-lui de lier son propre compte OAuth afin que la plateforme puisse le trouver via l'ID de compte fournisseur lié.
Le Groupe de sécurité manque des membres après une synchronisation
Vérifiez le journal d'audit pour l'événement INTEGRATION_ENTITLEMENT_SYNC le plus récent. L'événement enregistre le delta calculé par la plateforme et les appels d'ajout / suppression ayant réussi ou échoué. Un addMember échoué est journalisé comme une erreur avec le corps de réponse du fournisseur.
Les modifications d'appartenance à l'espace de travail ne se propagent pas à l'IdP
Vérifiez que la synchronisation automatique est activée dans l'assistant. Si c'est le cas et que les modifications ne se propagent toujours pas, vérifiez que le jeton d'accès de l'identifiant système n'a pas expiré — les identifiants système utilisent le flux OAuth client_credentials et ont besoin d'être renouvelés comme tout autre identifiant. L'assistant affiche la date d'expiration du jeton dans le panneau Statut.
Voir aussi
- Identité et provisionnement (SCIM) — le pendant côté utilisateur du cloisonnement strict.
- Modèle de permissions — hiérarchie d'autorisation à trois niveaux.
- Journal d'audit — chaque mutation de synchronisation est auditables.
- Sécurité → Gestion des secrets — où vivent les jetons de l'identifiant système.