更新背景
目的
最近笔者对于超大型企业的混合云安全架构有了更深入的了解，笔者想借此机会，讲透彻超大型企业的混合云安全架构里面会猜到的坑，以及我心目中的理想的解决方案和彻底解决安全风险问题的解决方案。希望能够给国内超大型企业带来一些对于风险认知的提升，笔者答应给大家的关于Azure、AWS、Google云的安全架构后续再慢慢更新。
笔者依然看到了国外AWS、Azure、Google给超大型企业的超完整解决方案，笔者也会借此机会找出AAG这三家给这些超大型企业提供的优秀的完整安全解决方案、提供的体系化安全能力、可落地的安全规范以及对应的上云安全治理框架。这些大家如果没有亲身设计过超大型企业的安全架构，是不太可能凭自找找到背后设计的原因（Why）、如何（How）设计以及设计了什么（What）？
对于超大型客户的混合云安全架构，笔者先做一个假设，笔者是站在整个企业的基础设施安全架构角度，既要设计顶层的架构设计、又要进行落地、还要覆盖企业/政府的租户侧安全体系、最终还要覆盖底层的云平台底层的安全体系。本篇文章会比较长，但是笔者本着最少的废话原则，用清晰、简洁、高效的来总结每个点的风险、对应的解决方案、使用的技术细节、运营角度、持续改进的维度等细节。
超大型企业整体介绍
综述
重要说明：以下情况纯属假设如有雷动，纯属巧合。
首先开始正式的安全风险分析、心目中的混合云安全架构、业界的某些领域的安全解决方案、具体采用的技术细节、安全运营等展开之前，先介绍一下超大型企业整体的情况介绍。
业务规模
超大规模上市公司ACME公司，年收入4000亿美金左右，市值接近2W亿，世界TOP3企业，主营业务图书、音像制品、软件、消费电子产品、服装鞋帽、首饰等等，业务遍布全球各地。另外除了电商业务之外还具有零售、物流、硬件、云计算、电子图书、支付等扩展业务，业务大小分类超过100+，而且过程中还在不断的收购各种企业来扩大业务规模。除了收购的业务之外，还跟全球的投资机构、金融机构、政府机构、监管机构等构建了复杂的生态体系。业务上超级错综复杂，而且每个版块之间的交互也是复杂无比。
管理层的技术战略
1、Cloud First、Mobile First
ACME的战略就是100%的迁移到云上，利用ACME的复杂业务来打磨自身公有云的成熟度，形成强大的竞争力，第二个全面拥抱Mobile移动平台，利用自身的业务下沉移动平台、整合云平台形成强大的战略落地能力。
2、技术架构OneInfrastructure
ACME全球业务形成统一架构，包括公有云、混合云统一开发模式（开发的应用能够直接适配整个公有云和混合云）、统一的身份认证模式（开启全网供应商、员工、第三方员工、外包公司等统一的身份认证体系，形成巨大的安全能力，来保证整个自身账号体系的安全）、统一的安全（整个ACME公司全部依靠ISAM基础设施安全态势评估系统构建的OneSOC系统来进行统一的100+ BU+分公司+收购公司的水位拉齐、威胁检测、安全基线、监控和响应体系）、统一的数据平台（整个公司形成了OneData架构，全部的混合云数据全部拉通，数据拉通之后的共享机制以及强大的规范、架构、模型、算法等形成了巨大的竞争优势）。
3、CTO战略
CTO为了进一步提升竞争优势，除了100% ”On Cloud“之外，提出了更加世界前沿的技术思路，100%迁移Cloud Native，形成Cloud Native On Cloud的态势，全球范围内只有Google做到了这一点，Cloud Native的主要优势是为了服务业务，降本增效提升研发效率，加速业务创新。
支撑系统规模
1、全球网络规模
全球30+ Region、100+ AZ可用区、超过250个Edge边缘节点、全球网络设备数据超过20W+的规模；服务器规模超过600W+规模；
2、全球IT规模
ACME公司成立了核心服务运营（CSE）团队，运营着庞大的2000+内部IT系统，范围包括供应链管理、人力资源管理、财务管理、安全、法务、销售、业务支撑等庞大的运转机制，CSE团队的职责主要是把内部的IT慢慢迁移上云，部分不能上的业务跑在私有云上，通过专线和公有云直接打通。
3、全球服务器规模
经过前面讲到云原生化之后整体容器数量超过400W+，IDC服务器超过200W+，服务和服务之间的交互也是非常复杂，在这样的规模上构建的安全体系是非常复杂的。
人员规模
员工总数超过80W+人员，分布在全球超过200+城市，同时超过2W+招聘岗位，这样的情况下人员管理也有巨大的安全挑战。
架构现状
目前ACME公司的超过90%的业务已经迁移到云上，并且跑在了基于公有云云产品底层基础上构建云原生上，还有10%的业务仍然在传统的IDC机房中，IDC机房通过专线跟云上的VPC打通，形成了混合云的态势。
混合云安全风险分析
安全风险综述
1、企业上云后的云侧风险
云上安全风险是企业上云之后，混合云环境下面临的巨大风险，包含AK凭证风险、云上默认配置导致的风险、云厂商自身的信任问题导致的风险；
AK特权凭证泄露：云上的AK存在较高的权限，利用获取到的AK可以进行这个AK拥有权限内的各种操作，导致入侵和数据泄露的风险，这块有非常多的公开材料可以参考，不再赘述；
云上默认配置导致的风险：企业上云之后采用了大量的云产品，这些云产品默认配置会有风险，例如采用对象存储用户配置之后可以进行Public的访问，可导致数据、代码等被直接访问，这里我讲一个具体的Case来说明这个不安全性在哪里，首先ACME上云之后由于自身的代码开发、编译、上线等需求，直接购买了Azure Blob、AWS S3等对象存储来存储自己的开发编译的中间代码，首先从公网环境来看Azure Blob、AWS S3没有直接进行列举所有文件和目录的漏洞，也直接获取不到相关信息，但是经过分析找到了ACME的这个代码发布平台，进行了JS的分析，掌握了采用Azure Blob、AWS S3存储代码的逻辑和版本，例如https://commitfiles.blob.core.xxxxxxx.net/coreService/2.3.0.2/UserAccountService.coreService.manifest，这个Mainfest里面包含了所有的这个组件相关的编译下载地址，这样就完美掌握这个ACME企业的编译信息了。
云厂商自身的信任问题导致的风险：这个时候云安全专家们可能笑了，我会做IP白名单啊，这里我放一个0day，来说明一下国外的云平台存在的高危风险，国外某云平台的数据库有白名单限制，直接从互联网是无法访问的，但是这个时候我利用这个云平台的一些数据库管理平台进行直接访问，完美绕过了数据库的白名单限制，截止到现在国外这个云平台的漏洞还未修复，所以真的是一个0day哟。
2、网络安全风险
ACME上云之后面临的最大风险就是账号风险以及网络安全风险，下面来说一下为什么网络安全风险较大，ACME早期的时候采用了大VPC安全架构，虽然使用安全组进行了各个层面的隔离，但仍然存在横向移动的风险，后来慢慢的采用了生产网零信任架构和VPC拆分安全架构慢慢逐步提升了安全等级，公司成立25+年历史上从未出现过大规模的数据泄露事件，这是ACME一直引以为豪的安全架构能力，后面会讲到ACME到底如何解决大VPC安全架构的风险问题。
专线网络安全风险：因为ACME公司的复杂性，必须要跟金融、政府、监管单位、合作伙伴、供应商等进行专线打通，这个是必然的需求，但是这里一旦失控，将会导致非常严重的后果，如无及时进行治理会导致企业面临巨大风险，这块ACME采用了对应卡点、收敛、安全网关的方式来进行管理，让风险降低到较小水位，而且收购的公司也会纳入ACME企业的网络，这块对于收购公司也会有非常严格的培训班升级机制，通过1-2年的培训升级机制来提升到对应的安全水位才可以进行接入。
云原生网络安全风险：因为ACME CTO发布云原生战略之后，开始逐步迁移到云原生平台上，在云原生平台上网络安全风险导致的横向移动也是巨大的，所以ACME采用了生产网零信任，默认鉴权、默认携带身份、默认认证的方式来进行解决，这个方案在ACME内部打磨了10年才形成目前的规模，所以技术趋势是做出来的，不是跟出来的，ACME用实践告诉了我们这个道理。
3、应用安全风险
应用安全风险粗略的分成了框架类通杀漏洞、大规模窃取用户数据漏洞、开源软件漏洞、开发和开发之间的信任调用导致的漏洞以及供应链漏洞。
框架类漏洞大家可能了解的比较清楚，例如Struts2、Spring等出现的漏洞，可以导致整个企业面临巨大的风险，修复难度也比较大，需要投入大量的人力成本去进行修复；
大规模窃取用户数据漏洞是上云企业CXO这个层面非常关注的点，例如通过利用高权限AK进行数据窃取，云平台底层会不会查看和窃取用户数据等；还有滥用各种数据对象存储类的AWS S3、Azure Blob等，其实数据对象存储类对于AWS、Azure自身也有很多高危风险的泄露案例，可导致泄露自身的数据、客户的数据、代码等，国内的云安全厂商对这块的风险还是要加强重视；
开源软件漏洞：因为云平台采用了大量的开源进行了构建，例如数据库采用MySQL、底层分析采用ELK、虚拟机采用KVM，XEN、云原生采用了K8s等等问题，一旦这些开源软件出现问题，会直接导致巨大的攻击面，而且这些产品都承载着用户的数据，所以一旦被入侵后果非常的严重；
开发和开发之间的信任调用导致的漏洞：这个点是我在2016年在做云的红蓝军对抗的时候发现的问题，因为云的架构的复杂性，每个产品会采用非常长的调用链路，这个环节上包含非常复杂的各种组件，一个产品包含上百个组件也是经常有的情况，但是问题来了，由于研发缺少这个维度的思维，默认认为传递过来的数据是可信的，没有进行很好的过滤，导致会出现严重的问题，而且这种问题对于企业的黑、白、灰盒来说非常难以发现。例如组件A是控制台，用于处理用户的输入参数P1，参数P1透传到组件B，B进行处理之后传递给组件C，C处理的时候直接带入了命令执行的参数进行了拼接，最终导致通过用户的三个传递最终形成了命令执行的例子，当然这样的例子也非常多，这里只是简化讲了一下，由于牵扯漏洞细节，所以用一些通用的描述方法，读者如不清楚，请到最后的章节练习微信讨论。
供应链漏洞：这是上云企业面临的一个较大的问题，由于自身业务的复杂性，必须使用各种各样的开发包，由于是这样的超大型企业的规模下，这里面每个点都可能造成风险，举个例子来说，ACME企业的某个应用采用了Nodejs Express作为自己的开发框架，由于有非常多的业务需求，所以采用了自研组件TaskCheckJson这个组件（黑客经过层层分析发现了这个点，在NPM上申请了这个不存在的组件），这个组件只能在内部进行调用，简单点说由于某些原因导致ACME企业的某个员工直接引用了公网NPM的TaskCheckJson，最终导致被入侵。
4、系统安全风险
一旦被突破了层层防御，包括应用层、网络层达到系统层，黑客会执行命令，会进行数据窃取，会进行横向移动，ACME企业采用了及其先进的方法模块化、eBPF、进程分离、影响面最小等构建的EDR来应对这些威胁（后面会讲到）。
5、数据安全风险
黑客入侵之后还远远未结束，而笔者觉得这才刚刚开始，黑客入侵都是带有极强的目的性的，ACME通过多年的国家级对抗也发现了黑客最重要的还是看上了ACME的核心的这些数据，这些数据有巨大的价值。所以数据泄露是企业的安全生命线，是企业的底线，是企业生存的命脉所以为了对抗，ACME采用了Zero Touch Prod、Zero Touch Network的先进理念来降低这块的风险。
ACME混合云安全发展历程
概述
前面铺垫了这些久，终于开始进入正题了，也感谢读者的耐心阅读，为了更好的引入ACME混合云安全技术体系，本章还是先交代一些ACME发展的历程，帮助读者可以很好的理解对应的发展，有了这几个阶段，相信能给很多超大型企业有一些良好的输入和发展的概念，下面的时间点都是YY的，没有理论依据和具体的证据支撑，如有巧合纯属雷同。
传统IDC安全
2006年之前，ACME公司的所有服务器都是采用物理机+虚拟化的方式进行管理，这个时候的安全攻击面入口相对来说比较小，只有对应开放的WEB应用以及ACME对应的企业专线的入口，攻击面相对集中，管控策略得当，容易控制。
云上账号体系
ACME上云之后开始账号非常混乱，权限设计也比较复杂，属于杂乱无章状态，后来经过ACME安全团队、账号团队、架构团队、业务团队的综合评估和最终的高层支持，在2009年开始了账号治理，并且开发了ACME的账号管理平台（内部使用的账号管理，主要是内部的账号申请、云产品审核限制、账号收敛、账号治理等功能，后面会简单讲到），其中ACME Organizations组织管理是一个比较重要的Feature，形成了企业组织树，通过3-5年的产品推广，目前覆盖了大量的云产品开始支持ACME Organizations，通过ACME Organizations的组织管理之外，还加入了账号细粒度权限牢笼机制，可以非常严格的限制ACME给BU什么权限，这个BU给下面的部门什么权限，这个部门给下面的每个业务什么权限，这个业务给下面的开发环境、测试环境、生产环境什么权限，牢笼设计非常到位。另外一点非常重要的之前杂乱无章的管理状态，后来经过发展也形成了对应的中心化管理方式，另外对于一个组织来说也可以进行组织化的构成和管理。
逐步开始迁移上云使用VPC
2006年之后，ACME开始计划逐步迁移上云，为了方便维护，ACME上云之后仅仅采用1个大的VPC的方式，利用专线跟IDC机房的业务进行打通，慢慢迁移，在过程中ACME安全架构师发现，在一个大VPC中虽然使用安全组进行隔离，但是仍然存在非常大的横向移动和数据泄露风险，于是开始了下面的VPC拆分计划；
VPC进行细粒度拆分
2010年，ACME安全团队开始进行了VPC拆分计划，策略打法就是新增卡点，存量迁移；首先把大VPC中的业务开始逐步的拆分出去进行存量迁移；每个业务BU新增的业务进行了独立的VPC的业务拆分，利用账号管理平台进行权限分配、账号分配、组织管理分配等内容，原则是一个业务一个VPC，当然如果这个业务VPC如果需要跟大VPC进行通信，可以通过VPC Peer进行打通，经过多层防御体系，包括安全组、VPC ACL、路由隔离、VPCFlow和VPC全流量分析来进行严格的控制，保证第一时间发现新增业务VPC访问大VPC的安全入侵行为。
ACME混合云安全技术体系
概述
码字好累，还是上一张图来看一下整体的ACME混合云安全技术体系的落地架构：
时间有限，图画的比较丑，我快速过一下每个版块的内容：
ACME混合云安全Policy：ACME作为国际化公司，具有国际化视角，极其重视顶层设计，ACME混合云安全Policy就是一个非常顶层的设计，包含基础设施安全策略（系统安全、网络安全、应用安全）等维度，比较重视的是这块维度的安全策略如何制定和实施；一般情况下ACME是三年重新制定一次Policy，半年或者一年进行一次修订，外部的咨询公司可以进行审查策略和实际的执行情况，其他类似不过多赘述；
ACME混合云安全覆盖领域：有了比较顶层的Policy之后需要覆盖如下的领域，系统安全、网络安全、应用安全等等领域，这些领域需要有更细致的落地的检测内容，例如应用安全简单说一下，需要WAF覆盖、RASP覆盖、漏洞数量等等维度；
ACME云产品接入：ACME对云产品的接入采用了上面Policy和安全领域覆盖里面的细粒度的要求，例如对于接入的云产品必须要有数据加密、存储加密、传输加密、接入IAM、支持ACME组织管理、支持细粒度授权等等要求，一旦满足这些要求，作为内部的业务方才可以进行使用；
OneIdentity：OneIdentity平台主要是ACME内部的云账号管理平台，在整个ACME内部只有一套，这套内容包含了云产品接入申请、账号管理、统一的账号生命周期管理例如ACME企业内部的账号的申请，权限变更，账号下线，员工变动自动调整等等策略、统一的审计策略对于所有操作都进行严格的审计、支持ACME的组织管理、统一的权限管理例如可以分配IAM策略、审批流例如申请云产品需要走审批流经过安全审核才可以使用等等内容；另外最重要的是OneIdentity可以对ACME的账号进行收敛到内部，提升账号安全体系；
数据安全和应用安全：数据安全和应用安全主要是使用秘钥管理、WAF、RASP等覆盖，这里必要重要的是ACME的业务逐步开始迁移ServerLess，为了提升安全性，ACME开发了安全容器+语言级Serverless RASP等功能，为了提升Serverless的安全性和隔离性；
VPC安全：这里分成了两种情况，一种是ACME业务构建在ACME云上，采用ECS虚拟机来支撑自身的业务，另外一种是ACME业务构建在云原生基础上，采用了安全容器来进行隔离等，这里的VPC安全还是进行了拆分和设计的，下面我们会逐步展开实现细节；
生产网零信任：为了进一步解决横向移动、数据泄露等问题，ACME在10年+前就开始了进一步的构建基础设施安全层，也就是生产网零信任，之前在Nuke将军的威胁情报一群有过讨论，生产网零信任到底能不能解决数据安全问题，在下面读者会看到对应的陈述；
账号安全
下面我们来谈一下ACME内部的账号安全：
这里面有几个核心概念：
1、组织：ACME这家公司就代表一个组织；
2、Shared Service：共享服务，这些服务包含DNS、活动目录、监控等内容，这个服务是所有其他VPC都需要访问到的一些服务，通过Core Accout来进行管理；这里面也包含对应的安全漏洞扫描服务，可以通过漏洞扫描来进行全网的漏洞评估、检测和修复动作；
3、Network：云上VPC通过Direct Connect和ACME的数据中心（Data Center）进行连接；
4、OU：ACME的下属BU，例如物流等；
这里讲一下核心逻辑：
1、Root账号：首先ACME这个组织有一个主账号Root账号，这个账号只有对应的管理职能，这个账号没有AK，在互联网上也不能进行访问，只作为内部的核心账号管理平台OneIdentity来进行管理用户的账号；
2、BU账号：这个时候通过ACME下发BU主账号，这个时候Root账号根据BU的特性设置了对应的SCP（Service Control Polices）牢笼，设计BU级牢笼，例如这个BU根据业务特点只能访问虚拟机、数据库、安全管理、数据处理服务等等云产品，并且这个BU的账号的权限是直接继承下来的，BU主账号开始赋予下面的业务子账号，不同的BU下面的业务之间是相互隔离和互不影响的，也就是说某个BU下面的业务出现漏洞，如果VPC网络没有打通的话，黑客入侵的权限仅仅是这个业务账号，无法逃脱出来进行更大范围的控制；
3、Core账号：核心（Core）账号用来访问一些通用的服务，这里面具体来讲一下安全服务：包含日志存储Logtail服务、安全日志、ActionTrails等日志以及安全扫描等；基础设施服务：DNS、LDAP/Active Directory、部署工具和平台、监控等；
4、SCP：指定组织中成员账户的最大权限。在 SCP 中，可以限制每个成员账户中的用户和角色可以访问的ACME服务、资源和各个API操作。另外还可以定义有关何时限制对ACME服务、资源和 API 操作的访问的条件。这些限制甚至会覆盖组织内的成员账户的管理员。当ACME Organizations 阻止对某个成员账户对服务、资源或 API 操作的访问时，该账户中的用户或角色将无法访问它。即使成员账户的管理员在 IAM 策略中明确授予此类权限，仍然会阻止访问。
5、其他：其他包含了IAM授权（IP白名单、细粒度访问权限）、审计、CloudTrails日志审计和其他的相关的账号异常威胁检测部分（AK异常调用）就不在赘述了；
身份安全
接着上面讲的内容，ACME CSE团队主要是把内部的IT服务迁移到云上，2000+的应用规模非常巨大，所以ACME CSE团队采用了零信任架构，把整个2000+ IT系统全部接入ACME Midway零信任架构。
上面的图是Azure的零信任架构，简单讲一下Azure零信任架构：
Azure 的零信任相对来说还是比较完善的，从体系角度来看涵盖了端、云、On-Permises、SaaS 等应用，下面我们分析一下相关的组件：
用户 Identity：然后通过 Identity Provider（创建、维护和管理用户身份的组件）的认证，在认证的过程中可以使用账号密码，也可以使用 MFA（Multi Factor Auth）多因素认证的方式，多因素认证包括软、硬 Token、SMS、人体特征等；
设备 Identity：设备包含了公司的设备以及没有统一管理的设备，这些设备的信息，包含 IP 地址、MAC 地址、安装的软件、操作系统版本、补丁状态等存储到 Device Inventory；另外设备也会有相应的 Identity 来证明设备的身份；设备会有对应的设备状态、设备的风险进行判定；
Security Policy Enforcement：通过收集的用户 Identity 以及状态、设备的信息，状态以及 Identity 后，SPE 策略进行综合的判定，同时可以结合 Threat Intelligence 来增强 SPE 的策略判定的范围和准备性；策略的例子包括可以访问后面的 Data、Apps、Infrastructure、Network；
Data：针对数据（Emails、Documents）进行分类、标签、加密的策略；
Apps：可以自适应访问对应的 SaaS 应用和 On-Permises 应用；
Infrastructure：包括 IaaS、PaaS、Container、Serverless 以及 JIT（按需开启访问）和 GIT 版本控制软件；
Network：针对网络交付过程以及内部的微隔离进行策略打通。
ACME稍微有一些不同，ACME为了方便BYOD移动办公和疫情期间的远程办公需求，慢慢把2000+的应用迁移到了互联网上，互联网通过Midway零信任进行认证，这里不同的点是Azure针对自身的访问和合作伙伴的访问是经过MFA短信双因素认证，重要的管理员访问采用了SmartCard的方式，ACME Midway采用了Yubikey的方式来进行访问，增强了安全等级，解决了钓鱼的一些问题，这块ACME采用了和Google MOMA一样等级的登陆方式。也就是说你拿到ACME的账号和密码之后是无法进行登陆的，必须要采用Yubikey的挑战和响应的认证方式后才可以。重要的是2000+应用已经大部分完成了ACME Midway的认证方式的接入。另外一点不同就是ACME Midway有对应的和严格的风控策略，针对IP地址、设备异常、账号安全等做了非常细粒度的风控策略，提升国家级黑客的对抗成本。ACME Midway从攻击面角度来看，裁剪了所有的JS接口，只保存了登陆、密码修改等非常简单的接口，安全性上也得到了很大的提升。
网络安全
针对前面说的风险内容（大VPC风险、专线风险和对应的云原生网络风险），ACME公司具体的做法现在简单讲一下：
1、大VPC风险：针对大VPC的风险，导致的入侵风险，ACME公司采用了两种手段来解决，第一个是新增卡点：经过ACME 安全团队的SDLC流程进行卡点，所有新的业务必须要开启新的账号，并且不能直接在大VPC中部署，新增的业务必须采用新账号、新VPC而且原则是每个业务一个VPC的划分力度，这样经过2-3年时间，ACME公司慢慢形成了制度、流程和对应的工具平台支撑，例如OneIdentity平台，这样形成了良好的VPC架构分离；第二个就是存量的迁移：目前大VPC的业务，除了一些特别重的业务之外，开始逐步迁移出来，逐步减少大VPC的业务；第三点必须要跟大VPC进行通信的，必须要采用严格的策略，包括对端ECS安全互相访问限制、双向VPC ACL、双向VPCFlow分析，双向流量分析等进行严格限制和严密监控，随时启动应急响应流程，另外针对网络安全的SOP应急响应流程非常完善，针对风险能够快速消除风险；
2、专线风险：为了逐步减少专线带来的风险，ACME安全架构师团队跟财务采购进行了审批，为的是卡住新增的专线，这个时候所有的审批专线的钱，必须要经过安全团队的审核，这个是新增卡点；第二个就是存量迁移，存量的专线进行下线梳理和对应的治理，逐步下线专线风险；第三个就是架构升级，采用专线安全接入区，这个区域是专门给专线进行接入的，这个地方部署流量安全、IDS/IPS、全部捕获、加密流量分析、Netflows等综合全面的分析，而且这个安全专线接入区和后台的实际业务形成点到点的访问控制，通过三个治理解决对应的安全风险；
3、云原生网络风险：其实这个风险从我的认知中Google也并未解决，Google也仅仅是做了ALTS的服务和服务的鉴权，另外对于ACME公司来说，构建了ZTPA的生产网零信任架构，加上VPC和账号的隔离，从风险角度也是认可了这个风险；从ACME首席安全架构师的视频中学到了，ACME的风险是按等级进行整改的，基于风险的安全处置方案，经过确认最终CEO、CSO和首席安全架构师接受了这个风险，认为相对较低；另外给阿里云做一个小广告，阿里云的生产网零信任是在四层+七层做的，四层方案也会有对应的身份，通过云原生自身组件的理解和方案的落地进行了云原生网络的身份问题的风险解决；
安全基础设施层
为了提升整个应用安全的层次，包括ACME和Google都构建了基础设施安全层，这一层是把服务之间的通信进行了鉴权，默认服务和服务之间是可信任的。
ACME公司CEO早在2000年左右就提出来了全面SOA化，谁不执行SOA直接开除，就在这种SOA架构的强力推进下，SOA化慢慢开始展现威力，就是因为SOA化，打造了ACME的微服务化，在微服务化的过程中，每一个微服务的API的请求需要另外一个微服务的API的授权，于是乎形成了几十亿上百亿的API关系库，正是因为有这个API关系库，ACME公司可以形成超大规模的API请求级的白名单，利用ACME ZTPA架构，在每台ECS上起一个运行时的守护进程，服务A和服务B之间不会直接进行通过，全部都过运行时的守护进程进行通信，访问关系进行确认。下面简单介绍一下流程：
SOA化维持API注册关系：前面讲到了SOA的背景和一些输入；
服务注册和API级访问申请：服务A首先要在SOA API关系平台注册，包括需要访问的服务B；
同步服务间访问策略和秘钥：把服务A要访问服务B的策略同步给运行时守护进程；
加密请求并使用秘钥签名：服务A访问服务B的请求经过守护进程，守护进程会针对整个请求进行加密和密钥签名，保证机密性、完整性防止被篡改和监听；
使用TLS隧道发送给服务B：服务A利用TLS隧道，双向验证、mTLS等发送请求到服务B；
解密A发过来的请求：这个时候守护进程进行解密A的请求；
校验服务A的授权策略：针对服务A的请求进行验证是否可以直接访问服务B；
处理A的业务请求：这个时候一旦经过策略验证就可以被服务B接受请求，并开始进行业务的处理；
加密响应：服务B加密请求返回服务A；
通过TLS隧道发送请求：通过mTLS隧道把响应发给服务A；
服务A接收返回结果：服务A拿到结果返回给用户；
其中Google BeyondProd做的稍微有一些不同和复杂，但是大概思路都类似，主要是在容器Borg进行了服务和服务之间的鉴权等操作，这块就不展开；
采用基础设施安全层的好处业务无感知，可以快速进行接入，快速提升整个混合云安全的水位，但是这里也有一点不好的地方，就是对工程化、稳定性、安全性要求极高，从安全性角度来说这个里面是整个ACME的基础设施安全层，一旦出现高危风险是不可接受的，所以在这个过程中经过了十年的打磨，升级换代，逐步形成了现在较高的安全水位，对于横向移动的解决提供了终极武器；
系统安全
近期对于系统EDR的威胁检测，笔者又有了深入的认识，从鸟哥谈云安全第二篇的威胁检测来看，笔者近期发现了一个非常牛的点，那就是Azure是单进程而且是模块化的。从第二篇文章可以看到，不管是SQL的漏洞、基线检查、漏洞检测全部都采用单模块并发进行。对于一些重要的核心业务可以进行定制化的裁剪，针对不同的云产品、系统（物理机、ECS、容器、Serverless等形态）可以做到不同的检测。
下面介绍一下ACME EDR的架构：首先ACME升级到了Linux 4.x的内核，是支持eBPF的模块，这里还是简单给大家介绍一下eBPF；
首先讲解一下BPF：Berkeley Packet Filter, BPF 提供了强大的网络包过滤规则，可以确定应该检查哪些流量、忽略哪些流量等，而内核近几年发展的 Extended BPF, eBPF 实际上将应用范围，处理效率进行了更新。
eBPF 是 Linux 内核近几年最为引人注目的特性之一，通过内核内置的字节码虚拟机，完成数据包过滤、调用栈跟踪、耗时统计、热点分析等等高级功能。
从上面的图上可以看到eBPF支持的范围包含File Systems（文件系统）、TCP/UDP（网络）、IP、VFS（虚拟文件系统）、System Call Interface（系统调用）、Sockets、Device Driver、Virtual Memory（虚拟内存）等内容；目前为应用与内核打造了一座桥梁，在系统跟踪、观测、性能调优、安全和网络等领域发挥重要的角色。为 Service Mesh 打造了具备 API 感知和安全高效的容器网络方案 Cilium，其底层正是基于 eBPF 技术。
介绍完了eBPF之后，开始介绍一下ACME的最佳实践，因为ACME业务的复杂性，最初的ACME安全团队构建了基础的eBPF检测模块，后来因为ACME的开放性，慢慢的更多人进行了完善和采集，而且由于ACME SOA化，很多EDR的检测模块也被进行了模块化处理，导致ACME内部有非常多的EDR模块可以选择，业务可以灵活根据内部的类型进行检测，例如我是EC2团队，我可以选择跟虚拟化逃逸相关的EDR检测模块，而裁剪掉应用层的威胁检测模块，这样大大提升了威胁检测的灵活性，而且重要的是EDR的模块化后全部采用的是单进程模式，可以方便的进行组装、组合，来应对不同的场景，做到了千系统千面的威胁检测能力，让威胁检测模块不再是单一的检测能力，极大扩大了灵活性、稳定性、工程化等。
应用安全
提到SDLC，读者们肯定不会陌生，相信读者的企业也建立了良好的SDLC的体系，从培训、需求、设计、开发、测试、上线等流程上也做了非常多的工作；这里不再针对这些内容进行赘述，笔者针对ACME公司做的比较好的亮点进行展开：
1、安全公司排名漏洞挖掘：前面已经讲到了利用自身业务进行业务VPC化划分的逻辑，ACME公司在架构评审阶段，会让业务填写Checklist，把业务的描述、业务的数据敏感度、业务的未来规模、业务是否跟大VPC相连接、业务的重要程度等等维度进行综合排名，如无较大风险或者可接受风险，这个时候SDLC除了过正常的黑、白、灰盒之外，会直接让这个业务系统上预发环境，在预发环境中，邀请50+安全厂商中的其中2-3家进行安全的漏洞挖掘，一旦发现漏洞，会直接进行漏洞的修复，节省ACME公司的人员，另外一点重要的就是，或者说比较狠的就是，会针对这50+安全厂商进行综合的排名算分，包括你的漏洞挖掘时长、漏洞挖掘的深度、漏洞的质量、漏洞的等级、漏洞修复的建议等等维度进行评审，每半年和一件进行一批淘汰，针对产出不明显的公司进行淘汰，让50+安全厂商形成良性竞争，保证质量结果。通过ACME公司也会针对具体的安全厂商进行观察和评判，准入标准非常严格。笔者有幸跟其中2-3家公司进行了交流，这些渗透测试公司的Checklist非常针对，有兴趣的读者可以跟我联系，Checklist可以小范围分享。
2、构建漏洞大规模升级延迟方案：因为有了RASP、eBPF和安全基础设施Aspect层的安全方案，内部的研发不会采用大规模升级的方法来打扰到研发，研发可以进行正常的排期漏洞修复即可。
数据安全（部分解决）
1、Zero Touch Prod（来自翻译的Google安全新书内容）
Zero Touch Prod是Google的一个项目，要求生产中的每项变更都必须由自动化（而不是人）进行，由软件进行预验证或通过经过审核的安全机制来触发。安全代理是Google用来实现这些原则的系列工具之一。估计，在谷歌评估的所有停机中，约13%的停机可以通过Zero Touch Prod来预防或缓解。
Google安全代理的实现：首先员工申请执行Borg的命令，利用代理工具发送命令到工具代理上，进而触发外部审批流程，审批通过之后才可以发送命令给Borg集群。
所以笔者认为Zero Touch Prod和Zero Touch Network是为了减少人员的接触导致的数据泄露风险、同时也减少了数据的泄露。
而ACME CSO也提出了《Humans and Data Don’t Mix》的方式，人和数据进行分离，解决部分数据安全问题。
2、BeyondProd
BeyondProd白皮书中讲到了一句：BeyondProd用于跨服务强制执行一致政策的关卡。例如，一个用于验证访问用户数据的请求的关卡，以确保服务的访问来自于获得授权的最终用户发出且经过验证的请求，并且管理员的访问需要提供正当的理由。笔者认为用了安全基础设施层+安全代理+Zero Touch Prod等等措施，可以有效的减少一些数据安全泄露的事件发生，如果大家觉得有其他想法，也可以进行交流。
笔者认为ACME通过Humans and Data Don"t MIX+Zero Touch Prod+安全基础设施层，完美的把内部员工定义为高危风险，最终严格限制这些员工的访问，对于服务的访问，又会是另外一个话题了。
总结
感谢各位看官能耐心看到这里，笔者经过这篇文章的编写也梳理了对应的ACME公司的一些顶层设计的思路和发展的历程，笔者非常欣喜，能够通过51劳动节快速梳理形成文章，非常开心。希望这篇文章能够给一些云厂商、政府、金融、大型政府带来一些输入，能够把云上比云下更安全的实际效果坐实，让更多人看到云安全体系的完备性，打消掉监管机构对于云的一些顾虑，能够引发更多人的讨论和完善，本文只是抛砖引玉的给出了一些好的混合云安全最佳实践，码字的过程就是梳理学习细节的过程。
另外笔者在参加近期组织的推演中，发现了一些重要行业防御上的一些短板，笔者敏锐的观察到了这是一次关键基础设施的安全基础设施架构升级的重大机会，借此笔者会在下篇鸟哥谈云安全文章中会重点介绍一下笔者认为的零信任架构到底是什么样的、结束什么样的问题、带来了什么样的变化、有哪些巨大的坑等问题，内容包含生产网零信任以及办公网零信任等内容，并且深入一些实现细节来深刻的形成一些思路给到国内的关键基础设施行业。
另行文比较仓促如有问题、建议、意见和写的不对的地方，请读者不吝指教，另可联系@ThreatSource的微信进行更加深入的交流。如有兴趣希望大家多多交流。再次感谢读者的耐心阅读，祝各位51劳动节快乐。
声明：本文来自鸟哥谈云安全，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
