云厂商视角安全_云服务厂商「建议收藏」

1. 公有云安全（AWS、Azure、Google）
早期：AWS， 租户层面安全
AWS安全模块化，安全最佳实践，客户的安全体系

AWS组织管理、VPC的安全架构管理、美国国防部做的SCCA安全架构

云平台的SDL和内部的安全架构

Google的底层安全架构非常完善，虚拟化安全体系包括： KVM漏洞挖掘、QEMU代码重构、业界第一个重构QEMU的沙箱、gVisor、业界第一个可信实例、Titan芯片、BeyondCorp、BeyondProd、 Zero Touch Prod、Zero Touch Network等等一些底层的安全实现思路（基础设施安全）

Azure安全收入已经100亿美金， Azure会减少跟AWS的收入差距甚至超越AWS.

Azure的安全架构整体安全思路和架构还是比较偏传统厂商，内部的网络安全架构、云防火墙的架构， Azure这一架构符合Azure ToB、 ToG的业务场景， 所以做的架构比较传统。

Azure的安全已经开始发力，Azure AD Conditional Access 、 Office 365安全、 Azure Active Directory、微软终端安全、Sharepoint Online、Exchange Online、 Microsoft Teams安全、Azure Information Protection、 Azure Defender系列，都有强力的客户需求， 这些需求都非常贴近实际需求的， 大部分的客户上云之后必须要跟Azure Active Directory 进行融合， 融合的过程中需要Azure AD Conditional Access 和针对SaaS的CASB等认证和DLP的需求。

另外上云之后文档、邮箱都开始使用Azure Sharepoint Online和Exchange Online等，OnPermises域和Azure Active Directory的域打通， 必须使用Azure Defender For Identity。Azure之后对于企业办公包括聊天、文件处理、文件共享等办公场景，还有终端安全保护、云上的DLP、CASB、统一的身份认证等都非常完善了， AAG的云特点讨论云安全架构和云安全技术的两点。

云安全面临的风险：

1、国家级对抗风险

其实从我个人角度我发现，国家级对抗已经特别关注云安全了，不管是SolarWinds针对微软的攻击（窃取Azure部分少量核心代码）还是从一些公开途径了解到的AWS的一些安全防护思路（假设美国也会攻击、其他国家也会攻击）的思路来做的全链路加密（针对光纤进行物理、链路层、应用层加密）、检测针对监听光纤的行为和动作进行告警，安全团队进行应急响应。

因为云承载了大量核心的客户数据，这些数据是客户甚至一个国家的重要资源，所以美国一直在打压中国不能让中国的云厂商在美国落地生根，发展壮大。如果能针对云平台进行控制，那影响的后果绝对非常大的，云上面承载客户的数据太多了，还包括政府的数据（疫情、疾控等数据）、美国国防部的DIB计划（武器数据）、国家人力情报（OPM等人力数据）、高科技企业（微软、Amazon）等。

 

所以对于云厂商来说每年数十亿的投入、大量的顶尖安全人才、核心的云安全技术都是云厂商特别关注的，说真的云和云安全更需要创新技术、更渴望顶尖的安全架构、更渴望有理想的追梦和同路的技术大牛、更渴望客户提出更高的安全要求、更渴望把技术做深入解决客户面临的APT攻击，保证国家新基建数字化转型过程中的关键基础设施的安全增强和落地。

 

2、上云后面临的风险

 

① 企业上云后的云侧风险

 

云上安全风险是企业上云之后，混合云环境下面临的巨大风险，包含AK凭证风险、云上默认配置导致的风险、云厂商自身的信任问题导致的风险；

 

AK特权凭证泄露：云上的AK存在较高的权限，利用获取到的AK可以进行这个AK拥有权限内的各种操作，导致入侵和数据泄露的风险，这块有非常多的公开材料可以参考，不再赘述；

 

云上默认配置导致的风险：企业上云之后采用了大量的云产品，这些云产品默认配置会有风险，例如采用对象存储用户配置之后可以进行Public的访问，可导致数据、代码等被直接访问；

 

云厂商自身的信任问题导致的风险：由于云厂商的一些信任导致的安全风险，举例来说数据类产品本来有IP白名单保护，但是可以通过一些漏洞绕过这个限制。

② 基础设施安全风险

 

网络安全风险：上云之后面临的最大风险就是账号风险以及网络安全风险，主要是账号混乱和VPC设计混乱导致横向移动；

 

应用安全风险：粗略的分成了框架类通杀漏洞、大规模窃取用户数据漏洞、开源软件漏洞、开发和开发之间的信任调用导致的漏洞以及供应链漏洞（详情参考https://mp.weixin.qq.com/s/xkeNxE99ORtVs9EOv0ellQ）；

系统安全风险：一旦被突破了层层防御，包括应用层、网络层达到系统层，黑客会执行命令，会进行数据窃取，会进行横向移动；

数据安全风险：数据安全才是黑客入侵的开始，所以黑客会从各个云的渠道窃取数据，造成数据泄露风险，由于云的API普遍化，数据窃取也形成了工具化、快速化的方式转变。

第三部分：云安全架构亮点

 

1、可信+零信任架构

零信任现在炒的火热，从个人观点来看业界是分三层零信任的：

第一种是针对企业办公网的零信任，代表作是Google BeyondCorp，面向的对象主要适合企业内部的各类员工，包括IT、财务、法务、运营等人员，提升他们的安全性，主要思想是免除企业的特权网络以及访问权限完全是取决于用户和设备的身份，不考虑企业内部员工和用户所在的网络位置；

第二种是针对企业内网东西向横向隔离提出的零信任，主要代表是Google BeyondProd、Amazon CloudAuth、Alibaba ZTPA(Zero Trust Prod Access)主要解决的问题内网横向移动隔离、默认认证鉴权、默认携带身份等能力，构建以身份为下一代的基础设施安全层，Google、Amazon和Alibaba都面临着三种典型的场景，后续会讲到三家基础设施安全层的区别；

 

第三种就是面向租户侧的零信任，主要是针对互联网产品用户侧的访问控制，例如Azure AD Conditional Access、Okta、Auth0为代表的，解决用户侧零信任问题，主要包括提供MFA、持续验证能力、Conditional Access（风控引擎）等。下面我们抽取生产网和办公网的代表架构来做讲解和分析，关于Okta、Auth0等可参考一下相关材料。

对于企业办公网零信任来说，国内外有大量的初创公司和安全大厂投入其中，个人观点解决的最核心的问题面对一些高价值(High Value Assets)企业用户的核心资产来看，一旦被APT组织突破边界，那么就可以利用内网中的默认信任进行渗透，包括之前Google Aurora攻击事件，那次攻击事件之后Google开始了架构升级，默认假设边界是不安全的，需要把目前的安全架构进行升级，Google BeyondCorp对于企业员工的管理就是慢慢去除VPN，核心逻辑使用Google Login(MOMA)登录内部相关的系统，采用硬件YubiKey方式杜绝钓鱼式攻击，使用安全设备（采集15+个类别200+采集点，并且高安全等级用户采用了TPM）、用户层认证等信息通过Access Control Engine来进行持续的验证和设备、用户、身份、应用权限的检查，一旦通过之后既可访问后台有分配对应权限的应用，并且在访问过程中不断验证各种维度的信息。

虽然Google首先提出了BeyondCorp并且有了对应的商业化能力，但从我观点来看，我还是更加看好AACA（Azure AD Conditional Access）。下面上一张图来看看整个AACA的架构：

这张图我就不展开了一一介绍了，大家肯定也在很多地方看过这张图了，也比较熟悉，我更多说说AACA架构的亮点，和一些我观察到的点。

在2019年疫情期间的时候，我通过观察世界500强一个月的相关的域名解析记录追踪，发现了使用Azure云的比例提升较快，其实基于这个点我加速了针对Azure的研究，我发现在疫情期间AACA的架构相对来说还是会比较弱的，但是仅仅拿到账号密码就能够进行登录，包括当时Amazon电商和AWS登录都是这种安全状态，相对来说安全等级还是比较低的。

随着疫情的慢慢变化，导致黑客攻击越来越多，对于采用Azure云的这些客户来说安全性遇到了巨大挑战，Azure、Amazon、Google对于自身的员工安全等级很高（后面会讲到Azure的最佳实践），但是对于Azure、AWS上的用户来说，大家同时开始发力，在同年7月增加了Device认证，2020年1月份打通了Intune、Citrix、VMWare、Citrix等MDM的生态，2021年截至到目前已经支持众多MDM厂商，企业原来管理自己设备的平台也可以跟AACA进行整合，扩大了整个AACA设备认证的生态。

在2020年除了Device生态之外也增加了一些针对AACA的攻击增强手段，提供了Header验证功能来提升Password Spraying对抗。目前Azure也提出了新的安全能力，提供可验证凭证的架构体系，对身份进行彻底的变革，分散标式身份识别方法 (DID：参考文档https://docs.microsoft.com/zh-cn/azure/active-directory/verifiable-credentials/decentralized-identifier-overview)方式来改变目前的一些身份安全性。

另外从安全性上来说，我也发现在2019年的时候通过密码窃取、Password Spraying等方式的难度大大增加，后来有了Device对抗，有了全新的Password Spraying对抗，有了社工库密码的查询（国外常见的泄露的库是无法进行登录的，个人猜测是跟HaveIBeenPwned进行了合作），全面提升账号安全性对抗。所以从黑客视角来看，这种零信任架构还是有对抗和进行持续安全能力和架构在提升的。但是从国家级APT组织和黑客来看，目前微软的身份认证架构还是存在一些分析的，例如可以绕过login.microsoftonline.com的SSO的限制直接登录绕过登录页面，直接访问后台的业务，当然这种漏洞叫做微软AACA的配置问题也可以的，而且Azure自身也存在各种漏洞可以Bypass MFA等限制。

所以给国内搞零信任的一些个人微小的建议，零信任的端、网关、SDP、Radius、NAC准入等零信任厂商，还是要非常重视零信任产品的安全性的，一旦零信任铺开而出高危漏洞的话，影响的范围都是十分广泛的，请一定要把安全性内嵌零信任当中，而且给参加攻击的同学一些建议，未来的攻防肯定会更聚焦基于零信任的攻击技术，这块也可提前布局研究攻击策略和手法。

 

 

办公网零信任讲完了，下面讲一下我们基础设施安全团队也在落地的一件事，这件事可能是未来5-10年的事情，对于落地、工程化、绩效体系等都有非常大的挑战，但是我们还是花了一年摸清楚了这条路的重要性。

 

生产网零信任主要解决的问题还是服务的默认认证、默认鉴权、默认携带身份，构建以身份为基础设施安全层的架构。我们在了解整个Google BeyondProd、Amazon CloudAuth以及Alibaba ZTPA（Zero Trust Prod Access）之前，还是讲一下各家的基本架构格局。Google是2015年公开了他们的架构Borg容器化的（论文地址：https://research.google/pubs/pub43438/），Borg可以理解是现在Kubernetes的Google内部版，基本上都是基于容器、容器编排、在离线混部、资源统一调度等维度的技术。也就是说Google内部大部分都是部署在容器上的，Google开始发展了容器，发现需要容器编排，容器编排之后发现利用率比较高，需要进行在离线混部，后来在发展到整个Google的统一资源的调度一步一步发展的。

 

同时Google非常重视安全架构，也就是在Borg的过程中涉及了ALTS（在容器层上构建了一套基础设施安全层）， 默认开启加密mTLS、默认针对gRPC进行鉴权和授权以及默认身份绑定实体（人、机器、容器）等，同时Google为了提升安全性，把可信计算也加入了其中，为达到的目的就是保证整个身份体系中整个ALTS根证书的安全性，零信任+可信的架构是未来一个非常高安全等级的必然之路。

下面讲一下Amazon的架构。

Amazon是电商业务，他们上云之后使用了云的EC2等，他们的服务都是基于EC2的所以他们的基础设施安全层，是构建在EC2上的，并不是容器化的。简单来说Amazon CEO Jeff早在20多年前左右就推广了SOA化，SOA化带来的好处就是所有的服务都是微服务的，API化的，所以Amazon维护了双十亿甚至上百亿的关系，每次服务要进行访问另外一个服务的话，是默认都需要进行申请、授权和鉴权的，并且把身份传递到零信任守护进程，详情见下图。阿里巴巴的做法是Google和Amazon的一个结合版，通过基于集团上云云原生化之后做的零信任架构，同时也要支持部分非容器化的业务，形成混合态生产网零信任。详情可以参考下图。Google是基于ALTS+证书+全链路Ticket机制，Amazon是基于SOA化的API网关构建的安全基础设施层，阿里巴巴是混合态、四层和七层构建的基础设施安全层。

2、全链路加密

 

上面云平台和云租户面临的风险的时候讲到了，在网络上美国是有能力来监听海底光纤的，所以明文存储我们也看到了斯诺登曝光的棱镜计划、Xkeyscore等项目的威力了，所以国外很多云厂商的安全性都做的非常高，他们不但要防御国外的APT攻击，还要防御具备顶尖攻击能力的美国。所以不管是Amazon、Azure、Google都有很系统化的针对这块的防御和检测手段的。

 

首先说一下Amazon，Amazon拥有丰富的数据和令美国垂涎的数据，通过这些数据可以做各种各样的事情。Amazon的CSO Stephen Schmidt是FBI出来的，所以对于美国的监控手段也有一些了解。而且慢慢的Amazon电商业务也开始慢慢上AWS云，所以AWS在全链路加密方面做了非常多的工作。下面的图可以看到整个AWS全链路加密的层次。

 

第一层物理层进行了物理的光纤的加密使用AES-256算法。

 

第二层数据链路层使用了IEEE 802.1AE的MACsec AES-256加密，这里还是要重点提一下MACsec的加密方式，MACsec的前提是加密AWS的流量是在运营商网络上进行传递的，默认不相信经过运营商的网络的安全性，另外一个假设就是如果仅仅是应用层加密的话，有可能美国还可以通过激活成功教程存储数据的方式来解密部分流量，所以AWS是进行了多层加密方式来保证安全性的。这种主要是为了防御AWS自身的业务被监听和数据激活成功教程。另外AWS的商业化思维是非常强的，AWS目前在Direct Connect等客户接入网络上，也可以使用MACsec的技术，保证10G和100G网络的安全性，提升因为IPSec流量超过10G而带来的性能问题。

 

第三层就是网络层，针对VPC内部的流量也进行了加密，VPC一般采用Vxlan技术，默认情况下是明文传递的，所以AWS针对VPC的底层加密卸载到Nitro裸金属上，这样的情况下针对Vxlan的流量也是进行加密的；同时跨Region之间的Peering网络组网也是进行链路加密的，同时针对客户采用的Amazon VPN等使用IPSec等协议进行的网络链接也是进行加密的。

 

第四层就是传输层包括Amazon s2n、NLB-TLS、ALB、CloudFront、ACM Intergration等也进行了加密；

 

第五层最后一层也就是应用层包括AWS Crypto SDK和基于KMS的服务端加密等应用层加密方式。

 

Google的方式稍微跟AWS有一些不一样的，Google的网络安全假设也是基于网络数据流向经过的途径进行流量加密的，例如Google认为网络如果经过运营商的话就一定要采用加密通信方式，在Google可控的内部DC（Data Center数据中心）的话，就是可选择加密也可以不选择加密，但是默认情况下一定要进行鉴权的方式提升安全性。

 

Azure跟AWS有一些雷同，也采用了全链路加密的方式，具体的不过多赘述。主要总结一下，其实就是横纵两层加密方式，纵向就是TCP/IP传统的层次，另外横向的就是客户侧入->云厂商内部->客户侧出的逻辑，而为了对抗国家级的攻击，客户侧入->云厂商内部->客户侧出的逻辑就是全链路加密的。这是一种非常值得学习的架构和思路。

 

3、云的安全纵深防御体系

 

其实在我跟很多大型客户、相关的评测机构聊的时候，大家都普遍反馈一个问题，那就是云安全的纵深防御体系到底是什么样子的？边界上部署了WAF、DDoS，然后被突破之后就是VPC之间的隔离、流量监控等、数据出方向进行控制等就是纵深防御体系了？

 

那肯定不是的，我来讲一下我心目中的云的安全纵深防御体系。

 

我实践下来的纵深防御体系是第一点规范和安全策略，规范、安全策略先行，定义好流程、红线、安全规范和你到底解决什么问题；第二点准入机制和统一账号身份管理：云产品接入、内部员工体系、资源的开通、身份的生命周期管理要进行统一管理；第三点账号管理：针对内部账号进行详细的组织管理、分层管理、权限牢笼、IAM落地、审计、访问行为等；第四点网络安全纵深：在云的边界入口处设置纵深防御隔离VPC，把WAF、RASP、CFW、全包捕获、NDR、安全生态产品等防止在类似传统的DMZ区域中，经过这个区域到达后台的业务，另外一点VPC也要按照业务进行详细的拆分，访问云产品的时候有对应的PrivateLink访问；第五点就是这次不详细展开的ISAM（Infrastructure Security Assess Management基础设施态势评估）；第六点是最终的应急响应等安全运营工作。详情见下图：

这个图大家可以看到比我在《鸟哥谈云安全》第三篇中架构进行了进一步的升级，因为逐步的开始清晰了。

我所认为的云安全终态安全架构，首先企业、政府、金融客户必须要有规范和云安全执行策略，规范就是定义清楚了具体要做哪些，安全策略就是要做到什么程度，落地的架构就是最终实际效果和运营的目标是什么。安全规范和安全执行策略包含了云安全的方方面面，最主要的就是账号管理、云产品准入标准、数据安全以及合规以及基础设施安全等。分的领域涵盖系统安全、云上网络安全、应用安全、云账号安全、数据安全、云产品安全、供应链安全和安全生态。

我举一个例子来看一下，账号安全的设计。

 

首先第一步云产品安全要有对应的准入标准，只有允许客户允许的云产品才能准入，包括IAM、日志记录、API调用记录、组织管理的支持和覆盖、Tagging标签管理、数据安全存储标准等等，这个是跟FedRAMP学习的，美国FedRAMP就是要卡住云产品一点点的进行接入准入的，让云的客户使用安全的产品。

第二个就是开发小二拥有的身份和设备的标识，可以参考零信任章节的内容，这里不再赘述。开发小二通过零信任访问OneCloudIdentity平台，OneCloudIdentity平台具备账号管理的各种能力，包括组织管理、统一发布的平台、统一的权限授权管理、生命周期管理、账号回收机制等。

这里介绍一个组织树管理，这个能力还是非常重要的，通过组织树管理，我可以给企业设置一个Root根账号，这个根账号默认不允许通过控制台直接进行登录，需要设置MFA登录方式，没有根AK密钥。同时Root根账号也可以设置一个SCP（Service Control Policy），SCP主要是来设置权限牢笼的，就是说主账号的权限没办法超过这个权限。Root账号下面可以设置Core Account账号，主要用来实施OneSOC、基础设施组件等，例如可以通过OneSOC来收集每个云账号的小SOC的信息，进行统一的处理和响应。还可以针对其他VPC的账号设置基础设施组件，例如DNS、漏洞扫描、YUM包等等。Root账号下也可以设计一个纵深防御的体系账号，用这个账号来部署WAF、RASP、Cloud Firewall云防火墙、全包捕获、NDR网络检测和响应以及安全生态的产品也可以进行部署。其他就是业务级的账号来部署具体的业务了，默认情况下不管是Core Account、纵深防御Account还是业务Account都可以来进行SCP和IAM的双层IAM限制。在VPC里面的业务，也可以针对云产品和自身的一些比较重要的应用使用PrivateLink来做限制，仅允许一个更小范围内的访问，设置PrivateLink的网络牢笼。

最终通过规范和策略知道自己要解决什么问题，利用账号架构、网络纵深防御、应用安全、网络牢笼、权限牢笼构建了一个我认为的云的真正的网络安全纵深防御体系。这个必然是国内云厂商要做的很痛苦的路，毕竟目前大家对于云的组织管理的重视程度还是略有不足和需要提升的，当然也有其他很多的安全项例如数据安全等，这里不再一一展开，但是从纵深防御体系角度来说安全规范、账号体系、VPC隔离体系、纵深防御体系、权限牢笼体系设计的已经比较全面了。

4、数据安全体系

 

其实用户上云之后，如果针对自己的云资产管理的不当的话，会造成很严重的数据安全泄露风险。我个人其实就在给国外云平台漏洞授权挖掘的时候，发现了云厂商的数据库白名单绕过漏洞导致窃取数据、利用AWS S3和Azure Blob进行对应的云厂商自身的数据泄露等（漏洞已上报）。

 

举例子来说，首先某CSP上云之后由于自身的代码开发、编译、上线等需求，直接购买了Azure Blob、AWS S3等对象存储来存储自己的开发编译的中间代码。首先从公网环境来看Azure Blob、AWS S3没有直接进行列举所有文件和目录的漏洞，也直接获取不到相关信息，但是经过分析找到了某CSP的这个代码发布平台，进行了JS的分析，掌握了采用Azure Blob、AWS S3存储代码的逻辑和版本，例如https://commitfiles.blob.core.xxxxxxx.net/coreService/2.3.0.2/UserAccountService.coreService.manifest，这个Mainfest里面包含了所有的这个组件相关的编译下载地址，这样就完美掌握这个某CSP企业的比较核心的编译信息了。

 

所以大家可以想象一下自己使用这些数据库和存储组件的时候，是不是也没使用Private这种模式，也许大家会认为信息存在不对称不会被泄露，但是实际情况呢。讲了这么多，今天不讲数据安全的体系，只讲一个AWS、Google都在提倡的一种减少和杜绝数据安全风险的一个可以看似很简单，但是非常有效果的数据安全架构，那就是AWS CSO Stephen Schmidt提出的Data And Human Don’t Mix以及Google提出的Zero Touch Prod和Zero Touch Network。

 

AWS提出的DHDM的思想，主要是为了减少人访问数据的直接机会，这是一种思想，核心是自动化能力。利用自动化能力、工程化能力、开发能力、变更管理等来减少人访问数据的机会。

 

例如在CI/CD开发阶段，源代码进行自动化的人员Review，一旦有人30天没有开发代码或者开发的代码突然增多和变少，都会出发一些行为异常，利用行为异常发现可能存在的一些风险，把安全隐患左移和掐死到腹中，这样的话恶意代码和有漏洞的一些代码就很难发布到线上，真正做到不打扰研发并且真正的左移。

 

开发阶段的源代码编写阶段之后，来到了Build阶段，这个阶段会进行自动化的黑、白、灰盒的测试，保证漏洞掐死在Build阶段，没办法发布到生产环境，这些全部都是自动化的。

 

过了Build阶段就来到了Release阶段，所有的发布必须通过发布系统进行发布，人是没有办法直接登录系统进行直接操作的，这种行为是被严格禁止的，也就是说Release阶段的发布的二进制、部署的位置、SLB的负载均衡、云账号的权限配置、安全产品的部署等等，全部都是通过IaC和PaC进行的，IaC就是基础设施既代码所有的部署都是Json和Yaml，专门由发布系统来进行解析和发布。PaC是安全策略代码，所有的安全策略和配置全部都是通过策略来进行部署的，例如IAM的策略、云防火墙的统一配置策略等。

 

Release之后来到了维护阶段，这个阶段同样通过自动化的发布跟踪变更系统，来跟进变更，处理变更，人是没有权限访问SSH、RDP的，全部都是通过发布变更系统来处理，但又极其特殊的一些场景需要登录用户数据的生产系统，需要利用访问透明化，一方面内部进行留存时候调查取证或者也可以利用Google Access Transparency这种方式来透明给客户针对数据的访问。AWS的思路相信大家都比较清楚了，AWS的核心就是减少人访问数据的机会，就是利用在开发生命周期、运维生命周期中不断的增强自动化能力，有数据访问的进行审计和访问数据日志透明化给客户的方式来搞。

 

Google Zero Touch Prod和Zero Touch Network都有异曲同工之妙，这里讲一点Google的不同：Google Zero Touch Prod采用了Security Proxy的方式来针对命令进行授权，并且针对Googler访问员工的管理采用了Group管理的方式，目前国内还是RBAC的管理方式，个人感觉使用Group组管理来说会更加的方便，针对在职员工的转岗、调整等有更好的管理方式和权限管理模型。另外分析一下Azure为了解决数据安全问题而设计的运维安全体系：

 

① 运维办公终端安全：System Center Endpoint Protection、Microsoft Endpoint Protection、Microsoft Defender；

 

② 限制来源（SAW）：访问Azure自身的服务需要特权安全终端，SAW包含IP白名单、TPM、命令白名单等等一系列的手段；

 

③ MFA：访问Azure自身的一些管理的服务需要Redmond Smart Card、Windows Hello PIN等高等级的认证手段；

 

④ 按需访问（JIT）：Just In Times按需访问对应的主机，对于Azure平台服务如果员工需要访问客户的数据，客户可以授权JIT Support操作；

 

⑤ Device认证：在2020年7月增加Device认证，目前支持了更高级别的Intune、MDM、MAM等集成设备管理方案，多层确认：确认用户凭证、确认设备签名、确认设备证书、确认设备自身；

 

⑥ 其他Passwordless认证：FIDO2、Windows Hello PIN等等手段，很明显的趋势是Azure不信任SMS，SMS认证级别很低，高等级不会用；

 

⑦ 访问策略风控（Condition Access）：针对登陆的风险，用户层面风险、设备层面风险来进行决策，来决策是否访问IaaS、PaaS、SaaS、IoT、智能设备、Xbox、On-Permises等应用；

 

⑧ 默认安全：Azure存在Leagcy认证，可以让攻击者采用PasswordSpary来进行暴力激活成功教程，这种攻击占比60%-70%左右，Azure提供默认安全选项一键屏蔽Leagcy认证。

 

有些时候Google也不一定神化，其实有些时候是技术架构倒逼安全架构的升级，先有了容器自然出现了容器编排进而出现了Borg，有了Borg的管理过程中遇到了node的管理，发现需要一个信任根来做mTLS的认证，出现了Titan，上层业务在慢慢完善BeyondProd，再进一步完善研发体系成为BAB，另外一套就是说所有的应用有统一的Identity，这个Identity是两套外部用户一套，内部的开发、运维等相关人员一套也就是所谓的OneIdentity，打通研发、运营、SRE等，其实做这些架构最终目的是解决内部数据安全问题。

 

理论上数据安全体系在内部也进行了卡点和收敛，用户的数据访问、应用访问都有限制也就是全链路Ticket或者说全链路Token，用来说微服务的默认权限验证。有了Identity之后也出现了RPC的鉴权体系，统一的身份、统一的鉴权，每个微服务入口鉴权，出口转发Ticket，直到最后一个业务的处理完成反馈数据。因为Google遭遇的Aurora行动，导致内部架构进行了升级，人的访问通过BeyondCorp解决，服务到服务的通过BeyondProd解决。

 

所以安全架构做的是不是世界第一的，还是在基础设施转型的时候是否进行了对应的安全架构升级，安全架构升级之后是否能够持续的迭代和完善，国内的安全圈还是要踏踏实实做深入的基础设施安全技术，而不是过于浮夸追求热点名词和PPT型产品的现状。

 

第四部分：云安全技术亮点

 

1、可信/机密计算

 

提到机密计算的发展，就不得不提Microsoft微软和Intel的合作，小道消息微软为了提升用户的数据安全的体系，让用户更信任公有云，就跟Intel进行了战略合作，其实就是针对Intel SGX进行了详细的设计。这真是一个芯片的安全能力改变了一个行业的数据安全的典型案例，所以这个技术首当其中的成为了最具有亮点的技术。

 

发现微软搞这件事的时候是拜读了《VC3: Trustworthy Data Analytics in the Cloud using SGX》，这篇论文是在2015年微软发布的，当时我记得清清楚楚，这篇文章的发布的时候，Intel SGX还有诸多内存限制，没有办法大规模的利用，当时我也根据VC3这篇论文，在阿里云的城市大脑项目中，跟诸多大神（不一一列举）进行了产品原型的孵化，当时在N个星期内，学会Intel SGX的SDK的开发流程，跟Hadoop进行了整合，跟DataX数据导入导出流程进行了整合，最终完成内部产品“交换宝”原型设计。

 

当时还是非常兴奋的，因为从设计流程、到实现细节都是亲自上手写C++代码、JAVA Native Library C++代码。当然产品是做出来了，但是也付出了惨重的代码。最惨的是一行代码，一个缓冲区溢出一个命令执行，至今都是无法被超越的经典（我代码安全和SDL还不错的，只是赶时间）。

 

当时也做出来了一些有趣的产品，叫做“交换小宝”，用来解决一些离线的威胁情报对客户输出的问题，客户可以拿到全量的数据，但是都是通过SGX进行加密的，密钥也进行保护，在对于威胁情报手机号和IP等枚举上也做了限制，当时觉得还是挺牛逼的。微软提出Azure Confidential Computing主要是为了解决数据在使用过程中的安全性，让CSP云平台无法看到对应的数据。

 

当然这里也要提一下阿里云，仅仅同步一些公开消息：扩展加密计算延展到FPGA讲机器学习模型和数据相关的计算运行在可信环境、跟Mellanox发布智能网卡加密计算，实现可信网络、布局SGX开发栈发布Graphene Golang解决方案、举办SGX应用创意大赛等等，这些并不是全部，近两年也有了更多的发展、国内首发了公有云可信实例、发布业界首个基于SGX2.0和TPM的可信虚拟化实例给高安全等级客户使用：https://mp.weixin.qq.com/s/v9yklMWSN-KPNxtvj_mEYw等等，各位如果感兴趣可以自行搜索。

 

其实很明显的微软、Google、AWS等已经不满足仅仅采用Intel SGX架构的东西了，更在深入布局AMD SEV、ARM TrustZoom、RISC-V Sanctum等，持续扩大基于机密计算/可信计算的技术深度和对应的安全生态。

 

提到安全生态，这个是一个利用技术来解决数据安全信任、数据使用过程中的安全以及可以引发一个安全生态的技术，例如安全生态可以通过实现Intel SGX的数据安全解决方案，实现数据安全交换，数据使用过程中的安全性等等厂商，这些厂商可以开发云上各种客户的场景性的数据安全问题解决方案和产品，来增加云上行业的粘性。

 

下面讲一下做的比较好的Azure的一些应用场景，Azure Confidential Computing nodes on Azure Kubernetes Service（AKS）这个功能主要是指通过底层机密计算底层通过硬件支持的SGX的受信任可执行容器环境来保护数据不受其他应用程序、云的管理员或者CSP服务提供商的影响。通过AKS这个能力，可以将容器应用程序定位为在隔离的、受硬件保护的和可证明的环境中执行。说白了就是提供了Confidential Container实例，把程序和数据跑在这个机密容器中，最终保证数据安全效果的，防止黑客、云的管理员来搞。

 

Azure Confidential Computing virtual machines主要是在虚拟机实例上使用SGX机密计算，说白了就是把硬件SGX透传到了虚拟机中形成了vSGX架构，让虚拟机可以在物理机使用SGX一样在虚拟机使用。SQL Server Always Encryted with secure enclaves主要是给Microsoft SQL Server提供机密计算的功能，进行数据使用过程中的安全。如下图所示：

 

 

客户端明文数据给到SQL Client Driver，SQL Client Driver使用加密算法把数据编程密文，密文进行计算的时候把数据放到基于SGX的Enclave中进行处理，在Enclave中是明文的，但是这块内存区域还是加密的，所以无法通过Dump Memory获取到数据。

 

总体来说基于Intel SGX还是AMD、ARM最终的重要作用就是让客户的数据可以安全上云，保证数据运算过程中，云厂商也是无法获取里面数据的，云厂商的运维还是管理员都是无法直接查看客户的数据。当然对于云的客户来说，在使用SGX进行编码的时候，密钥的管理、应用程序的安全还是要非常重视的，如果SGX Trust的程序代码遭到泄露还是有风险的，所以云的客户要针对SGX的程序进行重点保护的。当然说了这么多，机密计算也不能万能的，这个技术本身只是解决了一些信任的问题，所以云的客户在选择的时候要谨慎筛选。

 

另外一个点要说的，就是国内目前都在搞信创，基于国产芯片的机密计算还是要加速的，毕竟这个技术如果国产芯片非常成熟的话，对于提升信创云的安全性来说还是有一定提升的。

 

下面讲一下我所见到的可信计算布局比较好的厂商。

 

Google的可信体系也是有发展历程的，首先是Google为了增强整个安全体系，开始落地内部的可信计算，也就出现了大家熟知的Titan芯片（技术细节下面聊，先把发展历程搞清楚）。后来随着Titan和可信技术的深入覆盖落地和技术的完善，逐步开始在Google Cloud Platform开始推广，出现了基于Titan的Shielded VM实例。

 

介绍完了发展，再分享一下他们使用的场景。内部的基于Titan芯片做的可信主要是落地场景有几个，解决固件的安全风险、减少Bootkit木马，个人觉得最重要的就是在Google 生产网零信任中的ALTS中来通过安全启动过程验证Google系统软件的完整性，并基于受支持的安全微控制器硬件（Titan）运行。可信完整性检查包括 BIOS、BMC、引导加载程序和操作系统内核上的数字签名验证，并且在Google每台机器均具有通过可信系统（HINT）预配的 ALTS 凭据，并且只有在 HINT 已验证机器启动成功后才能解密。这样保证整个Google生产网零信任BeyondProd的安全性，因为Google是识别Borg容器上物理机的身份的，用来做身份的标识。作为信任传递的根，来逐层验证和传递信任。

 

对于在Google Cloud Platform上的Shielded VM主要是针对Google云上的高安全等级客户来提供的高级安全实例，主要解决以下3个问题：第一个就是保护虚拟机远离高等级威胁，主要解决的威胁包括内部恶意人员、客户固件、内核漏洞等。第二个就是确保Workload可靠可验证，提供安全启动以及度量启动功能，保护虚拟机能够防御Rootkit、启动级恶意软件和内核级恶意软件的威胁。第三个就是提供密钥管理和防重放攻击，生成和保护的密钥存放到虚拟机的vTPM中，并且只有验证过完整性之后才会被调用。

 

其实另外一点就是可信实例除了提升安全性之外，还可以让生态在上面长出来各种各样的针对客户问题，解决客户数据安全问题的可信生态市场。目前的市场的一些情况如下：

 

Azure云市场Fortanix、Anjuna、Anqlave大概17款产品；Google云市场Equinix等，目前从国外云市场来看，目前可信计算的安全生态并没有起来，我个人还是非常看好这个领域的。

 

但是最后还是要在提醒一嘴，机密计算在保护敏感数据方面是非常有用的，但是在使用的过程中也要考虑硬件的安全漏洞，包括SGX自身以及CPU的漏洞，例如某些漏洞可以利用侧信道漏洞攻击，窃取SGX保护的密钥和程序。

2、虚拟化安全防御技术

 

从上面的图我们可以看到Google Cloud Platform的可信体系，大家应该可以看到一个非常重要的技术能力，就是各家针对虚拟化逃逸所做的各种努力的工作。

 

今天我们讲解AAG到底如何做虚拟化安全相关的技术工作的。

 

先说Google，Google首先会针对KVM削减攻击面，主要包括Fuzzing和手工的漏洞挖掘，Google这块也是非常厉害的，发现了为数不多的一些KVM的严重漏洞，证明了其实力。另外现在主流的云厂商都在使用QEMU来做自己的虚拟化的硬件模拟、网卡、音频、USB等设备进行交互，因为QEMU历史上出现了大量的逃逸漏洞，所以Google选择了一条跟其他云厂商不一样的道路，他使用自研的类似QEMU的组件来替换掉了QEMU，并且从Google的安全架构经验来看他认为虚拟化是一定会被逃逸的，所以他们在类似QEMU的组件上启了沙箱，大家可能觉得这个技术也许不是特别神奇，但是大家可以想一下，云计算的性能、稳定性都是有极高要求的，可能损失1%的CPU就会对性能造成巨大的损失，而且从收入角度来也会影响收入，也许1%的性能小号，就要投入上千万美金的硬件投入和损失上亿的收入，这个真的不是夸张的，这个是我们评估过的。所以这一点来说还是非常牛的。对工程化、稳定性、安全性都有极高的要求，这个也是我唯一看到在虚拟化层做沙箱的云安全厂商。

 

第二家就是Azure，Azure的虚拟化架构跟其他家都有很大的不同，Azure采用的是Hyper-V架构，在Hyper-V架构的核心几万行代码中Azure完成了代码的形式化验证，保证虚拟化核心模块的真正安全性。Azure工程化也是世界级的，我曾见过Azure CTO演示虚拟机在物理机上跑，物理机直接蓝屏之后，虚拟机没有任何变化的继续跑，可以进行热实例的能力，而达到不影响运行实例的结果。当然这个仅仅是一个DEMO演示，实际的推广和覆盖度还是需要持续观察的。

 

AWS来说就比较体系化一些，下面的图就是我总结的整个虚拟化安全的体系化的架构。详细的内容就不过多解释了。各位一看就懂了。

 

第五部分：总结

 

感谢大家耐心的看完我这个长篇大论，我基本上梳理了一个星期左右，总感觉还是不尽完善。没有真正的讲透彻了清楚，如果各位群里的大佬有疑问，也可以尽情的提问。希望在交流的过程中能够把云安全的风险、安全架构和细节的安全技术聊透彻。分享结束了，感谢大家。

 

—————————————————

 

问答环节：

 

Q1：例如在CI/CD开发阶段，源代码进行自动化的人员Review，一旦有人30天没有开发代码或者开发的代码突然增多和变少，都会出发一些行为异常，利用行为异常发现可能存在的一些风险，把安全隐患左移和掐死到腹中，这样的话恶意代码和有漏洞的一些代码就很难发布到线上，真正做到不打扰研发并且真正的左移。有什么好办法知道开发人员留了后门吗？

 

A：感谢您的提问。其实个人感觉留后门这件事整体上来看还是有很大难度的，后门一定是执行命令吗？能不能写一个遍历ID窃取数据的API接口呢，因为我确实在上家电商的时候遇到过这样的问题，后门有可能是专业人做的，也有可能是非专业人做的，有各种别有用心的议题。所以我认为代码留后门这件事是一个体系化的事。讲一下纯技术层面的，国外就是进行Double Check和Peer结对编程双向Review的，最近大团队内部的人面试了一些国外云安全架构师，他们就是纯人工代码审核，当然不是安全Review，安全Review有白盒、黑盒、灰盒等手段，所以人是一种避免的方式，另外自动化的规则审核也算一种，可以根据一些重要核心的业务来进行定向针对性的检测，个人感觉这是一种运营+安全技术能力的综合搞法。

Q2：鸟哥你怎么看 PA 家的PRISMA 在头部云厂商疯狂叠加安全能力的情况下, 第三方安全厂商空间？只谈美国市场, 不谈国内。

 

A：谢谢李总的提问，问的确认很尖锐，因为说实话国外安全厂商的代表PA、CrowdStrike都在转型云安全，大家也可以看到近几年，PA和CrowdStrike在疯狂的收购跟云安全相关的技术，包括微隔离、容器安全等等。所以我不好说国内的，我仅代表个人观点，从我的认知，我觉得未来是一种合作的模式的，例如PA、CS第一点可以做多云的安全，AWS、Google、Azure等多云安全，所以这是安全公司的一条路，第二条路就是跟云厂商正面开始PK，我也不忌讳，现在是市场经济，谁牛逼就用谁的，全部听客户的，但是我认为做好的产品，不管谁做，能解决客户的问题就是好的安全厂商。

—————————————————

 

Q3：感谢鸟哥分享，请教一下，现在几个csp都提供k8s接口（eks，gke，aks）和容器接口（aecs，ce，acs），这几家不知道谁的安全成熟度比较高一点?

 

A：我个人感觉K8s这块都各有优势，但是我个人还是看好Google GKE和Google Anthos，因为不管HSBC是混合云还是私有云，都能够很好的支撑您的业务，但是这里确实也有一些问题，虽然Google的能力可能比较好一些，但是我觉得可能您们还需要选择专业的容器安全厂商，例如TwistLock、Aqua、Nuevector以及国内的很多容器的厂商，所以我觉得安全成熟度最高的就是Google GKE，但是容器安全要选择专业的厂商更加体系化。容器接口个人还是推荐成熟度更强的，符合自身业务的容器接口。

Q4：感谢鸟哥分享，请教一个问题，从你的落地实践经验上来看你觉得AAG这几家云厂商的安全之路哪个更适合国内企业去对标，最大的潜在挑战是什么？

 

A：这个问题我说的深入一点，我也说说个人观点，华为云从我的角度来看一定是要学习Google的，因为Google的安全体系最深入，最成熟，从个人观察角度来看华为云是被美国认为是关键基础设施云的，所以NSA和CIA会针对华为云进行各种想不到层面的攻击的，包括芯片层面、包括操作系统层面、包括OpenStack开源软件层面和其他开源软件层面等等，所以一定要在BeyondProd、零信任、基础设施安全、芯片安全、OpenStack安全、还有5G安全上，因为我了解5G已经慢慢上了云要进行大的布局和基础设施安全的变革和提升，所以我认为基础设施安全最好的可能就是华为云，这个是因为他可能会遭遇顶尖攻击的思维决定的。

 

—————————————————

 

Q5：问一个问题，AWS的SOA化做统一API平台，Google做borg容器化，从成本、实施难度、运营难度和实现效果而言，那种对安全来说更友好？容器的无状态优势，在安全层面是否反而添加了管控和监测的难度？

 

A：感谢谢总提问，说真的，我个人感觉都很难，成本、实施难度、运营难度和实现效果都很难。因为这些架构是企业的基因，是很难学的，所以个人感觉还是贴近自身业务和技术发展的安全才是最好的一个办法，而不是学人家架构升级、学人家SOA化，这样对于组织来说是十分不利的，感谢谢总的提问，我还是要正式说一下的，我只是想给大家一点点的输入，并不是希望大家和业界来抄这个东西。

—————————————————

 

Q6：谢谢鸟哥，干货满满，开拓了云安全的视野！也问个问题，云安全纵深防御方案，多涉及基础架构安全，落地成本太高，对于普通企业私有云安全建设投入的资源顺序和建设优先级的建议是什么样的？

 

A：确实我分享了非常多的基础设施的安全的亮点，但是说实话确实落地成本太高了，从我自己运营好几朵国家的大的部委的云安全架构来说，而且我也是落地的私有云项目，包括群里也有我的一些客户和甲方爸爸，所以我认为第一点是租户层的安全，一定要保证您企业的代码的安全流程，DevSecOps要一定够完善，第二步就是假设这些代码是不安全的，所以我要部署WAF、DDoS和RASP，第三步就是我要利用私有云做好VPC的隔离网络的隔离，第四步就是我肯定会假设被入侵了，所以我选择的是云的SOC，云的Agent来说威胁检测和响应，投入对应的运营团队。云平台侧的，请相信我们这些云安全厂商，我们会尽我们100%的努力和决心做好底层平台安全。

 

—————————————————

 

Q7：整体的安全建设，都在走基础设施融合路线，这对于乙方厂商不是一个好消息。

 

A：确实是的，但是我仅仅代表我个人观点，我个人希望云厂商做好底层的安全架构，包括分布式操作系统安全这些能力，底层一定要让我们专业的团队和人员来保证底层，但是对乙方来说底层的安全其实很难的，就是xi4oyu总说的不是一个好消息，所以个人感觉租户层是乙方厂商的一个大可为的地方，云厂商要开放心态，让更强的安全厂商接入进来，一起构建生态，为客户解决问题，为TOB、TOG来一起解决，共同发展和完善。

 

—————————————————

 

Q8：”Release之后来到了维护阶段……目前国内还是RBAC的管理方式，个人感觉使用Group组管理来说会更加的方便，针对在职员工的转岗、调整等有更好的管理方式和权限管理模型。”鸟哥，想了解一下这个组授权模型，后面的资源怎么分配？是归类吗还是原来的资源码管理方式？

 

A：我来解释一下Google Group管理的模型，首先企业有员工，现在大家大部分的管理方式还是通过RBAC的方式，你有什么权限就做什么事。Google Group组管理，其实变了一种玩法和模式，首先我是一个员工，我加入了运维业务A的Group，这个组的组管理员要进行审批，这个时候组就有了，然后我去访问运维业务A，这个时候运维业务A要维护一套组管理的引擎，也可以叫ABAC，例如例如允许Group Admin来进行访问。我找了个例子：

Example 3-1. Google Tool Proxy Borg policyconfig = {
  
  proxy_role = 'admin-proxy'tools = {
  
  borg = {
  
  mpm = 'client@live'binary_in_mpm = 'borg'any_command = trueallow = ['group:admin']require_mpa_approval_from = ['group:admin-leads']unit_tests = [{
  
  expected = 'ALLOW'command = 'file.borgcfg up'}]}}}

 

—————————————————

 

Q9：诚挚感谢鸟哥的分享。干货满满，学到了很多新知识。我想问一个对于企业核心商密上云风险评估和决策的问题。首先是企业上云必然是趋势，但对于一些大厂来说，走的是混合云建设模式，就必然涉及到哪些信息能上云，哪些不能上。对于企业核心商密上云，大厂是有顾虑的，一方面是云特有的数据安全风险需要去评估、制定策略、执行；另一方面就是云安全的监管，大家把钱放银行觉得比家里安全，那是有一套严格的金融监管体系，数据也是高价值资产，但是现在的云安全的法规及监管对比金融还是要弱一些的，所以企业有顾虑。但是如果企业希望提供全球化的数字化能力，上云是最快的弹性建设方式。鸟哥有什么看法呢？您是如何评估的？

 

A：感谢俞总的提问，这个问题真的感谢，我体会到了您的担心和顾虑，我也回答一下相关的看法，首先对于企业核心商密上云来说，数据安全问题是最最重要的核心问题，所以我实话实说，现在阶段还是私有云的阶段，所以可以在短期内选择私有云来部署，包括金融等机构；您这里提到了一个核心的问题，如果您的企业具有核心商密的话，在中国的企业也分层次的，如果是中兴，我个人非常不建议放到AWS、Amazon和Azure上，这对您企业来说是一个核心的打击，如果美国政府想要看您企业的一些数据，AAG给了的话，这里面对您的企业打击还是很大的。所以在云安全法律法规监管等逐步完善的过程中，又想选择使用云的弹性，做Global全球的业务，建议您走混合云模式，公有云做一些非常简单和少的东西，不放核心的，如果牵扯到机密的数据放到私有云上，私有云和公有云之间进行非常严格的限制和策略，所以这种混合云的场景，第一层是链路加密层，就是公有云和私有云的专线是一定要加密的，使用MACsec类似的机会进行加密，第二层就是要保证双向访问足够的细粒度，按需访问是非常必要的，第三层就是上面要部署双向IDS/IPS进行纵深防御体系，保证流量是可信和能检测的，第四层就是安全运营和响应，保证第一时间处置威胁。更重要的是要对您这边的私有云的数据安全做到Cloud DLP的详细分析和看，保证绝对的数据安全。

 

—————————————————

 

Q10：感谢鸟哥，想请问一下，在使用云上产品时，除了 WAF 和防 DDoS 的配置之外，运维还需重点关注那些问题，能降低或减少被攻击的风险？

 

A：WAF、DDoS是解决应用层的和网络层可用性的攻击问题，从攻击面开始分析，首先要先把开放出去的端口、业务、指纹进行分析，把所有的WAF和重要核心的业务进行DDoS的防护，保证核心业务的高质量。第二步就是要假设会被入侵，WAF说实话也可能会被绕过，所以要在主机、数据库等进行检测和防御，针对入侵行为进行快速的自动化响应等，然后保证核心的数据不被泄露，这样能够算一个比较完善的工作。

 

—————————————————

 

Q11：在混合云中，私有云和公有云的一起使用使业务连接或者共享，这个过程中有什么特别要关注的吗？

 

A：这个是一个非常好的问题，因为现在金融机构和企业机构都是混合云形态，所以会存在私有云和公有云一些使用的场景，所以这种混合云的场景，第一层是链路加密层，就是公有云和私有云的专线是一定要加密的，使用MACsec类似的机会进行加密，第二层就是要保证双向访问足够的细粒度，按需访问是非常必要的，第三层就是上面要部署双向IDS/IPS进行纵深防御体系，保证流量是可信和能检测的，第四层就是安全运营和响应，保证第一时间处置威胁。

 

—————————————————

 

Q12：感谢鸟哥分享，请教一个问题，云上那么多措施，也需要人去运营，那么哪些方向应该做为重点关注？

 

A：云上安全措施非常多，要做的事情也非常多，所以需要投入一些资源，所以可以选择MSSP云安全的托管服务，因为这些厂商比较专业，能够帮助客户来解决实际的问题；第二个如果企业有一定规模的情况下，就会选择自己建设团队，因为云安全的层面还是非常多的，所以需要关注应用安全、账号安全、密钥安全、网络安全、系统安全等等，所以SOAR自动化响应、TDR（威胁检测和响应）、应用层的安全漏洞和攻击面的减少，是重中之重的工作，如果选择一个重要的就是利用云的可见性API，来把资产100%管理好，然后防护做上去，自动化运营慢慢用起来，就能保持一定的安全水位。

今天的文章云厂商视角安全_云服务厂商「建议收藏」分享到此就结束了，感谢您的阅读。