Breaking down what's in your cloud SLA
A comprehensive collection of articles, videos and more, hand-picked by our editors
Internal auditors are endlessly frustrated because every time they nail down compliance and governance methods for an application, changes render their model obsolete. The cloud can be a special source of frustration with governance because it changes the most fundamental of all assumptions in IT: My stuff is running here, under my control. Ensuring that governance methods survive a cloud transition means following three steps:
- Assessing how much you depend on physical security and access
- Evaluating your governance methodologies for cloud's weaknesses
- Making sure your governance changes are final
Assessing your governance, security practices
Many companies rely on control of their physical facilities to frame the critical security and compliance strategies that form the foundation of internal governance. No application-level protection mechanism or encryption strategy will defeat a simple theft of a backup tape or direct meddling with software versions. However, nearly all major cloud providers have very specific certifications for security and compliance -- including ISO and specific ones for financial and health care.
The cloud can be a special source of frustration with governance because it changes the most fundamental of all assumptions in IT: My stuff is running here, under my control.
"Cloudifying" your governance practices means finding out what your proposed provider and other viable competitors offer. It's critical to know whether you have governance practices that are "fragile," or might fall short of regulations in case you switch providers. There are companies that specialize in tracking global compliance requirements, which are a good resource for companies considering all areas in which they may be at risk.
However, understanding your cloud provider's compliance strategies doesn't mean you can forget physical security issues. You must switch your governance policies from testing internal processes to testing your provider's compliance with regulations. To do this, you'll either need legal certifications from them periodically or conduct (or commission) audits of their processes. Do not accept an initial certification check as indication that the provider is maintaining the certifications up-to-date.
Evaluating cloud governance practices for holes
The next issue to address is evaluating your governance processes for cloud-induced weaknesses. Most companies exercise IT governance through their application lifecycle management (ALM) processes, combined with specific tools for application and infrastructure monitoring and control. Migrating to the cloud will nearly always impact both areas, so they can break governance even without breaking compliance regulations.
ALM enforces compliance by enforcing processes to validate application changes and the integrity of the production systems. Deployment in the cloud introduces new variables, including machine image and configuration integrity. Mechanisms for validating these new variables through versioning are different. One of the big issues is ensuring that OS and middleware changes are propagated to all impacted machine images -- something that may be automatic in the data center but must be explicit in the cloud.
Machine images can create problems in cloud governance but they may also be able to carry useful functionality into a place otherwise hard to reach. Any application or component that's loaded with a machine image and provides information about the app and its environment is, in effect, an agent for governance loaded into another data center. Building version testing, status testing and even performance testing into the machine image means that it can be used to provide information on what is running and how.
Using software agent technology to check component versions for installed libraries is fairly common, and it's worthwhile to examine these tools to see if they can validate the machine image versions actually running. This will prevent a versioning problem caused either by your own internal processes -- failing to update a machine image with new middleware releases -- or by a cloud provider falling back to a backup version or running an old image due to a configuration error.
The final "new" governance issue for the cloud is the cloud data services. Cloud providers offer various database/file/block storage options, and of course, data stored in the cloud isn't subject to the same physical security controls as on-premises. A sometimes overlooked truth is that the data may be subject to regulatory oversight simply based on where it's stored, and data access controls in the cloud may be different from controls on-premises because the cloud is accessed via the Internet or VPNs, which are subject to hacking.
The more regulatory oversight your company is subject to, the more you have to be concerned about data jurisdiction issues. Check with your own governance auditors, be sure you know whether there are state or local regulations that could apply to data stored in the cloud, and be sure you know where your cloud provider will store data.
Finalizing your cloud governance strategy
It's all too easy to make your cloud governance strategy provider-specific, rather than cloud-ready overall. Virtually every cloud provider will impact governance differently for different users, so look for areas where cloud introduces a weakness in your practices, formulate a general strategy and policy to address these weaknesses and then specify the application of your strategy to the provider(s) you're using. That way, the broader groundwork of a cloud governance strategy is your baseline, and the provider-specific elements are easier to adjust. With this strategy, introducing a new cloud provider or service won't send you back to the drawing board.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.