Difference between revisions of "Securing OpenEMR"
From OpenEMR Project Wiki
Bradymiller (talk | contribs) |
Bradymiller (talk | contribs) (→Apache) |
||
Line 42: | Line 42: | ||
:*sites/*/edi | :*sites/*/edi | ||
*If not using portal and want to allow users to access over the internet, then consider using client-sided certificates to only allow users access to site | *If not using portal and want to allow users to access over the internet, then consider using client-sided certificates to only allow users access to site | ||
*If want to give access to the patient | *If using third party patient portal, then use the current method whereby your instance is not on the internet and connects to the third party patient portal via vpn. | ||
*If want to give access to the onsite patient portal over the internet, then consider using a client-sided certificate to only allow users access to the main OpenEMR login page (this is not optimal, though). | |||
==MySQL== | ==MySQL== |
Revision as of 17:54, 20 February 2014
Securing OpenEMR
Overview
- With the advent of the Patient Portals, the community is now addressing the issues of how to best secure OpenEMR instances that are open to the web. Doing this requires a firm understanding of securing several parts, which at least include OpenEMR itself, Apache, MySQL, PHP, firewall, router, https, certficates, etc. A forum that began to discuss this issue can be found here.
- There is also a very nice write up on Security Assessment for EMRs (especially regarding HIPAA compliance) on the OEMR Organization wiki.
- This document is still just a work in progress; hopefully as members of the community begin securing their OpenEMR instances for the web, they will place things they learned here in order to help others.
OpenEMR
- For OpenEMR versions 4.1.1 or less, then remove the following file and directory, if they exist:
- FILE: library/openflashchart/php-ofc-library/ofc_upload_image.php
- DIRECTORY: library/openflashchart/tmp-upload-images/
- After installation/upgrade consider removing(or ensuring no access to) to the following scripts, which are not needed for general OpenEMR use:
- acl_setup.php
- acl_upgrade.php
- admin.php
- sl_convert.php
- setup.php
- sql_upgrade.php
- gacl/setup.php
- ippf_upgrade.php
- entire contrib directory
- (except for the contrib/icd9, contrib/icd10, contrib/snomed and contrib/rxnorm directories)
- entire phpmyadmin directory
- This is a rather controversial recommendation(some users rely on this tool). If you need to maximize security, then should consider removing this.
- After installing a patch consider removing (or ensuring no access to) the following script, which is not needed for general OpenEMR use:
- sql_patch.php
- Passwords
- Enforce strong/unique passwords, which can be set in Administration->Globals->Security.
- Enforce password expiration, which can be set in Administration->Globals->Security.
Network
- On server, consider only opening port 443 (https).
- Consider a firewall that only allows port 443 (https) traffic to the server.
Apache
- General hardening of Apache, which is described here.
- Only allow https (ie. turn off http)
- Do not allow direct web access to the following directories
- sites/*/documents
- sites/*/era
- sites/*/edi
- If not using portal and want to allow users to access over the internet, then consider using client-sided certificates to only allow users access to site
- If using third party patient portal, then use the current method whereby your instance is not on the internet and connects to the third party patient portal via vpn.
- If want to give access to the onsite patient portal over the internet, then consider using a client-sided certificate to only allow users access to the main OpenEMR login page (this is not optimal, though).
MySQL
- Ensure the root password is set to something.
PHP
- Follow the OpenEMR php settings recommendations
XAMPP
- If you are using XAMPP, note that this software is extremely unsecure after installation and you need to secure it (See the XAMPP security instructions to secure your XAMPP installation.).
Codebase
- Ongoing project to prevent sql-injection and cross-scripting attacks.
- Consider adding a specific sqlconf.php override settings when using the patient portal (especially the onsite portal), which can be used to use a separate mysql user (and possibly database).
Security Assessment
- A security risk assessment is a requirement in the US for compliance with HIPAA and Meaningful Use. There is a very nice write up on this topic on the Security Assessment wiki page on the OEMR organization wiki.