RBAC à 3 niveaux avec séparation des fonctions
Celui qui opère la donnée n'est pas celui qui la gouverne. Par conception.
Cadre / norme: ISO/IEC 38505-1 (Autorité) · SoD (SOX/DORA) · ISO/IEC TR 38505-2 §6
Le DBA qui opère une table ne devrait pas pouvoir approuver le terme métier qui la décrit. Linedat sépare qui opère de qui gouverne, avec un modèle d'autorisation à trois niveaux et une unique source de vérité pour les permissions.
Trois niveaux, un enum
L'autorisation combine le rôle d'organisation, le rôle de domaine et la propriété de ressource, le tout via un unique enum de permissions. Pas de vérifications de rôle dispersées dans les composants ni de conditions dupliquées : chaque décision d'autorisation passe par le même endroit.
Custodien technique sans autorité de gouvernance
Le rôle de custodien (opération technique) est délibérément en dessous du steward et n'hérite pas des actions de gouvernance (approuver des termes, affecter des owners). C'est une vraie séparation des fonctions, alignée avec celle qu'exigent SOX et DORA.
Les limites (ce que nous n'affirmons pas)
La permission au niveau de l'organisation est le contrôle porteur ; les groupes de domaine restreignent à l'intérieur de cette permission, ils n'accordent pas au-delà d'elle. Un changement de rôle met jusqu'à la durée de vie du cache d'auth (~30 s) à se propager entre processus s'il n'est pas invalidé explicitement.
Comment Linedat vous aide
Linedat vous fournit un RBAC enterprise granulaire sans complexité, avec une vraie séparation des fonctions — celui qui opère la donnée n'est pas celui qui la gouverne.
Capacités liées
Accès avec finalité typée et date d'expiration. Pas « parce qu'on l'a dit ».
Délégation d'autorité consentie et temporaireL'autorité ne s'impose pas : elle se délègue, le délégué l'accepte, et elle expire seule.
Le catalogue dans votre IDE : serveur MCP natifVotre IDE interroge le catalogue sans quitter l'éditeur — et sans contourner une permission.