2021年10月
1. 零信任简介
随着云服务、边缘终端、便携设备、移动办公等新技术的普及,内外网的边界逐渐模糊。传统基于边界的安全防护逻辑开始逐步失效。传统网络拓扑中,所有的安全和密码手段主要针对外部攻击,无法抵御来自内部的威胁。在传统的基于边界的安全中,当攻击者攻破一台内部主机后,将能轻易实施横向攻击。
零信任代表了新一代的网络安全防护理念,它的关键在于打破默认的“信任”,用一句通俗的话来概括,就是“持续验证,永不信任”。默认不信任企业网络内外的任何人、设备和系统,基于身份认证和授权重新构建访问控制的信任基础,从而确保身份可信、设备可信、应用可信和链路可信。
2019年,美国国家标准委员会NIST对外正式发布了《零信任架构ZTA》白皮书,强调了零信任的安全理念,并介绍了实现零信任架构的三大技术
1) 软件定义边界(SDP)
仅通过身份认证的用户,才能看到和访问应用资源。与传统的防火墙静态设置规则不同,在SDP中这种访问控制规则是动态的:用户只有通过身份认证且有相关权限时,被访问主机的防火墙才会添加可访问规则(默认为拒绝),用户才能看到和访问应用。
2) 身份认证和访问控制
实现端到端的身份认证和访问控制。应用访问控制实施的粒度越细,对应用的开发要求越高。对于新开发部署的应用,可强制要求其执行细粒度访问控制。
3) 微隔离
主要用于云环境,沿用以往基于边界的安全思想,将数据中心在逻辑上划分为各个工作负载级别的不同安全段,然后定义安全控制。微隔离使IT人员可以使用网络虚拟化技术在数据中心内部部署灵活的安全策略,而不必安装多个物理防火墙。
2. google零信任简介
google公司称,在2009年经历高度复杂的APT攻击——极光行动(Operation Aurora)后,该公司对员工与设备如何访问内部应用的安全架构,开始尝试重新设计。由此,零信任架构BeyondCorp开始萌芽。与传统的边界安全模式不同,BeyondCorp摒弃了将网络隔离作为防护敏感资源的主要机制。取而代之的是,所有的应用都部署在公网上,通过用户与设备为中心的认证与授权工作流进行访问。这就意味着,作为零信任安全架构的BeyondCorp,将访问控制权从边界转移到个人设备与用户上。由此员工可以实现在任何地点的安全访问,无需传统的VPN。Google零信任示意图如下所示:
图1 google 零信任架构
Google零信任的实施,从2011到2017, 历时6年, 才完成大部分的企业应用的系统改造。BeyondCorp仅仅对Web系统有较好的支持:对企业采购第三方软件, 远程桌面, UDP协议之类的软件支持, 需要做较大的改造或者体验上的牺牲。
3. 奇安信零信任简介
奇安信零信任身份安全解决方基于零信任架构实现了访问控制安全整体实践。通过以身份为基石、业务安全访问、持续信任评估和动态访问控制这四大关键能力,基于对网络所有参与实体的数字身份,对默认不可信的所有访问请求进行加密、认证和强制授权,汇聚关联各种数据源进行持续信任评估,并根据信任的程度动态对权限进行调整,从而在访问主体和访问客体之间建立一种动态的信任关系。系统框架如下图所示:
图2 奇安信零信任架构
可见,奇安信主要采用了应用代理的方式来实现用户对应用的访问。在其官方网址[1]的描述中,应用集中代理支持HTTP、RDP、Email等多种传输协议,言外之意有些协议无法支持或者支持不好。
4. 端到端安全及其问题
要实施零信任理念,必须实现端到端安全问题。端到端的安全能贯彻零信任的“持续信任,永不信任”理念。所有的应用在访问时,都必须执行强身份认证、传输加密和访问控制。每个应用的安全的实施同时包括了客户端和服务端,为应用的开发、部署带来了额外的工作量。主要存在如下问题:
1)无论是WEB还是C/S应用,每一个应用都需要认证用户身份,为应用系统开发者带来额外的开发工作量。所有应用系统开发者需要熟悉身份认证开发过程,分别在客户端和服务端添加身份认证过程,并对数据传输进行加密。
2)应用开发人员一般不熟悉密码算法、密码安全协议。每个应用系统在开发过程中,应用的客户端和服务端实现均由应用开发人员完成,很难保证应用系统的认证过程和数据加密过程合规。
3)基于端口代理的实现方式,无论是单端口代理(类似SOCKS代理和HTTP正向代理)还是多端口代理(HTTP反向代理和各种TCP端口代理等),对客户端提出更高要求:客户端必须将流量重新定位到本地的端口代理之上,通过本地端口代理与对端端口代理实施安全通信。应用类型复杂多样,包括WEB方式、C/S方式、静态TCP端口应用、动态TCP端口应用、UDP应用和IP应用等;用户终端可以是windows也可能是MAC或者Linux及手持设备,将应用流量重新定向到本地代理端口是一个费力而不讨好的过程。因此,端口代理并不是一种理想的安全解决方案。
5. 基于可信IP的通用零信任身份认证方案
本文提出了基于可信IP的零信任通用身份认证解决方案,在确保安全的同时,主要解决应用的开发、部署和易用性问题。
传统网络协议中,物理IP是不可信的,为解决该问题,本方案采用了虚拟IP地址和层叠网络(overlay network)技术,并将虚拟IP地址与用户身份(X.509数字证书)进行唯一绑定和验证,确保本方案中的虚拟IP地址唯一且可信。
上层应用很容易获取访问者的虚拟IP地址,并根据虚拟IP地址来获取用户身份,为后续的访问控制计算提供访问者身份信息,大大简化了应用验证用户身份的过程。
对于上层应用服务端而言,新增工作量非常少(根据虚拟IP地址查表即可);对于客户端而言,应用软件的客户端不需要做任何与安全相关的开发改动,保持原有功能即可。
数据流程如下图所示:
图3 基于可信IP的零信任身份认证原理
数据流说明:
1) 启动各个主机上的隧道管理软件(IP over SSL);
2) 隧道管理软件读取自己的数字证书,根据证书计算自己的虚拟IP地址,对虚拟网卡进行配置;
3) 隧道管理软件与目标主机进行SSL握手,完成身份认证、密钥协商,并获取对方身份;
4) 通信双方根据对端的X.509数字证书分别计算对方的虚拟IP地址,并将该虚拟IP地址添加到系统路由;
5) 通信双方均在共享内存中建立一张映射表,每一个表项包含了数字证书ID和其对应的虚拟IP地址;
6) 主机发起对目标虚拟IP的任意访问(ICMP/TCP/UDP等),IP包(源地址和目的地址均为虚拟IP)通过SSL到达目标主机;
7) 目标主机解析IP包,根据对方的数字证书检查源IP地址是否正确(确保源IP可信),如果正确则进行后续处理,否则丢弃;
8) 目标主机根据用户身份执行IP层访问控制,完成后将IP包写入虚拟网卡;
9) 数据到达应用服务端;
10) 应用服务端获取访问者IP,获取到访问者的虚拟IP,查找用户和虚拟IP映射表,获取用户身份;
11) 应用服务端根据用户身份进行下一步的访问控制。
本方法的核心思想在于通过可信的SSL隧道传输IP数据,并对IP源地址做严格检查。在使用本方案时,需要为整个虚拟地址网段预留一个或多个IP网段,以免与物理IP地址发生路由冲突,比如将8.0.0.0/255.0.0.0预留个虚拟IP地址网段。
6. 数字证书到虚拟IP的计算方法
为将虚拟IP与用户身份进行唯一绑定,可在数字证书中添加扩展项。格式如下:
1字节前缀 + 3 字节偏移量。前缀用于支持多个虚拟IP网段,偏移量用于计算某个网段中的具体IP地址。在颁发数字证书时,每个用户的偏移量单调递增,用户身份不变,前缀和偏移量不变。
计算虚拟IP地址时,可通过数字证书中的前缀和环境变量来得到IP地址前缀,比如8.x.x.x,然后根据偏移量得到最终的虚拟IP地址。
在本方案中,虚拟IP地址网段是受保护网段,不得用于物理IP地址的分配,以免引起路由混乱。
7. 云环境考虑
目前,很多应用都部署在云环境中,云环境主要包括两种:
1) 操作系统虚拟化
基于hypervisor软件(VMware/KVM/Xen/Virtual Box),实现操作系统级的虚拟化,某些hypervisor可以直接运行在硬件上,或者运行在正常操作系统之上。相对容器而言,这种虚拟化最大的特点是操作系统的完整性。
2) 容器虚拟化
基于Linux namespace 实现的虚拟化技术,以Docker为其代表,其主要特点是共享操作系统内核。容器本质是受到相同限制的一组进程。
考察本方案在云环境下的可行性,主要考察两个方面:
1) 虚拟网卡功能是否可用
对于操作系统虚拟化,以linux为例,虚拟网卡(tun.ko)是操作系统自带的功能,虚拟网卡功能以及路由设置功能均无问题。对于windows操作系统,可采用openvpn提供的虚拟网卡驱动,或者根据openvpn提供的驱动源码自己编译驱动。
对于容器虚拟化环境,宿主机能创建多个容器,同时也能创建多个虚拟网卡。理论上,可以将虚拟网卡添加到某个容器的名字空间,让该容器独占该虚拟网卡。是否可行,需要在真正的容器环境中做测试。
2) 基于硬件的加密如何在虚拟化环境下实施
随着云计算的发展,出现了很多IO虚拟化技术,一开始主要是针对物理网卡,现在也出现了很多支持云环境的PCIE加密卡,比如Intel 的QAT加密卡[2]通过SR-IOV来支持云环境。
8. 本方案的优点
1) 简单
相对于端口代理,IP代理更加简单,且非常容易在用户态实现隧道功能。
2) IP唯一可信
访问应用时,均通过虚拟IP进行,且在隧道转发时根据对端数字证书验证源IP地址,解决了传统物理IP地址不可信的问题。
3) 易于实施,快速促进零信任落地
google、奇安信等零信任方案采用端口代理技术;google的零信任方案只支持WEB应用,不支持UDP应用和IP层应用;奇安信对WEB应用采用HTTP代理技术,对网络访问方式采用wireguard/openvpn方式。端口代理技术对客户端要求较高,其本质还是SSLVPN,只是将SSLVPN实现从设备迁移到了主机端,毫无创新性可言。
4) 支持所有应用
通过IP over SSL的层叠网络,天然支持IP及IP之上的所有协议,支持所有应用;
5) 适应复杂网络环境
相对于直接在IP层加密,本方案能适应复杂网络环境,特别是有NAT地址转换的情况;同时虚拟IP的工作方式也能支持服务的负载均衡。
9. 性能考虑
按照传统的观点,很多人觉得IP over SSL存在性能问题。在端到端环境下,性能不存在问题。原因如下:
1) IP over SSL能对同一目的多个IP包组装,然后再加密,相对于IPSec的加密方式(每次只加密一个IP包,1500字节左右),能充分发挥硬件性能,大大提高了加解密吞吐率;
2) 相对于SSLVPN这种集中式设备而言,端到端的性能要求不会太高;
3) 可通过硬件设备来实现密码算法,提高性能;
4) 对于性能要求高的应用服务,可通过负载均衡来解决。
10. 访问控制考虑
访问控制是所有信息系统安全的核心,任何一个安全的服务都必须根据用户身份对用户想要访问的对象进行权限计算,允许或者拒绝用户请求。
基于可信IP的零信任身份认证方案只解决了应用如何获取用户身份的问题,但是未涉及访问控制。
目前访问控制最大的问题在于:当一个复杂的应用系统完成所有授权后,无法通过技术手段检测和证明授权是否存在漏洞。应用系统的开发人员和应用系统的管理人员之间可能存在巨大的认知鸿沟,最小授权原则不一定能够真正实施。
访问控制方案应当考虑如下因素:
1) 是否实现统一的授权管理系统;
2) 访问控制点部署在何处,是部署在应用系统内部,还是部署在应用系统之前;
3) 实现复杂环境下的动态授权,采用何种访问控制模型;
4) 系统管理员易于管理大量应用系统的权限,即能减轻管理员工作量,又能避免人为授权漏洞产生;
5) 权限模型良好,权限决策计算性能足够,时延尽量小。
关于授权模型,美国国家标准与技术研究院(NIST)提出了基于属性的授权模型(ABAC)[3],亚马逊(AWS)[4]公司实现了该模型,授权策略式例如下[5]:
图5 AWS AIM ABAC授权策略
可见,在复杂的云环境下,基于属性的授权将成为零信任持续动态验证的不二选择。
参考资料
[1] https://www.qianxin.com/product/detail/pid/83
[2] ***/content/dam/www/public/us/en/documents/
product- briefs/quickassist-adapter-8950-brief.pdf
[3] https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-162.pdf
[4] https://aws.amazon.com/cn/identity/attribute-based-access-control/
[5] ***/zh_cn/IAM/latest/UserGuide/introduction.html
声明:本网页内容旨在传播知识,若有侵权等问题请及时与本网联系,我们将在第一时间删除处理。E-MAIL:dandanxi6@qq.com