网站被入侵、数据泄露、服务中断之后，最常见的问题不是技术故障本身，而是各方对“这到底该谁负责”各执一词。客户认为买了云服务就该由云厂商兜底，云厂商指出现有条款只覆盖基础设施层，建站服务商则强调自己只负责交付时的配置。

事实上，网站安全从来不是单一主体的责任，而是服务商、云厂商、客户三方按控制范围分层承担的结果。厘清责任边界的关键，不在于事后争论，而在于事前把“谁控制、谁负责、谁举证、谁兜底”四件事写进合同与运维流程。本文按层次拆解三方责任，并给出可落地的划分方法。

一、责任划分的基本逻辑：控制权决定责任

安全责任划分的第一原则是控制权原则：谁对某一层资源拥有实际配置权和管理权，谁就对该层的安全结果负主要责任。这个原则在国内外监管实践中被广泛采纳，也是司法裁判中判断过错的重要依据。

第一，控制权包括账号权限、配置变更权、日志可见性和应急操作权四项内容。任何一方只要掌握其中一项，就不能声称对该层安全“完全不知情、不负责”。

第二，责任划分必须与服务的实际形态匹配。同样是“云服务器”，用户独享的物理机与多租户共享的虚拟主机，安全责任分配差异极大，不能用一套模板套用所有场景。

第三，责任边界应当以书面形式固定。口头承诺、销售话术、宣传页面上的“安全防护”字样，在事故追责时通常不足以构成有效约定，合同附件与技术协议才是核心依据。

第四，责任划分不是免责游戏，而是为了让每一层都有人真正做事。边界清晰的直接收益是响应速度：事故发生后，各方能在分钟级确认自己的处置范围，而不是花数小时互相推诿。

需要强调的是，控制权原则并不排斥连带责任。若某次入侵的原因是云厂商未及时修补虚拟化层漏洞，同时客户长期未修改弱口令，则双方按过错程度分担责任，而不是非此即彼。

二、云厂商的责任范围：基础设施与平台层

云厂商的责任集中在“客户无法直接控制”的资源层，典型包括物理机房、网络骨干、虚拟化平台、存储介质销毁以及平台自身的安全运营。

第一，物理与环境安全由云厂商全权负责。机房门禁、视频监控、供电冗余、消防与温控、介质报废销毁等环节，客户既无权限也无能力介入，出现物理层面问题应由云厂商承担。

第二，虚拟化与平台层漏洞的修补责任在云厂商。hypervisor 逃逸、平台侧权限绕过、管理控制台自身漏洞等问题，属于客户无法触达的层面，云厂商需负责发现、修复与通知。

第三，云厂商承担基础 DDoS 清洗和平台可用性义务，但通常有明确的防护阈值和免责条款。例如部分云厂商对公网 IP 提供默认 5Gbps 以下的流量清洗，超出部分需要客户购买高防产品，未购买则不属于厂商责任范围。

第四，云厂商对客户数据的责任通常限于“不主动访问、不泄露、按约定销毁”，而不包括客户自己误删、误配置导致的暴露。客户把对象存储权限设为公开导致数据被抓取，责任在客户一侧。

第五，云厂商的通报义务常被忽视但极为关键。平台侧发生安全事件、漏洞或异常调用时，厂商应在约定时限内通知受影响客户，未及时通知造成损失扩大的，可能承担相应责任。企业在签约时应明确通报时限与通知渠道。

三、建站服务商的责任范围：应用层交付与运维

网站服务商（含建站公司、托管运维方、外包开发团队）的责任集中在应用层及其运维流程，这是安全事件最高发的区域。

第一，交付时的代码安全与配置基线属于服务商责任。SQL 注入、越权访问、上传漏洞、默认口令、目录遍历等常见问题，若源于交付代码或初始配置，服务商应承担修复与赔偿责任。

第二，合同中约定的运维范围决定责任大小。若服务包含“日常安全运维”，则补丁更新、日志巡检、备份验证、告警响应应在责任范围内；若仅为“故障重启”，则不能要求服务商对未修补的 CMS 漏洞负责。这一条最易产生纠纷，必须在合同中逐项列明。

第三，服务商的注意义务包括主动告知风险。即使合同未约定某项工作，服务商在巡检中发现客户使用已停止维护的程序版本、存在弱口令或异常登录时，应有书面告知义务，并保留告知记录。未尽告知义务而损失扩大，服务商难以完全免责。

第四，人员操作风险由服务商承担。运维人员误删数据库、误改防火墙规则、密钥保管不当导致泄露，属于服务商内部管理责任，不能转嫁给客户。

第五，服务商通常要求责任限额。多数运维合同会将赔偿上限设定为年度服务费的若干倍，客户若涉及交易、支付、大量个人信息，应单独就安全事件约定更高的赔偿额度或购买网络安全责任险。

四、客户自身的责任范围：账号、内容与使用行为

客户是网站的所有者和数据控制者，其责任无法通过采购外包彻底转移，这是最容易被误判的一点。

第一，账号与权限管理责任在客户。管理员账号借用、离职人员权限未回收、多人共用同一账号、未启用多因素认证，这些问题引发的入侵，责任在客户内部管理，服务商与云厂商均不承担。

第二，客户对自身业务配置负责。安全组开放 0.0.0.0/0 的 3389 或 22 端口、数据库直接暴露公网、对象存储设为公共读、备份与生产环境同权限，这些均属于客户可控范围内的配置，出问题由客户承担。

第三，内容与合规责任在客户。网站发布的违法违规内容、未取得授权采集的个人信息、未落实等级保护或备案要求，属于客户作为运营者的法定义务，不能以“外包给服务商”为由抗辩。

第四，客户承担业务连续性的最终责任。无论采用何种托管模式，客户都应保有可独立恢复的离线备份，并定期验证恢复流程。数据被勒索加密且备份同时被删除的案例中，责任往往落在未做异地备份的一方。

第五，客户应履行配合义务。事故调查时拒绝提供日志、拖延授权、隐瞒自建系统情况，会导致责任认定向客户倾斜，也会拖长故障恢复时间。

五、把责任边界写进合同与流程的落地方法

责任划分的价值只有在落地时才成立。以下五项动作可直接执行，成本可控且效果明确。

第一，签订分层责任矩阵附件。用一页纸列明物理层、网络层、虚拟化层、系统层、应用层、数据层六层的责任人，逐层标注“负责、配合、知情”，三方签字确认，作为主合同附件。

第二，明确四个时间指标：漏洞通报时限、应急响应到场时限、日志留存天数、数据恢复目标。建议日志留存不少于 180 天，应急响应首响不超过 30 分钟，具体数值按业务等级调整。

第三，约定举证责任与日志归属。明确事故发生时的日志提供方、提供时限与格式，并约定关键操作日志由多方各自留存，避免单一主体既当运动员又当裁判。

第四，设定责任限额与保险安排。核对云厂商与建站服务商合同中的赔偿上限，评估是否与实际风险匹配；对涉及支付或个人敏感信息的网站，配置网络安全责任险作为兜底。

第五，建立季度联合复核机制。每季度核对一次权限清单、开放端口、补丁状态和备份可用性，形成带日期的复核记录。这份记录在事后追责时，是证明己方已尽合理注意义务的最有力材料。

FAQ问答

Q1：网站被入侵，云厂商需要赔偿吗？

A：通常不需要，除非能证明入侵源于虚拟化层、平台漏洞或厂商未按约定通报。多数云服务协议将客户侧的配置、账号和代码问题排除在赔偿范围外。

Q2：建站服务商说“安全不在服务范围”，这句话有效吗？

A：部分有效，但不能完全免责。交付代码本身存在漏洞、初始配置不当仍属服务商责任；同时服务商对巡检中发现的风险负有书面告知义务。

Q3：客户把服务器交给服务商全权管理，还需要担责吗？

A：需要。账号权限授予、内容合规、业务数据合法性属于客户法定义务，不因外包而转移。全托管只是转移运维操作，不转移主体责任。

Q4：日志留存多久比较合适？

A：建议不少于 180 天，涉及交易或个人信息的关键系统可延长至 1 年。留存不足会导致事故无法溯源，在责任认定时处于不利地位。

Q5：三方都推责时，客户最应该先做什么？

A：先固定证据，包括系统日志、云平台操作记录、与服务商的沟通记录和时间线；再按合同中的责任矩阵逐层核对，避免在没有依据的情况下继续争论。

总之，网站安全责任划分的核心是控制权原则：云厂商负责基础设施与平台层，服务商负责应用交付与约定运维，客户负责账号、配置、内容与备份，三方交界处用书面责任矩阵和明确时限固定下来。建议立即做三件事：整理现有云服务与运维合同中的责任条款和赔偿上限，制作一页纸的分层责任矩阵并补齐缺失项，设定日志留存与季度复核机制。责任边界越清晰，事故响应越快，损失也越小。