The promise of cloud computing is very compelling. Just listen to the pitch for hybrid clouds: “If your organization needs more computing resources, why purchase extra hardware? Just set up a connection to a public cloud, use the extra machines to your heart’s content, and stop using them when your needs are satisfied.”
Sounds nice, doesn’t it? To be sure, the advantages of any type of cloud computing, be it completely private and internal, public and external, or something in-between, are very real. But there’s potentially a big difference between the promise of instantly expanding your company’s infrastructure and the reality of getting your systems and the cloud’s completely and securely talking to each other.
Thinking about this on the network level alone brings up some daunting questions: if your organization is a public company, you can’t just trustingly connect to a public cloud infrastructure. Your company may have procedural and even regulatory security requirements to meet that would prevent such connections.
This is the kind of challenge Lori MacVittie sees organizations facing as they increasingly are drawn to the lure of the cloud. MacVittie, is the Senior Technical Marketing Manager at F5 Networks, an international firm that, among other services, specializes in delivering cloud solutions at the application level.
MacVittie has participated in a number of cloud deployments, both internal and external, and has some definite ideas on a best-practices approach to cloud security and authorization concerns.
“The first thing you have to ask yourself is,” MacVittie explained, “what’s the purpose of the cloud you’re setting up? Why are you building it?”
That high-level question may seem obvious, but really examining it may give you some clues as to what kind of security solution you will need for your cloud deployment. Is the cloud internal (private) or external (public)? What are you deploying? Is it cross-domain? What kind of authorization strategy does your company use now?
This last question, MacVittie emphasized, is a big one. When thinking about the cloud you want to build, she said, think about what kind of security requirements, procedures, and regulations do you already have in place with your internal systems? With that in mind, you should plan for how those security procedures will look when projected to an external or external/internal cloud deployment.
What parts of your existing security and authorization procedures absolutely need to be replicated out on an external set of machines? Virtual or otherwise, the machines on the cloud must be maintained in a way similar to any other machine in your internal network.
This is perhaps the biggest challenge to best-practices thinking that organizations must face. It’s not that public clouds aren’t secure—that’s the biggest myth MacVittie and her peers have to debunk. Public clouds are indeed very secure, but only in the most generic sense. For instance, MacVittie related, Amazon Web Services is fully PCIDSS compliant, but Amazon’s approach to security may not match a given organization’s security and authorization procedures.
Above all, it’s critical to keep all such security controls close.
“You always need to maintain control, especially when identity is concerned,” MacVittie stressed.
The principle applies no matter what kind of authorization system you have in place, be it LDAP, Active Directory, or even data from a human resource database. Whatever your internal authorization scheme, you must find a way to duplicate that authorization so that, to your users and applications, the cloud machine uses exactly the same centralized authorization.
This may mean (if you’re lucky and happen to match the cloud provider’s security protocols) you can plug right into a cloud. But if that best-case scenario does not work, you will need to make sure the provider will work with your security policies. If not, you should find one that will.
Sometimes, depending on the solution you’re trying to deploy, you may need to leverage a custom solution to authorization and security policies, MacVittie said, as no provider may meet your needs. That’s to be expected, but it something that should be considered when planning a cloud deployment.
In general, the “higher” up the stack your authorization policies apply, the easier authorization schemes can be translated to the cloud. Applications, for instance, can carry their own authorization policies with them. But, MacVittie explained, as you move down the stack, such as solutions that depend on network topology, the authorization plan could become more complex.
There are other security aspects to consider, when planning on an external cloud deployment. For instance, you may want to conduct an independent security audit of a cloud provider to make sure they can deliver on their promises. In fact, your own policies may require such an audit.
While you’re at it, find out with whom the cloud provider partners and discover exactly if or how these partners might touch your data. Ideally, not at all, but even cloud providers need support sometimes, and their support vendors may be put into a position to see your data. This may not be a deal breaker, but you will at least need to confirm the provider’s policy if such a situation occurs.
Regulatory requirements don’t just apply to security and authorization issues: data management must also be considered. Where, physically, where your data be stored and what, if any, laws are in place at that location regarding data protection and management? Have your legal team take a look at those rules and be sure they are compatible with your own policies and regulatory requirements. If they are not, this likely is a deal breaker, because you never want to expose your data to incompatible jurisdictions.
Finally, make sure your own house is in order before you start deploying to a cloud. How are your own security procedures working? Do they meet the overall goals of the company’s security needs? That’s on the high level as well as every day use: are your employees complying with the policies you have in place? If they aren’t, find out why. Whether it’s a technological issue or an educational one, it’s important that users are compliant with security internally before they start using cloud-based resources. The strongest security setup in the world is no match for an easily guessable password.
Though MacVittie addressed her comments to the authorization aspects of cloud deployment, there is much to be said for the central concept she highlights: keep as much as possible under your control. This is true for authorization, and it’s applicable to all of these security aspects. If the cloud is going to be effectively part of your IT resources, however briefly, then make sure you have control of as many aspects of the deployment and security process as possible.
The advantages of the cloud are powerful, and taking authorization and security into account as you deploy your solutions will help you find the silver lining faster.
