Các yêu cầu kinh doanh xung đột là một vấn đề phổ biến – và bạn tìm thấy nó ở mọi ngóc ngách của tổ chức, kể cả trong công nghệ thông tin. Giải quyết những xung đột này là điều bắt buộc, nhưng không phải lúc nào cũng dễ dàng – mặc dù đôi khi có một giải pháp mới hữu ích.
Trong quản lý CNTT, có một cuộc đấu tranh liên tục giữa các đội bảo mật và vận hành. Đúng vậy, cả hai nhóm cuối cùng đều muốn có các hệ thống an toàn khó bị vi phạm hơn. Tuy nhiên, bảo mật có thể đi kèm với chi phí sẵn có – và ngược lại. Trong bài viết này, chúng ta sẽ xem xét tính khả dụng so với xung đột bảo mật và giải pháp giúp giải quyết xung đột đó.
Nhóm hoạt động tập trung vào tính khả dụng… nhóm an ninh khóa
Các nhóm vận hành sẽ luôn có sự ổn định và do đó tính sẵn sàng là ưu tiên hàng đầu. Có, các nhóm hoạt động cũng sẽ ưu tiên bảo mật nhưng chỉ khi nó đề cập đến tính ổn định hoặc tính khả dụng, không bao giờ là mục tiêu tuyệt đối.
Nó diễn ra trong mục tiêu thời gian hoạt động “năm chín” đặt ra một yêu cầu cực kỳ cao – rằng một hệ thống đang chạy và sẵn sàng phục vụ các yêu cầu 99,999% thời gian. Đó là một mục tiêu đáng khen ngợi giúp các bên liên quan luôn hài lòng. Các công cụ như tính sẵn sàng cao sẽ trợ giúp ở đây bằng cách cung cấp dự phòng mức độ dịch vụ hoặc hệ thống, nhưng các mục tiêu bảo mật có thể nhanh chóng cản trở việc đạt được “năm chín”.
Đối với các đội bảo mật, mục tiêu cuối cùng là khóa các hệ thống càng tốt, giảm bề mặt tấn công và mức độ rủi ro tổng thể xuống mức tối thiểu tuyệt đối. Trên thực tế, các nhóm bảo mật có thể đưa ra yêu cầu rằng hệ thống phải ngừng hoạt động để vá ngay bây giờ chứ không phải hai tuần kể từ bây giờ, giảm khả năng sẵn sàng để vá ngay lập tức – đừng bận tâm đến hậu quả đối với người dùng.
Dễ dàng nhận thấy rằng cách tiếp cận này sẽ gây ra một cơn đau đầu lớn cho các đội hoạt động. Tệ hơn nữa, khi tính sẵn sàng cao thực sự giúp các nhóm hoạt động đạt được mục tiêu về tính khả dụng và ổn định, thì trên thực tế, vấn đề có thể khiến vấn đề tồi tệ hơn đối với các nhóm bảo mật, những người hiện phải chăm sóc số lượng máy chủ hoặc dịch vụ tăng theo cấp số nhân, tất cả đều yêu cầu bảo vệ và giám sát.
Thực hành tốt nhất để làm theo?
Nó tạo ra xung đột giữa hoạt động và bảo mật, có nghĩa là hai nhóm nhanh chóng mâu thuẫn về các chủ đề như các quy trình và phương pháp hay nhất. Khi nghĩ đến việc vá lỗi, chính sách vá lỗi dựa trên cửa sổ bảo trì sẽ ít gây gián đoạn hơn và tăng tính khả dụng vì có độ trễ nhiều tuần giữa các nỗ lực vá lỗi và thời gian ngừng hoạt động liên quan.
Nhưng có một điểm khó khăn: các cửa sổ bảo trì không vá đủ nhanh để bảo vệ đúng cách trước các mối đe dọa mới nổi vì những mối đe dọa này thường bị khai thác tích cực trong vòng vài phút sau khi tiết lộ (hoặc thậm chí trước khi tiết lộ, ví dụ như Log4j).
Vấn đề xảy ra trên tất cả các loại khối lượng công việc và nó không thực sự quan trọng cho dù bạn đang sử dụng DevOps, DevSecOps mới nhất hay bất kỳ phương pháp tiếp cận nào như là hương vị của ngày. Cuối cùng, bạn có thể vá nhanh hơn cho các hoạt động an toàn với chi phí khả dụng hoặc hiệu suất, hoặc vá chậm hơn và chịu rủi ro không thể chấp nhận được với bảo mật.
Nó nhanh chóng trở nên thực sự phức tạp
Quyết định tốc độ vá lỗi mới chỉ là bước khởi đầu. Đôi khi, việc vá lỗi không hề đơn giản. Ví dụ, bạn có thể xử lý các lỗ hổng ở cấp độ ngôn ngữ lập trình – từ đó tác động đến các ứng dụng được viết bằng ngôn ngữ đó, ví dụ: CVE-2022-31626, một lỗ hổng PHP.
Khi điều này xảy ra, có một nhóm khác tham gia vào xung đột tính khả dụng và bảo mật: các nhà phát triển cần xử lý lỗ hổng ở cấp độ ngôn ngữ trong hai bước. Đầu tiên, bằng cách cập nhật phiên bản ngôn ngữ được đề cập, đây là phần dễ dàng.
Nhưng cập nhật một phiên bản ngôn ngữ không chỉ mang lại những cải tiến về bảo mật; nó cũng mang lại những thay đổi cơ bản khác. Đó là lý do tại sao các nhà phát triển cần phải trải qua bước thứ hai: bù đắp cho những thay đổi ở cấp độ ngôn ngữ do viết lại mã ứng dụng.
Điều đó cũng có nghĩa là kiểm tra lại và thậm chí chứng nhận lại trong một số trường hợp. Cũng giống như các nhóm hoạt động muốn tránh thời gian ngừng hoạt động liên quan đến khởi động lại, các nhà phát triển thực sự muốn tránh các chỉnh sửa mã mở rộng càng lâu càng tốt vì nó ngụ ý công việc chính, vâng, đảm bảo an ninh chặt chẽ hơn – nhưng mặt khác khiến các nhà phát triển không có gì để hiển thị cho thời gian của họ .
Bạn có thể dễ dàng thấy tại sao các quy trình quản lý bản vá hiện tại lại gây ra xung đột nhiều lớp giữa các nhóm. Chính sách từ trên xuống dưới có thể giải quyết vấn đề ở một mức độ nào đó, nhưng nó thường có nghĩa là không ai thực sự hài lòng với kết quả.
Tệ hơn nữa, các chính sách này thường có thể làm tổn hại đến bảo mật bằng cách để các hệ thống chưa được vá trong thời gian quá dài. Các hệ thống vá lỗi định kỳ hàng tuần hoặc hàng tháng với suy nghĩ rằng rủi ro là điều có thể chấp nhận được, ở mức độ đe dọa hiện tại, sớm hay muộn cũng phải kiểm tra thực tế nghiêm túc.
Có một lộ trình để giảm thiểu đáng kể – hoặc thậm chí giải quyết xung đột giữa bản vá ngay lập tức (và sự gián đoạn) và bản vá bị trì hoãn (và lỗ hổng bảo mật). Câu trả lời nằm ở việc vá lỗi không gây gián đoạn và không có ma sát, ở mọi cấp độ hoặc ít nhất là nhiều cấp độ phù hợp với thực tế.
Vá không ma sát có thể giải quyết xung đột
Bản vá trực tiếp là công cụ vá dễ dàng mà nhóm bảo mật của bạn nên tìm kiếm. Nhờ bản vá trực tiếp, bạn vá lỗi nhanh hơn nhiều so với các cửa sổ bảo trì thường xuyên có thể hy vọng đạt được và không bao giờ cần phải khởi động lại dịch vụ để áp dụng các bản cập nhật. Bản vá nhanh chóng và an toàn, cùng với thời gian chết ít hoặc không có. Một cách đơn giản, hiệu quả để giải quyết xung đột giữa tính khả dụng và bảo mật.
Tại TuxCare, chúng tôi cung cấp bản vá trực tiếp toàn diện cho các thành phần hệ thống Linux quan trọng và các bản vá cho nhiều ngôn ngữ lập trình và các phiên bản ngôn ngữ lập trình tập trung vào các vấn đề bảo mật và không đưa ra các thay đổi ở cấp độ ngôn ngữ có thể buộc phải cấu trúc lại mã – mã của bạn sẽ tiếp tục chạy như- là, chỉ một cách an toàn. Ngay cả khi doanh nghiệp của bạn dựa vào các ứng dụng không được hỗ trợ, bạn sẽ không phải lo lắng về các lỗ hổng xâm nhập vào hệ thống của mình thông qua một lỗ hổng ngôn ngữ lập trình – và bạn cũng không cần phải cập nhật mã ứng dụng.
Vì vậy, tóm lại, trong tình trạng sẵn có và xung đột bảo mật, bản vá trực tiếp là một công cụ có thể làm giảm đáng kể sự căng thẳng giữa các hoạt động và đội bảo mật.
.
