> On Feb 17, 2015, at 3:40 AM, Yeb Havinga <yebhavi...@gmail.com> wrote:
> 
> Hi list,
> 
. . . . . 

> Auditing superuser access means auditing beyond the running database.
> The superuser can dump a table, and pipe this data everywhere outside of
> the auditing domain. I cannot begin to imagine the kind of security
> restrictions you'd need to audit what happens with data after libpq has
> produced the results. My best guess would be to incorporate some kind of
> separation of duty mechanism; only allow certain superuser operations
> with two people involved.

My views are from working with FDA validated environments, and I don’t really 
understand the above.  It is not db auditing’s job to stop or control the 
access to data or to log what happens to data outside of PostgreSQL.  To audit 
a db superuser is very simple, keep a log of everything a super user does and 
to write that log to a write append, no read filesystem or location.  Since the 
db superuser can do anything there is no value in configuring what to log.  
This should be an option that once set, cannot be changed without reinstalling 
the PostgreSQL binary.  The responsibility for auditing/controlling any binary 
replacement is the operating system’s, not PostgreSQL.  In this environment the 
db superuser will not have authorized root access for the os.

The use case examples, that I am familiar with, are that procedural policies 
control what the db superuser can do.  If the policy says that the db superuser 
cannot dump a table and pipe this data someplace without being supervised by a 
third party auditor (building on the above), then what you want in the log is 
that the data was dumped by whom with a date and time.  Thats it.  Its up to 
policies, audit review, management, and third party audit tools, to pick up the 
violation.  Auditing’s job is to keep a complete report, not prevent.  
Prevention is the role of security.

Neil



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to