4 ms·

It also defends against cultural indifference to privacy violations. If you go to Reddit r/sysadmin, most SREs and DevOps folks generally do not care too much f

It also defends against cultural indifference to privacy violations. If you go to Reddit r/sysadmin, most SREs and DevOps folks generally do not care too much for challenging subpoenas and government data requests. If a three letter spook shows up to their data center and demands data, it's just another Tuesday for them. IT people are very different from software engineers who are more likely to protest online and offline about civil right violations and government overreach.

EPWN3D 2y ago
Yeah I've always gotten power tripping vibes from sysadmins. They're happy to fork over data just to show that they can.
- Volundr 2y ago
  This is a weird take. For one, handing over data because someone in power told you too is the exact opposite of power tripping. It's pretty much the entire description of disempowering. But secondly, the idea that anyone who actually has a say in if the data is turned over (the legal team, executives) give a flying fork about how a random sysadmin in their data center feels about it is wildly off base. The data is going out or not according to legals instructions. Either sysadmin Bob does it, or he takes a principled stand, gets fired, and Bob 2 takes care of it.
- KAMSPioneer 2y ago
  I'm a sysadmin and I have no idea what you're referring to. Yeah there are guys in my field who are happy to overreach in terms of data access, but I'm sure we can come up with some anecdotes about devs over-harvesting data on...virtually any modern online platform. Most of my colleagues (at least those I've met) tend to be conscientious about data access and privacy. I host several E2EE services for friends/family because I believe in privacy and data sovereignty. But if my company's legal department says "give access to <these guys>," as a sibling commenter said, if I refuse then I'm fired and those guys will still get access. So I do what legal says and keep my job, TYVM.
blitzar 2y ago
software engineers who are more likely to want to harvest and process more personal data than the three letter agencies can possibly imagine
victorbjorklund 2y ago
But the SRE/Devops team would certainly have access to the decryption key. Seems a little bit weird to encrypt to just stop another team from doing their job. Wether data should be handed over to the govt or not should probably be a company decision and not the dev teams anyway.
- KRAKRISMOTT 2y ago
  Most companies don't really think too hard about these decisions, they just go with the easiest route. If the upstream hardware and software enforce encryption by default, very few companies would go out of their way to specifically try to disable that functionality if doing so is very tricky.
dfc 2y ago
Software engineers are more likely to care about civili rights than IT people?
t_sawyer 2y ago
Different levels of encryption at rest play different roles in your particular scenario. If you use a cloud service and they have an encryption at rest feature that you enable, the default is for them to control the key. Or, for Azure, put a "customer controlled" key in Key Vault. But again, that's their service. In this scenario you're only protected against people physically in the data centers not their DevOps folks. But, that feature gives you a checkmark for SOC2 or other regulations... The problem protecting against DevOps folks at a cloud is: 1. You are burdened with putting a key somewhere outside of their cloud. If you do something at the filesystem level like enable bitlocker on a VM you're going to experience pain during reboots and it's not possible on a root volume if you're not given a console. 2. You can't do this on a cloud service like RDS. You'd have to do row level encryption with your application doing the decryption/encryption. But, your application has to have the key and now your back to #1. The VM with the key needs the root disk encrypted or the drive where the key is store encrypted. And again, you're not able to use a cloud service like EKS or App Service you're stuck with VMs. Generally, I tend to just stick with regulation requirements which protect against the physical hard disk.

EPWN3D 2y ago

Yeah I've always gotten power tripping vibes from sysadmins. They're happy to fork over data just to show that they can.

Volundr 2y ago
This is a weird take. For one, handing over data because someone in power told you too is the exact opposite of power tripping. It's pretty much the entire description of disempowering. But secondly, the idea that anyone who actually has a say in if the data is turned over (the legal team, executives) give a flying fork about how a random sysadmin in their data center feels about it is wildly off base. The data is going out or not according to legals instructions. Either sysadmin Bob does it, or he takes a principled stand, gets fired, and Bob 2 takes care of it.
KAMSPioneer 2y ago
I'm a sysadmin and I have no idea what you're referring to. Yeah there are guys in my field who are happy to overreach in terms of data access, but I'm sure we can come up with some anecdotes about devs over-harvesting data on...virtually any modern online platform. Most of my colleagues (at least those I've met) tend to be conscientious about data access and privacy. I host several E2EE services for friends/family because I believe in privacy and data sovereignty. But if my company's legal department says "give access to <these guys>," as a sibling commenter said, if I refuse then I'm fired and those guys will still get access. So I do what legal says and keep my job, TYVM.

blitzar 2y ago

software engineers who are more likely to want to harvest and process more personal data than the three letter agencies can possibly imagine

victorbjorklund 2y ago

But the SRE/Devops team would certainly have access to the decryption key. Seems a little bit weird to encrypt to just stop another team from doing their job. Wether data should be handed over to the govt or not should probably be a company decision and not the dev teams anyway.

KRAKRISMOTT 2y ago
Most companies don't really think too hard about these decisions, they just go with the easiest route. If the upstream hardware and software enforce encryption by default, very few companies would go out of their way to specifically try to disable that functionality if doing so is very tricky.

dfc 2y ago

Software engineers are more likely to care about civili rights than IT people?

t_sawyer 2y ago

Different levels of encryption at rest play different roles in your particular scenario. If you use a cloud service and they have an encryption at rest feature that you enable, the default is for them to control the key. Or, for Azure, put a "customer controlled" key in Key Vault. But again, that's their service. In this scenario you're only protected against people physically in the data centers not their DevOps folks. But, that feature gives you a checkmark for SOC2 or other regulations... The problem protecting against DevOps folks at a cloud is: 1. You are burdened with putting a key somewhere outside of their cloud. If you do something at the filesystem level like enable bitlocker on a VM you're going to experience pain during reboots and it's not possible on a root volume if you're not given a console. 2. You can't do this on a cloud service like RDS. You'd have to do row level encryption with your application doing the decryption/encryption. But, your application has to have the key and now your back to #1. The VM with the key needs the root disk encrypted or the drive where the key is store encrypted. And again, you're not able to use a cloud service like EKS or App Service you're stuck with VMs. Generally, I tend to just stick with regulation requirements which protect against the physical hard disk.