1

我目前正在构建一个必须符合 SOX 审计要求的应用程序。其中之一是，所有插入、更新和删除（但您可以忽略删除）都需要留下难以改变的痕迹，即使不是标准用户（或非 DBA）也无法更改。

这意味着，我需要通过插入、更新和删除触发器在数据库级别执行审计。

我的问题是；这是一个webapp……典型的设计模式是将用户存储为“逻辑”，例如；在“用户”表中。我需要的是让应用程序在初始登录后以登录用户身份实际运行。

我的想法（这可能不是最好的）是执行以下操作：

  1. 通过标准用户名（webapp）加载登录页面
  2. 检查名为“stored_users”的表的逻辑用户名/密码。
  3. 如果他们输入了正确的用户/通行证；检索数据库用户名，生成会话密码（存储在 redis 上的 KVSession 中），更新 postgres 数据库上的用户并使用它登录。
  4. 在定义的不活动时间后，销毁密码会话，重置用户的数据库密码并将其注销。

这听起来像是确保以下内容的安全方法吗？

  1. 我的用户总是使用 postgres 用户；所以我可以通过 CURRENT_USER 等强制执行触发器。
  2. 通过始终使用随机临时密码重新生成 postgres 用户密码来确保安全

我真的很想听听其他人对此事的看法；因为我真的在谷歌上找不到这个（或者我没有搜索正确的术语）。用户登录的主流思维方式似乎是将它们存储为逻辑记录并拥有一个全局连接用户。

4

1 回答 1

1

为了实现你的目标

所有的插入、更新和删除都需要留下难以改变的痕迹，如果不是不可能的话，标准用户也无法更改。

您可以创建：

1) 两种模式：一种用于普通表，一种用于安全信息，例如登录/密码（哈希）表、用户会话日志、更改日志表等。

2）两个用户：一个普通用户，只能在通用模式（没有ddl）上使用dml，一个超级用户。

3）登录功能，将根据登录/通过表检查提供的用户/通行证，并将成功/失败的尝试记录到用户会话日志中（您需要SECURITY DEFINER功能）

4) 公共模式表上的一组审计触发器，它们将检查用户权限并记录用户所做的任何更改（SECURITY DEFINER这里也有函数）。

于 2013-07-12T08:06:50.197 回答