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/

Répondre à