Vous êtes sur la page 1sur 97

ECUE.3.

22

Section 1. Introduction à la Sécurité des


Données dans le Cloud

Leçon1. Des Données sur les Nuages!


Avant-Propos (1)

La migration vers une plate-forme de cloud computing signifie que votre


responsabilité en matière de sécurité des données augmente considérablement.
Les données avec différents niveaux de sensibilité (Sensitivity) sortent des limites de
votre pare-feu. Vous n’avez plus aucun contrôle - vos données pourraient résider
n’importe où dans le monde, selon le prestataire Cloud utilisé.

Passer au cloud public ou utiliser un cloud hybride signifie que le potentiel de


problèmes de sécurité du Cloud est omniprésent dans la chaîne. Cela peut se
produire lorsque les données sont préparées pour la migration, au cours de la
migration ou éventuellement dans le nuage après leur arrivée. Et vous devez être
prêt à résoudre ce problème à chaque étape du processus.
Avant-Propos (2)

La sécurité des données incombait aux fournisseurs de services de cloud computing,


qui ont été -jusque là- à la hauteur. Quelle que soit la plate-forme choisie dans le
débat entre AWS, Azure et Google, toutes ces entreprises se prétendent d’être
conformes à des normes de sécurité telles que HIPAA, ISO, PCI DSS et SOC! Bien
entendu, tel n’est pas le cas pour d’autres fournisseurs de Cloud qui n’ont pas le
privilège de se livrer à ce processus de conformité (Compliance).

Cependant, le fait que les fournisseurs offrent la conformité ne donne pas aux
clients le droit de renoncer à leurs responsabilités. Ils assument également une
certaine part de responsabilité, ce qui crée un défi considérable en matière
d'informatique en nuage.

De nombreuses organisations négligent le modèle de responsabilité partagé dans le


Cloud et pensent à tort que la sécurité est entièrement prise en charge par le
fournisseur de Cloud.
Des données sur le nuage

Données Données non Données semi-


structurées structurées structurées
Il s’agit d’une donnée qui Il s’agit d’une donnée qui
Il s’agit d’une donnée
est organisée suivant est organisée sans la
dont certains éléments
une structure. Elle peut moindre structure. Elle
de celle-ci sont
être générée par un peut être également
organisés suivant une
humain ou une machine, générée par un humain
structure.
cependant sa qualité ou une machine.
première est qu’elle
Exemple: fichiers XML et
puisse être facilement Exemple: document
JSON, Google Protocol
classée, retrouvée et Word, un fichier PDF, un
Buffer.
extraite . fichier audio, un fichier
Exemple: Base de image au format JPEG ou
données relationnelle. encore une vidéo .
Cycle de vie de la Sécurité des données dans
le nuage
NB: Dans le cycle de vie, les données peuvent rebondir entre les phases sans
restriction et peuvent ne pas passer par toutes les étapes (par exemple, toutes les
données ne sont pas finalement détruites).
Créer/Update: la création est la génération de nouveau
contenu numérique, ou la modification / mise à jour de
contenu existant.
Stocker: est l'acte qui valide les données numériques dans
une sorte de référentiel de stockage et se produit
généralement presque simultanément avec la création.
Utilisation: les données sont visualisées ou traitées.
Partager: les données sont échangées entre les utilisateurs,
les clients et les partenaires.
Archive: les données quittent une utilisation active et
entrent dans une mémoire à long terme.
Détruire: les données sont détruites de manière
Source: Security Guidance v4.0,
permanente à l’aide de moyens physiques ou numériques Cloud Security Alliance
(cryptographie, par exemple).
Exemple: Google Cloud Plateform (GCP)
Délimitation des responsabilités

• Le client: application, données et système d’exploitation


IaaS • Le fournisseur: hyperviseur, machine physique, locaux

• Le client: données , un sous-ensemble des applications


PaaS • Le fournisseur: un sous-ensemble des applications, système
d’exploitation, hyperviseur, machine physique, locaux

• Le client: rien
SaaS • Le fournisseur: tout
Délimitation des responsabilités (2)

Source: Cloud doption and Risk Report – McAfee 2019


Délimitation des responsabilités (3)

Le problème est que la plupart des fournisseurs de Cloud sont assez clairs dans
leurs conditions de licence qu'ils garantiront la protection des données
uniquement dans certains termes, comme le montre l'exemple ci-dessous de
Microsoft.
Objectifs de la sécurité… des plus classiques?
À l’instar des besoins de sécurité pour une infrastructure interne (On Premise), les
objectifs de sécurité pour un environnement Cloud sont :
Authentification (Authentication) : s’assurer de l’identité d’une personne ou d’une
entité (ou bien en détecter une usurpation), afin d’avoir la garantie que la personne
/ l’entité est bien celle qu’elle prétend être
Confidentialité (Confidentiality) : s’assurer que les informations stockées dans le
cloud ne sont accessibles qu’aux personnes autorisées
Intégrité (Integrity) : s’assurer que les informations n’ont pas été altérées,
notamment pendant le transport des données dans un environnement cloud, afin
d’avoir la garantie que les données sont complètes et exactes dans cet
environnement
Non-répudiation ou Imputabilité (Non-repudiation) : s’assurer que l’émetteur et le
destinataire d’une information sont bien ceux qui prétendent être et que
l’information envoyée est bien conforme à celle reçue. Techniquement, il s’agit d’une
combinaison entre les mécanismes d’authentification et d’intégrité
Objectifs de la sécurité (2)

Disponibilité (Disponibility) : s’assurer que les services, les ressources et les réseaux
informatiques soient accessibles
Contrôle d’accès (Access control) : s’assurer que des moyens ont été mis en place
pour limiter l’utilisation de systèmes ou d’applications
Fraîcheur (Refreshing) : s’assurer lors d’une communication de données du caractère
« récent » de ces informations, afin d’éviter des attaques dites « par rejeu »
Traçabilité ou Preuve ou Auditabilité (Evidence) : s’assurer d’avoir les moyens de
prouver la réalité des actions.

…Et sur le cloud, c’est une autre paire de manches!


Les enjeux de la sécurité dans le Cloud

Confidentialité des données: Data Privacy

Un grand nombre de lois nationales et internationales relatives à la protection de la


vie privée ont obligé plus d’une entreprise à refuser de passer au Cloud, car la loi
est trop lourde et exigeante!
De nombreux fournisseurs peuvent stocker des données sur des serveurs ne se
trouvant pas physiquement dans une région, car le propriétaire des données et les
lois peuvent être différents. Ceci est un problème pour les entreprises soumises à
des lois de résidence de données strictes. Sans compter que le fournisseur de
services de cloud computing va probablement se dégager de toute responsabilité
dans le contrat SLA (service Level Agreement), cela laisse les clients avec la pleine
responsabilité en cas de violation.
Les enjeux de la sécurité dans le Cloud
Confidentialité des données: Data Privacy (2)
Lois internationales sur la résidence des données:
États-Unis
Loi sur la transférabilité des informations sur la santé (HIPAA),
Les normes de sécurité des données du secteur des cartes de paiement (PCI DSS)
Le règlement sur le trafic international des armes (ITAR) et la loi sur les technologies de la
santé à des fins économiques et cliniques (HITECH). ).
Europe
Règlement général sur la protection des données (RGPD) , lourdement sanctionnant
de nombreux pays de l'Union européenne (UE) maintenant qui dictent que des
informations sensibles ou privées ne doivent pas quitter les frontières physiques du
pays ou de la région. d'où ils proviennent
Règlement du Royaume-Uni sur la protection des données
Loi fédérale suisse sur la protection des données
Loi russe sur la protection des données
Loi canadienne sur la protection des informations personnelles et les documents
électroniques (LPRPDE).
Les enjeux de la sécurité dans le Cloud
Intégrité, la perte de gouvernance, de souveraineté et le vol de données

L'intégrité des données peut être définie comme la protection des données contre
toute modification ou suppression non autorisée. Cela est facile dans une base de
données unique, car vous ne pouvez contrôler qu'une seule manière d'entrer ou de
sortir de la base de données. Mais dans le cloud, en particulier dans un
environnement multi-Cloud, cela devient difficile.

Les données stockées dans le Cloud pourraient être corrompues lors de la


transmission vers / depuis le stockage de données cloud. Comme les données et le
calcul sont externalisés vers un serveur distant, leur intégrité doit être maintenue et
vérifiée en permanence afin de prouver que les données et le calcul sont intacts.

Toute modification des données doit être détectée.


Les enjeux de la sécurité dans le Cloud

Contrôle d’accès

En raison du grand nombre de sources de données et de moyens d'accès,


l'autorisation devient cruciale pour garantir que seules les entités autorisées
peuvent interagir avec les données. Cela signifie des moyens d'accès plus stricts,
comme l'autorisation à deux facteurs, et la journalisation pour voir qui a accédé à
quoi.
Les enjeux de la sécurité dans le Cloud

Disponibilité

En réalité, les données qui ne sont pas disponibles en cas de besoin n’ont plus de
valeur! C'est pire qu'inutile car si des systèmes ont été configurés en fonction de
cette disponibilité (une réaction en chaîne à une catastrophe, une défaillance,…) de
les données nécessaires peuvent être manquantes, ou pire, obsolètes ou autrement
compromises.
Mais aussi: prévoir des mécanismes de « recovery » et de backup !
Dans un environnement Cloud, il s’ agit toujours d’un point de défaillance (Single
Point Of Failure – SPOF)
Les services du Cloud sont « scalables » et robustes, mais ils constituent un point
de défaillance unique pour les utilisateurs.
Prenons l'exemple du Playstation Network (PSN) de Sony. Il a été défaillant à plusieurs
reprises , empêchant essentiellement des millions d'utilisateurs de jouer pendant ces
périodes de défaillance..
Le Cloud, Pas aussi sécurisé que ça?
Vulnérabilité des données dans le Cloud
Quelques chiffres :
Source: Cloud Adoption and Risk Report-McAfee-SYDNEY 2018
« Le nombre d’incidents liés à la prévention des pertes de données (DLP) de l’Infrastructure-as-
a-Service a augmenté de 248 % par rapport à l’an dernier »
« 21% tous les fichiers dans le Cloud contiennent des données sensibles, démontrant une
augmentation régulière d'une année à l'autre (AAA) »
« Le partage de données sensibles via un lien ouvert et accessible au public a augmenté de
23% AAA »
Les menaces dans le cloud, telles qu'un compte compromis, des menaces d'utilisateurs
privilégiés et des menaces internes, ont augmenté de 27,7% AAA, les menaces dans Office365
augmentant de 63% AAA »
Le partage de données sensibles via un lien public a augmenté de 23% sur un an. »
Les données sensibles envoyées à une adresse électronique personnelle ont également
augmenté de 12% AAA. »
92% de toutes les organisations ont volé leurs identifiants cloud (Cloud Credentials) pour les
vendre sur le Dark Web. »
Infractions sur les données (Data Breaches)

Source: Cloud Security: Spotlight Report- Delta Risk 2017


« Les trois principales préoccupations des personnes interrogées en matière de sécurité
dans le cloud concernaient la protection contre la perte de données (57%), les
menaces à la confidentialité des données (49%) et les violations de la confidentialité
(47%) » .
Infractions sur les données

La violation de données (Data Breaches) constitue une menace extrêmement


préoccupante pour la sécurité de toute organisation qui utilise, traite, stocke ou
utilise des données. Cependant, généralement, les données utilisées par les
entreprises actuelles peuvent contenir des enregistrements comprenant des
informations sur les clients ou les partenaires personnellement identifiables.

Ce type de violation expose le consommateur au vol de données et à la vie


privée, ruinent la confiance des clients dans l’entreprise et entraînent des
répercussions majeures pour l’entreprise à partir de laquelle les données ont été
divulguées (Data Leakage)

Une information personnellement identifiable (PII) peut inclure un nom, une


adresse, un numéro de téléphone, une adresse électronique, des informations
financières, notamment des numéros de carte de crédit, des numéros de sécurité
sociale et de nombreux autres types d’informations permettant d’identifier
personnellement un individu.
Top 2018 Data incidents,…, et pas que!
1. Aadhaar India National ID Database
Base de données d'identification gouvernementale contenant des informations d'identité,
biométriques et autres sur plus de 1,1 milliard de citoyens indiens inscrits. Cause: Un API
endpoint non sécurisé.

2. Cambridge Analytica
Les données de près de 87 millions d'utilisateurs ont été compromises dans cette fuite de
données qui comprenait des informations telles que celles trouvées dans le profil public de
Facebook, les préférences de page, l'anniversaire et la ville actuelle. Cause: collecte de
données sans consentement et utiliser ces données à des fins politiques de manière non
autorisée.

3. Marriott Starwood Hotels


Base de données compromise d’environ 500 millions d'invités, quelque 327 millions
d’enregistrements contenant des informations telles que le nom, l’adresse postale, le numéro
de téléphone, l’adresse e-mail, le numéro de passeport, …, et éventuellement numéros de
carte de paiement et dates d'expiration cryptés avec le cryptage AES-128. Cause: Remote
Access Trojan.

4. Facebook
Une attaque a compromis près de 50 millions de comptes d'utilisateurs et d'informations
personnelles (c’était la plus grande infraction de Facebook en 14 ans d’existence) Cause:
Inconnue.
Pour récapituler…les « top threats »

Data breaches (Violations de données)

Data loss (Perte de données)

Hijacked accounts (Comptes piratés)

Cryptojacking

Malicious insiders (Initiés malveillants)

Denial of Service (Déni de service)

Data Location (Emplacement des données)

Ces menaces seront détaillées dans la Leçon2 de la Section1 !


ECUE.3.22

Section 1. Introduction à la Sécurité des


Données dans le Cloud

Leçon2. Vulnérabilités des Données dans le


Cloud
Data Breaches
Une infraction de données est la divulgation d'informations confidentielles,
privées ou autrement sensibles dans un environnement non sécurisé. Une violation
de données peut se produire accidentellement ou à la suite d'une attaque délibérée.

Les violations de données sont une préoccupation majeure pour la cybersécurité


car des données sensibles sont constamment transmises sur Internet. Ce transfert
continu d'informations permet aux attaquants de n'importe quel endroit de tenter
des violations de données sur presque toute personne ou entreprise de leur choix.
Data Leakage (fuite) & Exfiltration

L'exfiltration de données est le processus de vol et de transmission furtive de


données de systèmes compromis vers des emplacements non autorisés sur
Internet. Étant donné que les applications Cloud d'entreprise stockent des
données sensibles dans le cloud, elles sont vulnérables aux failles de sécurité qui
entraînent une fuite de données due à une erreur humaine ou à des pirates.

Scénario 1
Les utilisateurs d'applications Cloud d'entreprise peuvent partager publiquement des
documents sensibles en configurant les droits d'accès de manière non sécurisée, par exemple,
en partageant publiquement des fichiers sensibles via Google Drive, Box ou d'autres sites de
partage similaires.
Les compartiments Amazon S3 (Amazon S3 Buckets) ont été sous le radar parce que plusieurs cas
ont été notés où des données sensibles ont été divulguées via des buckets S3.
Data Leakage (fuite) & Exfiltration (2)
Scénario 2
Les utilisateurs peuvent télécharger des fichiers contenant des données sensibles telles
que des informations personnellement identifiables (PII), des informations sur l'industrie
des cartes de paiement (PCI) et des informations de santé protégées (PHI) sur des
applications Cloud et partager ces fichiers de manière non sécurisée avec d'autres
utilisateurs.

Scénario 3
Les attaquants peuvent valider et vérifier les fichiers sensibles hébergés dans des
comptes Cloud compromis et exfiltrer les données en rendant ces fichiers publics et en
les téléchargeant sur un serveur non autorisé, et en envoyant des fichiers sous forme de
pièces jointes par e-mail en utilisant des comptes utilisateurs compromis.

Scénario 4
Un code malveillant installé sur les systèmes des utilisateurs finaux (End user systems)
peut être dirigé pour voler des fichiers dans les dossiers spécifiques à un agent
d'application Cloud d'entreprise utilisé pour synchroniser les fichiers avec les serveurs
Cloud. Le malware peut facilement crypter les données et les exfiltrer via HTTP /
HTTPS ou d'autres protocoles.
Data Loss

Il existe de nombreuses possibilités de perte de données :


Attaque malveillante
Pannes de serveurs
Suppression involontaire par le fournisseur sans avoir de sauvegardes.
Des événements catastrophiques (séisme, incendie, …)
Tout événement qui porte atteinte aux clés de chiffrement pourraient entraîner
également une perte de données.
Accès intentionnel ou accidentel par les employés internes peuvent accéder aux
données
Les pirates externes peuvent gagner l’accès à des bases de données dans des
environnements en ayant recours au détournement de session et l'écoute
clandestine des transmissions réseau.
Hijacked accounts & Credential Stealing
Les attaquants ciblent les utilisateurs finaux pour voler leurs informations
d'identification Cloud (Credentials) afin d'effectuer des opérations néfastes.

Scénario 1
Attaques de phishing:
Il s'agit de la méthode d'attaque la plus utilisée par les attaquants. Il utilise des
techniques d'ingénierie sociale pour inciter les utilisateurs à fournir des
informations d'identification de compte afin de voler leurs informations
d'identification. Celles-ci sont classées en trois types en fonction de la façon dont
les pages Web de phishing sont déployées et distribuées:

o Pages de phishing déployées sur des applications cloud: il s'agit de l'une des techniques
les plus avancées, dans laquelle les pages de phishing sont hébergées sur les applications
cloud elles-mêmes. Les attaquants recourent à des fonctionnalités inhérentes à la prise en
charge HTML / JS des applications cloud pour héberger des pages Web de phishing. Une
fois les pages Web partagées publiquement, l'URL associée, intégrée dans un e-mail de
phishing, est envoyée aux utilisateurs. Cette attaque est difficile à contourner car les pages
de phishing sont hébergées sur des domaines d'application cloud légitimes qui utilisent
HTTPS. Un utilisateur non averti supposera généralement que les pages Web sont
légitimes. Par conséquent, les utilisateurs fournissent des informations d'identification qui
sont transmises via une demande HTTP GET / POST à un domaine géré par un attaquant.
Hijacked accounts & Credential Stealing (2)

o Pages de phishing déployées en tant que pièces jointes: les attaquants peuvent
user des fonctionnalités des URL de données prises en charge par leur navigateur. Il
est possible de coder les données dans un gestionnaire «data: text / html» et, lorsqu'il
est autorisé à s'ouvrir dans la barre d'adresse du navigateur, il rend le contenu.
Les attaquants utilisent cette astuce pour coder les pages Web de phishing dans le
gestionnaire de données et les transmettre en tant que pièces jointes dans les e-mails
de phishing. Lorsque l'utilisateur ouvre la pièce jointe, le contenu (gestionnaire de
données) est ouvert dans la barre d'adresse du navigateur et il affiche la page Web de
phishing décodée

o Pages d'hameçonnage déployées sur des domaines d'application en dehors du


Cloud: les pages Web des applications Cloud légitimes sont clonées, mises à jour et
déployées sur des domaines d'applications en dehors du Cloud. Les attaquants
sélectionnent un domaine qui peut sembler légitime mais qui ne l'est pas. Ces
attaques sont exécutées en conjonction avec des tactiques d'ingénierie sociale pour
inciter les utilisateurs à révéler leurs informations d'identification d'application Cloud.
Hijacked accounts & Credential Stealing(3)

Scénario 2
Attaques Man-in-the-browser (MitB)

les attaques MitB sont des exploits avancés dans lesquels les end user systems
sont d'abord infectés par des logiciels malveillants, tels qu'un bot, qui est
ensuite activé pour effectuer des opérations avancées dans le système
compromis. Le bot espionne la communication entre le navigateur de
l'utilisateur et l'application Cloud. Le bot injecte du code non autorisé dans le
processus du navigateur et enregistre les informations d'identification de
l'application Cloud entrées par l'utilisateur.
Le mode d'attaque MitB est actuellement déployé dans la majorité des botnets
(réseaux de zombies).
Principalement, le bot accroche (hook) les fonctions critiques importées des
bibliothèques du navigateur pour vider (dump) les informations d'identification
(credentials) dans les requêtes HTTP GET / POST.
Hijacked accounts & Credential Stealing(4)

Scénario 3
Attaques Man-in-the-Cloud (MitC)

Les attaques MitC10 sont similaires aux attaques MitB. La différence est que
les jetons (mécanismes d’authentification dans le Cloud) sont volés au lieu des
informations d'identification du compte. Les logiciels malveillants résidant dans
le système de l'utilisateur final sont capables de détourner (hijack) le canal de
communication (i.e. injecter des jetons de synchronisation non autorisés
fournis par l'attaquant afin que des jetons valides et non expirés puissent être
extraits pour accéder aux comptes des utilisateurs.)
Exemple: Le malware MitC exploite les services de synchronisation de fichiers pour
installer des logiciels malveillants supplémentaires, exfiltrer des données et effectuer
des opérations de commande et de contrôle (C&C).
Cryptojacking

Le cryptojacking est le fait de prendre importunément un ordinateur pour


exploiter la crypto-monnaie, qui est un processus très gourmand en calcul.
Le cryptojacking a haussé en 2017 et 2018 et le Cloud était une cible majeure à
cause de la prépondérance et la disponibilité de ressources de calcul.
La surveillance d'une activité de calcul inhabituelle est le principal moyen d'y mettre
un terme.
Malicious Insiders
Les initiés malveillants sont les personnes autorisées à gérer les données
(administrateurs de base de données, employés du prestataire Cloud, des partenaires,
les contractants qui ont accès aux données…) et peuvent voler ou corrompre les
données - qu'elles soient payées par d'autres sociétés ou simplement pour nuire à une
entreprise.

La vulnérabilité aux malicious insider provient de:


o Rôles et responsabilités peu clairs,
o Mauvaise application des définitions des rôles,
o Vulnérabilités AAA (Authentification,Authorization ,Accounting)
o Vulnérabilités des OS
o Procédures de sécurité physique inadéquates

Les attaques internes les plus courantes étaient l'accès et l'utilisation non autorisés des
informations de l'entreprise (63%), l'exposition involontaire de données privées ou sensibles
(57%), les virus, les vers ou autres codes malveillants (37%) et le vol de propriété intellectuelle
( 32%).
Denial of Service

L’objectif principale d'une attaque DDoS est de rendre la victime incapable d'utiliser
ses ressources. Dans la plupart des scénarios, les cibles peuvent être les serveurs Web,
le processeur, le stockage et d’autres ressources du réseau. Dans un environnement
Cloud, les DDoS peuvent également réduire considérablement les performances des
services Coud en endommageant les serveurs virtuels.
Les attaques DDoS sont lancées en affectant la victime sous les formes suivantes:
L'attaquant peut trouver un bogue ou une faille dans l'implémentation du logiciel
pour perturber le service.
Certaines attaques épuisent toute la bande passante ou les ressources du
système des victimes.
Récemment, les botnets ont été largement utilisés pour effectuer des attaques
DDoS afin de conduire des attaques DDoS flooding.
Data Location
Les prestataire du Cloud ont de nombreux data centers géographiquement
répartis. L'emplacement des données est un problème dans le Cloud computing du
moment que les utilisateurs de Cloud doivent savoir où leurs données sont
stockées.
Certains pays, selon la juridiction, exigent que leurs entreprises stockent leurs
données dans leur pays.
L’emplacement des données est important lorsque les données utilisateur sont
stockées dans des régions sujettes aux guerres et aux catastrophes.

Fin 2013, le ministère de la Justice américain a poursuivi Microsoft pour l'accès aux courriels
des clients stockés dans un centre de données de Dublin. L'argument de Microsoft était que,
comme les informations étaient stockées à l'étranger, elles ne relevaient pas des juridictions
légales des États-Unis. Microsoft a perdu et a par la suite fait appel, remportant l'appel à la
mi-2016.
Étrangement, Google a perdu sa propre affaire à peu près au même moment où Microsoft a
gagné son appel. Dans ce cas, les données ont également été stockées à l'étranger et Google
en a remis une partie au FBI dans le cadre d'une enquête.
Misconfigurations
Exemples de mauvaises configurations typiques du cloud

Manque de journalisation (logging)


Manque de contrôle d'accès et de gestion des accès - laissant l'accès ouvert
Buckets AWS S3 non sécurisés – pouvant être ouverts pour télécharger ou même midifiés
Absence / mauvais contrôles des autorisations
Non activation des contrôles de sécurité fournis par le prestataire Cloud
Absence d'audit
Éléments de stockage de données non sécurisés
Identifiants par défaut
Paramètres de configuration par défaut
Systèmes sans correctifs (unpatched systems)
Accès non restreint aux ports
Accès non restreint aux services
Absence de contrôle de modifications
ECUE.3.22

Section 2. Solutions de sécurité dans le


Cloud

Leçon1. Cloud Identification & Access Management


Authentification - Autorisation
La gestion des identités et des accès (Identification & Access Management –
abv. “ IAM”) implique deux concepts distincts:

L’authentification (Authentication – abv. “Authn”) est le processus de vérification


de l'identité.
L’autorisation (Authorization – abv. “Authz”) est le processus de vérification de
l'accès à une entité.

NB: N'oubliez pas les identités pour les entités « non humaines » telles que les
applications., les objets connectés, … celles-ci doivent également être gérées, tout
comme les identités humaines.
Cycle de vie du processus IAM
Exemples de services IAM des fournisseurs Cloud

Exemples de services de gestion d’identité pour authentifier vos


administrateurs Cloud avec les services de fournisseur Cloud.

Fournisseur Système de Gestion d’identités

Amazon Web Services Amazon IAM

Microsoft Azure Azure Active Directory B2C

Google Compute Cloud Cloud Identity

IBM Cloud Cloud IAM


Exemples de services IAM des fournisseurs Cloud (2)
Systèmes de gestion d’identités de vos utilisateurs finaux – end system users - qu'il s'agisse
de clients externes ou de vos propres employés:
o Utiliser un système d’authentification interne pour identifier les employés
o Utiliser un système d’authentification externe (Gmail, LinkedIn, Facebook,…)
o Utiliser un service Cloud pour la gestion des identité des utilisateurs finaux (Identity-
as-a-Service (IDaaS))
Fournisseur Système de Gestion d’identités des clients

Amazon Web Services Amazon Cognito

Microsoft Azure Azure Active Directory B2C

Google Compute Cloud Firebase

IBM Cloud Cloud Identity

Auth0 Customer Identity Management

Ping Customer Identity and Access Management

Okta Customer Identity Management

Oracle Oracle Identity Cloud Service


Authentification multi-facteurs

L'implémentation la plus courante est l’authentification à deux facteurs (2FA), qui


utilise quelque chose que vous connaissez (comme un mot de passe) et quelque
chose que vous avez (comme votre téléphone mobile).
Une authentification 2FA et fortement recommandée pour tout accès privilégié,
l'accès pour lire ou modifier des données sensibles, ou l'accès à des systèmes tels que
les e-mails qui peuvent être utilisés pour réinitialiser d'autres mots de passe.
Dans un environnement Cloud, un accès administrateur non autorisé aux services ou
API Cloud représente un risque très élevé (un attaquant disposant de cet accès peut
en tirer parti pour compromettre toutes vos données) . Vous devez impérativement
activer la 2FA.
La plupart des fournisseurs Cloud supportent nativement la 2FA. Sinon, si vous
utilisez l'authentification unique (SSO: Single Sign On) le fournisseur d'authentification
effectue une 2FA.
Google utilise le terme plus convivial de « 2-Step Verification ».
Authentification multi-facteurs (2)

Source: How to Build SMS 2FA That Won’t


Scare Away Your Users, Hugh Hopkins 2015
Authentification multi-facteurs (3)
Les méthodes les plus courantes pour vérifier «quelque chose que vous avez» sont :
o SMS – Facilement compromise en cas de vol de mobile ou de clonage de SIM
o Time-based One Time Passwords (TOTP): cette méthode nécessite de fournir à un appareil
mobile un «secret» initial (généralement transféré par un code-barres 2D). Le secret est
une formule pour calculer un mot de passe à usage unique toutes les minutes environ. Le
mot de passe à usage unique ne doit être conservé en sécurité que pendant une minute
ou deux, mais le secret initial peut permettre à n'importe quel appareil de générer des
mots de passe valides et doit donc être oublié ou placé dans un endroit physiquement sûr
après utilisation.
o Notifications push: avec cette méthode, une application cliente déjà authentifiée sur un
appareil mobile établit une connexion avec un serveur, ce qui «repousse» un code à usage
unique selon les besoins.
o Un périphérique matériel (clé usb, microship, NFC, BLE,…) conforme à la norme FIDO
U2F (Cf https://fidoalliance.org/).
o Pour une liste plus exhaustive : Yevseiev, Serhii & Hryhorii, Kots & Liekariev, Yehor. (2016).
Developing of multi-factor authentication method based on Niederreiter Mceliece modified
crypto-code system. Eastern-European Journal of Enterprise Technologies. 6. 11-23.
10.15587/1729-4061.2016.86175.
API Keys

Les API Keys sont très similaires aux mots de passe sauf qu’ils sont conçues pour être
utilisées par du code applicatif. Pour cette raison, l'authentification multi-facteurs
n’est pas plausible avec des API keys.
Il s'agit de longues chaînes aléatoires
On peut disposer de différentes API keys privées qui fournissent à la fois l'identité et
l'authentification, selon un protocole ou une opération définie : Read/ Write HTTP API
Key – Read/Write MQTT API KEY, …
Identités partagées / Fédérées

Les ID partagés sont des identités pour lesquelles plus d'une personne possède le
mot de passe ou d'autres informations d'identification, telles que les comptes root ou
administrateur. Cela suppose que vous devriez être en mesure de dire exactement
quelle personne utilisait l'ID pour tout accès (processus check-in/ check-out).

L'identité fédérée est un concept qui signifie que vous pouvez avoir des identités sur
deux systèmes différents, et les administrateurs de ces systèmes acceptent tous deux
d'utiliser des technologies qui lient ces identités ensemble afin que vous n'ayez pas à
créer manuellement des comptes distincts sur chaque système. De votre point de
vue en tant qu'utilisateur, vous n'avez qu'une seule identité.
Single Sign On (SSO)

L'authentification unique est un ensemble d'implémentations qui se basent sur le


concept d'identité fédérée.

le site Web redirige l'utilisateur vers un fournisseur d'identité centralisé (IdP) auquel
il fait confiance.
Exemples de technologies SSO :
o SAML (Security Assertion Markup Language),
la réponse est sous la forme d’une cookie
cryptée en format XML

o OIDC (OpenID Connect), utilise Json


Web Token (JWT) au lieu de XML.
Vue d’ensemble
Les six étapes

1. L'utilisateur final tente d'accéder à l'application et son accès est automatiquement


approuvé selon une identité valide. L'utilisateur final se connecte avec SSO. L'identité
est donc fédérée avec le IdP externe et l'application n'a pas à valider les mots de
passe. L'utilisateur utilise la même identité.
2. L'administrateur demande l'accès pour administrer l'application, ce qui est approuvé.
L'administrateur est alors autorisé dans un système d'autorisation centralisé.
L'autorisation peut avoir lieu dans le système IAM du cloud, ou le système IAM du
cloud peut être configuré pour demander au propre système d'autorisation interne
de l'organisation d'exécuter l'autorisation.
3. L'administrateur s'authentifie auprès du service cloud IAM à l'aide d'un mot de passe
fort et d'une authentification multifacteur et obtient un jeton d'accès à attribuer à
tout autre service. Encore une fois, facultativement, le service cloud IAM peut être
configuré pour envoyer l'utilisateur au système d'authentification interne de
l'organisation
Les six étapes (2)

4. L'administrateur envoie des demandes aux services du fournisseur de cloud, par


exemple pour créer une nouvelle machine virtuelle ou un nouveau conteneur. (En
arrière-plan, le service cloud VM demande au service cloud IAM si l'administrateur
est autorisé.)
5. L'administrateur utilise un service de fournisseur de cloud pour exécuter des
commandes sur les machines virtuelles ou les conteneurs selon les besoins. (En
arrière-plan, le service «exécuter la commande» du cloud demande au service IAM
du cloud si l'administrateur est autorisé à exécuter cette commande sur cette
machine virtuelle ou ce conteneur.) Si cette fonctionnalité n'est pas disponible
auprès d'un fournisseur de cloud particulier, l'administrateur peut utiliser une
méthode plus traditionnelle, telle que SSH, avec la machine virtuelle utilisant le
protocole LDAP pour authentifier et autoriser les administrateurs par rapport à un
annuaire d'identités.
6. Un service de gestion de « secrets » est utilisé pour conserver le mot de passe ou
la clé API permettant au serveur d'applications d'accéder au système de base de
données.
Le même processus pourrait se produire pour l'authentification entre le serveur
Web et le serveur d'applications,
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.
ECUE.3.22

Section 3. Solutions Complémentaires pour


la sécurité des Données dans le Cloud

Leçon 1. Data Security Intelligence


Détection, réponse et récupération suite à
des incidents de sécurité
Définitions
Un log (journal) , ou événement, est un enregistrement d'un élément spécifique qui
s'est produite. Par exemple, votre environnement peut générer un enregistrement
de journal chaque fois que quelqu'un s'authentifie, ou fait une demande Web, ou que
l'utilisation du processeur est élevée pendant cinq minutes, ou un certain nombre
d'autres éléments qui pourraient se produire dans un environnement complexe.
Une alerte est un type d'événement où le système décide qu'il vaut la peine d'en
informer quelqu'un. Le fait que le logiciel antivirus ait extrait les définitions mises à
jour est un événement. Le fait qu'il ait effectivement trouvé un malware devrait être
une alerte!
Les métriques sont un ensemble de chiffres qui donnent des informations sur un
élément quelconque. Les métriques sont généralement basées sur le temps, vous
pouvez donc avoir une métrique collectée chaque minute pour le nombre de
demandes d'authentification qui se sont produites, la quantité d'espace disque
disponible ou le nombre de demandes Web effectuées.
Les journaux et les métriques peuvent être utiles pour détecter les incidents de sécurité et
générer des alertes, et les métriques peuvent parfois être un meilleur choix pour alerter
lorsqu'il y a trop d'entrées de journal à traiter.
Détection des incidents de sécurité
Si vous exécutez un serveur de secrets,, vous devez superviser tous les accès aux
secrets. Voici quelques exemples d'activités inhabituelles sur lesquelles vous pouvez
alerter et enquêter:

Échecs d'authentification ou d'autorisation sur le serveur secret, ce qui peut indiquer une
attaque
Une quantité inhabituelle d'activité pour la récupération des secrets
L'utilisation des informations d'identification administratives
Etapes de détection des incidents de
sécurité
Une fois les événements et le métriques utiles collectées, Il est nécessaire de les
utiliser efficacement pour détecter et réagir aux intrusions. La figure ci-dessous
montre les différentes étapes de ce processus. Ces étapes peuvent toutes être
effectuées par un seul produit ou service, tel qu'un SIEM (Security Information and
Event Management) ou par plusieurs produits et services agissant ensemble.

agréger les
rechercher et alerter ou
journaux à un analyser les
corréler éventuellement
emplacement journaux pour
efficacement répondre à des
central et les extraire des
entre plusieurs événements
conserver (par informations
sources de importants
exemple importantes
journaux
pendant un an)

Assurez-vous que l'heure est synchronisée sur tous vos systèmes, généralement en utilisant le
Network Time Protocol (NTP)
Security Information and Event Managers
Les règles d’intelligence d’un SIEM peuvent être utilisées pour détecter un
mauvais comportement potentiel, parfois en corrélant des événements
survenus à deux endroits différents ou en comparant des données actuelles
et historiques.
Exemples:
o Le trafic de base de données a augmenté de 200% par rapport à la moyenne mensuelle. Peut-
être que l'application est vraiment très populaire en ce moment, mais quelqu'un vole-t-il
systématiquement nos données?
o Il y a eu 150 tentatives de connexion infructueuses sur un compte, suivies d'un succès. Est-ce une
attaque réussie par force brute?
o Nous avons vu une seule tentative de connexion échouée sur 300 comptes différents, suivie d'un
succès sur le compte # 301. Est-ce une attaque par pulvérisation de mots de passe réussie?
o John ne se connecte pas normalement à 3 h 00 HE, ni depuis ce pays. Peut-être que ce n'est pas
vraiment John?
o Trois comptes différents se sont connectés à partir du même système en 30 minutes. Il semble
peu probable que toutes ces personnes utilisent réellement ce système, alors peut-être que le
système et ces comptes sont compromis? »
o Un nouveau compte administratif vient d'être créé en dehors des heures normales de bureau.
Peut-être que quelqu'un travaille tard, mais peut-être qu'il y a un problème?
Exemples d'outils de détection, de réponse et
de récupération
Amazon GuardDuty peut rechercher une activité inhabituelle ou suspecte dans votre
compte ou vos systèmes AWS.
Amazon CloudWatch Logs, Azure Monitor, Google Stackdriver Logging et IBM Cloud Log
Analytics vous permettent tous de stocker et de rechercher dans vos journaux.
Amazon CloudWatch, Azure Monitor, Google Stackdriver Monitoring et IBM Cloud
Monitoring fournissent des mesures de performances.
AWS CloudTrail, Azure Monitor et IBM Cloud Activity Tracker peuvent surveiller l'activité
des utilisateurs privilégiés dans les comptes cloud.
Azure Security Center peut collecter des données de sécurité dans un emplacement
central, ainsi que la surveillance de l'intégrité des fichiers et d'autres fonctions de sécurité.
Cisco, McAfee et Snort sont des fournisseurs de services de détection d'intrusion réseau
populaires qui disposent d'appliances basées sur le cloud.
CloudFlare, Akamai et Signal Sciences fournissent des solutions de pare-feu d'applications
Web basées sur le cloud.
OSSEC, Tripwire, AIDE, NT Change Tracker, CloudPassage Halo, Qualys fournissent des
solutions de surveillance d'intégrité de fichiers traditionnelles ou basées sur le cloud.
Les SIEM tels qu'IBM QRadar, Splunk Security Intelligence Platform, LogRhythm collectent
les événements de journal, les analysent et déclenchent des alertes.
QRadar – User Bahavior Analytics
QRadar – Discovering Shadow IT
CASB (Cloud Access Security Broker)
En raison du risque de fuite de données dans le cloud, l'utilisation de CASB est
nécessaire afin de maintenir la visibilité sur les données qui ont dépassé la portée
des outils on-premise.

Journaux d'activité
En ce qui concerne les données sensibles, une organisation doit
avoir une visibilité et des connaissances complètes sur la façon
dont elles sont utilisées. Les CASB fournissent des journaux
détaillés sur toutes les transactions cloud, de sorte que toutes
les connexions ou téléchargements sont toujours enregistrés.
Les comportements spécifiques aux applications tels que le
partage de fichiers externes sont également consignés, aidant
les organisations à savoir où se trouvent les données si elles
sont partagées. Ces journaux permettent également aux
équipes informatiques de les filtrer afin d'avoir plus de visibilité
sur l'activité au sein de l'entreprise.
CASB (2)
Shadow IT
Egalement connu sous le nom « d'applications non sanctionnées», est classé en
fonction du risque - permettant aux organisations de décider ce qui doit être
bloqué. Certains CASB plus traditionnels concentrent leurs ressources sur la
détection et le catalogage manuels des applications cloud non autorisées. Cela se
fait généralement par le biais d'équipes de personnes qui parcourent Internet pour
évaluer de manière réactive les applications lorsqu'elles se présentent ou sont
mises à jour. D'autres CASB se concentrent sur la création d'un système qui
détecte, examine et classe automatiquement toute application. Ce système
automatisé, appelé Zero-day Shadow IT Discovery, utilise une approche
d'apprentissage automatique pour évaluer les applications à la volée.
CASB (3)
CSPM
la gestion de la posture de sécurité dans le cloud (CSPM: cloud security posture
management) détecte les mauvaises configurations IaaS, qui nécessitent souvent des
configurations étendues afin de s'assurer qu'elles fonctionnent correctement. Avoir
une posture de sécurité cloud solide sur ces plateformes est une étape critique
pour éviter les fuites de données. Les solutions de stockage, comme AWS par
exemple, doivent être configurées correctement, sinon elles peuvent rendre les
données sensibles accessibles au public. C'est précisément ce qui s'est produit lors
de la violation de Capital One.

Les organisations utilisant CSPM permettent d'identifier et de corriger les erreurs


de configuration.
CASB (4)
Protection des données au-delà du pare-feu
Si quelqu'un sur un appareil non géré se connecte à Office 365 via wifi depuis un
café, quel produit de sécurité dans votre pile protège cette session? Si vous êtes
perdu, vous n'êtes pas seul.

Avec l'introduction du cloud dans nos environnements d'entreprise, les employés


accèdent désormais aux données de l'entreprise en dehors des quatre murs du
bureau avec des applications comme Office 365, GSuite, Box, Salesforce, etc. Les
CASB sont architecturés pour garantir la sécurité de n'importe quelle application,
n'importe où
Utilisateurs malveillants
Les CASB permettent la détection et la correction des logiciels malveillants, le géo-
repérage, le chiffrement des données, la gestion des sessions, …
CASB (5)
Bring Your Own Device - BYOD
Une fois que les employés ont découvert
à quel point il était facile d'accéder aux
informations de leur entreprise à partir du
cloud, ils ont commencé à le faire à partir
de leurs propres appareils personnels
(ordinateurs portables, smartphones,
tablettes, etc.). Alors que de nombreuses
organisations souhaitent offrir de la
flexibilité et permettre aux employés de
travailler à partir de n'importe quel
appareil, elles frémissent à l'idée d'une
synchronisation des données d'entreprise
sensibles vers un appareil personnel
totalement non géré (et potentiellement
non sécurisé ou compromis). Une fois que
les informations se trouvent sur l'appareil
de l'utilisateur, il devient très difficile
d'avoir un contrôle – d’où le CASB.
ECUE.3.22

Section 3. Solutions Complémentaires pour


la sécurité des Données dans le Cloud

Leçon 2. Data Security Compliance & Regulations


Les principaux référentiels pour la conformité
de la sécurité des données dans le Cloud
Source : https://cloud.google.com/security/compliance/?hl=fr#/

FIPS 140-2 U.S. government computer security standard


ISO 27017 Controlling cloud-based information security.
ISO 27018 Protecting personal data
PCI DSS Protecting customers’ card information.
HIPAA Protecting health information
GDPR EU data protection laws
MPAA Protecting intellectual property data
NIST 800-53 Security and privacy requirements for United States Federal information
systems

La liste est loin d’autre exhaustive …


FIPS (Federal Information Processing
Standard)
L’acronyme FIPS renvoie à « Federal Information Processing Standards » (normes
fédérales de traitement de l’information). La série de normes FIPS 140 correspond aux
normes de sécurité informatique établies par le National Institute of Standards &
Technology (NIST) pour le gouvernement des États-Unis.
Les normes FIPS 140-2 portent plus particulièrement sur les clés de cryptage et leur
protection physique. Quelques termes essentiels :
o Paramètre de sécurité critique (PSC) – les CSP comprennent les informations relatives à
la sécurité, dont la modification ou la divulgation peuvent compromettre la sécurité d’un
module cryptographique.
o Critères communs (CC) – Également connus sous l’appellation Common Criteria for
Information Technology Security Evaluation (Critères communs pour l’évaluation de la sécurité
informatique). Sert de base technique pour le Common Criteria Recognition Arrangement
(CCRA), une entente internationale assurant que les produits de sécurité sont adéquatement
testés par des laboratoires agréés indépendants.

Source:https://www.xmedius.com/fr/blogue/que-signifie-la-conformite-aux-normes-fips-140-2/
FIPS (2)
La série FIPS 140 consiste en un ensemble d’exigences et de normes relatives aux
modules cryptographiques pour des composants tant matériels que logiciels utilisés par
les départements et les agences du gouvernement des États-Unis.
Les normes FIPS 140-2 constituent le deuxième et le plus actuel des ensembles de
normes FIPS 140 publiés par le NIST. Diffusées le 25 mai 2001, les normes FIPS 140-2
étendent la portée des normes FIPS 140-1 (diffusées le 11 janvier 1994), tirent parti des
niveaux d’assurance d’évaluation (EAL) des critères communs (CC) [Common Criteria
(Evaluation Assurance Levels] pour déterminer le niveau de sécurité, et prennent en
compte les commentaires de la communauté, ainsi que les nouveaux développements
en matière de technologie et d’informatique depuis 1994.
Il est important de noter que bien que ces éléments portent sur les normes de
cryptographie et de sécurité pour le matériel et les logiciels, la conformité d’un produit
donné aux normes FIPS 140-2 n’en garantit pas la sécurité. Les normes FIPS 140-2 ne
visent à s’appliquer qu’aux modules cryptographiques interagissant avec des charges de
travail gérant des informations confidentiels, mais non classées (SBU)
FIPS (3)
Les critères communs (Common Criteria) établissent sept niveaux différents
d’assurance d’évaluation (EAL), nommés EAL1 à EAL7. Il est aussi courant de voir un
signe « + » en regard d’un EAL donné (p. ex., EAL5+) pour signifier qu’un dispositif
donné respecte les critères au-delà du minimum pour un EAL donné. Puisque le niveau
le plus élevé prévu par les normes FIPS 140-2 ne requiert qu’un niveau de
sécurité EAL4, nous ne discuterons que des niveaux EAL1 à EAL4.
FIPS (4)
FIPS 140-2 – Niveau 1

Le niveau le plus bas des exigences de sécurité relatives à un module cryptographique


donné. Le premier niveau de sécurité ne nécessite aucun mécanisme de sécurité
physique au-delà des exigences de base pour des composants de production et permet
à un module cryptographique d’être exécuté sur un ordinateur d’usage général à l’aide
d’un système d’exploitation non évalué.
Un exemple de module cryptographique de niveau de sécurité 1 est un tableau de
cryptage sur un ordinateur personnel (PC).
FIPS (5)
FIPS 140-2 – Niveau 2

Le deuxième niveau de sécurité prolonge le niveau 1 en y ajoutant trois


exigences principales :
Preuve d’altération des modules cryptographiques : Cela peut inclure
des revêtements, des sceaux ou des serrures sécurisées révélant les tentatives
d’altération. Les mesures permettant de révéler les tentatives d’altération
doivent être appliquées de manière que les sceaux et (ou) revêtements doivent
être brisés pour pouvoir accéder physiquement aux clés cryptographiques en
texte clair et aux paramètres de sécurité critiques (CSP).
Authentification fondée sur le rôle : L’exigence de sécurité minimum de
niveau 2 stipule qu’un utilisateur donné doit être associé à un rôle spécifique et
à un niveau d’autorisation authentifiés par le module cryptographique.
Exigences de système d’exploitation : Le niveau de sécurité 2 permet à un
module cryptographique d’être exécuté sur un PC d’usage général tournant sur
un système d’exploitation fiable, approuvé ou évalué. Les systèmes
d’exploitation doivent être évalués au niveau d’assurance d’évaluation des
critères communs EAL2 ou plus.
FIPS (6)
FIPS 140-2 – Niveau 3
Les exigences de sécurité établies par le niveau 3, ajoutent à celles du niveau 2, quatre
domaines principaux :
Prévention des intrusions : Allant au-delà des mesures de preuve d’altération du niveau de sécurité 2, le niveau
de sécurité 3 exige des mécanismes de sécurité physique conçus pour empêcher tout intrus d’accéder aux CSP au
sein du module cryptographique. Ces mécanismes offrent de fortes probabilités de détecter toute tentative d’accès
au module cryptographique ou d’altération ou d’utilisation de celui-ci, et d’y réagir. Parmi les exemples de
mécanismes de ce genre, on compte les boitiers robustes et des circuits conçus pour mettre à zéros (effacer) les
CSP en texte clair lorsqu’une tentative est faite d’altérer le module cryptographique.
Authentification fondée sur l’identité : Constituant une méthode d’authentification plus fine, l’authentification
fondée sur l’identité permet d’améliorer l’exigence relative à l’authentification du niveau de sécurité 2. Cela est
accompli en vérifiant l’identité d’un utilisateur donné plutôt que d’authentifier le rôle de celui-ci. Un exemple de
cette différence serait un réseau qui exige des identifiants spécifiques à l’utilisateur, au lieu d’un réseau qui détient
des comptes d’utilisateur général ou invité en plus d’un compte générique d’administrateur.
Séparation physique (ou logique) : Pour se conformer au niveau de sécurité 3, l’entrée ou la sortie de CSP en
texte clair doivent être faites à l’aide de ports qui sont physiquement séparés des autres ports (ou à l’aide
d’interfaces logiquement séparées, s’il s’agit d’un environnement virtuel). Les CSP en texte clair doivent être entrés
dans le module cryptographique, ou en sortir par le biais d’un système de boîtier ou capable d’intervenir en cas de
tentative d’altération seulement s’ils sont sous forme cryptée.
Exigences de système d’exploitation : Tout comme le niveau de sécurité 2, le niveau de sécurité 3 permet à un
module cryptographique donné d’être exécuté sur un PC d’usage général tournant sur un système d’exploitation
respectant les exigences minimales. Les exigences pour le niveau de sécurité 3 sont plus rigoureuses que celles pour
le niveau 2 et comprennent une assurance d’évaluation des CC de niveau EAL3 ou plus élevé.
FIPS (7)
FIPS 140-2 – Niveau 4
Des quatre niveaux de sécurité prévus par les normes FIPS 140-2, le niveau de sécurité 4 est le
plus élevé et est idéal pour les modules cryptographiques tournant dans des environnements
physiquement non protégés. Pour avoir une idée de ce qui constitue un environnement
physiquement non protégé, il faut penser à tout lieu où des informations ou des communications
gouvernementales peuvent être traitées ou stockées, ou par lequel celles-ci transitent, comme les
satellites ou les véhicules aériens sans pilote. L’intention du niveau de sécurité 4 consiste à assurer
que des mécanismes physiques de sécurité sont complètement enveloppés et protègent le module
cryptographique de toute tentative non autorisée d’y accéder physiquement. Ces mécanismes
doivent fournir une forte probabilité de détecter une intrusion et doivent être conçus de manière
à immédiatement remettre à zéros les CSP en texte clair dans le cas où une intrusion est détectée.
Pour être conforme au niveau de sécurité 4 des normes FIPS 140-2, un module cryptographique
donné doit également être protégé contre des conditions environnementales qui pourraient
soumettre le module à des paramètres hors des limites normales auxquelles il est supposé
fonctionner. Il est courant que des intrus potentiels poussent un module cryptographique à des
températures ou à des voltages qui en compromettent la sécurité. Parmi les exemples, on peut
citer le chauffage ou le refroidissement extrêmes de l’enceinte du module dans le but de la
fragiliser (pensez à l’espion dans les films, qui verse de l’azote liquide sur une serrure pour la faire
geler et la casser).
FIPS (8)
FIPS 140-2 – Niveau 4 –suite
La protection environnementale peut prendre la forme de fonctionnalités qui remettent à
zéro les CSP si le module cryptographique détecte des fluctuations de paramètres hors de la
gamme des valeurs de fonctionnement normal. En reprenant l’exemple ci-dessus, si l’espion
dans les films faisait geler une serrure pour la briser afin d’accéder à un module
cryptographique, les mesures de protection environnementale détecteraient que la serrure
est soumise à des températures bien au-dessous du seuil acceptable et effaceraient le module.
Cela rendrait le module inutilisable par l’espion, même si celui-ci finissait par y accéder.
Autrement, l’exigence de protection environnementale peut être remplie par le biais d’une
garantie raisonnable que les fluctuations des paramètres en dehors de la plage de
fonctionnement normales ne compromettent pas la sécurité du module.
Tout comme les niveaux de sécurité 2 et 3, le niveau de sécurité 4 exige également que le
système d’exploitation respecte un certain niveau d’assurance d’évaluation des CC. Pour
qu’un module cryptographique puisse être considéré conforme au niveau de sécurité 4 établi
dans les normes FIPS 140-2, le système d’exploitation sur lequel il tourne doit avoir reçu une
assurance d’évaluation des CC de niveau EAL4 ou plus élevé.
ISO 27017
Contrôle de la sécurité de l'information dans le cloud

La norme ISO/CEI 27017 donne des consignes sur les contrôles de sécurité des
informations applicables dans le cadre de la fourniture et de l'utilisation des services
cloud à l'aide :
o d'instructions supplémentaires relatives à l'intégration des contrôles pertinents spécifiés
dans la norme ISO/CEI 27002 ;
o de contrôles supplémentaires avec des instructions relatives à l'intégration spécifiquement
en lien avec les services cloud.

La norme ISO 27017 fournit des conseils en matière de cloud relatifs à 37 des contrôles
décrits dans la norme ISO 27002. Elle présente également sept nouveaux contrôles cloud
abordant les sujets suivants :
o Partage de la responsabilité entre le fournisseur de services cloud et son client
o Suppression/Restitution des ressources au moment de la résiliation d'un contrat
o Protection et séparation de l'environnement virtuel du client
o Configuration des machines virtuelles
o Opérations et procédures administratives associées à l'environnement cloud
o Surveillance de la part du client de l'activité dans le cloud
o Alignement des environnements réseau cloud et virtuel
ISO 27017 (2)

Source:
https://www.bsigroup.com/LocalFiles/fr-fr/iso-iec-27001/ressources/BSI%20-
%20Pr%C3%A9sentation%20l'ISO%2027018%20%20ISO%2027017%20Par%20Fran%C3%A7ois%20Lorek.pdf
ISO 27018
Protection des données à caractère personnel

La norme ISO 27018 est associée à la protection des informations personnelles et


concerne de ce fait l'un des composants les plus critiques du cloud : la confidentialité.

Elle se concentre sur les contrôles de sécurité concernant les fournisseurs de services
cloud publics agissant en tant que sous-traitants d'informations personnelles.

La norme ISO 27018 opère de deux manières :


o Elle s'appuie sur les contrôles existants de la norme ISO 27002 avec des éléments
spécifiques liés à la confidentialité dans le cloud.
o Elle fournit de tout nouveaux contrôles de sécurité relatifs aux données à caractère
personnel.
ISO 27018

Source:
https://www.bsigroup.com/LocalFiles/fr-fr/iso-iec-27001/ressources/BSI%20-
%20Pr%C3%A9sentation%20l'ISO%2027018%20%20ISO%2027017%20Par%20Fran%C3%A7ois%20Lorek.pdf
Règlement général sur la protection des
données (RGPD)

Entré en vigueur le 25 mai 2018, il permet d’encadrer le traitement et la circulation des


données à caractère personnel sur le territoire de l’union européenne.
Le RGPD est né de la volonté européenne de créer un cadre juridique unifié, afin de faire face
aux enjeux majeurs que représente le traitement de données personnelles.
Une donnée personnelle est définie par la CNIL comme « toute information se rapportant à
une personne physique identifiée ou identifiable ».
o L’identification peut se faire de manière directe (nom, prénom, adresse postale) ou de manière
indirecte (éléments physiques, identifiant, adresse IP, numéro).
o Sont également considérées comme personnelles les données qui, par le recoupement de
plusieurs informations, (date de naissance, sexe, ville, diplôme, etc.) ou l'utilisation de divers
moyens techniques, permettent d'identifier une personne.

Source : https://www.juritravail.com/Actualite/protection-donnees-rgpd/Id/286054
RGPD (2)
Selon l’article 5.1 du RGPD, les données personnelles doivent être :
o Traitées de manière licite, loyale et transparente ;
o Collectées à des fins déterminée, explicite et légitimes ;
o Adéquates, pertinentes et limitées ;
o Exactes et tenues à jour ;
o Conservées pendant une durée raisonnable ;
o Traitées de façon à garantir leur protection.
RGPD (3)
Les personnes concernées bénéficient de nombreux droits :
o Droit d’accès : droit pour la personne concernée d’obtenir du responsable de traitement la
confirmation que des données personnelles sont ou ne sont pas traitées et lorsqu'elles le sont, l'accès
auxdites données ainsi qu’aux informations la concernant. L’entreprise dispose ensuite d’un délai d’un
mois pour accéder à la demande de la personne concernée.
o Droit de rectification : droit pour la personne concernée d’obtenir du responsable du traitement,
dans les meilleurs délais, la rectification des données inexactes la concernant.
o Droit d’opposition : droit pour la personne concernée de s'opposer, pour des raisons tenant à sa
situation particulière, à un traitement des données personnelles la concernant.
o Droit d’effacement (droit à l’oubli) : droit pour la personne concernée d’obtenir du responsable du
traitement l’effacement, dans les meilleurs délais, des données personnelles la concernant.
o Droit à la portabilité : droit pour la personne concernée d’obtenir et de réutiliser les données la
concernant pour ses besoins personnels.
o Droit à la limitation du traitement : droit pour la personne concernée d’interdire au responsable du
traitement de se servir de certaines données collectées.

Vous aimerez peut-être aussi