Zéro confiance pour les données financières

Les données financières ne ressemblent pas aux autres données. Une liste d’e-mails marketing qui fuite est un embarras ; un grand livre comptable qui fuite est une carte de chaque fournisseur, salaire, marge et relation bancaire d’une entreprise. Il révèle qui vous payez, combien vous gagnez, où se trouve votre trésorerie et quand elle bouge. Pour une fonction financière opérée par des agents IA, ces données doivent en plus être lisibles par le logiciel pour être utiles — ce qui soulève la question évidente qu’un directeur financier ou un réviseur sécurité pose en premier : qui, exactement, peut les voir.

FINMOZG répond à cette question par l’architecture plutôt que par des promesses. La plateforme est bâtie autour d’un modèle zéro confiance, d’un chiffrement par locataire, de clés gérées par le client, d’informatique confidentielle et d’un journal d’audit immuable. Cet article parcourt chaque couche et précise clairement ce qui est livré et ce qui relève d’un objectif de conception.

Zéro confiance : ne jamais faire confiance, toujours vérifier

Les systèmes plus anciens accordaient la confiance selon l’emplacement. Si une requête venait de l’intérieur du réseau d’entreprise ou d’un service derrière le pare-feu, elle était jugée sûre. Cette hypothèse s’effondre dès qu’un seul composant est compromis, car tout ce qui se trouve à l’intérieur du périmètre devient atteignable.

Le zéro confiance supprime entièrement la confiance implicite. Aucune requête n’est jugée fiable du fait de son origine. Chaque accès — d’un utilisateur, d’un agent ou d’un service interne — est authentifié, autorisé pour une portée précise, et vérifié face à la politique à chaque appel. Il n’y a pas d’intérieur privilégié. Cela compte pour un département financier autonome, car les agents agissent en continu et à travers les services ; chacune de ces actions est contrôlée, et non laissée passer sur la base de la position réseau.

Chiffrement par locataire : une frontière isolée par entreprise

Les plateformes multi-locataires partagent souvent une seule clé de chiffrement entre tous les clients et s’appuient sur le code applicatif pour cloisonner les données. C’est un point unique de défaillance : un seul bug de logique, et les frontières entre locataires se brouillent.

FINMOZG est conçu pour que chaque locataire — chaque entreprise — se trouve dans sa propre frontière de chiffrement, avec ses propres clés. Il n’y a pas de clés partagées entre locataires. Des données chiffrées pour une entreprise ne peuvent pas être déchiffrées avec le matériel de clé d’une autre, de sorte que l’isolation est imposée par la cryptographie plutôt que par la seule logique applicative. L’effet pratique est qu’un problème chez un locataire ne peut pas se propager vers un autre.

Clés gérées par le client : c’est le client qui détient les clés

Le chiffrement ne répond à « qui peut lire ceci » que si vous contrôlez aussi qui détient la clé. Le BYOK (clés gérées par le client) transfère ce contrôle au client.

• Les clés vivent dans votre KMS. La clé maîtresse provient de votre propre service de gestion de clés et y reste. La plateforme effectue des opérations cryptographiques face à elle plutôt que de la détenir.
• Vous faites tourner et révoquez. La rotation et la révocation des clés relèvent de votre décision. Révoquer une clé est un coupe-circuit définitif : les données deviennent illisibles, y compris pour l’opérateur.
• L’opérateur ne peut pas lire en clair. Parce que l’opérateur ne possède jamais votre clé maîtresse, il est conçu pour être incapable de déchiffrer seul vos données financières.

Le BYOK transforme une déclaration de confiance en un contrôle que vous pouvez démontrer. Un réviseur sécurité n’a pas à croire sur parole « nous ne regarderons pas » ; il peut vérifier que la clé ne quitte jamais sa juridiction et que la révocation fonctionne.

Informatique confidentielle : les agents travaillent sur des données que l’opérateur ne voit pas

Le chiffrement au repos et en transit est standard. Le problème plus difficile, ce sont les données en cours d’utilisation : pour classer une transaction ou préparer une déclaration, un agent doit à un moment travailler avec du texte en clair. Sur une infrastructure ordinaire, ce texte en clair est exposé à l’hôte pendant son traitement.

FINMOZG est conçu pour que les agents IA s’exécutent à l’intérieur d’environnements d’informatique confidentielle — des enclaves protégées par le matériel où les données sont déchiffrées et traitées dans une mémoire que le système d’exploitation environnant, l’hyperviseur et l’opérateur ne peuvent pas lire. L’attestation à distance permet à la charge de travail de prouver qu’elle exécute le code attendu, non modifié, dans une enclave authentique avant qu’aucune clé ne lui soit délivrée. Le but est une chaîne où les données financières en clair ne sont jamais exposées à l’infrastructure de l’opérateur, même pendant le calcul.

La chaîne de flux des données

Réunies, ces couches forment un chemin unique que parcourent les données, le contrôle étant tenu par le client au départ et la responsabilité saisie à l’arrivée :

• Appareil de l’utilisateur. Les données et les instructions proviennent d’un utilisateur ou d’un système authentifié, vérifié à chaque requête sous le régime zéro confiance.
• Clé client / KMS. Chiffrement et déchiffrement sont conditionnés par des clés que le client contrôle dans son propre KMS — la plateforme demande des opérations, elle ne possède pas la clé maîtresse.
• Coffre de données chiffrées. Les données de chaque locataire reposent à l’intérieur de sa propre frontière de chiffrement, sans clés partagées entre entreprises.
• Runtime d’informatique confidentielle. Les agents ne traitent le texte en clair qu’à l’intérieur d’enclaves attestées et protégées par le matériel, conçues pour le garder hors de portée de l’opérateur.
• Journal d’audit immuable. Chaque action qui touche les données est consignée dans un journal en ajout seul, chaîné par hachage.

Le journal d’audit immuable

L’autonomie n’est acceptable en finance que si chaque action est traçable a posteriori. FINMOZG consigne chaque action d’agent et chaque action humaine dans un journal en ajout seul, chaîné par hachage. Chaque entrée est cryptographiquement liée à la précédente, de sorte que retirer ou modifier un enregistrement passé brise la chaîne et devient détectable au lieu de rester silencieux.

Chaque entrée est conçue pour répondre aux questions qu’un auditeur pose réellement :

• Qui a effectué l’action — un utilisateur nommé ou un agent précis.
• Quand elle a eu lieu, à l’horodatage près.
• Quoi a changé — l’écriture, la déclaration ou le paiement exact.
• Quel agent était impliqué et sous quel réglage d’autonomie.
• Quelles preuves l’ont étayée — la pièce justificative et le raisonnement.
• Qui a approuvé, pour toute action ayant exigé une validation humaine.

Gouvernance d’accès au moindre privilège

Le zéro confiance sur le réseau s’accompagne du moindre privilège sur l’accès. Chaque personne voit et fait seulement ce que son rôle exige, et rien de plus. Le modèle correspond aux personnes réelles autour des comptes d’une entreprise :

• Propriétaire — contrôle administratif complet de l’entité et de ses réglages.
• Comptable — tenue de comptes au quotidien, classification et rapprochement.
• Directeur financier — analytique, approbations et décisions de trésorerie.
• Auditeur — accès cadré, orienté lecture, aux enregistrements et à la piste d’audit.
• Consultant externe — accès limité dans le temps et étroitement cadré pour une mission définie.
• Investisseur en lecture seule — visibilité sur les rapports sans possibilité de rien modifier.

Ce que cela signifie pour une revue de sécurité ou une banque

Les revues de sécurité et de partenariat se résument à une courte liste de questions, et cette architecture est bâtie pour donner des réponses concrètes à chacune :

• Le fournisseur peut-il lire nos données ? Le BYOK et l’informatique confidentielle sont conçus pour que la réponse soit non, en clair — et la révocation de clé est un contrôle que vous tenez, pas une demande que vous déposez.
• Comment les locataires sont-ils isolés ? Par un chiffrement par locataire sans clés partagées, de sorte que l’isolation ne dépend pas du fait que le code applicatif soit exempt de bugs.
• Quelqu’un peut-il réécrire l’histoire ? Le journal en ajout seul, chaîné par hachage, rend toute falsification détectable.
• Qui peut toucher à quoi ? Le moindre privilège fondé sur les rôles limite chaque acteur, interne ou externe, à une portée définie.

Pour être précis sur les affirmations : cet article décrit l’architecture et les principes de conception de la plateforme. Lorsqu’une capacité est un objectif de conception plutôt qu’un contrôle finalisé et vérifié de façon indépendante, cela est indiqué comme tel. FINMOZG ne se présente pas comme détenant une certification externe particulière, et tout statut d’audit ou d’attestation est communiqué séparément sur la page sécurité plutôt qu’affirmé ici.

Le zéro confiance n’est pas une fonctionnalité que l’on active ; c’est l’hypothèse sur laquelle tout le système est bâti — qu’aucun composant, réseau ni opérateur ne devrait être digne de confiance par défaut avec les chiffres les plus sensibles d’une entreprise. Pour savoir comment les agents eux-mêmes opèrent sous ces contrôles, voyez les agents, comment fonctionne la comptabilité par IA, et ce qu’est un département financier autonome. Si vous menez une revue fournisseur, contactez-nous pour le détail.