Introduction
Nous avons créé Octo pour réfuter une fausse dichotomie. Après le 11 septembre, beaucoup soutenaient qu'accroître la sécurité nationale américaine impliquait d'affaiblir la vie privée. Selon cette logique, prévenir le terrorisme exigeait davantage de surveillance étatique. Nous avons choisi une autre voie : concevoir des logiciels capables d'appuyer les missions antiterroristes tout en protégeant la vie privée et les libertés civiles. En intégrant dès la conception des protections de la vie privée, nous avons voulu instaurer un nouveau paradigme pour la lutte antiterroriste aux États-Unis et d'autres workflows gouvernementaux critiques. Aujourd'hui, ces technologies permettent à nos clients publics de traiter les données de façon responsable, conformément aux lois, réglementations et politiques en vigueur.
Dans le privé, à mesure que nos logiciels ont gagné du terrain, nous avons vu émerger d'autres faux dilemmes. L'un des plus répandus : arbitrer entre sécurité et transparence des données. Les DSI l'envisagent souvent comme un jeu à somme nulle : partager plus largement stimule la productivité, mais accroît la surface d'attaque. Ce « compromis » devient encore plus aigu dans les secteurs ultraréglementés — banque, santé — où les écosystèmes de données doivent suivre des règles strictes. Résultat : on verrouille et on isole les données, on multiplie les contrôles, et l'on sacrifie une collaboration inter-équipes pourtant légitime et productive.
Fortes des leçons de nos travaux publics, nous aidons les entreprises à déployer des logiciels qui instaurent des postures modernes de protection et de gouvernance des données sur des paysages complexes. Au menu : minimisation des données, usage responsable et traçable, gestion du cycle de vie (rétention, suppression). L'ensemble renforce la confiance dans l'écosystème de données pour qu'il serve — et non bloque — le partage et la collaboration.
Malgré ces progrès, beaucoup d'organisations fixent encore la barre trop bas dans leurs RFP, en recyclant des normes dépassées. Elles passent ainsi à côté de capacités de sécurité différenciantes, conçues pour stimuler la collaboration tout en respectant leur profil de risques.
Ce billet met en lumière ces capacités et propose une manière de formuler et d'évaluer les exigences de sécurité fonctionnelles afin d'accroître, en même temps, transparence, collaboration et partage de données dans l'organisation.
Comment les RFX évaluent-ils la sécurité logicielle ?
Les RFX couvrent généralement trois familles de fonctionnalités de sécurité :
- Sécurité d'entreprise : Les équipes et les sites du fournisseur sont-ils dûment documentés et fiables ? Les chaînes d'approvisionnement sont-elles robustes ?
- Sécurité d'infrastructure : L'infrastructure sous-jacente est-elle protégée (chiffrement, tests d'intrusion, protections réseau, etc.) ?
- Sécurité opérationnelle : Quels contrôles la plateforme offre-t-elle pour faire respecter la sécurité des données auprès de tous les utilisateurs et de toutes les connexions ?
Nous concentrons ce billet sur ce troisième volet : la sécurité opérationnelle. Les dimensions « entreprise » et « infrastructure » demeurent cruciales pour choisir ses partenaires data, mais sortent du périmètre ici.
Côté sécurité opérationnelle, on retrouve souvent la même check-list d'accès, d'authentification et d'autorisation (RBAC ? LDAP ? Une interface de gestion des contrôles ?). Indispensables, ces briques manquent toutefois, à elles seules, de la souplesse et de la finesse requises pour activer les niveaux de transparence et de collaboration que les entreprises modernes attendent.
Exemple emblématique : le RBAC. La plupart des systèmes l'intègrent, mais souvent de façon lourde et rigide, en imposant des permissions au niveau de groupes entiers. Par crainte de surexposition, les propriétaires verrouillent alors l'accès aux sources clés. D'autres systèmes proposent bien des contrôles granulaires, mais sans interface lisible et maintenable. Là encore, les propriétaires optent pour la prudence : on ferme.
Voyons comment spécifier des exigences qui augmentent à la fois la sécurité et la transparence à l'échelle de l'organisation.
Exigences
À la lumière de ces principes, nous recommandons d'intégrer les exigences suivantes dans vos RFX pour repérer les meilleures solutions.
- La solution doit offrir une interface claire et intuitive pour configurer et gérer les permissions. Mettre en œuvre, administrer et modifier les politiques de sécurité est capital. Toute friction d'accès, de disponibilité ou d'usage peut peser lourd sur les utilisateurs et sur l'organisation. L'interface doit être rapide à atteindre, simple à prendre en main et démontrable en live. Depuis cette interface, les administrateurs doivent pouvoir concevoir, tester, déployer et gérer les politiques. La prévisualisation avant mise en production est essentielle.
- La solution doit proposer des permissions granulaires fondées sur la source amont, le marquage de classification, les attributs utilisateurs, les noms de colonnes et/ou des valeurs spécifiques. Les systèmes modernes exigent une granularité fine pour maximiser l'utilité auprès de profils variés. Ces contrôles s'appliquent aux utilisateurs et aux données, sous le niveau « ressource ». Les politiques doivent pouvoir se définir au niveau enregistrement, ligne ou colonne, en croisant attributs individuels ou appartenance à des groupes avec des valeurs du jeu de données.
- La solution doit prendre en charge le PBAC (purpose-based access control), en plus du RBAC et du CBAC (classification-based). Avec le PBAC, on ne demande plus un accès global sans contexte : on postule pour une finalité. Chaque finalité regroupe les données et applications utiles à un objectif donné. Un utilisateur peut demander une ou plusieurs finalités ; il n'accède qu'aux données rattachées à ces finalités, dans des espaces projet cloisonnés et sécurisés. Les actifs de données (datasets, rapports, applications) peuvent être agréés pour une ou plusieurs finalités.
- Pour activer le RBAC, la solution doit inclure un rôle « Découvreur », en plus de « Propriétaire », « Éditeur » et « Lecteur ». Le Découvreur voit le nom et les métadonnées d'une ressource, sans en voir le contenu. Cela élargit l'éventail des options d'accès et évite le faux choix entre invisibiliser totalement les actifs et surexposer des données sensibles. Si une ressource semble pertinente, l'utilisateur demande l'accès, puis vérifie son adéquation à sa finalité.
- La solution doit permettre des rôles personnalisés adaptés aux workflows, plutôt que de se limiter aux rôles par défaut (administrateur vs utilisateur). Pour réussir, chacun doit pouvoir travailler librement dans le cadre de ses droits : tout ce qu'il peut voir — ni plus ni moins. Les rôles personnalisés assurent une séparation et une délégation précises, maximisent l'accès utile et évitent d'avoir à choisir entre des politiques trop permissives ou trop restrictives. La granularité des contrôles doit offrir la flexibilité nécessaire et détecter automatiquement les conflits entre permissions.
- La solution doit prendre en charge des marquages de sécurité (marquages). Appliqués à des actifs précis, ils se propagent à tous les dérivés et transformations en aval. Ces étiquettes de catégorisation définissent des critères d'éligibilité qui restreignent visibilité et actions aux seuls utilisateurs éligibles. C'est le mécanisme clé des contrôles obligatoires, le niveau le plus strict. L'accès à une ressource suppose d'être membre de tous ses marquages. Les administrateurs gèrent ces marquages à l'échelle de l'organisation, permettant une gestion et un audit centralisés par les délégués à la protection des données. Les marquages doivent s'hériter dans la hiérarchie de fichiers comme dans les dépendances directes, et se propager dans les logiques de transformation et d'analyse. Toute ressource dérivée d'un fichier, dossier ou projet marqué hérite du marquage, sauf suppression explicite.
- La solution doit permettre aux non-techniciens d'obfusquer des données via chiffrement, déchiffrement et/ou hachage. Toutes les opérations cryptographiques doivent être auditables. De nombreux workflows reposent sur la révélation sélective : l'accès à une donnée n'est autorisé qu'avec justification (ex. : un gestionnaire d'assurance santé qui doit consulter un numéro de Sécurité sociale). Dans ces cas, les champs sensibles sont chiffrés par défaut et les utilisateurs disposant d'une finalité légitime peuvent déchiffrer, à la demande, des champs précis. Le système doit rendre ces fonctions souples, fines et traçables.
Conclusion
À mesure que les écosystèmes de données se sont étoffés, les attentes en performance, impact et échelle ont grimpé. Pourtant, beaucoup d'entreprises s'en tiennent, dans leurs RFP, à une base d'exigences dépassée. Si chaque organisation et chaque système ont leurs spécificités, il est crucial de connaître l'éventail des capacités de sécurité opérationnelle disponibles pour éviter le faux dilemme « sécurité vs transparence ». Le cas échéant, concevez vos RFP pour faire remonter les informations sur le permissionnement granulaire, le contrôle d'accès par finalité, les marquages de sécurité et les capacités d'obfuscation des données.