Shared Responsibility Website Security

Shared Responsibility trong Website Security là nguyên tắc phân chia trách nhiệm bảo mật giữa chủ website và các bên tham gia vận hành hệ thống như hosting/cloud, developer, CDN/WAF, DNS provider, SaaS và Managed Security provider. Không một bên nào tự động chịu trách nhiệm cho toàn bộ security stack chỉ vì họ đang cung cấp một phần hạ tầng hoặc dịch vụ.

Mô hình này đặc biệt quan trọng với website hiện đại vì một sự cố có thể đi qua nhiều lớp: application code do developer quản lý, server chạy trên cloud, traffic đi qua CDN/WAF, DNS nằm ở registrar khác và alert được một Managed Security provider theo dõi. Nếu ownership không rõ, finding dễ bị chuyển vòng giữa các bên hoặc tồn tại vì ai cũng nghĩ “đó là phần của vendor khác”.

Shared Responsibility là gì?

Trong cloud security, mô hình shared responsibility phân tách những lớp nhà cung cấp bảo vệ và những lớp khách hàng vẫn phải quản lý. AWS mô tả trách nhiệm khách hàng thay đổi theo loại dịch vụ sử dụng; với IaaS, khách hàng vẫn quản lý guest OS, application và nhiều cấu hình bảo mật, trong khi cloud provider chịu trách nhiệm cho hạ tầng nền tảng.

Với website, nguyên tắc tương tự nhưng thường có nhiều hơn hai bên. Vì vậy không nên sao chép nguyên một sơ đồ cloud rồi áp cho mọi hệ thống. Responsibility phải được map theo kiến trúc, contract, quyền truy cập và capability thực tế.

Nguyên tắc ownership và các bên tham gia

Outsource vận hành không đồng nghĩa outsource toàn bộ Risk

Doanh nghiệp có thể thuê ngoài monitoring, WAF tuning, vulnerability management hoặc incident response, nhưng business owner vẫn phải quyết định asset nào quan trọng, mức risk nào chấp nhận được, ai có quyền production và thay đổi nào cần phê duyệt.

Provider chỉ có thể chịu trách nhiệm trong phạm vi capability và authorization được giao. Nếu provider không có quyền DNS, họ không thể chịu trách nhiệm trực tiếp cho DNS remediation. Nếu không quản lý source code, họ có thể validate vulnerability và escalation nhưng không thể bảo đảm thời điểm code fix.

Những bên thường xuất hiện trong Website Security

Business/Website Owner: sở hữu business risk, dữ liệu, critical flow và quyết định cuối cùng.
Developer/Agency: chịu trách nhiệm source code, application logic, dependency và deployment trong scope hợp đồng.
Hosting/Cloud Provider: chịu trách nhiệm cho phần hạ tầng/dịch vụ mà họ vận hành; phần khách hàng phải quản lý thay đổi theo service model.
CDN/WAF Provider: vận hành edge platform, nhưng rule, exception, DNS/origin và policy vẫn cần được cấu hình đúng.
Managed Security Provider: thực hiện monitoring, triage, WAF review, vulnerability coordination hoặc incident response theo scope.
DNS/Registrar/SaaS Vendor: bảo vệ nền tảng của họ, còn khách hàng vẫn quản lý account, permission và cấu hình sử dụng.

Một công ty có thể đảm nhiệm nhiều vai trò, nhưng responsibility nên được định nghĩa theo capability thay vì theo tên vendor.

Trách nhiệm theo từng lớp hệ thống

Data và Business Context

Nhà cung cấp kỹ thuật không thể tự biết dữ liệu nào nhạy cảm, flow nào tạo doanh thu hoặc downtime nào có impact cao nếu khách hàng không cung cấp context. Business owner cần xác định:

Critical assets và dữ liệu.
Critical flows như login, checkout, booking hoặc API.
Risk appetite.
Availability requirement.
Legal/contractual requirements nếu có.

Đây là đầu vào để severity, SLA và remediation priority có ý nghĩa.

Identity và Access

Hosting hoặc SaaS có thể cung cấp MFA, IAM và audit log; Managed Security có thể review privilege; nhưng doanh nghiệp vẫn phải quản lý user lifecycle: ai đang làm việc, ai đã nghỉ, ai cần admin và ai phê duyệt quyền.

Responsibility matrix nên trả lời:

Ai tạo và xóa user?
Ai review privilege?
Ai quản lý recovery channel?
Ai rotate API token/SSH key?
Ai được quyền disable account khi incident?

Source Code và Application Vulnerability

Hosting provider thường không chịu trách nhiệm sửa lỗi business logic, insecure authorization hoặc vulnerability trong source code khách hàng. Managed Security có thể phát hiện, validate và tạo remediation ticket; developer thường là bên triển khai fix.

Handoff tốt nên có chuỗi rõ: finding → severity → developer owner → fix → deploy → security retest → closure evidence.

Server, OS và Runtime

Trách nhiệm thay đổi theo service model. Với self-managed VM/IaaS, khách hàng hoặc đội vận hành thường phải quản lý guest OS, patch, web server, runtime, firewall rule và account. Với managed platform, provider có thể chịu nhiều lớp hơn.

Vì vậy contract không nên chỉ ghi “hosting đã bảo mật”. Nên map từng lớp cụ thể và dùng checklist vận hành như Server Security Maintenance Checklist để gắn patch, exposure và configuration drift vào đúng owner.

CDN/WAF và Origin Protection

CDN/WAF provider bảo vệ platform edge, nhưng khách hàng vẫn cần route traffic đúng, cấu hình rule/exception và bảo vệ origin. Managed Security có thể tune rule nếu nằm trong scope.

Một WAF hoạt động tốt vẫn có thể bị bypass nếu origin public. Origin Protection là ví dụ điển hình về responsibility cần phối hợp giữa DNS/CDN, firewall/origin và đội vận hành.

Rule và exception cũng cần lifecycle review; có thể dùng WAF Maintenance Checklist.

Vulnerability và Patch Management

Scanner hoặc security provider có thể phát hiện vulnerability, nhưng remediation owner phải rõ. Một flow thực tế:

Security/provider phát hiện và validate finding.
Risk được ưu tiên theo exposure và business impact.
Developer/hosting/ops thực hiện fix theo layer.
Production owner phê duyệt change nếu cần.
Security retest và xác nhận closure.

“Đã gửi cảnh báo” không nên được coi là hoàn thành nếu service được kỳ vọng theo dõi remediation đến closure.

Logging và Monitoring

Provider có thể triển khai monitoring, nhưng customer/vendor phải bảo đảm nguồn log tồn tại và provider có quyền truy cập. Nếu application không ghi security event quan trọng, SOC không thể điều tra dữ liệu chưa bao giờ được tạo.

Ở lớp server, Server Audit Logging giúp xác định nhóm sự kiện cần lưu trước khi bàn tới alert và retention.

Alert Triage và Incident Response

Shared responsibility phải tách detection khỏi response. Có thể monitoring platform hoạt động 24/7 nhưng human triage chỉ trong business hours; hoặc Managed Security triage 24/7 nhưng containment cần customer approval.

Incident responsibility nên trả lời:

Ai xác nhận incident?
Ai có quyền block, isolate hoặc revoke?
Ai liên hệ developer/hosting?
Ai quyết định shutdown hoặc degraded mode?
Ai giao tiếp với management/legal/customer?
Ai xác nhận recovery hoàn tất?

Backup và Recovery

Hosting có thể cung cấp backup feature nhưng customer vẫn cần biết backup nào quan trọng, retention phù hợp không và ai có quyền restore. Managed Security có thể monitor backup failure hoặc yêu cầu restore test nếu capability đó nằm trong scope.

Nên tách bốn responsibility: tạo backup, bảo vệ backup, kiểm tra backup và thực hiện recovery. Không mặc định cùng một bên chịu cả bốn.

DNS, Domain và Registrar

Registrar chịu trách nhiệm bảo vệ nền tảng registrar; customer chịu trách nhiệm account security, MFA, recovery contact và thay đổi DNS được ủy quyền. Nếu agency hoặc Managed Security quản lý DNS, phải có audit trail và approval process.

Domain takeover hoặc DNS change trái phép có thể bypass nhiều lớp application security, nên registrar access phải nằm trong security inventory.

Security Change và Production Approval

Managed Security có thể đề xuất hoặc thực hiện WAF rule, firewall change, account action hoặc patch. Nhưng quyền phê duyệt production change phải được xác định theo impact.

Thông thường customer giữ quyền đối với thay đổi có business impact lớn, trong khi provider có thể được pre-authorize một số action hẹp. Mỗi write nên có snapshot, validation và rollback phù hợp.

Compliance và Legal Responsibility

Vendor có thể cung cấp control hoặc evidence hỗ trợ compliance, nhưng sử dụng một dịch vụ không tự động khiến customer “compliant”. Doanh nghiệp vẫn phải xác định nghĩa vụ pháp lý, audit scope và risk acceptance của mình.

Provider chỉ nên claim chứng nhận hoặc phạm vi compliance mà họ có evidence tương ứng.

Responsibility Matrix thực tế

Ví dụ Responsibility Matrix cho Website

Capability	Business Owner	Managed Security	Developer	Hosting/Cloud
Risk/business priority	Accountable	Consulted	Consulted	Informed
Security monitoring	Informed	Responsible nếu in-scope	Consulted	Provide telemetry theo service
Code vulnerability fix	Accountable	Validate/coordinate	Responsible	Usually not responsible
Guest OS patch trên IaaS	Accountable	Theo scope	Consulted	Infrastructure layer
WAF tuning	Approve high-impact exception	Responsible nếu in-scope	Consulted	Platform availability
Incident containment	Authority/risk decision	Responsible theo authorization	Application action	Infrastructure support

Bảng này chỉ là ví dụ. RACI hoặc responsibility matrix phải được customize theo kiến trúc và hợp đồng thật.

Những Responsibility khách hàng không nên để trống

Business owner và risk acceptance.
User/account lifecycle.
Vendor access approval.
Critical asset/data classification.
High-impact production decision.
Legal/compliance ownership.
Emergency contact và management escalation.
Third-party/vendor governance.

Ngay cả khi vận hành kỹ thuật được outsource gần như toàn bộ, các quyết định này vẫn cần owner phía doanh nghiệp.

Managed Security Provider nên làm rõ những gì?

Asset nào được monitor.
Log source nào được ingest.
Coverage giờ nào cho automation, human triage và response.
Alert nào được triage.
Remediation nào provider được phép làm.
Change nào cần approval.
Incident nào phải escalation.
Evidence/report nào được cung cấp.
Hạng mục nào out-of-scope.

Scope capability có thể chuẩn hóa bằng Managed Security Scope.

Handoff và lifecycle của responsibility

Handoff giữa Vendor phải được thiết kế trước

Nhiều incident kéo dài không phải vì kỹ thuật quá khó mà vì ticket bị chuyển qua lại. Ví dụ Managed Security xác định lỗi application, developer cần fix, hosting cần mở log và CDN phải tạo temporary rule.

Handoff nên có ticket owner duy nhất, severity, evidence, next action, deadline và closure criteria. Khi chuyển trách nhiệm, original owner vẫn nên theo dõi cho tới khi bên nhận acknowledgment.

Shared Responsibility cần được kiểm tra khi Onboarding

Onboarding nên xác nhận:

Asset, service model và vendor hiện tại.
Ai sở hữu từng account/credential.
Ai patch OS, CMS, plugin và code.
Ai vận hành WAF/CDN/origin.
Ai quản lý backup/restore.
Ai tạo và giữ log.
Ai triage/response ngoài giờ.
Ai có emergency authority.
Ai chịu trách nhiệm communication khi incident.
Out-of-scope và escalation path.

Review Responsibility Matrix khi nào?

Matrix cần review khi:

Đổi hosting/cloud/CDN.
Thêm agency hoặc Managed Security provider.
Website thêm payment/API hoặc dữ liệu nhạy cảm.
Nhân sự/key owner thay đổi.
Scope dịch vụ thay đổi.
Incident cho thấy handoff thất bại.

Responsibility drift cũng là security drift: tài liệu còn ghi owner/vendor cũ trong khi production đã thay đổi.

Những hiểu lầm thường gặp

“Dùng cloud nên provider lo security”: trách nhiệm customer vẫn tồn tại và thay đổi theo service model.
“Thuê Managed Security thì không cần owner nội bộ”: business risk và approval vẫn cần owner.
“Agency làm website phải chịu mọi incident”: agency có thể không quản lý server, DNS, WAF hoặc monitoring.
“Có WAF thì CDN provider chịu mọi attack”: rule, origin, application và account có responsibility khác nhau.
“Compliance của vendor = compliance của khách hàng”: phạm vi và nghĩa vụ không tự động chuyển giao.

Kết luận

Shared Responsibility trong Website Security không nhằm chia lỗi khi sự cố xảy ra. Mục tiêu là loại bỏ khoảng trống ownership trước khi sự cố xảy ra. Mỗi asset và capability cần có owner, authorization, evidence và handoff rõ.

Cloud, hosting, developer, CDN/WAF và Managed Security đều có thể giảm operational burden, nhưng không thay thế governance của chủ website. Cách an toàn nhất là map responsibility theo kiến trúc thật, ghi thành matrix và review lại khi hệ thống hoặc vendor thay đổi.

Nguồn tham khảo: AWS Shared Responsibility Model; Microsoft shared responsibility guidance; Google Cloud shared responsibility guidance; NIST Cybersecurity Framework 2.0.

Dịch vụ liên quan: Nếu bạn cần triển khai hoặc vận hành chuyên sâu, xem dịch vụ Managed Security.