新视角下企业云化安全管控框架OCBC

安全运营 阿肯的不惑之年 2022-12-17

OCBC，新视角下企业云化安全的管控框架。

作者简介

李磊，现就职于某互联网公司，高级安全专家，多家VB银行安全负责人，专注云安全、数据安全和安全运营，期待在云安全中走出一片蓝海。

一、引言

最近和一位朋友聊天，提到他们企业在做数字化转型，业务逐步迁往云上。朋友戏称，云上、云下安全都是一个人，云上该有的都有，或许会安全些。也许，真的是或许吧。

数字化的浪潮，席卷而至，和云形成了密切的关联。当企业战略面向云时，业务准备好了，安全呢？

这个问题我们先放一放，先来看几组数据。

二、云上数据泄露事件

数据1：45%

来自《IBM 数据泄露成本报告》中的数字，45%的数据泄露发生在云上。混合云环境中发生数据泄露的平均成本为380万美元，而私有云中发生数据泄露的成本为424万美元，公共云中数据泄露的成本为502万美元。

数据2：云上数据泄露事件

表1 典型云上数据泄露事件

结合网上资料，笔者梳理了从2017年到2022年发生的多起典型云上数据泄露事件。

为什么从2017年开始呢？希望通过更长维度的梳理，发现典型数据泄露事件泄露原因通性。

从上表大家可以看到，一些企业在云上发生过数据泄露，包括比较大型的云企业服务商自身比如微软，涉及到的数据量和敏感度也非常高。

另外，笔者也特别标识了数据泄露原因和其关联的云产品，通过这些数据我们可以看到，云上数据泄露一方面原因为配置错误或AK/SK泄露，而且和云上常见的云产品有着密切的关联；另一方面无论公有云/私有云/混合云都可能发生数据泄露。

或许，你会有这样的疑问，是云本身不安全吗？所有云平台都存在这个情况吗？企业云化安全还有保障吗？

要回答这些问题，首先要搞清楚云和传统IDC最大的差异是什么？一些不是问题的问题，为什么上了云就变成了问题。

为了便于行文描述的准确性，下文中如涉及云产品名字将以阿里云产品名称为对象进行阐述，其他云类比即可。同时，避免误解，特别说明，每家云厂商发展到今天，或多或少都会存在“历史包袱”，企业云化不可“因噎废食”，选择一个合适的才是最重要的。

三、云与传统IDC差异

笔者看来，云平台和传统IDC最大的差异，主要是基于云自身特性和企业业务场景决定的，主要表现在：

1、云原生化

容器、微服务、K8S等属于云才会具备的专属概念和新生事物，在传统IDC基建中是不会存在的。云原生化本质上带来了基建的翻天覆地变化，这些云上特有的服务从根本上就决定了云的特殊性。

2、产品灵活化

灵活即云产品使用的方便和支持多种多样的业务场景。从业务的角度看，这是个优点，但从安全的角度，或许这就是个缺点了。灵活，就意味着有很多种用法，怎么用都行，潜在就会带来很多安全风险。例如存储桶OSS，bucket支持public、private，但即使private的桶，依然可能造成数据泄露，历史的教训已经很多。

3、安全属性化

鉴于云产品的灵活，意味着每一个云产品都需要有独立能力满足企业的场景诉求，同时满足一定的安全性。随之带来的是，除了云产品自身的功能，该云产品还会带上一些安全功能属性。我们还是拿存储桶来举例，有些场景，你可能需要某个桶只能通过某个IP来访问（acl控制）或只能某个RAM账号来访问（权限控制）。

4、边界多样化

云带来的另一个变化是安全边界的多样，任何一个云产品都有可能成为企业在云上的边界。例如：ECS，小企业可能只会用到ECS，其他都不使用，这种情况下，ECS可能就是企业云上网络的边界。

5、采购精简化

由于云的上述特点，有的企业在做云产品采购时，并不是所有的安全产品都会购买。例如，企业有几十台ECS，可能只会再买几个SLB和EIP，然后就对外提供服务了。在这种情况下，安全又如何做防护？

云的五个典型差异，带来了我们不能单单以传统的视角来做安全治理，如何短、长兼顾，提升云化企业安全状态达到一个相对理想的水位呢？

四、云上安全管控框架OCBC

基于多家金融企业云化落地经验和实践，笔者从一个新的视角提出云上安全管控框架OCBC来解答这个问题。OCBC即：运营Operation、控制Control、基准Baseline 和云原生安全Cloud Native Secuirty。下面将针对OCBC框架进行介绍。

图1 云安全管控框架OCBC

1、O运营

运营或称之为安全运营，是指以数据（日志）能力为基础，以分析能力为手段，以指标能力为度量，实现风险管控闭环和提质增效，助力安全管控和业务体验平衡。

从本质上来讲，运营关注的是Detection，可以从四个维度：数据（日志）、场景、规则和指标进行构建。这里笔者结合云上特性，重点讲一下数据和场景中的特殊点

数据

云化一方面给安全数据的获取提供了极大的便利性，而且多数数据天然就可以实现统一存储；另一方面大大降低了数据泛化难度和复杂度，节省大量构建运营能力的成本。

从数据来源的角度看，云上安全数据一种是通过云安全产品产生，另一种通过安装企业自身的安全工具将数据统一采集汇聚，通常二者兼备。

例如，阿里云提供了统一的日志服务SLS，你只需在日志审计服务的全局配置中打开相应的审计日志功能即可。企业可以用较低的成本基于SLS实现SIEM基本功能和能力。

像Actiontrail操作审计、OSS、WAF、防火墙和云安全中心等基本属于必备数据源。

但是，这里特别想提及的是，云产品日志的存储一般需要手工开启，通过不同的位置打开，可能会带来存储字段的差异性，有些关键字段也会对构建规则实现带来复杂度提升。另外，并非所有的数据都会在SLS中存在且也不能实现统一的汇聚。例如配置审计、DMS、DW日志等，这种情况下就需要特殊进行处理。

场景

场景是基于不同安全风险维度进行的划分，便于后续更细化构建规则。全局上来讲，云上风险场景分为数据泄露风险场景和外部攻击风险场景。

在数据安全泄露风险场景中，需要重点关注大数据产品DW、DMS、AK等使用可能带来的数据落在非可控终端安全风险。因为作为云产品，天生特点就是不存在互联网和办公网的区别，需要特别设置。

在外部攻击风险场景中，需要重点关注私有化部署某些云产品可能带来的潜在安全风险。例如，如果因为监管合规因素，私有化部署云产品WAF可能带来的HOST头穿透风险。

最后，规则一般是基于场景风险的技术化落地，指标是对前三个维度的评价体系。至于红蓝抑或众测等，可以归类为指标检验技术手段。

值得说明的是，运营，不是企业安全发展到一定阶段的追求选项，而是企业云上安全建设开始的同步选项。

2、C控制

控制，是整个OCBC框架安全管控的核心之一。控制，本质上，关注的是Prevention。

控制包括三部分，控边、控权和控桶，简称“3控”。

1）控边，即从网络安全的视角，做好云上网络边界的安全控制。特别解释下这里提到的“边”，有三层含义

第一层含义为：做好云上网络最外层边界防护即互联网边界防护；

第二层含义为：层层为边，纵深设控。云虽然模糊了边界，但是从企业网络防护的角度，仍然需要确定自己的安全边界在哪里，基于最外层边界，逐步向内推进到最内层容器，任何一个具备访问控制的云产品都可视为这个边界。

第三层含义为：云上企业网络内部，横向不同VPC间、VPC内不同安全组间、容器间亦有边界，也需要做好边的控制。即VPC边界、主机边界和容器边界

例如，在阿里云上，可以通过WAF、互联网边界防火墙、SLB、主机安全组、容器防火墙等来构建纵深防护。通过VPC边界防火墙、主机安全组来构建横向防护。

特别提出的是，主机安全组区分为企业安全组和普通安全组，不同安全默认安全策略直接带来安全组内部ECS间默认网络连通性有无。另外，从实践来看，安全组是缺少日志的，很大程度上增加使用时和故障摸排的复杂度。

2）控权，即人、应用、云服务针对所有云产品使用的权限管控，这是整个云上权限管控的基石。

一般云平台都会存在访问控制类产品IAM/RAM，用来统一管理自身产品的访问权限，用户可以通过这个IAM/RAM来管理和使用自己购买的云产品，IAM/RAM可以视为云上所有权限管控的入口。通常大家对IAM/RAM的认知，是听到AK/SK这个名词，等同于访问云产品的账号和密码。

AK/SK有个神奇的特点，不做轮换的前提下，SK只有生成的那一刻是已知的。而且，在默认情况下，AK/SK是不存在控边管控中提及的边界概念和属性的。拥有AK和SK，意味着你可以在任何时间，任何终端以任何访问该AK/SK下拥有的权限。

控权的核心为1中心3原则：以IAM/RAM为中心，遵循分类管控、权限最小、特例关注三个安全原则。

所以，基于以上原因和业务场景，笔者将控权划分为P-RAM，A-RAM，角色和其他。

P-RAM即用户账号，以人为中心的账号权限控制。P-RAM只能登录云控制台，不能拥有任何形式的AK。其中，ROOT为特殊形式的P-RAM，开启2FA，并禁止常规业务场景和用户使用，仅做特殊RAM管理员不能操控的场景。

A-RAM即AK，为应用账号，以应用为中心的账号权限控制。A-RAM只能为应用所使用，满足特定命名格式化规范，且保持读、写分离，禁止登录控制台。

同时，针对AK遵循控IP和控源安全机制，即控制AK调用的IP访问来源，控制AK调用的资源范围，保持最小化。

角色，是一种虚拟用户，有确定的身份，可以被赋予一组权限策略，但没有确定的登录密码或访问密钥。RAM角色需要被一个受信的实体用户扮演，扮演成功后实体用户将获得RAM角色的安全令牌，使用这个安全令牌就能以角色身份访问被授权的资源。基于某些特殊原因，禁止任何形式的角色扮演逻辑。

其他，这里特指的是对应云产品内部的账号和权限控制逻辑。一般有2种情况，一种是以P-RAM为账号体系，但非以P-RAM为权限体系控制，例如DMS、DW、Holergres等；另一种是不以P-RAM为账号体系，自成一体，例如ES、堡垒机、Redis等。

鉴于控权的重要性和复杂性，结合账号、权限全生命周期风险管理目标可管、可控、可审、可追，建议通过平台化能力落地控权机制，

在这里，笔者提供一个控权统一管控能力建设简要框架供参考。

图2 控权统一管控能力

3）控桶，即存储桶的安全管控。桶，是一种云上特有的产品，非结构化数据存储集散地。从前文“云上数据泄露事件”可以明显地看到约60%的云上数据泄露都和存储桶有着较大关联。

为什么存储桶的使用会存在如此多的安全风险呢?

作为历史最悠久的云产品之一，一方面是由于其复杂的鉴权控制模型决定的；另一方面其一般和应用关联使用，不正确的使用方式又加剧了这种严重性。

阿里云上存储桶OSS非匿名请求鉴权逻辑如图3所示，从图3可以管中一窥其鉴权模型的复杂。

图3 OSS非匿名请求鉴权逻辑图（来自阿里云官网）

所以，做好存储桶控制，要从Bucket和Object两方面入手，从安全机制上尽量规避Object与Bucket安全策略不一致情况。

控桶三原则为：‘公私’分离、权控模型统一化和标准化、特权管控。

‘公私’分离是指在应用存储桶设计时就区分开Public类型的桶和Private类型的桶，禁止Public类型桶存储任何敏感数据。

权控模型统一化和标准化是指优先选择Bucket policy或RAM policy作为桶权限管控的模型，一定程度简化鉴权控制逻辑。从本质上来讲，二者都可以实现授权某个用户拥有Bucket的操作权限，但操作对象和策略语法差异较大。

特权管控是指针对Bucket桶中的特权ListObject操作等进行管控，默认去除。

3、B基准

基准，是整个OCBC框架安全管控的另一个核心。基准，本质上，关注的亦是Prevention。

基准包括两部分，云产品安全基准和安全管理基准。简称“双基准”。

1）云产品安全基准

解决的是云产品“选”、“用”、“留”的问题，从机制上规避非必须、非安全的云产品引入和使用，以左移视角降低业务安全风险。

可能很多人会比较好奇，云产品还有不安全的吗？还有存在不能用的产品吗？

答案是肯定的。云上产品众多，每种产品都有自己归属的用途和业务适用场景。从云平台自身的角度上，会基于产品规划和发展开发不同类型云产品来满足用户场景，但是这个角度是站在单个产品大类来考量的，而不是站在整个云上产品组合应用的角度，这时候“坑多水深”的事就比较多了。

所以，云产品安全基准要从云产品评估、安全准入、安全基线、退出机制和策略管控五个维度来进行把控。

云产品评估：即建立对企业所有选用云产品的安全评估机制，首先确认诉求合理性和必要性，然后针对云产品的使用进行安全评估，确定风险等级、风险项、缓解措施等。

安全准入：建立云产品安全准入基础白名单清单，以“红”、“黄”、“绿”标识云产品准入资格。其中，经安全综合评估，确认因产品使用风险过大或无有效控制风险方案或绕过现有安全控制机制时，同时非业务必须、紧急类产品，属红色标识纳入禁止准入清单；经安全综合评估，可裁剪某些功能并满足产品安全基线标准前提下，属黄色标识云产品清单，可以采购；经安全综合评估，满足适度产品安全基线标准前提下，属绿色产品清单，可以采购。

安全基线：即云产品安全基线，对象为云产品自身。经过安全评估的云产品需具备对应的安全基线。

退出机制：因重大安全风险或业务调整或其他原因，带来云产品不再使用时，即启动退出机制。例如，因预算问题带来的云产品下线。

策略管控：云产品安全基准的技术化管控落地支撑，覆盖企业云产品使用的全生命周期。

2）安全管理基准

安全管理基准，是站在应用安全和数据安全视角，对云上业务的安全管理。

应用安全

围绕SDL生命周期，以横向纵深闭环和单点纵深闭环进行建设。横向纵深闭环，是指从需求-->开发-->测试-->上线-->运行，每个阶段的安全控制都是有管控，有落地，有检验；单点纵深闭环，是指针对单一阶段具备多层控制要求，每一层的控制要求同样遵循有管控，有落地，有检验。

另外，基于云上特点建立适应的云应用安全基线也是其中重要的一环。

数据安全

数据安全，围绕应用数安、大数据数安和终端数安进行。需要注意的是，企业云化带来的办公网边界模糊、AK/SK特性等问题，造成数据泄露风险渠道外溢性明显。如可以通过控制台掩码访问控制机制来圈定可控办公边界以规避类似风险。关于数安，笔者在企业数据安全治理1+3+1+1文章中，已经有着比较多的介绍，这里就不再过多赘述。

4、C云原生安全

云原生安全也是传统IDC架构下不会面临的基础设施环境场景，具体包括云平台安全、K8S安全、镜像安全和容器安全。

云平台安全，是指从云服务商的角度，需要确保云平台自身的安全性。这块的安全能力和水位建设完全依赖于云平台自身，历史上云平台自身安全性存在问题造成数据泄露的案例并不缺乏。作为云平台使用方的甲方企业可以在云平台选型时多方考量。

K8S安全、容器安全、镜像安全是企业云化后在云上最重要的基建。多数云上逃逸都是通过容器等安全漏洞，进而控制K8S集群。镜像安全亦是供应链安全管控中的重点。可以从API权限、网络访问、端口控制、特权管控等方面进行管理。

以上，是整个云上安全管控框架OCBC的主要介绍，重点还是站在甲方企业用云的角度来开展云上安全管理。下面通过示例来揭示框架C控制中控桶的重要性和复杂性。

桶Bucket典型授权风险举例

情形1：桶私有，采用Bucket Policy授权控制，权限配置如下，请注意条件和授权用户均为空，这种情况下桶的风险是什么？

图4 Bucket policy授权用户为空（授权资源为桶）

图5 匿名用户删除桶示例

结论

• 桶名称的全局唯一性。如果桶为空，匿名用户知道名称就可以删除桶；如果桶不为空，匿名用户即使知道名称也不可以删除桶（需要将桶中的文件清除后，才能被匿名删除动作）

• 清除桶文件需要具备DeleteObject权限，当授权资源为桶时，即使授权操作同时包括此权限，也不能以匿名执行DeleteObect操作

• 主要风险：刚创建个桶，为空时，还没有放文件，匿名用户删除桶

情形2：桶私有，采用Bucket Policy授权控制，权限配置如下，这种情况下桶的风险是什么？

图6 Bucket policy授权用户为*（授权资源为Object）

图7 匿名用户下载桶文件

结论

• 桶私有且授权资源为object和授权操作包含GetObject情况下，授权用户为空或*，均代表匿名用户可以访问对应资源。

• 主要风险：匿名访问文件，数据泄露

情形3：桶私有，采用Bucket Policy授权控制，权限配置如下，请注意条件和授权用户均为空，这种情况下桶的风险是什么？

图8 Bucket policy授权用户为空（授权资源为桶）

图9匿名用户下载失败

结论：

• 授权资源为桶，即使授权操作中有getobject权限，匿名用户仍不可访问文件

• 主要风险：匿名删除桶

情形4：桶私有，采用Bucket Policy授权控制，权限配置如下，请注意条件和授权用户均为空，这种情况下桶的风险是什么？

图10 Bucket policy授权用户为空（授权资源为Object）

图11 匿名用户下载成功

结论：

• 授权资源为Object维度，授权操作包括GetObect等，就可以实现匿名访问文件

• 主要风险：匿名访问文件、数据泄露、匿名删除桶

• 为什么会出现这种情况呢？

• 本质上来讲，属于OSS授权机制的灵活性，同时OSS Action分类分为Service级别操作、Bucket级别操作以及Object级别的操作。因为策略操作资源分为Bucket级别和Object层面，但是操作需要和资源支持的内容匹配，操作才会成功，否则依然不会成功。

• 在资源和操作匹配前提下，授权用户为空和授权用户为*，均是表达匿名访问或所有人可以访问的目的

• 针对Bucket级别的Resource设置，不需要在{bucket_name}之后添加正斜线（/）以及{object_name}，即acs:oss:{region}:{bucket_owner}:{bucket_name}

五、结语

云，既简化了传统IDC网络架构的复杂度和上手成本，也带来了基础设施和架构的新变化。

企业云上安全建设不是一蹴而就的，除了面临业务变化带来的新风险，还要面对新的云产品推出和云平台自身迭代更新可能产生的新风险，需要保持长期的持续学习和投入。

最后，有几个观点要大家分享下：

1.云上OCBC安全管控框架中的C控制天然具备安全属性，单纯的管理要求或职责转嫁，安全始终会处于一个被动收拾的角色，建议安全团队主动承担或提供标准的平台化安全能力支撑。

2.云上安全建设在不同云厂商平台间具备通用性和可复制性。基于用户需要对云产品理解的一致性，各云平台默契地在云产品设计时就兼顾用户认知（尤其典型的权限IAM、存储桶等产品），来规避从其他云平台迁移到自身带来的学习成本。

3.云是个特别复杂的东西，涉及大量新知识和新观点，尤其针对业务完全运行在云上的甲方企业。如果希望熟练掌握云安全相关领域，既要从云平台的维度加深对云底层的理解，又要从甲方用云的角度深入理解云上产品特点，这样才能更好的在业务场景中应用，从根本上规避或降低安全风险。

4.完全依赖云厂商的安全能力和平台来构建企业自身云上安全治理是不现实的，所有云产品拿来即用的思路也是不可取的。同时，希望引入三方非云平台安全产品需要考虑云平台环境的融入性和复杂度。

5.每家云平台都可能存在安全漏洞，只是存在多与少、发现早与晚的问题。但是，更多的时候，其实是作为甲方企业没有安全、合规的使用云而造成的安全漏洞或数据泄露，云平台间接成了”背锅侠“。所以，坚持做好用云安全第一责任人的角色定位是重要的。