关于“零信任”的一些学习和思考

一个好的安全体系的前提是为合法主体建立信任关系，通过信任在保证业务的前提下降低安全成本，在运行时及时检测并消除非法主体的恶意行为，所以信任是网络安全的前提要求。

从主体身份的角度看，主体身份是可能被假冒的，或合法主体在某些条件下会作恶。更具体可参考密码验证登录系统的操作，虽然系统安全策略要求用户设置复杂的密码，并要求定期更新，也不能完全假定用户是可信的。攻击者可以使用钓鱼、拖库等常见的攻击手段，获得用户密码。此外，虽然用户更新的密码复杂，但为了便于记忆，每次使用的密码存在规律性，也容易被破解。所以，现在越来越多的IAM方案采用无密码（Passwordless）、多因子认证MFA、生物技术Biotech等方式。

从资产属性的角度看，防火墙策略中五元组的目的地址所指示的就是被访问资源，但随着业务变更等环境变化，资源的属性也会随之变化，但如果安全策略没有及时更新，还是以之前的网络地址作为五元组的目的地址，显然会出现访问控制失效。事实上，在很多缺乏有效安全运营的大机构，这种现象是非常常见的。现在在一些以风险为基础的模型中，如Gartner的自适应访问控制，安全策略需要根据主体行为等上下文动态调整，这也体现了信任是主观、动态、不确定的。

从策略控制点的角度看，如云中的访问控制，随着虚拟机迁移，主体和资源属性、安全策略都没有发生变化，但资源所在的宿主机变化了，如果还在原宿主机的虚拟网络上执行策略控制，显然无法控制主体的访问行为。又如云中虚拟子网内部的流量不会经过虚拟路由器或虚拟防火墙，如果将这些虚拟设备作为子网内部访问行为的策略控制点，也是不合适的。可见，访问控制点应根据主体和资源间的访问路径进行动态部署，且其数据平面的处置应与控制平面的安全策略一致。

从控制面和数据面分离的角度看，传统的OSI TCP7层协议存在原生地安全问题，鉴权/授权的通道和数据传输的通道是混合在一起的（ip直连），这间接导致了网络缓冲区溢出、暴力破解、内网横向渗透等问题。

所以，一个好的信任管理机制，在控制平面需要保证主体、资源属性与安全策略在运行过程中保持一致；在数据平面，操作控制点能时刻在主体和资源的访问路径上；同时还要注意控制面和数据面要保持合理的独立隔离。

三、零信任的技术路线

到底什么事您想要的“零信任”，各位甲方朋友PPT看了无数版，各方的售前汇报听了好多场，方案过了N版，交付难得头疼也经历了。要想做好这件事，我们需要去对这个底层技术有个了解，反过头再去看我们的“零信访”是不是花拳绣腿，是不是忽悠其中。

0x1：身份和权限管理 技术路线

0x2：网络访问控制 技术路线

BeyondCorps的路线最早见Google BeyondCorps项目，其流程见下图，认证请求是由用户访问的服务发起的，控制点也在服务侧，所以该服务的角色就是代理。

从效果看，这两种技术路线都是隐藏后面的应用，除非用户提供了自己的身份和访问资源，否则用户是无法访问应用的。从部署上看，CSA SDP需要客户端安装Agent，所以环境要求较高，目前主要是应用于替代VPN的场景中，这类公司较多，如Cyxtera、Meta Network、Verizon等。

0x3：区域隔离 技术路线

0x4：应用安全 技术路线 

在SaaS场景中，随着敏捷开发、高效运营的驱动，用户越来越多地使用云原生的架构来开发应用。在云原生场景中，应用的颗粒度会被切得非常细，一个容器通常只运行一个或少数若干进程，故服务称为微服务。所以，通常实现一个业务需要多个微服务的交互，在云原生场景中，服务之间的访问关系非常复杂，不能依靠固化的访问控制逻辑，而是应该按照业务的逻辑确定微服务间的安全策略，划分微服务的边界进行持续有效的隔离，以及在微服务之间应用一致的访问权限控制，就变得非常重要。为了解决这个问题，云原生的系统通常都会有数据和管理平面的鉴权机制。

而在服务网格场景下，零信任还应覆盖微服务间的交互，这部分需要使用面向云原生的服务零信任机制。比较典型的方案是Google的Istio。从功能上看，Istio可为微服务无缝加入认证授权和加密通信的功能。其思想是通过策略控制器，使用Kubernetes的RBAC授权机制，对资源粒度细化到单个服务的访问控制，从而所有的服务交互都是可信的。

• Istio在控制平面上由Citadel组件做认证，Pilot组件做授权

• Istio在数据平面上，在源目的服务旁插入Sidecar容器，截获进出流量，在进行加解密的同时也根据Pilot的策略进行访问控制。

从效果看，如果攻击者没有合法身份，是无法在数据平面横向移动的。因为在网络层设置了网络策略白名单后，网络层的非法访问就被禁止了；而在服务层，微服务Pod的开放服务较少，且都引入了认证和业务层访问控制，攻击者也很难发起非授权的连接。

从数据平面分析，Istio和SDP都需要对网络做比较大的修改。如SDP需要添加IH和AH，客户端需要添加组件，服务端也需要部署代理，而Istio的Sidecar容器也需要部署在所有业务容器旁，且截获流量，通过重写IPTABLES的NAT表的方式将处理完的流量送回业务容器。

从结果观察，因为上述原因，SDP在传统企业网络中部署遇到了非常大的挑战，但可预计Sidecar的部署模式会在服务网格环境中成为主流的安全防护技术。原因是Sidecar虽然是一种侵入性部署模式，但全程自动化、用户友好：Istio主动监听k8s-api服务获得新服务部署事件，通过仓库自动部署Sidecar容器，通过Init容器劫持流量，最后Sidecar使用Citadel和RBAC策略进行认证授权。一方面，业务方对安全机制毫无感知，所有开发、测试和运维均保持不变；另一方面，应用间能实现完备的认证和授权，最终达到内生安全。

原文始发于微信公众号（三沐数安）：关于“零信任”的一些学习和思考