Re: How to revoke privileged from PostgreSQL's superuser

Bruce and Tim,

All good points — some of which go back to my quick response to Bejita’s original “newbie DBA” question back on 6-Aug. We’ve been talking about this for nine days now — it is clearly a challenging and thought-provoking issue.

I agree that you have to start with security business requirements that become policies — and often these policies need to implement governmental or industry regulatory requirements. Least-Privileged access and segregation of duties are just two of the policy principals that need to be applied to the business architecture that makes use of the technical architecture.

Controls that implement these policies have to be applied in-depth for successful NIST 800-171, NIST 800-53, HIPAA HITRUST, and similar sensitive environments. (My apologies to my international colleagues for my US-centric background.)

An effective (and auditable as effective) solution to building a highly secure information system with PostgreSQL to meet these business security requirements requires engineering the whole environment, including (but not limited to):
network firewall rules,
jump boxes with logging shells,
Identity and access management (e.g. LDAP or AD),
key and credential management,
SELinux roles, access controls, and privileges,
off-node logging to a SIEM with log inspection,
in addition to securely configuring the PostgreSQL cluster itself (including pgaudit).

Joe Conway of Crunchy delivered a meaty presentation on locking down Postgres to meet US Federal requirements at PGcon in Ottawa. His slides are at https://www.joeconway.com/presentations/SecurePostgreSQL-PGCon-2018.pdf — there is a lot there and it is worth taking the time to go through them. (Needless to say, Joe didn’t speak to all 69 slides in a 45 minute time slot.) He makes the superuser abuse possibilities clear, illustrating the reasons that the other layers are needed to provide a state-of-the-practice secure Postgres implementation.

Security architecture is an increasingly discipline within systems architecture — it applies to database applications as much or more as anything else in the IT infrastructure.

- Evan

Evan Bauer
eb(at)evanbauer(dot)com
+1 646 641 2973
Skype: evanbauer

> On Aug 15, 2018, at 18:30, Tim Cross <theophilusx(at)gmail(dot)com> wrote:
>
>
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>
>> On Wed, Aug 15, 2018 at 01:52:43PM -0700, Evan Rempel wrote:
>>> There are just a ton of configuration elements that the DBAs need to decide on and implement that require
>>> configuration of components that are outside of the database proper.
>>>
>>> It was a worthwhile discussion. One needs to trust the data stewards.
>>
>> Agreed. I just wish it had a more positive outcome. ;-)
>
> I think the key points to note are
>
> 1. At some point in the hierarchy of privileges, there is a need to have
> confidence and trust in at least one individual who will have (and need)
> sufficient privileges that restricting them via technology will become
> impossible as they will have sufficient power to circumvent
> anything. Typically, it will be more than a single individual to avoid
> the proverbial 'hit by a bus' risk.
>
> 2. Security comes at a cost. That cost is reduced convenience and
> increased bureaucracy. The challenge is getting the right balance where
> that cost is kept as low as possible while mitigating the identified
> risks. There is no one model which will suit all.
>
> 3. The principals of minimal privileges and separation of
> responsibilities is often a useful guideline. I have seen places where a
> 'Westminster' model is applied (distinct executive (C level),
> legislative (policy & Governance), judiciary (risk & audit).
>
> The real challenge with security is that it isn't actually a technology
> problem. It is a business problem. The technology can provide mechanisms
> to help address the issues, but technology alone cannot solve them.
>
> Where it becomes challenging is at the cross-over points. The executive
> should define overall high level strategy and direction, the legislature
> clarifies and codifies the strategies and business processes to enable
> staff to make appropriate decisions and the judiciary ensures everyone
> is playing by the rules. However, these three areas typically have only
> limited understanding of the technology (knowledge will typically
> increase as you work down from executive, legislature to judiciary). As
> DBAs, we need to understand the principals and risks and apply the
> technology in the best way possible to support the business and the
> defined strategies.
>
> Tim
>
> --
> Tim Cross
>