Control and Security
It is easy to underestimate the consequences of the ease with which resources will be deployed in the cloud when it becomes available to your organization. You can compare it to the time when virtualization was introduced. We expected it to deliver a greater utilization of existing hardware but because it became so much easier to deploy an instance it instead led to an explosion in virtual servers (and subsequently more hardware).
Prevent that resources are deployed manually and/or improperly labeled.
Staying with virtualization as a simile for cloud: as a result we did not bring total cost down by virtualization but we did lower the cost per instance. However, and this should also have your head nodding in recognition, it resulted in a chaotic landscape of virtual instances and a not so up-to-date configuration database. Maintaining an up-to-date CMDB in any IT environment has time and again proven to be very difficult. Cloud services will make it impossible to have an accurate central database.
So, problems then? Yes! Because from a governance standpoint we want to ensure that IT budget and resources are well spent and that we do not run any undue risk. The aim is to prevent that resources are deployed manually and/or improperly labeled.
So, how do we compel cloud users to adhere to strict deployment and tagging policies?
In what should be a familiar theme by now, we will fix it with automation. Automated deployments, automated configurations [Configuration and Asset Management] and some really sweet tagging policies. We use tags to label instances. Tags will be used extensively and with good reason. Use them to allocate cost, register support contact(s), data privacy sensitivity, application security sensitivity, etc., etc.. Tags are also indispensable when it comes to operational management tasks. For instance; finding databases with a certain version so they can be patched will be a cinch.
To come back to our governance processes: we have to communicate. Communicate why we care about this process and how we perform it. Report on the effectiveness of our automation and labeling. How accurate our knowledge is of our assets and configuration items. And, if we are successful in allocating cost and detecting compliance and security risks.
Here are some more tips.
Focus on Acceptance and Production environments as opposed to complete DTAP.
Routinely compare different sources of configuration and asset information to find discrepancies. This is a means to improve the data and the process.
Scripts, forms or whatever shape deployment requests have in your organization, should take into account important information such as:
- Application (application nr. and/or name)
- Application role (OTAP)
- Part of cluster
- Software versions
- Application owner
- Cost code (Project, dept, or unit to allocate cost to)
- Deployment requester
- CIA classification
*Plenty of organizations do not employ charge-back or show-back to allocate IT cost to business units or service chains. IT spend is just a lump sum cost on the overall budget of the organization. There’s little incentive there to make the considerable effort of administrating assets and items. However, there are not a lot of organizations that do not care about IT cost, efficiency, regulatory compliance, etc.. It’s just that there is little understanding of the relation between them. Extra effort is required to make sure this a priority when going cloud
Process or Activity
Demarcation of Responsibilities
Configuration and Asset Management responsibilities stay in place.
CCoE is responsible for tagging implementation and monitoring compliance on tag use.
CCoE creates reports and/or dashboard for process management.
To Do List
Limit Configuration Management scope to only Acceptance and Production systems.
Plan periodic exception reporting based on contrasts in overlapping data sets.