Protection des données dans les processus

Les trois classes

La classification porte sur la donnée elle-même, et non sur le node qui la manipule. Un même node peut donc recevoir simultanément un champ normal et un champ secret sans que tout son contexte devienne indistinctement secret.

D’où vient la classification

Une classification peut être portée directement par le contrat d'un champ ou être héritée depuis la donnée dont ce champ dérive.

• Déclaration explicite. Un input, output ou champ de formulaire peut déclarer une classe de protection.

• Type sémantique. Certains types portent une protection native. Par exemple, common.password est toujours traité comme secret.

• Héritage. Une donnée dérivée sans classification explicite conserve la classe de la source dont elle provient.

L'absence de déclaration sur une donnée dérivée ne signifie donc pas automatiquement normal. Elle signifie « conserver la protection de la donnée source ».

Pour un champ de formulaire personnalisé, la classification fait partie de la définition du champ. Par exemple :

{
"key": "temporary_password",
"label": "Mot de passe temporaire",
"value_type": { "type": "string", "subtype": "common.password" },
"control": "password",
"security": { "class": "secret" }
}

Comment elle se propage

Les bindings et expressions font circuler les valeurs entre les différentes étapes. La classe de protection circule avec la valeur.

Binding direct

input.password [secret]
      ↓ binding
param.password [secret]

Le paramètre reçoit la même classe que le chemin source. Cette règle fonctionne aussi pour une sortie de node ou une variable de processus.

Template ou expression

Une valeur composée hérite de la classe la plus protectrice parmi les données protégées dont elle dépend réellement.

"Continuer : {{ nodes.link.url }}"
                   ↑ secret

résultat du template → secret

Granularité par champ

La protection peut s'appliquer à un champ précis sans rendre tout l'objet équivalent. Par exemple :

company.legal_name          → normal
company.bank_account.iban   → sensitive

Cette granularité est également conservée dans les collections lorsque le contrat permet d'identifier les champs concernés.

Sortie sans classe explicite

Lorsqu'un node produit une sortie sans lui attribuer explicitement une classe plus précise, la sortie hérite de la protection des données protégées dont elle dépend. Cela évite qu'une transformation générique fasse disparaître silencieusement la sensibilité de sa source.

Réduire une classification

Certains nodes garantissent qu'une transformation produit une donnée moins sensible que son entrée. Par exemple, un node peut transformer un identifiant bancaire complet en ses quatre derniers caractères :

iban [sensitive]
    ↓ transformation
iban_last4 [normal déclaré]

Ormuz appelle ce changement un classification downgrade. Lorsqu'un processus configure un tel chemin, l'éditeur demande un consentement explicite avant l'enregistrement. Le consentement est lié au node, au mapping concerné et au contrat de sortie ; une modification significative du câblage demande un nouveau consentement.

Le consentement ne cherche pas à prouver que la transformation métier est correcte : le designer reste responsable du choix de la transformation et du câblage. Il évite en revanche qu'une baisse de protection soit introduite silencieusement.

Une écriture vers un stockage durable déclaré normal suit la même règle. Par exemple, Set metadata considère chaque clé comme une frontière de déclassification : écrire un IBAN sensitive, ou une valeur dont le subtype impose un accès agent plus restrictif, déclenche un consentement lié à cette clé et à son mapping. Modifier la source ou le mapping invalide ce consentement. Après l'écriture consentie, la valeur stockée est bien une metadata normale ; elle ne re-propage pas automatiquement la classification de sa source.

Entrées et formulaires

La protection commence dès l'entrée de la donnée dans le processus. Les principales frontières sont :

• les inputs fournis lors du lancement d'un processus ;
• les données typées reçues depuis un événement ;
• les valeurs saisies dans un formulaire ou une action utilisateur.

Si un champ de formulaire est classifié secret, la valeur soumise conserve cette classe lorsqu'elle devient une sortie du node puis lorsqu'elle est utilisée dans les étapes suivantes. Un champ sensitive suit la même règle de continuité de classification.

Les constantes secrètes ne peuvent pas être enregistrées directement dans la définition du processus. Un secret doit provenir d'une source protégée prévue pour cet usage — par exemple une entrée protégée, une configuration d'intégration ou une donnée produite pendant l'exécution.

Agents et divulgation

Un Agent reçoit les données protégées à travers le contrat explicite de l’activité invoquée. Pour chaque input concerné, la politique de divulgation détermine si l’Agent reçoit une projection contrôlée ou la valeur brute en mode raw lorsque cette exposition est autorisée.

La même logique s’applique aux résultats des tools. Une activité peut recevoir une projection sûre par défaut et n’accéder à une représentation brute que lorsque le contrat du tool et les consentements applicables le permettent.

Pour la frontière d’autorité, voir Activités, tools et autorité. Pour le câblage dans un processus, voir Utiliser un Agent dans un processus.

Historique et visibilité

Les surfaces génériques d'observabilité n'affichent pas directement les valeurs classifiées sensitive ou secret. Elles indiquent qu'une donnée protégée est présente et sa classe, sans rendre la valeur visible par défaut.

Cette protection s'applique notamment aux :

• inputs d'une instance ;
• entrées et sorties visibles dans la chronologie d'exécution ;
• variables de processus ;
• réponses d'actions utilisateur ;
• outputs du processus.

La même règle s'applique aux APIs génériques correspondantes. Une valeur masquée dans l'historique n'est pas pour autant indisponible fonctionnellement : un node qui la reçoit explicitement peut l'utiliser pour réaliser l'opération attendue.

Voir Observabilité pour le suivi des instances et de leur chronologie.

Révélation contrôlée

Lorsqu'une donnée protégée persistante doit être consultée pour un diagnostic, Ormuz propose un reveal ciblé depuis les surfaces d’observabilité. L’utilisateur sélectionne une valeur masquée précise, fournit le motif demandé, puis consulte cette valeur dans une fenêtre temporaire dédiée. Il ne s’agit jamais d’un mode global « afficher toutes les données sensibles ».

Une révélation est :

• limitée à la valeur demandée ;
• soumise au droit spécifique requis ;
• auditée avec son auteur, son contexte et son motif ;
• présentée temporairement sans transformer l’historique masqué en vue permanente.

Certaines valeurs très éphémères ne sont jamais conservées une fois leur usage terminé. C'est notamment le comportement attendu pour un code à usage unique lorsque son utilisation ne nécessite aucune conservation. Dans ce cas, aucune révélation a posteriori n'est possible : l'historique conserve seulement les informations utiles pour comprendre que l'opération a eu lieu.

Retry, fork et subworkflows

La classification fait partie du contexte de la donnée et ne disparaît pas lorsqu'un processus change de frontière d'exécution.

• Subworkflow. Un input transmis à un sous-processus conserve sa classe même lorsque le schéma du sous-processus ne la redéclare pas explicitement. Une déclaration explicite du sous-processus reste toutefois son contrat propre.

• Retry. Une nouvelle tentative conserve les protections associées aux données d'entrée reprises depuis l'instance d'origine.

• Fork. Les données reprises au point de fork conservent leurs classes de protection ; le fork ne transforme pas une donnée protégée en donnée normale simplement parce qu'une nouvelle instance est créée.

Responsabilité du designer

Le modèle de protection limite les expositions accidentelles et rend visibles les changements explicites de classification. Il ne remplace pas le design fonctionnel du processus.

Il est parfaitement légitime de transmettre une donnée secret à un node qui doit l'utiliser : un token peut être nécessaire à un appel externe, un mot de passe temporaire à une action précise, ou un identifiant protégé à un fournisseur. Ormuz ne bloque pas cet egress intentionnel simplement parce que la donnée est secrète.

Le designer reste donc responsable du choix des destinataires et des usages métier. La plateforme, elle, garantit que la classification accompagne la donnée, que les surfaces génériques respectent cette protection et qu'une baisse explicite de classification ne passe pas inaperçue.