The basis of this take is "because it doesn't happen very often, it's snake oil". Has DrRobinson considered that the mere fact they think this is proof it works?
The entire point of encryption at rest (on the cloud) is that when any of the following happen you have nothing to worry about.
1. A machine/disk is rendered inoperable and can't be wiped.
2. The data stream coming off of a disk cluster is tapped.
3. An employee steals a disk or is lost.
4. An actor violates their account segmentation and can read raw data from segments of YOUR sectors of the shared disk.
5. SSD firmware goes bad/gets hacked and starts returning incorrect sectors of disk.
6. Memory pointers go bad and return sectors from the wrong area of the disk.
It's incredibly naïve to not use encryption at rest on AWS with how incredibly easy and problem free it is to deploy.
I agree calling it snake oil is a bit too much, because I know there are benefits.
As I mention elsewhere in the thread, I use encryption, but I don't consider it to be of high value compared to other security mitigations one can spend time on.
As mentioned in the blog post, setting up encryption isn't always easy and problem free though.
Regarding 1, disks are physically destroyed if they are inoperable. Thanks for sharing the list of potential problems, it's always interesting to see how other people think and what they worry about!
>disks are physically destroyed if they are inoperable
'Supposed to be' is missing from this statement. We have seen many vendors over the years say 'we destroy disks' only to have a disk show up in the wild.
I'm equally interested to see what lengths people like yourself will go to when given the option!
Where is it you draw the line?
Do you bother with Spectre mitigations since Amazon policy is to deny service to those who would attack you?
Do you bother requiring authentication on your database since policy is to use a closed VPC?
Hell, we haven't seen any man in the middle attacks lately, let's just drop SSL because you know your customers are wired and trust the endpoint networks.
SSL is the best example subject to the same common failures (including expiration, key loss, downtime to initially deploy) as you describe disk encryption migrations.
Encrypting disks is mandatory and there is zero justification otherwise.
> Do you bother with Spectre mitigations since Amazon policy is to deny service to those who would attack you?
I don't go out of my way to mitigate that, no. Have you seen any real attacks with this? They seem very rare and hard to execute, especially if you have someone specific in mind.
> Do you bother requiring authentication on your database since policy is to use a closed VPC?
Yes. Usually you have multiple services running in the same VPC, by using authentication you limit the potential impact if one service is hacked. Adding authentication to a database that previously had none is also very easy.
> Hell, we haven't seen any man in the middle attacks lately, let's just drop SSL because you know your customers are wired and trust the endpoint networks.
MITM attacks are quite common actually. Internally inside AWS (i.e. between instances) the benefit of TLS is maybe questionable, especially since traffic is encrypted between instances automatically (depending on the instance type).
> Encrypting disks is mandatory and there is zero justification otherwise.
I disagree that there is "zero justification otherwise." I've updated the blog post some and I'm interested to hear your thoughts about it. But in short, adding encryption to an unencrypted machine can take a lot of time and effort. Setting it up correctly from the start is usually easy, but it's not always whoever set it up initially did that. There are many things one can do to improve security, and most things will probably be more beneficial than re-encrypting disks.
Backwards compatibility — GCP started enough later that their hardware could do this at close to zero cost but by then AWS had many large customers who had made decisions based on the performance delta.
By now that's moot so I'd assume they'll set it by default for new accounts at some point but there's a regional option which you can turn on by default:
If you use tools like Security Hub with the Amazon Foundational Security Best Practices suite of controls enabled there's a specific check for that setting:
That's a good sentiment. But you can say the same for the aws encryption.
I.e. how do you even know it's working and your data is encrypted?
Just because API says so, doesn't mean it's so. There is no way for you to verify. Is there?
Unless you encrypt on your end, you can't be sure.
I know people who work there. I've read the infrastructure designs. I know Amazon audits themselves. I know AWS has third party audits. I know AWS has government and enterprise users who require their partners be legally liable for improper implementation. I do not subscribe to conspiracy.
The same is true for other points one through six, if you choose to trust aws. But somehow "It's incredibly naïve to not use encryption at rest on AWS".
I once bought a "new" hard drive off Amazon. The connectors looked suspiciously scratched up, like it had been used before.
When I dug deeper, they had wiped the SMART data and the partition table, but it was absolutely full of readable data. I found clear text server logs indicating that this drive was in a backblaze center for several thousand hours.
Disclaimer: I work at Backblaze, and I was here first.
> I'd worry they would sue for...
If you are referring to Backblaze, we're not going to "sue" anybody for anything.
We (Backblaze) have dealt with a bunch of frivolous lawsuits (and patent trolls) over the years suing us, and OMG we're not going to instigate any lawsuits over some honest person legitimately reporting some issue and being helpful. It isn't going to happen.
Our reputation is important to us. Not just for Backblaze: I'm saying the individuals that founded Backblaze and those people that work now here base our entire existence and careers and the number one marketing efforts at Backblaze are based around we are trying to be "the good guys" and transparent and acting like it. There is no possibly world where we try to suppress a screwup like this through legal means. That would be a PR debacle of epic proportions.
If something went wrong, let's shine a spotlight on that cockroach and figure it out together. I'm not sure the exact drive we are all talking about, but my first guess would be a customer ordered a $189 "USB Restore" all their data shipped to them on an encrypted drive) and we (Backblaze) shipped the customer a USB restore drive and they are subsequently selling it (after copying their restore off of it) on the open market. If it is above 8 TBytes this is absolutely *NOT* the case and we should get to the bottom of it. Without lawyers mucking up the situation.
Absolutely do not tell them. This is a can of worms you really do not want to open. You will not be met with a welcoming response. Its sad, but that is the state of affairs.
What can of worms exactly is opened with a ‘Hey I bought this drive on eBay that seems to have your info on it - want it back?’
What plausible damage have you done that they could sue you over? If all you want is your cost or the like, I can’t imagine that is a crime either.
If someone has a lot to lose, I guess sending a letter through a law office would be a sane option, but backblaze doesn’t strike me as the shoot-first-ask-questions-in-the-deposition type of company anyway.
I'd tell them anonymously. Register a new protonmail account and email support at Backblaze with some incriminating evidence that you're actually in possession of what you claim, and then offer to mail the drive back to them.
How could they sue if you legitimately purchased one of their discarded drives? When you bought it whatever was on it became yours and I doubt their CEO would like their data floating around like that unless it's considered useless.
First they'd cast aspersions on the drive being "legitimately" purchased, then they'd float that you're an evil criminal, in violation of the CFAA and wire fraud acts, and for receiving stolen property.
If the government is out to get you, they'll try and find something to come after you for. Just ask Josh Renaud.
Backblaze is not the government. I mean if you're paranoid about it you could submit a bug bounty with a temporary email address and gauge the response. If I were Backblaze I would like to know about this and would be willing to at least send you a pair of new replacement drives to get that one back, assuming this kind of disposal is not their SOP. It's possible they ran this drive through their vetting process and it didn't meet their spec so they sold it off. The logs might just be from that testing/vetting and any data even on real production backblaze drives I would assume is so striped-out that a single disk would not have anything of recoverable value.
The author is talking specifically about AWS. The odds that there is a mistake decommissioning the disk that leaves the data intact, times that somebody salvaged it from a landfill, times that they care about your data is basically zero. Which means a logical person should worry about everything else.
This would require you or the person in the data center to know which customer is using which disk. And data isn't stored on just one disk, it's spread out over multiple disks and many customers have shards of data stored on the same disk. So even if this did happen, the would only get fragments of data.
Google mostly runs their own data centers. Amazon mostly rents space in commercial data centers with lots of different companies. Aws is probably pretty secure but likely less physically secure compared to Google if you get into the nitty gritty details.
This is false. Aws builds and operates their own data centers. The design and architecture of their data centers are highly standardized and an enormous amount of the build is fully automated. When they do lease they lease just a basic power and fiber build and they build their data center ontop of the base. Given how much custom equipment they run at the data center level it would be impractical to do anything that was collocated. But most data centers for aws, especially in Virginia, are on Amazon owned land. As far as I am aware the only collocations are in the satellite zones, outposts, and in peering locations.
Implicit in this article is the idea that security posturing is a zero-sum game for many companies on the dimensions of both software complexity and time.
Adding full disk encryption takes time from other projects and makes the system more complex. That equation needs to pay out. In all likelihood, the reason your data is going to get stolen is a privilege escalation in your app code or a bad actor on your team. Rogue AWS employee swiping your particular hard drive in us-east-1 is way down the list. Full disk encryption does nothing for the first two vectors.
I think compliance programs are oriented around pushing companies into complex/expensive system designs thinking that is a proxy for a secure system.
Aws has done a really good job making encryption fairly simple to enable. It does make some common tasks complex though, like sharing images between accounts. However it’s not fragile or time consuming, and it is typically standardized in an org of any size that requires these sorts of compliance regimes so individual teams don’t need to worry about it. But associating a volume with a key in KMS is not complex or difficult.
I agree. The problem is mainly going from an infrastructure that's not setup like this, to an infrastructure that is.
Usually you inherit an infrastructure, and it's usually not set up in this way (in my experience) and then there is a lot of work to re-encrypt the data in order to use KMS rather than the default key.
> it is typically standardized in an org
I have still not found any SCP I can set that prevent the use of the default key and enforces KMS. If you have one, I'd be happy to take it! If you mean "standardized" as in written on a paper, I'll rely on wishful thinking because people make mistakes or just don't know about it even if it's a standard.
Yes sorry I mean through cloud formation or terraform templates. I think you can do some config policy malarkey to at least isolate where it’s not happening and feed into a policy engine.
You put it really well, I think that's close to how I think about it.
Compliance has good sides too though. For example, they force you to think about areas your intuition might otherwise not have gone, so I don't dismiss them but sometimes it makes you spend time on less than optimal things in order to stay compliant.
> But what problems does it solve? Are you worried about someone breaking into the AWS data center, stealing the specific disks your data is stored on, and restoring and analyzing the disk data to target your organization? Just imagine how much effort such an attack would take.
This sounds like it's coming from someone who's forgetting that all of our data
in "the cloud" resides in physical buildings throughout the world, which are all high value targets for physical attacks.
I don't think it's an antiquated idea to protect against physical data center attacks. It's best practice.
Disk encryption is far more effective in addressing risks for devices like laptops, desktops, etc. that are not always locked inside an ISO27000 compliant data center that has tons of physical security controls.
Could a data center break-in happen? Sure. Is it likely? No. When used in a data center, FDE is mostly useful when media is being transported or disposed, as an extra layer of protection.
I’m not saying it shouldn’t be used, but when comparing using FDE in other situations vs. a data center, in a data center the physical risk is far lower.
Does AWS not already do full-disk encryption transparently on their side?
If they do, I trust them to be good stewards of their keys. If not, then why not? I don't know about the enterprise part of the market, but I know consumer SSDs come with encryption permanently enabled in the firmware.
But in short, the key is kept in memory on the HSM, and employees don't have access to it. They key can be referenced, but not actually read.
It also means that if a user accidentally deletes their key, there's no recovery. That's it. (Pro tip: Deleting a key is a faster mechanism to make data unreadable than deleting the data itself. ;)
- the drive can request the key on each boot
- the drive stores the key in the firmware, but part of the de-provisioning process would be to reset this key
The people with physical access in AWS datacenters are not the same people who have access to the encryption keys.
In fact, it's likely much more complex than that. The people with software access to the machines very likely don't have access to the key storing system (and definitely not the hardware).
This means that the number of people it's possible to bribe to get access to your data is much smaller than if you can just bribe a DC employee to either smuggle the disk out, or make a copy onto a thumb drive.
I'm not saying the number of people who could "break glass" and read anyone's data is zero. But it's at least an order of magnitude fewer than the hoards of people employed to swap hard broken drives all day every day.
And the people with this "root" access will likely be very well paid, reducing (but not eliminating) risk of bribes.
I think this is a valid point, though I don't expect the people in the datacenter to know which customer stores data on which disks. There could of course still be someone working there that steals data from all customers and you end up being part of that, but that's probably quite hard and risky for the employee since the datacenters are heavily monitored and access is restricted. As a targeted attack, I'd expect them to need to team up with a different department, which makes the attack even more expensive.
Yup. Security is layers. Checking this box helps against some threats. Definitely not "close to useless".
Public Cloud cloud have their shit together, but they also deal with millions of hard drives. I could definitely see a story coming out where someone finds a hard drive, some sensitive stuff on it, and just nobody has any idea how it got out. Stranger things than that happen every day.
If it's encrypted then that's another layer of swiss cheese.
It lowers the risk a minimum amount (which makes it not useless, but close to it.) Your resources are limited, so you want to prioritize actions that have good cost:benefit ratio.
Re-encrypting disks is a significant effort (cost), effort that could be spent on something with better benefit. Should you spend a day encrypting a database or should you spend it on looking over publicly exposed S3 buckets? Ideally both, but resources are limited. Doing one action always means you're putting off something else.
Did you see other comments in this thread, for example someone bought a drive online and turned out it still had some backblaze data?
Compliance often has a bunch of useless checkboxing, but in that case it really mattered.
I heard a rumor that some companies had their backups "in the other tower". People won't be making that mistake again.
In some places they have a policy against two key people being on the same plane. It's ridiculous, until it isn't.
Obviously there are priorities. But you can't say "I need to add features, not unit tests, because the company will go under without these features implemented very soon, and therefore unit tests are close to useless".
Part of it, maybe. But the point about it reducing risk by very little is true.
> Did you see other comments in this thread, for example someone bought a drive online and turned out it still had some backblaze data?
Backblaze data is encrypted, or so they claim. Backblaze is also not hosted on AWS. I've also yet to see any evidence of that claim, though I don't dismiss it.
Data is sharded/spread out over multiple disks, you don't have one disk per customer and have all their data there. You'd get fragments of data. If Backblaze was running their servers on specific disks that were not encrypted, not zeroed, and not destroyed, that'll have to stand for them. Backblaze is hosted in a shared data center/colocation, while AWS has their own data centers with their own personnel. Backblaze is a separate company from AWS.
The author is not talking about getting someone with physical access. He’s talking about bribing someone with software access to your disks, who can access the data, regardless of the encryption settings.
> The author is not talking about getting someone with physical access.
Right. The author missed this as one of the major attack vectors that this aims to protect against. I don't think leaving out a real justification for it when saying it's snake oil speaks in favour of the author's point.
Like Bedon292 said, I think you misread my comment. I was saying thanks to encryption they don't have access.
Most well paid engineers at AWS won't have access either. Presumably some minimal set would, but they would likely be pretty senior, and well paid.
But ideally you'd want one set of people with access to the keys, another with access to the data, and a third with physical access, and no overlap. That way you need three people to conspire.
But that's going to be very hard to achieve in practice. But it's not all or nothing. The closer you get to this goal the harder it'll be for someone to not just do it, but do it without triggering a tripwire from the security folks, or at least persist a log entry that if found would get them thrown in prison.
Public cloud companies are not like a small startup where everyone has root.
(sounds like twitter kinda was, according to recent reports)
Right now it's just defence in depth, to protect you if Amazon screws up their physical security. It will make more sense as confidential computing[1] becomes more common. This is because the data can't be accessed by the cloud vendor, assuming the key is generated inside the trusted VM.
[1] The trust moves to the CPU vendors instead of the cloud vendors, but if you don't trust CPU vendors then you're going to have a hard time doing anything with computers in the modern world.
I agree with the author that it's worthwhile spending your time elsewhere than adding encryption.
I think the real issue is higher-ups think that if data is encrypted that somehow mitigates meaningful exfiltration, but just look at data breaches like Capital One and you'll see that's not the case.
The whole stealing the (correct) hard drive or concerning yourself with a host-level attack should be at the very bottom of the list as far as your threat model goes -- these are not really typical of the surface area of most deployments and you're better off focusing on the surface area such as application security, transport security, having your applications perform the encryption than relying on AWS controls, etc.
I think the author and the commenters here are using two different threat models. A lot of people here are saying you should encrypt the disks because it’s best practice for security. Or because it protects against some specific, if implausible, scenario. They’re talking about theoretical security.
The author is saying the probability that it improves your security is so low that any time it takes away from other security related work is actually making your security worse. That’s a different threat model, and it’s probably the better way to approach security, and the author is probably correct - if he actually uses that saved time to improve security in other ways.
I have a question though, what are the laws that require encryption? I can think of HIPPA, SOC2 maybe? What about GDPR?
There are secondary effects to not using encryption you can see.
For instance, it greatly expands the scope of ‘I lost your data/I exposed your data’ notifications in places like California, and for those under many of those other rulesets.
Someone getting access to a repo of encrypted drive images, or someone losing an encrypted drive, doesn’t count. And for reasonableish reasons.
It’s a basic risk mitigation/blast radius limiting move.
For physical/on-prem especially, since old disks tend to ‘wander’ after retirement, and it’s a great idea to always have had them full disk encrypted to reduce the odds someone sensitive gets exposed years down the line.
It’s more that the author is arguing that their inexperience is universally applicable. “Why do banks have guards, I’ve never had someone break into my couch cushions?”
Beyond the compliance requirements (e.g. CIS), it’s wrong to assume that disks are always perfectly disposed of – simply never having to worry about featuring in one of those “look what I found on eBay!” posts and notifying your customers is worth the basically non-existent cost of basic encryption. It’s something you turn on and basically never think about again - the performance hit disappeared around 2010 and it’s easy to enable globally.
Beyond that, however, there are two key benefits - the author even almost discovers one of them but didn’t think about it enough: encryption means deletion is probably fast - delete the key and you don’t need to monkey around wiping disks and snapshots.
The other, bigger, one is that it can protect against mistakes or compromises. If you share a KMS-encrypted resource accidentally, an attacker won’t have access to the data. An attacker can’t access a resource with a custom KMS policy unless they compromise the specific role which has access or do more invasive things which will trip alerts. Again, not perfect but it protects against common mistakes like the Capitol One firewall breach, which is why all of those standards started recommending it.
> It’s more that the author is arguing that their inexperience is universally applicable. “Why do banks have guards, I’ve never had someone break into my couch cushions?”
That was not my intention and it's unfortunate that's how it sounds. Just like most people don't need armed guards, most people don't need bank level security for their disks either. Encrypting disk encryption is usually not the most effective thing you can do to improve your security, there are usually other actions with better payoff.
AWS zeroes the disks before they're reused, so from your point of view it's instant. As mentioned in the post, deleting a KMS key takes at least 7 days (and up to 30 days, depending on your configuration.) Regarding other point, that's also mentioned in the post as "if your IAM access configuration is bad your KMS access configuration might save you," which is referring to what you mention.
> It’s something you turn on and basically never think about again - the performance hit disappeared around 2010 and it’s easy to enable globally.
This is true if you, or the one you inherit the infrastructure from, configured it correctly from the start. But re-encrypting disks, databases, S3-buckets etc is time consuming and might require downtime. So it's not always easy or cost free (in terms of labor.) I'm not sure what you're referring to with "easy to enable globally", enable what?
> AWS zeroes the disks before they're reused, so from your point of view it's instant. As mentioned in the post, deleting a KMS key takes at least 7 days (and up to 30 days, depending on your configuration.)
Yes, the point is that it separates physical and logical concerns. That's why all of the major services have been moving to have it on by default since it means that there's no way for lost hardware to cause a data breach, and while the KMS delays to prevent accidental / ransomware deletion are not instantaneous they're visible and deterministic: things are deleted when you think they are.
> Regarding other point, that's also mentioned in the post as "if your IAM access configuration is bad your KMS access configuration might save you," which is referring to what you mention.
I guess I'm just not seeing how that's “close to useless and potentially harmful” – defense in depth is a useful hardening technique, especially if you have to worry about admins being compromised or demonstrate that sysadmins can't access data without following a standard logged path.
> This is true if you, or the one you inherit the infrastructure from, configured it correctly from the start. But re-encrypting disks, databases, S3-buckets etc is time consuming and might require downtime.
Saying that something is hard to clean up later isn't “close to useless and potentially harmful” — if anything, I'd take the opposite position that if you do the “pointless” compliance work, you're not going to be in that position later when you have a ton of data and busy applications.
> So it's not always easy or cost free (in terms of labor.) I'm not sure what you're referring to with "easy to enable globally", enable what?
Partially I was thinking about https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncry... but the more general point was just that these are easy to set up when you're creating new resources and there isn't a runtime impediment for having done so the way there was decades ago when performance was a reasonable concern.
In general, when the entire industry is saying you should do something or, as is the case for the major cloud providers, turning it on by default, I would stop to ask whether it is in fact unnecessary or them trying to prevent yet another customer from ending up in a situation where the work required to deal with a problem is considerably greater than preventing it would have been.
> Saying that something is hard to clean up later isn't “close to useless and potentially harmful”
The "close to useless" is based on it lowering any risk with very little, it's not a big payoff security wise in most cases. "Potentially harmful" refers to the cost of potentially having to re-encrypt data, that is cost/effort that could instead be spent on other security mitigations with better cost:benefit ratio.
You have a limited amount of resources, and with those resources you want to lower the risk as much as possible. I consider re-encrypting data to fare badly in such calculation. It's a high effort low benefit mitigation in most cases. If encryption is done correctly, it might cost little effort and gives little benefit and might therefore be worth it. It's very common to not do it correctly though, and that requires re-encrypting. I have not found an SCP that allows KMS keys but not default encryption keys, which means manual effort is spent on teaching developers and/or build/use tooling.
This is partially true with respect to EBS (i.e. virtual disks). When you boot up an EC2 instance, the a plaintext data encryption key is loaded into hypervisor memory. As long as the EC2 instance is still running, you can add an additional EBS volume to the instance and then copy data from the disk that has the orphaned key. Even if the underlying KMS key was deleted.
The rest of this stuff feels like FUD me. Yes, IAM has identity-based policies and KMS has resource-based policies. And yes, default service KMS keys are unique per account (why would you expect otherwise?).
Implementing an encryption program takes forethought. This is true if you're hosting your own data, too. I really don't miss manually rotating drives, fighting with LUKS, and then putting drives in a fireproof safe (which was never locked anyway, so I'm not sure if it would've actually protected anything in an actual fire).
> And yes, default service KMS keys are unique per account (why would you expect otherwise?).
I expect it to be unique per account, but I would be happy if it was possible to share it with other accounts so one could make cross account backups (it's good practice to have a separate AWS account for backups.) Currently this requires a KMS key, which means data encrypted with the default key must be re-encrypted and that takes a lot of time and effort.
I disagree that encryption at rest with AWS is actually the proper way. If someone can get to the actual hardware and steal disks, I can't trust that AWS hasn't also lost control of the encryption keys.
Just because something isn't 100% perfect in every scenario doesn't mean it shouldn't be done at all.
But I agree with your point, if you're really worried about data to the point where you don't trust AWS with encryption keys, you should self-manage your keys and manually encrypt/decrypt data without AWS KMS.
I'm not sure if the author is aware that they can bring their own key material if they wish to KMS. The cost model is a little different, but you retain complete control of their life cycle across time and regions. It would seem to solve many of their pain points. Additionally, AWS recently added support for a user maintained keystore.
As for some of these statements (i.e. loss of key equals loss of data, re-encryption with a new key is expensive to go through an entire disk, etc.), that is exactly the point of encryption and holds true beyond the cloud. It is not meant to be trivial; it is a layer of security that trades convenience and often some level of performance.
Disks are wiped immediately before they are made available as a new volume. If your policies require a certain level of wipe, you should wipe the disk before releasing it.
That's an interesting idea. I imagine they don't do DoD wipes of their disks because they are probably multi-tenant, right? Can a guest operating system do forensic analysis on the host disk?
AWS wipes disks before reusing them (loosely speaking--an EBS volume doesn't correspond 1:1 to a physical disk). Forensic analysis of overwritten data requires disassembling the physical disk, so no, it's not possible.
It helps you trust the data protection and destruction policies of AWS less. If a disk goes bad, will it be wiped properly before being discarded for example? Or will your confidential data be recoverable by anyone at the landfill? What if an AWS DC tech identifies the bare metal your VM runs on and replaces a disk in the raid and takes the old one home? How good is their security to prevent that from happening? I can think a few ways of getting that past man trap xray scanners and all that physical security.
This is a low quality article. Disk encryption at rest has a bunch of reasons to be required besides someone breaking into AWS to steal the disk (and someone could bribe an employee to do that as easily as bribe an employee to steal your data digitially.)
This blog post is like someone complaining "parameterized queries are so much more of a pain than just using string interpolation to build my queries. I'd never allow SQL injection in my app." Hubris of an inexperienced engineer imho.
This seems unnecessarily hostile. I've worked with cloud infrastructure and security for more than 10 years. If you have experience of unencrypted disks being stolen from AWS I'm very interested to hear about it.
Note, though, that I don't claim one shouldn't encrypt disks, but I consider it to be very low on the list of priorities when it comes to lowering risk. There is almost always risk-lowering actions with better cost:benefit ratio than encrypting disks in the cloud, since that risk is already so low.
The primary reason I see for encryption is because all of the disks are shared. Encrypting at rest is to make sure that the next user of the disk is not able to find any of your data. Even if the odds are low, you still don't want any private information leaking on accident. And you have to be able to guarantee it for things like HIPAA or PCI compliance.
Are you saying that EBS exposes previous tenant disk contents when you provision a new disk? I've never heard of that happening. It would be incredibly insecure if true.
>> Are you worried about someone breaking into the AWS data center, stealing the specific disks your data is stored on, and restoring and analyzing the disk data to target your organization?
How to exfiltrate data is a large topic of discussion. A rogue developer copying the production database to their laptop is another threat, but then they have to copy the data from there, so then you disable USB devices on endpoints. It's an ongoing battle.
Imagine if disk encryption were not routinely used. The disks of the cloud providers would be a goldmine of sensitive corporate data and the incentive for them to go missing correspondingly higher.
tl;dr author finds it a hassle to set up proper encryption at rest and rationalizes away why they shouldn’t need to do it.
> You used the AWS default key to encrypt a database?
Don’t do that? Create a separate account to hold keys. Lock it down like you would your domain DNS or anything else with security implications that will impact your entire company.
Share granular read permissions across accounts as needed to encrypt / decrypt.
Agreed it’s time consuming to initially setup, but it’s a solved problem and can be implemented with your IaC flavor of choice (CloudFormation directly, CDK, Terraform, …).
What you describe is essentially what I currently do. But I've inherited an infrastructure that was not setup that way, and re-encrypting things has been very time consuming.
The company I'm at now use multiple AWS accounts where teams have their own accounts, and it's common for people to forget to use KMS when creating databases or similar. I might have just failed in my search but I couldn't find any way to block default keys via SCPs. If you have any suggestions for that I'm happy to take them!
The entire point of encryption at rest (on the cloud) is that when any of the following happen you have nothing to worry about.
1. A machine/disk is rendered inoperable and can't be wiped.
2. The data stream coming off of a disk cluster is tapped.
3. An employee steals a disk or is lost.
4. An actor violates their account segmentation and can read raw data from segments of YOUR sectors of the shared disk.
5. SSD firmware goes bad/gets hacked and starts returning incorrect sectors of disk.
6. Memory pointers go bad and return sectors from the wrong area of the disk.
It's incredibly naïve to not use encryption at rest on AWS with how incredibly easy and problem free it is to deploy.