ECUE.3.

22

Section 2. Solutions de sécurité dans le

Cloud

Leçon2. Cloud Data Asset Security

Classification des données

La classification des données est le processus d'organisation des données

par catégories pertinentes afin qu'elles puissent être utilisées et protégées
plus efficacement.
Le processus de classification facilite la localisation et la récupération des
données. La classification des données est particulièrement importante en
matière de gestion des risques, de conformité et de sécurité des données.

La classification des données implique le balisage (tagging) des données

pour les rendre facilement consultables et traçables.
La classification des données élimine également les duplications multiples
de données, ce qui peut réduire les coûts de stockage et de sauvegarde
tout en accélérant le processus de recherche.
Types de Classification des données

La classification des données implique diverses balises le type de données,

leur confidentialité, leur intégrité et leur disponibilité.
Il existe trois principaux types de classification des données qui sont
considérés comme des standards industriels:
o Content-based Classification : inspecte et interprète les fichiers à la recherche
d'informations sensibles
o Context-based Classification : considère l'application, l'emplacement … parmi
d'autres variables comme des indicateurs indirects d'informations sensibles
o User-based Classification : dépend d'une sélection manuelle de l'utilisateur final de
chaque document.
Exemples de Classification des données
Faible : l'impact de la divulgation de ces données sur l'organisation serait très faible
ou négligeable:
o Adresses IP publiques de vos serveurs, journaux de log des applications sans données
personnelles ou secrets, matériel d'installation de logiciels sans secrets ni autres
éléments de valeur pour les attaquants
Modéré: Ces informations ne doivent pas être divulguées en dehors de
l'organisation (exceptionnellement dans le cadre du droit d’accès)
o Des informations détaillées sur la conception de vos systèmes d'information, qui
peuvent être utiles à un attaquant , Informations sur votre personnel, qui pourraient
fournir des informations aux attaquants pour des attaques de phishing , Informations
financières courantes, telles que les bons de commande …
Elevé: Ces informations sont vitales pour l'organisation et leur divulgation pourrait
causer des dommages importants. L'accès à ces données devrait être très
étroitement contrôlé, avec de multiples garanties. Dans certaines organisations, ce
type de données est appelé les « Crown Jewels »
o Informations stratégiques, informations financières qui fourniraient un avantage
significatif aux concurrents
o Des secrets commerciaux, des secrets qui fournissent les «clés du royaume»,
tels que les informations d'identification d'accès complet à votre infrastructure
cloud, les données financières de vos clients
Des règles pour la classification des données
Les lois et les règles de l'industrie peuvent dicter la façon dont les données sont
classifiées:
Par exemple, le RGPD vous oblige à cataloguer, protéger et auditer l'accès à «toute information
relative à une personne identifiable qui peut être identifiée directement ou indirectement
notamment par référence à un identifiant».
Si vous manipulez des informations de carte de crédit, la norme de sécurité des données de
l'industrie des cartes de paiement (PCI) dicte qu'il y a des contrôles spécifiques que vous devez
mettre en place et qu'il y a certains types de données que vous n'êtes pas autorisé à stocker.
Si vous traitez avec des informations de santé protégées (PHI), la loi sur la portabilité et la
responsabilité en matière d'assurance maladie (HIPAA) vous oblige à inclure ces informations dans
votre liste et à les protéger, ce qui implique souvent le cryptage.

Il existe également des services cloud qui peuvent aider à la classification et à la

protection des données. :
À titre d'exemple, Amazon Macie peut vous aider à trouver des données sensibles dans des
compartiments S3, et l'API Google Cloud Data Loss Prevention peut vous aider à classer ou
masquer certains types de données sensibles.
Balisage des Données
L’utilisation des services cloud apporte un certain niveau de standardisation By
design. Les données persistantes dans le Cloud seront dans l'un des services cloud
qui stockent des données, telles que:
o Le stockage d'objets, le stockage de fichiers, le stockage par blocs, une base de données cloud ou
une file d'attente de messages cloud.
Un fournisseur de Cloud donne les outils nécessaires pour inventorier ces
emplacements de stockage, ainsi que pour y accéder (de manière soigneusement
contrôlée) pour déterminer quels types de données y sont stockés.
La plupart des fournisseurs de cloud, ainsi que des systèmes de gestion de
conteneurs tels que Kubernetes, ont le concept de balises. Une balise est
généralement une ombinaison d'un nom (ou «clé») et d'une valeur
généralement entre 15 et 64 balises par ressource
Si vous n'avez pas besoin de les utiliser pour catégoriser ou prendre des décisions plus
tard, ils sont facilement ignorés.
Exemples de quelques balises liées aux données qui peuvent s'appliquer à vos
différentes ressources cloud:
dataclass:low, dataclass:moderate, dataclass:high, or regulatory:gdpr.
Protéger les Données dans le Cloud
Tokenisation
La tokenisation, comme le cryptage, est un processus réversible qui remplace les
données sensibles par des données qui ne peuvent pas être utilisées par des parties
non autorisées.
Alors que le chiffrement utilise des algorithmes pour générer du texte chiffré à
partir de texte en clair, la tokenisation remplace les données d'origine par des
caractères générés de manière aléatoire dans le même format (valeurs de jeton).
Les relations entre les valeurs d'origine et les valeurs de jeton sont stockées sur un
serveur de jetons. Lorsqu'un utilisateur ou une application a besoin des données
correctes, le système de tokenisation recherche la valeur du token et récupère la
valeur d'origine.
Cas d’usage : Systèmes de traitement des paiements; données structurées
Protéger les Données dans le Cloud (2)
Masquage
Le masquage est essentiellement une tokenisation permanente. Les informations
sensibles sont remplacées par des caractères aléatoires dans le même format que
les données d'origine, sans mécanisme de récupération des valeurs d'origine.
Le masquage peut également être utilisé pour contrôler l'accès aux données
sensibles en fonction des droits. Cette approche, connue sous le nom de masquage
dynamique des données, permet aux utilisateurs et applications autorisés de
récupérer des données non masquées dans une base de données, tout en
fournissant des données masquées aux utilisateurs qui ne sont pas autorisés à
afficher les informations sensibles.
Protéger les Données dans le Cloud (3)
Redaction
La rédaction est la suppression permanente des données sensibles, l'équivalent
numérique du "noircissement" du texte (blacking-out) dans les documents imprimés.
La rédaction peut être effectuée en supprimant simplement les caractères d'un
fichier ou d'un enregistrement de base de données, ou en remplaçant les caractères
par des astérisques ou d'autres espaces réservés.

La rédaction de données automatisée est une méthode efficace pour éliminer les
données sensibles des documents, des feuilles de calcul et d'autres fichiers, sans
modifier le contenu du fichier restant.
Les organisations adoptent souvent cette approche pour empêcher la propagation
d'informations sensibles extraites d'une base de données et enregistrées sur des
serveurs de fichiers, des ordinateurs portables ou des ordinateurs de bureau.
Protéger les Données dans le Cloud (4)
Chiffrement
Le chiffrement est la méthode la plus puissante et la plus utilisée pour protéger
les données sensibles. Lorsqu'il est correctement mis en œuvre, le cryptage ne
peut être vaincu par aucune technologie connue (avant l’ère du quantique!!)
Le chiffrement utilise des algorithmes complexes pour convertir les données
originales (texte en clair) en blocs de texte illisibles (texte chiffré) qui ne
peuvent pas être reconvertis sous une forme lisible sans la clé de déchiffrement
appropriée.
Le chiffrement peut être mis en œuvre de différentes manières, chacune
adaptée à différents cas d'utilisation:
o Le chiffrement du réseau protège les données lors de leur déplacement (in motion) ,
laissant les données en clair à chaque extrémité d'une transmission.
o Un chiffrement transparent protège les données au repos (at rest), déchiffrant les
données avant qu'elles ne soient accessibles aux utilisateurs autorisés.
o Le chiffrement persistant protège les données indépendamment de l'endroit où elles
sont stockées ou copiées (in use) , offrant une protection maximale contre une
utilisation inappropriée.

Utilisations typiques: échange de données sécurisé; protéger les données au repos; données structurées
et non structurées
Chiffrement des données « In-Use »
Le cryptage des données «en cours d'utilisation» est encore relativement nouveau
et vise principalement les environnements de très haute sécurité. Il nécessite une
prise en charge dans la plate-forme matérielle et doit être fourni par le fournisseur
de Cloud.
L'implémentation la plus courante consiste à crypter la mémoire du processus afin
que même un utilisateur privilégié (ou un logiciel malveillant s'exécutant en tant
qu'utilisateur privilégié) ne puisse pas le lire, et le processeur ne peut le lire que
lorsque ce processus spécifique est en cours d'exécution.

Exemples de plate-formes qui prennent en charge le cryptage de la mémoire: Intel SGX,

AMD SME et IBM Z Pervasive Encryption.
Chiffrement des données « At- Rest»
Le problème n'est pas de crypter les données, il existe de nombreuses bibliothèques pour ce
faire. Le problème est qu'une fois que vous avez chiffré les données, où mettre les clés de
chiffrement qui peuvent être utilisées pour y accéder?
HSM (Hardware Security Module) : Certains fournisseurs de Cloud ont la possibilité
de louer un HSM dédié à votre environnement. Bien que cela puisse être nécessaire
pour les environnements à plus haute sécurité, un HSM dédié reste cher dans un
environnement cloud.
KMS (Key Management Service) : C’est un service multi-tenants qui utilise un HSM
sur le backend pour protéger les clés. Vous devez faire confiance à la fois au HSM et
au KMS (au lieu de simplement le HSM)! ce qui ajoute un peu de risque
supplémentaire. Cependant, par rapport à l'exécution de votre propre gestion des
clés (souvent incorrecte), un KMS offre une excellente sécurité à un coût nul ou
très faible.
Exemples de solutions KMS Cloud

Fournisseur Option de HSM dédié KMS

Amazon Web Services CloudHSM Amazon KMS

Microsoft Azure ---- Key Vault (software

keys)

Google Compute ---- Cloud KMS

Cloud

IBM Cloud Cloud HSM Key Protect

Chiffrement Client-Side vs Server-Side
Chiffrement côté client
l'application a la responsabilité de chiffrer et de déchiffrer les données qu'elle
échange aux fournisseurs de services cloud (souvent appelé chiffrement BYOK,
pour Bring Your Own Key)
Alors que le chiffrement côté client offre un certain degré de protection pour
garantir que les fournisseurs de cloud ne peuvent pas accéder aux données
chiffrées, les organisations rencontrent souvent des problèmes de complexité
en raison de la gestion des clés et de plusieurs applications.
Le chiffrement géré par le client utilise un concept appelé chiffrement
d'enveloppe (Wrapping Encryption) pour implémenter des clés gérées par le
client. Le chiffrement d'enveloppe est une pratique qui consiste à chiffrer une
clé de chiffrement avec une autre clé de chiffrement.
La clé utilisée pour chiffrer les données réelles porte le nom de clé DEK (Data
Encryption Key). La clé elle-même n'est jamais stockée, mais elle est encapsulée
par une seconde clé connue sous le nom de clé KEK (Key Encryption Key) afin
de créer une clé DEK encapsulée.
Pour déchiffrer les données, la clé DEK encapsulée doit d'abord être
désencapsulée pour obtenir la clé DEK.
Chiffrement Client-Side vs Server-Side (2)
Chiffrement côté serveur
Contrairement au chiffrement côté client, le chiffrement côté serveur permet
au fournisseur de services cloud de gérer les clés de chiffrement avec les
données.
Bien que cette approche offre la simplicité, vous laissez la protection des
données et les clés sous le contrôle du fournisseur de services
BYOK avec Google Cloud Platorm
Google offre le support BYOK avec une fonctionnalité appelée Clé de
chiffrement fournie par le client (Customer Supplied Encryption Key -CSEK).
Actuellement, CSEK est pris en charge dans GCE (Compute Engine) et GCS
(Cloud Storage).
GCE active par défaut le chiffrement du disque sur les instances de calcul, les
clés étant fournies et gérées par Google. Vous pouvez également fournir un
CSEK en tant que clé AES 256 bits, fournie à la fois sous forme de clé brute ou
encapsulée par une clé publique Google.
Il est toujours recommandé d’envelopper la clé pour assurer la sécurité de la
clé d'origine.
GCS prend également en charge le chiffrement côté serveur à l'aide de CSEK, à
l'aide d'une clé AES 256 bits. GCS, cependant, ne prend pas en charge un
mécanisme d’encapsulation des clés. Cette clé doit être fournie avec chaque
demande de téléchargement et de téléchargement des fichiers. La clé n'est
utilisée que de manière éphémère et n'est jamais stockée sur un disque en
interne par Google.
BYOK avec Azure
AWS prend en charge BYOK, cependant, cela nécessite l'utilisation de son
service de gestion des clés (KMS).
Pour commencer avec KMS, vous générez une clé principale client (Customer
Master Key - CMK), qui est utilisée pour dériver d'autres clés. Vous pouvez
importer votre propre clé AES 256 bits comme CMK, activant ainsi BYOK.
AWS fournit une clé d'encapsulation et un jeton pour importer en toute
sécurité les clés client.
On peut également définir la date d'expiration et les politiques d'accès des
utilisateurs pour les clés dans KMS. Une fois importé, vous pouvez utiliser
n'importe lequel des services intégrés KMS (S3, EBS, RDS, Redshift, etc.) pour le
chiffrement côté serveur.
BYOK avec AWS
Azure Key Vault prend en charge l'importation directe des clés client RSA 2048
bits en tant que clés protégées par logiciel ou clés protégées par HSM. Les clés
protégées par HSM ne quittent jamais les limites du HSM fourni par Azure
tandis que les clés logicielles sont garanties d'être chiffrées au repos via des clés
Microsoft sécurisées. Une fois importées, les clés ne peuvent être utilisées que
dans Azure et ne peuvent jamais être exportées.
Azure prend en charge BYOK dans Azure Information Protection où il permet
au client de gérer la clé du locataire via Azure Key Vault (la clé du locataire est
la clé racine de l'organisation; d'autres clés d'utilisateur ou d'application en sont
dérivées).
Azure SQL Database et Data Warehouse prennent également en charge BYOK
pour Transparent Data Encryption (TDE). Vous pouvez utiliser vos clés
importées dans Key Vault pour chiffrer les clés de chiffrement des données
(DEK) utilisées par la base de données SQL.