3

The short answer is: Just don't. The long answer is: It depends on the rest of the system. As ram0nvaldez said, you have to decrypt the data to work with it. Some level of decrypted in-memory is necessary. But! Are you storing your cached DoB data in a Redis cache? Redis writes its cache data out to disk on a regular basis to facilitate fast restarts. ...


2

I'm continuing the theme of @schoeder's questions and answering the questions that you didn't ask. First though let's answer your questions. You don't want to sign records. You want to figure out who is responsible for the manual edits to your database. The most direct answer to your question is that you want an audit trail. Many databases have ...


1

You cannot protect the database from the users who have full permissions on the database. Your suggested approaches all point to the same thing: an external system (obfuscated (hashed) data, blockchain, CAs) where the local admins don't have permissions. And there's your clue. The only way is to protect the data is to get it or get the integrity controls ...


1

In any case, all data will be unencrypted to be processed, once finished the processing will be encrypted again in storage. The regulations mainly have to do with storage, so you are good. Remember there is no way to not decrypt the data to make computations. To decide how long or in what circumstances keep the data unencrypted, you may need a risk ...


1

I can see a couple downsides: Remote access This is the most basic one. If the attacker gets the credentials for any user of the database, it will have remote access. Not as improbable as you think. Remember that config.php.bak, vars.php.old, and so on, that someone left over? Guess what happens when the attacker uses dirbuster and grabs those... ...


Only top voted, non community-wiki answers of a minimum length are eligible