Autorisation
La frontière unique de décision d'autorisation en processus de Scrydon — multi-tenant, fermée en cas d'échec et auditable.
Chaque opération protégée de Scrydon traverse une seule frontière de décision d'autorisation, dans le service propriétaire de la ressource. Le même modèle s'applique aux utilisateurs, workflows, clients API et appels service-to-service.
Application d'une décision
Chaque opération protégée :
- authentifie l'appelant ;
- résout la ressource dans son organisation ;
- évalue une politique typée pour l'action demandée ;
- consomme une preuve de décision avant de lire, modifier ou renvoyer des données protégées.
L'authentification établit l'identité. Les rôles, portées OAuth, capacités de service, appartenances aux espaces de travail, statut de réviseur et politiques de ressource sont évalués comme des faits d'autorisation.
L'évaluation renvoie l'un des trois résultats suivants :
- Autorisé — l'opération reçoit une preuve à usage unique, liée à l'appelant, à l'action et à la ressource.
- Refusé — la politique a été évaluée correctement et rejette l'opération.
- Indéterminé — la politique n'a pas pu produire une réponse fiable, par exemple parce qu'un évaluateur a échoué ou renvoyé des données invalides. Scrydon refuse l'opération et ne bascule pas vers un second évaluateur.
Décisions sur les ressources, lignes et champs
La frontière prend en charge :
- les décisions sur une ressource précise, comme la modification d'un workflow ;
- les filtres de lignes gouvernés pour les lectures de tables gérées et d'ontologies ;
- les plans de projection gouvernés qui autorisent, masquent, cachent ou refusent les champs demandés.
Les moteurs placés derrière la frontière peuvent inclure Rego, les ACL de stockage et des modèles de permissions propres aux applications. Ce sont des détails d'implémentation : un appelant ne peut pas contourner la frontière en choisissant un autre moteur.
Frontière multi-tenant
Chaque cible porte son organisation et, le cas échéant, son espace de travail. La preuve d'autorisation est liée à cette cible exacte et ne peut pas être réutilisée pour un autre tenant ou une autre ressource.
La résolution applicative des cibles, les colonnes et contraintes de propriété en base de données, ainsi que les entrées de politique propres à l'organisation, renforcent cette frontière.
Grants de workflow
Les exécutions de workflows utilisent des grants de courte durée, stockés côté serveur, au lieu de faire confiance à une autorité transmise dans le payload. Un grant est lié à l'exécution et au tenant concernés. L'accès aux secrets reste délégué séparément et ne découle pas implicitement de l'autorité du workflow.
La création, la liaison, le rejet, l'expiration et la révocation des grants sont enregistrés dans le journal d'audit.
Preuves d'audit
Chaque résultat autorisé, refusé ou indéterminé déclenche une tentative durable d'enregistrement de preuve. Celle-ci contient l'identité de la décision, la provenance sûre de la politique, le type de ressource, le résultat et les corrélations, sans stocker les entrées brutes de politique, les prédicats de lignes, les secrets ni les données renvoyées.
Les preuves passent par le journal d'événements unifié, sa chaîne d'intégrité par organisation et la livraison SIEM configurée. Une dégradation de livraison est surveillée et récupérable sans modifier le résultat initial de la politique.