Is moving regulated content to the cloud really an issue?
I’ve worked in product management of enterprise software for about 10 years now including heading up the EMC Records Management group for a while so when we started looking at the security implications of moving our systems to a cloud delivery model I was skeptical to say the least. Why? Because a move to the cloud surely means that you are putting your company’s assets out where any decently equipped hacker can access them without breaking a sweat...doesn’t it?
As we worked through the choices of cloud architectures it became apparent that actually a move to the right cloud-based system with a cooperative vendor could actually reduce your compliance exposure. Don’t believe me? Read on.
We have to start by separating cloud solutions by “available connection points”. That is, what is your cloud solution connected to? The public internet or directly into your secure corporate network? It is important that you understand this differentiation because it will have a huge impact on your risk profile after deployment.
Comparing Public and Private Cloud Solutions
- A public cloud solution is plumbed directly into the public internet; typically anyone can go to www.SomeCloudURL.com and access the cloud solution. This makes it ideal if you want public access but remember that this means that although your target audience can easily access the systems, so can those hacking miscreants.
- A private cloud does not have a public address; it is plumbed directly into your existing corporate network via a secure connection, (VPN for example). Only people inside your corporate network can get to those services.
Moving to a Public Cloud Solution
I am not going to say that a move to a public cloud-based solution will never work for content that you need to protect but I will say that your considerations to protect the data will be far more arduous. You will have to assume that undesirable types absolutely will get into the system and you should build your protection based on that premise.
I am actually not going to pretend to be an expert in enforcing this level of security, instead I am going to focus in on the approach that we took which is to remove the public access point and deploy solutions as a private cloud. This works well for enterprise systems that are typically used by internal people or integrated into existing internal systems.
Moving to a Private Cloud Solution
If your cloud service provider connects your instance of the solution directly, point-to-point, to your data center using a dedicated, secure connection then you have a cloud solution that is effectively just an extension of your existing data center, your current security model and your internal network. If the provider is flexible and will work with you on the connection, security, monitoring, authentication, etc. then the polices that you already have in place for protecting data, authenticating access, regulating the distribution of content etc. can often be used as-is. You get the benefits of the cloud delivery without giving up security.
In fact, the only significant thing that really changes when you move to a private cloud based solution is where the content is being stored. If you work for a large company then you already have data being stored in many locations – backups, remote servers, laptops, smart devices, etc. At least with a decent private cloud provider you will know where it is.
When you position it like this the move to an off-premise deployment does not seem quite as scary. In fact, if your service provider can illustrate how the content is protected from unauthorized access and you are ok with the location of their storage/backup then the move could easily enhance your compliance.
Access to protected customer data.
I’m calling this out as a specific topic because it is a recurring concern especially in some regions. As an example let me paraphrase HIPPA, you “must make reasonable efforts to disclose, only the minimum amount of health information needed to accomplish the intended purpose”. We translate this to say that only authorized people should have access to the health information and that they should only get to see what they need to see.
If your system can be accessed by administrators from your cloud service provider then you need to ensure that those admins have only the appropriate level of access to that health information. What is an appropriate level of access for them? None would seem like a good level. So you need to ensure that (1) the system admins cannot access the data and (2) if they do then you are notified of the breach.
Before you start to panic take a look at the sentence above,”If your system can be accessed by administrators from your cloud service provider…” and now replace “cloud service provider” with “internal IT department”. HIPPA doesn’t say that it is OK for your own internal IT department to see my medical data. Your HIPAA compliant application must already know how to protect data from your admins; it must be providing security and encryption levels to protect data from your own admins. You simply need to ensure that same protection is extended to the service provider.
You may need to ask your service provider to show you their processes to see how they will audit any attempts to bypass the application’s security but as long as the application can enforce the regulation then the move to the cloud should neither add to nor remove any of these controls.
So that’s it?
Pretty much, as usual the devil is in the details but remember that a move to the cloud is never going to solve any of your compliance issues, just like upgrading your hardware or network switch isn’t going to. Your compliance challenges will typically be solved by the application and your processes not the location of the servers.