作者：bloodzer0

背景

互联网数据中心（IDC）属于互联网基础设施范畴的一个细分领域。为企业、金融机构等提供一个存放服务器的空间场所，随着科技技术的发展，IDC也经历了一个又一个的里程碑，如下图是：摘自《美国数据中心建设发展历程分析情况》

从图中我们可以看到IDC发展由传统的自建IDC机房、租用或托管服务器的方式向虚拟化云IDC转型。过去的几年里，选择云IDC的中小型企业数不胜数，小B也曾经在几家企业中参与相关的安全建设。提到云IDC那么不得不提的就是现在云计算模式的不同带来的云IDC类型不同：

云计算平台本身提供三种类型的云服务：

  • IaaS（基础设施即服务）：消费者通过Internet可以从完善的计算机基础设施获得服务，这类服务称为基础设施即服务，基于Internet的服务（如存储和数据库）是IaaS的一部分。

  • PaaS（平台即服务）：PaaS提供了用户可以访问的完整或部分的应用程序开发。

  • SaaS（软件即服务）：SaaS则提供了完整的可直接使用的应用程序，比如通过Internet管理企业资源。

同样的，在云服务的衍生下，我们还出现了：公有云、私有云、混合云等概念。在本篇文章中，我们主要探讨的是基于IaaS公有云的安全，因为IaaS是最贴近传统IDC这样的理念，它具有用户可访问的资源（主机、数据库等等）。

IaaS云的安全痛点

小B在参考了一些行业内的资料以及根据自身的实践，将云安全痛点分为了3类：

第一类是CSA云计算联盟定义的威胁分级种类;第二类就是根据云平台自身的属性所导致的安全⻛险;第三类是小B在从企业安全建设时遇到的痛点与难题。我们从这三类中不难看出主要的⻛险集中在：资产管理问题、网络攻击⻛险、数据安全管理、身份管理与访问控制、业务连续性管理、监管合规。

因为精力与时间，当然了主要问题是很多层面的安全⻛险小B没有接触过，所以下文就主要从企业安全建设的⻆度来谈：

凭证管理的痛点

对于凭证管理，小B主要列举了2类的痛点：第一类是比传统IDC更多的凭证类型，在传统IDC中我们更多的是使用服务器管理凭证，但是在云IDC中我们会新增两类凭证：

  • 云控制台访问凭证，此类凭证用于我们通过Internet访问云控制台，在这其中又存在两个小类：

    • 主账号：拥有其下所有资源和企业级分布式应用服务的所有操作权限。

    • 子账号：主账号通过创建子账号，避免用户间共享密钥，按需给子账号分配权限。

  • AccessKey：访问密钥AccessKey（AK）用于程序方式调用云服务API（主账号与子账号都有AccessKey）。

第二类痛点就是由于云IDC的非集中化导致的分散式凭证生命周期管理。多样化的凭证与凭证的分散性导致了我们难以集中化管理，也经常会导致凭证管理不当而出现的安全问题。

资产管理的痛点

  • 分散的地区：在使用传统IDC机房的时候，中小型企业可能只有1~3机房，但是我们在使用云IDC时面临的地域就会变得更多，上述提到的4种架构都会形成不同的地域IDC分布，给我们管理云资产带来不便。

  • 多样的类型：云上的产品的细分类给我们提供了使用便捷的同时也带来了资产管理的难题，多样的类型导致我们在进行管理的时候需要处理的数据源更多，不同数据源的字段、属性也不一致也会造成统一采集的困难。

  • 不同的维度：在这里需要提到的一个系统就是CMDB，可能对于很多企业来讲CMDB的维护都是做的很一般或者做不到资产的实时管理。这个问题在中小型企业就更为常⻅，他们可能都没有CMDB或者是非常简易的CMDB。并且运维与安全对于CMDB数据的细粒度要求是不一致的，很难将两者合二为一，更多的做法是各行其事，数据互补。最后在安全做黑盒的云资产管理时云平台自身会对黑盒的方式进行一些拦截从而造成一些资产收集的误报以及漏报，这些问题我们都会在下面的解决方案中提到。

访问控制的痛点

对于访问控制来说，它是基于前面两者痛点的延伸：其中主要是2类问题，第一类问题是从凭证层面的访问控制：

  • 云控制台有哪些用户可以访问?

    • 主账号是否存在共享使用?（有多少企业是所有运维直接共用主账号进行管理）

    • 子账号是否存在共享使用?（云控制台用户是否将自己的账号共享给其他用户）

    • 子账号是否有⻆色权限以外的权限?

    • 灰度账号是否处于活跃状态?（离职员工的账号是否及时清理）

    • AccessKey是否拥有过高的权限?

    • ............

  • 服务器资源哪些用户可以访问?

    • 谁拥有服务器上的特权账户?

    • 统一单点登录以外的账号?

第二类的痛点是网络层面的访问控制：在这一类问题中云控制台本身就是针对互联网开放的，我们需要做好的就是凭证管理，其次就是云资产的访问控制

  • 云资产对互联网或办公网络的访问控制策略（RDS是否允许互联网直接访问?核心服务器是否允许互联网直接访问?）

  • 不同类型云资产之间的访问控制策略（RDS对ECS的访问控制策略）

  • 相同类型不同属性云资产的访问控制策略（生产环境与测试环境的访问控制）

当然了访问控制的痛点远远不止我这里列举的这些，还有很多企业在安全建设时都会遇到不同的安全痛点。

流量采集的痛点

因为云IDC边界淡化失去了传统意义上的统一入口或出口，我们无法在对出入口的流量进行镜像或汇聚处理，导致安全建设中失去了一张王牌。

其他安全痛点

  • 胡乱的资产分组：生产与测试处于同一VPC;

  • 成吨的网络攻击：由于云IDC的开放性，所以每天会面临成吨的访问控制扫描、漏洞扫描、Web扫描等;

  • 分散的补丁管理：如果企业没有统一资产管理系统或者服务器未使用域环境，那么我们在安装补丁时也会遇到麻烦;

IaaS云的基础安全建设

在知道了⻛险之后，我们就需要进行安全防护了，本文没有涉及数据、应用与业务层面的安全防护方案。云安全自身是一个大的安全话题，也不是一篇文章就能够写完的。

购买云产品

小B在这里只是列举了应对上述提出的安全问题的云产品，当然我这里也只选择了一家云服务商的产品，并且可能还忽略了一些产品，所以大家只参考一下即可。

对于购买产品，小B这里有一点想分享的经验：云产品更多是普遍适用性的，可能在不同企业中使用相同产品达到的效果也是不一致的。

其次就是购买产品是需要money的，加之本文的前提是中小型企业，这样的企业很可能就是无安全人员或者1~3个人的安全部。如果企业无安全人员，小B的建议是别折腾，能买一些重要的产品再好好运营一些也是OK，包括小B在图中提到的也不是每一项都要钱。如果是1~3个人安全部，企业愿意花钱与无安全团队的做法建议是一致的，不愿意花钱可以选择折腾一些开源产品，小B在博客上也提到过很多相关的安全产品（https://bloodzer0.github.io/ossa/）

最后就是产品也好，开源工具也罢都是需要我们去不断运营和优化的。工具是死的人是活的，我们需要做的就是将工具发挥出它最大的价值。

解决凭证管理难题

在解决凭证管理这个问题上，小B经历了3个阶段：第一个阶段是没有任何辅助，只能通过主账号来梳理凭证并且通过一些IT流程来进行管理;第二个阶段是利用云API进行自动化的凭证管理;第三个阶段就是实现集中化的凭证管理。在这里小B主要提一下后两个阶段：

利用云API实现凭证管理

在这一个部分小B主要是通过代码来实现3个方向上的凭证管理：

  1. 通过内部通讯工具的接口获取用户原始数据，并且采集通讯工具中的用户属性;

  2. 利用云API管理云控制台账户，根据用户属性决定是否需要创建或删除云控制台账户;

  3. 与内部的跳板机打通，根据用户属性决定是否需要创建登录或删除资产访问账户;

在这里小B还额外做了一件事情，就是监控互联网的部分平台，查看是否有公司的凭证信息泄露，主要是GitHub、码云与网盘。

集中化的凭证管理

在前一阶段的基础之上，小B完善了凭证管理体系，还是以内部通讯工具中用户属性作为源数据，并且实现统一账户管理（基于FreeIPA）与统一单点登录，最后将统一账户管理接入跳板机（JumpServer）与单点登录接入云控制台：

解决资产管理难题

资产管理小B也分为了几步走，但是本文提到的最后一步是小B还未实现的;

  1. 黑盒资产管理：以扫描的形式发现资产（masscan+nmap+nessus等），通过将扫描结果进行数据处理后入库然后以CMDB的形式展示。但是在这个阶段中会由于云平台的拦截产生误报与漏报，所以这里的资产管理数据我们还需要更进一步的处理。

  2. 白盒资产管理（利用云API），之前小B也分析过对应的文章：

    https://bloodzer0.github.io/ossa/other-security-branch/asset-management/asset-acquisition/

  3. 利用主机入侵检测Agent采集数据，不论是前面的黑盒方式或利用API的方式，我们获取到的数据在细粒度上都达不到安全后期的要求，所以利用主机入侵检测的Agent可以获取更详细的信息，但是由于这个层面需要对底层开发有着足够深厚的了解，这也是小B未实现的原因。但是小B也实践过开源的主机入侵检测系统（OSSEC）采集信息完善安全的CMDB，效果也是很不错的。

解决访问控制问题

访问控制是一个很大的话题，涉及的面也是多种多样的，小B可能一句两句也讲不清楚，但是会尽力把实践过的内容给大家讲清楚：

  1. 制定访问控制策略与管理流程：访问控制难题不仅仅是一个通过技术就能解决的，首先我们需要制定好访问控制策略，在制定策略之前我们需要梳理我们的主体（使用者）与客体（资源），在评估主体的需求后制定出策略，访问控制策略一定要依据最小权限原则。制定好策略只是一个起始点，后期策略的管理也至关重要，在这其中小B是通过以IT流程的形式进行策略变更管理。

  2. 制定好策略以后我们需要实现策略控制，在这里对于凭证的访问控制，主要是通过云控制台管理进行。对于资产的管理主要是利用安全组来实现的，安全组可能并不具备攻击防护能力，但是具备良好的访问控制策略。在安全组实现访问控制的时候，会遇到一个大坑，就是当我们的IDC数量越来越多时，我们管理就会变的更加困难。所以如果前期就有这样的安全意识是最好的，后期就会需要我们逐一的去调整已有的策略。

  3. 定期审计访问控制策略是否合理，这里提一点的就是，我们的策略审计最好是以实践的方式进行审计。通过将审计策略拉取到本地（API是可以拉取的，云控制台也可以导出）然后根据策略的内容去实践策略是否有效。

其他安全痛点

每个企业在使用云都会遇到不同的安全难点，一千个读者就有一千个哈姆雷特，安全也是如此，希望大家一起讨论云安全建设。

声明：本文来自heysec，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。