Login system using physical postgres users not “lo

问题:

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.

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

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. Load the login page via a standard username (webapp)
2. Check a table called "stored_users" for their logical username/password.
3. If they enter the correct user/pass; retrieve the db username, generate a session password (stored in KVSession on redis), update the user on the postgres DB and login with it.
4. After a defined time of inactivity, destroy the password session, reset the db password for the user and log them out.

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

1. My users are always using postgres users; so I can enforce the triggers via CURRENT_USER etc..
2. Security by always regenerating the postgres user password with a random, temporary password

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.

回答1:

To achieve your goal

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

you can create:

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

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

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) 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).