On 25/09/2017 12:24, Wallace wrote:
Bien résumé Eric et pour avoir tenu un discours comme celui de Raphael à
des boites qui faisaient n'importe quoi en conteneur, la réponse est ha
oui mais c'est super compliqué et trop abstrait de faire comme cela. En
gros le côté éphémère leur fait super peur et c'est complètement
abstrait = risque +++ pour les directions donc ils ne font pas.
OK donc tu critiques la mauvaise mise en place des containers pas les
containers en tant que tel. Mais c'est exactement pareil sinon pire de
multiplier plein de petite vm(s) en terme de sécurité.
Un container ne devrait être vu que comme une instance (dans le vrai
sens instanciation objet) d'une application/service.
Après même avec une superbe archi conteneur, si tu fais toutes tes
images pour être iso27001, pcidss et HDS le côté éphémère complexifie
grandement le traitement des métriques / logs et le suivi qualité.
Non c'est l'inverse. Évidement il faut prendre cela en compte dès la
création du container. Par exemple chez nous toutes les applications
"dockerisé" ont obligation d'envoyer leurs logs de manière structuré à
un système de log central (graylog en l’occurrence).
Au final j'ai l'impression que l'on parle de deux choses différentes.
Remplacer des vm(s) par des containers n'a aucun sens en effet.
Développer une nouvelle stack/SI dans un environnement container est une
grande opportunité. La où je te rejoins c'est qu'il y a une grande
courbe d'apprentissage que ce soit coté dev ou coté ops.
Faut penser aussi aux audits externes qui peuvent être imposés genre
suite à une fuite de données, la CNIL / ANSI qui vient auditer. Aucune
des boites que j'ai vu faire du conteneur n'est apte à répondre à la
moindre question d'extraction de donnée. Et quand on pense aux données
que ces boites voient transiter c'est pas du tout rassurant pour nos
profils persos.
Parce c'est différent dans un environnement classique ?
C'est aussi ça le rôle d'un hébergeur infogéreur, être sûr que son
client soit apte à répondre à la loi en cas de besoin.
Je trouve qu'une solution Ansible telle qu'on l'a monté chez nous qui
permet de faire du on demand sur différents hosteurs c'est tout aussi
souple. L'intégration d'une VM ça prend 5 min max avec le déroulé
Ansible mettant tout aux normes. Avantage on peut aussi commander des
baremetal et avoir des ressources bien différentes qui s'intègrent en
10/15 min max si le hosteur livre rapidement.
Je ne vois toujours pas en quoi cela serait plus difficile dans un
environnement container. Ne pas oublier qu'un container n'est rien de
plus qu'un ensemble de process un peu isolé. Donc sécuriser n'importe
quelle application ou un container c'est pareil.
Sinon pour la partie des mega hosteurs, même s'ils débarquent en France
ceux qui y mettent leurs données sont exposées aux lois américaines. Je
parle même pas de la confidentialité en chiffrant les données, je parle
de la réponse de ces boites vis à vis de la France et EU.
L'aspect légal. Argument recevable.
Et là aussi même constat dans tous les boites et mêmes administrations
qui utilisent Amazon ou Azur j'ai jamais vu une seule donnée chiffrée.
C'est complètement irresponsable. J'ai vu des données santé brutes
(image IRM, doc rapport du médecin, fichier txt avec le mot de passe par
défaut 12345 pour en faire un mémo, nom des patients dans le nom de
fichier, ...) aller chez Amazon et Azur pour le PRA. A titre personnel
ça ne me donne même plus envie d'aller voir des médecins qui ont du
matériel connecté. Et quand on fait réagir le client sur ce point, ha
mais les médecins on peut rien leur demander, c'est les maîtres ici,
12345 c'est déjà trop compliqué pour eux comme mot de passe ils
appellent le support quand le verr num n'est pas activé ... Et le cloud
public c'est pratique on a pas d'infra à mettre en place et à gérer.
Là encore tu critiques des mauvaises pratiques. Je ne penses pas que les
gros encouragent ce genre de choses. D'ailleurs Amazon (pour ne citer
qu'eux) fait beaucoup de sensibilisation/formation sur la sécurisation
d'une infrastructure hosté chez eux.
Et quelle différence entre un truc mal sécurisé chez gafa, d'un truc mal
sécurisé chez hébergeur lambda ? je ne peux te citer un certain nombre
d'hébergeur qui ne se gênaient pas trop utiliser les données de leur
client. Je ne parle même pas de la résilience des données.
Dans les DSI je vois une prise de conscience des méfaits du cloud public
et de l'adage de ne pas mettre les oeufs dans le même panier, ils ont
tous les mots hybridation des clouds à la bouche et certains qui n'ont
pas entièrement vidé leurs cloud privés sont content de pouvoir retrouvé
des fonds pour les gérer ou les faire gérer.
Donc les petits hébergeurs ont encore du travail clairement.
Il y a plusieurs aspects qu'un DSI doit pendre en compte quand on
choisit un cloud publique en effet. On peut citer le fait de ne pas se
retrouver locké à tel ou tel provider (rien de bien nouveau quand on y
pense) et justement l'aspect containerisation aide beaucoup, la
sécurisation (nouveauté ?), les coûts (un cloud privé coûte encore moins
cher qu'un cloud publique, encore qu'il faille prendre en compte le coût
et la rareté des bons Ops)
--
Raphael Mazelier
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
