Le 25/09/2017 à 21:57, Raphael Mazelier a écrit : > > > 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. Je répond sous le paragraphe suivant puisque c'est lié. > >> 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.
Et là on reboucle sur le sujet, les conteneurs c'est super si on les fait soit même, on met ce que l'on veut : la sécurité, le déport de métriques / logs, les mises à jour, ... mais cela implique de faire ses images. Ca ne va clairement pas dans le sens des dirigeants qui y voient le gain financier temps / emmerdement à cours terme. Le pire ce sont les images officielles des applications, c'est officiel donc ça ne peut pas être foncièrement mauvais dixit des DSI et de DT. > >> 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 ? On reboucle sur le souci des images stock ou custom, en stock oui y a une différence parce qu'en VM l'OS peut être modifié facilement (à la main, script, automate) en conteneur c'est trop complexe pour les équipes qu'on croise. Du coup l'option de facilité c'est de dire ces mesures de sécurité, ces conformité c'est pas bien grave on relancera l'instance en cas de soucis ... > >> 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. Ca implique toujours une image conteneur custom. Sinon lancer un outil automate dans un OS conteneur qui est censé se regénérer toutes les x minutes / heures n'a que peu de sens. > >> 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. La grande différence c'est que seuls les gros hébergeurs ont des CGV indiquant clairement que l'on cède à titre gracieux, de façon inaliénable et sans limite de temps l'usage des données que l'on y dépose. Que ces mêmes gros ne garantissent pas la suppression des données lorsqu'on le demande. Alors y a le côté ingénieur qui me dit normal un serveur dé-commissionné en toute logique n'a pas reçu l'ordre de suppression donc ils se couvrent là dessus. Pour le stockage ils se blindent pour que l'on puisse rien leur reprocher. Mais y a le côté analyse des lois post 11 septembre et l'espionnage industriel et commercial fait par les USA qui offrent une seconde lecture moins glamour des mêmes CGV. J'ai eu vent d'une entreprise qui lorsqu'elle vend du transit à des hébergeurs espionnait le trafic pour analyser les flux et envoyait les commerciaux venir tenter de débaucher un client pour la filiale hébergement. Néanmoins par MP je veux bien d'autres infos c'est toujours bon de savoir quels prestataires ne sont pas de confiance.
signature.asc
Description: OpenPGP digital signature
