Để cập nhật hay không cập nhật?


12

Kể từ khi bắt đầu làm việc tại nơi tôi đang làm việc, tôi đã phải vật lộn vô tận với sếp và đồng nghiệp của mình về việc cập nhật hệ thống.

Tất nhiên tôi hoàn toàn đồng ý rằng mọi bản cập nhật (có thể là phần sụn, hệ điều hành hoặc ứng dụng) không nên được áp dụng một cách bất cẩn ngay khi phát hành, nhưng tôi cũng tin chắc rằng ít nhất nên có một số lý do nếu nhà cung cấp phát hành nó; và lý do phổ biến nhất thường là sửa một số lỗi ... có thể bạn chưa gặp phải bây giờ, nhưng bạn thể gặp phải sớm nếu bạn không theo kịp.

Điều này đặc biệt đúng đối với các bản sửa lỗi bảo mật; như một bài kiểm tra, có ai chỉ cần áp dụng một bản vá đã có sẵn trong nhiều tháng , SQL Slammercon sâu khét tiếng sẽ vô hại.

Tôi là tất cả để thử nghiệm và đánh giá các bản cập nhật trước khi triển khai chúng; nhưng tôi hoàn toàn không đồng ý với cách tiếp cận "nếu nó không bị hỏng thì đừng chạm vào nó" để quản lý hệ thống và nó thực sự làm tôi đau khi tìm thấy các hệ thống Windows 2003 SP1 hoặc ESX 3.5 Update 2 và câu trả lời duy nhất tôi có thể nhận được là "nó đang hoạt động, chúng tôi không muốn phá vỡ nó".

Bạn nghĩ gì về điều này? Chính sách của bạn
là gì? Và chính sách công ty của bạn là gì , nếu nó không phù hợp với chính bạn?

Còn những cập nhật firmware (BIOS, lưu trữ, v.v.) thì sao?
Còn những cập nhật hệ điều hành chính (gói dịch vụ) thì sao?
Còn những cập nhật hệ điều hành nhỏ thì sao?
Còn cập nhật ứng dụng thì sao?

Tất nhiên, mối quan tâm chính của tôi là cập nhật các máy chủ, vì việc quản lý bản vá máy khách thường đơn giản hơn và có các công cụ nổi tiếng và thực tiễn tốt nhất để xử lý nó.


1
Chào mừng đến với thế giới của tôi. Tôi có nhiều máy Windows 2003 SP1 hơn tôi muốn biết và chính sách vá / cập nhật không bao gồm máy chủ. Tôi có những khoảnh khắc thường xuyên cố gắng thuyết phục quản lý của mình và khách hàng rằng điều này rất quan trọng để giải quyết.
Mitch

Gần 5 năm sau khi câu hỏi này được đăng, nơi tôi làm việc, chúng tôi vẫn có máy chủ của mình trên Windows Server 2003 với các bản cập nhật bị tắt. Quản lý không thể đưa ra quyết định về những việc cần làm sau nhiều tháng nói chuyện.
MrLane

Câu trả lời:


10

Bảo mật và nhanh nhẹn nên được cân bằng với sự ổn định và thời gian hoạt động khi xác định chiến lược vá lỗi của bạn. Cách tiếp cận đẩy lùi của bạn cho vấn đề này phải tuân theo dòng 'Được rồi, nhưng bạn cần biết rằng chúng tôi hiện đang có nguy cơ các máy chủ này bị xâm phạm và khiến dữ liệu của chúng tôi bị đánh cắp hoặc khiến các máy chủ không hoạt động' và 'Được rồi, nhưng bạn cần biết rằng điều này tác động đến sự hỗ trợ của nhà cung cấp cho hệ thống này và khả năng tương lai để hệ thống này tương tác với các hệ thống mới'.

Chống lại tâm lý 'không phá vỡ, không cập nhật' dài hạn, bạn nên nói rõ rằng:

  • Chuyển một hệ thống di sản chưa được vá đó là cách rơi đằng sau sang một hệ thống hiện đại là một nhiều quá trình đắt và đau đớn hơn dần dần cập nhật hệ thống theo thời gian.
  • Nhân viên CNTT có kinh nghiệm và có kỹ năng tích cực tìm kiếm công nghệ mới và các công ty không ngừng phát triển hệ thống CNTT của họ. Có một chi phí rất lớn về doanh thu, mất cơ hội và mất kiến ​​thức khi một công ty mất đi đội ngũ nhân viên CNTT sáng tạo, gắn bó cao do hệ thống của họ bị đình trệ và trở nên không hấp dẫn để làm việc. Sau đó, tất cả những gì bạn còn lại là 'người nâng đỡ'.

Hy vọng điều này mang lại cho bạn một số đòn bẩy và may mắn nhất trong việc thuyết phục các aboves thực hiện mọi việc một cách nghiêm túc. Như mọi khi, hãy thiết lập một dấu vết giấy chứng tỏ bạn đã quản lý các rủi ro mà họ đang gặp phải.


4
+1, Gần đây chúng tôi gặp sự cố với một hệ thống, được gọi là nhà cung cấp, chúng tôi đã không cập nhật trong khoảng 18 tháng, điều đầu tiên họ nói là "cập nhật, sau đó gọi cho chúng tôi nếu nó vẫn không hoạt động".
Chris S

3

Đây là một cuộc tranh luận bất tận và những người hợp lý sẽ không đồng ý. Nếu bạn đang nói về PC người dùng, tôi đồng ý rằng họ cần được cập nhật. Nếu bạn đang nói về máy chủ, hãy xem xét một chính sách riêng cho các máy chủ phải đối mặt với internet và những máy chủ không có. Tôi không biết về máy chủ của bạn nhưng trong môi trường của tôi, có thể 10% máy chủ của chúng tôi có cổng mở ra internet. Các máy chủ truy cập internet này được ưu tiên cao nhất khi nói đến các bản vá bảo mật. Máy chủ không phải đối mặt với internet là ưu tiên thấp hơn.

Các chuyên gia bảo mật sẽ lập luận rằng cách tiếp cận này có vấn đề bởi vì nếu tin tặc xâm nhập vào mạng của bạn, các máy chủ chưa được vá sẽ cho phép khai thác để xáo trộn qua mạng như cháy rừng và đó là một lý lẽ hợp lý. Tuy nhiên, nếu bạn giữ các máy chủ trực tuyến bị khóa chặt và cấu hình đúng tường lửa của bạn để chỉ mở các cổng đó là hoàn toàn cần thiết, tôi nghĩ cách tiếp cận này hoạt động và thường có thể được sử dụng để xoa dịu các nhà quản lý sợ các bản vá.

Nếu bạn chỉ dựa vào Windows Update cho các bản vá (bạn không đề cập đến hệ điều hành nào bạn đang chạy nhưng tôi hầu hết là một người Windows nên đây là tài liệu tham khảo của tôi), hãy xem các hotfix thực tế được phát hành mỗi tháng . Tôi có một số máy chủ mà nếu tôi chạy Windows Update trên chúng, tôi sẽ được bảo là tôi cần hơn 50 bản vá nhưng nếu tôi cuộn qua các bản vá đó và nghiên cứu từng bản đó, tôi sẽ thấy rằng 90% các mục là bản vá không bảo mật liên quan nhưng sửa các lỗi ảnh hưởng đến các dịch vụ tôi không chạy trên hộp đó. Trong các môi trường lớn hơn nơi bạn sử dụng hệ thống quản lý bản vá, việc xem xét mọi thứ được phát hành là điều phổ biến và chỉ bận tâm với những gì thực sự cần thiết và thường chiếm khoảng 10% những gì Microsoft phát hành.

Lập luận của tôi là cuộc tranh luận về việc "vá hay không vá" cho thấy bạn phải ở bên này hay bên kia khi, thực sự, đây là một khu vực màu xám khổng lồ.


2
Tôi cũng thực sự quan tâm đến các bản vá sửa lỗi; quá nhiều lần tôi đã gặp phải các lỗi đã được nhà cung cấp sửa chữa, nhưng không ai bận tâm đến việc áp dụng các bản vá. Điều này đặc biệt nguy hiểm với phần cứng.
Massimo

3

Tôi chỉ có thể nói về máy chủ nhưng chúng tôi có chế độ 'Cập nhật hàng quý', vào bốn ngày được xác định trước và công bố mỗi năm, chúng tôi tập hợp các yêu cầu cập nhật, áp dụng chúng vào môi trường tham chiếu của chúng tôi, chạy chúng trong một tháng để kiểm tra sự ổn định và nếu triển khai tốt trong n ngày / tuần sau. Trên hết, chúng tôi áp dụng chính sách cập nhật khẩn cấp, nơi chúng tôi có khả năng triển khai thành tài liệu tham khảo, thử nghiệm và đưa ra các bản cập nhật khẩn cấp trong vòng một hoặc hai ngày nếu mức độ nghiêm trọng là như vậy - mặc dù điều này chỉ được sử dụng 2/3 lần cuối cùng 4 năm hoặc lâu hơn.

Cách tiếp cận song sinh này đảm bảo rằng các máy chủ của chúng tôi hợp lý, nhưng không ngu ngốc, cập nhật, các bản cập nhật được điều khiển bởi các chuyên gia về chủ đề (ví dụ: phần sụn, trình điều khiển, nhân viên ứng dụng) không phải nhà cung cấp nhưng nó cũng cho phép khắc phục nhanh nếu cần thiết. Tất nhiên, chúng tôi rất may mắn khi có rất ít mô hình phần cứng khác nhau trên toàn bộ doanh nghiệp (<10 biến máy chủ) và khá lớn, và cập nhật, các nền tảng tham chiếu để kiểm tra.


+1. Chúng tôi có một chính sách cập nhật gần như giống hệt nhau.
joeqwerty

1

Tôi đã làm việc tại các công ty khác nhau có chính sách liên tục từ "áp dụng các bản vá càng sớm càng tốt, chúng tôi không quan tâm nếu họ phá vỡ thứ gì đó chúng tôi đang làm việc - chúng tôi sẽ hỗ trợ họ sau đó" thành "không có gì được áp dụng mà không cần hai tuần kiểm tra. " Cả hai thái cực (và các điểm ở giữa) đều tốt miễn là Công ty hiểu được sự đánh đổi .

Đó là điểm quan trọng: không có câu trả lời cụ thể đúng hay sai cho câu hỏi này; đó là vấn đề cân bằng giữa ổn định và an toàn hoặc các tính năng trong môi trường cụ thể của bạn . Nếu chuỗi quản lý của bạn hiểu rằng việc trì hoãn các bản vá để thử nghiệm có thể khiến chúng dễ bị phần mềm độc hại hơn, điều đó tốt. Tương tự như vậy, nếu họ hiểu rằng việc áp dụng các bản vá ngay khi chúng có sẵn có thể không hoạt động hoặc thậm chí phá vỡ cấu hình hệ thống cụ thể của bạn, điều đó cũng tốt. Vấn đề tồn tại khi những sự đánh đổi này không được hiểu.


1

Quan điểm của tôi là khóa học tốt nhất là khá nhiều cú đánh ở giữa hai thái cực của bạn. ví dụ: Tại sao bạn rất muốn nâng cấp ESX nếu không có lý do rõ ràng để làm như vậy, có thể phá vỡ các hệ thống làm việc trong quy trình? Chắc chắn nó có thể dễ bị tổn thương nếu nó phải đối mặt công khai nhưng không có cách nào có thể truy cập trực tiếp từ bên ngoài mạng của bạn, vậy rủi ro ở đâu? Có bất kỳ lỗi hoặc thiếu các tính năng thực sự trình bày cho bạn một lý do để nâng cấp?

Nâng cấp vì lợi ích của nó, đó thực sự là những gì bạn đang đề xuất ("nhưng bạn sẽ sớm gặp phải"), ngay cả khi khẳng định bạn không phải, là một con đường vô lý và nguy hiểm để đi du lịch. Trừ khi bạn có thể trình bày một lý do thực tế , trái với lý do có thể về mặt lý thuyết, bạn sẽ không bao giờ thuyết phục người khác nếu họ phản đối việc nâng cấp.

Nếu bạn tin rằng có một lý do thực sự để thực hiện nâng cấp, bạn nên ghi lại cả ưu và nhược điểm, và luôn có những khuyết điểm, và trình bày điều đó cho những người cao hơn trên cây. Tài liệu đúng nên có ít sức đề kháng. Nếu bạn không thể đưa ra một lập luận thuyết phục thì hãy ngồi lại và suy nghĩ nghiêm túc.

Biên tập

Tôi nghĩ rằng tôi nên làm rõ rằng tôi thấy một sự khác biệt lớn giữa việc áp dụng các bản vá bảo mật và độ ổn định cần thiết so với việc nâng cấp phần mềm hoặc hệ điều hành. Việc đầu tiên tôi thực hiện sau khi thử nghiệm thích hợp. Sau này tôi chỉ làm nếu có lợi ích thực sự.


0

Các cập nhật bảo mật được gửi đến một máy chủ dàn dựng, sau đó sản xuất sau khi chúng cho thấy rằng chúng không làm nổ tung mọi thứ. Trừ khi có một thực bleep ing khẩn cấp (mà tôi đã đánh một vài lần :(), trong trường hợp đó SẢN XUẤT VỚI DOANH NGHIỆP. Cập nhật khác chỉ theo yêu cầu, sau khi trải qua thời gian trong dàn.


0

Tôi nghĩ rằng điều đầu tiên cần làm là "phân loại" các cập nhật theo mức độ nghiêm trọng và có lịch trình vá lỗi dựa trên phân loại. Không có nghi ngờ sửa chữa bảo mật zero-day phải được áp dụng ngay lập tức; trong khi Gói dịch vụ có thể đợi sau khi đánh giá cẩn thận.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.