Une intégration réussie : RegData Protection Suite (RPS) et Thales CipherTrust
Laurent Chuat
Security Consultant
Nous sommes heureux d’annoncer une nouvelle intégration entre deux partenaires majeurs de Kyos : RegData et Thales. RegData Protection Suite (RPS) peut désormais utiliser CipherTrust Manager de Thales comme solution de gestion de clés (KMS). Nous sommes très heureux de cette nouvelle, car elle nous permet de vous proposer une solution de protection des données sécurisée, évolutive et adaptée aux besoins de chaque application.
Pour bien comprendre cette intégration, nous devons prendre un peu de recul et aborder quelques notions de base sur la protection des données.
Table des matières
Add a header to begin generating the table of contents
La protection des données : Pourquoi et où ?
De nombreuses stratégies peuvent être employées pour empêcher les attaquants de s’infiltrer dans un système. On pense notamment aux systèmes de détection d’intrusion (IDS), VPN, et pare-feux. Mais si ces mesures sont essentielles pour se défendre contre les menaces externes et contrôler l’accès à un réseau, elles ne suffisent pas à protéger les données contre les menaces internes et les attaques plus sophistiquées. Ces défenses ne parviennent souvent pas à protéger les données une fois qu’un intrus a contourné les barrières initiales. En outre, avec l’avènement du Cloud le concept de « périmètre du réseau » devient de plus en plus flou. C’est là que la protection des données devient indispensable. Les fuites de données étant à la fois coûteuses et très préjudiciables à la réputation d’une entreprise, il est essentiel d’aller au-delà de l’approche traditionnelle de la sécurité périmétrique.
La protection des données sensibles par la cryptographie apparaît donc comme un choix évident, mais il reste à savoir où appliquer exactement le chiffrement. En effet, la cryptographie peut être intégrée dans un système existant de différentes manières. Voici quelques exemples d’utilisation du chiffrement :
- au niveau du stockage, pour chiffrer l’ensemble d’un dispositif de stockage ;
- au niveau du système de fichiers, pour chiffrer de manière transparente des dossiers/fichiers individuels et protéger les données au repos ;
- au niveau de la base de données, pour chiffrer des colonnes spécifiques ;
- au niveau de l’application, pour transformer sélectivement les données sensibles dès le début, soit à partir de l’application elle-même, soit par l’intermédiaire d’un proxy dédié.
Ces différentes approches ne sont pas exclusives – elles peuvent (et doivent souvent) être utilisées conjointement. Chaque méthode a ses avantages et ses inconvénients. Mais la protection des données au niveau le plus élevé (c’est-à-dire au niveau de l’application) présente de nombreux avantages. Elle permet de protéger des éléments spécifiques plutôt que de chiffrer des bases de données ou fichiers entiers. Cette approche est particulièrement utile pour protéger les données personnelles telles que les noms ou les numéros de compte. En outre, le chiffrement au niveau de l’application peut être adapté aux besoins d’applications spécifiques, ce qui permet aux développeurs de mettre en œuvre des schémas de protection personnalisés (transformations de données) qui peuvent préserver un format spécifique, par exemple. De plus, la protection des données au niveau de l’application permet de sécuriser les données tout au long de leur cycle de vie, ce qui garantit que les informations sensibles restent protégées à la fois au repos et en transit. Enfin, il est également possible de configurer la manière dont les données sont révélées (ou non), en fonction du contexte de la demande (c’est-à-dire qui demande les données et comment).
RegData Protection Suite (RPS)
Protéger les données au niveau de l’application : c’est là que RegData intervient. Sa plateforme, RegData Protection Suite (RPS), va au-delà du simple chiffrement des données et offre une gamme de méthodes de transformation hautement configurables telles que la pseudonymisation, l’anonymisation, la tokenisation et le chiffrement.
RegData peut être adopté avec deux modèles d’intégration principaux : soit un proxy est introduit entre l’application et le client pour intercepter et transformer les données, soit les données sont transformées à partir de l’application elle-même, en appelant l’API RegData.
Un autre avantage majeur de RegData est la protection contextuelle : par exemple, il est possible de configurer si/comment les données sont révélées au client, en fonction de divers attributs. Par exemple, une donnée sensible peut être entièrement révélée à un groupe d’utilisateurs tout en restant tokenisée pour un autre groupe.
Qu'est-ce que la tokenisation ?
La tokenisation remplace les éléments de données sensibles par des équivalents non sensibles, appelés tokens, qui n’ont aucune valeur exploitable. Ce processus est idéal dans les scénarios où les données doivent être traitées ou analysées tout en restant confidentielles.
Par exemple, dans le traitement des numéros de compte bancaire tels que les IBAN, la tokenisation peut remplacer l’IBAN réel par un faux IBAN (un token). De cette manière, les données sensibles sont sécurisées, tandis que le token peut être utilisé sans risque. Ceci est particulièrement utile dans les services financiers, où la confidentialité et la sécurité sont primordiales, mais où les données sont nécessaires pour traiter les transactions et effectuer des analyses. Le processus de tokenisation peut également être configuré pour garantir que l’IBAN tokenisé ressemble à un IBAN, c’est-à-dire qu’il conserve certaines propriétés telles que le format.
CipherTrust Manager comme KMS
Pourquoi intégrer RegData à CipherTrust ? Pour répondre à cette question, nous devons parler de clés. Dans le contexte de la protection des données, une question tout aussi importante que celle de savoir où et comment le chiffrement est appliqué est celle de savoir où et comment les clés sont stockées. Une clé compromise pouvant mettre en péril la sécurité de l’ensemble du système, la protection des clés est évidemment primordiale.
Thales propose une large gamme de produits et de fonctionnalités pour la protection des données sous la marque CipherTrust. Au centre de cette offre se trouve CipherTrust Manager. L’un des principaux rôles de ce gestionnaire est d’agir en tant que solution de gestion de clés (KMS), non seulement pour les produits faisant partie de l’offre CipherTrust, mais aussi pour les solutions tierces. CipherTrust Manager peut ainsi créer, stocker, utiliser et fournir des clés à des clients à travers différents protocoles (y compris une API REST).
L’utilisation d’un KMS renforce la sécurité en stockant toutes les clés cryptographiques dans un endroit unique et sécurisé. La centralisation des clés minimise le risque d’accès non autorisé et simplifie la surveillance de ces actifs critiques. En s’appuyant sur CipherTrust Manager de Thales, RPS bénéficie de fonctions de protection et de gestion des clés qui contribuent à prévenir les violations potentielles.
De plus, la séparation des tâches est clairement définie dans cette intégration. CipherTrust gère les clés cryptographiques, tandis que RegData s’occupe des transformations de données. Cette séparation garantit qu’aucune entité n’a le contrôle total des clés et des données. En maintenant une frontière claire entre ces fonctions, les organisations peuvent renforcer l’application des politiques de sécurité et se conformer aux réglementations qui exigent des contrôles d’accès stricts et des audits.
L’intégration de RPS avec un gestionnaire de clés externe tel que CipherTrust présente donc l’avantage d’améliorer la sécurité, la conformité et la flexibilité. Elle permet aux organisations de gérer les clés dans plusieurs environnements, que ce soit dans le Cloud ou sur site, sans sacrifier le contrôle de leurs clés cryptographiques. En outre, l’utilisation d’un KMS externe telle que CipherTrust offre évolutivité et résilience, garantissant que les capacités de gestion des clés peuvent évoluer avec les besoins de l’entreprise.
Protection physique avec un HSM
Pour aller plus loin dans la protection des clés cryptographiques, il est possible d’utiliser un HSM comme base de confiance (root of trust) pour tout le système. Thales dispose de sa propre gamme de HSM compatible (sous la marque Luna), mais des HSM tiers sont également pris en charge par CipherTrust Manager.
Pourquoi utiliser un HSM ? Le problème du stockage à long terme des clés est que, si une clé est stockée sur du matériel ordinaire, il est toujours possible qu’une personne ayant un accès physique à ce matériel soit en mesure d’extraire la clé. Un HSM est un dispositif physique conçu pour résoudre ce problème.
Le HSM peut être configuré pour agir comme root of trust pour l’ensemble du système : pour protéger ses secrets, CipherTrust Manager utilise une série de clés issues d’une clé non exportable générée et protégée par le HSM. En d’autres termes, cette clé est créée par le HSM et ne peut jamais le quitter. Même pour un attaquant ayant un accès physique au HSM, il sera virtuellement impossible de récupérer la clé, car le HSM a été spécifiquement conçu non seulement pour détecter de telles tentatives, mais aussi pour les empêcher.
Détails techniques de l'intégration
Entrons maintenant dans quelques détails techniques de l’intégration. Comment RPS accède-t-il aux clés stockées et protégées par CipherTrust Manager ?
Comme RPS utilise différents types de clés (et pas seulement des clés de type AES ou RSA, par exemple), des clés dites opaques sont utilisées dans CipherTrust Manager. Opaque signifie que les clés ne sont pas considérées comme générées par un algorithme spécifique ou avec un format spécifique, mais qu’elles sont simplement stockées comme un bloc de données. Ces clés opaques sont ensuite utilisées pour chiffrer les données dans le RPS. Ces clés opaques jouent donc ici le rôle de clés de chiffrement de données (DEK).
Vient ensuite la question de savoir comment exporter les clés en toute sécurité, c’est-à-dire les transférer de CipherTrust Manager au RPS. À cette fin, l’API REST est utilisée via HTTPS. Cela implique qu’un tunnel authentifié et confidentiel est créé par TLS pour transporter les clés. Toutefois, il faut envisager la possibilité que les clés soient interceptées par l’équipement du réseau (par terminaison TLS). Il s’agit d’un scénario courant pour de nombreuses organisations. C’est pourquoi une clé AES supplémentaire est utilisée pour chiffrer chaque clé opaque. Cette clé AES fait donc office de clé de chiffrement (KEK). Comme chaque DEK possède sa propre KEK, le nombre total de clés est doublé.
Il semblerait que l’on revienne à la case départ, car la KEK doit également être exportée, mais il existe une astuce que l’on peut utiliser avec les clés AES. En effet, CipherTrust Manager fournit un endpoint API qui nous permet de chiffrer une clé AES avec une clé publique avant de l’exporter. La clé privée correspondant à la clé publique ne sera jamais révélée. De cette manière, RPS peut récupérer en toute sécurité la clé AES KEK (même si un proxy de terminaison TLS intercepte le trafic), récupérer la clé opaque (c’est-à-dire la DEK) et la déchiffrer à l’aide de la KEK.
Conclusion
Cette intégration nous donne un système complet et mature pour la protection des données applicatives. Grâce à cette solution, nous serons en mesure de relever de nombreux défis et d’offrir à nos clients des configurations de sécurité sur mesure, adaptées à chacune de leurs exigences. Comme nous l’avons vu, les avantages de cette intégration sont nombreux : flexibilité, évolutivité, sécurité, et plus encore. Nous sommes très enthousiastes face à ce développement et nous nous réjouissons d’accompagner de plus en plus de clients dans le déploiement de cette solution.
Plus d’information à ce sujet ?
Nous sommes à votre disposition !