Shared Responsibility chỉ hoạt động khi từng control có owner rõ ràng. Khoảng trống nguy hiểm xuất hiện khi hosting nghĩ khách hàng chịu phần application, khách hàng lại tưởng hosting hoặc managed provider đã lo toàn bộ security; kết quả là patch, account review, firewall rule, backup, monitoring hoặc remediation có thể bị bỏ trống dù mỗi bên đều tin “phần đó đã có người xử lý”.
AWS mô tả shared responsibility theo hướng provider chịu “security of the cloud”, còn khách hàng chịu phần “security in the cloud” tùy dịch vụ sử dụng; với IaaS, customer vẫn phải quản lý guest OS, patch, application và security-group configuration. Microsoft cũng nêu rõ data, identities và configurations luôn còn phần trách nhiệm của khách hàng, trong khi mức chia thay đổi theo IaaS/PaaS/SaaS. Google Cloud chuyển sang khái niệm shared fate để giảm các security assumptions sai và tăng phối hợp giữa provider với customer. Nguồn: AWS Shared Responsibility Model, Microsoft — Shared responsibility in the cloud và Google Cloud — Shared Fate.
Bối cảnh: control quan trọng bị bỏ trống giữa nhiều bên
Giả sử một website chạy trên cloud VM, phía hosting/provider bảo vệ physical infrastructure và hypervisor. Đội website thuê thêm một đơn vị vận hành để quản lý uptime và deployment, nhưng không có tài liệu xác định ai chịu trách nhiệm patch OS, review admin account, quản lý firewall, cập nhật plugin và xử lý security alert.
Một plugin vulnerable tồn tại lâu hơn dự kiến, đồng thời một admin account cũ vẫn còn quyền cao. Khi compromise xảy ra, mỗi bên đều có một phần capability nhưng không bên nào sở hữu end-to-end control.
Những tín hiệu cho thấy Shared Responsibility đang có gap
- Không có responsibility matrix theo control/capability.
- Cùng một control được hai bên tưởng rằng bên kia đang xử lý.
- Security finding không có remediation owner rõ ràng.
- Provider gửi advisory nhưng không ai xác nhận action ở application layer.
- Monitoring tạo alert nhưng không có quyền thay đổi hoặc escalation path.
- Hạng mục out-of-scope không được ghi rõ nên bị hiểu nhầm thành “đã được cover”.
Investigation: xác định control nào không có owner
Bước 1: map responsibility theo service model và capability
Không nên dùng một câu chung như “hosting lo security”. Với IaaS, provider có thể bảo vệ hardware, physical network và virtualization layer nhưng customer vẫn chịu OS, app, identity, data và nhiều network control. Với PaaS/SaaS, một phần trách nhiệm chuyển thêm sang provider nhưng customer vẫn giữ data, identity và configuration liên quan.
Vì vậy responsibility matrix phải đi theo capability cụ thể: patching, identity, backup, WAF/CDN, DNS, TLS, application code, monitoring, incident response, remediation và recovery.
Bước 2: phân biệt “có công cụ” với “có owner vận hành”
Cloud provider có thể cung cấp firewall, IAM, logging hoặc backup service nhưng điều đó không có nghĩa policy đã được cấu hình đúng hoặc có người theo dõi output. Microsoft nhấn mạnh configuration, accounts và access management vẫn là phần customer phải quản trị trong nhiều mô hình dịch vụ.
Một managed provider cũng có thể monitor nhưng không có quyền patch; hoặc có quyền patch nhưng không sở hữu application testing. Nếu quyền và trách nhiệm không khớp, finding dễ rơi vào trạng thái “đã giao cho bên khác” mà không có closure.
Bước 3: truy ngược timeline của control failure
Với incident cụ thể, cần dựng timeline từ advisory/finding ban đầu → notification → owner assignment → remediation action → retest/closure. Nếu gap xuất hiện tại bước không có owner, quyền không đủ hoặc out-of-scope mơ hồ, đó là evidence của shared-responsibility failure.
Đọc thêm Shared Responsibility trong Website Security, Managed Security Scope và Managed Security Review để chuẩn hóa ownership, scope và evidence.
Khi nào có thể xác nhận compromise liên quan responsibility gap?
Không nên đổ lỗi cho shared responsibility chỉ vì có nhiều vendor tham gia. Cần chỉ ra một control cụ thể đã không được thực hiện hoặc không được verify do ownership gap.
- Control cần thiết không có owner được ghi nhận.
- Hai bên có expectation trái ngược về cùng một responsibility.
- Finding/advisory đã tồn tại nhưng không ai thực hiện remediation.
- Quyền thay đổi và trách nhiệm không nằm ở cùng một bên hoặc không có escalation.
- Timeline cho thấy gap trực tiếp kéo dài exposure tới thời điểm compromise.
Remediation: biến Shared Responsibility thành operating model thực tế
Lập responsibility matrix theo control
- Ghi rõ Responsible, Accountable, Consulted và Informed cho từng capability quan trọng.
- Phân biệt provider responsibility, customer responsibility và shared responsibility.
- Gắn quyền thay đổi tương ứng với remediation owner.
- Ghi rõ hạng mục out-of-scope để không tạo assumption sai.
- Đặt escalation path khi owner không có đủ quyền hoặc dependency nằm ở bên khác.
AWS Prescriptive Guidance khuyến nghị phân phối security ownership giữa cloud và application teams; một cách hiểu thực tế là bên nào có quyền cấu hình resource thì phải có trách nhiệm bảo vệ phần cấu hình đó. Tuy nhiên với website nhiều vendor, vẫn cần một accountable owner để tránh trách nhiệm bị chia nhỏ tới mức không ai chịu closure.
Đưa ownership vào SLA, review và closure gate
Responsibility matrix chỉ có giá trị khi đi vào vận hành: alert phải route đúng owner, finding phải có remediation SLA, out-of-scope phải được escalate và review định kỳ phải kiểm tra gap mới xuất hiện sau architecture/vendor change.
Dùng Managed Security Scope để khóa capability và quyền thay đổi; dùng Managed Security Review để kiểm tra scope drift, recurring gap và unresolved ownership.
Validation sau khi sửa responsibility gap
| Kiểm tra | Kết quả mong đợi |
|---|---|
| Responsibility matrix | Mỗi control có owner/accountable rõ ràng |
| Out-of-scope items | Được ghi rõ và có escalation path |
| Permissions | Remediation owner có đủ quyền hoặc dependency rõ |
| Alert routing | Signal tới đúng owner trong SLA |
| Finding closure | Có remediation + read-back/retest evidence |
| Architecture/vendor changes | Kích hoạt review trách nhiệm |
| Recurring gaps | Giảm ở review cycle tiếp theo |
Bài học vận hành
- Provider cung cấp control không đồng nghĩa control đã được cấu hình và vận hành đúng.
- Shared responsibility thay đổi theo IaaS/PaaS/SaaS và từng dịch vụ cụ thể.
- Security gap thường xuất hiện ở ranh giới giữa nhiều owner hơn là ở phần mỗi bên sở hữu rõ.
- Out-of-scope mơ hồ dễ tạo false assurance.
- Quyền thay đổi, remediation owner và closure evidence phải gắn với nhau.
- Mỗi thay đổi provider, architecture hoặc managed-service scope nên kích hoạt review responsibility matrix.