La gouvernance des données financières échoue précisément à l’intersection des canaux

La plupart des institutions financières ne disposent pas d’une seule politique de gouvernance des données. Elles en ont plusieurs : une pour la messagerie électronique, une autre pour le partage de fichiers, une différente pour la messagerie de paiement, et souvent aucune politique cohérente pour le canal le plus récent, les agents IA qui résument les portefeuilles clients. Chaque politique a été élaborée par une équipe différente, à une période différente, en réponse à des exigences distinctes. Individuellement, chaque politique peut sembler raisonnable. Ensemble, elles laissent des failles que personne n’a voulues et que peu de personnes peuvent repérer.

Ces failles ne restent pas longtemps théoriques. Un dossier client classé comme sensible dans un dossier protégé peut circuler librement en pièce jointe d’un e-mail dès qu’il est transféré, car la politique du dossier ne suit pas le fichier hors de son environnement d’origine. Un jeu de données confidentiel, bloqué pour le partage externe dans un système, peut sortir via une intégration API que personne n’a pensé à couvrir. Cet article explique pourquoi la gestion séparée de chaque canal garantit l’existence de ces failles pour les institutions financières, et ce qu’il faut réellement mettre en place pour les combler.

Résumé Exécutif

La gouvernance des données dans les institutions financières, construite canal par canal, aboutit inévitablement à une protection incohérente, car chaque outil a été conçu et configuré indépendamment, souvent par des équipes différentes pour résoudre des problèmes immédiats distincts. Le résultat n’est pas une série de risques acceptables pris séparément. Il s’agit d’un risque global équivalent au canal le plus faible, puisque les données clients circulent régulièrement entre eux et qu’une politique qui s’arrête à la frontière d’un canal ne protège plus rien une fois cette frontière franchie. Pour les responsables sécurité et conformité, cela signifie qu’auditer chaque canal séparément ne permet pas de détecter ce risque. Il faut auditer ce qui arrive à une donnée client précise lorsqu’elle passe d’un canal à l’autre.

Résumé des points clés

1. Une gouvernance fragmentée signifie qu’un même fichier client peut être protégé sur un canal et exposé sur un autre. Une règle de classification ou d’accès appliquée dans un système ne suit que rarement la donnée lorsqu’elle circule ailleurs.
2. Les pièces jointes sont l’endroit le plus fréquent où une politique cesse discrètement de s’appliquer. Un fichier soigneusement gouverné dans un dossier protégé peut être joint à un e-mail et envoyé sans que les restrictions du dossier ne soient conservées.
3. Chaque canal supplémentaire est un point où une faille peut se cacher. Messagerie électronique, partage de fichiers, messagerie de paiement, API et désormais agents IA : tous doivent être couverts, et une faille sur l’un d’eux suffit.
4. La classification doit être une propriété de la donnée, et non du système dans lequel elle se trouve. Une balise ou une étiquette de sensibilité ne protège les données clients de façon cohérente que si elle les accompagne lors de leurs déplacements entre canaux.
5. Un moteur de politique unique couvrant tous les canaux comble la faille que les outils par canal ne peuvent pas traiter. L’application des règles doit être évaluée de la même manière, selon les mêmes règles, quel que soit le canal par lequel la donnée circule.

Pourquoi la gouvernance par canal était la norme, et pourquoi elle ne fonctionne pas pour les institutions financières

La plupart des institutions ont abouti à une gouvernance fragmentée suite à une série de décisions individuelles et logiques, plutôt qu’à une seule mauvaise décision. Une plateforme de partage de fichiers a été choisie, puis sécurisée. Un système de messagerie a été choisi, puis sécurisé séparément.

Chaque outil gère son canal, pas le parcours complet de la donnée

Les contrôles d’accès d’une plateforme de partage de fichiers déterminent qui peut ouvrir, télécharger ou partager un fichier dans cette plateforme. Ils n’ont aucune visibilité ni autorité sur ce qui se passe une fois que le fichier part en pièce jointe d’un e-mail, est copié dans un autre système ou transite via une API de paiement. Chaque outil a été conçu pour bien gérer son propre canal. Aucun n’a été conçu pour suivre la donnée une fois qu’elle le quitte.

Les politiques sont rarement harmonisées entre canaux après coup

Une fois que chaque canal dispose de son propre outil de gouvernance et de ses propres administrateurs, harmoniser les politiques entre eux devient un projet sans propriétaire. Il faudrait comparer des ensembles de règles rédigés dans des langages différents, appliqués par des systèmes différents, couvrant des catégories de données clients qui se recoupent sans être identiques. En pratique, cette harmonisation n’a quasiment jamais lieu de façon globale.

Où la faille se manifeste concrètement pour les institutions financières

Le risque théorique d’une gouvernance fragmentée devient concret à des points précis et prévisibles, lorsque les données clients franchissent la frontière d’un canal.

Le problème des pièces jointes

Un fichier stocké dans un dossier soigneusement gouverné et à accès restreint n’est, du point de vue de la plupart des systèmes de messagerie, qu’un fichier que l’utilisateur choisit de joindre. Les règles d’accès et les restrictions de partage du dossier ne suivent pas le fichier dans l’e-mail. Une fois joint et envoyé, le fichier est alors régi uniquement par la politique, généralement bien plus légère, du canal e-mail.

Le problème des intégrations et des API

Les institutions financières interconnectent en permanence leurs systèmes via des API, des plateformes d’automatisation et, de plus en plus, des agents IA qui lisent et agissent sur les données de portefeuille pour le compte du client. Chaque intégration constitue un canal potentiel pour le transfert de données sensibles, régi par sa propre configuration d’accès, souvent minimale, plutôt que par la politique de données de l’institution.

Pourquoi la classification doit accompagner la donnée

Pour combler ces failles, il faut changer de point de départ : au lieu de demander à chaque canal d’appliquer sa propre version d’une politique, il faut évaluer la politique de la même façon, quel que soit le canal où se trouve la donnée.

Balises et classification comme propriétés portables

Lorsqu’un fichier ou une donnée client est marqué comme sensible dès son entrée dans un système, cette classification doit l’accompagner dans tous les environnements où il circule. Un fichier marqué comme confidentiel dans un dossier doit rester identifiable comme confidentiel lorsqu’un utilisateur tente de l’attacher à un e-mail sortant.

L’application des règles doit couvrir le passage de relais, pas seulement chaque côté

Le moment le plus risqué pour une donnée client est le passage d’un canal à un autre, et non sa présence dans l’un ou l’autre. Une gouvernance qui applique bien les règles dans une plateforme de partage de fichiers et dans un système de messagerie, mais ne prévoit rien pour l’action précise de joindre un fichier de l’un à l’autre, n’a pas réellement comblé la faille.

Auditer la fragmentation plutôt qu’auditer canal par canal

Le changement à opérer pour la fonction sécurité ou conformité d’une institution financière consiste à ne plus se demander séparément « notre plateforme de partage de fichiers est-elle sécurisée » et « notre système de messagerie est-il sécurisé », mais à s’interroger sur ce qui arrive à un fichier client sensible précis lorsqu’il passe de l’un à l’autre, puis au suivant.

Comment un Data Control Plane comble la faille entre les canaux

Combler la fragmentation ne signifie pas remplacer tous les outils spécifiques à chaque canal sur lesquels une institution s’appuie déjà. Il s’agit d’ajouter une couche de gouvernance transversale, qui surplombe l’ensemble, et applique la même politique à la même donnée, quel que soit le canal par lequel elle circule.

Le Data Control Plane de Kiteworks applique un ensemble unique de règles de zéro trust tenant compte des données, sur tous les canaux par lesquels transitent les données sensibles : messagerie électronique, partage de fichiers, API et agents IA. La classification appliquée automatiquement à l’entrée dans le système accompagne la donnée, de sorte que la même restriction qui s’applique à un fichier dans un dossier protégé s’applique à nouveau dès qu’un utilisateur tente de joindre ce fichier à un e-mail ou de le transférer via une intégration. Chaque décision d’application, sur chaque canal, est enregistrée dans un journal d’audit infalsifiable et non limité qui alimente directement les outils SIEM.

Les institutions qui souhaitent localiser précisément leurs propres failles entre canaux peuvent réserver une démo personnalisée pour comparer l’application d’une politique unique sur tous les canaux à leur approche actuelle, canal par canal.