云服务迁移后 千万别让治理方法死亡

内部审计员的挫败感永无止境，因为每次他们为应用确定了法规遵从和治理方法，新的变化趋势却显示他们的模型过时了。云就是治理挫败感的一个特殊源头，因为云改变了IT中所有假设的基础架构中的大多数内容：我的资源都在这里运行，在我的控制之下。要确保治理方法能够在云过渡的过程中活下来，要遵从下面三个步骤：

1、评估企业对于物理安全和访问的依赖性有多大

2、针对云劣势评估治理方法

3、确保治理变更是最后想要的结果

评估治理和安全实践

很多企业依赖于物理设施上的控制，构架关键的安全和法规遵从战略，这也形成了内部治理的基础。没有应用级别的保护机制或者加密战略可以击败一个简单的备份磁带盗窃或者直接乱动软件版本。然而，差不多所有主要的云提供商对于安全和法规遵从都有非常详细的认证，包括ISO和针对金融和医药保健的具体法规。

“云化”你的治理实践意味着找出提议的提供商和其他可行的竞争对手。万一你转换提供商，了解你是否有脆弱治理实践很重要，或者可能缺乏规则。有些企业专门追踪全球的法规遵从需求，对于那些考虑各个领域可能涉及的风险的企业而言，这会是非常有用的资源。

然而，立即你的云提供商法规遵从战略并不意味着你要忘记物理安全问题。你必须变换治理策略，从测试内部流程到测试你的提供商的法规遵从。为了实现这个，你需要定期的法律认证和流程的审计管理。不要接受最初的认证检查作为一个提供商的标准，因为提供商应该维护认证的不断更新。

为漏洞评估云治理实践

下一个要解决的问题是为云包含的劣势评估你的治理流程。大多数企业通过气应用生命周期管理（ALM）流程实践IT治理，针对应用和基础架构监控和控制，结合具体的工具实现。迁移到云端差不多也会影响这些领域，因此也会破坏治理，但可能还没破坏法规遵从。

ALM通过强制流程遵从法律规范来验证应用变更和生产系统的完整性。云端部署引入了新的变量，包括机器镜像和配置完整性。根据版本验证这些新的变量的机制是不同。最大的问题是确保操作系统和中间件变更覆盖到所有受影响的机器镜像，可能是数据中心的自动化，但是必须在云端明确出来。

机器镜像在云治理中会导致问题，但是他们可能也能够带来有用的功能，而这些功能是其他功能所难以实现的。通过机器镜像可以加载的任何应用或者组件，而且提供了应用和其所在环境的信息，实际上，治理的代理载入到其他的数据中心。构建版本测试、状态测试，甚至性能测试到一个机器镜像，意味着可以将其用来提供现在运行什么和如何运行的信息。

使用软件代理技术来检查安装库的组件版本相当普遍，很值得用来检查这些工具，看看是否能够验证实际运行的机器镜像版本。这将有效阻止版本问题，这些版本问题可能由内部流程（无法用新的中间件升级到机器镜像）导致，或者云提供商无法回归到备份版本或者运行旧的镜像导致的配置错误。

最后云端“新的”治理问题就是云数据服务。云提供商提供了各种数据库/文件/块存储选项，当然，将数据存储在云端并不会得到同本地一样的物理安全控制。有时候经常被忽视的事实是数据可能就是简单的因为存在云端，所以受到法规的监管，而且云端数据访问控制可能不同于本地的控制，因为云的访问时通过互联网或者VPN。

你的企业所受到的法规监管越多，你就越需要关注数据权限问题。同你的治理审计人员检查一下，确保你知道哪些法规适用于云端数据存储，确保你知道你的云提供商将数据存在哪里。

确定最终的云治理策略

要让云治理战略适应特定的提供商太容易了，但是要是针对整个云就不简单了。实际上，每一个云提供商将会对不同的用户产生不同的治理影响，因此要关注可能引入云劣势的实践，制定通用的战略和策略，处理这些劣势，然后为你所使用的每一个提供商详细说明。广泛的云治理战略就是基础，具体的提供商元素就更易于调整，通过这个战略，引入新的云提供商或者服务就不会让企业重蹈覆辙。