IBM Cloud Forum

20 novembre 2019New Cap Event Center, Paris

Cloud Forum / @ 2019 IBM Corporation

Sécuriser votre environnement Cloud10h30 – 11h15

2 11/22/19

Laurent BrotoCloud Security Competency Leader

IBM

3 11/22/19

Pourquoi la sécurité du Cloud ?

Responsabilité partagée• Transparence limitée

• Plateformes propriétaires

• Plateformes multiples

Architectures émergentes• Micro-services

• Fonctionnalités API-driven

• Containers

Modèle d’opérations

• Agile

• DevOps

• Instances « immutables »

• Infrastructure as code

Implications en terme de sécurité• Sécuriser et administrer plusieurs

plateformes• Comprendre les fonctionnalités

intégrées et choisir les outils complémentaires

• Sécuriser la data dans différents environnements

• Intégrer la sécurité dans des environnements dynamiques

• Gérer la gouvernance avec son (ses) fournisseur(s) de cloud

• …

4 11/22/19

Périmètres de responsabilité

5 11/22/19

Domaines de sécurisation Agenda

Les mêmes que dans les environnements standards avec des outils et des problématiques différentes :• La gestion des Assets• Chiffrement• IAM• Le réseau• La sécurité des containers• Détection

• Sécurisation des différents domaines• « CloudPak for Security »• Présentation des sessions suivantes

6 11/22/19

La gestion des assets• Ce qui diffère par rapport à de l’IT standard

• Généralement, pas de gestion des assets physiques (CCTV, slab-to-slab, tailgating, …)• Plus de flexibilité pour créer des assets• Processus déplacés ( « Capacity Planning », …)• Le CSP tient à jour l’inventaire de certains assets (besoin de facturation !)

• On distingue plusieurs types d’assets• Assets de calculs : VM, containers, orchestrateurs, …• Assets de stockage : stockage d’image, stockage block, stockage fichiers, DB, …• Assets réseau : VPC, certificats, loads balancer, …

• On se sert de tags• Fonction, environnement, application supportée, version réglementation applicable, …

• Ces tags pourront être réutilisés par des scripts / applications pour traiter que certains assets

7 11/22/19

Le chiffrement sur le Cloud• Ce qui diffère par rapport à de l’IT standard

• Les opérations de chiffrement et déchiffrement sont effectuées par le CSP• Plusieurs type de chiffrement

• « at rest » : protection contre le vol d’un disque• « at motion » : protection pendant le transfert de données• « in use » : protection pendant l’utilisation (Intel SGX, AMD SME, …)

• La gestion des clés (BYOK)• Les CSP fournissent un KMS (Key Management System) adossés ou non à un HSM• Gestion simple des clés :

• Stockage d’un clé qui servira aux opérations de chiffrement dé-chiffrement• « cloud ready »

• Gestion avancée des clés : « envelop encryption »• Système de wrapping de clé à décrit dans le slide suivant• Permet le « crypto shredding »

• D’autres techniques : « tokenisation », …

8 11/22/19

Le chiffrement dans IBM Cloud

Cloud Object Storage Block Storage

Data services

1 2 3 21

Key Management Kernel(CRK key rotation / CRK key deletion)

Key ProtectWrapped instance

Key Encryption Key (KEK=CRK)

Man

aged

by

Serv

ices

Man

aged

by K

ey P

rote

ct

Services Responsible for storing the wrapped Data Encryption Keys (DEK)• Services store wrapped DEKs (wDEK) with the Data (envelope encryption).• Anytime a service needs to access encrypted Data, it contacts Key Protect for a DEK.• Service will also send the reference of the Customer Root Key along with the wrapped DEK.

Each Customer can bring multiple Customer Root Keys (CRK)• CRK is the key encryption key to wrap/unwrap (encrypt/decrypt) the DEK.• Key Protect retrieves the wrapped CRK (wCRK) from the Database and sends the wCRK

and wDEK to the HSM.• The wrapped CRK (wCRK) are managed by Key Protect and stored within a database.• CRK is the Key Encryption Key that is never stored or processed in clear outside the HSM.• Customer can upload multiple CRKs.• Key Protect provides a secure mechanism for the customers to upload the CRK (by API

with a transport key : a 4096-bit, DER encoded public encryption key in PKIX format that you can use to encrypt your CRK key material).

Hardware Security Module

Wrapped CRK DB

Rest API

PKCS #11One Master Key Encryption Key (MKEK)• HSM sends the clear DEK back to Key Protect.• MKEK is the key encryption key to wrap/unwrap (encrypt/decrypt) the CRK.• Can't be extracted out of HSM.• Key is synchronized across all the HSM in a region.

9 11/22/19

L’IAM• Ce qui différe par rapport à de l’IT standard

• Plus de contrôle physique (entrée dans les bâtiments)• Beaucoup d’asset cloud peuvent être configurée comme publiques d’un clic ! (bucket, …)

• Plusieurs niveaux d’authentification gérées par le CSP• Business to CSP (Cloud IAM : accès des employés au Cloud)• Business to customers (accès des clients aux applications hébergées sur le Cloud)• Business to employees (accès des employés aux applications)

• Autorisations gérées par le CSP• Gestion des rôles, des groupes

• Gestion des identités facilités généralement portée par le CSP• Facilités de déploiement SSO, 2FA, …• Un seul endroit pour gérer toutes les autorisation et les authentifications• Unification des mécanismes d’authentification et d’autorisations• Couplage automatique aux systèmes de gestion des certificats, de « secret management »

…

10 11/22/19

Le réseau• Ce qui diffère par rapport à de l’IT standard

• Difficultés pour définir les zones• « Gratuité » du réseau

• Les mêmes (bonnes) pratiques s’appliquent dans le cloud• Bastion, DMZ, VPN, WAF, …• Avec des notions un peu différentes : VPC, ACL, Security Groups• Plus simplement (déploiement facilité, WAF as a service, DDOS as a service, …)

• Problématiques de cloud hybride et multi-cloud• Micro-segmentation de niveau OS peut aider• « Cloud-ready »

11 11/22/19

La sécurité des containers• Ce qui diffère par rapport à de l’IT standard

• Dans le cadre du DevOps, la sortie du pipeline peut être directement accessible publiquement

• Protection à plusieurs niveaux• D’autres techniques liées

• API management• Scan de vulnérabilités• …

12 11/22/19

La détection• Ce qui diffère par rapport à de l’IT standard

• Diversité des techniques à diversité des formats de logs• Réunification des « puits de logs » dans une approche « cloud ready »• Logs récupérés seulement sur le périmètre de responsabilité du client

• Les logs peuvent être traités à différents endroits :• Vers un agrégateur de log (souvent fourni par le CSP)• Vers un SIEM (« On premise » ou as a service (Qradar On Cloud))

• A travers l’intégrateur de log. Dans ce cas, attention au format des logs !• Vers un SOC

• Use-cases de détection supplémentaires• Surveillance du portail de connexion (Qui ? Où ? Quand ?)• Surveillance de la création / configuration / suppression d’objets cloud

• Pour certains incidents, la réponse devra être coordonnée avec le CSP (DDOS, failles sur le cloud lui-même, …)

13 11/22/19

IBM Cloud Pak for Security (CP4S)

AppDev framework

Unified Interface

Threat managementThreat huntingInsider threat

Data securityPrivacy complianceRisk assessment

Cloud workload protectionIncident responseIdentity and access

Hybrid multicloudarchitecture

Composable security solutions

Open integration with existing security tools

Security Orchestration & AutomationUniversal data service | |

Open Hybrid Multicloud Platform

14 11/22/19

Sessions suivantes sur la sécurité

• Aligner les pratiques DevOps et Sécurité sur le Coud• Présentation d’une solution permettant la sécurisation des containers dans le cadre d’un

environnement (sec)devops• Comment maitriser ses flux dans un environnement hybride dynamique en constante

évolution ?• Présentation d’une solution de micro-segmentation dans le cadre d’un environnement

cloud Hybride

15 11/22/19

Questions

laurent.broto@fr.ibm.com

CEHBU Securité, IBM France