2 Votre organisation perd constamment des données au niveau du stockage. Pas de manière catastrophique — les sauvegardes et les réplicas évitent la plupart du temps une perte définitive — mais de manière persistante. Des utilisateurs suppriment des fichiers dont ils auront besoin plus tard. Des développeurs publient des informations sensibles dans des dépôts de code. Des jeux de données fuient à la suite de mauvaises configurations. Des erreurs d’administration suppriment des données protégées. Ces incidents font rarement les gros titres, mais leur enquête et leur remédiation consomment d’énormes ressources. Ils créent aussi une responsabilité en matière de conformité : lorsque des données personnelles fuient de vos systèmes de stockage, les régulateurs veulent savoir pourquoi vous ne l’avez pas empêché. Les stratégies de prévention des pertes de données (DLP) se concentrent traditionnellement sur les couches réseau et postes de travail : surveillance des transferts sortants, blocage des périphériques USB, analyse des pièces jointes. C’est nécessaire, mais insuffisant. Lorsque les systèmes de DLP détectent une exfiltration à la frontière du réseau, les informations sensibles ont déjà échappé à votre contrôle. Une approche plus efficace met en œuvre la DLP au niveau de la couche de stockage elle-même, là où vous pouvez appliquer les politiques directement aux données stockées et consultées. Cet article explique comment bâtir une stratégie en couches centrée sur le stockage objet d’entreprise : classification, application des politiques, chiffrement et intégration à la gestion des identités. L’avantage de la couche de stockage pour la DLP Le stockage est l’endroit où résident les données, et celui où vous disposez du plus grand contrôle. Lorsque les données atteignent le réseau pour être exfiltrées, l’occasion d’empêcher la perte est en grande partie passée. Au niveau de la couche de stockage, en revanche, vous pouvez appliquer des politiques qui empêchent la copie de données sensibles vers des emplacements non autorisés, leur partage avec des tiers externes ou leur consultation par des utilisateurs sans habilitation appropriée. La DLP passe ainsi de la détection et de la remédiation à la prévention et au contrôle. Prenons le problème classique de la DLP : un prestataire disposant d’un accès légitime à la base de données clients télécharge un fichier CSV contenant les noms, e-mails et numéros de téléphone des clients, avec l’intention de le copier sur son ordinateur portable pour une analyse hors ligne. Un système de DLP au niveau réseau peut détecter et bloquer le transfert sortant, s’il identifie le trafic comme anormal. Mais le prestataire peut faire valoir que le transfert était lié à son travail. Ou le système peut le manquer s’il est chiffré ou passe par une application métier normale. Au niveau de la couche de stockage, vous pouvez appliquer directement une politique : « les données classées “données personnelles clients” ne peuvent pas être téléchargées par des comptes de prestataires, point. » Aucune ambiguïté, aucun faux positif, aucune dépendance à la détection d’anomalies. La DLP au niveau du stockage simplifie aussi la démonstration de conformité. Les régulateurs veulent comprendre comment vous empêchez la perte de données. Un système de stockage qui applique directement les politiques fournit une preuve claire : « Nous classons toutes les données contenant des données personnelles, restreignons l’accès selon les rôles des utilisateurs et journalisons tous les accès à des fins d’audit. » Cela répond bien mieux aux attentes réglementaires que « Nous surveillons le réseau à la recherche de transferts suspects ». La classification des données comme fondement Une DLP efficace commence par la connaissance des données dont vous disposez et du niveau de protection qu’exige chaque catégorie. De nombreuses organisations pensent connaître leur paysage de données, puis découvrent lors d’évaluations de sécurité qu’elles n’ont aucun schéma de classification documenté. Vous ne pouvez pas appliquer de politiques de DLP si vous ne savez pas si les données consultées sont publiques, confidentielles, réglementées ou autres. Bâtissez un schéma de classification complet avant de mettre en œuvre des politiques de DLP. Commencez de manière large : votre organisation compte probablement au moins quatre catégories. Les données publiques comprennent les supports marketing, la documentation et les informations explicitement destinées à l’extérieur. Les données internes comprennent la plupart des informations opérationnelles non sensibles. Les données confidentielles comprennent les secrets commerciaux, les informations stratégiques et les données concurrentielles dont la fuite nuirait à l’organisation. Les données réglementées comprennent les données personnelles, les informations de santé, les données financières et les autres informations protégées par la loi. Au sein des données réglementées, créez des sous-catégories alignées sur les cadres de conformité. Si votre organisation traite des données de cartes bancaires, classez les données PCI-DSS à part. Si vous détenez des informations de santé, classez à part les données HIPAA. Si vous traitez des données personnelles européennes, classez à part les données RGPD. Cette granularité permet des politiques adaptées à chaque exigence réglementaire. Mettre en œuvre la classification à grande échelle exige plusieurs approches. Certaines données peuvent être classées manuellement par leurs propriétaires — un responsable d’équipe marque explicitement des jeux de données comme confidentiels parce qu’ils contiennent des plans stratégiques. D’autres peuvent l’être automatiquement : un système signale les fichiers contenant des motifs de numéros de carte bancaire (16 chiffres avec une somme de contrôle spécifique) comme données PCI-DSS. D’autres encore peuvent l’être par déduction contextuelle : les fichiers d’un répertoire « paie » sont probablement des données financières sensibles. La plupart des organisations combinent ces approches : classification manuelle des jeux de données critiques, analyse automatisée des motifs courants (numéros de carte, numéros de sécurité sociale, informations de santé) et déduction contextuelle pour le reste. Cette approche hybride offre une couverture raisonnable avec une charge maîtrisée. L’application des politiques au niveau de la couche de stockage Une fois les données classées, appliquez des politiques qui encadrent la manière dont elles peuvent être consultées et déplacées. Pour le stockage objet, les politiques visent généralement à limiter les opérations autorisées sur quelles données et par quels utilisateurs ou rôles. Commencez par des contrôles d’accès simples : les utilisateurs du rôle « Finance » peuvent lire les données de paie ; ceux du rôle « Ingénierie » non. Les utilisateurs du « Marketing produit » peuvent lire les informations produit publiques ; les prestataires non. Ces contrôles d’accès basés sur les rôles (RBAC) sont fondamentaux. Mais le RBAC seul ne suffit pas, car les rôles sont larges — tous leurs membres obtiennent les mêmes autorisations — alors que la sensibilité des données varie. Une meilleure approche est le contrôle d’accès basé sur les attributs (ABAC), qui évalue plusieurs facteurs : le rôle de l’utilisateur, la classification des données, l’heure, l’appareil utilisé et le fait que l’utilisateur ait suivi la formation requise. Une politique pourrait être : « Les utilisateurs ne peuvent lire des données confidentielles que pendant les heures ouvrées, depuis des appareils enregistrés auprès de l’organisation, et seulement après avoir suivi une formation à la sécurité des données au cours de l’année écoulée. » C’est plus nuancé qu’un contrôle d’accès fondé sur les seuls rôles, et bien plus applicable au niveau du stockage. Lorsqu’un utilisateur tente de lire des données confidentielles, le système de stockage vérifie : le rôle de l’utilisateur est-il autorisé ? Est-on pendant les heures ouvrées ? L’appareil est-il enregistré ? L’utilisateur a-t-il suivi la formation ? Si l’une des vérifications échoue, l’accès est refusé. Pour les opérations sensibles — copie de données vers des emplacements externes, export de jeux de données, partage avec des tiers — mettez en place des workflows d’approbation. Un utilisateur peut demander l’export de données personnelles, mais la demande est soumise à un responsable des données pour approbation. Cela évite à la fois l’exfiltration malveillante et les erreurs de négligence, lorsque quelqu’un copie des données qu’il croit anonymisées alors qu’elles ne le sont pas. Le chiffrement constitue une autre couche d’application des politiques. Des données chiffrées avec des clés contrôlées par l’organisation ne peuvent être consultées que si le système de gestion des clés de l’organisation l’autorise. Lorsqu’un utilisateur demande l’export de données chiffrées, le KMS vérifie l’autorisation avant de libérer la clé de déchiffrement. Ainsi, même si les données sont copiées hors des systèmes de stockage de l’organisation, elles restent chiffrées et inutilisables sans la clé. Un guide complet du chiffrement des données (en anglais) aide à rendre opérationnelle l’application du chiffrement sur l’ensemble de votre infrastructure de stockage. L’intégration à la gestion des identités et des accès La DLP au niveau du stockage ne fonctionne que si vous disposez d’une gestion des identités et des accès (IAM) fiable. Le système de stockage doit pouvoir être certain que, lorsqu’un utilisateur s’authentifie, vous savez qui il est et quels rôles il détient. Intégrez vos systèmes de stockage au fournisseur d’identité central de votre organisation (Active Directory, Okta, AWS IAM, etc.). Lorsqu’un utilisateur tente d’accéder à des données, le système de stockage interroge le fournisseur d’identité pour connaître son rôle et ses attributs actuels. Les politiques sont ainsi appliquées selon l’état d’autorisation actuel, et non selon des informations en cache ou périmées. Si un utilisateur quitte l’équipe Finance, son accès aux données financières est immédiatement révoqué, sans modification de la configuration du stockage. Mettre en œuvre une gestion des identités et des accès (en anglais) robuste au niveau du stockage empêche les accès non autorisés dès la base. Pour les prestataires et les partenaires externes, établissez des processus formels d’identité et d’accès. Créez des rôles de prestataires aux autorisations explicitement limitées. Les prestataires n’accèdent qu’aux jeux de données nécessaires à leur travail, avec des dates d’expiration qui imposent une réautorisation périodique. À la fin des contrats, les comptes sont désactivés et tous les accès révoqués. Cela évite que des comptes de prestataires restent actifs longtemps après la fin de leur mission, avec un accès toujours ouvert à des données sensibles. La gestion des comptes à privilèges (PAM) est essentielle pour prévenir les menaces internes. Les comptes d’administration capables de modifier les politiques ou les clés de chiffrement doivent être soumis à des contrôles plus stricts : authentification multifacteur obligatoire, accès journalisés et revus régulièrement, privilèges élevés accordés uniquement pour des fenêtres de temps précises. Pour les données les plus sensibles, envisagez d’exiger l’approbation de plusieurs administrateurs avant d’accorder un accès privilégié. Cela empêche qu’un seul compte d’administrateur compromis exfiltre les données de l’organisation. Supervision et journalisation pour l’audit et la détection Stocker les données en toute sécurité n’est qu’une partie de la DLP. Vous devez aussi détecter les violations de politiques et les accès suspects. Une journalisation complète de tous les accès au stockage en est le fondement. Journalisez chaque accès aux données sensibles : qui y a accédé, quand et ce qui a été fait (lecture, écriture, copie, export). Pour les jeux de données les plus sensibles, ces journaux peuvent générer un volume énorme — des millions d’enregistrements d’accès par jour pour les données fréquemment consultées. Ce volume est pourtant nécessaire. Vous devez auditer les accès aux données sensibles et répondre à des questions comme : « Quels utilisateurs ont consulté des données personnelles clients la semaine dernière ? » ou « Ce prestataire a-t-il accédé à des données hors de son périmètre autorisé ? » Utilisez l’agrégation et l’analyse des journaux pour détecter les anomalies. Un utilisateur qui consulte habituellement 100 fichiers par jour et qui en consulte soudain 10 000 est suspect : il collecte peut-être des données pour les exfiltrer. Un utilisateur qui accède aux données depuis un lieu géographique inhabituel peut signaler une compromission de compte. Un accès administratif à des données qui n’en reçoivent habituellement pas peut indiquer une enquête sur une violation. Des modèles de machine learning entraînés sur les profils d’accès de référence peuvent repérer des écarts significatifs et déclencher des alertes. Complétez la détection automatisée par un audit manuel périodique. Chaque trimestre, examinez les journaux d’accès aux données les plus sensibles. Vérifiez que les accès sont cohérents avec les fonctions attendues. Si un utilisateur dispose d’un accès inutile, révoquez-le. Cette revue manuelle repère des abus subtils que la détection automatisée peut manquer — des utilisateurs qui n’ont enfreint aucune politique mais accèdent à des données plus sensibles que leur rôle ne le justifie, ou des schémas suspects pris individuellement qui ne déclenchent pas d’alerte automatique. Le stockage immuable (en anglais) empêche toute altération (en anglais) de ces journaux d’audit eux-mêmes, garantissant leur intégrité lors des enquêtes. Gérer les faux positifs et les frictions opérationnelles Des politiques de DLP trop restrictives créent des frictions opérationnelles. Les utilisateurs ne peuvent pas faire leur travail parce que des accès légitimes sont bloqués. Cela génère des tickets de support, des contournements et une pression pour désactiver ou assouplir les politiques. Celles-ci deviennent alors de plus en plus permissives, jusqu’à ne plus être efficaces. Évitez ces frictions en comprenant les cas d’usage légitimes avant d’imposer des restrictions. Travaillez avec les équipes finance, juridique et opérations pour comprendre quels déplacements de données doivent normalement avoir lieu. Une clôture financière trimestrielle exige d’exporter de grandes quantités de données des systèmes comptables. L’analyse du chiffre d’affaires exige de copier des données clients vers des data warehouses. Les gels juridiques exigent d’exporter des e-mails archivés pour les besoins d’un contentieux. Des politiques qui bloquent ces opérations échoueront. Mettez en place des workflows d’approbation pour les exceptions. Au lieu de bloquer totalement l’export de données, exigez l’approbation d’un responsable des données. Cela laisse la souplesse nécessaire aux opérations légitimes tout en empêchant les abus accidentels ou intentionnels. Pour les opérations fréquentes et prévisibles (export financier mensuel), pré-approuvez-les afin qu’elles se déroulent sans approbation à chaque fois. Mettez en œuvre les politiques progressivement. Commencez par la supervision et le reporting : observez où les données sensibles sont consultées et par qui, sans rien bloquer. Utilisez ces observations pour identifier les politiques à fort impact et à faible taux de faux positifs. Mettez-les en œuvre en premier. Ajoutez progressivement des politiques plus restrictives à mesure que vous les affinez et que vous apprenez les profils d’accès légitimes. Intégration à la conformité et reporting Les politiques de DLP reposent souvent sur des fondements de conformité. PCI-DSS impose de contrôler l’accès aux données de cartes de paiement. HIPAA impose de restreindre l’accès aux dossiers patients. Le RGPD impose d’empêcher les transferts de données non autorisés. Bâtir des stratégies de DLP alignées sur les cadres de conformité garantit que vous protégez les données comme les régulateurs l’attendent. Produisez des rapports de conformité qui démontrent vos contrôles de DLP. Incluez des statistiques de classification : quelle quantité de données personnelles est stockée ? Quelle part est chiffrée ? Comment l’accès est-il contrôlé ? Combien de demandes d’accès ont été refusées ? Ces rapports montrent aux régulateurs ce qu’ils attendent lorsqu’ils demandent : « Comment empêchez-vous la perte de données ? » Vous montrez que vous avez classé les données, appliqué des politiques et supervisé les accès. Utilisez la journalisation de la DLP pour soutenir la réponse aux incidents. En cas de suspicion de violation, les journaux de DLP vous aident à comprendre qui a accédé aux données et quand. Ils fournissent des preuves pour l’enquête forensique et aident à déterminer l’étendue de la compromission. Les données qui n’ont pas été consultées pendant la période suspecte n’ont pas été exfiltrées, ce qui réduit l’ampleur de l’impact. Conclusion : la DLP comme infrastructure, et pas seulement comme politique La prévention des pertes de données est souvent traitée comme un exercice de politique : définir ce qui doit se passer, puis espérer que les utilisateurs s’y conforment. Cette approche est inefficace à grande échelle. Une véritable DLP exige d’intégrer la prévention à l’infrastructure. Un stockage objet doté de classification, de contrôles d’accès, de chiffrement et d’une journalisation complète devient un système de DLP qui empêche la perte là où résident les données, et non après une tentative de sortie de l’organisation. Commencez par classer vos données les plus sensibles et par identifier les politiques qui les protégeraient. Quels jeux de données sont les plus critiques ? Qui doit y avoir accès ? Quelles opérations doivent être restreintes ? Mettez ensuite ces politiques en œuvre dans votre infrastructure de stockage : contrôles d’accès fondés sur les rôles et les attributs des utilisateurs, chiffrement avec des clés contrôlées par l’organisation, journalisation de tous les accès et supervision des schémas suspects. La stratégie de prévention des pertes de données de votre organisation doit être centrée sur l’infrastructure de stockage, et pas seulement sur la supervision du réseau. C’est maintenant qu’il faut la mettre en œuvre, avant qu’une violation ne révèle ce que vous auriez dû empêcher et que les régulateurs ne vous demandent pourquoi vos contrôles de DLP ont échoué. Pour aller plus loin Bonnes pratiques de sécurité zero trust (en anglais) Authentification multifacteur (MFA) (en anglais) Le chiffrement AES pour la sécurité des données d’entreprise (en anglais) Qu’est-ce que le stockage immuable ? (en anglais) Stockage objet ou stockage bloc (en anglais) NIST Cybersecurity Framework (en anglais) Stockage immuable et défense contre les ransomwares (en anglais)
