Autorisation

Chaque contrôle d'autorisation dans Scrydon passe par un unique point de décision de politique (PDP). Un seul modèle, évalué de la même façon qu'il s'agisse d'un utilisateur, d'un workflow ou d'une requête service-to-service.

Le schéma en quatre étapes

Chaque opération protégée suit ce schéma :

1. Construire le contexte d'autorisation — acteur, organisation, espace de travail, action demandée, type de ressource.
2. Résoudre la ressource — rechercher la ligne cible (le workflow, le document de base de connaissances, la ligne de table gérée).
3. Évaluer le registre de politiques — le registre contient des politiques typées, une par type de ressource, et dispatche vers la bonne.
4. Marquer la requête comme évaluée — sans ce marqueur, les couches en aval échouent fermement. Il n'existe pas de chemin qui retourne « autoriser » sans évaluation explicite.

Ce contrat en quatre étapes est appliqué au niveau du système de types : les routes qui ne le respectent pas échouent à l'analyse statique.

Rôle de Rego

Pour les lectures sur le plan de données (lignes de tables gérées, objets d'ontologie projetés), le point de décision de politique est Open Policy Agent. Chaque tenant dispose d'un bundle Rego compilé encodant :

• Classifications des données — quelles colonnes sont confidentielles / restreintes / publiques.
• Stratégies de masquage — quels rôles voient quelles colonnes, masquées, hachées ou refusées.
• Filtres de lignes — prédicats restreignant les lignes qu'un rôle donné peut voir.

Lorsqu'un workflow lit une table gérée, la requête est évaluée par OPA en fonction de l'identité de l'appelant. Les lignes qui échouent au filtre sont exclues ; les colonnes qui échouent à la stratégie de masquage sont expurgées avant que la valeur ne quitte le service du plan de données.

Frontière multi-tenant

L'autorisation est toujours limitée à une organisation. Il n'existe aucun moyen pour un workflow d'une organisation de lire ou d'écrire des données dans une autre organisation, quel que soit le rôle de l'utilisateur. Cette frontière est appliquée à trois niveaux :

• Base de données — chaque table contenant des données de tenant possède une colonne organizationId et une contrainte de clé étrangère vers la table des organisations. Les jointures inter-organisations ne sont pas possibles.
• Application — chaque route API construit le contexte d'autorisation à partir de l'organizationId de la session. Il n'existe pas d'appel « changer d'organisation » qui modifie l'org active sans réauthentification.
• Plan de données — les politiques Rego sont compilées par organisation. Un bundle compilé pour l'org A ne peut pas évaluer une requête pour l'org B.

Grants d'exécution

Les exécutions de workflows ne transmettent pas l'identité de l'utilisateur dans la charge utile. À la place, la route API qui déclenche le workflow évalue la permission de l'utilisateur, puis émet un grant d'exécution à courte durée de vie stocké côté serveur. Le runtime de workflow ne reçoit qu'une référence de grant et les données métier en entrée.

Cela prévient deux classes d'attaque :

• Une charge utile de workflow copiée ne peut pas être rejouée contre une autre instance de workflow avec la même autorité.
• Une activité d'outil ne peut pas s'étendre au-delà de la portée tenant du workflow parent, car le grant est lié à une seule instance de workflow.

L'accès aux secrets est délégué comme un sous-grant séparé à courte durée de vie. L'autorité d'un workflow n'accorde pas implicitement de lectures de secrets ; chaque lecture de secret nécessite son propre grant.

La création, la liaison, le rejet, l'expiration et la révocation des grants sont tous enregistrés dans le journal d'audit.

Ressources associées

• Modèle de permissions — la hiérarchie à trois niveaux qui alimente le point de décision de politique.
• Journal d'audit — chaque évaluation d'autorisation est auditable.
• Architecture → Pile analytique — où les politiques Rego du plan de données sont appliquées.
• SPIFFE / mTLS — authentification service-to-service qui sous-tend les appelants de services.