Người dùng VMware đang chuyển sang Proxmox, nhưng vấn đề bảo mật đang bị ảnh hưởng: nhiều người đang bỏ qua các bản cập nhật.

VMware rất tốn kém, giấy phép thay đổi sáu tháng một lần, vì vậy các quản trị viên phải thắt chặt chi phí và di chuyển máy ảo (VM) của họ sang Proxmox. Lợi ích trước mắt: không còn hóa đơn hàng năm khổng lồ. Thiệt hại trước mắt: sự nghiêm ngặt của việc quản lý bản vá. Kết quả: các cụm hoàn toàn mới, nhưng các kernel đã hai tháng tuổi khiến các lỗ hổng bảo mật vẫn còn bỏ ngỏ. Đây là nhược điểm mà những người ra quyết định đánh giá thấp.

Di chuyển VMware sang Proxmox: tiết kiệm chi phí, lỗ hổng bảo mật là một lợi ích

Phép tính có vẻ hiển nhiên: một node ESXi + vCenter + vSAN tiêu tốn đáng kể ngân sách. Ngược lại, Proxmox cài đặt trong hai mươi phút, chạy trên phần cứng tái chế và chỉ yêu cầu đăng ký tùy chọn. Một số doanh nghiệp vừa và nhỏ ở khu vực Paris đã giảm chi phí ảo hóa xuống mười lần trong năm đầu tiên. Tuy nhiên, hoạt động này lại tạo ra một điểm mù. Tại Dupont Electronics, nhóm đã sao chép 120 máy ảo (VM) bằng QEMU và nhập lại các đĩa ở định dạng thô. Quá háo hức chứng minh lợi nhuận (ROI), họ đã bỏ qua việc cấu hình kho lưu trữ APT. Một tháng sau, một lỗ hổng CVE trên bộ lưu trữ Ceph vẫn còn đó, do thiếu lệnh “apt update && apt full-upgrade” đơn giản. Tin tặc rất thích kiểu nâng cấp vội vã này: các cổng vẫn bị lộ, ngăn xếp kernel dễ bị tấn công, và SOC phát hiện ra lỗ hổng khi đã quá muộn. Các bản vá Proxmox bị bỏ quên: lý do tại sao một hệ thống đơn giản lại bị quản lý kém. Không cần phải vòng vo: giao diện cập nhật Proxmox quá cơ bản. Không có bảng điều khiển hào nhoáng như Nutanix. Kết quả là, các quản trị viên cấp thấp thường trì hoãn công việc. Họ thích nhấp vào GUI hơn là nhập “pveupdate”. Vấn đề: Công cụ gửi bản vá nhanh hơn bao giờ hết. VMware

hoặc

Microsoft Hyper-V Bỏ qua những gói này cũng giống như từ chối một chiếc áo chống đạn miễn phí. Tại WebMed, một máy chủ lưu trữ đã chạy chậm ba phiên bản. Vào ngày một máy ảo quan trọng bị tải nặng, chức năng di chuyển trực tiếp bị sập hoàn toàn, trả về một dấu vết Python. Một bản vá được phát hành vào ngày hôm trước đã khắc phục lỗi. Không ai áp dụng nó. Sự lười biếng này còn tốn kém hơn cả giấy phép. Cần bằng chứng không? Video này từ cơ quan SecPatch cho thấy cách một shell cục bộ trở thành root trong mười giây trên một cụm chưa được cập nhật. Cập nhật hay thất bại: tình thế tiến thoái lưỡng nan sau khi di chuyển đối với các doanh nghiệp vừa và nhỏ. Sếp muốn thời gian chết bằng không. Quản trị viên muốn khởi động lại các nút. Hãy chọn phe của bạn. Trong thực tế, bạn đặt một khoảng thời gian và kiểm tra trước. Các phương pháp cũ vẫn hoạt động: sao chép, bật nguồn, khôi phục nếu có sự cố. Tuy nhiên, nhiều người vẫn để máy chủ chạy cho đến khi một đĩa bị lỗi. Fred, một nhà thầu cho một phòng khám y tế, đã thử vá kernel vào giữa buổi chiều. Kết quả: khởi động lại, khởi động không thành công và cơ sở dữ liệu PostgreSQL bị hỏng. Anh ấy thề sẽ không bao giờ mắc lỗi đó nữa. Thời gian bảo trì phải được đưa trở lại vào kế hoạch, ngay cả khi điều đó đồng nghĩa với việc bán nó như một “bảo hiểm sinh tồn”. Nếu không có nó, lời hứa về phần mềm miễn phí sẽ trở thành cơn ác mộng. Quản lý bản vá mà không cần bảng điều khiển trả phí: tập lệnh, Git và sự nghiêm ngặt. Bạn không cần một SaaS đắt đỏ để duy trì sự sạch sẽ. Kho lưu trữ Git, một hook Ansible và mỗi máy chủ Proxmox sẽ đồng thời tải các bản cập nhật. Tại Alpha-Tech, runbook chỉ gói gọn trong ba trang: ảnh chụp nhanh, nâng cấp, khởi động lại, xác minh. Không cần đến phép thuật. Các tập lệnh Bash sẽ làm những công việc khó khăn, và việc giám sát thông qua OpenStack Monasca sẽ báo động. Ngay cả Citrix XenServer và Oracle VM cũng vậy. Họ có thể làm theo cùng một mô hình. Ý tưởng chính: tự động hóa, sau đó xác minh. Quản trị viên phê duyệt bản vá trong môi trường sản xuất mà không chạy thử sẽ phải dành cả cuối tuần để khôi phục bản sao lưu. Lý lẽ tốt nhất cho sếp: thời gian ngừng hoạt động theo kế hoạch ít tốn kém hơn một ngày khủng hoảng do nhà cung cấp dịch vụ được quản lý tính phí. Bài phát biểu của tác giả tập lệnh “pve-autoupdate” nêu chi tiết về cách tiếp cận này. Giữa Hyper-V, KVM và Proxmox: duy trì, kết hợp hay bắt đầu lại? Không ai loại trừ khả năng lai ghép. Một số công ty khởi nghiệp vẫn giữ Microsoft Hyper-V cho khối lượng công việc Windows, sử dụng KVMthông qua

Proxmox

cho Linux và thử nghiệm

Red Hat Virtualization

trên một nút thí điểm. Điều quan trọng là tính kỷ luật đối với các bản cập nhật. Các nhà cung cấp thay đổi, nhưng bề mặt tấn công vẫn còn. Sai lầm sẽ là tin rằng một trình quản lý ảo hóa nguồn mở sẽ dung thứ cho sự cẩu thả hơn. Cuối cùng, bảo mật luôn dựa trên ba trụ cột giống nhau: các bản vá được áp dụng, các bản sao lưu được kiểm tra và giám sát để phát hiện báo động trước khi xảy ra lỗi. Các tổ chức duy trì được ba trụ cột này sẽ có thể yên tâm, cho dù họ sử dụng VMware, Proxmox hay một sản phẩm tương lai nào đó chưa được biết đến.