Bir sunucuyu sanallaştırmak, yama ve güncelleme yapmak, daha fazla iş ve daha fazla risk almak için başka bir işletim sistemi katmanı anlamına mı gelir?

Bir arama yaptım ve yama ve sistem güncellemeleriyle ilgili sorunları giderecek bir şey bulamadım. Sunucuların gerekli yamaları olması gerektiğini söyleyen kurallarım var. Bir VM sunucum varsa, o zaman çıplak metal hipervizörlerde bile yama ve güncelleme yapmak için ekstra bir katman var mı? Metal bir sunucuya karşı mı? (örn. rehberlerime göre daha fazla iş ve test ve dokümantasyon).

Tip 1 / çıplak metal hiper vizörler ne sıklıkla güncellenir? Önemi var? Ekstra bir yazılım katmanı olması, daha fazla karmaşıklık ve risk oluşturuyor mu (güvenlik ve güvenilirlik)? (örneğin,% 99 hatasız yazılım x% 99 hatasız yazılım =% 98 hatasız sistem)?

(Benim pratik deneyimim VMWare İş İstasyonu ve Sunucu ve VirtualBox ile).

Evet, VMware gibi ürünleri (bazen yamanmalıdır güncellemeler olan kümülatif ), ancak yamalar bir ana hat işletim sistemine göre daha az sıklıkla gelip potansiyel saldırı vektörü küçüktür - senin hiper yönetici genel olarak erişilebilen olmamalıdır .

VMware ESXi 5.0 versiyonunu (5.1 değil) örnek olarak kullanacağım ...

ESXi 5.0 aşağıdaki güncelleme planına sahiptir:

9/2011 ve şimdi arasında , ESXi 5.0 ürününe yönelik TEN güncellemeleri yapıldı. Bunlardan SIX , aşağıdaki gibi açıklamalarla güncelleme paketlerine alınmış güvenlik odaklı güncellemelerdi:

"ESXi NFS trafik ayrıştırma güvenlik açığı" - CVE-2012-2448 .

Bu güvenlik açıkları gerçektir, çünkü bazen genel Linux güvenlik hatalarını yansıtırlar, ancak çoğu kuruluşun risklere karşı çok duyarlı olmadığını düşünüyorum. Bu riski değerlendirmek mühendisin elinde. Kullanıcılarınız aşağıdaki açıklamayı düzeltmek için büyük bir kesinti ister mi ?

Msgstr "GNU C Kütüphanesinde misc / mntent_r.c içindeki encode_name makrosu (aka glibc veya libc6) 2.11.1 ve önceki sürümlerde, ncpmount ve mount.cifs tarafından kullanıldığı gibi, yerel kullanıcılara izin veren mountpoint adlarındaki newline karakterlerini doğru şekilde işlemez bir hizmet reddine neden olmak (mtab bozulması) veya hazırlanmış bir montaj isteği ile montaj seçeneklerini değiştirmek ve ayrıcalıklar kazanmak. "

Olabilir? Belki de değil.

VMware'in Güncelleme Yöneticisi'ni çalıştırıyorum , ancak yalnızca bir hatadan etkilendiğim veya özellik geliştirme gerektirdiğimde güncelleme yapma eğilimindeyim. Kümelenmiş bir kurulumda çalıştırıldığında, yama, çalışan VM'lerde kesinti yapmadan kolaydır. Başka bir acil sebep yoksa, sadece üç ayda bir güncelleme yapmaya çalışacağım. Yamalar monolitik görüntüler olarak teslim edildiğinden, ayrı ayrı ana bilgisayarların yeniden başlatılması gerekir.

Yan not olarak, ne zaman bir VMware ESXi kurulumunu devraldığımda veya normalde yönetmediğim bir sistemde çalıştığımda, çalışan hiçbir zaman VMware yamaları uygulanmış olmayan ana bilgisayarları görüyorum . Bu yanlış!! Ancak, sistemler çalışır durumdayken yöneticilerin bu hatayı nasıl yapabildiklerini anlayabiliyorum.

'Çıplak metal' konaklarla sanallaştırma konusunda yeniyseniz, bu oldukça iyi bir sorudur. Bu şekilde yapmak, geleneksel bir işletim sisteminin üstünde hizmet / uygulama olarak çalışan hipervizörlerle yapabileceğiniz yaklaşım için farklı bir zihniyet gerektirir.

Tecrübelerime göre, ESX ve HyperV'in geleneksel işletim sistemlerinden daha az yamaya ihtiyaç duyduğunu söylemek doğru olur . Bu , hiçbir şekilde yamalara ihtiyaç duymayacakları anlamına gelmez veya bazı yamaların uygulanmasının “ihtiyaç” ne olursa olsun yararlı olamayacağı anlamına gelmez, ancak bu, sunucunuzu yamalamak için hizmetlerinize yapılan müdahalelerin daha az sıklıkta olması gerektiği anlamına gelir ve kontrolünüz altında daha fazlası. Hiper yönetici işletim sistemlerinde, diğerlerinde olduğu gibi potansiyel bir güvenlik riski vardır ve bu riskin maruz kalmasını en aza indirgeyebilirsiniz (örneğin, yalnızca mantıksal olarak tehlikeye atılmış bir sunucudan erişilemeyen izole edilmiş bir VLAN'da hiper yönetici yönetimini göstermek) Risk yokmuş gibi davranmak aptallık olurdu.

Yani, sanal olmayan 4 sunucunuz varsa, ve hepsini aynı sanallaştırılmış ana makineye taşıyorsanız, evet, ana bilgisayar sistemini düzeltme ihtiyacı (veya bununla başa çıkma gereksiniminin neden olabileceği aksaklık miktarını artırıyorsunuzdur). Bu konuda bir donanım sorunu, vb.

Bu riskin ortaya çıkma şansının göreceli olarak düşük olduğunu öne sürmeme rağmen (sanal bir ana bilgisayarı yama ile yine de tek başına bir sistemde yapmanız gereken yeniden başlatmayı gerektiren yeniden başlatma türü arasındaki farktan bahsediyorum ), etkinin yüksek olduğu gerçeğinden uzaklaşılmaz.

Peki neden o zaman yapıyoruz?

Sanallaştırmanın gerçek yararı, birden fazla ana bilgisayar kurabilmekten ve ana bilgisayarları birlikte çalışacak şekilde yapılandırabilmekten, konukların bir ana bilgisayardan diğerine geçebilmelerine izin vermek, bir ana bilgisayarın başarısız olması ya da yamalar planlamak istediğinizde ev sahibi sistemler.

Bu yaklaşımı kullanarak 5 ESX ana bilgisayarını üst üste çalışan 40 sanal sunucuya herhangi bir kesinti olmadan sıraya sokmayı başardım . Bu sadece bir ölçek ekonomisi meselesidir - bir kez bu tür karmaşık kurulumları oluşturmaya değecek kadar potansiyel sanal konuk makineniz olduğunda ve bunu, cevabında bahsettiğimiz araçlarla, riskleri azaltmadaki geri ödeme yöntemini kullanmaya yarayan araçlarla yönetmeniz yeterlidir. çok çabuk geldiğiniz için endişeleniyorsunuz.

Bir sanal sunucu aynı bakımı gerektirir ve fiziksel bir sunucunun yaptığı yamaları yapar, çıplak metal hipervizörleri güvenlik, aynı zamanda hataları düzeltmek ve performansı artırmak için güncellemeler ister. Ne kadar çok sunucuya sahipseniz, güncel kalmaları için o kadar çok iş yapmanız gerekecek, fiziksel ya da sanal olmaları önemli değil.

Yukarıdaki cevaplara dayanarak görünmektedir: Bir sunucuyu sanallaştırmak, güvenlik ve güvenilirlikte daha fazla karmaşıklık ve risk getirmiştir, ancak bunların bir sunucuyu sanallaştırarak arıza süresini azaltmanın yararlarına karşı tartılması gerekir.

Ortamınız denetim, testler ve belgeler gerektiriyorsa, sanallaştırılmış bir ortamın eklenmiş iş yükünün maliyet avantajı, sahip olduğunuz sunucu ve sistem personelinin sayısında dikkate alınmalıdır. Çevremizde sanallaştırılmış bir ortam için denetim izini sürecek personel / personel zamanımız yok. İş süreçlerimizde biraz aksama alabiliriz, ancak bir denetim takibi ve belgesini kaçıramayız.