Architecture de sécurité distribuée
Statut documentaire : guide — voir Maturité et preuves.
Une architecture distribuée sûre combine identité, transport, autorisation, isolation des secrets, audit et gouvernance des domaines de confiance. Aucun mécanisme cryptographique isolé ne suffit à garantir la sécurité du système.
Principes
- authentifier les utilisateurs, services et pairs ;
- chiffrer les transports lorsque le contexte l'exige ;
- autoriser les opérations à la frontière des capacités publiées ;
- conserver les secrets hors des modèles et références d'objet ;
- propager un contexte d'audit sans exposer d'informations sensibles ;
- séparer les domaines de confiance et limiter la propagation inter-domaines ;
- traiter le Runtime local lui-même comme une frontière de confiance.
Identités et autorisation
L'identité d'un pair, l'identité d'un service, l'identité d'un utilisateur et l'identité d'un objet Runtime sont des notions distinctes. Une connexion réussie ou un objet joignable ne donne aucun droit implicite.
Les décisions d'autorisation doivent porter sur la capacité demandée et le contexte de l'appel, pas seulement sur l'adresse réseau.
Secrets
Clés, mots de passe, tokens et certificats doivent provenir d'une configuration protégée ou d'un gestionnaire de secrets. Ils ne doivent pas être sérialisés dans les métadonnées métier, les logs ou les références d'objet.
Communications et résilience
TLS ou un mécanisme équivalent protège le transport mais ne remplace pas l'autorisation. Les retries ne doivent jamais contourner une décision de sécurité. Les opérations distribuées doivent conserver correlation IDs, identifiants d'opération et informations d'audit nécessaires à l'investigation.
Déploiements P2P
Dans une topologie P2P, la découverte et le routage doivent respecter groupes, rôles et domaines de confiance. Un pair découvert n'est pas automatiquement un pair autorisé.
Les détails cryptographiques internes et formats privés de certificats ne constituent pas un contrat public du framework.