Presque toutes les organisations cloud-native arrivent à une évaluation de couche de preuve avec la même phrase d'ouverture : on logge déjà tout dans CloudTrail, ou Stackdriver, ou Azure Monitor — qu'est-ce que Certyo nous apporte que ceux-là n'apportent pas ? C'est une question juste et elle mérite une réponse structurelle plutôt que marketing. La réponse honnête est que les logs opérationnels et la preuve d'intégrité sont des catégories différentes d'artefact, conçues pour des travaux différents, avec des propriétés de confiance structurellement incompatibles. Les mêmes données peuvent être dans les deux, mais les mêmes données ne vous donnent pas la même défendabilité.
Pour quoi les logs opérationnels sont conçus
CloudTrail, Stackdriver et Azure Monitor ont été construits pour répondre à des questions comme : quel appel API notre service a-t-il fait à 03:14 UTC, quelle a été la réponse, quel principal IAM l'a initié. Le travail est la visibilité opérationnelle — debugging, alerting, planification de capacité, investigation de sécurité. Ce sont d'excellents outils pour ces travaux.
Les contraintes de conception qui les rendent excellents pour les opérations les rendent aussi inappropriés pour les preuves. Les logs opérationnels sont conçus pour être conservés sur une fenêtre, faits tourner, rejoués, indexés, interrogés et occasionnellement rédigés. Aucune de ces opérations n'est un problème pour le travail opérationnel. Toutes sont des problèmes pour le travail de preuve.
Trois différences structurelles qui comptent au moment de l'audit
Quand un auditeur, régulateur ou avocat adverse conteste un enregistrement, la conversation passe de la visibilité opérationnelle à la défendabilité forensique. À ce point trois différences structurelles entre logs opérationnels et preuve d'intégrité deviennent décisives :
- Même domaine de confiance — vos logs CloudTrail sont écrits, conservés et lus par des comptes à l'intérieur de votre organisation AWS. Le journal d'audit du journal d'audit vit au même endroit. Un insider déterminé avec des privilèges suffisants peut muter le trail et muter le trail des mutations. La preuve nécessite une frontière de confiance en dehors du système qui a produit les données.
- Mutation-friendly par politique — les fenêtres de rétention des logs expirent les enregistrements par conception. Les politiques de cycle de vie déplacent les enregistrements vers du stockage froid et finissent par les supprimer. Ce sont des fonctionnalités pour les opérations et des bugs pour les preuves. Un enregistrement que vous ne pouvez pas produire à la demande au moment de l'audit n'est pas une preuve ; c'est un ancien log.
- Pas de chemin de vérification par tiers — quand vous donnez un export CloudTrail à un auditeur, l'auditeur doit faire confiance au fait que l'export est fidèle à l'original. Il n'y a pas de primitive cryptographique qui permet à un régulateur de vérifier l'export contre une référence immuable sans votre coopération. Les logs opérationnels sont des affirmations ; la preuve est une revendication vérifiable indépendamment.
Ce qui change quand l'intégrité est ancrée à l'extérieur
L'ancrage externe — ce que Certyo fait sur Polygon — n'est pas un remplacement de CloudTrail. C'est un artefact différent qui adresse les trois lacunes structurelles ci-dessus. Les enregistrements sont hashés, accumulés, mis en lots, et la racine Merkle de chaque lot est écrite sur une chaîne publique. Trois propriétés découlent de cette conception :
Premièrement, la frontière de confiance se déplace en dehors de votre compte : la racine Merkle on-chain ne peut être modifiée par personne, y compris l'équipe qui opère Certyo. Deuxièmement, l'ancrage n'est pas soumis à une politique de rétention : il persiste indéfiniment comme propriété de la chaîne, pas comme propriété de votre abonnement. Troisièmement, la vérification ne nécessite pas votre participation : un régulateur avec l'enregistrement original et la référence on-chain peut confirmer indépendamment que l'enregistrement a été ancré au timestamp original.
Où les deux artefacts se complètent
Le bon modèle mental n'est pas CloudTrail-ou-Certyo. C'est CloudTrail-et-Certyo, chaque artefact faisant son propre travail. Le pipeline opérationnel continue de faire ce qu'il fait bien ; le pipeline de preuves court à côté, ancrant les enregistrements qui doivent survivre à l'audit, au litige ou au procès :
Au moment de l'audit, CloudTrail répond à "ce qui s'est passé opérationnellement" et l'ancrage d'intégrité répond à "et les enregistrements résultant de ces opérations sont inchangés". Les deux artefacts répondent à des questions différentes et les réponses se composent. Un auditeur qui ne voit que CloudTrail a une histoire ; un auditeur qui voit CloudTrail plus un enregistrement ancré a une histoire plus une revendication vérifiable.
Trois scénarios d'acheteur où la distinction est décisive
Si la différence entre logs opérationnels et preuves semble académique, elle tend à devenir urgente dans trois scénarios spécifiques. Ce sont les scénarios où la position "CloudTrail suffit" échoue sur le terrain :
- Enquêtes sur menaces internes — Quand un régulateur ou assureur enquête sur une possible manipulation par un insider, les logs qui vivent dans le même domaine de confiance que l'acteur suspect ne peuvent être utilisés pour réfuter la manipulation. L'enquêteur a besoin d'un artefact que l'acteur ne pouvait démontrablement pas modifier. CloudTrail ne franchit pas cette barre ; un ancrage externe le fait.
- Litiges pluriannuels — Quand un litige sur un enregistrement d'il y a trois ans surgit aujourd'hui, la question est de savoir si l'enregistrement peut être produit dans sa forme originale. La rétention CloudTrail peut avoir expiré l'entrée. L'ancrage d'intégrité sur une chaîne publique n'a pas de fenêtre de rétention. Les enregistrements que vous pouvez hasher aujourd'hui contre l'ancrage original sont toujours vérifiables.
- Audits inter-fournisseurs — Quand un auditeur doit vérifier un enregistrement produit par votre service contre des enregistrements d'un partenaire ou d'une contrepartie, l'auditeur ne peut demander aux deux organisations de partager leur CloudTrail. Il peut leur demander de partager le hash ancré et de vérifier contre la même référence on-chain. L'audit inter-fournisseurs est structurellement plus facile quand la primitive de vérification est indépendante de tout fournisseur.
Que faire quand l'objection surgit dans une vente
La bonne réponse à "on utilise déjà CloudTrail" n'est pas d'argumenter que CloudTrail est mauvais. Il est excellent à ce qu'il fait. La bonne réponse est de demander laquelle des trois lacunes structurelles l'acheteur accepterait dans le pire des cas : un insider déterminé mutant le journal d'audit, une politique de rétention expirant un enregistrement contesté, un auditeur incapable de vérifier sans votre coopération. Si la réponse est aucune, CloudTrail seul n'est pas le bon outil pour cette partie du workload. Pour comment Certyo tourne aux côtés de l'infrastructure de logs existante, voir /fr/about. Pour la primitive de vérification en détail, voir /fr/blog/blockchain-without-crypto.
CloudTrail vous dit ce qui s'est passé. Un ancrage d'intégrité permet à un tiers de vérifier que l'enregistrement de ce qui s'est passé n'a pas changé. Mêmes données, propriété de confiance structurellement différente. Les deux artefacts répondent à des questions différentes et vous avez besoin des deux au moment de l'audit.