Je plusoie. Mea Culpa mais quand je parlais de virtualisation j'entendais par abus de langage toutes technos basées sur un hyperviseur et/ou implémentant virtualisation complète ou para-virtualisation (Xen, kvm, vmware, virtualbox+vagrant, libvirt, ...) mais également les "environnements de confinement" comme l'a rappelé Pierre (LXC, OpenVZ, BSD Jails, ...)
Pour ceux que ça intéresse, quelques présentations du fosdem sur le sujet : http://www.fosdem.org/2012/schedule/event/427/83_ganeti_internals.pdf http://video.fosdem.org/2012/maintracks/janson/Linux_containers_and_OpenVZ.webm http://www.fosdem.org/2012/schedule/event/444/82_fosdem12.pdf http://www.fosdem.org/2012/schedule/event/360/2_2011-forum-native-linux-kvm-tool.pdf Le 10 avril 2012 09:53, Pierre Jaury <pie...@jaury.eu> a écrit : > Bonjour, > > Le point clairement prioritaire si tu t'orientes vers quelque chose à > plus grande échelle que la machine dans le garage, c'est d'isoler les > catégories de services. JP Troll a beau dire que la virtualisation, > c'est un bond en arrière jusqu'aux OS monotâches, une bonne isolation de > contexte façon Linux Containers ou OpenVZ t'offrira deux avantages > indéniables. > > D'abord tu gagnes évidemment en sécurité dans le sens où tu ne te fais > jamais rooter un hôte physique et où un hôte virtuel compromis peut > facilement être supprimé et redéployé, éventuellement mis de côté pour > du forensique. Ensuite, tu gagnes énormément en souplesse : à partir > même de trois pauvres hôtes physiques, tu peux te permettre une gestion > en cluster virtualisé (RTFM pour le coup, sinon ça va partir en troll vu > le nombre d'options), et donc de la souplesse quant-à la gestion de > l'infra physique, réseau, etc. > > Ce discours pour expliquer qu'isoler tes services sur des machines (même > virtuelles) différentes sera le premier pas en avant. Il s'agit d'isoler > d'une part les services frontaux : mails, Web, etc. et d'autres part les > couches sur ces services, en prenant bien soin de factoriser : gestion > d'utilisateurs centralisée (LDAP), accès au réseau interne uniformisé > via VPN et/ou SSH, fichiers partagés centralisés en iSCSI, etc. Tu peux > mine de rien te permettre une telle isolation sur un nombre très réduit > d'hôtes physiques, en assurant au passage la redondance et le hotspare. > > Si c'est en revanche pour une utilisation très personnelle, toi et ta > bande de potes, je t'invite seulement à faire une usine à gaz et à café > qui tient sur un boîtier à 100€ que tu plug dans ton garage sur une > ligne ADSL. À chaque usage son approche. Tu pourras éventuellement > t'éclater avec LXC (j'avais publié des patchs pour différents chipsets à > base d'ARM) histoire de filer à tes potes un véritable accès au système > à peu de frais/peu de risques. > > kaiyou. > > On Tue, 2012-04-10 at 09:41 +0200, cam.la...@azerttyu.net wrote: > > Bonjour > > > > Je réponds à la liste vu que la question et la réponse peuvent > > intéresser tout le monde > > > > > Je ne comprends pas en quoi ta question diffère de la précédente. > > > Si tu veux dire un serveur qui héberge plusieurs services qui n'ont > rien à > > > voir (ce qui est abominable sans à minima un chroot avec une sécu > > > élémentaires au mieux via libvirt ou autre mécanisme de virtualisation > sur > > > un noyau sécurisé). Est-il question de protéger seul le service http > (ce qui > > > ne serait pas une bonne idée à côté d'un ftp publique par exemple) ou > est-ce > > > qu'il est question de sécuriser tout le serveur (ce qui est compliqué > > > lorsque le serveur est une usine a gaz) ? > > > > Avec ma gestion du temps en week end encore cafouilleuse, je n'ai pu > > répondre plus tôt :) > > > > Pour le moment je n'ai pas de cas bien concret plutôt des question > > génériques sur, comme tu l'as pu dire dans un tes autres mail, > > d'architecture / infrastructure. > > > > Dans mon cas je me retrouve avec des serveurs qui font un peu tout et > > presque le café, et en partant de là je me demande qu'elles sont les > > bonnes approches pour améliorer la sécurité de ses services, la > > question aurait pu être "comment architecturer au mieux son > > infrastructure une fois qu'on a eu son premier serveur SWABDELP ?". > > > > Au lieu de poser la question du genre "comment faire pour sécuriser > > mon serveur ?" où il est assez facile de balancer du RTFM ou va lire > > sur le forum d'une distro connue j'ai préféré poser la question du > > point de vue d'un service. > > > > Cette formulation n'était peut être pas idéale, en tout cas les > > réponses de tous me semblent pas mal intéressantes. Cela permet de > > mettre en exergues les points à aborder en priorité. > > > > Merci pour vos lectures > > > > Km > > _______________________________________________ > > Liste de diffusion du FRsAG > > http://www.frsag.org/ > > > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ > >
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
