Moving to the cloud is easy, but remaining compliant in the cloud is another matter. When you move to the cloud you're handing over control of your data to a third party. When data is not under your direct control, it can be tough to ensure that the way it is handled meets security compliance regulatory requirements.
Which regulatory requirements do you have to worry about in the cloud? The simple answer is the same ones that apply to you already. That's most likely to be one or more of:
- Sarbanes Oxley Act (SOX)
- Health Insurance Portability and Accountability Act (HIPAA)
- Payment Card Industry Data Security Standard (PCI- DSS)
- Federal Information Security Management Act (FISMA)
- Gramm-Leach-Bliley Act
- European Union Data Protection Directive
One piece of good news: Many of the regulations have overlapping requirements relating to cloud security and privacy, so general best practices can help. Here are four widely applicable tips for avoiding compliance problems in the cloud:
Minimize Your Scope
If you run your IT operations in-house, your environment will be isolated from those of other organizations - physically, organizationally and administratively. That's obviously not the case when you use a cloud service provider. This is a potential problem. Unless the cloud service provider's infrastructure is segmented so that your cloud environment is isolated from other customers' in a way equivalent to physical network separation, other customers' environments could fall within the scope of your regulatory responsibilities.https://o1.qnsr.com/log/p.gif?;n=203;c=204660766;s=9477;x=7936;f=201812281312070;u=j;z=TIMESTAMP;a=20392931;e=i
The PCI Security Standards Council suggests three ways of avoiding scoping issues that nay be found in shared cloud environments:
- Traditional Application Service Provider (ASP) model where physically separate servers are provided for each client's environment
- Virtualized servers that are individually dedicated to a particular client, including any virtualized disks such as SAN, NAS or virtual database servers
- Environments where clients run their applications in separate logical partitions using separate database management system images and do not share disk storage or other resources
Nail Down Where Data Will Be Stored
Regulations such as the European Union Data Protection Directive place restrictions on where certain types of data can be stored and processed geographically. For example, it requires personal data to remain within the borders of the EU or a third-party country which offers adequate protection.
That can obviously be a big problem if a cloud provider operates data centers around the world and stores your data in multiple locations. The good news is that all reputable cloud service providers are aware of the problem and offer geographical nodes that customers can select for their data to reside in.
The key thing, then, is to read the fine print to ensure that all your data stays in those geographical areas. Secondary copies, archive copies or other copies made by the service provider for redundancy, speed or other purposes, or to be stored with subcontractors, should never leave those areas.
Realize a Compliant Provider Won't Make You Compliant
Regulations may require that any cloud service provider you use is certified to be compliant with those regulations. But that doesn't mean using one also makes you compliant automatically. You still have to use the service in a compliant manner; it is your responsibility to ensure the provider maintains regulatory controls on an ongoing basis. And you still have to maintain compliance for your own IT operations which connect to the cloud service provider.
Where a cloud service is certified or validated for a given set of regulations, that doesn't mean that your environment in that cloud service will be compliant. As an example of how this can happen, the PCI Security Standards Council points out that validation may have included use of up-to-date anti-virus software on the cloud service provider's systems. However, this validation might not extend to the individual client operating systems or virtual machines.
If you use a service that is offered as "compliant," the council recommends that you get a clear and unambiguous explanation, supported by appropriate evidence, of which aspects of the service have been validated as compliant and which have not.
Get It in Writing
Service level agreements (SLAs) tend to be treated as boilerplate documents which spell out what you can expect to get for your money from your cloud service provider in terms of uptime or availability and support.
But compliance is a vital issue, with severe penalties for breaching regulations, so it's sensible to ensure that the cloud service provider knows exactly what you require of it to stay in compliance. The best way to do this is to specify your requirements in a written SLA and also spell out how you expect the service provider to meet them.
Relating to the first three points mentioned above, the SLA should make clear how the cloud service provider will ensure that your environment is segmented from other customers', and where your data can (and can't) be geographically located.
When it comes to cloud security, including these sorts of terms may not just be a good idea - they may be the law. That's because HIPAA regulations, for example, dictate that any subcontractors that you use - such as a cloud service provider - must have a clause in their contracts which says that they will use reasonable security controls and also comply with any data privacy provisions.
It's important to remember that having it in writing doesn't automatically guarantee that a cloud service provider will comply with the SLA, so it is still ultimately your responsibility to ensure that it does. But having it in writing makes it much easier to put pressure on a cloud service provider if you believe it is not doing what it has agreed to.
Paul Rubens has been covering enterprise technology for over 20 years. In that time he has written for leading UK and international publications including The Economist, The Times, Financial Times, the BBC, Computing and ServerWatch.