[acdha]

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.

[DrRobinson]

> 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?

Thanks for sharing your perspective!

[acdha]

> 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.

[DrRobinson]

> 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.