一、安全世界观：为什么需要数据安全？
说实话，我入行头三年，对数据安全的理解就是“装个防火墙、设个密码”。直到有一次，我负责的系统被拖了库——用户手机号、身份证、消费记录全被挂到了暗网上。那晚我盯着告警邮件，后背全是冷汗。
从那以后我才真正明白：数据安全不是IT部门的KPI，而是业务的生死线。
1.1 为什么你躲不开数据安全？
你想想看，现在哪个系统不碰用户数据？注册要手机号、支付要银行卡、推荐算法要行为日志。数据就是新时代的石油，但石油会泄露，会着火。
我见过太多团队，前期图省事不做权限隔离，等用户量上来再补安全措施——那感觉就像给飞驰的火车换轮子。所以，安全必须从第一天就设计进去。
核心观点：数据安全不是成本，是投资。一次数据泄露的平均成本是 386 万美元（IBM 2023 年报告），而提前做好权限设计，成本可能不到这个数字的 1%。
1.2 核心三要素：CIA 三元组
聊数据安全，绕不开 CIA。不是美国那个中央情报局，是三个单词的首字母：
| 要素 | 英文 | 一句话解释 | 我踩过的坑 |
|---|---|---|---|
| 机密性 | Confidentiality | 只有该看的人能看到 | 曾经把生产库的明文密码打印在日志里，运维同学一查日志全看见了 |
| 完整性 | Integrity | 数据没被篡改过 | 有一次订单金额字段没做签名校验，被用户抓包改了价格 |
| 可用性 | Availability | 该用的时候能用上 | DDoS 攻击打过来，数据库连不上，用户下单全失败 |
这三个要素互相制约。你加密做得太狠（机密性），查询就慢了（可用性）；你为了性能放开写权限（可用性），数据就可能被改（完整性）。好的安全架构，就是在三者之间找平衡。
我的习惯：每次设计新系统，先画一个 CIA 三角，把业务对每个维度的容忍度标出来。比如支付系统，完整性排第一；推荐系统，可用性更重要。这样后面做决策就有依据了。
1.3 权限体系：CIA 落地的抓手
CIA 是理念，权限体系是落地工具。说白了，权限体系就是回答三个问题：
- 谁（用户/角色）
- 能对什么（资源/数据）
- 做什么操作（读/写/删/执行）
我刚开始做权限设计时，喜欢把权限写死在代码里——每个接口 if-else 判断用户类型。结果呢？业务一变化，改代码改到吐。后来才明白，权限必须从业务逻辑中抽离出来，做成独立的模型。
1.4 权限体系全景图
下面这张图，是我这些年做权限设计的核心框架。你把它记在心里，后面每一章都会用到。
这张图从下往上看：
- 最底层是最小权限原则——所有权限设计的底线。能不给就不给，能给读就别给写。
- 往上一层是审计，记录所有操作。出了事能追溯，合规审查能过关。
- 再往上是策略层，用 ABAC、ReBAC 或策略引擎做精细控制。
- 授权模型是核心，RBAC 最常用，DAC 和 MAC 在特定场景下用。
- 最顶层是认证，先确认你是谁，再谈权限。
我曾经犯过的错：一开始只做了认证，没做授权。结果所有认证通过的用户都能访问所有数据。测试环境没问题，上了生产才发现——普通员工能看到 CEO 的薪资条。嗯，那个月绩效没了。
1.5 权限体系的三个核心模型
刚才全景图里提到了几个模型，这里先给你一个快速对比。后面章节会逐个深入。
| 模型 | 核心思想 | 适用场景 | 复杂度 |
|---|---|---|---|
| DAC | 资源所有者自己决定谁可以访问 | 文件共享、个人网盘 | 低 |
| MAC | 系统根据安全标签强制控制 | 军事、政府机密系统 | 高 |
| RBAC | 权限赋予角色，角色赋予用户 | 企业管理系统、SaaS 平台 | 中 |
我个人最常用的是 RBAC，因为它够灵活，也够直观。但遇到复杂场景——比如“同一个文档，不同部门的人看到不同字段”——就得用 ABAC 了。这些后面都会细讲。
1.6 本章小结
这一章我们聊了三件事：
- CIA 三元组是数据安全的北极星，所有决策都要围绕它来权衡。
- 权限体系是 CIA 落地的工程手段，解决“谁对什么做什么”的问题。
- 全景图给你一个全局视角，后面每一章都会在这个框架里展开。