Sécurité formelle par contexte
Quatre règles impératives, pipeline serveur, types canoniques, trace persistante
La sécurité de StrateFluxDistr n'est pas un appendice technique. Elle est un contexte d'admissibilité de l'action : un acte protocolaire (Inscribe, Resolve, Validate, Trace, Field, List) n'est admissible que si le contexte de sécurité dans lequel il se manifeste l'autorise.
Ce principe se décline dans une architecture concrète qui vit principalement côté serveur, dans un pipeline de validation et dans des types canoniques.
Quatre règles impératives
Quatre règles posent les invariants de sécurité du protocole. Elles sont matérialisées dans le code et testées.
Règle 1 — Non-confiance dans l'enveloppe client. Le serveur ne fait jamais confiance à envelope.source_endpoint simplement parce que le client l'envoie. Il vérifie que la source déclarée appartient à l'ensemble des sources autorisées pour l'acteur authentifié, sinon diagnostic SOURCE_ENDPOINT_NOT_AUTHORIZED.
Règle 2 — Le contexte effectif est serveur. L'ActorIdentity est dérivé de l'authentification serveur, jamais déclaré par le client. Le client n'envoie jamais directement un ActorIdentity ni un SecurityContextPayload.
Règle 3 — Gouvernance TracePolicy. Le serveur calcule une effective_trace_policy qui satisfait l'invariant requested ≤ effective. Le serveur peut renforcer la trace pour les Contracts sensibles ; il ne peut jamais l'affaiblir pour une action sensible.
Règle 4 — Le contexte porte la preuve, jamais le secret. SecurityEvidence n'a que des variantes en fingerprint, hash, ou identifiant de session. Aucun credential brut, aucun secret en clair n'est jamais stocké ni transmis dans le contexte de sécurité.
Pipeline serveur en 18 étapes
Le pipeline serveur matérialise la sécurité par contexte en 18 étapes regroupées en cinq blocs :
Bloc 1 — Réception et déchiffrage. Lecture de la requête gRPC, conversion proto::DistributedEnvelope vers core::DistributedEnvelope. Échec → diagnostic structurel.
Bloc 2 — Authentification et résolution de l'acteur. Lecture de l'en-tête x-actor-id en mode dev, vérification de signature en mode strict, construction de l'ActorIdentity avec son AssuranceLevel et ses SecurityEvidence.
Bloc 3 — Vérifications structurelles et contractuelles. Application de la règle 1 : la source déclarée appartient-elle à l'ensemble autorisé ? Lookup du Contract dans le store via la politique Tolerant ou Strict.
Bloc 4 — Construction du SecurityContext et décisions. Évaluation de l'AuthorizationDecision via CanEngage(actor, source, contract, sink, payloadKind, context). Évaluation de l'AdmissibilityDecision sur l'état architectural et la fenêtre temporelle. Calcul de l'effective_trace_policy.
Bloc 5 — Exécution métier et finalisation. Validation contractuelle V0.1 (champ requis, taille, type), idempotence, inscription effective, inscription de la trace persistante (Lease serveur, Flow serveur si Full), construction de l'OperationMeta.
Types canoniques de la sécurité
Sept types canoniques portent la sécurité formelle dans le module security/ du noyau :
ActorIdentity: identité authentifiée de l'acteur, avecAssuranceLeveletAuthSubject.SecurityContextPayload: contexte de sécurité effectif, avec quatre sous-contextes (Transport, Actor, Contract, Execution).AuthorizationDecision: résultat deCanEngage.AdmissibilityDecision: résultat de l'évaluation des règles d'admissibilité.LeaseSecurityBinding: liaison entre source demandée et source effective vérifiée.FlowSecurityTrace: trace de sécurité attachée au Flow.SecurityEvidence: preuve attachée au contexte (fingerprint, hash, identifiant de session).
Trace persistante effective
Quand effective_trace_policy ≥ LeaseOnly, le serveur inscrit un LeasePayload serveur protocolaire dans le store, sous l'OccurrenceId <server_instance>::server.lease::<correlation_id>. Quand Full, il inscrit en plus un FlowPayload serveur. Les OccurrenceId sont retournés au client dans OperationMeta.server_lease et server_flow, ce qui permet au client de retracer sa propre activité auditée.
Cette inscription est best-effort en V0 : si elle échoue, la requête principale n'échoue pas, mais un avertissement TRACE_INSCRIPTION_FAILED est ajouté au ValidationReport et le compteur TraceAudit est incrémenté.
Pour aller plus loin
La spécification protocolaire décrit la sémantique exacte des types portés au-dessus du wire. La page serveur de référence décrit comment ces invariants sont matérialisés et exercés par la couverture de tests.