1. PaaS安全概述：模型、责任与威胁

大家好，我是你们这堂课的讲师。咱们直接进入正题。

PaaS，平台即服务。说白了，就是云厂商给你搭好了一个“舞台”，你只管在上面“唱戏”。这个舞台有操作系统、有中间件、有数据库运行时。你只需要把你的代码和配置丢上去就行。

听起来很爽，对吧？但安全这件事，从来就没有“甩手掌柜”一说。

1.1 PaaS模型定义：到底什么是PaaS？

我个人习惯把云计算服务分成三层：IaaS、PaaS、SaaS。PaaS正好卡在中间。

• IaaS：给你一台虚拟机，从OS开始你自己折腾。
• PaaS：给你一个运行时环境，你只管写代码。
• SaaS：给你一个应用，你直接用。

举个例子。你用阿里云的RDS，那就是PaaS。你不用管MySQL怎么安装、怎么打补丁。你只需要建表、写SQL。但如果你自己在一台ECS上装MySQL，那就是IaaS玩法。

嗯，这里要注意：PaaS不是“万能药”。它帮你省了运维的力，但也限制了你的控制权。

1.2 共享责任模型解析：谁该为安全负责？

这是PaaS安全里最绕不开的话题。我见过太多团队，一出事就互相甩锅。

云厂商说：“底层我加固了，是你代码有漏洞。” 开发说：“我代码没问题，是你平台配置不对。”

其实，AWS、Azure、阿里云都有明确的文档。我建议你直接去翻一遍。核心原则就一句话：云厂商负责“云的安全”，你负责“云里的安全”。

责任层级	云厂商负责	用户负责
物理安全	数据中心、网络、硬件	无
虚拟化层	Hypervisor、虚拟网络	无
运行时环境	OS补丁、中间件版本	运行时配置、依赖库版本
应用层	无	代码安全、身份认证、数据加密
数据层	存储基础设施	数据分类、访问控制、加密密钥

1.3 PaaS安全挑战：你可能会遇到哪些坑？

说实话，PaaS的安全挑战，比IaaS更隐蔽。为什么？因为你看不到底层。你没法自己装WAF，没法自己改内核参数。

我总结了几类最常见的挑战：

1. 配置错误：这是头号杀手。比如存储桶权限设为公开，比如数据库白名单设为0.0.0.0/0。你想想看，一个配置项，就能让整个数据库裸奔。
2. 依赖供应链风险：PaaS环境里，你用的中间件、SDK、第三方库，都是厂商提供的。如果厂商的某个组件有漏洞，你只能等补丁。我遇到过Spring4Shell爆发时，整个团队通宵升级版本。
3. 身份与访问管理（IAM）混乱：PaaS里的服务间调用，经常用AK/SK或者临时凭证。一旦泄露，攻击者就能以你的身份调用所有API。
4. 数据泄露与合规：数据在PaaS平台里流转，日志、缓存、数据库，每一层都可能泄露。GDPR、等保2.0，这些合规要求，你都得满足。

1.4 威胁建模：怎么系统地找漏洞？

威胁建模，说白了就是“假设自己是个坏蛋，想想怎么搞破坏”。

我个人比较喜欢用STRIDE模型。它把威胁分成六类：

• Spoofing（假冒）：攻击者冒充合法用户或服务。
• Tampering（篡改）：数据在传输或存储中被修改。
• Repudiation（抵赖）：用户做了操作却不承认。
• Information Disclosure（信息泄露）：敏感数据被不该看的人看到。
• Denial of Service（拒绝服务）：让服务不可用。
• Elevation of Privilege（权限提升）：普通用户拿到管理员权限。

举个例子。你在PaaS上部署了一个Web应用。用STRIDE过一遍：

• 假冒：登录接口有没有暴力破解防护？
• 篡改：API请求参数有没有做完整性校验？
• 抵赖：操作日志有没有存到不可篡改的存储里？
• 信息泄露：数据库里的密码是不是明文存的？
• 拒绝服务：有没有限流和熔断机制？
• 权限提升：普通用户能不能调用管理员接口？

嗯，这样一梳理，漏洞就清晰了。我每次做新项目，都会拉上开发和运维，花半天时间过一遍STRIDE。效果比事后救火好得多。

好，这一章就到这里。下一章，咱们聊聊PaaS平台的身份认证与访问控制。那才是真正的硬骨头。