Due to new laws in my country, any personal information must to be stored encrypted in the database. So, to be able to perform querys over this data I was thinking to keep an in-memory copy of these tables with decrypted data.
For example, to get everyone that are more than 18 years old will be very hard if the DateOfBirth column is encrypted.
I'm using aspnet.core on a linux machine.
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. That would need to be encrypted, too.
Is swap encrypted? If it's not, then any of your cache that gets swapped may break compliance. At the very least, it opens the door to a lot of explaining why it's not a problem.
Not to mention storing all that cache creates new problems for your app: memory pressure, cache coherence, and scalability among them. New devs on the project need to be told to use the cache-search object, and not instinctively write direct database queries. Is it just DoB? How many other columns in other tables need the same? Really, you're better off finding a way to make the database do the work.
AES-NI instructions in modern CPUs make short work of encrypting and decrypting data. Try to copy a file over the network with scp -o Compression=no and you'll likely see it copy over at wire speed, thanks to AES-NI. Encryption simply isn't the bottleneck it used to be. The database can use those instructions to decrypt the index and the data page-by-page, not row-by-row.
If the application has to fetch and decrypt each and every row to find all the records with age >= 18, then you may as well cache it as you'll be pulling the whole table into memory with every query anyway.
Leveraging the encryption features of modern databases makes it easier to be compliant with less overhead.
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 assessment, since there is a vulnerability (keep the data unencrypted in memory), you need to identify if there is a threat to the data, that may determine if there is a risk or not, once you know that, you may assess the likelyhood of the risk to occur and the impact should it occur.
The results may let you decide how long may the decrypted data be and stay in decrypted status in memory.
