1. 安全基础概念：CIA三元组、威胁模型与策略制定
各位同学，咱们今天聊点实在的。系统安全这事儿，说白了就是一场攻防博弈。你不需要成为黑客，但得知道黑客在想什么。我做了十几年运维，见过太多“我以为很安全”的系统，结果被人从最意想不到的地方捅了篓子。
这一章，咱们把地基打牢。先搞懂安全领域最核心的三个词——机密性、完整性、可用性。然后看看威胁从哪来，最后聊聊怎么定规矩。
1.1 CIA三元组：安全的三个支点
CIA不是美国中央情报局，是 Confidentiality（机密性）、Integrity（完整性）、Availability（可用性）。这三个词，是所有安全工作的出发点。你做的任何安全配置，最终都能归到这三条里。
| 属性 | 核心含义 | 一句话人话 | 我踩过的坑 |
|---|---|---|---|
| 机密性 | 数据只能被授权的人看到 | 不该看的别看 | 某次数据库权限没回收，实习生看到了全公司工资单 |
| 完整性 | 数据在传输和存储中不被篡改 | 数据是原装的 | 日志被删了，查了半天才发现是写权限没控制好 |
| 可用性 | 系统在需要时能正常服务 | 别宕机 | DDoS打过来，业务挂了3小时，备份没切过来 |
核心原则：这三个属性是互相制衡的。你加密做得太狠（机密性），解密慢，可用性就下降。你为了高可用搞多副本，数据一致性（完整性）又可能出问题。做安全，就是在这三个角里找平衡。
1.1.1 机密性：谁该看，谁不该看
机密性，说白了就是权限控制。谁有资格读这份文件？谁能看到这个数据库字段？
我习惯用 最小权限原则——只给一个人完成工作所必需的最小权限。举个例子，一个前端开发，他需要读API文档，但不需要看生产环境的数据库密码。那就只给他文档库的只读权限。
我的经验：权限不是越收越紧就好。收得太死，员工会想办法绕过你——比如把密码写在便签纸上贴在显示器上。嗯，我亲眼见过。
实现机密性的常见手段：
- 加密：传输层用TLS，存储层用AES-256
- 访问控制：RBAC（基于角色的权限控制）、ACL（访问控制列表）
- 数据脱敏：日志里把身份证号中间几位打星号
1.1.2 完整性：数据没被人动过手脚
完整性保证的是：数据从A传到B，中间没被人改过。你想想看，如果银行转账记录能被篡改，那还得了？
我曾经遇到过一个案例：某系统的日志文件被攻击者删除了关键条目，导致我们花了三天才还原攻击路径。从那以后，我强制所有日志服务器启用 写一次读多次（WORM） 策略，日志一旦写入就不能再改。
保证完整性的常用技术：
- 哈希校验：SHA-256，下载文件后比对哈希值
- 数字签名：用私钥签名，公钥验证
- 审计日志：记录谁在什么时候改了什么
1.1.3 可用性：关键时刻别掉链子
可用性最容易被忽视。很多公司把精力都放在防泄露上，结果DDoS一来，网站直接打不开。你数据再安全，用户访问不了，有什么用？
我记得有一次，某电商平台大促前夜，数据库主库挂了。因为没做读写分离，整个站直接瘫痪。那晚我陪着运维团队熬到凌晨四点，才把从库切上来。教训就是：高可用不是锦上添花，是命根子。
提升可用性的手段：
- 冗余部署：多活、主备、异地容灾
- 负载均衡：Nginx、F5、云上的SLB
- 限流降级：扛不住的时候，先保核心业务
1.2 安全威胁模型：你的对手是谁
搞安全，不能闭门造车。你得知道谁会来打你，用什么方式打。这就是威胁模型的作用。
我常用的一个框架是 STRIDE，微软提出的威胁分类法。它把威胁分成六类：
| 威胁类型 | 英文 | 针对的CIA属性 | 举个栗子 |
|---|---|---|---|
| 假冒 | Spoofing | 机密性 | 伪造登录页面，骗用户输入密码 |
| 篡改 | Tampering | 完整性 | 中间人攻击，修改HTTP响应内容 |
| 抵赖 | Repudiation | 完整性 | 用户说“我没下过这个订单”，但你没日志可查 |
| 信息泄露 | Information Disclosure | 机密性 | SQL注入，把用户表拖出来 |
| 拒绝服务 | Denial of Service | 可用性 | DDoS，把带宽打满 |
| 权限提升 | Elevation of Privilege | 机密性+完整性 | 普通用户通过漏洞拿到root权限 |
注意：威胁模型不是做一次就完事了。系统在变，攻击手法也在变。我建议每半年重新做一次威胁建模，特别是大版本上线前。
除了STRIDE，还有一个更简单的模型叫 攻击树。你把攻击者的最终目标画在树根，然后往上分叉，列出所有可能的攻击路径。比如“拿到数据库权限”这个目标，可以分叉成“SQL注入”、“弱密码爆破”、“内部人员泄露”等。每个叶子节点就是一个防御点。
1.3 安全策略制定原则：规矩怎么定
有了CIA三元组做理论，有了威胁模型做分析，接下来就是定规矩了。安全策略不是写一堆没人看的文档，而是可执行、可审计的规则。
我总结了几条原则，都是血泪换来的：
- 最小权限原则：前面说过了，权限只给到够用为止。别图省事给个“管理员”角色完事。
- 纵深防御：别指望一道墙挡住所有人。网络层、应用层、数据层，每层都设防。攻击者突破一层，还有下一层等着他。
- 默认拒绝：没明确允许的，一律禁止。防火墙规则、文件权限、API访问，都按这个来。
- 可审计性：所有操作都要有日志。谁、什么时间、做了什么、结果如何。出了事能追溯。
- 最小暴露面：不必要的端口关掉，不必要的服务停掉，不必要的接口删掉。你暴露得越少，攻击面越小。
我的习惯：每次新系统上线前，我都会问三个问题：1）这个服务必须对外暴露吗？2）这个端口能不能只对内网开放？3）这个接口有没有做鉴权？三个问题答完，至少能砍掉一半的攻击面。
1.4 知识结构图：CIA与威胁模型的关系
下面这张图，把CIA三元组、STRIDE威胁模型和防御策略串在了一起。你仔细看，每个威胁类型都对应着CIA的一个或两个属性，而防御策略就是针对这些威胁的。
1.5 避坑指南：新手最容易犯的三个错
最后，分享几个我亲眼见过的翻车现场。你记住了，能少走半年弯路。
坑一：只防外部，不防内部。 我见过一家公司，防火墙做得固若金汤，但内部员工可以随便访问所有人的邮件。结果离职员工把客户名单带走了。记住：内鬼比外贼更难防。
坑二：安全策略写得太复杂。 有一份安全文档写了200页，没人看，也没人执行。我建议：策略文档别超过10页，剩下的用自动化工具落地。
坑三：忘了备份的可用性。 很多公司天天做备份，但从没演练过恢复。真出事了才发现备份文件是坏的。我的习惯是：每季度做一次恢复演练，确保备份真的能用。
好了，这一章的内容就到这儿。CIA三元组是安全的地基，威胁模型是地图，策略是施工规范。这三样东西搞明白了，后面的权限配置、加密通信、日志审计，你学起来会轻松很多。