Re: How to revoke privileged from PostgreSQL's superuser
| От | Evan Bauer |
|---|---|
| Тема | Re: How to revoke privileged from PostgreSQL's superuser |
| Дата | |
| Msg-id | 8D2B91EF-3D8F-4DE6-81F7-724A387A4C04@mac.com обсуждение исходный текст |
| Ответ на | Re: How to revoke privileged from PostgreSQL's superuser (Tim Cross <theophilusx@gmail.com>) |
| Список | pgsql-admin |
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
On Aug 15, 2018, at 18:30, Tim Cross <theophilusx@gmail.com> wrote:
Bruce Momjian <bruce@momjian.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
В списке pgsql-admin по дате отправления: