随着数字化经济和远程办公的兴起，网络访问方式的转变，让企业意识到传统的安全防护暗含着巨大的风险。在此背景下，零信任逐渐从概念走向落地，作为新一代的网络架构理念，其核心思想是所有的资产都是身份，所有的流量都需要被看见、被认证，所有资产之间的网络连接必须经过身份认证和授权。

但说概念容易，落地难，业内目前大多企业主要在办公网采用了零信任的安全管理理念或方法，例如Google BeyondCrop。但是对于内部的生产网管控，则很少能有企业，根据新一代的网络架构，真正进行零信任的落地。

阿里云作为国内份额最大的云厂商，内部业务结构多元，访问流量复杂、身份变动频繁，给安全带来了极大的挑战。云安全团队经过多年摸索，将零信任和云原生进行结合，落地并实践了一套身份和微隔离结合的方案，解决了大企业生产网中的隔离问题。

理解新一代网络架构下，零信任的内核：5个假设

零信任的定义一般建立在以下5个假设之下：

• 网络无时无刻不处于危险的环境中
• 网络中自始至终存在外部或内部威胁
• 网络的位置不足以决定网络的可信程度
• 所有的设备、用户和网络流量都应当经过认证和授权
• 安全策略必须是动态的，并基于尽可能多的数据源计算而来

需要特别强调的是：网络的位置不足以决定网络的可信程度。因为从安全运营实践来看，企业内网管理存在着普遍误区：“内网是安全的（办公网和生产网），安全在边界上搞搞就好了”。但从安全事件上来看，带有目的性的入侵，一定会涉及到内网中进一步的横向渗透。如果内网畅通无阻，没有安全防护手段，必将导致严重安全问题。

生产网的零信任尝试：BeyondProd & Istio

在零信任安全的落地实践中，目前广为人知的零信任方案主要集中在办公网。比如经常被提到的Google BeyondCorp，通过将访问权限控制措施从网络边界转移至具体的用户（基于用户、设备的身份而不是设备位置），BeyondCorp 使用户几乎可以在任何地点安全地工作，而不必借助于传统 VPN，安全的访问办公网中的各类系统。

对于生产网内服务之间的零信任方案，业界成熟的方案相对较少。公开、大规模、成熟落地似乎仅有Google BeyondProd。

在开源的k8s架构下，Istio尝试通过service mesh（服务网格）将零信任引入生产网。其核心思想是借助k8s架构，在生产网中每个Pod均部署service mesh sidecar，由于service mesh天然的接管了Pod之间的RPC通信，所以可以在其中增加网络访问的认证、鉴权与安全日志记录。但在实践中我们也发现原生的Istio存在一些问题：

• Istio本身的安全功能未经过生产环境验证，只是Demo阶段
• Istio对于工作负载之间（Peer authentication）的身份认证是通过将RPC协议封装在mtls中实现的。mtls带来的额外计算成本与延时开销相对较大，很多业务难以接受
• Istio仅接管RCP流量，非RPC流量鉴权机制不完善

通过对业内实践的参考，再结合Forrester对“零信任模型“的三个基本理念，阿里云团队在企业内网分步骤落地零信任：

• 检查并记录所有网络流量的日志
• 验证并检查所有来源
• 限制并严格执行访问控制

阿里云的生产网保护，基于零信任的网络微隔离

生产网中南北向的数据通过WAF、防火墙可以做到网络隔离。而对于工作负载之间的通信，也就是东西向流量，缺乏有效的网络安全隔离手段，所以微隔离的核心能力自然是聚焦在东西向流量的隔离管控上。

对于一般的企业生产网，往往仅部署了边界防御设备，如Waf、防火墙。

首先，如果攻击者突破边界防御（WAF、防火墙），或心怀不轨的员工连入生产网，便可直接触内网中的所有工作负载。内网的脆弱性将直接暴露在攻击者面前，且没有有效的隔离手段控制爆炸半径。其次，企业，特别是互联网企业，由于业务快速发展，传统的按照安全域、VPC的隔离手段难以有效的适应业务的快速变化，导致无法有效隔离。最后，随着云原生技术的逐渐普及，k8s开始大规模应用。在云原生环境中，应用实例的工作负载是可迁移的、甚至是短时存在的，一天内可能有几千、甚至上万Pod创建与销毁。传统的通过IP进行隔离的手段将导致频繁的策略变更，策略几乎不可维护。

所以我们寄希望于通过结合云原生技术的网络微隔离将企业生产网分割成弹性可变的N网，以满足业务快速变化的弹性隔离，并且降低入侵后的攻击面，控制爆炸半径。

在实践中，阿里云将零信任的基于身份访问控制与网络微隔离相结合，使用身份进行网络微隔离，降低入侵后的攻击面，以提高企业生产网的安全防御水位。

同时借鉴Istio sidecar的思想，将给基于零信任的网络微隔离下沉至每个工作负载的Pod中，这样从架构层面带来几个好处：

• 随业务工作负载部署，以应用身份为粒度进行网络管理
• 安全能力可以随着业务的弹性扩缩容自动部署
• 安全能力与业务代码解耦，对业务系统无侵入性

在工作负载通信阶段，我们也进行两层的认证、鉴权能力的建设：

在L3/4通信层面附加应用身份，保证连接级别认证、鉴权

在L7通信层面附加应用身份，保证request级别的认证、鉴权

若L7层面无需request级别访问控制，在只开启L3/4层认证、鉴权的情况下可以做到网络性能几乎无损耗，并且支持各种应用层协议

在安全运营层面，阿里云进行分阶段部署与建设：

• 首先确定互联网边界应用、核心业务应用为优先保护对象
• 通过微隔离安全容器的部署，采集了完善的内网东西向流量数据
• 原始的东西向流量数据通过应用身份+资产库信息，将IP之间的访问关系转换成应用身份之间的访问关系，并通过一段时间的观察建立应用间的访问基线
• 在安全策略执行层面，优先对高危服务（SSH、SMB、LDAP、Kerberos等）、关键服务（敏感数据接口等）进行强制的认证、鉴权，提高关键系统的安全隔离水位
• 最后，进行了持续的运营监控。一方面为了防止误拦截导致业务受损，另一方面通过监控内网高危服务流量，发现可以的横向入侵行为或蠕虫感染事件

未来展望

在经过不断探索后，我们发现结合云原生技术，在安全领域可以做出新的创新实践。在过去的一段时间中，各个安全企业一直在思考云原生架构的安全问题，如何保护云原生系统。其实安全可以利用云原生架构的优势，做出新的安全方案。比如将WAF、防火墙能力下沉至sidecar中，随业务快速弹性部署。如果安全sidecar在拥有认证鉴权能力之外，还具备WAF、防火墙的能力，这样可以做到内网安全水位与边界安全水位持平，最大限度的保护每一台工作负载。

在云原生安全的路上，阿里云将持续探索。