存取控制
| 类型 | 核心逻辑 | 例子类比 | 特点 |
|---|---|---|---|
| 自主存取控制C2 | 谁创建 / 拥有，谁决定权限 | 自己的文件自己分配权限 | 灵活、权限可转授 |
| 强制存取控制B1 | 系统 / 规则强制定权限 | 公司机密文件按密级管控 | 严格、权限不能改 / 转授 |
C2重点介绍
| 对象类型 | 对象 | 操作类型 |
|---|---|---|
| 数据库和模式 | 数据库和模式 | CREATE |
| 数据库和模式 | 基本表 | CREATE TABLE, ALTER TABLE |
| 数据库和模式 | 视图 | CREATE VIEW |
| 数据库和模式 | 索引 | CREATE INDEX |
| 数据 | 基本表和视图 | SELECT, INSERT, UPDATE, DELETE, REFERENCES, ALL PRIVILEGES |
| 数据 | 属性列 | SELECT, INSERT, UPDATE, REFERENCES, ALL PRIVILEGES |
其中insert权限必须把主码放进去
发出GRANT语句的可以是数据库管理员，也可以是数据库创建者，还可以是已经有该权限的用户（WITH GRANT OPTION）,接受对象可以是一个或多个用户，也可以是PUBLIC.
1.GRANT 权限...（select）
on 对象类型 对象名...（table test）
to 用户...（user）
[with grant option](有这句可以实现权限传递)
授予用户的权限可以由数据库管理员或其他授权者用REVOKE语句收回。
2.revoke
revoke 权限...(select)
on 对象类型 对象名...（table test）
from 用户...（user）[CASCADE|RESTRICT]
数据库角色
1.创建
CREAT ROLE <角色名>
2.给角色授权
GRANT 权限...（select）
on 对象类型 对象名...（table test）
to 角色...（R1）
3.角色权限的收回
revoke 权限...(select)
on 对象类型 对象名...（table test）
from 角色...（R1）
4.把角色授权给其他的角色和用户
GRANT 角色（R1）
TO 角色（用户）
[WITH ADMIN OPTION]
用户、权限、角色关系
一、核心关系总结
权限 ↔ 角色：角色是 “权限的容器”（把多个权限打包成一个角色）；角色 ↔ 用户：用户是 “角色的使用者”（通过获取角色，间接拿到角色里的所有权限）；最终逻辑：用户 ← 继承角色 ← 包含权限，实现 “批量分配权限” 的目的。
二、分场景拆解
-
权限与角色的关系：角色是 “权限的打包工具”角色本身没有权限，需要手动把权限 “装” 进角色里，相当于把多把 “钥匙” 串成一个 “钥匙串”。比如：先创建角色 R1（相当于做了一个空钥匙串），再给 R1 授予查看 test 表的权限（把对应钥匙装进钥匙串），此时 R1 就拥有了该权限，后续把 R1 给用户即可让用户获得该权限。
-
角色与用户的关系：用户是 “角色的使用者”用户可以直接获取零散权限，但操作麻烦，更高效的方式是拿 “角色” 这个打包好的钥匙串，一次性拿到角色里的所有权限。比如：把 R1 这个 “钥匙串” 分配给用户，用户就能直接继承 R1 的所有权限，进而可以查看 test 表。
-
权限的传递 / 收回逻辑权限传递（WITH GRANT OPTION）：给用户授权时添加该选项，相当于 “允许用户把自己的钥匙再复制给别人”，用户可将自己的权限转授给其他用户。角色权限的传递（WITH ADMIN OPTION）：给用户或角色分配角色时添加该选项，相当于 “允许用户把这个钥匙串再转交给别人”，用户可将该角色转授给其他用户。权限收回（REVOKE）：收回角色的权限 → 所有持有该角色的用户，会同步失去这个权限（相当于把钥匙串里的某把钥匙拿走，所有拿这个钥匙串的人都没这把钥匙了）；收回用户的角色 → 该用户会失去这个角色包含的所有权限（相当于把钥匙串从用户手里拿走）。
三、一句话总结
权限是 “最小单位的访问许可”；角色是 “权限的打包组合”，用来简化权限管理；用户是 “权限的最终使用者”，通过获取角色来拿到对应的权限。
强制存取控制
一、先搞懂 3 个核心概念（通俗类比）
1. 主体 vs 客体：谁操作 & 操作什么
- 主体：就是 “操作数据的人 / 程序”（比如你、公司员工），简单理解为 “文件的使用者（借阅人 / 归档人）”。
- 客体：就是 “被操作的数据对象”（比如数据库里的表、记录、文件），简单理解为 “被操作的文件本身”。
- 核心关系：主体（人） ↔ 操作 ↔ 客体（文件 / 数据）
2. 敏感度标记（Label）：给 “人” 和 “文件” 贴等级标签
相当于给主体（人）和客体（文件）分别分配 “保密等级资格”，两个标签有专属名称：
- 给 主体（人） 的标签：许可证级别（Clearance Level）→ 理解为 “你的保密资质等级”（比如公司给你颁发的 “保密授权证书” 等级）。
- 给 客体（文件）的标签：密级（Classification Level）→ 理解为 “文件的保密等级”（比如文件封面上标注的保密级别）。
- 举例：
- 主体（你）的许可证级别：「秘密」
- 客体（销售报表）的密级：「普通」；客体（公司核心配方）的密级：「机密」
二、强制存取控制的 2 条核心规则（通俗解读，结合例子）
这两条规则是 “铁律”，由系统强制执行，个人无法更改（这也是 “强制” 的含义）。
规则 1：读权限（查看 / 借阅文件）—— 主体资质 ≥ 文件密级，才能读
简单说：你的保密资质必须 “够格” 或 “更高级”，才能查看这份文件，低资质的人看不到高密级文件。
- 核心逻辑：防止低权限人员获取高保密信息，避免信息泄露。
- 类比：公司规定，只有 “部门经理及以上”（高资质）才能看 “部门机密文件”（高密级），普通员工（低资质）根本看不到这份文件。
规则 2：写权限（修改 / 创建 / 归档文件）—— 主体资质 ≤ 文件密级，才能写
简单说：你的保密资质只能 “持平” 或 “更低”，才能修改 / 创建这份高密级文件，高资质的人不能往低密级文件里写入内容。
- 核心逻辑：防止高权限人员把高保密信息，泄露到低密级文件中（低密级文件能被更多人查看，避免 “高级信息降级泄露”）。
- 类比：你是持有「机密」资质的高管，不能把 “公司核心配方”（机密信息）写到 “普通销售报表”（低密级文件）里 —— 因为普通员工能看到销售报表，会导致核心配方泄露，系统会强制禁止这种操作。
三、一句话总结强制存取控制
给 “操作数据的人” 贴资质标签、给 “被操作的数据” 贴保密标签，系统强制执行两条铁律：够格才能看（主体≥客体），不越权才能写（主体≤客体），从根源上严格管控保密信息的流转。
扫一扫
到【灌水乐园】发言
