Các yếu tố bảo mật cần xem xét khi áp dụng dịch vụ đám mây

1. Tổng quan

A. Định nghĩa

Các yếu tố bảo mật cần xem xét khi áp dụng điện toán đám mây là tập hợp các hạng mục kiểm soát bảo mật cần được rà soát và bảo đảm trên toàn bộ các khía cạnh dữ liệu, truy cập, quy định và vận hành khi doanh nghiệp lựa chọn và vận hành dịch vụ đám mây. Mục đích là ứng phó với các rủi ro đặc thù của đám mây khác căn bản với on-premise (phân chia trách nhiệm, phơi lộ trên Internet, đa thuê bao, mở rộng động).

Lý do căn bản khiến bảo mật đám mây khó khăn nằm ở mô hình trách nhiệm chia sẻ (Shared Responsibility Model), trong đó 'một phần quyền kiểm soát được chuyển sang nhà cung cấp dịch vụ đám mây (CSP)'. Ở on-premise, doanh nghiệp trực tiếp kiểm soát mọi tầng từ máy chủ vật lý đến dữ liệu, còn trên đám mây, hạ tầng vật lý và hypervisor do CSP chịu trách nhiệm, còn dữ liệu, tài khoản, truy cập và cấu hình do người dùng chịu trách nhiệm. Vấn đề phát sinh khi hiểu sai ranh giới trách nhiệm này. Nếu chủ quan cho rằng "đã là đám mây thì CSP sẽ tự lo bảo mật", người dùng sẽ lơ là việc quản lý quyền truy cập hay cấu hình kho lưu trữ vốn thuộc trách nhiệm của mình và dẫn đến sự cố.

Trên thực tế, hầu hết các vụ rò rỉ trên đám mây không bắt nguồn từ việc hạ tầng của CSP bị tấn công mà từ lỗi cấu hình (storage bucket bị mở công khai) hoặc đánh cắp tài khoản, khóa ở phía người dùng. Đây cũng là lý do Gartner từ lâu đã cảnh báo rằng "đến năm 2025, 99% sự cố bảo mật đám mây sẽ thuộc trách nhiệm của khách hàng". Vì vậy, điểm xuất phát của bảo mật đám mây không phải là công nghệ mới hào nhoáng mà là biết chính xác "tôi chịu trách nhiệm về cái gì", và trên nền tảng đó, cốt lõi là kiểm soát có hệ thống dữ liệu, truy cập và cấu hình.

B. Sự cần thiết và bối cảnh xuất hiện

Đám mây mang lại lợi ích về khả năng mở rộng, tính linh hoạt và chi phí (chuyển từ CapEx sang OpEx), nhưng do đặc tính luôn phơi ra Internet, nhiều tenant dùng chung tài nguyên vật lý, và tài nguyên được tạo hàng loạt trong chớp mắt bằng IaC (hạ tầng dưới dạng mã), nó tạo ra bề mặt tấn công (attack surface) mới vốn không có ở on-premise. Đặc biệt, phát triển và triển khai càng nhanh thì 'nợ bảo mật' do rà soát bảo mật bị tụt lại phía sau càng dễ tích tụ. Vì vậy, phải rà soát có hệ thống các yếu tố bảo mật ngay từ giai đoạn trước khi áp dụng và nội tại hóa chúng vào kiến trúc (security by design) thì mới tận hưởng an toàn lợi ích của đám mây. Đây không phải việc áp dụng công nghệ đơn thuần mà là nhiệm vụ toàn doanh nghiệp bao trùm quản trị, quy trình và nhân lực.

2. Mô hình trách nhiệm chia sẻ — Sự dịch chuyển của ranh giới kiểm soát

Mô hình trách nhiệm chia sẻ là bộ khung của bảo mật đám mây. Cốt lõi là ranh giới trách nhiệm giữa CSP và người dùng dịch chuyển theo mô hình dịch vụ (IaaS, PaaS, SaaS), và trong bất kỳ mô hình nào thì bảo mật dữ liệu và tài khoản (quyền truy cập) luôn là phần của người dùng. Sơ đồ cấu trúc dưới đây thể hiện sự dịch chuyển ranh giới này.

flowchart TB
  subgraph IAAS["IaaS"]
    I1["Người dùng: OS·Middleware·Ứng dụng·Dữ liệu·Tài khoản"]
    I2["CSP: Ảo hóa·Vật lý·Mạng"]
  end
  subgraph PAAS["PaaS"]
    P1["Người dùng: Ứng dụng·Dữ liệu·Tài khoản"]
    P2["CSP: OS·Runtime·Hạ tầng"]
  end
  subgraph SAAS["SaaS"]
    S1["Người dùng: Dữ liệu·Tài khoản·Cấu hình"]
    S2["CSP: Toàn bộ ứng dụng·hạ tầng"]
  end
  IAAS --> PAAS --> SAAS
  NOTE["Bất biến chung: bảo mật dữ liệu·tài khoản luôn là trách nhiệm người dùng"]
  SAAS --> NOTE
  style NOTE fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px

Với IaaS, người dùng trực tiếp chịu trách nhiệm đến cả OS, middleware, runtime nên gánh nặng vá lỗi và gia cố (hardening) lớn. Ngược lại, với SaaS, CSP vận hành đến tận ứng dụng nên người dùng chỉ cần tập trung vào phân loại dữ liệu, quyền truy cập và cấu hình chia sẻ. Nếu không nhận thức được khác biệt này, sẽ xảy ra sự cố như hiểu nhầm rằng CSP sẽ vá OS cho cơ sở dữ liệu đặt trên IaaS và bỏ mặc nó. Vì vậy, bước đầu tiên là văn bản hóa 'danh sách trách nhiệm của mình' theo từng mô hình dịch vụ định áp dụng.

3. Các yếu tố bảo mật chính cần xem xét — Từ dữ liệu đến chuỗi cung ứng

Khi áp dụng đám mây, cần rà soát phân tầng nhiều yếu tố từ dữ liệu đến vận hành. Bảng dưới đây nhằm bao quát toàn bộ các yếu tố, còn 'lý do' và hàm ý thực tiễn của từng yếu tố được giải thích bằng văn xuôi sau bảng.

Thứ nhất, bảo mật dữ liệu là đối tượng bảo vệ cuối cùng của mọi biện pháp kiểm soát. Phải mã hóa cả dữ liệu lưu trữ (at-rest) và dữ liệu truyền (in-transit), nhưng mấu chốt thực sự là quản lý khóa. Khóa do CSP quản lý (SSE) tiện lợi, nhưng khi yêu cầu về quy định và chủ quyền mạnh thì phải dùng khóa do khách hàng quản lý (BYOK/CMK) hoặc HSM. Ngoài ra, phải xác nhận dữ liệu được lưu trữ và xử lý vật lý ở quốc gia nào (chủ quyền dữ liệu); ví dụ, đặt thông tin cá nhân của Hàn Quốc tại region ở nước ngoài có thể phát sinh vấn đề pháp lý. Cần thiết kế toàn bộ vòng đời dữ liệu, đến cả tính toàn vẹn của bản sao lưu và việc hủy an toàn (bao gồm crypto-shredding thông qua hủy khóa mã hóa).

Thứ hai, kiểm soát truy cập (IAM) là tuyến đầu của các sự cố đám mây. Trên đám mây, console quản lý và API mở ra Internet, nên chỉ cần một tài khoản bị đánh cắp là toàn bộ hạ tầng bị phơi lộ. Vì vậy nguyên tắc đặc quyền tối thiểu, bắt buộc MFA cho mọi tài khoản quản trị, tránh khóa truy cập dài hạn (dùng token ngắn hạn·ủy quyền vai trò) là bắt buộc. Hơn nữa, CIEM (quản lý quyền hạ tầng đám mây) tự động phát hiện và thu hồi các quyền dư thừa tích tụ theo thời gian đang được chú ý gần đây. Trên thực tế, nhiều vụ rò rỉ bắt nguồn từ khóa truy cập bị bỏ quên hoặc chính sách IAM quá rộng.

Thứ ba, bảo mật cấu hình là nguồn rủi ro lớn nhất đặc thù của đám mây. Cấu hình sai (misconfiguration) như storage bucket bị cấu hình công khai nhầm, security group bị mở, log bị vô hiệu hóa chiếm phần lớn các sự cố thực tế. Con người không thể kiểm tra từng cái một, nên phương thức quét cấu hình liên tục bằng CSPM (Cloud Security Posture Management), và hơn nữa là dịch trái (shift-left) bắt cấu hình sai ngay ở giai đoạn mã IaC (Terraform…) trước khi triển khai, đang dần được định hình. Cốt lõi là chuyển từ "làm xong rồi sửa" sang "chặn trước khi làm".

Thứ tư, mạng, khả năng quan sát, quy định, tính liên tục, chuỗi cung ứng cũng phải được thực hiện song song. Về mạng, giảm phơi lộ bằng security group và kết nối riêng, đồng thời kiểm soát truy cập bằng Zero Trust không tin tưởng cả bên trong. Về khả năng quan sát, phải lưu log gọi API và bản ghi kiểm toán để có thể truy vết khi xảy ra sự cố, và liên kết với SIEM để phát hiện hành vi bất thường. Về quy định, nếu là đám mây khu vực công tại Hàn Quốc thì phải có CSAP (chứng nhận bảo mật đám mây), còn khu vực tư nhân cũng phải tuân thủ ISMS-P, Luật Bảo vệ Thông tin Cá nhân, GDPR…, và những điều này được đưa vào tiêu chí lựa chọn CSP trước khi áp dụng. Về tính liên tục, cần chuẩn bị trước thiết kế đa vùng sẵn sàng (AZ), đa region và DR, cùng chiến lược Exit (chấm dứt·chuyển đổi) cho phép thu hồi và di chuyển dữ liệu, khối lượng công việc để không bị trói buộc vào một CSP cụ thể. Cuối cùng, bảo mật chuỗi cung ứng — minh bạch hóa lỗ hổng của container image, mã nguồn mở, IaC bằng SBOM (bảng kê thành phần phần mềm) — gần đây đã nổi lên như một yếu tố bắt buộc.

A. Quy trình nội tại hóa bảo mật theo từng giai đoạn áp dụng

Các yếu tố trên chỉ có hiệu lực khi được bố trí vào từng giai đoạn của quy trình áp dụng. Luồng nội tại hóa bảo mật vào vòng đời áp dụng, thay vì kiểm tra sau, như sau.

flowchart LR
  A["1. Phân loại tài sản·dữ liệu<br/>(nhận diện độ nhạy cảm·quy định)"] --> B["2. Chọn CSP·mô hình dịch vụ<br/>(xác nhận CSAP·SLA·ranh giới trách nhiệm)"]
  B --> C["3. Thiết kế kiến trúc<br/>(IAM·mạng·mã hóa by design)"]
  C --> D["4. Triển khai·hiện thực<br/>(quét IaC·dịch trái)"]
  D --> E["5. Vận hành·giám sát<br/>(CSPM·log·phát hiện mối đe dọa)"]
  E --> F["6. Cải tiến·kiểm toán<br/>(ứng phó lỗ hổng·kiểm toán tuân thủ)"]
  F -. Phản hồi .-> C
  style D fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style E fill:#fff3e0,stroke:#e8890c,stroke-width:2px

Thất bại phổ biến nhất trong quy trình này là bỏ qua bước 1~3 (thiết kế) và chuyển thẳng sang triển khai. Nếu đưa lên đám mây mà không phân loại độ nhạy cảm của dữ liệu thì không thể phán đoán nên đặt kiểm soát nào ở đâu, và nếu không xác định ranh giới trách nhiệm thì sẽ xuất hiện khoảng trống kiểm soát. Vì vậy, bảo mật không phải thứ gắn thêm sau khi triển khai mà phải được phản ánh vào thiết kế ngay từ giai đoạn phân loại tài sản và chọn CSP, đồng thời phải có cấu trúc tuần hoàn (PDCA) trong đó kết quả CSPM và giám sát ở giai đoạn vận hành được phản hồi trở lại thiết kế. Trên thực tế, phần lớn sự cố cấu hình sai xảy ra ở những tổ chức đầu tư vào tự động hóa triển khai (IaC) nhưng lại bỏ qua kiểm chứng bảo mật cho chính mã đó (bước 4).

4. Tình huống và so sánh — Điều gì thay đổi so với on-premise

Sự khác biệt giữa bảo mật on-premise và đám mây xuất phát từ tính chất của 'ranh giới'. So sánh dưới đây không phải liệt kê hạng mục đơn thuần mà cho thấy vì sao phải thay đổi cách tiếp cận.

Ở on-premise, bảo mật vành đai coi mạng nội bộ được bao bọc bởi tường lửa là 'vùng tin cậy' đã hiệu quả. Nhưng trên đám mây, tài nguyên phơi ra Internet và được truy cập qua danh tính (ID) và API nên ranh giới gần như biến mất. Vì vậy mô hình chuyển sang Zero Trust, "lấy danh tính chứ không phải vị trí làm tiêu chuẩn tin cậy".

Một ví dụ cụ thể là vụ việc năm 2019 tại một công ty tài chính lớn, khi tường lửa đám mây (WAF) bị cấu hình sai kết hợp với vai trò IAM có quyền dư thừa khiến hơn 100 triệu bản ghi thông tin khách hàng bị rò rỉ; nguyên nhân không phải do bản thân hạ tầng bị xuyên thủng mà do thất bại trong cấu hình và quản lý quyền ở phía người dùng. Trường hợp này minh họa mang tính biểu tượng cho nhận định đã nhấn mạnh ở trên: "phần lớn sự cố thuộc trách nhiệm khách hàng". Một ví dụ khác là khi cơ quan công quyền Hàn Quốc áp dụng đám mây tư nhân, chỉ được dùng CSP đã có chứng nhận CSAP, nên ngay từ đầu việc tuân thủ quy định đã quyết định lựa chọn CSP. Như vậy, bảo mật đám mây gắn liền không chỉ với công nghệ mà cả quy định và quản trị.

5. Chuyên sâu — Tích hợp vào CNAPP·Zero Trust và xu hướng mới nhất

Bảo mật đám mây giai đoạn đầu có CSPM (cấu hình), CWPP (khối lượng công việc), CIEM (quyền), bảo mật container… tồn tại như những công cụ riêng biệt, khiến cảnh báo bị phân mảnh và khó xác định thứ tự ưu tiên. Gần đây, thị trường đang hội tụ về CNAPP (Cloud-Native Application Protection Platform) gộp tất cả thành một. CNAPP trực quan hóa tích hợp rủi ro trên toàn vòng đời ứng dụng từ mã (IaC) đến runtime, và liên kết tương quan (context) nhiều tín hiệu để ưu tiên hóa "những rủi ro thực sự có thể bị khai thác". Các tổ chức nghiên cứu thị trường dự báo trong vài năm tới, nếu không áp dụng CNAPP tích hợp thì nhiều doanh nghiệp sẽ khó bảo đảm khả năng quan sát rộng đối với bề mặt tấn công đám mây (số liệu và năm chính xác khác nhau giữa các báo cáo nên được khái quát hóa).

Một trục khác là sự kết hợp giữa dịch trái (Shift-Left) và Zero Trust. Dịch trái kéo bảo mật từ giai đoạn vận hành về giai đoạn đầu của phát triển (mã·CI/CD), chặn cấu hình sai và image dễ tổn thương trước khi chúng đi vào vận hành. Zero Trust kiểm chứng mọi truy cập bất kể bên trong hay bên ngoài (never trust, always verify), qua đó giảm thiểu di chuyển ngang (lateral movement) ngay cả khi tài khoản bị đánh cắp. Hai cách tiếp cận lần lượt đảm nhận 'chặn đầu vào' và 'kìm hãm lan rộng xâm phạm', còn CNAPP đóng vai trò nền tảng vận hành tích hợp chúng.

Ngoài ra, về mặt quy định cũng thay đổi nhanh chóng. Tại Hàn Quốc, khi mở rộng việc khu vực công sử dụng đám mây tư nhân, xu hướng chia CSAP thành các cấp 'cao·trung·thấp' để áp dụng phân biệt theo mức độ quan trọng của hệ thống đang được thảo luận và định hình; trên thế giới, yêu cầu minh bạch chuỗi cung ứng ngày càng mạnh và việc nộp SBOM đang lan rộng thành điều kiện mua sắm (tiêu chí phân cấp chi tiết và thời điểm thi hành có thể thay đổi theo chính sách nên được khái quát hóa). Điều này có nghĩa bảo mật đám mây vượt ra ngoài kiểm soát kỹ thuật và gắn trực tiếp với ứng phó quy định·yêu cầu mua sắm, vì vậy tổ chức áp dụng không chỉ cần đội kỹ thuật mà phải phối hợp với bộ phận tuân thủ và pháp chế để liên tục theo dõi thay đổi quy định.

Về chiến lược làm bài từ góc nhìn Kỹ sư chuyên nghiệp, thay vì chỉ liệt kê đơn thuần các yếu tố bảo mật đám mây, cấu trúc hóa theo mạch ba bước ① mô hình trách nhiệm chia sẻ (tiền đề) → ② các kiểm soát cốt lõi như dữ liệu·IAM·cấu hình (thân bài) → ③ tích hợp vào CNAPP·Zero Trust·dịch trái (hướng phát triển) sẽ có lợi cho điểm cao. Đặc biệt, đưa ra căn cứ thực chứng rằng "phần lớn sự cố bắt nguồn từ cấu hình sai và quản lý tài khoản" sẽ giúp luận điểm có sức thuyết phục.

6. Những điểm cần cân nhắc và hàm ý

1. Hiểu mô hình trách nhiệm chia sẻ là điểm xuất phát của bảo mật. Cần văn bản hóa rõ ràng phạm vi mình chịu trách nhiệm (luôn bao gồm dữ liệu và tài khoản) trong mô hình dịch vụ đã chọn (IaaS/PaaS/SaaS) và bố trí kiểm soát phù hợp. Hiểu sai ranh giới sẽ dẫn thẳng đến khoảng trống kiểm soát.
2. Lỗi cấu hình và quản lý tài khoản là rủi ro lớn nhất. Kho lưu trữ công khai, quyền quá mức, khóa truy cập bị rò rỉ chiếm phần lớn sự cố thực tế, vì vậy phải ưu tiên hàng đầu tăng cường CSPM (kiểm tra cấu hình), IAM/CIEM (quản lý quyền), MFA, và chặn cấu hình sai ở giai đoạn IaC trước khi triển khai.
3. Phản ánh quy định và chủ quyền dữ liệu ngay từ đầu quá trình áp dụng. Đưa các quy định áp dụng như CSAP cho khu vực công, ISMS-P, Luật Bảo vệ Thông tin Cá nhân, GDPR cho khu vực tư vào tiêu chí chọn CSP, đồng thời rà soát trước vị trí lưu trữ vật lý của dữ liệu và yêu cầu chuyển dữ liệu ra nước ngoài để loại bỏ rủi ro pháp lý.
4. Chuẩn bị cho sự phụ thuộc bằng tính liên tục và chiến lược Exit. Bảo đảm tính sẵn sàng bằng đa AZ, đa region, DR, và để không bị khóa chặt (lock-in) vào một CSP cụ thể, cần bảo đảm trước khả năng di chuyển dữ liệu và khối lượng công việc cùng điều kiện thu hồi theo hợp đồng, nhằm duy trì năng lực đàm phán và khả năng phục hồi.
5. Phát triển theo hướng quản lý tích hợp bằng CNAPP·Zero Trust. Thay cho các công cụ riêng lẻ phân mảnh, áp dụng CNAPP kiểm tra tích hợp khối lượng công việc, cấu hình, quyền và chuỗi cung ứng, đồng thời hướng tới phòng thủ nhiều lớp: chặn đầu vào bằng dịch trái và kìm hãm lan rộng bằng Zero Trust.

Tài liệu tham khảo

• Khái niệm CNAPP (Wiz Academy): https://www.wiz.io/academy/cloud-security/what-is-a-cloud-native-application-protection-platform-cnapp
• Tổng quan công cụ CSPM 2025 (SentinelOne): https://www.sentinelone.com/cybersecurity-101/cloud-security/cspm-tools/
• Hướng dẫn chế độ chứng nhận bảo mật đám mây Hàn Quốc (CSAP) (KISA): https://isms.kisa.or.kr/main/csap/intro/

Tóm tắt một câu: Khi áp dụng đám mây, cần rà soát phân tầng trên tiền đề mô hình trách nhiệm chia sẻ các yếu tố mã hóa dữ liệu·quản lý khóa, IAM/CIEM, bảo mật cấu hình (CSPM), mạng·khả năng quan sát, quy định (CSAP)·chủ quyền dữ liệu, tính liên tục·Exit, chuỗi cung ứng (SBOM); vì phần lớn sự cố bắt nguồn từ cấu hình sai và quản lý tài khoản, cần ứng phó bằng CSPM, IAM, dịch trái cùng với tích hợp CNAPP và Zero Trust.