| 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):
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
|
