使用物理Postgres的用户登录系统不能与QUOT;逻辑QUOT;用户 [英] Login system using physical postgres users not "logical" users

查看:195
本文介绍了使用物理Postgres的用户登录系统不能与QUOT;逻辑QUOT;用户的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前正在建设一个与SOX审计要求,以符合应用程序。其中的一个原因是,所有的插入,更新和删除(但删除可以忽略),需要离开一个线索,是困难的,如果不是不可能的标准用户(或非DBA)来改变

I'm currently building an application that has to conform with SOX auditing requirements. One of these, is that all inserts, updates and deletes (but delete you can ignore), need to leave a trail that is difficult, if not impossible for a standard user (or non-DBA) to change.

这意味着,我需要通过在INSERT,UPDATE触发器执行在数据库级别的审核和删除。

This means, I need to enforce the auditing at the database level via triggers on insert, update and delete.

我的问题是;这是一个Web应用程序...的典型设计模式是用户存储为逻辑,例如;在用户表。我需要什么,是应用程序实际作为登录的用户在首次登录后运行。

My problem is; this is a webapp... The typical design pattern is to store users as "logical", for example; in a "users" table. What I need, is for the application to actually run as the logged in user after the initial login.

我的想法(这很可能不是最好的)是做到以下几点:

My thinking (which is likely not the best) is to do the following:


  1. 通过一个标准的用户名加载登录页面(Web应用程序)

  2. 检查一个名为stored_users表的逻辑用户名/密码。

  3. 如果他们输入正确的用户名/密码;检索数据库的用户名,生成会话密码(存储在Redis的KVSession),更新Postgres的数据库用户,并用它登录。

  4. 定义的闲置时间后,破坏了密码会议上,为用户重置密码数据库和日志出来。

这听起来像一个安全的方式,以确保以下?

Does this sound like a safe way to ensure the following?


  1. 我的用户始终使用Postgres的用户;所以我可以通过CURRENT_USER执行触发器等。

  2. 将始终用一个随机的临时密码再生postgres用户密码安全性

我很想听听别人怎么在这个问题上说的;因为我实在找不到这个在谷歌(或者我不是寻找合适的条款)。这似乎为用户登录的prevailing心态是将它们存储为逻辑记录,并有一个全球性的连接用户。

I'd really like to hear what others have to say on this matter; as I really can't find this on Google (or I'm not searching the right terms). It seems the prevailing mindset for user logins is to store them as logical records and have a global connection user.

推荐答案

要实现自己的目标。

所有的插入,更新和删除,需要留下痕迹,这是
  困难的,如果不是不可能的一个标准用户改变

all inserts, updates and deletes, need to leave a trail that is difficult, if not impossible for a standard user to change.

您可以创建:

1)两个模式:一个是普通表,一个是安全的东西,如登录/密码(哈希)表,用户会话日志,更改日志表等

1) Two schemas: one for common tables, one for security stuff like login/pass(hash) table, user session log, change log table, etc.

2)两个用户:一个普通用户,只能在公共模式(无DDL)使用DML,一是超级

2) Two users: one common user, that can only use dml on common schema (no ddl), one superuser.

3)登录功能,将检查所提供的用户名/密码对登录/密码表,记录成功/失败的尝试到用户会话日志(需要 SECURITY DEFINER 功能)

3) Login function that will check provided user/pass against login/pass table and log successful/failed attempts into user session log (you need SECURITY DEFINER function)

4)将审核触发公共架构表,将检查用户权限并记录任何更改,用户所做的( SECURITY DEFINER 的功能在这里太)。

4) Set of audit triggers on common schema tables that will check the user privileges and log any changes, made by the user (SECURITY DEFINER functions here too).

这篇关于使用物理Postgres的用户登录系统不能与QUOT;逻辑QUOT;用户的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆