4 ms·
Take the "drop database" bit (on the production database) away from your developers, too. As well as pretty much every other privilege they don't legitimately
by jlgaddis 6y ago
Take the "drop database" bit (on the production database) away from your developers, too.
As well as pretty much every other privilege they don't legitimately need to use on a daily basis -- which, for prod, should be most of them (quite possibly including "delete").
If or when they really need to delete a ton of rows all in one go, they can be given a (temporary) set of credentials that they can use to do that, once, and which are then revoked immediately afterwards -- after another set of eyes reviews the script they've written to actually perform the operation, of course.
Basic best practices aren't difficult or some secret thing that only the experts know about. It is necessary to actually implement and follow them, however!
Sure, it can be a pain in the ass sometimes. Will it be worth it when it eventually saves your ass one day, "after a couple of glasses of red wine"? Absolutely.
- asddubs 6y agothat's true, I totally forgot about SQL permissions, there's so many failsafes for this
- astura 6y agoAs a developer at all the jobs I've had, I've never even had access to the production database, full stop - only the server admins did. If I needed something from prod I'd go through them. I don't even consider it inconvenient.
- Izmaki 6y agoThe distance between the developer and the production database is directly proportional with the size of the company. The same is true for the amount of paperwork needed for even the simplest things. For some company sizes a feedback cycle measured in days is not good enough and may kill the business. There is a whole lot of things that could be applied which would have prevented this, before needing to hire a separate server admin as an interface to the production database. :D