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
