Oracle安全 - 如何防止用户从DROP TABLE自己的表中删除

问题描述:

作为安全性收紧练习,我将从Oracle数据库用户中删除所有系统权限。现在,这个用户只具有以下系统权限:Oracle安全 - 如何防止用户从DROP TABLE自己的表中删除

  • 创建会话
  • UNLIMITED TABLESPACE

我希望用户将无法做任何DDL命令。但令我惊讶的是,即使用户不能创建DROP TABLE,用户也可以在自己的模式下使用DROP TABLE。

Oracle documentation表示DROP TABLE的先决条件是“该表必须位于您自己的模式中,或者您必须具有DROP ANY TABLE系统特权”。只是!!!我不明白Oracle的安全逻辑,但有什么办法可以阻止用户删除自己的表?

另一种方法是创建另一个用户来运行应用程序和授予对象访问权限,我想避免这种情况,因为存在潜在的问题。

+2

你确实意识到无限制的TABLESPACE并不是一件好事情来授予用户吗?因为它授予任何表空间的权限,包括SYSTEM和SYSAUX之类的应用程序不应该使用的权限。如果你要锁定的东西,你应该明确地向用户授予* named tablespace *的配额。 – APC 2012-01-12 17:36:59

+0

感谢您的建议APC。是的,UNLIMITED TABLESPACE对于生产系统来说不是最好的特权。但是所有的数据库用户都被授予了RESOURCE角色(Oracle默默授予UNLIMITED TABLESPACE而不告诉你)。现在我删除了RESOURCE角色,我必须授予此特权以用于临时目的。但稍后会进一步提供拨款额度。 – Tyn 2012-01-13 11:07:09

用户将始终有权删除他们拥有的对象。您无法通过撤消权限来防止这种情况。

由于您正在考虑加强安全性,因此创建新用户并授予该用户所需的任何权限来操作数据都是正确答案。唯一应该以拥有应用程序对象的用户身份登录到生产数据库的人员是DBA,并且只有当他们正在部署对模式的更改时才会这样做。其他人都应该以架构所有者以外的用户身份登录到数据库。这就是说,如果正确的解决方案比你现在准备进行的工作多,那么一个潜在的权宜之计就是在数据库上创建一个DDL触发器,如果​​针对对象发出了DROP在指定的模式中。这比适当的解决方案更安全。实施触发器时,您可能会错过某些东西,您或其他人可能会放弃或禁用触发器并忘记重新启用触发器等等。由于您拥有的定制解决方案不会执行,因此安全性报告会变得更加困难在各种与安全相关的数据字典视图中显而易见,这可能会给审计人员带来问题。

+4

+1基本架构所有者不应该能够连接到生产数据库。 – APC 2012-01-12 17:38:33

+1

如果您有大量SQL查询当前未指定模式名称,则可以通过为新用户为旧模式中的所有对象创建同义词来实现这一点,而这些同义词是他们需要的。这样就不需要改变查询。 – ivanatpr 2012-01-12 18:30:08

+0

除非@invantpr考虑到创建和维护同义词负载的麻烦。 – Ben 2012-01-12 18:41:48