การทำเวอร์ชวลเซิร์ฟเวอร์หมายถึงเลเยอร์ระบบปฏิบัติการอื่นเพื่อแก้ไขและอัปเดตทำงานมากขึ้นและมีความเสี่ยงมากขึ้น


27

ฉันได้ทำการค้นหาและไม่พบปัญหาใด ๆ เกี่ยวกับการแก้ไขและการอัปเดตระบบ ฉันมีแนวทางที่บอกว่าเซิร์ฟเวอร์จำเป็นต้องมีโปรแกรมแก้ไขที่จำเป็น ถ้าฉันมีโฮสต์ VM แล้วมันเป็นชั้นพิเศษที่จะแก้ไขและปรับปรุง - แม้จะมีไฮเปอร์ไวเซอร์โลหะเปลือยหรือไม่ ตรงข้ามกับการมีเซิร์ฟเวอร์โลหะ? (เช่นทำงานและทดสอบและเอกสารเพิ่มเติมตามแนวทางของฉัน)

Hyper-visors ประเภท 1 / โลหะเปลือยได้รับการอัปเดตบ่อยเพียงใด มันเป็นเรื่องสำคัญไหม ความจริงที่ว่าเป็นเลเยอร์ซอฟต์แวร์พิเศษที่นำเสนอความซับซ้อนและความเสี่ยงที่มากขึ้น (เช่นซอฟต์แวร์ข้อบกพร่อง 99% x ซอฟต์แวร์ข้อผิดพลาด 99% = ระบบ 98% ปราศจากข้อบกพร่อง)?

(ประสบการณ์จริงของฉันอยู่กับ VMWare Workstation และเซิร์ฟเวอร์และ VirtualBox)


สิ่งนี้ตอบคำถามของคุณหรือไม่
ewwhite

ฉันคิดว่ามันตอบครึ่งหนึ่งของมัน ....
user127379

คำตอบ:


20

ใช่ผลิตภัณฑ์เช่น VMware ควรจะ patched บางครั้ง ( ปรับปรุงเป็นที่สะสม ) แต่แพทช์มาน้อยกว่าระบบปฏิบัติการฉีดและเวกเตอร์การโจมตีที่อาจเกิดขึ้นมีขนาดเล็ก - ไฮเปอร์ไวเซอร์ของคุณไม่ควรจะสาธารณชนสามารถเข้าถึง

ฉันจะใช้ VMware ESXi เวอร์ชัน 5.0 (ไม่ใช่ 5.1) เป็นตัวอย่าง ...

ESXi 5.0 มีกำหนดการอัพเดทต่อไปนี้:

ระหว่าง 9/2011 และปัจจุบันมีการปรับปรุงTENสำหรับผลิตภัณฑ์ ESXi 5.0 นอกเหนือจากนั้นSIXคือการอัปเดตที่เน้นเรื่องความปลอดภัยที่รวมอยู่ในบันเดิลการอัพเดตพร้อมคำอธิบายเช่น:

"การจราจร ESXi NFS แยกช่องโหว่" - CVE-2012-2448

ช่องโหว่ด้านความปลอดภัยเหล่านี้เป็นของจริงเนื่องจากบางครั้งพวกเขาสะท้อนข้อบกพร่องด้านความปลอดภัยทั่วไปของ Linux แต่ฉันคิดว่าองค์กรส่วนใหญ่ไม่เสี่ยงต่อความเสี่ยง แต่ก็ขึ้นอยู่กับวิศวกรว่าจะประเมินความเสี่ยงนี้อย่างไร ผู้ใช้ของคุณต้องการหยุดทำงานครั้งใหญ่เพื่อแก้ไขการหาประโยชน์ดังต่อไปนี้หรือไม่

"มาโคร encode_name ใน misc / mntent_r.c ในไลบรารี GNU C (aka glibc หรือ libc6) 2.11.1 และก่อนหน้านี้ซึ่งใช้โดย ncpmount และ mount.cifs ไม่สามารถจัดการอักขระบรรทัดใหม่ในชื่อเมานต์ได้อย่างถูกต้อง เพื่อทำให้เกิดการปฏิเสธการบริการ (ความเสียหายของ mtab) หรืออาจแก้ไขตัวเลือกการเมานต์และรับสิทธิ์ผ่านคำขอเมาท์ที่สร้างขึ้น "

อาจจะ? อาจจะไม่.

ฉันเรียกใช้ตัวจัดการการอัปเดตของ VMwareแต่มีแนวโน้มที่จะอัปเดตหากฉันได้รับผลกระทบจากข้อบกพร่องหรือต้องการการปรับปรุงคุณสมบัติ เมื่อรันในการตั้งค่าแบบคลัสเตอร์การแพตช์ทำได้ง่ายโดยไม่มีการหยุดทำงานของ VM หากไม่มีเหตุผลอื่นเร่งด่วนฉันจะพยายามอัปเดตรายไตรมาส โฮสต์แต่ละรายการจะต้องมีการรีบูทแบบเต็มเนื่องจากแพทช์จะถูกส่งเป็นภาพเสาหิน

ตามหมายเหตุด้านข้างเมื่อใดก็ตามที่ฉันได้รับการติดตั้ง VMware ESXi หรือทำงานบนระบบที่ฉันไม่ได้จัดการตามปกติฉันมักเห็นโฮสต์ที่ใช้งานซึ่งไม่เคยมีโปรแกรมปรับปรุง VMware มาใช้เลย ว่าเป็นสิ่งที่ผิด!! แต่ฉันเห็นได้ว่าผู้ดูแลระบบสามารถทำผิดพลาดได้อย่างไรเมื่อระบบเริ่มทำงาน


1
เพิ่มไปที่โครงสร้างพื้นฐาน VmWare ปกติควรมีความจุสำรอง - เพื่อให้คุณสามารถย้าย vm ไปยังโฮสต์และแพทช์อื่น ๆ ทำงานได้มากกว่า - ใช่ (MS iirc สามารถทำสิ่งนั้นได้โดยอัตโนมัติ) แต่ไม่หยุดทำงาน
TomTom

ที่ดียิ่งขึ้นคือเมื่อไม่มีใครเคยอัปเดตเฟิร์มแวร์หรือไดรเวอร์
SpacemanSpiff

ดังนั้นคุณกำลังพูดว่า: 1. ใช่มันเป็นงานการปรับปรุงและการอัพเดทการจัดทำเอกสารและการทดสอบกับเซิร์ฟเวอร์โลหะมากกว่า 2. Hypervisor โลหะเปลือยรับ / จำเป็นต้องปรับปรุงน้อยบ่อยกว่าระบบปฏิบัติการฉีด ตัวอย่าง ESXi 5.0 พร้อมอัปเดต 10 รายการใน 5 เดือน อย่างไรก็ตามจะมีมิเรอร์ของบัก Linux บางตัวสำหรับไฮเปอร์ไวเซอร์เหล่านั้นที่ใช้ Linux
user127379

6

นี่เป็นคำถามที่ดีถ้าคุณยังใหม่กับ virtualisation กับโฮสต์ 'metal metal' การทำสิ่งต่าง ๆ ในลักษณะนี้ต้องใช้ความคิดที่แตกต่างจากวิธีการที่คุณอาจใช้กับไฮเปอร์ไวเซอร์ที่ทำงานเป็นบริการ / แอปพลิเคชันด้านบนของระบบปฏิบัติการทั่วไป

จากประสบการณ์ของผมมันอาจจะยุติธรรมกล่าวว่า ESX และ HyperV จำเป็นน้อยปะโดยรวมกว่าระบบปฏิบัติการทั่วไป นี่ไม่ได้หมายความว่าพวกเขาไม่จำเป็นต้องทำการแก้ไขเลยหรือการใช้งานบางส่วนของแพทช์จะไม่เป็นประโยชน์โดยไม่คำนึงถึง "ต้องการ" แต่นี่หมายความว่าการขัดจังหวะการบริการของคุณเพื่อแก้ไขโฮสต์ควรจะบ่อยกว่าและ ภายใต้การควบคุมของคุณ มีความเสี่ยงด้านความปลอดภัยที่อาจเกิดขึ้นกับระบบปฏิบัติการ hypervisor เช่นเดียวกับคนอื่น ๆ และในขณะที่คุณสามารถลดความเสี่ยงนี้ได้ (เช่นการเปิดเผยการจัดการไฮเปอร์ไวเซอร์บน VLAN แยกที่ไม่สามารถเข้าถึงได้จากเซิร์ฟเวอร์ที่ถูกโจมตี) มันคงเป็นเรื่องโง่ที่จะแกล้งทำเป็นไม่มีความเสี่ยงเลย

ดังนั้นหากคุณมีเซิร์ฟเวอร์ที่ไม่ใช่เซิร์ฟเวอร์เสมือน 4 ตัวให้ย้ายและย้ายไปยังโฮสต์เสมือนจริงที่มีโฮสต์เดียวกันแต่ละตัวใช่แล้วคุณจะเพิ่มจำนวนของการหยุดชะงักที่อาจเกิดจากความจำเป็นในการแก้ไขระบบโฮสต์ (หรือจัดการกับ ปัญหาฮาร์ดแวร์ ฯลฯ สำหรับเรื่องนั้น)

ในขณะที่ผมขอแนะนำให้โอกาสที่จะเกิดขึ้นความเสี่ยงนี้เป็นที่ค่อนข้างต่ำ (ผมกำลังพูดถึงความแตกต่างระหว่างปะโฮสต์เสมือนและการเรียงลำดับของ patching ว่าต้องเริ่มต้นใหม่ที่คุณจะต้องทำเพื่อให้ระบบแบบสแตนด์อโลนเป็นอยู่แล้ว ) ไม่มีการหนีจากความจริงที่ว่าผลกระทบสูง

แล้วทำไมเราถึงทำอย่างนั้น?

ประโยชน์ที่แท้จริงของ virtualisation มาจากความสามารถในการตั้งค่ามากกว่าหนึ่งโฮสต์และกำหนดค่าโฮสต์ให้ทำงานร่วมกันช่วยให้แขกย้ายจากโฮสต์หนึ่งไปยังอีกในกรณีที่โฮสต์หนึ่งล้มเหลวหรือคุณต้องการกำหนดเวลาแก้ไขบน ระบบโฮสต์

การใช้วิธีการนี้ฉันจัดการแพตช์ ESX โฮสต์ 5 โฮสต์โดยไม่มีการหยุดชะงักใด ๆกับเซิร์ฟเวอร์เสมือน 40 ตัวที่ทำงานอยู่ด้านบน นี่เป็นเพียงเรื่องของการประหยัดต่อขนาด - เมื่อคุณมีเครื่องเสมือนแขกที่มีศักยภาพเพียงพอที่จะสร้างความคุ้มค่าในการสร้างการตั้งค่าที่ซับซ้อนและจัดการมันด้วยเครื่องมือประเภท @white กล่าวถึงในคำตอบของเขาการคืนทุนในการลดความเสี่ยง คุณเป็นห่วงเรื่องมาถึงอย่างรวดเร็ว


4

เซิร์ฟเวอร์เสมือนจะต้องการการบำรุงรักษาแบบเดียวกันและแก้ไขเซิร์ฟเวอร์แบบฟิสิคัลไฮเปอร์ไวเซอร์แบบโลหะเปลือยจะต้องมีการอัปเดตเพื่อความปลอดภัย แต่ต้องแก้ไขข้อบกพร่องและปรับปรุงประสิทธิภาพด้วย ยิ่งคุณมีเซิร์ฟเวอร์มากเท่าไหร่คุณก็ยิ่งต้องทำงานมากขึ้นเพื่อให้ทันสมัยอยู่เสมอไม่สำคัญว่าจะเป็นเซิร์ฟเวอร์จริงหรือเสมือนจริง


0

จากคำตอบข้างต้นดูเหมือนว่า: เซิร์ฟเวอร์เสมือนจริงได้นำเสนอความซับซ้อนและความเสี่ยงในการรักษาความปลอดภัยและความน่าเชื่อถือมากขึ้น แต่สิ่งเหล่านี้จำเป็นต้องได้รับการชั่งน้ำหนักเทียบกับประโยชน์ของความสามารถในการลดการหยุดทำงาน

หากสภาพแวดล้อมของคุณต้องการการตรวจสอบการทดสอบและการจัดทำเอกสารประโยชน์ด้านต้นทุนของภาระงานที่เพิ่มขึ้นของสภาพแวดล้อมเสมือนจริงจะต้องนำมาพิจารณาด้วยจำนวนเซิร์ฟเวอร์และเจ้าหน้าที่ระบบที่คุณมี ในสภาพแวดล้อมของเราเราไม่มีเวลาพนักงาน / พนักงานในการรักษาเส้นทางการตรวจสอบสำหรับสภาพแวดล้อมเสมือนจริง ในกระบวนการทางธุรกิจของเราเราสามารถหยุดทำงานได้ แต่เราไม่สามารถพลาดหลักฐานการตรวจสอบและเอกสารประกอบได้

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.