loader image

Dans la quatrième partie de notre série sur la résidence des données, nous discuterons des différentes techniques de cryptage et soulignerons leurs avantages et leurs inconvénients.

Les messages et les informations sont cryptés depuis l’antiquité. Cependant, les temps modernes fixent de nouvelles exigences. Pour que la protection soit maximale, elle doit commencer au plus près de l’utilisateur : le cryptage doit être facile à utiliser, il doit fonctionner de manière transparente et assurer un haut niveau de fiabilité opérationnelle.

Fondamentalement, les données peuvent être disponibles sous deux formes différentes dans le cloud :

  • En tant que fichier (il peut également s’agir d’un e-mail) dans un stockage
    de données non structuré
    Ces données peuvent être protégées en tant qu’ensemble entier en cryptant le fichier dans son ensemble.
  • En tant que champ dans un record(tel qu’une ligne ou une entrée de table) d’un stockage de 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 ce à quoi ces données doivent ressembler. Une date doit être sous une certaine forme et un e-mail a également certaines caractéristiques d’identification. Si le contenu du champ ne répond pas à ces attentes, une erreur de cohérence de champ peut se produire : l’application signale une erreur et refuse de l’enregistrer.

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 doivent donc être protégées : les données dans les fichiers, tant que le cloud est principalement utilisé comme une « Plateforme en tant que Service » (PaaS) comme avec SAP ou Microsoft Azure, et les données dans les champs si le cloud est de plus en plus utilisé comme « Software as a Service » (SaaS) comme Microsoft 365.

Où puis-je chiffrer ?

Le cryptage doit être simple et facile à utiliser – idéalement, les utilisateurs finaux n’y sont pour rien. Les emplacements suivants conviennent au chiffrement et au déchiffrement :

… sur le point de terminaison dans le navigateur

Le cryptage serait probablement implémenté sous forme de script Java ou sous une forme similaire. Étant donné que le navigateur devrait recevoir des clés parce que la méthode serait livrée avec le script Java, et le tout a lieu au niveau du navigateur, la solution est seulement sécurisée si le navigateur est capable de protéger la clé et d’authentifier l’utilisateur. Cela serait effectivement possible, mais cela ne se fait généralement pas en raison de la grande susceptibilité aux erreurs. En outre, le cryptage pourrait être facilement éliminé via les paramètres du navigateur et l’enregistrement malveillant ne serait également pas particulièrement difficile. De mon point de vue, protéger le point de terminaison n’a pas de sens.

… via un composant actif proche du système d’exploitation

Un logiciel sur le point de terminaison s’intégrerait dans le système de fichiers (pour les fichiers) d’une part et dans le système réseau (pour les champs) d’autre part. La manière invasive de cette approche ne se laisse pas utilisér de manière stable: les systèmes sous Windows, Mac, Android et autres sont trop rapides, fréquents et différents.

… directement dans une application

L’application sur le point de terminaison peut gérer le chiffrement. Microsoft, par exemple, le fait avec sa gestion des droits pour les fichiers. Cependant, cette approche ne fonctionne pas pour les champs via une application Web. C’est donc principalement possible avec des fichiers.

… dans un composant réseau en ligne situé entre l’utilisateur et le fournisseur

La communication entre l’utilisateur et le fournisseur est interceptée entre les deux, cryptée et déchiffrée. L’utilisateur ne remarque généralement rien de tout cela et le processus est rapide. Cependant, un « entre-deux » doit être possible. Bien que cela fonctionne généralement bien avec les champs, c’est un peu plus compliqué avec les fichiers. Cela a à voir avec la façon dont les données du stockage 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. Toutefois, l’appliance de chiffrement ne peut pas chiffrer l’ensemble du fichier de manière cohérente si elle n’obtient que des parties individuelles de celui-ci. Pour les champs, cependant, cela fonctionne généralement très bien.

… dans un composant actif qui communique avec le fournisseur

Les données arrivent au fournisseur de manière non cryptée (à l’exception du cryptage de transport). Si le fournisseur rend maintenant ces informations disponibles via API, un composant actif tel qu’un Cloud Access Security Broker (CASB) peut obtenir les données non chiffrées via API et renvoyer les données chiffrées via 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. Cela dépend de l’implémentation si les données non cryptées sont supprimées rapidement ou non. Encore une fois, il s’agit d’une question de confiance, sans aucune garantie que cela ne puisse pas être changé dans le futur.

… chez le fournisseur avant l’application

Le fournisseur propose un cryptage directement avant son interface utilisateur. C’est encore rare. Avec cette solution, tout dépend de l’origine de la clé, de la qualité du cryptage et s’il est garanti que les données ne survivent pas quelque part dans l’état non chiffré.

… chez le fournisseur dans l’application

Dès le début, l’application est construite de manière à ce que les données soient cryptées en fonction de la couche logique avant d’être stockées. Les grands fournisseurs tels que Salesforce ou ServiceNow sont en mesure de le faire, les plus petits par contre, ne le sont pas. La modernisation 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 de l’efficacité de cette opération incombe exclusivement au fournisseur. Il serait très simple de créer un cliché instantané non chiffré.

… chez le prestataire au repos

Le fournisseur chiffre les données lorsqu’elles sont stockées 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 l’emplacement (emplacement de la base de données/serveur de fichiers). Le contrôle incombe exclusivement au fournisseur.

Une sécurité maximale est assurée par l’option « composant réseau en ligne entre l’utilisateur et le fournisseur », car le fournisseur ne voit pas le contenu non crypté. Cependant, cette solution a également ses limites: le fournisseur ne peut plus « calculer » avec les données cryptées et ne peut généralement pas exécuter d’autres fonctionnalités plus complexes. Cette approche permet ainsi une plus grande anonymisation des données dans le cloud. Dans la plupart des cas, cela suffit.

Le facteur décisif est l’endroit où les données sont cryptées, le mécanisme et qui garde la clé entre leurs mains.

Qui contrôle mon chiffrement ?

Le chiffrement comporte trois éléments importants :

    • La clé ne doit pas se retrouver entre les mains de tiers. Des mauvaises clés créent un cryptage faible, et si une clé tombe entre les mains de tiers, ils peuvent déchiffrer les données et, si nécessaire, les modifier ou falsifier de nouvelles données.
    • Le mécanisme de cryptage doit impérativement ê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 même si la clé est bonne, car un mécanisme faible ne produit pas un bon cryptage. Il est donc important que le mécanisme utilisé soit bon et que le code utilisé pour celui-ci soit digne de confiance.
    • Bien sûr, l’endroit où le cryptage a lieu est également important. Si cela n’a pas lieu localement, personne n’empêche le remplacement des clés ou des mécanismes par une version débilitante.

Le cryptage n’est sous contrôle que si les trois éléments peuvent être contrôlés. Si un élément tombe entre les mains de 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 ici.

BYOK signifie « bring your own key » soit « apportez votre propre clé » ou « donnez-moi votre clé ». La clé est généralement remise au fournisseur, qui utilise ensuite un mécanisme contrôlé par lui à l’endroit de son choix. Ce mécanisme est souvent proclamé comme une « solution sûre ». En fait, cela ne fait qu’augmenter l’effort du client (qui doit maintenant faire la gestion des clés) sans augmenter considérablement la protection. Un package trompeur du service marketing du fournisseur.

Mieux vaut un BYOE « bring your own encryption », soit « apportez votre propre cryptage ». La clé, le mécanisme et l’emplacement sont contrôlés par le client et sont donc beaucoup plus fiables. Cette option a également le potentiel de résoudre les problématiques de résidence de données. La plupart des autres approches n’en sont pas capables.

Quel cryptage me convient le mieux?

  1. Une protection optimale est assurée par BYOE, c’est-à-dire un cryptage local. Les fournisseurs ne reçoivent que des informations cryptées. Il existe peu d’alternatives pour le multi-cloud. Toujours en ce qui concerne le problème de la résidence, cette approche est capable d’utiliser des clés dédiées par pays. Cette fonctionnalité est généralement offerte par le chiffrement des solutions CASB telles que centraya.com.
  2. Il est également possible que le cryptage ait lieu localement, mais sur le logiciel du fournisseur, tel que le cryptage à double clé de Microsoft ou le cryptage Edge ServiceNow. Cependant, cette approche compromet le contrôle du mécanisme.
  3. « Hold your own Key » (HYOK) est une approche dans laquelle vous, en tant que client, n’abandonnez pas votre clé. En règle générale, vous avez également besoin d’une infrastructure locale, ce qui fait du chiffrement HYOK un chiffrement local lié au fournisseur. Pour un seul fournisseur/application, il s’agit d’une approche sécurisée. Si différents fournisseurs sont utilisés, tout le monde a généralement besoin d’une solution HYOK dédiée. Les solutions inter-fournisseurs ou inter-applications créent une complexité d’infrastructure importante dans votre centre de données.
  4. On parle de solution de « clé gérée par le fournisseur » 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 l’emplacement. Le client n’a pratiquement aucun contrôle sur le cryptage. Provider Managed Key est la solution la plus couramment proposée par les fournisseurs. Fondamentalement, une “Provider Managed Key” signifie simplement qu le fournisseur emploit un cryptage. La clé, le mécanisme et l’emplacement sont contrôlés exclusivement par le fournisseur.

Seulement 1-3 augmentent considérablement votre sécurité. 4 a un faible potentiel d’interférence pour la fonctionnalité du fournisseur. Il s’agit donc de choisir entre sécurité et fonctionnalité. En raison du multi-cloud, nous recommandons une solution de classe 1 et un accent sur les « informations d’identification de la personne » (IPP). Cela signifie que la protection des données personnelles est élevée et que le potentiel de perturbation de la fonctionnalité est faible.

Vous devez être conscient d’une chose : dès que vous ne stockez plus de données (sensibles) uniquement localement – et cela a longtemps été une réalité pour la plupart des entreprises – vous abandonnez le contrôle de vos données. De bons termes pour les types de cryptage proposés par les fournisseurs, tels que « bring your own key », inspirent intuitivement confiance aux utilisateurs, mais ne garantissent pas pour cela la sécurité des données. Les facteurs décisifs sont l’endroit où les données sont cryptées, le mécanisme et qui garde la clé entre leurs mains.

Si le cloud est votre stratégie, ne manquez pas le prochain blog de cette série. Il s’agit du multi-cloud et de ses besoins spécifiques. Cheers.