When you store or process any kind of data in the cloud, you face certain security risks that would not exist in an on-premises environment. However, workloads that involve regulated healthcare data (which is known under the United States Health Insurance Portability and Accountability Act, or HIPAA, as Protected Health Information, or PHI) are especially sensitive, given the highly personal nature of healthcare information and the special compliance rules that govern it. This article offers a primer on cloud native security for healthcare organizations, explaining you need to know about cloud native architectures.
It’s not a comprehensive guide to cloud computing and HIPAA, but it offers a 101-level overview of the main security and compliance risks that healthcare organizations face when deploying cloud native workloads, as well as which architectural strategies can help mitigate those risks.
Most major service providers have safeguards in place that allow healthcare data to be stored on or processed in the cloud without necessarily requiring separate or special hosting arrangements. However, remaining compliant with HIPAA requirements when using the cloud requires addressing certain challenges:
These HIPAA-related compliance and security regulations can certainly be managed, but they require some special consideration that would not be necessary if all healthcare data were stored and processed directly on an organization’s own on-premises infrastructure.
Given the tremendous advantages of the cloud – including its agility, reliability and cost – many healthcare organizations today are less hesitant to run workloads in the cloud. Those that do adopt strategies that help them take full advantage of cloud native computing while protecting sensitive data.
Below is a list of common methods for minimizing security and compliance risks associated with healthcare data in the cloud.
First and foremost, ensure that the cloud platform or platforms you use are designed to be HIPAA-compliant, which means (among other things) that their systems meet HIPAA requirements regarding auditing as well as physical and virtual access control. Finding HIPAA-friendly providers is easy because virtually all major CSPs design their services to be HIPAA-compliant, at least if you adhere to certain guidelines when using them.
That said, don’t simply assume that just because a CSP promises HIPAA compliance, you can upload your data and applications and assume you’re meeting all of your compliance requirements. You must carefully read the CSP’s policies to ensure that the cloud services you intend to use, and the workloads you intend to run on them, meet the CSP’s requirements for PHI.
In general, anonymizing data by stripping it of personally identifiable information turns that data into what HIPAA calls de-identified data. This process frees the healthcare organization from having to comply with most HIPAA rules when using the data.
When possible, then, removing personal information like names and addresses from healthcare data that is stored or processed in the cloud can potentially reduce your HIPAA compliance burden.
Keep in mind, however, that data that you believe to have been anonymized may still contain personally identifiable information. As a result, although de-identification can help reduce your compliance and security risks related to healthcare data in the cloud, you should never assume that it totally eliminates them. It’s a best practice to act as if all healthcare-related data in the cloud is subject to HIPAA requirements, even if you have anonymized it.
The more often data travels across a network, especially the public internet, the more frequently you have to ensure that proper access-control measures are in place. For that reason, a cloud architectural strategy that minimizes the frequency of data transmissions can help simplify HIPAA compliance.
For example, instead of spreading a workload across an on-premises environment and the public cloud, consider keeping all of the workload in one location so that data doesn’t have to be exchanged between the two environments. Or, in situations where you do need to transmit data over the network, consider caching it where possible so that you can avoid having to transmit data that already exists in the cache.
As OWASP (a leading security group in the open source community) points out, encrypting data when it is at rest or in transit is an incredibly important step, but is not enough on its own to protect against unauthorized access. Attackers could take advantage of security flaws within applications that allow them to access the data in decrypted form when it is being processed by the application. For example, an application that doesn’t properly validate data input could be subject to a SQL injection attack that reveals sensitive information.
This category of risk exists with applications, and from a cloud architectural standpoint, you cannot mitigate it entirely. Instead, be sure to scan your application source code (if you can access it) for security vulnerabilities, as well as monitor applications continuously for signs of a breach or attempted breach.
Immutable infrastructure is a strategy wherein applications and infrastructure are never modified while running, but are instead fully replaced with a new instance whenever a change or update is required. Containers and serverless functions use this paradigm by default, but it can be applied to almost any type of workload or technology.
In addition to being a general best practice and safeguard against the risk that the modification of a running application or server creates an unknown security vulnerability, immutable infrastructure helps to decouple PHI from the infrastructure that hosts it. If your applications and servers are destroyed and replaced each time they are updated, your developers can’t decide to store PHI inside those applications or servers. Instead, they’ll be forced to store it in a centralized location, where securing and auditing it will likely be easier.
Most healthcare organizations will need to retain PHI for a relatively long period of time. HIPAA itself doesn’t impose a requirement on data retention for medical records (it does mandate retention periods for other types of data, mostly related to HIPAA compliance operations), but state governments do have mandatory retention rules for healthcare records.
If you choose to store this data in the cloud – which you may if, for example, you wish to take advantage of the low cost of archival cloud storage services – you can mitigate your security and compliance risks by “air gapping” the data. In a general sense, air gapping means ensuring that air-gapped data is not connected to production environments and can be accessed only by using special tools or procedures. (In the narrowest sense, air-gapped data means data that is not connected to a network in any way, but that level of air-gapping is not possible in the cloud.)
If you use the cloud to archive PHI, then, you should ensure that the storage buckets you use to hold it are fully encrypted, that no applications have access to the archival data, and that the archival data is not mixed in with more recent data. These strategies don’t guarantee that unauthorized users can’t access the data, but they will help provide a high level of protection for data that is stored in the cloud for a long period.
Despite the security and compliance challenges related to healthcare workloads in the cloud, the risks can be effectively managed through the right cloud architectural strategies. Meeting them is well worth the effort in order to take advantage of the benefits that cloud native architectures offer.
For more information on the cloud and workload security concepts discussed above, check out a few of our other blogs:
By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement. Please look for a confirmation email from us. If you don't receive it in the next 10 minutes, please check your spam folder.