Loading...

Bài 40. Mô hình trách nhiệm chia sẻ: IaaS, PaaS, SaaS và multicloud

Khóa học CompTIA Security+ SY0-801 · Phần 3: Kiến trúc bảo mật · Bài 40 · 🎯 Objective 3.1 · ⏱️ Đọc khoảng 15 phút · 🧪 Không cần lab · 📝 5 câu bài tập cuối bài

🎯 Mục tiêu bài học

  • Nhắc lại và đi sâu hơn mô hình trách nhiệm chia sẻ theo từng lớp cụ thể, không chỉ ba chữ IaaS/PaaS/SaaS.
  • Phân biệt trách nhiệm của nhà cung cấp và khách hàng ở từng lớp: phần cứng, ảo hóa, mạng, hệ điều hành, ứng dụng, dữ liệu, danh tính.
  • Hiểu multicloud là gì và rủi ro riêng khi dùng nhiều nhà cung cấp cùng lúc.
  • Tránh các hiểu lầm phổ biến dẫn tới sự cố thật trong ngành.

📎 Vị trí trong đề thi: Bài 26 và Bài 39 đã giới thiệu trách nhiệm chia sẻ ở mức tổng quan. Bài này là phiên bản chi tiết hơn mà đề thi SY0-801 thường hỏi dưới dạng: cho một lớp cụ thể (như "hệ điều hành" hay "ứng dụng"), hỏi ai chịu trách nhiệm với từng mô hình dịch vụ.

💡 Liên hệ thực tế: cuộc họp với nhà cung cấp cloud

Công ty chị Lan sắp ký hợp đồng dùng dịch vụ của hai nhà cung cấp cloud khác nhau: một cho máy chủ ảo, một cho phần mềm quản lý nhân sự. Trước khi ký, Nam yêu cầu làm rõ: "ai vá lỗi hệ điều hành? ai chịu trách nhiệm nếu tài khoản quản trị của chúng tôi bị lộ?" Đây là tình huống minh họa, không phải vụ việc có thật.

Câu trả lời khác nhau tùy dịch vụ. Với máy chủ ảo (IaaS), nhà cung cấp chỉ lo phần cứng và lớp ảo hóa; vá hệ điều hành là việc của công ty. Với phần mềm nhân sự (SaaS), nhà cung cấp lo gần như mọi thứ kỹ thuật, nhưng nếu nhân viên dùng mật khẩu yếu và bị chiếm tài khoản, đó vẫn là trách nhiệm của công ty, không phải lỗi của nhà cung cấp.

Nam tóm cho chị Lan một câu: "Dù thuê loại dịch vụ nào, không ai thay chúng ta quản lý ai được vào xem dữ liệu của mình."

📊 Hình 40a. Càng lên IaaS → PaaS → SaaS, nhà cung cấp lo càng nhiều lớp, nhưng dòng trên cùng luôn là việc của khách hàng.

📘 Kiến thức cốt lõi

🧱 Bảy lớp trong mô hình trách nhiệm chia sẻ

Thay vì chỉ nhớ "IaaS/PaaS/SaaS chia việc khác nhau", hãy nhớ bảy lớp xếp từ thấp lên cao, và với mỗi mô hình dịch vụ, một "lằn ranh" nằm ở vị trí khác nhau:

  1. Phần cứng, trung tâm dữ liệu (bảo vệ vật lý, điện, làm mát)
  2. Ảo hóa (hypervisor, Bài 26)
  3. Mạng (định tuyến, tường lửa của hạ tầng)
  4. Hệ điều hành (vá lỗi, cấu hình máy chủ)
  5. Runtime và middleware (môi trường chạy ứng dụng)
  6. Ứng dụng (mã nguồn, logic nghiệp vụ)
  7. Dữ liệu và danh tính (ai được truy cập gì)

Với IaaS, lằn ranh nằm giữa lớp 3 và 4: nhà cung cấp lo từ ảo hóa trở xuống, khách hàng lo từ hệ điều hành trở lên. Với PaaS, lằn ranh nằm giữa lớp 5 và 6: nhà cung cấp lo cả hệ điều hành và môi trường chạy, khách hàng chỉ lo ứng dụng, dữ liệu, danh tính. Với SaaS, lằn ranh nằm giữa lớp 6 và 7: nhà cung cấp lo gần như mọi thứ kỹ thuật, khách hàng chỉ còn dữ liệu và danh tính.

Lớp 7 (dữ liệu và danh tính) không bao giờ thuộc về nhà cung cấp, bất kể mô hình nào. Đây là điểm quan trọng nhất của toàn bộ mô hình.

📋 Bảng chi tiết theo mô hình dịch vụ

LớpIaaSPaaSSaaS
Phần cứng, trung tâm dữ liệu Nhà cung cấp Nhà cung cấp Nhà cung cấp
Ảo hóa Nhà cung cấp Nhà cung cấp Nhà cung cấp
Mạng hạ tầng Nhà cung cấp Nhà cung cấp Nhà cung cấp
Hệ điều hành (vá lỗi, cấu hình) Khách hàng Nhà cung cấp Nhà cung cấp
Runtime, middleware Khách hàng Nhà cung cấp Nhà cung cấp
Ứng dụng (mã nguồn, cấu hình) Khách hàng Khách hàng Nhà cung cấp
Dữ liệu và danh tính Khách hàng Khách hàng Khách hàng

Ví dụ cụ thể để ghi nhớ:

  • IaaS (như một máy chủ ảo thuê): nếu máy bị nhiễm mã độc do hệ điều hành chưa vá, đó là lỗi của khách hàng.
  • PaaS (như một nền tảng chạy ứng dụng web được quản lý sẵn): nếu ứng dụng có lỗ hổng SQL injection do mã do khách hàng viết (Bài 25), đó là lỗi của khách hàng, dù nhà cung cấp lo hệ điều hành bên dưới.
  • SaaS (như phần mềm quản lý nhân sự thuê trọn gói): nếu nhân viên dùng mật khẩu yếu và bị chiếm tài khoản, đó vẫn là lỗi của khách hàng, dù nhà cung cấp lo toàn bộ hạ tầng và ứng dụng.

⚠️ Hiểu lầm phổ biến dẫn tới sự cố thật

Rất nhiều vụ rò rỉ dữ liệu trên cloud trong thực tế không đến từ lỗi của nhà cung cấp, mà từ việc khách hàng hiểu sai ranh giới trách nhiệm:

  • Nghĩ rằng "cloud tự động sao lưu", trong khi phần lớn nhà cung cấp chỉ đảm bảo tính sẵn sàng của hạ tầng, còn sao lưu dữ liệu ứng dụng thường là việc khách hàng phải tự cấu hình.
  • Nghĩ rằng "cloud tự động mã hóa và bảo mật", trong khi nhiều tính năng bảo mật (mã hóa, ghi nhật ký, MFA) cần khách hàng chủ động bật và cấu hình đúng.
  • Để kho lưu trữ công khai do không hiểu thiết lập mặc định của dịch vụ (Bài 27).
  • Không bật MFA cho tài khoản quản trị cloud, cho rằng "nhà cung cấp đã bảo mật hệ thống của họ rồi".

🌐 Multicloud

Multicloud là dùng nhiều nhà cung cấp cloud khác nhau cùng lúc, thường vì các lý do:

  • Tránh phụ thuộc một nhà cung cấp (vendor lock-in, Bài 39).
  • Tận dụng điểm mạnh riêng của mỗi nhà cung cấp cho từng loại khối lượng công việc.
  • Yêu cầu của khách hàng hoặc quy định tại từng khu vực địa lý.

Rủi ro riêng của multicloud:

🌐 Hình 40b. Nhiều nhà cung cấp nghĩa là nhiều giao diện quản trị, nhiều mô hình quyền, dễ xảy ra khoảng trống khi không ai theo dõi đủ cả hai bên.

  • Độ phức tạp nhân lên: mỗi nhà cung cấp có công cụ, thuật ngữ và mô hình quyền riêng, đội vận hành phải thông thạo nhiều hệ thống.
  • Khó có cái nhìn tổng thể (visibility): nhật ký và cảnh báo nằm rải rác ở nhiều nơi, dễ bỏ sót dấu hiệu bất thường (liên quan IoC, Bài 33).
  • Cấu hình không nhất quán: chính sách bảo mật ở nhà cung cấp A có thể không được áp dụng giống ở nhà cung cấp B, tạo ra lỗ hổng do sai khác.
  • Chi phí và công sức quản lý tăng, dễ dẫn tới việc một môi trường bị "bỏ quên" ít được rà soát hơn môi trường chính.

Giảm thiểu: dùng công cụ quản lý tư thế bảo mật cloud (CSPM, Bài 26) có khả năng nhìn xuyên nhiều nhà cung cấp, chuẩn hóa chính sách bằng hạ tầng dưới dạng mã (Infrastructure as Code, sẽ học ở Bài 41), và phân công rõ ai chịu trách nhiệm giám sát từng môi trường.

🎯 Mẹo làm bài: khi đề cho một lớp cụ thể (hệ điều hành, ứng dụng, dữ liệu...) và hỏi ai chịu trách nhiệm, hãy nhớ quy tắc: dữ liệu và danh tính luôn là của khách hàng. Với IaaS, mọi thứ từ hệ điều hành trở lên là của khách hàng. Với PaaS, chỉ ứng dụng và dữ liệu là của khách hàng. Với SaaS, chỉ dữ liệu và danh tính là của khách hàng. Khi đề nói đến nhiều nhà cung cấp cloud cùng lúc, nghĩ ngay đến multicloud và rủi ro về tính nhất quán và khả năng quan sát.

🧠 Áp vào câu chuyện của Nam

Câu hỏi của chị LanKhái niệm trả lời
"Máy chủ ảo bị nhiễm do hệ điều hành chưa vá, lỗi của ai?" IaaS: hệ điều hành là trách nhiệm của khách hàng
"Ứng dụng tự viết trên nền tảng PaaS bị SQL injection, lỗi của ai?" PaaS: ứng dụng vẫn là trách nhiệm của khách hàng
"Nhân viên dùng mật khẩu yếu trên phần mềm SaaS thì sao?" SaaS: dữ liệu và danh tính luôn là việc của khách hàng
"Dùng hai nhà cung cấp cloud có lợi gì, rủi ro gì?" Multicloud: tránh phụ thuộc, nhưng khó nhất quán và khó quan sát

📖 Thuật ngữ cần nhớ

Thuật ngữNghĩa
Shared responsibility Mô hình chia trách nhiệm bảo mật giữa nhà cung cấp và khách hàng.
IaaS / PaaS / SaaS Hạ tầng / nền tảng / phần mềm dưới dạng dịch vụ.
Multicloud Dùng nhiều nhà cung cấp cloud khác nhau cùng lúc.
Vendor lock-in Phụ thuộc vào một nhà cung cấp, khó chuyển đổi.
CSPM Công cụ quản lý tư thế bảo mật cloud.
Visibility Khả năng quan sát và giám sát toàn bộ môi trường.

📌 Tóm tắt nhanh

  • Mô hình trách nhiệm chia sẻ chia theo bảy lớp; lằn ranh dịch chuyển tùy IaaS, PaaS hay SaaS.
  • Dữ liệu và danh tính luôn là trách nhiệm của khách hàng, dù dùng mô hình nào.
  • Nhiều sự cố cloud thực tế đến từ hiểu lầm về ranh giới trách nhiệm, không phải lỗi hạ tầng của nhà cung cấp.
  • Multicloud giảm phụ thuộc một nhà cung cấp nhưng tăng độ phức tạp, dễ mất tính nhất quán và khả năng quan sát.

💬 Hỏi & Đáp nhanh

❓ Nhà cung cấp cloud có "mặc định" bảo mật mọi thứ không? Không. Nhiều tính năng bảo mật quan trọng (mã hóa, MFA, ghi nhật ký, chặn truy cập công khai) cần khách hàng chủ động bật và cấu hình. Thiết lập mặc định đôi khi ưu tiên dễ dùng hơn là an toàn tối đa.

❓ Multicloud có phải lúc nào cũng tốt hơn một nhà cung cấp duy nhất? Không. Nó giải quyết vấn đề phụ thuộc nhưng tạo ra vấn đề khác: độ phức tạp và khó quan sát. Tổ chức cần cân nhắc liệu lợi ích có vượt qua chi phí quản lý tăng thêm hay không.

❓ Làm sao nhớ nhanh ai chịu trách nhiệm gì? Nhớ một câu: "Càng dịch vụ hóa cao (SaaS), nhà cung cấp lo càng nhiều — nhưng dữ liệu và ai được vào xem luôn là việc của mình."

📝 Bài tập đánh giá

Tự chọn đáp án cho từng câu, rồi đối chiếu với phần đáp án ở cuối bài.

Câu 1. Với mô hình IaaS, ai chịu trách nhiệm vá lỗi hệ điều hành của máy chủ ảo?

  • A. Nhà cung cấp cloud
  • B. Khách hàng
  • C. Không ai cần vá
  • D. Tùy thỏa thuận, không có quy tắc chung

Câu 2. Với mô hình SaaS, lớp nào sau đây vẫn luôn là trách nhiệm của khách hàng?

  • A. Phần cứng máy chủ
  • B. Dữ liệu và quản lý danh tính, quyền truy cập
  • C. Lớp ảo hóa
  • D. Bảo vệ vật lý trung tâm dữ liệu

Câu 3. Một tổ chức dùng PaaS để chạy ứng dụng tự viết. Ứng dụng bị lỗi SQL injection do mã nguồn của chính tổ chức. Ai chịu trách nhiệm?

  • A. Nhà cung cấp PaaS, vì họ quản lý nền tảng
  • B. Khách hàng, vì ứng dụng và mã nguồn là trách nhiệm của khách hàng trong mô hình PaaS
  • C. Không ai, vì PaaS tự động an toàn
  • D. Nhà sản xuất phần cứng

Câu 4. Rủi ro đặc trưng của multicloud là gì?

  • A. Không có rủi ro gì vì dùng nhiều nhà cung cấp luôn an toàn hơn
  • B. Độ phức tạp tăng, khó duy trì tính nhất quán và khả năng quan sát xuyên các môi trường
  • C. Chỉ tồn tại ở on-premises
  • D. Chỉ liên quan tới tốc độ mạng

Câu 5. Một tổ chức tin rằng dịch vụ cloud họ đang thuê "tự động sao lưu toàn bộ dữ liệu ứng dụng" nên không cấu hình gì thêm. Đây là ví dụ của vấn đề gì?

  • A. Zero-day
  • B. Hiểu lầm về ranh giới trách nhiệm chia sẻ
  • C. VM escape
  • D. Typosquatting

👉 Đáp án

Câu 1: B — Với IaaS, hệ điều hành trở lên là trách nhiệm của khách hàng.

Câu 2: B — Dữ liệu và quản lý danh tính, quyền truy cập luôn là trách nhiệm của khách hàng ở mọi mô hình, kể cả SaaS.

Câu 3: B — Với PaaS, ứng dụng và mã nguồn do khách hàng viết vẫn là trách nhiệm của khách hàng.

Câu 4: B — Multicloud tăng độ phức tạp quản lý, dễ mất tính nhất quán về chính sách và khó có cái nhìn tổng thể.

Câu 5: B — Đây là hiểu lầm phổ biến về ranh giới trách nhiệm: sao lưu dữ liệu ứng dụng thường cần khách hàng tự cấu hình.


📚 Bài viết thuộc khóa học CompTIA Security+ của VNExperts

🧭 Điều hướng

⬅️ Bài trước🏠 Mục lục khóa họcBài kế tiếp ➡️
Bài 39: Kiến trúc on-premises, cloud và hybrid Mục lục khóa học CompTIA Security+ Bài 41: Hạ tầng dưới dạng mã (IaC), serverless và tự động mở rộng