5 ms·
That's impractical for the vast majority of use cases. The performance costs would be enormous, turning millisecond response times into seconds in many cases.
by idontpost 8y ago
That's impractical for the vast majority of use cases. The performance costs would be enormous, turning millisecond response times into seconds in many cases.
- LinuxBender 8y agoFor existing database design for many, sure. This requires rethinking how you access your data and changing the architecture and data flows accordingly. I am not in any way suggesting it would be trivial for existing applications to suddenly do this. It requires forethought.
- v_lisivka 8y agoThey store unencrypted data in memory instead of hard drive. From security perspective: nothing changed, so their access times may be even faster than with traditional approach.
- LinuxBender 8y agoActually it means that you must be able to access memory when the server is running. Still possible, but much more difficult and requires gaining root on the server while it is running and has decrypted the data, or finding some RCE that allows direct access to this memory. We have numerous pen testers and code reviewers that look for and test for such things all the time. This also means evading various monitoring tools that security and network operations centers are watching. Again, still possible, but much more difficult. This also means, disks walking away are always encrypted. We physically shred all of our disks, but humans can make mistakes.
- idontpost 8y agoYou're assuming that all your unencrypted data fits in memory. For most of us, that's not the case.