集中化是多云安全策略的关键

山东 姜建华 李文竹

在企业构建多云的安全策略时，集中化是安全团队重点关注的最为关键的领域之一。对于多云系统，运营和安全团队可能面临碎片化或分散的安全访问控制和监视工具，如果这些控制和工具在每个独立的供应商环境中设计和实施，企业往往面临着不少挑战。

有些云运营团队寻求多云代理商并将所有的云管理集中和整合到一个地方，还有的企业选择一种独立的产品或平台，使其与所有必要的供应商环境相集成，从而可以对安全策略和访问管理进行集中控制，而不管其底层的云基础架构是什么。

在部署多云安全策略时，安全团队应当评估当前所有的云控制，并判断是否实施了集中化，其中包括：

端点安全工具：许多反恶意软件、端点检测的工具能够在多云的环境中运行。

配置和打补丁工具：如果可能的话，构建云负载镜像应当实现集中化，这要比传统的镜像工具更多地依赖基础架构。配置管理的自动化平台可用于维护所有已部署实例的配置的连续性。

漏洞扫描：多数企业的漏洞扫描器已经成功地集成到当今主要云供应商的环境中，所以，为这种类型的控制实施一种分散性的方法已不太可能，云“控制面”扫描和评估工具可以对云账户的配置和环境自身形成报告，这种操作应当对云的覆盖范围进行评估。

事件收集和SIEM/分析：将所有的日志从云环境迁移到一个用于评估的中心源已经变得相对简单，因为主要的SIEM 企业已经与多数云供应商进行集成。此外，在这方面还有一些新的SaaS产品。

基于模板的“基础设施即代码”：云运营团队应当将基础架构用作代码工具，其可以与本地云的模板技术（如AWS Cloud Formation 及Azure Resource Manager 模板）相整合，用以定义基础架构配置和云账户的其他要素，很多安全控制如身份策略、网络配置、镜像模板等也可用这种方法配置。

而有些控制是不容易集中化的，其中包括三个方面：首先是加密，多数企业最终使用的是特定的云供应商的密钥管理工具；其次是所有的身份和访问管理；第三是自动化，常见的就是环境中的API 和特定脚本的编写。

务必关注跨平台的厂商。理想情况下，如果企业可以在功能基本相同的厂商和成本之间进行选择，应优先考虑在多云环境中覆盖范围更大的厂商。对于事件响应、取证、SOC 团队所使用的取证和响应工具而言，也应如此考虑。这些工具需要尽可能地简化流程和操作手册，以使用统一的证据收集和调查策略。

集中化并不是在迁移到多云架构时唯一考虑的重点。安全团队还应当在多层上实施控制，并考虑如何应用在每种环境中。对于在多云以及在本地环境中实施一种深度防御的控制架构来说，企业有着比以往更多的选项。安全和运营团队应当真正关注几个问题。

首先就是可以为策略的构建和总体管理而集中实施的工具。这些工具的管理越简单，网络设计的结果就越成功。

其次，安全和运营团队还应当优先考虑使用“基础架构即代码”之类的工具。

最后，安全团队应当考虑实施多层网络分段策略。传统的防火墙在支持本地和云环境的网络连接方面仍有其地位，这种防火墙还可以提供入侵防御和许多企业今天仍需要的其他控制。当然，企业还要实施本地的云访问和分段控制。

对于大型的云部署而言，有些本地云控制的基准实施可以证明是有价值的，但是拥有大量资产的多云设计，可能真正地从更深层次的应用程序的可见性中获益。这种做法还有助于监视和报告的集中化。当今没有哪种本地云的工具提供这种水平的检查和动态的策略评估，这意味着需要实施传统的工具，目的是为确定检查了哪些类型的应用程序通信，并且还是为了对多云环境和本地数据中心内部的负载传输而实施一种集中化的策略。这往往要求某种类型的终端代理来提供必要的检查和执行。

大型企业迁移到多云环境是一种趋势，但仍有关于集中化利弊的一些争论。可证明的是，集中化的系统有益于协调和通信效率，并可确保一致性。与之形成对比的是，在大型企业中很难实施和维护一种非集中化的、非分级的系统。