Re: How to revoke privileged from PostgreSQL's superuser - Mailing list pgsql-admin

From raf
Subject Re: How to revoke privileged from PostgreSQL's superuser
Date
Msg-id 20180815214111.xy4y7j5hg5jl7pgo@raf.org
Whole thread Raw
In response to Re: How to revoke privileged from PostgreSQL's superuser  (Bruce Momjian <bruce@momjian.us>)
Responses Re: How to revoke privileged from PostgreSQL's superuser  (Bruce Momjian <bruce@momjian.us>)
List pgsql-admin
Bruce Momjian wrote:

> On Tue, Aug 14, 2018 at 03:59:19PM -0400, Bruce Momjian wrote:
> > On Fri, Aug 10, 2018 at 04:06:40PM -0400, Benedict Holland wrote:
> > > I also would take Bruce's comment with a massive grain of salt. Everything that
> > > everyone does on a database is logged somewhere assuming proper logging. Now do
> > > you have the person-power to go through gigs of plain text logs to find out if
> > > someone is doing something shady... that is a question for your management
> > > team. Also, if you suspect someone of doing something shady, you should
> > > probably revoke their admin rights. 
> > 
> > Agreed, the best way to limit the risk of undetected DBA removal of data
> > is secure auditing --- I should have mentioned that.
> 
> So, how do you securely audit?  You ship the logs to a server that isn't
> controlled by the DBA, via syslog?  How do you prevent the DBA from
> turning off logging when the want to so something undetected?  Do you
> log the turning off of logging?
> 
> -- 
>   Bruce Momjian  <bruce@momjian.us>        http://momjian.us

Yes. You can set up terminal session logging with redhat's
tlog (https://github.com/Scribery/tlog) which can record all
terminal activity done via ssh, ship it offsite and replay it
for auditing purposes. So if an administrator does turn off any
logging (presumably including tlog itself), you'll at least be
able to see them turning it off.

cheers,
raf



pgsql-admin by date:

Previous
From: Natalie Wenz
Date:
Subject: Cursors
Next
From: Bruce Momjian
Date:
Subject: Re: How to revoke privileged from PostgreSQL's superuser