第1章：数据库访问控制模型
大家好，我是老张。在金融数据库安全这个领域摸爬滚打了十几年，今天咱们来聊聊访问控制模型。
说白了，访问控制就是「谁可以干什么」的问题。你想想看，银行的核心系统里存着几千万客户的存款信息、交易记录，要是谁都能随便看、随便改，那不乱套了？
我刚开始做金融数据库安全那会儿，就遇到过一家城商行，因为权限没管好，内部员工把客户信息导出卖了。嗯，那事儿闹得挺大。从那以后，我对访问控制就格外上心。
核心观点：访问控制模型是数据库安全的第一道防线。选对了模型，安全就成功了一半。
1.1 自主访问控制（DAC）
DAC 是最早出现的模型。它的核心思想是：谁创建的数据，谁说了算。
举个例子，你创建了一张表，你就可以决定谁能读、谁能写。就像你买了套房，你可以决定让谁进来住。
在金融场景里，DAC 用得不多。为什么？因为太灵活了。我记得有个项目，开发人员用 DAC 给同事开了权限，结果离职后权限没回收，差点出问题。
我的建议：DAC 适合小团队、临时授权。金融核心系统慎用。
1.2 强制访问控制（MAC）
MAC 就严格多了。系统给每个主体（用户）和客体（数据）都打上安全标签。比如「绝密」「机密」「公开」。
只有标签匹配，才能访问。这就不是数据主人说了算了，是系统说了算。
我在某国有大行做过一个项目，他们的核心账务系统就用了 MAC。每个柜员只能看到自己权限级别的数据。高级柜员能看到更多，但也不能越级。
注意：MAC 配置复杂，维护成本高。我曾经见过一个团队，因为标签设置错误，导致整个部门三天无法正常查询数据。
1.3 基于角色的访问控制（RBAC）
RBAC 是目前金融行业最常用的模型。它的思路是：把权限赋给角色，再把角色赋给用户。
比如「柜员」这个角色，可以查询客户信息、办理存取款。「主管」角色，可以审批大额交易、查看日志。
你想想看，这样管理多方便。新员工入职，直接分配一个「柜员」角色就行。离职了，把角色一回收，完事。
我个人习惯用 RBAC 做权限设计。在项目中，我一般会先梳理业务角色，再定义权限。这样结构清晰，也容易审计。
实践要点：
- 角色粒度要适中。太粗了权限失控，太细了管理麻烦
- 避免角色爆炸。我见过一个系统，角色数量超过 500 个，那基本没法管
- 定期审计角色分配情况
1.4 属性基访问控制（ABAC）
ABAC 是更灵活的模型。它根据主体属性、客体属性、环境属性来动态决定是否允许访问。
举个例子：
- 主体属性：用户级别、部门、岗位
- 客体属性：数据密级、数据类别
- 环境属性：访问时间、IP 地址、设备类型
规则可以写成：「只有风控部门的高级经理，在办公时间，从内网 IP 访问，才能查看客户风险评估报告」。
我在一个互联网金融平台用过 ABAC。他们的业务变化快，RBAC 的角色定义跟不上。用 ABAC 后，权限控制灵活多了。
避坑指南：我曾经在 ABAC 的规则引擎上踩过坑。规则写得太复杂，性能就下来了。建议规则数量控制在 100 条以内，并且做好缓存。
1.5 四种模型对比
| 模型 | 核心思想 | 优点 | 缺点 | 金融适用场景 |
|---|---|---|---|---|
| DAC | 数据主人控制 | 灵活、简单 | 安全性差、审计困难 | 临时授权、开发环境 |
| MAC | 系统强制控制 | 安全性高、防泄露 | 配置复杂、维护成本高 | 核心账务、高安全等级系统 |
| RBAC | 角色控制 | 管理方便、结构清晰 | 角色可能爆炸、不够灵活 | 大部分金融业务系统 |
| ABAC | 属性动态控制 | 灵活、细粒度 | 规则复杂、性能有影响 | 风控系统、动态权限场景 |
1.6 知识体系结构图
下面这张图展示了四种访问控制模型的核心逻辑和关系：
1.7 实际项目中的选择建议
说了这么多，到底怎么选？我给大家一个参考：
- 核心账务系统：用 MAC。安全第一，配置复杂也得忍
- 一般业务系统：用 RBAC。90% 的场景都够用
- 风控、反欺诈系统：用 ABAC。业务规则变化快，需要动态控制
- 开发测试环境：用 DAC。方便灵活，反正不是生产数据
重要提醒：不管用哪种模型，一定要做好审计日志。我见过太多系统，权限模型设计得挺好，但没日志，出了事查都查不到。
好了，这一章就到这里。四种模型各有优劣，关键是根据业务场景选对。下一章咱们聊聊具体的权限管理实战，到时候我会拿真实案例来讲。