Các vùng chứa đã cách mạng hóa quy trình phát triển, đóng vai trò là nền tảng cho các sáng kiến DevOps, nhưng các vùng chứa mang lại những rủi ro bảo mật phức tạp mà không phải lúc nào cũng rõ ràng. Các tổ chức không giảm thiểu những rủi ro này rất dễ bị tấn công.
Trong bài viết này, chúng tôi trình bày cách các vùng chứa đã đóng góp vào sự phát triển nhanh nhẹn, những rủi ro bảo mật duy nhất mà vùng chứa mang lại – và các tổ chức có thể làm gì để đảm bảo khối lượng công việc được chứa trong vùng chứa, vượt ra ngoài DevOps để đạt được DevSecOps.
Tại sao các container lại tăng nhanh như vậy?
Theo nhiều cách, các container là sự phát triển của ảo hóa. Mục đích là để tăng tốc quá trình phát triển, tạo ra một lộ trình nhanh nhẹn hơn từ phát triển đến kiểm tra và thực hiện – dù sao thì một phương pháp nhẹ hơn so với việc sử dụng các máy ảo toàn diện.
Cốt lõi của vấn đề này là khả năng tương thích của ứng dụng, vì các ứng dụng yêu cầu một số phiên bản thư viện nhất định – điều này có thể mâu thuẫn với các yêu cầu của các ứng dụng khác. Các vùng chứa đã khắc phục sự cố này và tình cờ liên kết tốt với các quy trình phát triển và cơ sở hạ tầng quản lý thúc đẩy các quy trình này.
Các vùng chứa thực hiện công việc của họ bằng cách đưa ảo hóa lên cấp độ tiếp theo. Ảo hóa trừu tượng hóa lớp phần cứng, trong khi các thùng chứa trừu tượng hóa lớp hệ điều hành, về cơ bản ảo hóa vai trò của hệ điều hành. Containerization hoạt động bằng cách đóng gói các ứng dụng thành “vùng chứa” bao gồm tất cả các thư viện cần thiết để làm cho một ứng dụng hoạt động, đồng thời giữ cho các ứng dụng không nhận biết nhau vì mỗi ứng dụng nghĩ rằng nó có Hệ điều hành cho riêng mình.
Về mặt chức năng, vùng chứa khá đơn giản – vùng chứa chỉ là một tệp văn bản với mô tả phác thảo những thành phần nào nên được bao gồm trong một thể hiện. Sự đơn giản này và bản chất nhẹ hơn của vùng chứa giúp dễ dàng sử dụng các công cụ tự động hóa (điều phối) để triển khai trong suốt vòng đời phát triển.
DevOps để giành chiến thắng… nhưng vấn đề bảo mật cũng vậy
Các vùng chứa có khả năng tăng cường đáng kể hiệu quả phát triển – đóng vai trò như chìa khóa mở khóa DevOps. Đó có thể là một trong những lý do chính tại sao container được phát triển rộng rãi như vậy, với Gartner ước tính rằng vào năm 2023, 70% tổ chức sẽ vận hành khối lượng công việc đóng container.
Quá trình phát triển, thử nghiệm và triển khai ứng dụng từng chứa đầy những trở ngại, với sự qua lại liên tục giữa các nhà phát triển và các nhóm chăm sóc cơ sở hạ tầng. Ngày nay, nhờ các thùng chứa, các nhà phát triển có thể xây dựng và thử nghiệm trong một môi trường hoạt động và chỉ cần gửi mã hoàn thiện cùng với một thông số kỹ thuật xác định môi trường đó.
Về phía các nhóm hoạt động chỉ đơn thuần thực hiện thông số kỹ thuật này để tạo ra một môi trường phù hợp sẵn sàng sử dụng. “Có, nhưng nó hoạt động trên máy của tôi …” chưa bao giờ giúp khắc phục sự cố – nhưng ngày nay, đó là một biểu thức mà các nhà phát triển biểu thức không cần sử dụng nữa vì không có vấn đề môi trường nào để gỡ lỗi.
Vì vậy, vâng, DevOps có nghĩa là phát triển nhanh chóng. Nhưng có một thành phần còn thiếu: bảo mật. Đây là lý do tại sao chúng ta ngày càng nghe nhiều hơn về DevSecOps khi nó phát triển từ DevOps vì các nhà phát triển nhận thấy rằng chỉ riêng mô hình DevOps không đủ giải quyết các mối quan tâm về bảo mật.
Các thùng chứa có một số rủi ro bảo mật
Các vùng chứa đơn giản hóa quá trình phát triển nhưng đưa sự phức tạp vào bức tranh an ninh. Khi bạn đóng gói chặt chẽ toàn bộ môi trường hoạt động vào một thùng chứa chỉ để phân phối nó rộng rãi, bạn cũng tăng bề mặt tấn công và mở ra cánh cửa cho các vectơ tấn công khác nhau. Bất kỳ thư viện dễ bị tấn công nào được đóng gói với vùng chứa sẽ lây lan các lỗ hổng này qua vô số khối lượng công việc.
Có một số rủi ro. Một là “cuộc tấn công chuỗi cung ứng” trong đó một tác nhân ác độc thực hiện một cuộc tấn công không phải bằng cách gây rối với ứng dụng của bạn, mà bằng cách sửa đổi một trong các gói hoặc thành phần được cung cấp cùng với ứng dụng của bạn. Vì vậy, các nhóm chăm sóc các nỗ lực phát triển cần phải đánh giá ứng dụng mà họ đang phát triển và mọi thư viện được cấu hình vùng chứa kéo vào như một phần phụ thuộc.
Các rủi ro đối với bảo mật vùng chứa cũng liên quan đến các công cụ cho phép vùng chứa – từ Dockers đến các công cụ điều phối như Kubernetes, vì những công cụ này cần được giám sát và bảo vệ. Ví dụ: bạn không nên cho phép các sysadmins chạy các vùng chứa Docker với tư cách là người chủ. Tương tự như vậy, bạn cần phải bảo vệ chặt chẽ các sổ đăng ký vùng chứa của mình để đảm bảo rằng chúng không bị xâm phạm.
Bảo mật hạt nhân ở cốt lõi của bảo mật vùng chứa
Một số rủi ro bảo mật liên quan đến vùng chứa ít được nhìn thấy hơn những rủi ro khác. Mọi vùng chứa đều cần quyền truy cập vào một hạt nhân – xét cho cùng, các vùng chứa chỉ là một kiểu cách ly quy trình nâng cao. Nhưng rất dễ bỏ lỡ thực tế là tất cả các vùng chứa đều dựa trên cùng một nhân – không quan trọng là các ứng dụng bên trong các vùng chứa được tách biệt với nhau.
Kernel mà các ứng dụng trong vùng chứa nhìn thấy giống với hạt nhân mà máy chủ dựa vào để hoạt động. Nó mang lại một số vấn đề. Nếu hạt nhân trên máy chủ hỗ trợ vùng chứa dễ bị khai thác, thì lỗ hổng này có thể bị khai thác bằng cách bắt đầu tấn công từ một ứng dụng bên trong vùng chứa.
Vì vậy, việc hạt nhân được chia sẻ bởi tất cả các vùng chứa trên máy chủ có nghĩa là một hạt nhân bị lỗi phải được vá nhanh chóng, hoặc tất cả các vùng chứa có thể nhanh chóng bị ảnh hưởng bởi lỗ hổng.
Tuy nhiên, một lần nữa, nó đi xuống để vá
Do đó, giữ cho hạt nhân của máy chủ được cập nhật là một bước quan trọng trong việc đảm bảo các hoạt động vùng chứa an toàn và bảo mật. Và không chỉ hạt nhân cần vá, các bản vá phải được áp dụng cho các thư viện được kéo vào bởi một vùng chứa. Tuy nhiên, như chúng ta biết, việc vá lỗi một cách nhất quán nói thì dễ hơn làm. Đó có lẽ là lý do tại sao một nghiên cứu đã phát hiện ra rằng 75% các container được phân tích có chứa một lỗ hổng được phân loại là nguy cơ nghiêm trọng hoặc nguy cơ cao.
Các lỗ hổng này có thể dẫn đến, ví dụ, dẫn đến các cuộc tấn công đột phá trong đó kẻ tấn công dựa vào một thư viện bị lỗi bên trong vùng chứa để có thể thực thi mã bên ngoài vùng chứa. Bằng cách xâm phạm một vùng chứa, kẻ tấn công cuối cùng có thể tiếp cận mục tiêu dự kiến của chúng cho dù đó là hệ thống máy chủ hay một ứng dụng trong vùng chứa khác.
Trong bối cảnh các vùng chứa, việc duy trì các thư viện an toàn có thể là một vấn đề thực sự đau đầu – ai đó cần theo dõi các lỗ hổng mới cũng như những gì đã được vá và những gì chưa. Quá trình này tốn nhiều công sức, nhưng nó cũng đòi hỏi các kỹ năng chuyên môn, đây là thứ mà tổ chức của bạn sẽ cần phải có nếu tổ chức của bạn chưa có.
Với giá trị của việc vá lỗi thường xuyên, nhất quán, những lý do đó không đủ để gây ra loại quy trình vá lỗi mà chúng ta thấy, nhưng – đặc biệt khi nghĩ về hạt nhân hệ điều hành – sự gián đoạn của các lần khởi động lại bắt buộc và liên kết cần duy trì các cửa sổ thời gian chết có thể trì hoãn đáng kể việc vá lỗi. Bản vá trực tiếp hạt nhân giúp giảm thiểu vấn đề này, nhưng nó vẫn chưa được triển khai bởi tất cả các tổ chức.
Luôn bao gồm các mục tiêu bảo mật trong hoạt động vùng chứa của bạn
Việc công nghệ tiên tiến tạo ra những phức tạp mới khi nói đến bảo mật thông tin là điều thường thấy. Các công cụ mới thường dẫn đến các khai thác mới và mới lạ. Điều đó cũng đúng đối với vùng chứa và mặc dù nó không làm giảm giá trị tổng thể của việc sử dụng vùng chứa trong khối lượng công việc của bạn, nhưng điều đó có nghĩa là bạn cần phải theo dõi những rủi ro do vùng chứa gây ra.
Việc giáo dục các nhà phát triển và hệ thống của bạn về các lỗi phổ biến trong bảo mật vùng chứa và các phương pháp hay nhất để giảm thiểu những sai sót này là một bước khởi đầu. Vá là một khía cạnh quan trọng khác. Như thường lệ, việc thực hiện các bước phù hợp để giảm thiểu các lỗi an ninh mạng sẽ giúp bảo vệ tổ chức của bạn – và cho phép nhóm của bạn hưởng lợi từ công nghệ tiên tiến đó mà không phải mất ngủ hàng đêm.
.
