4 ms·

> Then try thinking about potential ways of how all these things could interact to break a system. This is where your advice goes south, IMHO. The sysadmin can

> Then try thinking about potential ways of how all these things could interact to break a system. This is where your advice goes south, IMHO. The sysadmin can't think of every possible way his system can get compromised -- they are not paid for that, black-hat hackers are. Instead of collecting settings from a hundred places that must be set correctly for production, and inventing ways the system can get compromised, the safe settings could be provided in one place: ideally in the default settings so they are impossible to miss, or in a list, such as Django's deployment checklist [1]. Not saying that Postgres doesn't provide such a list, although googling for "checklist site:postgresql.org" only resulted in a mailing list reply [2], with some points not trivial to follow. Please comment below if you know an official one. [1]: https://docs.djangoproject.com/en/3.0/howto/deployment/checklist/ https://docs.djangoproject.com/en/3.0/howto/deployment/check... [2]: https://www.postgresql.org/message-id/D960CB61B694CF459DCFB4B0128514C202FF6542@exadv11.host.magwien.gv.at https://www.postgresql.org/message-id/D960CB61B694CF459DCFB4...

chousuke 6y ago
Of course you don't need to think of every possible way to compromise a system; just enough to reasonably protect against your threat model given the resources you have. If you have a complicated system that requires "hundreds of settings", then you just have to put more effort in making sure you don't miss anything. I'm pretty sure most security breaches are caused by really basic configuration mistakes (or process failures). following a checklist can definitely be effective, but if you don't actually understand why you're configuring things as you are, you're likely to make mistakes elsewhere.