鸟哥谈云原生安全最佳实践

嘉宾 | 鸟哥整理 | 孙正印

出品 | CSDN云原生

2022年6月7日，在CSDN云原生系列在线峰会第7期“安全技术峰会”上，鸟哥谈安全公众号作者、某互联网公司云化办公安全架构师鸟哥分享了Google、阿里巴巴的云原生安全最佳实践。

云原生安全的定义

Gartner定义的大一统云原生安全包括三方面：云安全、应用安全（DevSecOps）和运行时保护。

其中，云安全可以分成五个层面：

第一层是架构及代码的扫描能力
第二层是网络配置和安全策略
第三层是CIEM，也称之为特权管理和AK管理
第四层是K8s的安全态势，包括K8s的安全配置和Pod的安全策略
第五层是CSPM，主要是数据泄露，在云上的所有云产品都可以通过CSPM做对应的配置检查，来保证不安全的配置没有开放到互联网

DevSecOps是应用安全主流方式，在Dev阶段主要做的事情是能够进行左移，充分减少上线后的修复成本。

而狭义的云原生安全框架如下图所示，可以看出，最底层是容器层。

以阿里容器为例，它是构建在ASI（Alibaba Serverless Infrastructure）底座的ECS基础上，以ASI Pod的形式运行，所以最底层单个容器做了沙箱隔离。容器和容器之间需要网络调用，这个过程涉及到网络的容器安全可视化默认的安全策略，还有微隔离策略，网络策略之上可能是整个认证。

运行时之上是服务之间的鉴权双向通信身份的标识，还有身份认证、Workload Pod的统一身份安全认证等；在应用层中，包含白盒WAF的防御、DevSecOps、黑盒API的安全、DDoS、软件包的管理签名。

在供应链中，Google也定义了一些元数据的标准，把供应链做得更细致化，包含了源代码的安全，在引用过程中的二进制的代码安全和三方的安全，形成了狭义的云原生安全框架。

Google的云原生安全实践

Google的云原生安全方案非常具有代表性，基于容器化Borg平台，在业务网里面构建了安全的基础设施层，通过基础设施层为上面的业务提供默认的安全防御能力。

Google Borg

如下图所示，Google Borg包括六个核心组件和四个攻击面。

六个核心组件：

Cell：集群
BorgMaster：每个Cell集群一个，有多台应对单点进行容灾
Borglet：被动接受来自BorgMaster的指令
Link Shard：只把提交变化的数据给BorgMaster
Paxos：分布式系统中一致性存储
Scheduler：调度（ Feasibility Checking 、Scroing）

四个攻击面：

BorgMaster：验证来自调用方的调用鉴权、链路加密
Paxos：Paxos的鉴权、链路加密
Borglet：被调用的鉴权、链路加密、集群信任管理
Task：Task的隔离及沙箱、多租户、网络级访问控制

BeyondProd

如上图所示，BeyondProd分成A、B、C、D四个步骤：

请求数据
请求路由服务
认证和鉴权
请求对应的用户数据

初识时，用户发起对应用的访问，首先会经过Google Front End做DDoS对应的防护和SSL协议的卸载。

然后，通过ALTS协议和mTLS双向链路加密访问，把请求转发到Application Front应用前端，把用户的身份转成对应的服务和服务的身份，通过End User鉴权服务进行转换，携带对应的EUC Ticket进行服务和服务之间的鉴权，最后进行对应的后端存储的数据的读取。

这里遵循了五个设计原则：

服务和服务之间是默认不可信的
服务和服务要实现全流的鉴权
服务实现全流的加密，防止被中间人窃听
构建ALTS协议，建立整个服务和服务之间的信任关系
Titan提供硬件信任根，通过硬件信任根构建服务和服务之间的访问体系

分成了三个重要的身份：

第一个是人员的身份，办公人员的身份Identity，为人员访问提供安全基础，用账号密码、MFA认证，向RPC服务提供有效的握手证书
第二个是工作负载的身份，一旦用户的身份通过之后开始访问对应的服务，服务和服务之间通过信任的建立服务身份之间的鉴权
第三个是对应的机器的身份，就是整个物理机。物理机上有两个重要的功能，第一个就是他自己的身份，第二就是它的核心证书，这个证书用于签发Workload和Workload之间的通信

Google ALTS云原生安全协议

Google ALTS协议有如下特点。

透明度：ALTS配置对应用层是透明的。默认情况下，服务RPC受到ALTS的保护。这使应用开发者可以专注于服务的功能逻辑，而无需担心凭据管理或安全配置。在服务到服务连接建立期间，ALTS为应用提供经过身份验证的远程对等身份，此身份可用于精细的授权检查和审核。

先进的加密技术：ALTS使用的所有加密原语和协议都是针对已知攻击进行了修复的最新版本。ALTS在Google控制的机器上运行，这意味着所有受支持的加密协议都可以实现轻松升级和快速部署。

身份模型：ALTS主要通过身份而非主机名执行身份验证。在Google，每个网络实体（例如企业用户、物理机器或生产服务/工作负载）都具有相关联的身份。服务之间的所有通信都需要进行相互验证。

密钥分发：ALTS需要每个工作负载都具有特定身份，该身份表示为一组凭据。这些凭据在初始化期间部署在每个工作负载中，无需用户进行操作。同时，系统将为机器和工作负载针对这些凭据建立信任根和信任链。该系统允许自动证书轮换和撤销，而无需应用开发者进行操作。

可扩缩性：为了支持Google基础架构的庞大规模，ALTS设计为具有极高的可扩缩性。为满足此要求，Google开发了高效的会话恢复功能。

长期有效的连接：经过身份验证的密钥交换加密操作的计算开销非常高昂。为了适应Google基础架构的规模，在初始ALTS握手之后，连接将持续较长时间以提高整体系统性能。

简洁：TLS默认支持旧版协议且具有向后兼容性。ALTS则要简单许多，因为Google同时控制着设计为原生支持ALTS的客户端和服务器。

Google以数据为边界的云原生数据安全

第一个层面是全链路的身份传递和数据跟踪。通过云原生基础设施层，实现用户身份的全链路传递（前端->中间件->数据库）以及全链路数据的跟踪（Trace）等
第二个是以数据为边界的访问控制。它有三个层面：可信标识、可信资源、可信网络

Google可信体系：构建云原生可信根体系

第一个是可信标识，只有受信任的身份才能访问对应的资源，基于资源的访问策略，设置可信的身份。

第二个是可信的资源，对应的身份只能访问受信任的资源，通过scps层面来做对应的资源访问限制。

第三个是可信网络，对应的资源和数据只能从预期的网络进行发起。

构建云原生可信根体系，它的安全设计理念就是用更少的代码提升更高的安全。首先，Google通过自研的Titan芯片保存了整个BeyondProd里面核心的身份，以及对应的机器身份来进行信任根的传递。其次，Google进行了攻击面的削减，以及对应的KVM的裁剪。这两个层面是构成整个底座安全的可信根。

阿里巴巴的云原生安全实践

2006年，阿里巴巴标志性地开发了自研的互联网中间件，包括HSF、Dubbo。2009年开始自研阿里的飞天操作系统，开启云的时代。2011年T4项目开始容器化，支持在线业务，开启云原生的时代。

2014年淘宝的小型机最终下线，自研的飞天操作系统开始全面支撑，集团业务开始全面上云，2015年开始全面商业化，对外提供服务。2017年开始混沌模式，进行资源值的统一，支持百万级的调度。2019年阿里的核心系统100%上云，2020年创建了云原生的技术委员会，开启了整个云原生时代的service时代。

阿里开始全面云原生化，在这个过程中需要对架构做升级，实现应用之间的微隔离。设计了一套更完整的方案，实现了三四层的网络级认证和鉴权。

阿里的原生访问模型有两个Pod，可能是在一台机器，也可能在不同的机器之间有对应的隔离。

Pod和Pod之间承载了对应的业务A和业务B。业务A和业务B进行互信访问时，首先要在策略中心配置对应的策略，包括拦截模式和观察模式。在拦截模式情况下，如果业务C来访问是没有访问权限的，没有办法访问对应的业务A和业务B，由此实现了策略阻断。

业务A和业务B有了访问关系之后，可以在整个原生的基础设施层进行注入Sidercar行实现应用级的微隔离，通过这种方式来阻断对应的非可信的横向移动，通过访问策略把对应的日志输出到整个云的SIEM，通过云的SIEM分析入侵情况，一旦发现入侵时，可以进行策略的下发，直接阻断。

未来是端到端的云原生零信任架构

未来3-5年，云原生安全发展将呈现两个方向。

员工侧：实现员工的身份可信+内部应用安全云原生化，进而形成端到端安全体系
云化业务：未来更多的业务通过云原生承载，在云原生上实现云原生安全全链路的体系发展方向（芯片->硬件->云->云原生->云原生业务->数据），构建端到端的原生零信任架构

聚焦云原生新技术、新实践，帮助开发者群体赢在开发范式转移的新时代。欢迎关注CSDN云原生微信公众号～