Bảo mật Cloud được thực hiện như thế nào?

Quá trình này được thực hiện theo nhiều lớp: xác định trách nhiệm giữa nhà cung cấp và khách hàng; kiểm soát ai được truy cập; mã hóa và quản lý dữ liệu; thiết lập cấu hình an toàn; bảo vệ ứng dụng và workload; phân đoạn mạng; thu thập nhật ký; phát hiện bất thường; ứng phó sự cố; sao lưu và khôi phục. Các lớp phải hỗ trợ lẫn nhau, vì một biện pháp riêng lẻ không thể xử lý toàn bộ rủi ro.

Cloud Security Alliance mô tả bảo mật đám mây hiện đại qua các miền như quản trị, quản lý rủi ro, danh tính và quyền truy cập, giám sát, hạ tầng mạng, bảo mật workload, dữ liệu, ứng dụng, ứng phó sự cố và khả năng phục hồi. Điều đó cho thấy bảo mật Cloud là một hệ thống kiểm soát tổng thể chứ không chỉ gồm tường lửa hoặc mã hóa.

Bảo mật Cloud bắt đầu từ mô hình trách nhiệm chia sẻ

Nhà cung cấp dịch vụ Cloud bảo vệ hạ tầng mà dịch vụ vận hành trên đó, chẳng hạn trung tâm dữ liệu, phần cứng, lớp ảo hóa, mạng nền và các thành phần dịch vụ do họ quản lý. Khách hàng vẫn chịu trách nhiệm đối với cách mình sử dụng dịch vụ, bao gồm dữ liệu, tài khoản, quyền truy cập, cấu hình, ứng dụng và một phần hệ điều hành tùy mô hình dịch vụ.

Phạm vi của mỗi bên thay đổi theo loại hình triển khai:

·         Với IaaS, khách hàng thường quản lý hệ điều hành máy ảo, bản vá, ứng dụng, dữ liệu, tài khoản và cấu hình mạng

·         Với PaaS, nhà cung cấp quản lý thêm hệ điều hành và nền tảng, còn khách hàng tập trung vào dữ liệu, danh tính, mã nguồn và cấu hình ứng dụng

·         Với SaaS, nhà cung cấp vận hành phần lớn ngăn xếp kỹ thuật, nhưng khách hàng vẫn phải quản lý người dùng, quyền, dữ liệu, thiết lập chia sẻ và cách tích hợp dịch vụ

Tài liệu về mô hình trách nhiệm chia sẻ của AWS minh họa rõ sự phân chia này: nhà cung cấp chịu trách nhiệm về “bảo mật của Cloud”, còn khách hàng chịu trách nhiệm về “bảo mật trong Cloud”. Với máy ảo IaaS, khách hàng phải quản lý hệ điều hành khách, bản vá, phần mềm và cấu hình tường lửa; với dịch vụ được trừu tượng hóa nhiều hơn, khách hàng vẫn quản lý dữ liệu, mã hóa, phân loại tài sản và quyền IAM.

Điểm dễ hiểu sai là chuyển dữ liệu lên Cloud không đồng nghĩa chuyển toàn bộ trách nhiệm bảo mật cho nhà cung cấp. Nếu khách hàng cấp quyền quá rộng, công khai kho lưu trữ hoặc để lộ khóa truy cập, hạ tầng vật lý an toàn của nhà cung cấp không tự động sửa được những sai sót đó.

Doanh nghiệp vì vậy cần lập ma trận trách nhiệm cho từng dịch vụ, chỉ rõ bên nào thực hiện, bên nào phê duyệt, bên nào giám sát và bên nào cung cấp bằng chứng kiểm soát. Cloud Controls Matrix phiên bản 4.1 của CSA gồm 207 kiểm soát thuộc 17 miền và có hướng dẫn về mô hình trách nhiệm bảo mật chia sẻ, giúp tổ chức ánh xạ trách nhiệm và đánh giá mức độ triển khai kiểm soát.

Danh tính trở thành lớp kiểm soát trung tâm

Trong môi trường truyền thống, tổ chức thường đặt niềm tin lớn vào vị trí mạng: thiết bị nằm trong mạng nội bộ được xem là đáng tin cậy hơn. Trên Cloud, người dùng, API, ứng dụng, máy ảo và dịch vụ có thể truy cập tài nguyên từ nhiều mạng và vị trí khác nhau. Vì vậy, danh tính và quyền truy cập trở thành một trong những lớp phòng vệ quan trọng nhất.

Quy trình bảo vệ danh tính thường bao gồm:

·         Sử dụng hệ thống danh tính tập trung và đăng nhập liên kết

·         Bật xác thực đa yếu tố, đặc biệt với tài khoản quản trị

·         Cấp quyền theo nguyên tắc đặc quyền tối thiểu

·         Tách tài khoản quản trị khỏi tài khoản làm việc hằng ngày

·         Cấp quyền tạm thời thay cho khóa truy cập tồn tại lâu dài

·         Rà soát định kỳ người dùng, vai trò và quyền không còn cần thiết

·         Thu hồi quyền ngay khi nhân sự thay đổi vị trí hoặc rời tổ chức

·         Kiểm soát cả danh tính con người lẫn danh tính máy

Nguyên tắc đặc quyền tối thiểu yêu cầu mỗi danh tính chỉ có đúng quyền cần thiết, trên đúng tài nguyên và trong đúng thời gian. Cơ chế này làm giảm phạm vi ảnh hưởng nếu tài khoản bị chiếm đoạt. Một tài khoản chỉ được đọc một nhóm dữ liệu sẽ tạo ra rủi ro thấp hơn tài khoản có quyền quản trị toàn bộ môi trường.

Tuy nhiên, xác thực đa yếu tố không thể thay thế việc thiết kế quyền đúng. Một tài khoản đã xác thực mạnh nhưng được cấp quyền quá rộng vẫn có thể gây thiệt hại lớn khi bị lạm dụng. Ngược lại, chính sách quyền chặt chẽ nhưng dùng mật khẩu yếu hoặc khóa API dài hạn vẫn để lại đường tấn công đáng kể.

Kiến trúc Zero Trust bổ sung nguyên tắc không mặc nhiên tin tưởng người dùng hoặc tài sản chỉ vì vị trí mạng hay quyền sở hữu. Việc xác thực và cấp quyền cho chủ thể và thiết bị phải được thực hiện trước khi thiết lập phiên truy cập tài nguyên. NIST cũng nhấn mạnh Zero Trust tập trung bảo vệ tài nguyên thay vì coi phân đoạn mạng là trọng tâm duy nhất.

Dữ liệu được bảo vệ trong toàn bộ vòng đời

Bảo mật dữ liệu không dừng ở việc mã hóa tệp đang lưu trữ. Tổ chức phải biết mình có dữ liệu gì, dữ liệu nằm ở đâu, ai được truy cập, được sử dụng cho mục đích nào, được giữ trong bao lâu và phải xử lý ra sao khi hết nhu cầu.

Một vòng đời bảo vệ dữ liệu thường gồm các bước:

1.    Khám phá và lập danh mục dữ liệu

2.    Phân loại theo mức độ nhạy cảm

3.    Xác định chủ sở hữu và mục đích xử lý

4.    Giới hạn quyền truy cập

5.    Mã hóa khi truyền và khi lưu trữ

6.    Quản lý khóa mã hóa

7.    Theo dõi hoạt động đọc, sửa, tải xuống và chia sẻ

8.    Sao lưu và kiểm tra khả năng khôi phục

9.    Áp dụng thời hạn lưu giữ

10.  Xóa hoặc tiêu hủy an toàn khi hết vòng đời

Mã hóa làm cho dữ liệu khó sử dụng nếu bên không được phép lấy được bản sao, nhưng hiệu quả của nó phụ thuộc vào cách quản lý khóa. Nếu dữ liệu và khóa được bảo vệ bởi cùng một tài khoản có quyền quá rộng, kẻ chiếm được tài khoản đó có thể truy cập cả hai. Vì vậy, khóa cần được phân quyền riêng, ghi nhật ký sử dụng, luân chuyển phù hợp và hạn chế khả năng xuất ra ngoài.

Phân loại dữ liệu quyết định mức kiểm soát cần áp dụng. Dữ liệu công khai không cần cơ chế giống dữ liệu cá nhân, bí mật kinh doanh hoặc thông tin xác thực. Nếu không phân loại, tổ chức thường rơi vào một trong hai trạng thái: bảo vệ thiếu đối với dữ liệu nhạy cảm hoặc áp dụng kiểm soát quá nặng cho mọi dữ liệu, làm tăng chi phí và độ phức tạp.

CSA xác định các kiểm soát bảo vệ dữ liệu Cloud phải bao phủ phân loại, quyền riêng tư, lưu giữ và tiêu hủy trong toàn bộ vòng đời. Theo mô hình trách nhiệm chia sẻ, nhà cung cấp cung cấp hạ tầng và khả năng lưu trữ an toàn, còn khách hàng phải phân loại dữ liệu, lựa chọn công cụ mã hóa, quản lý cách sử dụng dữ liệu và đáp ứng nghĩa vụ bảo vệ dữ liệu liên quan.

Cấu hình an toàn được chuẩn hóa và kiểm tra liên tục

Cloud cho phép tạo tài nguyên rất nhanh thông qua giao diện quản trị, API hoặc mã hạ tầng. Tốc độ này mang lại hiệu quả vận hành nhưng cũng khiến cấu hình sai có thể được nhân rộng chỉ trong thời gian ngắn.

Các sai lệch thường gặp gồm:

·         Kho lưu trữ hoặc cơ sở dữ liệu bị công khai ngoài ý muốn

·         Nhóm bảo mật cho phép truy cập từ mọi địa chỉ

·         Tài khoản hoặc vai trò được cấp quyền quản trị không cần thiết

·         Dịch vụ ghi nhật ký bị tắt

·         Dữ liệu không được mã hóa theo chính sách

·         Tài nguyên thử nghiệm không được xóa

·         Cổng quản trị được mở trực tiếp ra Internet

·         Bản sao dữ liệu tồn tại tại khu vực không được phê duyệt

Bảo vệ cấu hình được thực hiện hiệu quả nhất khi tổ chức chuyển yêu cầu bảo mật thành chính sách có thể kiểm tra tự động. Thay vì chờ con người rà soát từng tài nguyên, hệ thống đối chiếu trạng thái thực tế với đường cơ sở an toàn và cảnh báo hoặc khắc phục khi phát hiện sai lệch.

Infrastructure as Code giúp cấu hình được lưu thành mã, xem xét trước khi triển khai, kiểm thử trong quy trình CI/CD và quản lý phiên bản. Cách tiếp cận này tạo khả năng tái lập và truy vết tốt hơn thao tác thủ công. Tuy nhiên, tự động hóa không bảo đảm cấu hình đúng; một mẫu cấu hình sai có thể nhân bản lỗi trên hàng trăm tài nguyên. Vì vậy, mã hạ tầng cũng cần được quét chính sách, đánh giá thay đổi và phê duyệt theo mức rủi ro.

NIST SP 800-53 tổ chức các kiểm soát bảo mật và quyền riêng tư thành nhiều nhóm, trong đó có quản lý cấu hình, kiểm soát truy cập, nhận dạng và xác thực, kiểm toán, ứng phó sự cố, bảo vệ hệ thống truyền thông và tính toàn vẹn hệ thống. Các kiểm soát có thể được điều chỉnh theo nhiệm vụ, yêu cầu kinh doanh và mức rủi ro của tổ chức.

Mạng Cloud được phân đoạn để giới hạn đường tấn công

Tường lửa vẫn cần thiết nhưng không còn là toàn bộ chiến lược bảo vệ mạng. Môi trường Cloud thường gồm nhiều tài khoản, mạng ảo, vùng triển khai, API, dịch vụ được quản lý và workload có vòng đời ngắn. Kiểm soát mạng vì thế phải được đặt ở nhiều cấp.

Các biện pháp chính gồm:

·         Tách môi trường phát triển, kiểm thử và sản xuất

·         Phân đoạn workload theo mức độ tin cậy và chức năng

·         Chỉ mở cổng, giao thức và nguồn truy cập thực sự cần thiết

·         Sử dụng kết nối riêng cho tài nguyên nhạy cảm khi phù hợp

·         Bảo vệ API và điểm truy cập công khai

·         Kiểm soát lưu lượng đi ra ngoài, không chỉ lưu lượng đi vào

·         Áp dụng tường lửa ứng dụng Web và biện pháp chống từ chối dịch vụ

·         Ghi lại luồng mạng để hỗ trợ điều tra

Phân đoạn làm giảm khả năng di chuyển ngang sau khi một workload bị xâm nhập. Nếu toàn bộ hệ thống nằm trong một miền mạng rộng và các máy có thể kết nối tự do với nhau, một lỗ hổng tại dịch vụ ít quan trọng có thể trở thành điểm khởi đầu để tiếp cận dữ liệu nhạy cảm.

Tuy vậy, phân đoạn mạng không thay thế kiểm soát danh tính. Nhiều dịch vụ Cloud được truy cập qua API và danh tính dịch vụ, nên quyền IAM sai có thể cho phép truy cập dù đường mạng đã được giới hạn. Mạng và danh tính phải cùng tham gia vào quyết định truy cập.

Workload được bảo vệ từ mã nguồn đến thời gian chạy

Workload Cloud có thể là máy ảo, container, cụm điều phối, hàm serverless, cơ sở dữ liệu, ứng dụng hoặc dịch vụ nền tảng. Mỗi loại có bề mặt tấn công và phạm vi trách nhiệm khác nhau.

Bảo vệ workload nên bắt đầu trước khi triển khai:

Trong giai đoạn phát triển

Mã nguồn, thư viện phụ thuộc, cấu hình và bí mật phải được kiểm tra trước khi đưa vào môi trường vận hành. Khóa API, mật khẩu và chứng thư không nên được ghi trực tiếp trong mã hoặc tệp cấu hình. Chúng cần được lưu trong hệ thống quản lý bí mật, cấp theo danh tính workload và luân chuyển khi cần.

Trong quá trình xây dựng

Pipeline phải kiểm tra thành phần phần mềm, lỗ hổng đã biết, cấu hình nguy hiểm và nguồn gốc của gói triển khai. Artifact đã được kiểm tra cần được ký hoặc kiểm chứng tính toàn vẹn để hạn chế nguy cơ bị thay thế trước khi triển khai.

Khi triển khai

Workload nên dùng hình ảnh cơ sở tối giản, không chạy bằng quyền cao khi không cần thiết và chỉ nhận các quyền Cloud cần cho nhiệm vụ. Cấu hình mạng, dung lượng tài nguyên và chính sách bảo mật phải được áp dụng nhất quán.

Trong thời gian chạy

Hệ thống cần theo dõi hành vi bất thường, tiến trình lạ, kết nối ngoài dự kiến, thay đổi tệp quan trọng và hoạt động sử dụng thông tin xác thực. Khi phát hiện dấu hiệu xâm nhập, workload có thể được cách ly, thu hồi quyền hoặc thay thế bằng phiên bản sạch.

Quản lý bản vá vẫn là yêu cầu quan trọng với máy ảo và các thành phần do khách hàng vận hành. Với dịch vụ được quản lý, nhà cung cấp có thể vá hệ điều hành và nền tảng, nhưng khách hàng vẫn phải cập nhật mã ứng dụng, thư viện, container và cấu hình thuộc phạm vi của mình. Trách nhiệm cụ thể phải được xác nhận theo từng dịch vụ thay vì áp dụng một giả định chung.

Giám sát liên tục biến sự kiện thành tín hiệu phát hiện

Bảo mật Cloud không thể dựa vào ảnh chụp trạng thái tại một thời điểm. Tài nguyên được tạo, sửa và xóa liên tục; quyền có thể thay đổi qua API; workload có thể chỉ tồn tại trong vài phút. Tổ chức cần giám sát liên tục để biết điều gì đã xảy ra và nhận ra hành vi bất thường.

Nguồn dữ liệu giám sát thường bao gồm:

·         Nhật ký đăng nhập và xác thực

·         Nhật ký thay đổi quyền và chính sách

·         Nhật ký quản trị dịch vụ Cloud

·         Nhật ký truy cập dữ liệu

·         Luồng mạng

·         Sự kiện từ máy ảo, container và ứng dụng

·         Cảnh báo cấu hình

·         Sự kiện từ công cụ bảo vệ điểm cuối và workload

Nhật ký chỉ tạo giá trị khi được thu thập đầy đủ, đồng bộ thời gian, bảo vệ khỏi sửa đổi, lưu giữ phù hợp và liên kết với ngữ cảnh. Một lần đăng nhập từ vị trí mới chưa chắc là sự cố; nhưng nếu cùng lúc xuất hiện việc tắt nhật ký, tạo khóa truy cập và tải lượng dữ liệu lớn, chuỗi sự kiện trở nên đáng chú ý hơn.

Hệ thống giám sát nên ưu tiên những tín hiệu có ảnh hưởng cao, chẳng hạn sử dụng tài khoản đặc quyền bất thường, thay đổi chính sách truy cập, vô hiệu hóa kiểm soát, truy xuất bí mật hàng loạt hoặc tạo tài nguyên tại khu vực chưa được phê duyệt. Nếu mọi sự kiện đều tạo cảnh báo giống nhau, đội vận hành dễ rơi vào tình trạng quá tải và bỏ sót tín hiệu quan trọng.

Giám sát cũng phải bao phủ mặt phẳng điều khiển của Cloud, không chỉ hệ điều hành và ứng dụng. Nhiều hành động có ảnh hưởng lớn—như cấp quyền, thay đổi cấu hình mạng hoặc tạo bản sao dữ liệu—được thực hiện qua API quản trị mà không cần đăng nhập vào máy chủ.

Ứng phó sự cố phải phù hợp với đặc tính của Cloud

Kế hoạch ứng phó sự cố tại trung tâm dữ liệu truyền thống không thể được chuyển nguyên trạng sang Cloud. Tài nguyên Cloud có tính động, nhiều bằng chứng nằm trong nhật ký dịch vụ và một số lớp hạ tầng thuộc quyền quản lý của nhà cung cấp.

Quy trình ứng phó cần chuẩn bị trước:

1.    Xác định nguồn nhật ký và thời hạn lưu giữ

2.    Thiết lập quyền điều tra khẩn cấp

3.    Chuẩn bị cơ chế cách ly tài khoản, khóa, workload và mạng

4.    Xây dựng playbook cho các tình huống phổ biến

5.    Xác định kênh phối hợp với nhà cung cấp

6.    Tự động hóa các hành động có thể đảo ngược và rủi ro thấp

7.    Kiểm thử bằng diễn tập định kỳ

8.    Bảo toàn bằng chứng phục vụ phân tích nguyên nhân

Khi tài khoản bị nghi ngờ xâm nhập, tổ chức không chỉ đổi mật khẩu. Cần thu hồi phiên đăng nhập, vô hiệu hóa khóa, rà soát quyền được cấp, kiểm tra các thay đổi đã thực hiện và tìm kiếm cơ chế duy trì truy cập. Khi workload bị xâm nhập, việc xây dựng lại từ artifact đáng tin cậy thường an toàn hơn cố gắng sửa thủ công tại chỗ.

Khả năng phục hồi cũng là một phần của bảo mật. Bản sao lưu phải được tách biệt hợp lý, giới hạn quyền xóa, kiểm tra tính toàn vẹn và thử khôi phục. Việc có bản sao lưu nhưng chưa từng kiểm thử không chứng minh rằng dịch vụ có thể phục hồi trong thời gian yêu cầu.

NIST xem ứng phó sự cố, lập kế hoạch dự phòng, kiểm toán, giám sát, bảo vệ tính toàn vẹn và quản lý rủi ro là các nhóm kiểm soát liên kết trong một quy trình bảo vệ tổng thể.

Bảo mật Cloud được vận hành theo chu trình quản trị rủi ro

Một chương trình bảo mật Cloud hiệu quả không bắt đầu bằng việc mua thật nhiều công cụ. Nó bắt đầu bằng việc hiểu tài sản, dữ liệu, mối đe dọa, trách nhiệm và mức thiệt hại có thể chấp nhận.

Chu trình triển khai có thể gồm:

1.    Lập danh mục tài khoản, dịch vụ, dữ liệu và workload

2.    Phân loại tài sản theo mức độ quan trọng

3.    Xác định yêu cầu bảo mật và tuân thủ

4.    Ánh xạ trách nhiệm giữa nhà cung cấp và khách hàng

5.    Chọn đường cơ sở kiểm soát

6.    Triển khai kiểm soát bằng chính sách và tự động hóa

7.    Thu thập bằng chứng vận hành

8.    Đánh giá hiệu lực thay vì chỉ kiểm tra sự tồn tại

9.    Khắc phục sai lệch theo mức rủi ro

10.  Cải tiến sau thay đổi và sự cố

Sự tồn tại của một kiểm soát không đồng nghĩa kiểm soát đó có hiệu lực. Ví dụ, tổ chức có thể đã bật ghi nhật ký nhưng lưu thiếu nguồn dữ liệu, đặt thời hạn quá ngắn hoặc không có quy tắc phát hiện. Tương tự, mã hóa có thể đã được bật nhưng khóa lại nằm trong tay quá nhiều tài khoản.

Vì vậy, chương trình cần đánh giá cả hai mặt: chức năng kiểm soát và mức độ bảo đảm rằng kiểm soát đang hoạt động đúng. NIST SP 800-53 phân biệt chức năng bảo mật với assurance—mức độ tin cậy vào năng lực mà kiểm soát cung cấp—và đặt các kiểm soát trong quy trình quản lý rủi ro ở cấp tổ chức.

Các chỉ số nên phản ánh kết quả vận hành, chẳng hạn:

·         Tỷ lệ tài nguyên tuân thủ đường cơ sở

·         Số danh tính đặc quyền không hoạt động

·         Tỷ lệ tài khoản quản trị đã bật xác thực đa yếu tố

·         Thời gian phát hiện và khắc phục cấu hình sai

·         Tỷ lệ dữ liệu nhạy cảm đã được phân loại

·         Tỷ lệ workload vượt thời hạn vá

·         Tỷ lệ khôi phục thử nghiệm thành công

·         Thời gian thu hồi quyền sau thay đổi nhân sự

Chỉ số phải được đặt trong ngữ cảnh. Tỷ lệ tuân thủ cao vẫn có thể che giấu một tài nguyên không tuân thủ nhưng chứa dữ liệu đặc biệt quan trọng. Do đó, mức độ nghiêm trọng và tác động kinh doanh cần được xem xét cùng số lượng.

Những giới hạn cần hiểu đúng

Bảo mật Cloud không thể loại bỏ hoàn toàn rủi ro. Mục tiêu thực tế là giảm xác suất xảy ra sự cố, giới hạn phạm vi ảnh hưởng, phát hiện sớm và phục hồi có kiểm soát.

Một số giới hạn quan trọng gồm:

·         Mã hóa không ngăn người dùng hợp lệ lạm dụng quyền

·         Xác thực đa yếu tố không sửa được chính sách cấp quyền quá rộng

·         Tường lửa không bảo vệ khỏi API bị cấp quyền sai

·         Công cụ quét cấu hình không hiểu đầy đủ mọi ngữ cảnh kinh doanh

·         Sao lưu không hữu ích nếu không thể khôi phục đúng thời hạn

·         Chứng nhận của nhà cung cấp không tự động làm cấu hình của khách hàng tuân thủ

·         Zero Trust không phải một sản phẩm có thể mua và hoàn tất ngay

·         Tự động hóa có thể nhân rộng cả cấu hình tốt lẫn cấu hình sai

NIST lưu ý rằng việc đưa dữ liệu và dịch vụ ra ngoài tổ chức tạo ra các thách thức bảo mật và quyền riêng tư cần được xem xét khi sử dụng Cloud công cộng. Việc lựa chọn dịch vụ vì thế phải gắn với yêu cầu rủi ro, quyền kiểm soát, khả năng kiểm toán và nghĩa vụ đối với dữ liệu.

Bảo mật Cloud được thực hiện bằng hệ thống phòng vệ nhiều lớp vận hành liên tục. Nhà cung cấp bảo vệ hạ tầng Cloud; khách hàng bảo vệ cách mình sử dụng Cloud; và một số kiểm soát cần sự phối hợp của cả hai bên.

Trọng tâm của hệ thống là danh tính được xác minh, quyền truy cập tối thiểu, dữ liệu được quản lý theo vòng đời, cấu hình được chuẩn hóa, mạng được phân đoạn, workload được bảo vệ từ phát triển đến thời gian chạy, hoạt động được giám sát và sự cố được chuẩn bị trước. Hiệu quả không đến từ số lượng công cụ mà từ việc mỗi rủi ro có chủ sở hữu, mỗi kiểm soát có bằng chứng và mỗi sai lệch được phát hiện, ưu tiên, khắc phục.