当前位置:   article > 正文

零信任,重构网络安全架构!_零信任网络安全架构

零信任网络安全架构

一、引言

2021年5月12日美国总统拜登签署网络安全行政命令,要求联邦政府采用“零信任架构”。让零信任又大火了一把,近几年安全圈里面越来越热的“零信任”到底是个啥呢?本文就跟大家一起来探讨下“零信任”这个IP。

二、传统安全架构的困境

在传统的IT组网中,网络安全需求的落地往往把重心放在以下工作:

  1. 精心设计的网络架构,如:带外管理网段/带内生产网段的严格划分、不同网段之间的严格隔离,严格划分网络区域,不同区域执行不同的安全策略等;

  2. 网络边界处部署专门的边界安全设备,如F5、IPS/IDS、防火墙、WAF、DDOS等,这些经典的网络安全部署方案,长期以来起到了较好的安全防护作用。但随着企业网络规模的日益扩大、网络攻击技术的不断发展、云技术/容器化的不断发展,传统安全方案的缺点越来越明显;

  3. 整体防御能力重边界、轻纵深,这种理念通过“边界”来区分“可信”与“不可信”。但是复杂的网络部署环境造成过长的网络边界,同时云计算、大数据、移动互联、物联网等技术的混搭也导致网络边界越来越模糊,所以边界的界定也越来越困难。黑客一旦突破边界防御,就如同进入无人之境,而在过于强调边界防护的传统安全方案下,网络边界越来越容易成为实际上的“马奇诺防线”;
    攻击者往往第一步会利用通过应用薄弱点(0day或nday)、水坑攻击、钓鱼邮件等手段绕过企业重兵部署的防御边界,找到突破点后,通过端口扫描探测更大的攻击目标。

  4. 检测能力的局限性,传统的类似IPS、WAF、DDOS和防病毒这样的防护工具,基本上都属于对已知固定恶意代码进行特征识别的一种静态分析方法,无法有效应对恶意代码变形、加壳等隐蔽手段,特别是对于针对性很强APT攻击更是无能为力。一般情况攻击者可以通过以下两种方法逃逸:
    1)通过编码、异形报文进行逃逸;
    2)通过大流量的攻击报文,超出设备检测能力逃逸。

  5. 审计、权限控制的缺失。当攻击者或内部人员以正常业务操作途径,尝试恶意登录、越权下载数据、破坏数据完整性时,现有的“盒子”设备欠缺防护能力。往往APT组织会利用社会工程系进行网络攻击,获取“合法权限”,就可以轻松绕过边界的“盒子”。对于上述恶意操作,一般采用以下方式进行管控:
    1)确保业务系统对人员的最小授权;
    2)能够通过审计能力,在事中或事后发现侵害行为;
    3)通过动态风控手段,结合一定规则、用户行为特征,实现侵害行为的事前阻断。

  6. 无法满足企业服务上云后的安全需求
    服务上云已经成为越来越多企业的必然选择,公有云、混合云部署场景下,云上服务存在网络界面扁平、攻击面大、服务动态伸缩等特点,传统的防护手段已无法适用。而现有云上的安全组、防火墙策略,则存在配置不灵活等问题。

基于边界的网络安全模型一直是信息安全的主要模型。它假设用户在企业网络边界内的用户是“受信任的”,而外部的任何人都是“不受信任的”。 几十年来,这种观点一直是确定用户/设备可以访问哪些资源的准则。

一旦进入边界内部,用户通常可以广泛访问许多企业资源,这意味着 恶意行为者可以来自网络内部或外部。此外,云计算和远程员工的增加使组织数字资源的保护工作更加复杂,因为存在比以往更多的出入口和数据访问点。在这种情况下,安全人员不得不寻求更加安全的方法以保障企业的网络安全。

这里特别强调下“内部”,选在很多著名的攻击都是利用社会工程学的手段,绕过边界盒子的安检,渗透到内部,成为“合法用户”去访问系统资源并执行恶意攻击。


三、零信任的概念

这里引用NIST Special Publication 800-207中的一句话:零信任是一种思想,而非一种技术

理解上面这句话很重要!零信任和我们常见的抗DDOS技术、入侵检测技术、身份认证等技术不一样,它不是一种新的技术,也很难有一款产品,可以称之为“零信任产品”。但是从另一个角度思考,凡是符合零信任思想的安全产品甚至是网络产品,也都可以称之为“零信任”产品。

拜登要求联邦政府采用的“零信任架构”就是利用“零信任”思想,建立的网络架构。

狭义概念:即零信任网络访问(ZTNA),解决的是人、用户、物、设备和终端的信任问题。“由一个控制点控制它怎样对 IT 资源进行访问,授予它什么权限”。

广义概念:即零信任架构(ZTA),它是基于数据的安全,从各方面采集多种数据,包括网络数据、安全数据、终端数据、身份数据等,利用这些数据做信任的计算和决策,真正动态的判断全网安全态势,最终做好决策后再交给部署在整个数字架构中各种各样的决策执行点(可能是一个网关、一个软件或 API),来决定是否允许此次访问以及能访问到何种程度。

简而言之,“零信任”即对一切区域、一切请求,均保持不信任的状态,需要对其进行身份认证、合理授权以及持续的信任评估。

零信任访问模型如下,在图 1 的抽象模型中,如果用户或计算机需要访问企业资源时,其需要通过策略决策点(PDP)和相应的策略执行点(PEP)授予访问权限。
在这里插入图片描述

图 1:零信任访问

隐含信任区表示一个区域,其中所有实体都至少被信任到最后一个PDP/PEP 网关的级别。例如,可以参考机场的乘客安检模型。所有乘客通过机场安检点(PDP/PEP)进入登机口。乘客可以在候机区内闲逛,所有通过检查的乘客都被认为是可信的。在这个模型中,隐含信任区域是登机区。

PDP/PEP 采用一系列的控制策略,使得所有通过检查点之后的通信流量都具有一个共同信任级别。PDP/PEP 不能对访问流量使用超出其位置的策略。为了使 PDP/PEP尽可能明确,隐含信任区必须尽可能小。


四、零信任的发展

  • 2010年:提出零信任安全(或零信任网络、零信任架构、零信任)最早由约翰.金德维(JohnKindervag)在2010年提出,约翰.金德维格当时是著名研究机Forrester的首席分析师;

  • 2011年-2014年:Google共在《login》杂志上发表了5篇BeyondCorp相关的论文,全面介绍BeyondCorp的架构和Google从2011年至今的实施情况;

  • 2017年:Google对外宣布基于零信任概念的新一代网络安全架构BeyondCrop落地完成。业界厂商大力跟进,包括Cisco、微软、亚马逊、Cyxtera,国内安全厂商等成立身份安全实验室大力跟进;

  • 2018年:公安部开始做“一网双域” 探索并开始大规模投资建设

  • 2019年:NIST发布了Draft NIST Special Publication 800-207《Zero Trust Architecture》为给出了零信任官方意义上的解读;

  • 2020年:NIST发布了Draft (2nd) NIST Special Publication 800-207,细化了零信任架构的细节,更有力的推动了零信任思想的发展和落地。


五、零信任架构

零信任架构作为一种企业网络安全规划,利用了零信任概念,囊括其组件关系、工作流规划与访问策略,聚焦数据保护,横向扩展到所有政企网络中的资产。它不是单一的网络架构,而是一套网络基础设施设计和运行的指导原则,可以用来改善敏感级别的安全态势。

5.1 设计/部署原则

根据NIST白皮书中的声明, 零信任架构的设计和部署遵循以下基本原则:

  1. 所有数据源和计算服务均被视为资源。网络可以由几种不同类别的设备组成。网络可能还拥有小微型设备,这些设备将数据发送到聚合器/存储、软件即服务(SaaS),还有将指令发送到执行器的系统等。此外,如果允许个人自带的设备访问企业拥有的资源,则企业也可以决定将其归类为资源。
  2. 无论网络位置如何,所有通信都必须是安全的。来自位于企业自有网络基础设施上的系统的访问请求(例如,在传统概念中内网)必须与来自任何其他非企业自有网络的访问请求和通信采用相同的安全要求。所有通信应以最安全的方式进行,保证机密性和完整性,并提供源身份认证。
    即不区分来自内网还是外网(可信区还是不可信区)的请求,都需要保证通信过程的安全性。
  3. 对企业资源的访问授权是基于每个连接的。在授予访问权限之前,需要对请求者的信任进行评估。这意味着此特定事务只能在“以前某个时间”发生, 并且在启动会话或使用资源执行事务之前不应该直接发生。但是,对某一个资源访问的身份认证和授权不会自动授予到其他不同的资源访问。
    这段话讲的很晦涩,不太容易理解。简而言之就是对资源请求的会话连接的授权是临时的且单一的。“临时”表现在每次连接都需要重新认证,不存在熟客,“单一”表现在更为细粒度的权限划分。
  4. 对资源的访问权限由动态策略(包括客户身份、应用、请求资产的可观测状态)决定,也可能包括其他行为属性。一个组织通过定义其所拥有的资源、其成员是谁、这些成员需要哪些资源访问权等方式来保护资源。(对于零信任模型,用户身份包括使用的用户账户和由企业分配给该帐户或组件以认证自动化任务获取的任何相关属性。请求发送者的资产状态包括设备特征,例如:已安装的软件版本、网络位置、请求时间和日期、以前观测到的行为、已安装的凭证等。行为属性包括自动化的用户分析、设备分析、度量到的与已观测到的使用模式的偏差。)策略是一系列基于组织机构分配给用户、数据资产或应用的属性的访问规则集。这些属性基于业务流程的需要和可接受的风险水平。资源访问和操作权限策略可以根据资源/数据的敏感性而变化。最小特权原则应该被应用于限制可视性和可访问性。
    这段其实只在强调一件事:持续动态认证并以此持续动态授权。
  5. 企业需要确保所有拥有的和关联的设备处于尽可能最安全的状态,并监视设备资产以确保它们保持尽可能最安全的状态。没有设备是天生可信的。这里,
    “尽可能安全的状态”是指设备处于最可行的安全状态,并且可以执行任务所需的操作。实施 ZTA战略的企业应建立一个CDM或类似的系统来监控设备和应用的状态,并根据需要应用补丁/修复程序。那些被攻陷、具有已知漏洞和/或不受企业管理的设备(包括拒绝与企业资源的所有连接设备),与那些企业所拥有的或与企业关联的被认为处于最安全状态的设备相比,应该被区别对待。这种要求也应该适用于允许访问某些资源但不允许访问其他资源的关联设备(例如,个人自带的设备)。因此,需要一个强大的监控和报告系统来提供关于企业资源当前状态的可操作数据。
    这里可以理解为建立一个SOC平台,对网络中的所有设备进行集中的监控。
  6. 在访问被允许之前,所有资源访问的身份验证和授权是动态的和严格强制实施的。这是一个不断的访问请求、扫描和评估威胁、自适应、在通信中进行持续信任评估的循环过程。实施 ZTA策略的企业具有身份、凭证和访问管理系统(ICAM)以及资产管理系统。这其中包括使用多因子身份验证访问某些企业资源。整个用户交互过程应该持续地监视,根据策略(如基于时间的、新的资源请求、检测到异常用户活动)的定义和执行,可能进行重新的身份认证和重新授权,以努力实现安全性、高可用性、易用性和成本效率之间的平衡。
    传统网络架构是以网络为中心的,而零信任架构是以身份为中心的。
  7. 企业应该收集尽量多关于网络基础设施和通信当前状态的信息,并将其应用于提高网络安全状况。一个企业需要收集关于网络流量和访问请求的数据, 并将这些数据用于提高安全策略的创建和改进。

5.2 零信任体系架构的逻辑组件

图 2 中的概念框架模型显示了组件及其相互作用的基 本关系。注意,这是显示逻辑组件及其相互作用的理想模型。从图 1 中,策略判定点(PDP)被分解为策略引擎(PE)和策略管理器(PA)两个逻辑组件。
在这里插入图片描述

图2 核心零信任逻辑组件

以上组件的具体描述:

  • 策略引擎(Policy Engine, PE):该组件负责最终决定是否授予指定访问主体对资源(访问客体)的访问权限。该组件负责最终决定是否授予指定访问主体对资源(访问客体)的访问权限。策略引擎使用企业安全策略 以及来自外部信息源(例如 IP 黑名单、威胁情报服务)的输入作为“信任算法”(TA)的输入,以决定授予或拒绝对该资源的访问。策略引擎 (PE)与策略管理器(PA)组件配对使用。策略引擎做出并记录决策, 策略管理器执行决策(批准或拒绝)。
  • 策略管理器(Policy Administrator, PA):该组件负责建立客户端与 资源之间的连接通道(是逻辑职责,而非物理连接)。它将生成客户端用于访问企业资源的任何身份验证令牌或凭证。它与策略引擎紧密相关, 并依赖于其决定最终允许或拒绝连接。PA 在创建连接时与策略执行点(PEP)通信。这种通信是通过控制平面完成的。
  • 策略执行点(Policy Enforcement Point, PEP):此系统负责启用、 监视并最终终止访问主体和企业资源之间的连接。在 PEP 组件的后面就是放置 企业资源的隐含信任区域。

除了企业中实现 ZTA 策略的核心组件之外,还有几个数据源提供输入和策略规则,以供策略引擎在做出访问决策时使用。这些数据源包括本地的和外部(即非企业控制或创建的),其中包括:

  • 持续诊断和缓解(CDM)系统:该系统收集关于企业系统当前状态的信息,并对配置和软件组件应用已有的更新。企业 CDM 系统向策略引 擎提供关于发出访问请求的系统的信息,例如它是否正在运行适当的打 过补丁的操作系统和应用程序,或者系统中是否存在任何已知的漏洞。
  • 行业合规系统(Industry Compliance System):该系统确保企业遵 守其可能归入的任何监管制度(如 FISMA、HIPAA、PCI-DSS 等)。 这包括企业为确保合规性而制定的所有策略规则。
  • 威胁情报源(Threat Intelligence Feeds):该系统提供外部来源的信 息,帮助策略引擎做出访问决策。
    数据访问策略(Data Access Policies)**:这是一组由企业围绕着企业 资源而创建的数据访问的属性、规则和策略。
  • 企业公钥基础设施(PKI):此系统负责生成由企业颁发给资源、访问 主体和应用程序的证书,并将其记录在案。
  • 身份管理系统(ID Management System):该系统负责创建、存储 和管理企业用户账户和身份记录。该系统包含必要的用户信息(如姓名、电子邮件地址、证书等) 和其他企业特征,如角色、访问属性或分配的系统。
  • 网络与系统行为日志:该企业系统聚合资产日志、网络流量、资源授权 行为和其他事件,这些事件提供对企业信息系统安全态势实时(或者非 实时)的反馈。
  • 安全信息和事件管理(SIEM)系统:该系统收集以安全为核心、可用于后续分析的信息。这些数据可被用于优化策略并预警可能对企业系统进行的主动攻击。

以上所有组件都是逻辑组件。他们不一定必须是个单一系统。单个服务可以执行多个逻辑组件的职责,同样,一个逻辑组件可以由多个硬件或软件元素组成以执行其任务。

5.3 零信任架构常见方案

根据NIST白皮书中对零信任架构 ZTA的常见方案描述,企业可以通过多种方式为工作流引入零信任架构 ZTA,每种方案都实现了零信任的所有原则,但可以使用一个或两个组件作为策略的主要驱动元素,常见方案有以下三种:

  1. 基于增强身份治理的ZTA
    基于增强身份治理的 ZTA 使用参与者身份作为策略创建的关键组件。如果不是请求访问企业资源的主体,则无需创建访问策略。对于这种方案,企业资源访问策略基于身份和分配的属性。资源访问的主要诉求是基于给定主体身份的访问授权。其他因素,如使用的设备、资产状态和环境因素,可以改变其最终信任评分计算(和最终访问授权),或者以某种方式调整结果(例如,基于网络位置 仅授予对给定数据源的部分访问权限)。保护资源的 PEP 组件必须有能力可以把请求转发到策略引擎服务,在访问授权之前进行主体身份认证和请求核准。
  2. 基于微隔离的 ZTA
    企业可以将单个或一组资源放在由网关安全组件保护的私有网段上来实施 ZTA。在这种方案中,企业将防火墙(NGFW,Next Generation Firewall)或 网关设备用作 PEP,以保护每个资源或一组资源。这些网关设备动态授权访问来 自客户端资产的各个请求。根据型号的不同,网关可以是唯一的 PEP(Policy Enforcement Point)组件,也可以是由网关和客户端代理组成的多部分 PEP 的一部分。
  3. 基于网络基础设施和软件定义边界 SDP 的 ZTA
    第三种方案是使用网络基础设施来实现 ZTA。 零信任的实现可以通过使用 顶层网络来实现(即第 7 层,但也可以将其部署在更低的 ISO 网络协议栈)。 这种方案有时称为软件定义边界(SDP)方法,并且经常包含 SDN [SDNBOOK] 和基于意图的联网(IBN)[IBNVN]的概念。在这种方案中,PA 充当网络控制器, 根据 PE 做出的决定来建立和重新配置网络。客户端继续请求通过 PEP(由 PA 组件管理)进行访问。当在应用网络层(即第 7 层)实施该方案时,最常见的部 署模型是代理/网关。 在此实现中,代理和资源网关(充当单个 PEP,由 PA 配 置)建立用于客户端和资源之间通信的安全通道。

零信任到底是靠什么技术做底层支撑的呢?零信任的三种建设方案正好对应三大支撑技术,分别是IAM、MSG、SDP

  1. 增强型身份认证与访问管理(IAM)
    零信任时代的身份管理,核心是持续的动态认证持续的动态授权
    在实操中,零信任方案会使用多因素身份验证、单点登录等IAM技术来确保用户使用安全的设备、建立安全的会话、访问适当的资源。
  2. 微隔离技术(MSG)
    零信任时代MSG的核心要义就是把资源更细粒度分割,便于增加更周密的访问控制权限
    既能防范违规的东西横移,又可以为南北向访客精细分配资源。
    在这里插入图片描述
图3 MSG示意
如图3所示,数据中心有边界防护(大仓保安),而对于数据中心内部/企业内网来说,还需要“小仓保安”对横向移动进行监管,服务器之间、虚机之间等,甚至pod之间都需要进行管控,这是微隔离的初衷。
  1. 软件定义边界(SDP)
    SDP在“访问者”和“资源”之间建立动态和细粒度的“业务访问隧道”。
    SDP与传统VPN隧道不同,它是临时单一的访问控制,把业务资源对未授权的用户完全屏蔽。即便获得授权的用户,也只是使用资源,却不知道资源具体位置,正所谓,“可用而不可见”。

基于控制通道与数据通道分离的设计,SDP构造了一个暗黑网络,减少了资源的暴露面,安全性更好,不仅可以替代VPN/边界网关来控制南北向流量,也可以用于内网间的访问权限控制,彻底定义一个弹性的动态的安全边界。

freebuf团队总结出一个相对完整的零信任网络结构,分享给大家,如图4所示:
在这里插入图片描述

图4 零信任网络结构

可以看出,此零信任网络结构图也是在NIST白皮书中的逻辑组件基础上构建的。

在数据平面层,我们需要通过网关(包括4层协议网关与7层协议网关),来实现数据的收口,以便实现权限的控制。

更为安全或复杂的场景,可以辅以安全客户端,来保证数据来源环境信息的可靠性。

在管理平面层,零信任的核心思想在于认证、授权以及持续的信任评估,因此,对应的需要“单点登录”来实现访问源的身份认证,需要IAM(Identity & Access Management)来实现权限管理,需要“风控中心”来进行持续的风险评估,通过“决策中心”将上述三部分进行串联,实现一次访问请求的权限授予。

当安全客户端存在时,则对应的需要其管理的服务端。服务端实现了客户端的管理与信息的收集,并以此整理“设备信息库”。客户端的管理与可控,则是以PKI为基础来实现的。


六、应用场景

任何企业环境都可基于零信任原则来设计规划。大多数组织机构在企业基础设施中已经有一些零信任的元素,或者已经通过实施信息安全和弹性政策及最佳实践走在通往零信任的路上。有几个部署场景和用例很容易成为零信任架构。例如,ZTA 就是起源于地理上分散和/或员工流动性高的组织机构。总的来说,任何组织都可以从零信任架构中受益。

6.1 具有分支机构的企业

最常见的情况是一个企业有一个总部和一个或多个地理上分散的分支机构, 并企业拥有的物理网络(内网)无法把他们连接一起(请参见图 4)。外部地区 的员工可能没有完全企业拥有的本地网络,但为了执行工作任务仍然需要访问企 业资源。同样,员工可能是远程办公或在外部地区使用企业所有或个人拥有的设 备。在这种情况下,企业可能希望授予员工日历、电子邮件等某些资源的访问权 限,但拒绝其访问或限制操作更敏感的资源(例如,人力资源数据库)。

在这种使用场景下,PE / PA 通常作为云服务托管终端设备资产安装了 Agent 代理程序或直接访问资源门户。

将 PE / PA 托管在企业本地网络可能不是最有效的方法,因为远程办公室和工作人员必须将所有流量发送回企业网络才能访问由云服务托管的应用程序。
在这里插入图片描述

图5 具有远程员工的企业

6.2 多云企业

一种越来越普遍的部署 ZTA 用例是企业使用了多个云提供商(请参见图 5)。 在这种情况下,企业拥有本地网络,但同时使用两个或多个云服务提供商托管应 用程序和数据。有时,应用程序托管在与数据源分离的云服务上。考虑性能和便 于管理,云提供商 A 中托管的应用程序应该能够直接连接到托管在云提供商 B 中的数据源,而不应强制应用程序通过企业网络连接。
在这里插入图片描述

图6 多云场景

零信任原则认为企业自有和运营的网络基础设施与任何 其他服务提供商拥有和运营的基础设施之间应该没有任何区别。多云所用的零信 任方案是把 PEP 放在每个应用程序和数据源的访问点。PE 和 PA 可以是位于云 中或甚至是托管在第三方提供商的云服务。然后,客户端(通过门户或本地安装 的 Agent 代理程序)直接访问 PEP。这样,即便资源托管在企业外部,企业仍 然可以管理资源的访问。

6.3 具有外包服务和/或访客的企业

另一个常见的场景是企业的现场访客和/或外包服务人员需要对企业资源进 行有限访问(请参见图 6)。例如,企业有自己的内部应用程序、数据库和资 产,其中包括外包给供应商偶尔需要在现场提供维修的服务。这些访客和服务提供商需要 网络连接以执行任务。实施零信任原则有助于企业在允许这些设备和来访的技术 人员访问互联网的同时隐藏企业资源。
在这里插入图片描述

图7 允许非员工访问权限的企业

6.4 跨企业边界协作

在这里插入图片描述

图8 跨企业协作

第四个用例是跨企业协作(如图7)。两家企业的员工都可能不在他们组 织的网络基础设施上,他们需要访问的资源可能在一个企业环境中也可能托管在 云中。这意味着无需通过复杂的防火墙规则或企业范围的访问控制列表(ACL) 允许某些属于企业 B 的 IP 地址访问企业 A 的资源。如何进行访问取决于使用的技术。

6.5 具有面向公共或面向用户服务的企业

许多企业的一个常见特征是面向公众的服务,该服务可能包括也可能不包括 用户注册(即,用户必须创建或已颁发一组登录凭证)。这些服务可以服务于一 般公众、一组具有现有业务关系的客户、或一组特殊的非企业用户,如员工家属。 在所有情况下,很可能请求的设备资产不是企业所有,因此企业可以实施的内部 网络安全策略是受局限的。

通常来说,对于不需要登录凭证即可访问的面向公众的通用资源(例如,公 共网页),ZTA 的原则并不直接适用。企业不能严格控制请求设备资产的状态和公共资源不需要凭证才能访问。


参考资料:

  1. Draft (2nd) NIST Special Publication 800-207
  2. 零信任网络建设及部分细节讨论
  3. 零信任,绝情的令人窒息!
  4. Cam-Winget N (ed.), Appala S, Pope S, Saint-Andre P (2019) Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 8600.
  5. Stanton B, Theofanos MF, Spickard Prettyman S, Furman S (2016)
    Security Fatigue. IT Professional 18(5):26-32.
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/知新_RL/article/detail/399733
推荐阅读
相关标签
  

闽ICP备14008679号