📚 课程目录第1章课程导入与权限治理全景

1. 课程导入与权限治理全景

数据库访问控制的核心目标可以用一句话概括：让正确的主体，在正确的条件下，对正确的数据对象，执行被允许的操作，并且全过程可追溯、可审计、可回收。这句话拆开看，包含五个要素——主体（谁）、对象（访问什么）、操作（做什么）、条件（在什么约束下）、证据（如何证明合规）。任何一次数据库访问，本质上都是这五个要素的一次匹配判定。权限治理要做的，就是把这五个要素从"散落在各处的口头约定和临时授权"变成"有结构、有生命周期、有审计闭环的管理体系"。

很多团队对权限的理解停留在"给账号授个 SELECT 就行"，但真实生产环境中的问题往往出在更隐蔽的地方：离职员工的账号还挂在应用连接池里、临时排查问题开的只读账号三个月没回收、某个业务库的 PUBLIC 角色默认拥有建表权限、DBA 用超级账号直连生产导致操作无法归因到具体人。这些问题不是"授权语句写错了"，而是治理缺位。因此本课程不把访问控制当作单纯的 SQL 语法练习，而是当作一套贯穿"设计—实施—监控—回收"的治理工程。

权限治理的范畴：从认证到审计的完整链条

权限治理的范畴可以按数据访问的时间顺序划分为四个阶段，它们构成一条完整的责任链：

身份认证（Authentication）：确认"你是谁"。数据库层面包括密码策略、证书认证、LDAP/AD 集成、Kerberos 等；应用层面还包括连接池账号与真实用户的映射关系。
授权（Authorization）：确认"你能做什么"。这是访问控制模型发挥作用的地方，包括自主访问控制（DAC）、强制访问控制（MAC）、基于角色的访问控制（RBAC）、基于属性的访问控制（ABAC）等。
访问执行（Enforcement）：数据库引擎在语句解析、执行计划生成、数据读取各阶段实际拦截或放行请求，涉及权限检查时机、视图与行级安全策略（RLS）、列级权限等。
审计与回收（Audit & Revocation）：记录谁在何时访问了什么、结果如何，并据此发现越权、清理冗余权限、完成权限回收。

这四个阶段缺一不可。只做认证不做授权，等于门锁装好了但门一直开着；只做授权不做审计，等于不知道谁进过门；只做审计不做回收，等于知道问题却永远不处理。本课程后续章节会沿着这条链条逐段展开。

课程整体路线：从模型到落地的六段推进

本课程共 30 章，整体按"认知—建模—实施—加固—审计—治理"六段推进。前几章建立访问控制模型与权限体系的基础认知，包括 DAC、MAC、RBAC、ABAC 的适用边界与组合方式；中间部分进入具体数据库平台的权限实施，覆盖账号体系、角色继承、对象权限、列级与行级控制；随后进入加固与审计环节，讨论最小权限落地、权限膨胀治理、审计日志分析与越权检测；最后回到治理视角，讨论权限生命周期管理、定期复核、自动化回收与合规报告。每一章都会给出可操作的示例参数、配置片段或判断依据，而不是停留在概念介绍。

需要特别说明的是，本课程不绑定单一数据库产品。示例会以 PostgreSQL 和 MySQL 为主，因为二者在开源生态中覆盖最广，且权限模型具有代表性；同时会在关键差异处对比 Oracle、SQL Server 以及云数据库（如 RDS、PolarDB）的权限机制。读者应关注的是权限模型的设计思路与治理方法，而不是死记某个产品的语法。

实战环境搭建：一套可复现的本地实验环境

为了让后续章节的示例可以直接运行和验证，建议先搭建一套本地实验环境。推荐使用 Docker Compose 启动 PostgreSQL 16 与 MySQL 8.0 两个实例，并预置一个模拟业务库。以下是一份可直接使用的 docker-compose.yml 示例：

version: "3.9"
services:
  pg:
    image: postgres:16
    container_name: lab-pg
    environment:
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: Admin@123
      POSTGRES_DB: shopdb
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data

  mysql:
    image: mysql:8.0
    container_name: lab-mysql
    environment:
      MYSQL_ROOT_PASSWORD: Root@123
      MYSQL_DATABASE: shopdb
    ports:
      - "3306:3306"
    volumes:
      - mysqldata:/var/lib/mysql

volumes:
  pgdata:
  mysqldata:

启动后，用 docker compose up -d 拉起两个实例，再用 psql -h 127.0.0.1 -U admin -d shopdb 和 mysql -h 127.0.0.1 -u root -p 分别连接验证。建议在 shopdb 中创建三张表作为后续实验对象：customers（客户信息，含手机号、身份证号等敏感列）、orders（订单，含金额与状态）、audit_log（操作日志）。这三张表足以覆盖列级权限、行级权限、角色继承、审计追踪等绝大多数实验场景。

实验环境中的密码仅用于本地学习，切勿复制到任何真实环境。真实环境中应使用密钥管理服务或环境变量注入，并启用 TLS 连接。

一个贯穿全课程的判断示例

为了建立直观感受，先看一个后续会反复用到的判断场景。假设业务方提出需求："客服人员只能查看自己负责区域的客户手机号，且不能看到身份证号。"在传统授权模式下，这需要拆成三个动作：给客服角色授予 customers 表的 SELECT 权限、通过列级权限排除 id_card 列、通过行级安全策略限制 region 等于当前客服所属区域。如果只做了第一步，客服就能看到全部客户的全部字段——这正是权限治理中最常见的"授权过宽"问题。后续章节会分别用 PostgreSQL 的 GRANT (col) 与 CREATE POLICY、MySQL 的列级授权与视图方案来实现并验证这个需求。

权限治理的难点从来不是"能不能授"，而是"授得是否刚好、是否可查、是否可收"。带着这个判断标准进入后续学习，会比单纯记忆语法更有价值。