"Sécurisons nos nuages : virtualisation, cloud, microservices, conteneurs"

1. Commission sécurité & cloud
Sécurisons nos Nuages
Virtualisation ⩫ Cloud ⩫ Microservices ⩫ Conteneurs
Serge Hartmann serge.hartmann@gmail.com
Telecom Valley
présente
ou 6 Février de l’An 2018le 18 Pluviôse de l’An CCXXVI

2. rétrospective : adoption du cloud
ref : 2017 Internet Security Threat Symantec Report
leurs dirigeants pensent
qu’il n’y en a que 30 à 40

3. rétrospective : clouds publics
ref : RightScale 2017 State of the Cloud Report

4. rétrospective : objectifs pour cette année
ref : RightScale 2017 State of the Cloud Report
expertise, ressources
sécurité
maîtrise des coûts
conformité
gouvernance et contrôle
exploiter des services multi-clouds
mettre en place un cloud privé
gagner en performance
en pourcentage d’entreprises utilisatrices du cloud

5. rétrospective : budget sécurité
ref : Cloud Security 2017 Spotlight Report

6. rétrospective : exploitation des
mobiles par les “cloud botnets”
75% des apps échouent aux tests basiques de sécurité
75% ne chiffrent pas les données PII stockées
localement
97% accèdent à des PII sans sécurité appropriée
75% des attaques exploitent des applications mal
développées
76% des smartphones n’ont pas leur OS à jour
90% des employés utilisent leur smartphone au travail
PII : Personally identifiable information
BYOD : Bring Your Own Device ref : Gartner Report, 2016
heureusement...

7. A third benefit is in virtual space, information can be moved
around the network, Lynn said. “If you move them around the
network, it’s hard to attack it,” he said “That’s when defense
really starts kicking in.”
Security of information on the cloud is No. 1, the general said.
“We have the best security apparatus that tears through an
attack that’s happening before it gets down to the user level,”
he explained.
Le troisième avantage se situe dans l'espace
virtuel : l'information peut être déplacée
autour du réseau, a déclaré Lynn. «Si vous
les distribuez sur tout le réseau, il est
difficile de les attaquer», a-t-il dit. “C'est à ce
moment que la défense commence
vraiment à entrer en action”.
La sécurité des informations dans le cloud
est la priorité, a déclaré le général. “Nous
avons le meilleur des dispositifs de sécurité,
il neutralise une attaque avant qu’elle
n'arrive au niveau de l'utilisateur”, a-t-il
expliqué.
Defense Department to Move to Cloud Computing, 21/12/2017
DOD looks to get aggressive about cloud adoption, 20/09/2017
traduction

8. ref: Russians Lead the Quantum Computer Race With 51-Qubit Machine, 28/8/2017
Google’s New Chip Is a Stepping Stone to Quantum Computing Supremacy, 21/4/2017
Google Reveals Blueprint for Quantum Supremacy, 4/10/2017
Cryptology ePrint Archive: Report 2017/351, 21/4/2017
So one way to achieve quantum supremacy is to
create a system that can support 49 qubits in a
superposition of states. This system doesn’t need to
perform any complex calculations—it just needs to
be able to explore the entire space of a 49-qubit
superposition reliably. So Neill and Roushan’s goal is
to create a 49-qubit superposition.
Cryptology ePrint Archive: Report 2017/351
Post-quantum RSA
Daniel J. Bernstein and Nadia Heninger and Paul Lou and Luke Valenta
Abstract: This paper proposes RSA parameters for which (1) key generation, encryption,
decryption, signing, and verification are feasible on today's computers while (2) all known
attacks are infeasible, even assuming highly scalable quantum computers. As part of the
performance analysis, this paper introduces a new algorithm to generate a batch of
primes. As part of the attack analysis, this paper introduces a new quantum factorization
algorithm that is often much faster than Shor's algorithm and much faster than
pre-quantum factorization algorithms. Initial pqRSA implementation results are provided.
Category / Keywords: public-key cryptography / post-quantum cryptography, RSA
scalability, Shor's algorithm, ECM, Grover's algorithm, Make RSA Great Again
Original Publication (in the same form): PQCrypto 2017
Date: received 19 Apr 2017
Contact author: authorcontact-pqrsa at box cr yp to
Available format(s): PDF | BibTeX Citation
Version: 20170426:172322 (All versions of this report)
Short URL: ia.cr/2017/351

9. rétrospective : CVEs
refs : CVE details, vulnerabilities by date, 5/2/2018
VulnDB Totql Vulnerabilities, 5/2/2018

10. lingua hoc anno MMXVIII in nubibus
● data in flight ; data at rest
● secret data ; sensitive data
● multi tenant
● on premise
● object storage
● CaaS
● BYOD / CORP / CYOD / COPE
● kill switch
● feature masking ; feature toggle
CaaS : Container as a Service
BYOD : Bring Your Own Device
CORP : Corporate
CYOD : Choose Your Own Device
COPE : Corporate Owned & Personally Enabled
Saint Cloud
605 ♰ 697
ref : Europol: There's no kill switch for malware attack, juin 2017

11. Interlude
La bicyclette de sécurité
du Docteur Lawson
Serge Hartmann serge.hartmann@gmail.com

12. ce mot de passe
serait bien meilleur
haché avec une
pincée de sel
à ce propos : les sandwiches
sont bien là ; courage, encore
quelques minutes à tenir

13. Fin de l’interlude
Serge Hartmann serge.hartmann@gmail.com

14. revenons à notre nuage

15. traditionnel
sur site
données
application
base de
données
OS
virtualisation
machine
physique
stockage
réseau
salle
machines
fonction
IaaS
infrastructure
données
application
base de
données
OS
virtualisation
machine
physique
stockage
réseau
salle
machines
fonction
PaaS
plateforme
données
orches-
trateur
OS
virtualisation
machine
physique
stockage
réseau
salle
machines
fonction
CaaS
conteneur
données
conteneur
orches-
trateur
OS
virtualisation
machine
physique
stockage
réseau
salle
machines
fonction
application
FaaS
fonction
données
runtime
orches-
trateur
OS
virtualisation
machine
physique
stockage
réseau
salle
machines
fonction
SaaS
software
données
application
orches-
trateur
OS
virtualisation
machine
physique
stockage
réseau
salle
machines
fonction
application
le cloud vu par le DSI

16. partage de responsabilité :
1. le fournisseur de l’infrastructure
sécurité du cloud
● accès aux salles
● infra systèmes et réseaux
● cycle de vie des serveurs
● transparence sur les logiciels et OS proposés
● garanties légales, iso27018, localisation des données
● authentification sur les utilisateurs de l’infrastructure et données associées
● chiffrement côté serveur et réseau pour le stockage objet
● logs de l’infrastructure et des accès API/admin (CloudTrail)
● protection DDoS, IP spoofing, port scanning, et autres mesures généralisables
DDoS : Distributed Denial of Service

17. partage de responsabilité :
2. l’utilisateur de l’infrastructure
sécurité dans le cloud
● choix des systèmes et dépendances
● correctifs sécurité dans son périmètre (IaaS, PaaS)
● configurations applicatives
● gestion d’accès, authentification, autorisation, RBAC
● groupes de sécurité, ACLs
● logs applicatifs
● détection des comportements anormaux
● tests d’intrusion et de vulnérabilités - à signaler préalablement, et si autorisés
ACL : Access Control List
RBAC : Role Based Access Control

18. sécuriser l’accès admin et dev au cloud
clefs ssh fortes + jetons à durée limitée + RBAC + au choix :
● solution de l’hébergeur cloud + interfaçage avec l’IAM privé
● IAM centralisé privé avec miroir ro accessible depuis le cloud
● VPN / IPsec entre le réseau privé et le fournisseur cloud
● système à bastions + ansible user_module sur les instances
● gestion d’accès séparée avec mots de passe forts, MFA et OTP
MFA : Multiple Factor Authentication
OTP : One-Time Password
IAM : Identity and Access Management
VPN : Virtual Private Network
RBAC : Role-Based Access Control
ACL : Access Control Lists
RBAC
ACL
gestionnaire de jetons
et de clefs publiques
dédié aux accès admin
APIs
shell
internet ou VPN
cloud public
administrateur
réseau privé

19. le cloud vu par l’attaquant
Denis Makrushin - The cost of launching a DDoS attack, 2017
John Lambert, Defenders think in lists. Attackers think in graphs. Attackers win, 2015

20. virtualisation, cloud, microservices, conteneurs
● premiers ordinateurs : gèrent un seul traitement
● OS : permet d’orchestrer plusieurs programmes
● 1963 : les processus isolent les programmes avec leurs dépendances (libs), droits,
ressources, priorités
● 1983 : init / PID1
PID : Process IDentifier
# ps -p1 u
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 43476 3888 ? Ss Jan31 0:02 /usr/lib/systemd/systemd --switched-root --system --deserialize 21
refs: Quentin Adam, Clever-Cloud, 2017

21. ● 1979 : chroot
○ droits pour créer le chroot et son
environnement (mount/(r)bind)
○ pas de gestion des ressources
○ ces droits permettent un chroot à la
racine (zut)
○ élévation de privilèges
PID : Process IDentifier refs: Quentin Adam, Clever-Cloud, 2017
/# ls /
bin dev home lib64 media opt root
sbin sys usr var srv tmp run
boot etc lib lost+found mnt proc truc
/#
/# touch /truc/MACHIN
/# cd /truc
truc/# mount -t proc proc proc
truc/# mount --rbind /sys sys
truc/# mount --rbind /dev dev
truc/# mount --rbind /usr usr
truc/# mount --rbind /bin bin
truc/# chroot /truc
#
# ls /
bin dev proc usr sys bidule.go MACHIN
# /usr/bin/go run bidule.go
[1] 1067
virtualisation, cloud, microservices, conteneurs

22. virtualisation
● 1980 (IBM) : émuler le processeur et faire tourner un système dessus
● 2003 : instructions intel VT-X
○ isolation des OS au niveau matériel
○ allocation des ressources matérielles par OS
○ accès cloisonnés entre hyperviseur et instances
paravirtualisation(“... is evil”)
● 1972 : modification des noyaux hôtes et invités pour gérer les instructions non virtualisables
● 2018 : problème posé par Meltdown / Kaiser patches / Kernel Page Table Isolation
ref: Bulletin d'alerte CERTFR-2018-ALE-001, 2018

23. sécurité de l’hyperviseur
● points de vulnérabilité :
○ isolation de ressource matérielle
○ implémentation d’appel système ; registre CPU, tampon de stockage et réseau
○ purge avant réallocation de zone mémoire
○ authentification des appels des instances vers l’API d’hyperviseur
○ pilotes d’interface entre l’hyperviseur et le matériel
○ extensions tierces à l’hyperviseur
○ contrôle d’accès à la console
● ne pas confondre l’accès à l’API de gestion des instances et l’accès direct à
l’hyperviseur (mais attention à VMware ESX 1.5 and 2.x)
● l’hyperviseur n’accède pas facilement aux systèmes invités
● peu d’attaques connues sur les hyperviseurs
ref: Universite de Princeton, NJ - Characterizing Hypervisor Vulnerabilities in Cloud Computing Servers, 2013

24. conteneurs / OS-level
● 2000: freeBSD jail
● 2004: Solaris containers
● 2005: openVZ
● 2008: cgoups, LXC
● 2002→2012: linux namespaces (ipc, mnt, net, pid, user, uts, cgroup)
● 2013: docker
● 2014 : rkt appc ; LXD ; overlayFS
● 2015 : systemd-nspawn
LXC : LinuX Containers

25. conteneurs / OS-level
● conteneur = process unix + chroot + namespace + cgroup
● l’OS est toujours limité en processus / forks et en descripteurs de fichiers
○ risque fork bombs
● l’orchestrateur de conteneurs ne communique pas avec init
● l’app est PID1 dans le conteneur
● processus difficiles à superviser
● conflit ressources affichées / allouées
● la sécurité des conteneurs est avant tout dépendante du noyau

26. + -
+ réduit la surface
d’attaque
+ embarque le strict
nécessaire
+ dont un shell posix
+ permet un debug
basique
- libc remplacée par
µClibc et musl -> fort
impact
- incohérence entre
images embarquant
musl ; et dockerd, init
et noyau en glibc

27. $ head -n 1 Dockerfile
FROM ubuntu:18.04
$ docker images gailuron/truc-en-rust
REPOSITORY TAG IMAGE ID CREATED SIZE
gailuron/truc-en-rust latest 8a16969f12b0 11 minutes ago 431.7 MB
$ docker-slim build --http-probe gailuron/truc-en-rust
INFO[0000] docker-slim: inspecting 'fat' image metadata...
INFO[0000] docker-slim: starting instrumented 'fat' container...
docker-slim: press when you are done using the container...
INFO[0005] docker-slim: shutting down 'fat' container...
INFO[0006] docker-slim: processing instrumented 'fat' container info...
INFO[0006] docker-slim: building 'slim' image...
INFO[0010] docker-slim: created new image: gailuron/truc-en-rust.slim ( has data artifacts: true ).
$ docker images gailuron/truc-en-rust.slim
REPOSITORY TAG IMAGE ID CREATED SIZE
gailuron/truc-en-rust.slim latest f6ac586a418f 1 minute ago 14 MB
heureusement il y a
nodej:ubuntu : 431.7 MB => 14.22 MB
python:ubuntu : 433.1 MB => 15.97 MB
ruby:ubuntu : 406.2 MB => 13.66 MB
java:ubuntu : 743.6 MB => 100.3 MB

28. Virtualisation
isolation au niveau d’un hyperviseur et/ou du
matériel
intégrité : un hyperviseur est plus fiable qu’un
noyau partagé ; remonter à l’hyperviseur pour
prendre le contrôle des instances virtuelles n’a
été exploité que par des white hats sur du
VMware - et sur de la paravirtualisation
meilleure supervision des ressources
disponibles
technos et outils mieux maîtrisés, compétences
plus faciles à trouver
Conteneurs
isolation des processus par le noyau
pas mieux cloisonné qu’un LAMP mutualisé où
chaque utilisateur fait tourner son code
exécute au même niveau du code tiers
développé par des équipes ou des clients
différents
leur surface d’attaque peut être réduite, mais au
prix d’un noyau élargi pour être généraliste
contrôler et auditer leur contenu est plus
important que sur des VM (privilèges, CVE, etc)
LAMP : Linux/Apache/MySQL/PHP
CVE : Common Vulnerabilities and Exposures

29. quelques attaques connues sur des conteneurs
● CVE-2015-2925 : bind mount / attaque double-chroot
● CVE-2013-1858 : escalade de privilèges par l’usage combine des appels noyau
CLONE_NEWUSER et CLONE_FS puis chroot a la racine
● CVE-2016-8867 : linux capabilities / attaque par force brute sur les inodes du
système visibles depuis le conteneur, puis appels système pour ouvrir les fichiers
● image docker malicieuse qui modifie la somme de contrôle de sa propre couche
● arp spoofing depuis un conteneur avec Ettercap
contexte kubernetes
● exploitation des variables d’environnement transmises au conteneur par k8s
● détournement de service par etcd non protégé
● accès aux secrets k8s
refs : Fabien Kerbouci, 2016
Philippe Bogaerts - ARP spoofing Docker containers, 2017

30. Interlude
⩫ Oh la belle paire de jumelles ! ⩫
Serge Hartmann serge.hartmann@gmail.com

31. soyonsàlamodeen
supervision,maispastrop
TV5 monde, avril 2015.
Les mots de passe étaient affichés à côté
des écrans de supervision :
- lemotdepassedeyoutube
- azerty12345

32. soyonsàlamodeen
supervision,maispastrop
TV5 monde, avril 2015.
Les mots de passe étaient affichés à côté
des écrans de supervision :
- lemotdepassedeyoutube
- azerty12345

33. soyonsàlamodeen
supervision,maispastrop
TV5 monde, avril 2015.
Les mots de passe étaient affichés à côté
des écrans de supervision :
- lemotdepassedeyoutube
- azerty12345

34. soyonsàlamodeen
supervision,maispastrop
TV5 monde, avril 2015.
Les mots de passe étaient affichés à côté
des écrans de supervision :
- lemotdepassedeyoutube
- azerty12345

35. soyonsàlamodeen
supervision,maispastrop
TV5 monde, avril 2015.
Les mots de passe étaient affichés à côté
des écrans de supervision :
- lemotdepassedeyoutube
- azerty12345

36. soyonsàlamodeen
supervision,maispastrop
TV5 monde, avril 2015.
Les mots de passe étaient affichés à côté
des écrans de supervision :
- lemotdepassedeyoutube
- azerty12345

37. Fin de l’interlude
Serge Hartmann serge.hartmann@gmail.com

38. cloud : ce qui n’apporte plus de sécurité
● la forteresse (pare-feu, NAT, DMZ, proxy explicite, filtrage) → le cloud est une ville ; notre
trusted network n’a pas de frontières, il n’existe pas
○ un cloud privé apporte surtout des illusions en sécurité
● la réaction à la publication de CVE
● la culture du secret, frein à la communication et au développement pour les équipes
devOps/cloud
● les préconisations hors périmètre strict sécu (technos, langages, frameworks, logiciels)
● la réticence au cloud et aux pratiques associées ⇒ shadow IT → 35% des ressources
informatiques (Gartner)
● les agents permanents dédiés à chaque couche qui scannent leur système hôte
● la croyance de la visibilité sur le parc
● se démarquer, ou cultiver nos différences en risques et problèmes
Geoffroy Couprie - The end of the fortress metaphor, 2015
Oliver Rist - Air-gap networking for the price of a pair of sneakers, 2006
David Meyer - Why shutting down Shadow IT stifles innovation, 2015
NAT: Network Address Translation
DMZ: DeMilitarized Zone
CVE : Common Vulnerabilities & Exposures

39. Interlude
⩫ Chez le chasseur ⩫
Serge Hartmann serge.hartmann@gmail.com

43. Fin de l’interlude
Serge Hartmann serge.hartmann@gmail.com

44. approches cloud-native : les microservices
des ensembles de petits services déployables indépendamment, idéalement
modélisés sur les domaines d’application évolutifs
refs: Sam Newman - Building Microservices - Designing Fine-Grained Systems, O’Reilly, 2015
Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, 2003
commande
catalogue
produit
expédition
enregistrement
utilisateur
client
facturation
Concepts are integrated by constant
communication among team members. The
team must cultivate a shared
understanding of the ever-changing
model. Many practices help, but the most
fundamental is constantly hammering out
the ubiquitous language.
(Eric Evans, Domain Driven Design, p. 375)

45. microservices : gain en sécurité
● processus et données ne sont plus concentrés au même endroit comme dans un
monolithe ⇒ patches mieux ciblés et mieux testés
● microservices et données peuvent être cloisonnés, meilleur contrôle
● plusieurs périmètres isolés
● mixer pare-feu par processus et par réseau
● repenser une architecture → opportunité
de revoir la sécurité dans le design
● instances sans état jetables
● réduit le risque de mettre à jour
● microservice optimisé ⇒ surface
d’attaque plus petite
● services polyglottes

46. microservices : faiblesses en sécurité
● plus il y a de réseau, de composants, de machines, d’APIs ; plus la surface
d’attaque et d’interception de trafic augmente
● architecture complexe
○ diagnostic
○ nombre de services à lancer pour un pentest ou un scan
○ moins de maintenance naturelle/fonctionnelle
● peu d’outils de détection des composants fantômes ou de données
orphelines
● pas d’agent résidant sur chaque instance
● moins de contrôle sur les dépendances
● disruption ⇒ multiples raisons s’y prendre mal et de causer des catastrophes
API : Application Programming Interface

47. client
web
service
boutique
service
données
utilisateur
service
catalogue
service
recommandation
passerelle
paiements
exemple
mon disquaire en ligne

48. client
web
service
boutique
service
données
utilisateur
service
catalogue
service
recommandation
passerelle
paiements
exemple
mon disquaire en ligne

49. client
web
service
boutique
service
données
utilisateur
Salut ! C’est Papy Mougeot !

50. client
web
service
boutique
service
données
utilisateur
Salut ! C’est Papy Mougeot ! Heureux de vous revoir, Papy Mougeot.
Vous êtes connecté, sais-tu.
connecté en tant que Papy Mougeot

51. client
web
service
boutique
service
données
utilisateur
Pourriez-vous m’afficher les
données qui me concernent ?
connecté en tant que Papy Mougeot

52. client
web
service
boutique
service
données
utilisateur
Salut Frida, c’est Flupke !
Sais-tu une fois me passer
le dossier de Papy Mougeot ?
connecté en tant que Papy Mougeot
Pourriez-vous m’afficher les
données qui me concernent ?

53. client
web
service
boutique
service
données
utilisateur
Salut Frida, c’est Flupke !
Sais-tu une fois me passer
le dossier de Papy Mougeot ?
Hôp-là cher collègue,
Voici le dossier de
Papy Mougeot.
connecté en tant que Papy Mougeot
Pourriez-vous m’afficher les
données qui me concernent ?

54. client
web
service
boutique
service
données
utilisateur
Voulez-vous bien m’afficher les
données de l'inspecteur Clouseau ?
connecté en tant que Papy Mougeot

55. client
web
service
boutique
service
données
utilisateur
connecté en tant que Papy Mougeot
Frida, c’est encore Flupke !
Sais-tu une fois me passer le
dossier de l'inspecteur Clouseau ?
Voulez-vous bien m’afficher les
données de l'inspecteur Clouseau ?

56. client
web
service
boutique
service
données
utilisateur
Frida, c’est encore Flupke !
Sais-tu une fois me passer le
dossier de l'inspecteur Clouseau ?
Hôp-là cher collègue,
Voici le dossier de
l'inspecteur Clouseau.
connecté en tant que Papy Mougeot
Voulez-vous bien m’afficher les
données de l'inspecteur Clouseau ?

57. Confused deputy problem
● procédé similaire au CSRF
● s’en protéger avec des jetons de session type JWT
stockés en cookie puis transmis de service en service
● expiration des jetons
● Macaroons
● même principe pour authentifier les requêtes des
microservices entre eux → secrets
CSRF : Cross-Site Request Forgery
JWT : JSON Web Token
client
web
service
boutique
service
données
utilisateur
{"id":"eil2Aefooye8","name":"Marcel Gottlieb"}

58. prévention des risques
● apprendre au développeur à se poser les bonnes questions avant de coder :
○ comment éviter qu’un intrus accède à des services ou des données sensibles
○ où sommes-nous les plus vulnérables, comment nous en protéger au mieux
● quand nous ne pouvons pas rendre une action impossible, rendons-la plus coûteuse
(moyens, temps)
● appliquer rapidement et automatiquement les mises à jour de sécurité
→ à tous les niveaux
● chiffrer toute donnée stockée ou transmise dès que
le chiffrement est peu coûteux → Cloud DLP
● isoler et séparer les données chiffrées
du gestionnaire de clefs
● SCM, forge logicielle → MFA obligatoire
“44% des incidents de sécurité surviennent après que les
vulnérabilités et leurs résolutions aient été identifiés. Ces incidents
auraient été évités si les correctifs avaient été appliqués plus tôt.”
Ref: Forbes, BMC - 2nd Annual IT Security and Operations Survey, 2016
“83% des organisations utilisent des
dépendances qui exposent des
vulnérabilités. Il est temps de scanner tous
les composants pour référencer ces
vulnérabilités et réduire les risques”
Ref: Neil MacDonald, Gartner
DLP : Data Loss Prevention
MFA : Multi-Factor Authentication
SCM : Source Code Management

59. détection des failles et des intrusions
● délai entre l’introduction d’une vulnérabilité et la publication
d’un CVE
● préconiser des WAF
● importance des logs agrégés centralisés
● services polyglottes dans le cloud ⇒ automatiser
● outils cloud-native de détection orientés UEBA + AI
WAF : Web Application Firewall
AI : Intelligence Artificielle
UEBA : Users and Entity Behaviour Analytics
DLP : Data Loss Prevention
client
web
service
boutique
service
données
utilisateur

60. réponse appropriée
fuite de données → panique → erreurs de communication
● identifier les risques pour les utilisateurs
○ matrice de risques
○ n’oublions pas les logiciels tiers
● définir les canaux et plans de communication
● préparer les messages correspondant aux principaux risques
● pour répondre rationnellement dans le calme aux préoccupations de nos
utilisateurs
lutter à long terme contre les cybercriminels
● partage d’informations entre professionnels
● pédagogie envers les utilisateurs Alison “Snipeyhead” Gianotto - Security and Risks, 2014
Failing Wall - Managing risk in web applications, 2013
Caleb Barlow - Where is cybercrime really coming from ?, 2017

61. retour à la normale
● pré-requis :
○ des sauvegardes testées régulièrement
○ stockages séparés pour les sauvegardes récentes, anciennes, et clefs de chiffrement
○ une procédure répétable de restauration du code et des données
● technos cloud ⇒ déploiement automatisé services et données
○ infrastructure immutable
○ ⇒ détruire et re-créer → rolling update
● le pire est testable ; durée prédictible
ref: Sam Newman - Building Microservices - Designing Fine-Grained Systems, O’Reilly, 2015

62. quelques normes et guides officiels
● ISO/CEI 27017 - “Code de pratique pour les contrôles de sécurité de l'information
fondés sur l'ISO/IEC 27002 pour les services du nuage » traite des aspects de la
sécurité de l'information du nuage”
● ISO/CEI 27002 - “Code de bonne pratique pour le management de la sécurité de
l’information”
● ISO/CEI 27018 - “Code de bonnes pratiques pour la protection des PII dans
l’informatique en nuage public agissant comme processeur de PII”
● ANSSI EBIOS - “Expression des Besoins et Identification des Objectifs de Sécurité -
gestion des risques SSI conforme au RGS et aux normes ISO 27001, 27005 et 31000”
● note ANSSI DAT-NT-011/ANSSI/SDE/NP - “Problématiques de sécurité associées à la
virtualisation des systèmes d’information”
PII : informations personnelles identifiables

63. contexte cloud et risques
● risques globalement similaires aux infrastructures traditionnelles
● opacité de la partie gérée par le fournisseur cloud
● dilution du cloud → perception différente de la sécurité en fonction de la zone
d’hébergement et de sa législation
● hébergement clandestin dans le cloud public
● changement d’échelle (inventaires, vulnérabilités, correctifs)
○ chez l’attaquant aussi ; ressources illimitées, botnets cloud à 2$/h
● données sensibles dans les logs
● toute opération manuelle est un risque
CI/CD : Intégration et Déploiement Continus
ref: Cisco - Top 10 Cloud Risks That Will Keep You Awake at Night, màj 2017
OWASP - OWASP Cloud ‐ 10 Project

64. autres risques et bonnes pratiques
● décommissionnement → supprimons toutes les données, y compris en stockage objet,
même quand le fournisseur cloud le garantit
● architectures complexes ⇒ travaillons notre instinct
● supervision : définissons les comportements standards
● automatisons les tests d’intrusion en boîtes noires et blanches → déclencheurs depuis
CI/CD
● données : ne collectons que le nécessaire
● considérons tous les bugs comme des risques sécurité
● éclatement des équipes en devOps ⇒ transparence et communication entre équipes
réduit les risques ⇒ travaillons notre rôle d’ambassadeur ; cultivons l’amitié avec les
gens du métier pour ne pas être mis de côté
CI/CD : Intégration et Déploiement Continus
ref: Cisco - Top 10 Cloud Risks That Will Keep You Awake at Night, màj 2017
OWASP - OWASP Cloud ‐ Cloud Top 10 Security Risks

65. d’autres bonnes pratiques
● ne nous acharnons pas à isoler le cloud de l’internet
○ l’attaquant est déjà dans notre cloud
○ il pense en graphes, et non plus en listes
● ne cherchons plus à contrôler les innombrables et éphémères points d’entrée et de sortie des
services (noms, chemins, adresses, ports)
● considérons chaque service, microservice, base de code, processus, s’exécutant dans le cloud,
comme potentielle intrusion → authentifions et autorisons au niveau utilisateur et microservice
● considérons tous les environnements dev/rec/préprod/prod avec la même criticité
● logs en flux standard
● mesurons les impacts du chiffrement (données / communications), tendons à rendre https
systématique et chiffrons AES-256 toutes les données stockées
● bannissons les accès root, voire les accès au shell
● suivons les bonnes listes de diffusion
TLS : Transport Layer Security Ref: John Lambert - Defenders think in lists. Attackers think in graphs. Attackers win, 2015

66. Faim
Serge Hartmann serge.hartmann@gmail.com