Situation
Hi i would like to ask any advice on how we could encrypt the patient record in the database? I just review the patient-data table and all the PI for the patient are just exposed. We already implemented an SSL in the apache, but its only for encryption in transit. It’s also good to have an encryption at rest in the database, Just in case the database is compromise.
OpenEMR Version
I’m using OpenEMR version
Browser:
I’m using:
Operating System
I’m using:
Search
Did you search the forum for similar questions?
Logs
Did you check the logs?
Was there anything pertinent in them?
Please paste them here (surround with three backticks (```) for readability.
You can also turn on User Debugging under Administration->Globals->Logging User Debugging Options=>All
You should only open HTTPS to the world if necessary (you can restrict https to trusted IPs as well if there is no need to be opned to the world). All other ports should be restricted to trusted IPs
Hi @moussa We already done all necessary security for data in-transit and we are also in a contain environment, What we are looking at is having another layer of security by implementing encryption at rest in the database since all PI are just exposed in the database.
There are arguments to both sides of this. Full encryption at rest has its merits.
However, consider this, what if you need to solve a problem or correct an error at the database level? Now everything you do administratively must also run through decryption/encryption in order to function.
How about reporting? Or 3rd party interfaces like Laboratories, HIEs, imaging/diagnostiscs, all that data flow now has to be routed through the encryption layer.
Not saying it can’t be done, just saying there are a lot of factors to consider.
It’s possible to easily render a production environment useless in the quest for ultimate security, conversely, it’s also possible to lose a production environment due to lack of security. Working software is always a compromise between security and functionality.
I’ve worked on healthcare systems where the PHI fields are encrypted inside the database. Unfortunately it’d be a big stretch to implement it into OpenEMR at the application layer since it wasn’t designed with that purpose from the beginning. There are lots and lots of entry points into the patient_data table for example throughout the code.
If you do this at the application layer one approach would be that you’d need to consolidate all uses of the PHI into the Data Access service classes in the src/Service tables. In order to deal with searching you’d have to look at doing some form of bloom index filters to handle encrypted search so you could have performant search w/o leaking heuristic data that could recreate the PHI. I built something similar for this using this php library: GitHub - paragonie/ciphersweet: Fast, searchable field-level encryption for PHP projects
Its not a drop in and you have to really understand your data set to accomplish this, all of which makes it hard to implement for OpenEMR.
If you’re threat model is to prevent users logging in directly into the database from seeing the PHI or a rogue person getting a dump of the database, you could conceivably do this at the database layer using session variables, authenticated users and triggers to encrypt / decrypt the data. Application Layer would have to manage the key, or use something like Hashicorp or AWS KMS for key management. The application would have seamless access to the unencrypted data, but any direct db access would be protected. It would have issues though as you still have to solve the search problem and reporting issues that @Penguin8R brings up.
If you are more concerned about database, explore native capabilities provided different engines.. It brings in its own set of complications but it will be transparent to an application such as emr.
Just an FYI - Ubuntu’s encrypted disc capability is transparent to OpenEMR, it works with RAID config’s, it doesn’t impact performance and it offers some peace of mind knowing that if your server is physically stolen the disc cannot be accessed without the passphrase. Implementation must be accomplished during O/S installation and once booted the disc is technically running “unencrypted” to authorized users. I must caution everyone that the implications of running both OpenEMR’s internal file encryption option and the O/S disc encryption are unknown to me.
For what it’s worth, mileage may vary of course, but there have been quite a few servers running OpenEMR for many years, going all the way back to starting with Version 4.x, using Ubuntu with LUKS encrypted file systems. This does comply with “at rest” data encryption, but as pointed out above, once the system is booted & running, all the data is available.
However, it does solve the problem of someone removing a hard drive or stealing a physical server and then attempting to break into the data storage at their leisure after a hardware theft. From what I can tell, it’s never had any impact on performance, just means that you need to carry out a couple of extra steps after a system reboot or power outage event.