网络安全技术和实践第8章-(2)数据库安全.ppt

例3：把对表SC的查询权限授予所有用户 GRANT SELECT ON TABLE SC TO PUBLIC; 例4：把查询Student表和修改学生学号的权限授给用户U4　 GRANT UPDATE(Sno), SELECT ON TABLE Student TO U4; 注意： WITH GRANT OPTION子句: 若指定：可以再授予，即权限可传递。 没有指定：不能传递。 特别注意：不能循环授权 例5：把对表SC的INSERT权限授予U5用户，并允许他再将此权限授予其他用户 GRANT INSERT ON TABLE SC TO U5 WITH GRANT OPTION; 执行例5后，U5不仅拥有了对表SC的INSERT权限，还可以传播此权限。 例6：GRANT INSERT ON TABLE SC TO U6 WITH GRANT OPTION; 同样，U6还可以将此权限授予U7： 例7：GRANT INSERT ON TABLE SC TO U7; 注意：U7不能再往下传递权限了。 （2）收回权限 基本语法： REVOKE：授予的权限可以由DBA或其他授权者用REVOKE语句收回 REVOKE 权限[,权限]... [ON 对象类型 对象名] FROM 用户[,用户]...; —— 所有授予出去的权力在必要时又都可用REVOKE语句收回 例8：把用户U4修改学生学号的权限收回 REVOKE UPDATE(Sno) ON TABLE Student FROM U4; 例9：收回所有用户对表SC的查询权限 REVOKE SELECT ON TABLE SC FROM PUBLIC; 例10：把用户U5对SC表的INSERT权限收回 REVOKE INSERT ON TABLE SC FROM U5 CASCADE ; 将U5的INSERT权限收回时必须级联（CASCADE）收回 系统只收回直接或间接从U5处获得的权限 U5 → U6 → U7 灵活多样的数据库角色管理 授权机制易于个体控制，但操作繁琐，修改、更新、维护量大 借助传统的用户组思想，构建角色管理体系 什么是数据库角色？ —— 简单滴说，就是被命名的一组与数据库操作相关的权限,是一组权限的有机集合。 创建角色 给角色授权 将角色授予其他的角色或用户 角色权限的回收 创建角色： CREATE ROLE 角色名 或：sp_addrole [ @rolename = ] role???? [ , [ @ownername = ] owner ] 例： CREATE ROLE R1； 或： sp_addrole R1； 注意：此时新创建的角色是空的，没有任何内容。 给角色授权 GRANT 权限[, 权限]… ON 对象类型 对象名 TO 角色 [,角色 ]… 例：GRANT SELECT,UPDATE,INSERT ON TABLE STUDENT TO R1; 收回角色权限： REVOKE 权限[, 权限]… ON 对象类型 对象名 FROM 角色1[,角色2]… 例： REVOKE SELECT ON TABLE Student FROM R1 自主存取控制的缺陷 可能存在数据的“无意泄露” 原因：这种机制仅仅通过对数据的存取权限来进行安全控制， 而数据本身并无安全性标记 解决：对系统控制下的所有主客体实施强制存取控制策略 强制存取控制 保证更高程度的安全性 用户不能直接感知或控制 适用于对数据有严格而固定密级分类的部门 军事部门 政府部门 银行系统 主体 —— 系统中的活动实体 数据库系统所管理的实际用户 代表用户的各进程 客体 —— 系统中的被动实体 文件 基表 索引 视图 敏感度标记（Label）。例如： 绝密（Top Secret，TS） 机密（Secret，S） 可信（Confidential，C） 公开（Public，P） 主体的敏感度标记称为许可证级别（Clearance Level） 客体的敏感度标记称为密级（Classification Level） 基本规则 仅当主体的许可证级别大于或等于客体的密级时，该主体才能读取相应的客体 仅当主体的许可证级别等于客体的密级时，该主体才能写相应的客体 修正规则（慎用） 主体的许可证级别 = 客