There's a large amount of process in place at traditional companies to prevent this kind of tampering. Commonly, it involves separation of powers, with an "Operations" team that runs the software and an "Engineering" team that runs the software. This way, theoretically, nobody who has the knowledge of how to abuse the system would have access to abuse it. Making "unwanted" changes to software would require the consent of two parties at odds - One on Ops, one on Eng.
In practice, it was impossible to debug software if you didn't have knowledge of how it ran and it was impossible for teams to cooperate when designed as antagonistic. "Operations" people needed to know enough programming and SQL to be able to audit engineering access, or they became blind drones parroting the actions that the Engineering team took. A useless layer of signaling that added no substance. And it was easy to align bad actors in Ops and Eng, at least in places where it mattered - Usually with money.
My career in DevOps has been breaking down these barriers, promoting a "shared ownership" model where it's devs are directly oncall and have production credentials to their services. Still, there are serious protections in place: The passwords to the production databases are stored securely, not typically visible to devs - They have to jump through hoops of using a auditable bastion box to run SQL commands directly on the production databases. Not that it's not possible, not that it's not done (Though good engineering practices make it an uncommon task, I think we've actually used the ability half a dozen times in the last year), but as the commands are being typed they send out logs to a third-party service that's instructed to archive them. It's not hard to get access, but it would be easy to see the trail.
That said: This is on a mature team. That doesn't come out of the box and we didn't get there easily. Many teams, even with all of that protection, don't actually audit the logs, and do generate a lot of logs because of poor system behavior.
Knowing the engineering talent at Reddit, I doubt that it's a concern. Whether by malice or naivete, it has likely never crossed their mind that anyone would break protocol and access databases directly for anything other than legitimate debugging purposes. I'm convinced that the SF bay has some of the narrowest focused minds... and also many of the most malicious.
In practice, it was impossible to debug software if you didn't have knowledge of how it ran and it was impossible for teams to cooperate when designed as antagonistic. "Operations" people needed to know enough programming and SQL to be able to audit engineering access, or they became blind drones parroting the actions that the Engineering team took. A useless layer of signaling that added no substance. And it was easy to align bad actors in Ops and Eng, at least in places where it mattered - Usually with money.
My career in DevOps has been breaking down these barriers, promoting a "shared ownership" model where it's devs are directly oncall and have production credentials to their services. Still, there are serious protections in place: The passwords to the production databases are stored securely, not typically visible to devs - They have to jump through hoops of using a auditable bastion box to run SQL commands directly on the production databases. Not that it's not possible, not that it's not done (Though good engineering practices make it an uncommon task, I think we've actually used the ability half a dozen times in the last year), but as the commands are being typed they send out logs to a third-party service that's instructed to archive them. It's not hard to get access, but it would be easy to see the trail.
That said: This is on a mature team. That doesn't come out of the box and we didn't get there easily. Many teams, even with all of that protection, don't actually audit the logs, and do generate a lot of logs because of poor system behavior.
Knowing the engineering talent at Reddit, I doubt that it's a concern. Whether by malice or naivete, it has likely never crossed their mind that anyone would break protocol and access databases directly for anything other than legitimate debugging purposes. I'm convinced that the SF bay has some of the narrowest focused minds... and also many of the most malicious.