Résidence de données (partie 4) - Comment fonctionne le cryptage ?
Dans la quatrième partie de notre série sur la résidence des données, nous nous penchons sur les différentes techniques de cryptage et examinons leurs avantages et inconvénients.
Les messages et les informations sont codés depuis l'Antiquité. Les temps modernes imposent toutefois de nouvelles exigences. Pour que la protection soit maximale, elle doit commencer le plus près possible de l'utilisateur : Le cryptage doit être convivial, fonctionner de manière transparente et garantir une sécurité de fonctionnement élevée.
En principe, les données peuvent se présenter sous deux formes différentes dans le cloud :
- sous forme de fichier (qui peut aussi être un e-mail) dans un stockage de données non structuré
Ces données peuvent être protégées en tant qu'ensemble en chiffrant le fichier dans son intégralité. - En tant que champ dans un enregistrement (par exemple une ligne ou une entrée de tableau) d'un système de gestion des données structurées.
Les champs sont beaucoup plus complexes à protéger, car l'application dans le cloud a une idée précise de la manière dont ces données doivent se présenter. Une date doit se présenter sous une certaine forme et un e-mail a également certaines caractéristiques de reconnaissance. Si le contenu du champ ne correspond pas à ces idées, une erreur de cohérence de champ peut se produire : L'application signale une erreur et refuse l'enregistrement.
Avec la numérisation croissante, les données seront de plus en plus stockées sous forme de champs plutôt que de fichiers. Les deux formes devraient donc impérativement être protégées : Les données dans des fichiers, tant que le cloud est utilisé principalement comme "Platform as a Service" (PaaS), comme chez SAP ou Microsoft Azure, et les données dans des champs, lorsque le cloud est de plus en plus utilisé comme "Software as a Service" (SaaS), comme chez Microsoft 365.
Où peut-on encoder ?
Le cryptage doit être simple et convivial - idéalement, les utilisateurs finaux n'ont rien à y faire. Ainsi, les endroits suivants entrent en ligne de compte pour le cryptage et le décryptage :
... sur le poste d'extrémité dans le navigateur
Le cryptage serait probablement mis en œuvre sous la forme d'un script Java ou d'une forme similaire. Étant donné que le navigateur devrait recevoir des clés, car la méthode serait fournie avec le Java-Script et que le lieu de l'action est le navigateur, la solution n'est sûre que dans la mesure où le navigateur peut protéger la clé et authentifier l'utilisateur. Cela serait possible dans les faits, mais n'est généralement pas fait en raison du grand risque d'erreur. En outre, elle peut être facilement désactivée via les paramètres du navigateur et l'enregistrement malveillant ne serait pas particulièrement difficile. De mon point de vue, la protection du point d'accès n'a aucun sens.
... via un composant actif proche du système d'exploitation
Un logiciel sur le point d'accès s'intégrerait d'une part dans le système de fichiers (pour les fichiers) et d'autre part dans le système de réseau (pour les champs). Le caractère invasif de cette approche ne permet guère de fonctionner de manière stable : Les systèmes Windows, Mac, Android et autres sont trop rapides, trop fréquents et trop différents les uns des autres.
... directement dans une application
L'application sur le terminal peut gérer le cryptage. C'est ce que fait par exemple Microsoft avec sa gestion des droits pour les fichiers. Cette approche ne fonctionne toutefois pas pour les champs via une application web. Elle est donc possible en premier lieu avec les fichiers.
... dans un composant de réseau en ligne quelque part entre l'utilisateur et le fournisseur d'accès
La communication entre l'utilisateur et le fournisseur d'accès est interceptée entre les deux et c'est là qu'elle est cryptée et décryptée. En règle générale, l'utilisateur ne remarque rien et le processus est rapide. Toutefois, un "entre-deux" doit être possible. Si cela fonctionne généralement bien pour les champs, c'est un peu plus compliqué pour les fichiers. Cela est lié à la manière dont les données des dépôts de fichiers dans le cloud sont synchronisées entre le local et le cloud. En règle générale, le fichier n'est pas déplacé dans son ensemble à chaque modification, mais seules les parties modifiées sont copiées. L'appliance de cryptage peut toutefois difficilement crypter l'ensemble du fichier de manière cohérente si elle n'en reçoit que certaines parties. En revanche, cela fonctionne généralement très bien pour les champs.
... dans un composant actif qui parle au fournisseur d'accès
Les données arrivent chez le fournisseur non cryptées (à l'exception du cryptage de transport). Si le fournisseur met cette information à disposition via l'API, un composant actif tel qu'un Cloud Access Security Broker (CASB) peut obtenir les données non cryptées via l'API et renvoyer les données cryptées via l'API. Le problème est que le fournisseur a vu les données non cryptées et les a généralement stockées au moins temporairement. Tout dépend maintenant de l'implémentation, à savoir si les données non cryptées sont rapidement effacées ou non. Là encore, c'est une question de confiance, sans garantie que cela ne puisse pas être modifié à l'avenir.
... chez le fournisseur d'accès avant l'application
Le fournisseur d'accès propose un cryptage directement devant son interface utilisateur. Cela est encore rarement fait. Pour cette solution, tout dépend de l'origine de la clé, de la qualité du cryptage et de la garantie que les données ne survivent pas quelque part en l'état.
...chez le fournisseur d'accès dans l'application
L'application est construite dès le départ de manière à ce que les données soient cryptées après la couche logique, avant d'être stockées. Les grands fournisseurs comme Salesforce ou ServiceNow peuvent le faire, les plus petits ne le peuvent généralement pas. Une installation ultérieure est complexe, très coûteuse et la migration des données est une tâche plutôt difficile. En outre, cette solution dépend également de l'origine de la clé et de la qualité du mécanisme. Le contrôle pour savoir si cela est fait correctement incombe exclusivement au fournisseur. Une copie fantôme non cryptée pourrait être réalisée sans problème.
... chez le fournisseur d'accès at Rest
Le fournisseur crypte les données lors de leur stockage dans la base de données ou sous forme de fichier sur son conteneur de fichiers. Cette solution doit également être analysée plus en détail en ce qui concerne l'origine de la clé, le mécanisme utilisé et le lieu de l'événement (emplacement de la base de données/du serveur de fichiers). Le contrôle incombe exclusivement au fournisseur d'accès.
L'option "sécurité maximale" garantit "Composant de réseau en ligne quelque part entre l'utilisateur et le fournisseur d'accès"car le fournisseur d'accès ne voit pas le contenu non crypté. Mais cette solution a aussi ses limites : Le fournisseur ne peut plus "calculer" avec les données cryptées et ne peut généralement pas non plus exécuter d'autres fonctionnalités plus complexes. Cette approche permet donc plutôt d'anonymiser les données dans le nuage. Dans la plupart des cas, cette solution est suffisante.
Ce qui compte, c'est l'endroit où les données sont cryptées, le mécanisme utilisé et la personne qui détient la clé..
Qui contrôle mon cryptage ?
Trois éléments importants sont impliqués dans un cryptage :
- La clé ne doit pas tomber entre les mains de tiers. Des clés de mauvaise qualité génèrent un cryptage faible, et si une clé tombe entre les mains d'un tiers, celui-ci peut décrypter les données et éventuellement les modifier de manière malveillante ou en falsifier de nouvelles.
- Le mécanisme de cryptage doit être bon. Il existe une littérature abondante sur les différents mécanismes, leurs forces, leurs faiblesses et leurs utilisations idéales. Mais un mécanisme modifié peut être utilisé contre vous : la clé est bonne, mais le mécanisme est faible et ne produit pas un bon cryptage. Il est donc important que le mécanisme utilisé soit bon et que le code utilisé soit digne de confiance.
- L'endroit où le cryptage a lieu est bien sûr également important. Si celui-ci n'a pas lieu localement, personne n'empêche le remplacement de la clé ou du mécanisme par une version plus faible.
Ce n'est que si les trois éléments peuvent être contrôlés que le cryptage est sous contrôle. Si un élément tombe entre les mains d'un tiers, votre cryptage peut être exploité par ce tiers, ses employés, ses fournisseurs, des États étrangers ou des cybercriminels. Il y a donc très peu de marge de manœuvre à cet égard.
BYOK signifie "bring your own key" ou, en français, "apporte ta propre clé" ou "donne-moi ta clé". La clé est généralement remise au fournisseur d'accès, qui utilise ensuite un mécanisme qu'il contrôle à l'endroit de son choix. Ce mécanisme est souvent proclamé comme une "solution sûre". En réalité, il ne fait qu'augmenter les dépenses du client (qui doit désormais gérer les clés) sans augmenter significativement la protection. Un emballage trompeur du département marketing du fournisseur d'accès.
Il vaut mieux opter pour un BYOE "bring your own encryption". Dans ce cas, la clé, le mécanisme et le lieu sont contrôlés par le client et sont donc beaucoup plus fiables. Cette option a également le potentiel de résoudre les aspects de résidence de votre besoin de protection. La plupart des autres approches ne peuvent pas le faire.
Qui contrôle mon cryptage ?
- Une protection optimale est offerte par un cryptage BYOE, c'est-à-dire un cryptage local. Les fournisseurs d'accès ne reçoivent que des informations cryptées. Il existe peu d'alternatives pour le multi-cloud. En ce qui concerne la problématique de la résidence, cette approche est également en mesure d'utiliser des clés dédiées par pays. Cette fonctionnalité est généralement utilisée par les solutions CASB de cryptage telles que centraya.com est proposé.
- Il est également possible que le cryptage ait lieu localement, mais sur le logiciel du fournisseur - par exemple le Double Key Encryption de Microsoft ou le ServiceNow Edge Encryption. Cette approche fait toutefois des concessions en termes de contrôle du mécanisme.
- "Hold your own key" (HYOK) est une approche dans laquelle vous, le client, ne perdez pas votre clé. En règle générale, vous avez également besoin d'une infrastructure locale, ce qui fait du cryptage HYOK un cryptage local avec une connexion au fournisseur. Pour un seul fournisseur/application, il s'agit d'une approche sûre. Si différents fournisseurs sont utilisés, chacun a généralement besoin d'une solution HYOK dédiée. Les solutions inter-fournisseurs ou inter-applications génèrent une complexité d'infrastructure significative dans votre centre de données.
- Nous parlons d'une solution "Provider Managed Key" lorsque le fournisseur gère une clé dédiée par client. La clé reste sous le contrôle du fournisseur, qui choisit également le mécanisme et le lieu. Le client n'a en fait aucun contrôle sur le cryptage. Provider Managed Key est la solution la plus courante proposée par les fournisseurs d'accès. En principe, ils indiquent seulement qu'ils chiffrent quelque chose. La clé, le mécanisme et le lieu sont exclusivement contrôlés par le fournisseur.
Seules les trois premières approches de cryptage mentionnées ci-dessus augmentent votre sécurité de manière significative. Une solution "Provider Managed Key" a en revanche un petit potentiel de perturbation pour la fonctionnalité du fournisseur. Il reste à peser le pour et le contre entre sécurité et fonctionnalité. En raison du multi-cloud, nous recommandons une solution basée sur le cryptage BYOE, qui met l'accent sur les "informations d'identification personnelle" (PII). Ainsi, la protection des données personnelles est élevée et le potentiel de perturbation de la fonctionnalité est faible.
Vous devez être conscient d'une chose : dès que vous ne stockez plus seulement des données (sensibles) localement - et c'est depuis longtemps une réalité pour la plupart des entreprises - vous abandonnez le contrôle de vos données. Les termes à consonance positive pour les types de cryptage proposés par les fournisseurs d'accès, tels que "Bring your own key", inspirent certes intuitivement confiance aux utilisateurs, mais ne garantissent pas pour autant la sécurité des données. Ce qui est décisif, c'est le lieu où les données sont cryptées, le mécanisme utilisé et la personne qui détient la clé.
Si le cloud est votre stratégie, ne manquez pas le prochain blog de cette série. Il y sera question du multi-cloud et de ses besoins spécifiques. Santé !
Vous souhaitez obtenir plus d'informations sur le sujet ?
S'inscrire
Apprenez-en plus sur les tendances. Après votre inscription, vous pourrez télécharger des fiches d'information et d'autres articles spécialisés sur nos sites de tendances.
N'hésitez pas à nous contacter. Nous vous conseillons volontiers
Nos experts se tiennent à votre disposition pour répondre à vos questions sur ce thème tendance.
DE 
EN 
FR 