2.5 安全与身份管理服务

2.5 安全与身份管理服务

本节摘要：安全与身份管理服务是云上的一道"门禁系统"，四大件分别是：IAM（身份与访问管理）管"谁能进来、能干什么"，密钥管理服务（KMS）管"加密用的钥匙放哪儿"，Web 应用防火墙（WAF）挡在应用入口防攻击，安全审计记录并分析一切可疑行为。本节把这四件套放进一座建筑的安保模型里讲清职责分工，为第 4 章的系统化安全知识打前站。

本节导航

阅读完本节，你应当能够：

1. 说明 IAM 的核心职责：身份验证（Authentication）与授权（Authorization）的区别。
2. 解释密钥管理服务存在的必要性与基本用法。
3. 说出 WAF 能防哪些典型攻击（如 SQL 注入、XSS）。
4. 理解安全审计日志在"事后追责"与"事中预警"中的作用。

一、问题与直觉

假设你管理的云账号下有 50 个资源：虚拟机、数据库、存储桶。现在要允许三个同事各自管理一部分资源——研发管服务器、数据组管数据库、财务只看账单。你会怎么做？全给管理员权限？那一旦有人误操作删库，整个团队一起陪葬；逐台机器手动配权限？50 个资源配起来要命，而且离职一个同事，你还得想起来删掉他所有的权限。

这就是 IAM（Identity and Access Management，身份与访问管理）存在的理由。它把"谁"和"能干什么"拆成两个可管理的对象：先定义一堆"角色"（开发者、运维、财务），再把权限挂到角色上，最后把人分到角色里。管理权限变成了管理角色，职责清晰、好维护、可审计。

再想一步：就算权限配得再好，总有些东西要防"外面的人"。数据库的加密密钥放哪？应用入口的恶意请求怎么挡？出了事怎么回溯是谁干的？这三个问题分别由密钥管理服务、Web 应用防火墙、安全审计回答。本节就把这四件套挨个讲清。

二、核心原理

2.1 IAM：身份验证与授权

IAM 解决两个层次的问题。第一层是身份验证（Authentication）：确认"你确实是你"，手段包括用户名密码、多因素认证（MFA）、证书、临时凭证。第二层是授权（Authorization）：确认"你有权做这件事"，常用的模型是基于角色的访问控制（RBAC）——把权限集合定义成角色，再把角色分配给用户或组。

IAM 的工程要点是"最小权限"：只给完成任务所需的最小权限，不因省事而放开。很多云安全事故的根源，不是攻击者破解了什么高级漏洞，而是某个长期不用的账号带着管理员权限被盯上了。定期审查 IAM 策略、启用 MFA、禁止用根账号做日常操作，是三个几乎免费的加固动作。

2.2 密钥管理服务：保险箱的钥匙柜

数据加密了，但加密用的密钥放哪？如果密钥和密文放一起，加密等于白做；放自己手里，密钥的备份、轮换、权限控制又是一堆麻烦。密钥管理服务（KMS，Key Management Service）把"管钥匙"这件事集中化、服务化：它安全地存储密钥、按权限发放、支持定期轮换，还能记录每一次用钥匙的记录。

KMS 通常与加密功能联动：对象存储加密、数据库加密、磁盘加密都能指定用 KMS 管理的密钥。用 KMS 的收益是"加密这件事变得便宜且一致"——你不用在每台机器上手工维护密钥文件，全部统一在服务里管。

2.3 Web 应用防火墙：应用的守门员

WAF（Web Application Firewall）部署在应用入口，专门拦截面向 Web 应用的攻击，最典型的有 SQL 注入（把恶意 SQL 塞进表单参数）、跨站脚本 XSS（往页面里注入脚本盗取用户信息）、以及各种爬虫与恶意扫描。它像一个门卫，检查每一个进门的请求，发现可疑模式直接挡在外面，让攻击到不了你的应用代码。

WAF 的取舍是"误杀"：规则太严会误伤正常请求，太松又挡不住攻击。所以 WAF 通常支持"观察模式"和"拦截模式"——先观察日志调规则，再真正拦截。配置 WAF 不是"装上就完事"，而是一个持续调优的过程。

2.4 安全审计：事后能查、事中能警

安全审计记录"谁在什么时候对哪个资源做了什么操作"——创建实例、修改权限、删除存储桶，全部留下日志。它有两个价值：事后追责（出问题时回溯操作链条）和事中预警（检测异常行为，比如凌晨三点有账号在批量下载数据）。SIEM（安全信息和事件管理）系统就是干这个的：把分散的安全日志汇集起来分析。第 4.5 节会展开讲审计与合规。

三、工程实践要点

3.1 四大件对比

⚠️ 常见坑：把安全服务当"装了就行"的摆设。IAM 配了却给全员管理员、KMS 建了却不用、WAF 开了却从没看过拦截日志——这些"僵尸安全配置"比没有更危险，因为它给你虚假的安全感。

💡 关键直觉：安全服务的核心是"责任边界与最小暴露"。凡是能减的权限就减，凡是能收的口子就收。安全感不来自"装了很多安全产品"，而来自"每一层都真的在起作用"。

3.2 一道典型的攻击路径防线

一个典型的攻击场景可以串起全部四件套：攻击者扫描到一个对外暴露的 Web 接口（应该被 WAF 挡住），尝试 SQL 注入（WAF 拦截或代码层防护）；如果攻进了应用，他拿到的是普通应用账号（IAM 最小权限限制了横向移动）；他想读取数据库密文，但没有密钥（KMS 管控）；最后他的一切操作都留在审计日志里（事后可追溯）。四道防线各有作用，缺一道，攻击链就向前推进一层。这就是第 4 章"纵深防御"的具体化。

四、常见问题（FAQ）

Q1：IAM 只能管人吗？

不，IAM 还管"程序"与"机器"：应用要访问云资源，通常用一个专门的"服务角色"（Service Role）获得临时凭证，而不是把长期的访问密钥写死在代码里。这是云安全里极其重要的一条实践——代码里出现明文密钥，等于把保险柜钥匙贴在门口。

Q2：MFA 一定要开吗？

几乎建议所有账号都开。多因素认证（Multi-Factor Authentication）要求密码之外再加一个验证因素（手机验证码、硬件密钥），即使密码泄露，攻击者也过不了第二关。它是"投入产出比最高"的安全措施之一，尤其对管理员账号属于必选项。

Q3：WAF 能防 DDoS 吗？

WAF 主要防应用层攻击（SQL 注入、XSS 等），DDoS（分布式拒绝服务）是流量层面的攻击，需要专门的 DDoS 防护产品（带宽清洗、流量调度）。两者配合使用：DDoS 防护挡流量洪水，WAF 挡应用层恶意请求。第 4.4 节会讲网络边界防护。

Q4：安全审计日志要存多久？

取决于合规要求与业务需要。法规要求的（如金融、医疗）要按监管期限保存；一般业务建议至少保留一段时间以便事件回溯。日志可以转存到对象存储或专门的日志服务里，控制存储成本。存多久没有通用答案，先满足合规下限，再按"出事后要能查到多远"的预算往上加。

Q5：这些服务自己配还是用托管？

这四件套都是云平台的托管服务，开箱即用，重点在"配置"而不在"搭建"。真正的工作是：IAM 的角色策略设计、KMS 的密钥轮换策略、WAF 的规则调优、审计日志的采集范围。第 4 章会把每块的配置要点展开成独立小节，本节先建立"有哪些门禁、各守什么门"的全局观。

五、一个真实的安全事件复盘

把四件套放在一起看它们如何协作，最有效的办法是复盘一起典型事故。以下是一个在安全社区反复出现的剧本，细节做了脱敏，但流程是真实的。

事发经过：某公司一个对外提供下载服务的 Web 应用被入侵。攻击者先扫描到应用有个未鉴权的接口，接着用自动化工具尝试注入，最终通过一个没过滤的输入点拿下了应用权限。随后他在内网横向移动，发现一台数据库服务器，导出了一批用户数据。整个过程持续了几个小时，公司直到收到安全厂商的"数据疑似泄露"通知才反应过来。

对照四件套逐层复盘：如果 WAF 开了并启用了注入防护规则，第一波注入尝试就会被拦下，攻击可能在第一步就结束；如果应用使用服务角色与最小权限，攻击者拿下应用后能碰到的资源会很有限，横向移动寸步难行；如果数据库启用了 KMS 加密，导出的密文对攻击者毫无价值；如果审计日志早就配好并接入了告警，凌晨时分的异常下载行为本会触发预警。四道防线任何一道真正生效，这场事故都能被压缩成"一次被记录的攻击尝试"。

复盘的意义不是批评当事人，而是提醒：安全不是某个产品的事，而是所有防线"同时在线"才成立的系统工程。单开一个 WAF 而 IAM 全员管理员，等于装了防盗门却把所有钥匙挂在门口。第 4 章会把每一道防线展开讲，这里先用这个剧本把"四件套如何协作"印在脑子里。

六、安全服务的成本意识

安全服务同样要算账，但账要算在"风险"上。一个云账号每个月多开几项安全能力（审计日志、WAF、密钥托管），成本通常是几十到几百元级别；而一次数据泄露的损失，轻则罚款与公关危机，重则直接断送业务。用成本视角看，安全服务是云账单里"性价比"最高的一类支出——它买的是"不出事的可能性"。

但也别走向另一个极端：给每个项目都上全套企业级安全配置，成本与复杂度一样失控。正确的做法是按数据敏感度分级——核心生产数据配齐四件套，开发测试环境用最小必要的防护。安全投入应该和资产价值成正比，而不是和领导的焦虑成正比。

一节小结

• IAM：管"谁能进、能干什么"，身份验证 + 授权两件事，最小权限是铁律。
• KMS：集中管理加密密钥，支持轮换与权限控制，让加密变得一致且便宜。
• WAF：拦应用层攻击（SQL 注入、XSS），观察模式调规则后再拦截。
• 安全审计：记录操作日志，兼顾事后追责与事中预警，是合规的底座。
• 僵尸配置：装了不用的安全服务比没有更危险，每层都要真的起作用。
• 纵深防线：WAF → IAM → KMS → 审计，四道防线各拦攻击链的一环。
• 代码防泄漏：应用访问云资源用服务角色与临时凭证，绝不在代码里写死密钥。

云上的"人货场"都齐了：算力、数据、网络、数据库、安全。但一家企业上云不是"有服务可用"就结束，还得有人管——下一节先看安全后面的"大数据与分析服务"，把数据的价值榨出来。