Further, if data is encrypted at rest then there are multiple levels of auth that must fail for a breach to occur, namely access to the data and access to the key.
Then what is the cost / overhead / complexity / other cons of adding encryption at rest? Cyber budgets often go crazy I see so many clients that are buying tech based on marketing hype or the security teams lusts for cool tech rather than what reduces the risk the most for the dollars available.
The option triggered the implementation of a dm-crypt layer between the physical device and the upper storage layers. Crypto keys were stored in the storage system. Once revoked, the whole server was rendered useless (from a data thief point of view).
We benchmarked the stuff a bit. Indeed, there was a loss. While dm-crypt uses AES (with hardware acceleration) and since we had multi-hundreds of thousands IOPS per device, we did not care.
>In web applications and cloud services drives could still be misplaced, stolen, or improperly disposed of.
This is explicitly called out in the article by the author, despite it not being part of the threat model the author is examining. And people are still bringing it up like some sort of gotcha.
See (again):
>This is not a comprehensive blog post covering every possible use case or threat model relating to encryption at rest.
Regardless, even in their very restrictive scenario, it provides defense in depth as I said.
Loss of control of the hard disks may have many different ways it can manifest in the real world, but from a cryptography and software development perspective, is congruent to other flavors of the same underlying problem.
That's not being "restrictive", it's recognizing the common denominator.
It doesn't need in-depth discussion, and the way data is still highly exposed despite disk encryption is very important, but that implication is not great.