文章总结： 本文解析IaaS、PaaS和SaaS三种云服务模型对应急响应深度与取证能力的决定性影响，阐述共享责任模型下云厂商与客户的安全边界。文章指出客户需在责任范围内关注配置、应用及账号安全，并建议依据合同与SLA明确责任划分，确保云安全事故处置高效顺畅。 综合评分： 85 文章分类： 应急响应,云安全,安全建设

---

应急响应 | 云上应急响应理论基础（下）

Zgao Zgao

篝火信安

2026年3月12日 10:30 北京

在应急响应和取证工作中，我们越来越频繁地面对一个现实：大量关键业务和数据已经不在传统机房，而是在云上运行。理解云计算的基本概念，已经不再是架构师或运维工程师的专属能力，而是每一位安全响应人员的必备基础。

本篇为应急响应 | 云上应急响应理论基础（上）的续篇。

三、云服务模型：决定能在应急响应中能做到哪一步

在云环境中，应急响应和取证能力并不是“想做就能做”的，它从一开始就被云服务模型所限定。

IaaS、PaaS 和 SaaS，不只是技术架构的区别，更是安全责任、取证边界和响应深度的分水岭。

理解云服务模型，是每一位云安全工程师和应急响应人员的必修课。

1、IaaS：最接近传统取证思维的云模式

基础设施即服务（IaaS）是云计算中最底层、也是最灵活的一种服务模式。

在 IaaS 下，云厂商向用户提供虚拟化后的计算资源，包括服务器、存储、网络以及操作系统。

从应急响应的角度来看，IaaS 的最大特点是：仍然可以掌控从操作系统到应用层的大部分环境。

这意味着在发生安全事件时，仍然可以进行很多“传统取证操作”，例如：

• 操作系统配置检查
• 系统和应用日志分析
• 进程与服务排查
• 磁盘与内存层面的调查（在条件允许的情况下）

IaaS 的弹性也是它的重要优势。企业可以根据业务需求快速扩容或缩容资源，比如在业务高峰期临时增加算力，在需求下降后及时回收资源。这种能力在应急响应中也很重要，例如快速隔离受影响实例、拉起新的干净环境进行替换。

但需要注意的是，IaaS 并不意味着安全责任转移。

在这个模型下，网络配置、操作系统加固、应用安全、补丁管理，基本都由客户负责。一旦出现配置错误，比如安全组开放过大、管理端口暴露公网，攻击往往来得非常快。

IaaS 的优势在于可控性强，但前提是：安全运维和审计能力必须跟得上。

2、PaaS：开发效率提升，但取证深度明显下降

平台即服务（PaaS）的核心目标是让开发人员“少操心基础设施，多关注业务逻辑”。

云厂商负责运行环境、系统平台和底层资源，用户只需要专注于应用开发、部署和配置。

对于应急响应人员来说，PaaS 带来的变化非常明显：已经无法直接接触操作系统和底层运行环境。

在安全事件发生时，可调查的重点通常集中在：

• 应用日志
• 平台提供的运行状态信息
• 应用配置与权限
• 身份认证和访问控制记录

PaaS 非常适合快速开发、测试和迭代，但也引入了新的风险。例如：

• 对平台特性的过度依赖，导致供应商锁定
• 应用配置错误引发的数据泄露
• 应用层漏洞被直接利用

在 PaaS 模式下，应用安全几乎完全由客户负责。

如果应用本身存在逻辑漏洞或权限设计缺陷，即使底层平台再安全，也无法避免被攻击。

从应急响应角度看，PaaS 的调查能力介于 IaaS 和 SaaS 之间，但已经无法进行主机级取证，需要更多依赖日志和平台能力。

3、SaaS：最省心，也是最难调查的模式

软件即服务（SaaS）是最上层、也是最常见的云服务模式。

用户通过浏览器直接使用应用，无需关心系统部署、升级或维护。

典型的 SaaS 应用包括：邮件系统、办公套件、CRM、协作平台等。

在应急响应中，SaaS 的现实是：几乎无法触及任何底层系统，只能使用厂商提供的接口和日志能力。

一旦发生安全事件，可用的调查手段通常只剩下：

• 登录日志
• 用户操作记录
• 权限变更记录
• 审计日志或 API 输出

SaaS 的优点是使用门槛低、运维成本小，但风险同样明显：

• 一旦账号被攻破，影响范围可能非常大
• 对云厂商安全能力高度依赖
• 网络中断或厂商故障会直接影响业务

在 SaaS 模式下，客户仍然需要对账号安全和访问控制负责。

弱口令、多因素认证缺失、权限滥用，往往是 SaaS 安全事件的直接原因。

4、不同云模型下的安全风险与应急关注点

从应急响应的角度，不同云服务模型关注的重点完全不同：

在IaaS模式中，最常见的问题包括：

• 网络和系统配置错误
• 身份与访问控制管理不当
• 系统和应用漏洞未及时修复
• 数据未正确加密

在PaaS 模式中，风险更多集中在：

• 应用配置错误
• 身份认证和授权设计不合理
• 应用层漏洞
• 多租户环境带来的隔离风险

在SaaS模式中，重点则变成：

• 账号滥用与权限失控
• 数据泄露
• 合规与隐私问题
• 对厂商安全能力的依赖

需要明确的是：云安全从来不是“全交给厂商”的问题，而是责任边界的问题。

四、共享责任模型：云安全事故中最容易被误解的真相

在云环境中，很多安全事故并不是因为“攻击手法多高明”，而是因为责任边界不清。共享责任模型（Shared Responsibility Model），正是用来回答一个最关键的问题：

云上的安全，到底谁负责？

1、什么是共享责任模型

共享责任模型定义了在云计算环境中，云服务提供商与客户之间如何分担安全与合规责任。

它明确指出：哪些安全任务由云厂商负责，哪些必须由客户自己承担。

很多企业在上云初期都会产生一个误区——“上了云，安全是不是就交给云厂商了？”

答案是：不完全是，甚至在很多关键环节并不是。

2、云厂商负责的是什么

在绝大多数云服务场景下，云服务提供商主要负责的是云的安全（Security of the Cloud），包括：

• 数据中心的物理安全

• 服务器硬件的维护与防护

• 底层网络基础设施

• 存储系统的可用性与可靠性

• 虚拟化层的隔离

• 服务整体的高可用性与抗故障能力

从应急响应角度来看，这意味着：几乎不需要，也无法介入这些层面的调查和处置。

如果这些层面出现问题，通常只能由云厂商介入处理。

3、客户真正要负责的部分

而客户需要负责的，是云中的安全（Security in the Cloud）。 这些往往也是安全事件最容易发生的地方：

• 用户身份认证与访问控制
• 网络配置（安全组、ACL、防火墙等）
• 应用安全与配置
• 数据加密与数据保护
• 日志监控与告警
• 安全事件的响应与处置

换句话说： 攻击者真正能利用的，大多数恰恰是客户负责的那一部分。

4、不同云服务模型下，责任并不一样

共享责任模型并不是一成不变的，它会随着云服务模型（IaaS、PaaS、SaaS）的不同而发生变化。

在IaaS模式下，客户的责任范围最大； 在PaaS模式下，客户的责任范围居中；

在SaaS模式下，客户的责任范围最小，但并不为零。

这也是为什么理解云服务模型和共享责任模型，必须放在一起看。

5、IaaS 模式下的共享责任

在 IaaS 模式中，责任划分相对清晰，也最接近传统数据中心的安全模式。

云厂商负责的部分包括：

• 物理服务器的安全与运维
• 数据中心的电力、制冷与环境保障
• 存储与网络基础设施
• 虚拟化层的隔离与稳定性

客户需要负责的部分包括：

• 操作系统的安装、加固与更新
• 应用程序的安全与配置
• 数据加密、备份与保护
• 虚拟网络的设计与访问控制
• 身份与权限管理
• 安全监控与事件响应

从应急响应视角来看，IaaS 提供了最大的调查自由度，也带来了最大的安全责任。 配置错误、补丁缺失、权限滥用，几乎都是在这一层面被攻击者利用。

6、PaaS 模式下的共享责任

在 PaaS 模式中，云厂商接管了更多底层组件，客户的关注点开始上移。

云厂商负责的部分包括：

• 物理服务器与存储
• 网络基础设施
• 虚拟化层
• 操作系统的安装与维护
• 平台级网络服务（负载均衡、DNS、VPN 等）
• 应用运行环境与平台服务

客户需要负责的部分包括：

• 应用程序本身的安全
• 应用配置与权限设计
• 应用数据的保护与加密
• 身份认证与授权
• 安全监控与事件响应

在 PaaS 模式下，应急响应人员通常无法进行主机层面的取证，调查重点会集中在应用日志、访问记录和平台提供的审计能力上。

7、SaaS 模式下的共享责任

SaaS 是责任最“集中”在云厂商一侧的模型，但这并不意味着客户可以完全放手。

云厂商负责的部分包括：

• 数据中心与硬件安全
• 网络基础设施
• 虚拟化与操作系统
• 应用本身的维护、更新与安全
• 应用数据的加密与备份

客户需要负责的部分包括：

• 用户账号管理
• 身份认证与权限分配
• 数据的正确使用与管理
• 安全事件的发现与上报

在实际安全事件中，SaaS 的高发问题往往是：

• 账号被盗
• 权限配置不当
• 内部人员误操作
• 第三方集成带来的风险

即使在 SaaS 模式下，账号安全和访问控制依然是客户无法推卸的责任。

五、合同、SLA 与责任边界

在真实的应急响应场景中，合同和 SLA 往往比技术文档更重要。

云厂商的安全策略、服务条款和责任范围，可能会随着服务升级而变化。

如果在合同中没有明确责任划分，一旦发生安全事件，很容易陷入“谁该负责”的拉扯中，直接影响响应效率。

共享责任模型的核心价值，不在于理论，而在于实战：

• 它决定了能不能查、查到哪一层
• 它决定了该不该自己处置，还是必须找云厂商
• 它决定了事故发生后，责任是否清晰、响应是否顺畅

很多云安全事故的教训只有一句话：

你以为云厂商在负责，其实那一层一直是你自己的责任。

如果您觉得内容还不错的话，请关注我吧！

建议把公众号“篝火信安”设为星标，否则可能就看不到啦！因为公众号现在只对常读和星标的公众号才能展示大图推送。

操作方法：点击公众号页面右上角的【…】，然后点击【设为星标】即可。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：篝火信安 Zgao Zgao《应急响应 | 云上应急响应理论基础（下）》