by Jacob Beasley, Director of DevOps
Every organization working with data related to the healthcare industry in the United States knows that they need to be compliant with HIPAA regulations. HIPAA, short for the Health Insurance Portability and Accountability Act of 1996, is a set of regulations passed by congress in order to ensure that personal healthcare information (PHI) and electronic personal healthcare information (ePHI) remains private and confidential. It covers the storage, sharing, and access of healthcare-related data of any kind by any company.
In this article, we will talk about some of the challenges of as well as technical solutions to achieving HIPAA compliance when deploying software on various cloud providers. We will center most heavily on Microsoft Azure, but the advice we give is also relevant to Oracle Cloud Infrastructure (OCI), Google Cloud (GCP), Amazon Web Services (AWS), and other cloud providers. HIPAA regulations are some of the most strict technical recommendations, so the advice here will easily apply to other industries, such as banking, point of sale, or education compliance.
This article will not dwell deeply on the legal standard of compliance. This article is not a legal guide for your company and we recommend you consult with lawyers and compliance experts before declaring yourselves compliant. Instead, this article is meant to inform a technical audience of what kinds of approaches and tools are available to enhance compliance when deploying in the cloud. If you have deeper questions about HIPAA compliance in 2020, we recommend you read this article from HIPAAJournal.com.
Also, it is worth noting that compliance is bigger than tech – this article purely focused on the technical challenges of achieving compliance. Your organization will also have to talk through the business processes required to achieve compliance as well as the relevant certification/auditing processes which you may need to employ.
Common Challenges
There are many challenges you must address when implementing HIPAA compliance. Below, we will speak to several of the most common challenges.
Access Controls
No one should be allowed to access any electronic Protected Health Information (ePHI) without first authenticating and determining that they have been granted access to this data. This means that all aspects of infrastructure that might contain ePHI – from servers to logs to load balancers to databases – must be secured.
Audit Logs and Audit Controls
It should be possible to log and report on all ePHI access attempts, both successful and failed. These audit logs should be retained and should be audit-able to determine if a HIPAA violation has taken place, such as someone misusing their access to view information without a legal reason.
Storage of Files and Structured Data (SQL)
Many healthcare information systems store data files which contain ePHI. X-Rays, CT Scans, and scanned paperwork all fall into this category. These must be encrypted when sent over a network and access controls must be in place to prevent unauthorized access. Audit logs must track access and attempted access. Access to structured data stored in SQL databases must similarly be locked down with appropriate access controls and audit logs.
Encrypting Data In-Transit
Messages and data sent beyond a server must be encrypted so as not to send/receive ePHI unencrypted over an open network connection in a way that could be intercepted. This is really a form of access control.
Encrypting Data At-Rest
HIPAA does not require encryption at rest, but it is relevant for many other forms of compliance. Encryption at-rest protects data from outside users who gain access to the physical hardware by encrypting it. This may occur in the case of improper disposal or theft.
Technical Solutions
While these challenges may seem daunting, cloud service providers have many tools to make some of them easier. However, there is no silver bullet; if you are a SaaS company creating HIPAA-compliant software, you will need to instrument some of these things, such as access controls and audit logs, within your own software.
Access Controls
While it may be clear that your software will have to implement access controls, it may be less clear that the underlying infrastructure will also need access controls. This will ensure that users are individually granted access to infrastructure. There are a number of options available to implement access controls, including:
- Active Directory Integration – Servers in Microsoft Azure have the ability to use Active Directory to login. Active Directory can then be used to control access to servers through the use of Resource Groups.
- VPN and Network Policies – Servers can be made available to only those who are part of a VPN and then access to the VPN can be federated with Active Directory. This ensures servers are only accessible by administrators with infrastructure access.
- Individual Logins Set Up Per-Server – While not ideal, individual logins for each user can be set up for each of your individual Windows or Linux servers or for their underlying infrastructures, such as SQL databases. This is not ideal because if a user ever leaves or their account is compromised, it can be very hard to find and remove their access to everything. It is nonetheless an option so long as each user has individual access.
The simplest and one of the most effective practices is to firewall servers to only be available from within a VPN and to also enable Active Directory integration so that only users with appropriate access can log in and access servers. This creates 2 layers of protection. It also protects against operating system vulnerabilities being exploited by hackers since the servers are firewalled and only accessible if someone has access to the VPN.
Audit Logs and Audit Controls
You will need to write your software in a way that enables audit logs of whenever HIPAA data is accessed and the time of access. These logs will need to be tracked in log files (or SQL tables) that can be backed up and retained for the appropriate period of time.
Furthermore, to ensure audit logs are implemented for server access, underlying operating systems and infrastructure events can be logged in platforms like Azure. You simply need to turn on security logging and auditing features. For more information, see the Microsoft Azure Documentation.
Storage of Files
If you need to secure file storage, there are a few options available to you:
- Your servers could mount shared storage, such as Azure Disk Storage, so that a certain folder is attached to a form of network-attached storage under the hood. The method provides incredibly good performance, backups are easy to setup, and the same storage can be shared by multiple servers. This is popular for running databases and for file storage in which your application needs to store files on disk quickly and securely.
- Your servers could use Microsoft’s APIs to store or read files through Azure Blob Storage (similar to Amazon S3). When using Azure Blob Storage, it is important that you do not expose the files on the internet publicly. Instead, either stream the files through your own servers or generate individual access tokens for users (if you choose to directly link to Azure blob storage).
- Your clients could use Office 365 / OneDrive to share files and Microsoft Active Directory groups could be used to control access. This is likely not an option if you are a software development firm, but if you just occasionally need to share files, this could be a way to securely store and transfer files and to ensure that only those who are allowed to access those files are able to do so.
Storage of Structured Data (SQL Databases)
Services like Microsoft Azure offer managed database solutions for common databases like Oracle, Microsoft SQL Server, MySQL, and PostgreSQL. These come complete with backups, provisioned IOPS, replication, failover, and integration with Microsoft Active Directory. SSL Encryption can be enabled to ensure data is encrypted in transit, and network policies can be setup so that the servers can only be accessed over a virtual private network by approved servers.
Encrypting Data In-Transit
When transmitting data internally, TLS/SSL should be used between your various software services. Services like SQL Server and Azure Blob Storage/Azure Disk support SSL out-of-box if you enable it.
Sometimes applications using APIs like SOAP or REST (or load balancers routing traffic between services) do not support encryption, which can be challenging. In this case, you would need to set up certificates between each caller and receiver in order to validate access controls (public/private key authentication) as well as ensure end-to-end encryption. If this sounds daunting to you, you are not alone. Software deployed on Kubernetes with Istio can make this kind of end-to-end encryption easy to set up by layering on mutual-tls between each of your services, enabling end-to-end encryption and enforcing network policies.
Also, if you are exposing data on the internet, such as on a website, chances are you will need to transfer all data over the public internet using an encrypted SSL (HTTPS) connection. This is fairly easy to do with the Azure Load Balancer service. Each cloud provider supplies a similar load balancer service which can be extremely useful to ensure high availability and enable horizontal scalability. They also automate tasks like provisioning SSL certificates, which can be extremely valuable.
Encrypting Data At-Rest
When provisioning storage disks for databases, virtual machines, file storage, and disk storage, Microsoft Azure and other cloud providers have the option of enabling disk encryption. This can have a slight performance hit, but it also means that if someone is able to steal the hard drive from a cloud data center (which is extremely unlikely), the data will effectively be useless to them because it will be encrypted.
If additional encryption is required, such as if you are storing it in a SQL database, you can encrypt data before storing it in SQL database columns and decrypt when reading it. This will ensure that those accessing it cannot decrypt it without the relevant security certificates.
Avoid Accessing Electronic Personal Health Information (ePHI)
If you are a software vendor working in the electronic personal health information industry but ePHI data is not required in order to fulfill your tasks, then by all means limit which data you collect and store to only components that do not pertain directly to personal health information. For example, if you are a medical billing software platform, it may be possible to genericize the data you are receiving to just summaries and refer clients back to their healthcare providers for details that would constitute ePHI data. In doing so, you may limit your exposure and potential avoid some or all of the requirements to comply completely with HIPAA regulations.
That being said, many of the HIPAA compliance requirements are generally good things to have in any software project, even those that are not required to be HIPAA compliant. You should consider factors such as encryption, access controls, and audit logs regardless of your HIPAA compliance requirements. Be sure to consult with a lawyer familiar with compliance law before drawing any conclusions.
Solving These Challenges with Terraform and Kubernetes
Terraform can be used as a way to automate the configuration of virtual private networks and computing resources within Azure that comply with your security and compliance requirements. This can include provisioning databases, setting up network policies, and creating Kubernetes clusters of virtual machines to run your software.
Ansible is a great tool for orchestrating the configuration of individual virtual machines or configuring services like Kubernetes. It works on the basis of configuration scripts called runbooks which are then applied to infrastructure. Under the hood, these runbooks are just remote SSH/Powershell scripts that configure a machine to match the desired state specified.
Kubernetes can be used as a way to orchestrate software configuration. It allows you to mount persistent volumes, configure your software (including environmental variables), configure security certificates and network policies, automatically scale your software, set up load balancers, perform zero-downtime rolling deployments, and complete other configuration tasks. Best of all, plugins like Istio can be used to enable mutual-TLS between services, layering on encryption and network firewalls between applications not originally designed for such things.
Conclusion
Many organizations working with technology in the healthcare industry need to ensure that they are compliant with the Health Insurance Portability and Accountability Act of 1996. While this can be a good deal of work, we have seen that it is completely achievable when building and deploying software to the cloud.
Do you need help architecting and building compliant technology in the cloud?
If so, reach out to our team! We deliver a full range of DevOps services and solutions that help propel transformative change for our customers. Our range of capabilities includes:
- Software Development
- Site Reliability Engineering
- Build and Support Services
- Secure Software and Systems
- Respond and Support Services
- Compliance and Security Capabilities
If there’s software that needs to be built, secured, or improved, our team can help. Feel free to reach out to us at connectwithu[email protected] or by filling out our brief Contact Us inquiry form if you’re interested in learning more about our DevOps services. We’re confident we can help you build reliable, secure, and powerful software that can truly move the needle for your organization and your customers.