UK healthcare encryption obligations

Question

I'll soon be working on upgrading a system which contains a MYSQL server and redis server on AWS

It works by querying two entire tables decrypting all of the contents and then putting the result in redis, the application then queries redis from then on to retrieve results.

The problem is everytime we clear redis all our sites grind to a halt as maybe as much as 20 separate things per user, per site are decrypted at runtime in PHP, some of these things are not even things we're that concerned about from a data privacy point of view like whether they are "active" or not, but some definitely feel like they are address, and some it's hard to figure out like their name

Because the other problem we have with this setup is that we cannot query our users or sort our users by name in SQL we have to start doing that by "querying" redis and then doing SQL like operations in PHP and it can get really ugly performance wise.

I've been looking at mariaDB's encryption at rest feature it would drastically sort out some of our architecture problems from an ease of use and performance point of view, if encryption was transparent in the database, but on the other hand it would be less secure than application level encryption

My question is what obilgations do we have as a company in the UK when it comes to encryption of healthcare related data and is my idea of encryption at rest enough? Are there some specific things about patients that definitely need to be encrypted? (Maybe we could do a hybrid approach?)

Is there a third approach I haven't thought about?

Answer 1

I'll start by saying I'm not a lawyer, and its been a long time since I worked in Healthcare....

I am not aware of any legal constraints beyond the DPA and GDPR. However it is not unusual for health boards to have their own requirements independent of the legislation. Depending on the usage you may also be subject to the HSCIC rules - Amazon have a doc about this. A requirement of the latter is that you trained in the use and application of the policy.

It works by querying two entire tables decrypting all of the contents and then putting the result in redis

This makes me think that someone has not understood the requirement nor the impact of applying encryption. Since you've written the cleartext outside the encryption, then there is no benefit to the encryption. I suspect that the reason for writing the cleartext outside the encryption is in order to query the data. I'm not surprised that this has an impact on the service as a whole. That is does have a detriment to the service and no benefit implies a net detriment and hence the encryption is actually worse than useless. Presumably someone just heard "encryption" and thought it was more secure. It doesn't matter all that much that Redis is "in memory".

If this was on a platform where you could guarantee the integrity of the memory, then it would be trivial to configure 2 instances of MySQL - one running off zram and one off disk, then replicating between them to make sure you always had an up to date, unencrypted copy which wasn't written to disk without having to rely on batch copying and the constraints of a noSQL database.

There's little effective difference between using transparent encryption implemented by the DBMS and encryption on the block device (e.g. dmcrypt, luks) or at the filesystem tier. There are operational differences about who controls the keys - which may be an important consideration). There is a difference with Mariadb encryption in that it can be specified at the table or tablespace level without having to split tables/tablespaces across different filesystems. MariaDB also supports the AWS key store.

As it stands, IMHO, using any of these transparent encryption methods and not copying the cleartext to redis would give you a faster and more secure solution.