应该为每个创建的应用程序分配一个新用户吗？

Question

我得到了一个“最佳实践”的问题。我不是数据库管理员，所以我对此没有深入的了解，但我们的管理员正在推动我们构建的每个应用程序都需要创建一个新的数据库用户的过程（或者可能是每个用户“喜欢“应用程序），以便他可以识别哪个用户可能会吃掉资源。我理解这个决定背后的理论，但我想知道这是否是一种标准做法。在我看来，这将导致管理噩梦。例如，我们已经说50多个应用程序在内部运行，因此如果每个应用程序都绑定了不同的用户，则不仅难以管理，而且会看到很多这些应用程序具有重叠的权限。识别要使用哪个用户或者是否需要为每个新应用程序创建新用户变得麻烦。

对此有何看法？

感谢。

Answer 1

在一定程度上，这取决于你的意思是“应用程序”，因为这是一个非常有弹性的术语。这还取决于您是否在讨论创建新用户，然后拥有特定应用程序的所有表，或者您是否在讨论创建将用于登录数据库的新用户，但这些用户可以访问到存储在单独的（并且可能更小的）用户模式集合中的对象。

如果50岁以上的应用意味着你有50+自足集，由一般的独立代码50个分开帅哥访问的表，创建单独的用户和不同的模式为每个应用程序是非常合理的。它可以更容易地跟踪哪些应用程序使用最多的磁盘空间，哪些应用程序正在创建性能问题等。它还使得锁定每个帐户的特权相对容易，因为每个帐户只需要访问一个模式中的数据并且任何系统级权限授予都将针对特定的应用程序。另一方面，如果你有50多个应用程序碰到同一个数据库，这些应用程序可能更像是一个更大的应用程序的组件，它们最终需要共享对各种对象的访问。例如，如果您有一个应用程序让人力资源输入关于新员工，终止，辞职等的数据，另一个让经理人员输入员工评论的应用程序以及让人力资源管理组织结构图的第三个应用程序，那么很可能所有这三个应用程序都需要访问相同的基本表格集合，这可能会带来一些例外情况。如果一个用户拥有员工表，而另一个用户拥有存储组织层次结构的表，并且第三个用户拥有存储员工评论的表，则会非常恼人。在技​​术上构建这种系统是可能的，但管理同义词，权限授予和构建过程可能会很快变得难以实现，除了使不同的应用程序在不同的应用程序中放入基本相同的数据时引入数据完整性问题的可能性更大因为他们没有意识到某个其他应用程序已经拥有该实体的表。

此外，你必须要考虑的事情，如应用程序如何部署。如果您拥有50个小型Java应用程序，例如连接到单个Oracle数据库的2台应用程序服务器，则有50个独立的Oracle用户将使连接池面临挑战。即使每个连接池只有5个数据库连接，当您添加应用程序服务器或应用程序并随着用户负载增加而创建更多连接时，您仍然在讨论50 * 5 * 2 = 500个数据库连接。虽然支持数百或数千个连接到数据库当然是可能的，但这种方法也会产生各种行政头痛。

根据管理员的具体目标，可能还有更好的方法（代替或除了单独的数据库帐户之外）。例如，Oracle提供DBMS_APPLICATION_INFO软件包，应用程序可轻松使用该软件包添加工具来显示DBA数据库会话当前正在执行的操作。这可以为DBA提供更多细粒度的信息，而不仅仅是拥有单独的数据库帐户。例如，如果您有三层应用程序，那么在从连接池中取出连接以传递实际用户名时，可以很方便地调用SET_CLIENT_INFO过程，并且可以定义当前应用程序，甚至可以定义当前应用程序的哪一部分用户目前处于这个状态。然后，将这些信息放置在DBA已经查询的各种视图中，并且使DBA能够深入了解正在消耗大量资源的会话，以查看人类用户是“JustinCave “他目前在”InventoryManagement“应用程序的”QuarterlyReporting“模块中，DBA可能从经验或上下文中知道该模块是否合理地发出长时间运行但仍然重要的查询。即使您有可供查阅的应用程序日志以获取所有这些信息，使其可直接提供给DBA，也可以使故障排除更加高效，并帮助开发组和支持组之间的沟通更高效。例如，DBA可以告诉应用程序开发人员，某个特定应用程序的特定模块似乎正在创建性能问题，或询问为什么有人在月中的QuarterlyReporting模块中，而不是简单地说“InventoryManagement应用程序很慢“或者要求其他人通过应用程序日志来了解特定时间点发生了什么。

Answer 2

这是常见的做法既为您的管理员，也为你发挥你的应用程序中的读/写控制的精确水平的事实列举的原因。通过仅为您的应用程序提供他们需要的权限，可以限制潜在的安全违规。

@Rutt为每个的applcation新用户。尽管您的应用程序目前可能具有重叠权限，但不保证应用程序的权限不会改变。你正在用一种不受其他应用程序新兴需求影响的方式对每一组权限进行打包。