Search Postgresql Archives

Re: Loggingt psql meta-commands

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Dec 10, 2015 at 02:52:38PM -0800, John R Pierce wrote:
> thats a rather insane bunch of requirements.   Reads like a wish list by
> academic security researchers.

Well, I don't know.  Might be a wish list by insurance adjusters who
want to minimise liability.  At least in the United States of
Liability, I think the day is rapidly approaching where people will
need insurance against database breaches.  Therefore,

> https://www.stigviewer.com/stig/database_security_requirements_guide/2015-06-23/finding/V-58123
> 
> ??!?   The database server has no clue about the difference between an
> "application that it supports" and a user directly querying.  The PSQL
> shell, or dbadmin, is an 'application that it supports'.

while I agree that there's no way for the RDBMS to tell when it's an
attacker mimicing an application's normal connection and query
pattern, I think there are some things you could do here that would
catch this.  For instance,

    • use strong authentication mechanisms for your clients.  Kerberos
      seems like a good alternative, but TLS (SSL) certificates might
      do.  Log connections and the connection origin.  If you get
      connections for a given user from the wrong place, you know you
      have a problem.

    • isolate your users, so that your application (or better, each
      instance of your application) has an associated user.  Your
      humans are not allowed to log in with this username.  Then,
      queries issued by non-application usernames are your candidate
      queries.

Again, this will not defend against, "Attacker got into my system and
subverted the application user."  You need to have other lines of
defence for that.  But depending on your auditor, this might be enough
to satisfy the condition.

Also, of course, there is the application_name (string) parameter.  In
principle, you ought to be able to filter on this.  Again, won't help
you if your application login is somehow compromised.

I agree that all of this depends on logging everything and filtering,
however.

Best regards,

A

-- 
Andrew Sullivan
ajs@xxxxxxxxxxxxxxx


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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux