Checklist bảo mật Cloud không còn đủ để bảo vệ doanh nghiệp

Rủi ro không giống nhau giữa các nền tảng

Intruder phân loại các lỗi cấu hình thành sáu nhóm chính: IAM, logging, cấu hình dịch vụ, firewall, dịch vụ public và encryption.

IAM yếu và thiếu logging xuất hiện ở khoảng 80–98% tài khoản, bất kể nền tảng nào.

Điểm đáng chú ý là AWS có tỷ lệ cao nhất ở 5/6 nhóm rủi ro, trong khi Google Cloud thấp nhất ở 5 nhóm. Một trong những nguyên nhân có thể đến từ sự khác biệt về số lượng dịch vụ, mô hình quản lý trách nhiệm và các thiết lập bảo mật mặc định.

AWS: Firewall và IAM cần được ưu tiên

Năm cấu hình sai phổ biến nhất trên AWS:

Đáng chú ý, 83% tài khoản AWS được khảo sát có IAM Policy có khả năng cho phép privilege escalation.

Đây là vấn đề đặc biệt nguy hiểm vì một identity có quyền vượt quá nhu cầu thực tế có thể trở thành điểm khởi đầu để kẻ tấn công mở rộng quyền kiểm soát hệ thống.

Azure: Storage và Identity là điểm yếu chính

Trên Azure, ba vấn đề hàng đầu đều liên quan đến Storage Account:

Việc hơn một nửa tài khoản có người dùng Entra ID chưa bật MFA là một rủi ro đáng chú ý, bởi Entra ID không chỉ kiểm soát tài nguyên Azure mà còn liên quan tới Microsoft 365, SaaS và các hệ thống on-premises.

Google Cloud: IAM là vấn đề nổi bật

Khác với AWS và Azure, phần lớn các vấn đề phổ biến nhất trên Google Cloud tập trung vào IAM:

Đặc biệt, hơn 3/4 tài khoản được khảo sát chưa triển khai đầy đủ các kiểm soát OS Login – cơ chế cung cấp phương thức truy cập máy chủ an toàn hơn so với SSH truyền thống.

Doanh nghiệp càng lớn, IAM càng trở thành vấn đề

Một phát hiện khá bất ngờ là các doanh nghiệp lớn thường có tỷ lệ thấp hơn đối với firewall quá rộng, exposed services và encryption yếu.

Tuy nhiên, IAM lại đi theo chiều ngược lại:

Điều này cho thấy quy mô lớn không đồng nghĩa với IAM tốt hơn. Khi số lượng người dùng, service account, workload và policy tăng lên, việc kiểm soát quyền truy cập trở nên phức tạp hơn đáng kể.

Đáng chú ý, nhóm mid-market mất trung bình khoảng 35 ngày để xử lý các vấn đề Cloud, so với 8–16 ngày ở doanh nghiệp nhỏ và khoảng 10 ngày ở doanh nghiệp lớn.

Cloud Security không thể chỉ dựa vào một checklist

Điểm quan trọng nhất từ nghiên cứu này là:

Không nên sử dụng một checklist bảo mật giống nhau cho AWS, Azure và Google Cloud.

Một baseline chung vẫn cần thiết, nhưng cách đánh giá và ưu tiên remediation phải phù hợp với từng nền tảng.

Ví dụ:

• AWS: tập trung vào IAM, network ACL, firewall và encryption.
• Azure: ưu tiên Storage Account, Entra ID và MFA.
• Google Cloud: tập trung mạnh vào IAM, OS Login và Service Account.
• Multi-cloud: cần một hệ thống quản lý security posture thống nhất nhưng vẫn phải duy trì các rule và tiêu chí riêng cho từng Cloud provider.

Quan trọng hơn, Cloud security không phải là việc kiểm tra một lần rồi hoàn thành. Khi workload, identity, policy và network thay đổi liên tục, security posture cũng phải được đánh giá và remediation liên tục.

Kết luận

Một checklist chỉ cho chúng ta biết cần kiểm tra những gì. Một chiến lược Cloud Security hiệu quả phải trả lời thêm câu hỏi:

Rủi ro nào đang quan trọng nhất đối với môi trường của chúng ta và cần được xử lý trước?

Đó mới là sự khác biệt giữa việc "có checklist bảo mật" và thực sự quản lý được Cloud Security Posture.

Nguồn:
The Hacker News, Your Cloud Security Checklist Doesn't Work the Way You Think It Does, 07/09/2026. Bài viết sử dụng dữ liệu từ Intruder – 2026 Cloud Security Index.

Đọc bài gốc trên The Hacker News