Oracle权限那些事儿，怎么开始管理才不乱套呢？

Oracle权限那些事儿，怎么开始管理才不乱套呢？

管理Oracle数据库的权限，感觉像收拾一个塞满各种钥匙、而且不断有新房间加入的大房子，如果一开始没个章法，很快就会乱得找不到北，要么有人进不了该进的门，要么不该进的人到处溜达，要理清头绪，你得先明白Oracle是怎么管“谁能干什么”的。

核心就三样东西：用户、权限和角色。 你可以把用户想象成具体的人，权限就是一把把能开特定门的钥匙（比如能查某张表的“SELECT钥匙”，能改数据的“UPDATE钥匙”），而角色，就是一个钥匙串，可以把一堆常用的钥匙串在一起，你可以创建一个“财务专员钥匙串”，上面串好所有能开财务相关房间的钥匙，然后直接把这一串钥匙交给财务部门的人，这比一把把单独给要省事太多了，也容易管理。（这个基础模型在Oracle官方的基础管理指南中有清晰阐述）。

要开始管而不乱，第一步千万别急着给用户一把把发单独的钥匙，很多混乱就是从直接给用户（比如USER_A）授予一大堆系统权限（如CREATE TABLE）或对象权限（比如对表EMPLOYEE的INSERT权限）开始的，人一多，权限一杂,根本记不住谁有什么。

正确的起步姿势是这样的：

1. 从角色开始规划，而不是从人开始。 先别管具体有哪些张三李四，先想想数据库里有哪几类“事”，通常会有：做数据查询的报告员、做日常数据录入的操作员、做开发建表的开发员、做核心运维的管理员，为每一类“事”创建一个角色，根据Oracle的实践建议，你可以创建像REPORT_ROLE、OPERATOR_ROLE、DEV_ROLE这样的角色。

2. 给角色串上合适的钥匙。 根据每类人的工作需要，把合适的权限授予对应的角色，给REPORT_ROLE授予对某些关键业务表的SELECT权限；给DEV_ROLE授予CREATE TABLE、CREATE VIEW这类系统权限，但通常不给能删整个表空间的危险权限，记住一个黄金原则：最小权限原则——只给完成工作所必需的最少权限，宁少勿多,不够再加。

3. 把人归类，发钥匙串。 创建具体的数据库用户，然后只需要将规划好的角色授予相应用户，张三做数据分析，就把他加入REPORT_ROLE；李四做开发，就授予DEV_ROLE，这样，张三的权限变了，你只需要调整REPORT_ROLE这个钥匙串上的钥匙，所有拿着这个钥匙串的人权限就都同步更新了,管理效率极高。

要避免的几个乱套坑：

• 滥用PUBLIC角色： Oracle有个特殊的公共角色叫PUBLIC，授予它的权限，所有用户都能拿到，就像把一把万能钥匙挂在小区大门上，谁都能拿，除非你确定某个权限（比如使用某个基础工具包的权限）真的需要给所有人，否则千万别图省事把重要权限塞给PUBLIC，很多安全漏洞和混乱都源于此（Oracle安全文档中会强烈警示对PUBLIC的授权需极其谨慎）。
• 忽视权限的传递： 在Oracle里，如果你有“WITH ADMIN OPTION”的系统权限或者“WITH GRANT OPTION”的对象权限，你就能把这权限再给别人，这就像你把钥匙给了同事，还允许他去配钥匙再发，如果不加控制，权限会像野草一样蔓延，在授予这类可传递的权限时要格外警惕,通常只给非常受信任的核心管理员。
• 从不检查和清理： 权限管理不是一劳永逸的，人员会变动，职责会调整，必须定期做两件事：一是审计，用数据字典视图（如DBA_SYS_PRIVS、DBA_TAB_PRIVS）看看现在到底有哪些权限，都给了谁，二是回收，对离职或转岗的用户,及时回收其权限或角色。

让Oracle权限不乱套的起点就是：忘掉具体的人，先分事、建角色、配好权限，然后把人放进角色里，坚持用角色管人，坚持最小授权，并且定期盘点。 一开始多花点时间设计角色体系，后面你会感谢自己这个决定的，这套方法是Oracle权限管理的最佳实践基础，能帮你搭建一个清晰、灵活且安全的管理框架。