Le 10/07/2013 19:04, Yves Rutschle a écrit :
et bien, d'un point de vu sécuritaire, c'est au contraire, plus simple à gérer. les stacks sont identiques, il faut bien sur mettre à jour tous les jails et le serveur hébergeur. moyennant un reboot bien entendu. mais le boulot est le même si les serveurs font tourner la même version d'apache. en cas de découverte d'une faille, tous les serveurs apache doivent être mis à jour.On Wed, Jul 10, 2013 at 03:36:42PM +0200, admini wrote:les conteneurs sont très étanches, et possèdent leur propre stack.Leur propre stack? qu'entend-tu par là?stack protocolaire.TCP/IP donc? J'imagine que chaque stack est identique, et contient donc les mêmes vulnérabilités potentielles, du coup quel est l'intérêt? Ou est-ce que le but n'est pas la sécurité, et dans ce cas quel est-il? Y.
l'autre avantage du jail au stack indépendant (c'est le cas sous BSD, et très probablement sous debian), c'est qu'on peut firewaller, donc gérer les politiques de sécurité de façon totalement indépendante pour chacun des jail, flager les options du stack (QoS, Vlans, interface virtuelle pour les SAN...) selon les besoins de chacun.
la sécurité est très précisément le but principal du jail. un jail compromis? pas de problème, il sera le seul à l'être pour l'instant. l'admin doit fait son boulot c'est tout.
d'ailleurs, les failles de sécurité touchant le stack de BSD .... à part ces fameuses backdoors de FBI dans IPsec, pour peu que quelqu'un se serve encore de ca dans le monde libre, j'en connais pas. l'autre avantage du jail, est la perfe. sans la sur-couche de la virtue classique, le jail est très proche du matériel, car il se sert du noyau hébergeur pour fonctionner. les IO sont rapides comme sur le serveur hébergeur, ainsi que pour tout le reste.