3

我正在编写一个带有 postgresql 9.2 数据库后端的 C++ 应用程序。是一款会计软件。它是一个具有权限分离功能的多用户应用程序。

我需要帮助来实施用户帐户系统。用户的权限不必相互排斥。我应该在应用程序级别还是在数据库级别实现它？

公司目前不是很大。假设大约有 15-20 个办公室，每个办公室平均有 10 个程序用户。

  • 我可以利用 postgres 中的角色来实现这个吗？它会变得过于乏味、难以管理，还是这种方法存在一些缺陷？
  • 如果我通过应用程序路由，我如何存储用户拥有的权限集？二进制字符串就足够了吗？如果以后有额外的权限，我该如何合并它们？我需要做些什么来确保没有安全问题？在这种方法中，我假设应用程序连接到最高特权用户所需的特权。
  • 这两种方法的某种组合？还是完全不同的东西？

欢迎所有建议和争论。

4

1 回答 1

1

切勿从在不受控制的环境中运行的客户端应用程序提供授权。用户可以物理访问的每台设备都是一个不受控制的环境。这是通过默默无闻的安全性——用户可以简单地使用调试器从客户端程序内存中获取数据库访问凭据，然后psql用来做任何事情。

使用角色。

当我开发 C++/PostgreSQL 桌面应用程序时，我选择禁止所有用户访问修改所有表，并且我使用带有VOLATILE SECURITY DEFINER选项的 Pl/PgSQL 函数创建了一个 API。但我认为这不是最好的方法，因为它不自然且容易出错，例如：

select add_person(?,?,?,?,?,?,?,?,?,?,?,?);

我认为更好的方法是允许修改用户需要修改的表，并在需要时使用 BEFORE 触发器强制授权，这会在 current_user 不属于适当的角色时引发错误。

但请记住set search_path=...在所有与安全有关的功能中使用选项。

如果您想授权对某些表进行只读访问，那么它会变得更加复杂。您需要禁用这些表的选择权限并使用安全定义器函数创建 API 以访问所有数据。这将是一个怪物大小的 API，极其丑陋且极其脆弱。或者您需要禁用这些表的选择权限并使用create view with (security_barrier). 也不好看。

于 2013-04-17T22:14:42.000 回答