Bảo mật container trên cloud: Các khái niệm và yêu cầu

Chúng tôi sẽ đi sâu vào thế giới của vấn đề bảo mật container trên đám mây, trình bày chi tiết các chiến lược bảo vệ và các kiến thức triển khai cần thiết.

Sự quan tâm đến container và các nền tảng container bùng nổ vào nửa sau của thập kỷ 2010. Trong bối cảnh mức độ phổ biến ngày càng tăng này, các container đã trở thành kiến trúc runtime đứng thứ ba cho việc lưu trữ các ứng dụng, bên cạnh các máy ảo (VM) Linux và Windows.

Trong bài hướng dẫn này, chúng tôi trình bày những lợi ích của việc chạy container trên đám mây và xem xét kỹ hơn cách thức giúp bảo mật hoạt động hiệu quả cho các tải xử lý đã được container hóa.

Làm thế nào để chạy container trên đám mây

So với các ứng dụng truyền thống, container image không chỉ bao gồm ứng dụng mà còn kết hợp tất cả các phần phụ thuộc, bao gồm thư viện hệ thống, driver và thông tin cấu hình. Chúng giúp cho việc triển khai dễ dàng và thuận tiện, thay vì bằng cách phải cấu hình hệ điều hành thủ công và cài đặt thiết bị theo kiểu dễ xảy ra lỗi trên máy ảo. Việc triển khai trở nên suôn sẻ, nhanh chóng và không gặp sự cố.

Tất cả các nhà cung cấp dịch vụ đám mây lớn (CSP) đều cung cấp nhiều dịch vụ đám mây để chạy tải xử lý của container (Hình 1). Biến thể đầu tiên là khách hàng triển khai một giải pháp nguồn mở hoặc nền tảng container của bên thứ ba theo lựa chọn của họ (ví dụ: RedHat OpenShift hoặc Apache Mesos). Họ tự cài đặt nền tảng vào máy ảo trên đám mây. Vì vậy, trong trường hợp này, nhà cung cấp đám mây không tham gia vào việc thiết lập và chạy nền tảng container.

Hình 1 – Cách chạy các ứng dụng được chứa trong dịch vụ đám mây

Tùy chọn thứ hai là các container trên dịch vụ nền tảng container được quản lý do CSP cung cấp. Ví dụ như Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE) và Amazon Elastic Kubernetes Service. Chỉ cần một cú nhấp chuột là cụm Kubernetes sẽ tự động hoạt động.

Theo mô hình này, cấu hình container và nền tảng là trách nhiệm của khách hàng, đây là điểm khác biệt chính đối với tùy chọn thứ ba, nền tảng container runtime tập trung trên đám mây, chẳng hạn như Azure Function Apps hoặc Azure Web Apps (Hình 2). Các dịch vụ sau cho phép các kỹ sư cung cấp – bên cạnh các tùy chọn khác – các ứng dụng được đóng gói nhưng che giấu sự tồn tại của nền tảng container cơ bản. Vì vậy, thách thức đối với các kiến ​​trúc sư bảo mật là bảo mật một loạt nền tảng chạy các ứng dụng được đóng gói như vậy.

 

Hình 2 – Triển khai container dưới dạng chức năng hoặc ứng dụng web trong Azure

Các yêu cầu bảo mật cho container

Để bảo vệ tải xử lý container một cách hiệu quả, kiến ​​trúc sư bảo mật cần hiểu biết toàn diện về lớp công nghệ và các nhiệm vụ liên quan đến bảo mật. Các nhiệm vụ này nhằm mục đích củng cố tất cả các thành phần có liên quan, quản lý các lỗ hổng cũng như chủ động xác định và ứng phó với các mối đe dọa và cuộc tấn công đối với toàn bộ hệ thống công nghệ (Hình 3).

Việc tăng cường đòi hỏi phải cấu hình tất cả các thành phần một cách an toàn, đặc biệt là triển khai các thiết kế kiểm soát truy cập và mạng mạnh mẽ. Quản lý lỗ hổng bao gồm việc xác định các điểm yếu về bảo mật và cấu hình sai trong các thành phần tự phát triển và do bên thứ ba cung cấp và vá chúng lại. Ngay cả khi container image không có lỗ hổng bảo mật tại thời điểm triển khai, các lỗ hổng bảo mật có thể được xác định sau đó, như trường hợp Log4j minh họa. Cuối cùng, tin tặc có thể tấn công các ứng dụng được đóng gói và các nền tảng chứa bên dưới. Do đó, các tổ chức phải phát hiện những điều bất thường và hành vi đáng ngờ bên trong container của tổ chức (phát hiện mối đe dọa).

Hình 3: Những thách thức liên quan đến bảo mật đối với tải xử lý được đóng gói trong container

Tăng cường, quản lý lỗ hổng và phát hiện mối đe dọa là những điều cần thiết cho toàn bộ lớp công nghệ (Hình 3, bên trái), lớp hạ tầng bên dưới (ví dụ như các VMs, hệ thống mạng, lưu trữ hoặc các cloud tenant), bản thân nền tảng container (ví dụ: OpenShift hoặc Amazon Elastic Kubernetes Service EKS) và cuối cùng là cho từng ứng dụng đã được container hóa.

Các trách nhiệm khác nhau đối với lớp nền tảng, tùy thuộc vào dịch vụ đám mây. Đối với các môi trường runtime được đóng gói như Azure Function Apps, khách hàng phải đảm bảo rằng image không có lỗ hổng bảo mật và cấu hình dịch vụ được bảo mật; mọi thứ khác sẽ thuộc về CSP. Ngược lại, việc chạy cụm Amazon EKS tức là khách hàng cũng phải chịu trách nhiệm cấu hình nền tảng container mặc dù CSP là người sẽ cập nhật bản vá các thành phần nền tảng.

Hình 4 trực quan hóa tất cả các thách thức bảo mật liên quan đến tải xử lý của container. Kiến trúc sư bảo mật phải hiểu và xác định cách họ giải quyết các nhiệm vụ bảo mật (tăng cường, quản lý lỗ hổng, phát hiện tấn công/mối đe dọa) cho từng dịch vụ đám mây chạy container image (ví dụ: Azure Function Apps, Amazon EKS, Cloud Run) cho mọi lớp công nghệ lớp (ứng dụng, nền tảng, hạ tầng) – nếu khách hàng chứ không phải CSP chịu trách nhiệm về lớp cụ thể.

 

Hình 4 – Phân tích mức độ bao phủ của tổ chức về các công nghệ và rủi ro liên quan đến container

Thực hiện công việc bảo mật cho tải xử lý được đóng gói

Các công cụ bảo mật thuần đám mây như Microsoft Defender hoặc Google Security Center là những giải pháp tuyệt vời đầu tiên để bảo mật tải xử lý được chứa trong container trên dịch vụ đám mây. Những công cụ này phát hiện các lỗ hổng và mối đe dọa trong tải xử lý của container và các nền tảng cơ bản. Mặc dù chắc chắn chúng không miễn phí nhưng khách hàng có thể kích hoạt chúng chỉ bằng một hoặc hai (hoặc rất ít) cú nhấp chuột và được hưởng lợi ngay lập tức từ tình trạng bảo mật được cải thiện.

Khi xem xét Azure Function Apps, một trong những dịch vụ Azure có thể chạy tải xử lý được đóng gói, sản phẩm phù hợp của Microsoft là Defender for Cloud. Đầu tiên, nó cung cấp tính năng Defender Recommendations giúp tiết lộ các lựa chọn cấu hình và tham số không an toàn, chẳng hạn như “Function App chỉ có thể truy cập được qua HTTPS” (Hình 5, 1). Những khuyến nghị này dựa (một phần) vào tiêu chuẩn CIS. Tính năng Defender thứ hai, phân tích Đường dẫn tấn công, xem xét bối cảnh rộng hơn. Nó xác định các đường dẫn tấn công bằng cách sử dụng nhiều lựa chọn cấu hình không hoàn hảo để xâm nhập vào khu vực đám mây của công ty (2). Cuối cùng, Defender Security Alerts cảnh báo các chuyên gia về các hoạt động đang diễn ra có thể là một cuộc tấn công (3).

Hình 5 – Microsoft Defender dành cho đám mây

Những gì bộ công cụ Microsoft Defender có trên Azure cũng có trên Amazon GuardDuty dành cho AWS và Google Security Command Center thì dành cho GCP: các dịch vụ có sẵn, thuần đám mây rất tốt để bảo mật (không chỉ) tải xử lý dựa trên container. Bên cạnh các giải pháp thuần đám mây này, các công cụ bảo mật của bên thứ ba cũng là những lựa chọn khả thi. Các tổ chức lớn hơn nên so sánh các tính năng và chi phí của họ với các tính năng và chi phí của dịch vụ thuần đám mây.

Thách thức thực sự với bảo mật container bắt đầu khi các CISO yêu cầu bảo vệ đầy đủ cho tất cả tải xử lý của container dựa trên đám mây. Sau đó, các kiến ​​trúc sư bảo mật cần phân tích riêng từng dịch vụ đám mây có liên quan. Trong một phân tích như vậy, họ nên đặc biệt chú ý đến ba chủ đề:

  1. Củng cố là việc xác định các quy tắc chi tiết dựa trên tải xử lý cụ thể của công ty và thiết lập đám mây. Khi nào máy ảo được hiển thị công khai được chấp nhận? Khi nào bạn cần (hoặc không được yêu cầu) xác thực cho lệnh gọi API? Đó là một mục tiêu toàn diện hơn nhiều so với việc chỉ đảm bảo không tồn tại các lỗ hổng rõ ràng.
  2. Đối với việc quét các lỗ hổng cho container hoặc container image, tồn tại hai hình mẫu: quét repository và quét runtime. Phương pháp thứ hai chỉ kiểm tra các image đang được sử dụng và có nguy cơ bị ảnh hưởng—lợi ích: không có kết quả “dương tính giả” do lỗ hổng trong các image được tạo nhưng chưa bao giờ được triển khai. Tuy nhiên, tính năng quét runtime không có sẵn ở mọi dịch vụ. Phương pháp dự phòng là quét image trong các repositories như GCP Artifact Register – một mẫu hình cho phép tích hợp chức năng quét lỗ hổng vào quy trình CI/CD.
  3. Phát hiện mối đe dọa yêu cầu phân tích các hoạt động trong container và nền tảng cơ bản để phát hiện hành vi đáng ngờ và các điểm bất thường. Tương tự như việc quét lỗ hổng dựa trên container, các kiến ​​trúc sư bảo mật có thể muốn kiểm tra kỹ xem tính năng đó có sẵn (và đang hoạt động) cho tất cả các môi trường dựa trên container hay không.

Ngoài ra, các giải pháp của bên thứ ba về bảo mật container cũng chắc chắn là những lựa chọn hợp lý. Tuy nhiên, việc so sánh các tính năng và chi phí của chúng với các giải pháp thuần đám mây là điều bắt buộc – ít nhất là đối với các tổ chức lớn.

Ngăn chặn các mối đe dọa

Thực tế kinh hoàng đối với các CISO về bảo mật container là công nghệ container đã thâm nhập vào hầu hết các đơn vị IT. Mặc dù CISO và CIO thường biết các cụm Kubernetes lớn của họ, nhưng họ ít biết đến nhiều container thực thi dịch vụ đám mây bổ sung, ít được biết đến hơn. Vì tin tặc muốn tìm các dịch vụ không được bảo vệ (thay vì tấn công các dịch vụ được bảo mật), nên các tổ chức phải phân tích nơi họ có tải xử lý trong container và đảm bảo tất cả đều được an toàn.

Nguồn DCK