@radekmieBy Radosław Miernik · Published on · Updated on · Comment on Hacker News, Reddit
I must admit – my wife and I are binge-watching HBO’s Succession1, and it got me thinking… What could happen if some people I work with went rogue? Not that I expect it to happen, but it’s… Well, not impossible.
Let’s keep this one short: are you aware of how many people have (or can have) a so-called “destructive access” at your company? For example, who can kill halt the production environment? Remove it completely? Or stab it a little?
If it happens, you can quickly set it up again (right…?) and get back to the usual business (revoke accesses, fire someone, etc.). Of course, there will be some downtime, but it’s such a wild case most users will get it. I hope so, at least.
But let’s look further: your database. Someone can purge the hell of it. You have backups in place (right…?) and can bring it back soon. But I bet that this someone can also remove the backups2. And that’s a big deal.
The same goes for code: there’s usually someone who can deploy a malicious code rather fast. Sure, it’ll leave a trace (right…?), but it’ll still hit the customers. And I bet they could purge the repository too.
Let’s wrap up: there are people who can bring the whole company down in a matter of minutes. Make sure you know who that is and that you trust them.
Or get ready to sue them.
Yes, that’s why this month’s text is short. And yes, it may be a little paranoid. Maybe that’s what everyone needs (from time to time): a nice series to watch and a tough problem to sleep on.
Henrik Sylvester Pederesen reached out to me and suggested a potential solution: Write Once Read Many (WORM) locks. The idea is simple: make data immutable, at least for some time. Here’s AWS’s blog post introducing it for S3, suggesting both compliance and legal use cases. Similarly, database providers have thier counterparts, e.g., Backup Compliance Policy in MongoDB Atlas.