By Jamie Brenzel, CEO, KineticD
Choosing the right cloud flavor for your customer and avoiding cutting common security corners are keys to successful cloud rollouts.
When it comes to the security risks VARs need to be aware of when selling public cloud services, the first step a VAR needs to take is performing due diligence on its cloud service provider’s datacenter operation. For example, a VAR should ask for a SAS (statement on auditing standards) 70 or SSAE (statements on standards for attestation engagements) 16 audit to take a closer look at how the cloud provider maintains uptime and to make sure malignant users cannot access the database. Additionally, the VAR must ensure its customer’s application-level security through proper encryption:
They also should ask what encryption algorithm is being used. These days, 256-bit AES (advanced encryption standard) should be the absolute minimum, and 448-bit Blowfish is what large banks prefer. Last but not least, VAR due diligence prior to selling cloud services should include identifying a master key. For example, is there a contact at the cloud provider who could access all customer data in the database?
The less obvious, but more interesting, issue for a VAR is “access to the application,” where the same security rules apply for internal applications as they do for cloud applications (i.e. SaaS). If all users of the application use the same administrator account with a generic password (e.g. “password1”), all the safeguards discussed above become useless. Therefore, it is critical that the cloud service provider supports granular access rights based on user roles. As long as the cloud service provider provides that functionality, a VAR can provide implementation services that add a layer of security on top of what the product includes right out of the box.
If the cloud service provider did their part in securing the infrastructure and application, then the VAR can focus on implementing clear user roles with granular access rights. This is probably the most critical security element of any cloud service VARs can implement. A VAR can further augment user role security by building in a three-factor authentication process, such as a physical or digital token.
However, a token might not provide a sufficient level of security for highly regulated industries. For these industries, a private key solution might be required. Some cloud service providers, like a few cloud backup services I know, will support the option of a private encryption key for larger customers.
Private Vs. Public Cloud
Private clouds are only necessary for tightly regulated industries and other high security operations. However, they come at a heavy cost when compared with public clouds. With the high complexity and cost involved in setting up and maintaining a private cloud, only large enterprises or government entities should entertain the option of undertaking a private cloud.
There are interesting compromises on the horizon in which a company can buy into a dedicated private cloud provider like dinCloud. Under this model, the cloud provider operates a dedicated infrastructure for the end customer, and the end user doesn’t have to worry about the risks normally associated with a multitenant offering.
Ultimately, hybrid clouds make the most sense in the cloud backup space, not necessarily because of security concerns, but because of recovery time objectives (RTOs). Maintaining your data on-site will allow you to recover it more quickly than having to go over the wire.
An often forgotten step in analyzing a cloud service’s security level is determining the types of APIs (application programming interfaces) it supports. APIs are a critical part of making cloud service interoperable, either between each other (e.g. Salesforce.com combined with a marketing automation application) or with internal applications. Because API interoperability level is a less visible part of a cloud service, providers are more likely to cut corners in this area. VARs should ensure that the APIs are as secure as the rest of the cloud service.