对于有使用Oracle和PHP经验的人，我有一个问题。请不要开这个毫无意义的辩论。我只想确保在我的系统中正确考虑所有内容。 我正在开发一个项目，其中有成千上万的用户，分为组和子组。每个组都有不同的访问权限，每个子组都有自己的权限。 我需要对这两种方法有你的看法：
使用一个大的实现PHP中的访问权限和特权 应用程序用户（oracle帐户），（我对这些优点一无所知 和这种方法的缺点）。
在Oracle数据库中实现访问权限和权限（每个 用户将是Oracle帐户）并使用虚拟私有 数据库，缓存，安全角色......从绩效角度来看 这是最好的方法。安全！我知道它很好但是我 害怕我错过了没有用PHP实现它的好东西。
我在网上做了一些研究但是徒劳（我抓了很多头）。我是PHP新手，但我对Oracle很了解。 任何建议，想法？
答案 0 :(得分：2)
正如你所说，你将拥有1000名用户，我认为你的软件将用于一家大公司，这可能意味着没有一个 IT部门，但其中有几个 - 一个提供托管基本硬件（操作系统级但没有应用程序），另一个管理数据库，第三个提供所有（硬件+操作系统，数据库，应用程序）并将托管应用程序作为最终用户的服务提供。我的决定可能会因为这个部门工作超过10年而受到很大影响。
我见过一个应用程序使用“每个操作系统用户一个数据库用户”的方法（Dassault Systems的VPM，Catia V4 CAD系统的附件 - 维护很恐怖。你想拥有自己的权限 ONE 的地方，而不是几个。可能你有一个很好的GUI来改变它们，但当你的用户打电话给你说“我不能做X”，你的GUI说他应该能够做X在任何地方搜索都太简单了。我们曾经遇到过这样的情况：视图没有他们应该拥有的访问角色，错误地定义了视图，用户对某些表有权限，但不是所有表都有权限。所有这些都是。
此外，我们的数据库部门目前有大约600个“数据库”，供不同部门使用。因此，他们在几个集群上运行了大约20个真正的“数据库”，并且他们已经实现了相当严格的数据库名称和相应的用户名方案。每个数据库都有一个基本名称XXX，其中XXX_A是用户名DDL语句，XXX_U是DML。应用程序可能只使用XXX_U，这也意味着应用程序可能不会执行DDL。这允许数据库管理员在集群上出现负载问题时，可以轻松地将整个模式（包括所有用户，角色和表）移动到不同集群上的不同实例，而无需了解各个数据库。当然，我们的VPM数据库不适合该模式，因此我们不得不与DB人员争论 - 而且我们每月向DB部门收取的费用远高于正常情况，因为他们管理它时会遇到更多麻烦。 / p>
结论：不要指望您可以在数据库中执行任何操作。在一家大型公司中，由一个管理数据库的部门，您将限制您的应用程序可以执行的操作以及不允许的操作。
此外，您的管理层可能会一度决定出于政治原因转移到不同的数据库系统（如DB2）。这与技术优势的关系要少于邀请谁去打高尔夫球。有时，您可能会被问及是否可以将您的系统移动到其他数据库，而您不想对其说“不”。在这种情况下，我不想依赖于过于具体的oracle功能。
还要记住，需求会随着时间的推移而变化，并且可能会有一些新的，更精细的需求。这非常有利于在软件中执行权限，因为将另一列添加到指定新内容的权限表要容易得多，而不必在数据库权限结构中实现新的内容，而这种结构并不意味着处理这种的事情。
如果您正在开发在个人用户的PC上运行的本机应用程序，则仅使用一个oracle帐户可能是一个很大的安全漏洞。但是当你使用PHP时，它只是与数据库通信的服务器，所以没有人可以从用户空间中提取登录信息。
在我看来，首先为权限管理创建一个api。不要使用oracle用户，组和角色;相反，在一些SQL表中管理您的权限。创建一个api（check_if_user_X_may_do_Y函数的集合），如果你感觉更舒服，可能在pl / sql中，如果你想要便携，可以在PHP中更好。在此API上构建应用程序。它可能在开始时更具开发性，但稍后会导致（imho）更少的管理工作。
答案 1 :(得分：0)
尽管Guntram提出了一些非常突出的观点，但他已经错过了我认为相当重要的考虑因素：
1）您描述了Oracle权限模型无法容纳的3层授权模型（尽管可以将其表示为2层模型，但代价是创建工作和复杂性）。
2）使用用户提供的凭据对数据库进行身份验证几乎排除了持久性数据库连接的使用 - 当您的连接设置时间与Oracle一样昂贵时，这一点非常重要。
一定要将组/子组/用户/权限的表示存储在数据库中，而不是Oracle用户。但是使用单个（或少量）oracle帐户进行从PHP到DBMS的访问。
如果要实现强大的安全性，那么您还应该在数据库中存储会话ID和用户（不一定是会话数据本身）之间的映射，不允许从指定的Oracle帐户直接访问数据 - 仅通过存储过程 - 并将会话ID作为身份验证令牌传递给存储过程并在那里进行验证（但请注意，如果使用简单的ORM，这将相当昂贵）。