证券行业应用零信任思想的探索【上】

 

前言

疫情三年，远程办公的理念已经深入人心，零信任概念和产品也在这几年蓬勃发展，颇有乱花渐欲迷人眼的感觉。但是到底什么是零信任、如何运用零信任思想来构建安全体系，却一直是我们希望思考和解决的问题。为此，我们在2021-2022年接触了国内外几乎所有的主流零信任厂商，调研搜集了证券行业可能运用零信任思想的场景，对厂商产品做了较全面的测试和评估，写了一份报告。本来是想作为行业课题成果分享的，结果可能报告写的不好，没被评审专家看上。于是我们就稍微修改了一下、于此处发表，供各位同行交流、指正。本文在撰写过程中得到如下专家的支持，特此鸣谢：安信证券李家攀、刘亦翔、何洲星、唐新华、李维春、覃阳青，深信服科技刘敏杰，持安科技何艺，筋斗腾云杨洋，国信证券金文佳，第一创业证券唐立峰。文字很多，请耐心观看。

一、背景及意义

数字化转型使得业务更开放，各种业务系统不仅仅需要内部员工或外包人员接入，同时还需要供应商、客户、第三方单位等接入，组织之间的数字化连接更加密切。在搭建网络架构时需要不仅需要考虑信息安全体系如何建设，同时企业的快速发展及数字化进程的推进也会引发接入终端、业务访问角色、网络环境、业务系统趋向于多样化，牵引整个组织思考面向用户体验如何转变以及效率如何改进，以便更好支撑企业数字化进程以及业务的快速发展。

同时，随着证券数字化转型的不断深入，以及证券业务的不断发展和开放，券商的业务系统快速增加，除了为客户提供交易通道的核心交易系统外，还有大量的外围系统、为第三方提供的API、以及支撑企业运营的财务、OA、HR等系统。测试人员角色复杂多样，加上频繁的系统迭代，使用白名单、VPN及用户密码等传统安全技术进行测试环境接入的方案已经无法满足繁重的系统测试要求。除了互联网的业务测试场景，还有员工或外协人员远程办公场景，特殊终端的安全管控场景，定制化交易系统接入和测试场景，将内网应用发布到互联网的场景，跨网横向细颗粒度访问控制场景，应用间、私有云内、容器云内流量访问控制场景，内网操作、访问敏感数据的场景，老旧系统的访问保护场景。

以上需求对企业的安全建设提出了新的挑战，使用传统的安全管控措施均面临控制措施不全面、控制效果有缺失、响应效率较低的情况，无法适应新时代背景下证券业务开展既快又好的需求。为此，需要寻求效果更好、投资收益比更好的综合解决方案。

二、课题目标

针对员工或外协人员远程办公场景，特殊终端的安全管控场景，基于互联网的业务测试场景，定制化交易系统接入和测试场景，跨网横向细颗粒度访问控制场景，应用间、私有云内、容器云内流量访问控制场景，内网操作、访问敏感数据的场景，老旧系统的访问保护场景。通过运用零信任思想和技术解决方案，结合强有力的身份认证和管理，可以实现严格的访问控制、同时保障用户体验和业务效率，是未来主流技术方向之一。通过对不同场景下的应用探索，寻求零信任技术在券商环境下的综合解决方案，尝试整合SDP、统一身份管理、微隔离、零信任应用代理网关、零信任决策引擎等多种技术，尝试通过统一调度和控制平面，实现多场景下持续有效、细颗粒度的访问控制，为同行探索一条可行的零信任实践道路。

三、典型场景分析及风险评估

根据课题组的分析和调研，认为在如下典型场景中可以考虑运用零信任思想

场景1	员工或外协人员远程访问内网应用
场景2	特殊终端访问内网应用
场景3	基于互联网的业务测试
场景4	定制化交易系统的接入和访问
场景5	传统网络环境下，跨网络域东西向的访问控制
场景6	私有云内、容器云内、多云环境的访问控制
场景7	内网访问敏感数据；保护老旧系统

3.1 场景1：员工或外协人员远程访问内网应用

3.1.1 子场景1-1：远程访问内网资源场景

1、场景描述

• 员工、驻场外协人员、合作开发人员、营业部IT经理等非工作时间应急、疫情隔离等原因，需使用个人电脑、计算机设备在公司外部、远程访问内网资源（终端或生产系统）；
• 合作方工程师因需要临时远程排障、远程指导软件部署，需使用个人电脑、计算机设备在公司外部、远程访问内网资源（终端或生产系统）；

当下，本场景的需求更多地通过VPN方案（必要时增加双因素认证）满足。

2、本场景的问题和风险分析

1. VPN本质上是通过虚拟隧道方式打通了家庭到公司内部的网络，因此实际也包含了传统内网隔离下的隐性信任关系，所以一旦家庭电脑网络被勒索、蠕虫等方式入侵，会很容易将攻击蔓延到公司网络中；接入VPN的个人电脑被攻破后，无法进行及时隔离处置；
2. 大多数的安全风险都来自应用和业务层面风险，VPN作为网络传输层的系统并不能防护应用层和业务层面风险，只能进行网络层控制；
3. 个人电脑很难控制准入控制基线，但不控制的话容易引入各种安全风险；个人电脑类型繁多，VPN客户端体验差；
4. 如果是外协人员使用VPN，安全人员无法得知其网络访问行为是否可控；即便通过堡垒机采取控制，但由于堡垒机视频太多太长，实际上并不可审计；外部人员被授权后，有异常行为无法发现、告警、处置；安全告警数据无法集中分析和监测；
5. 基于控制安全风险的考虑，开放VPN用户的访问权限就会很谨慎，由此带来审批流程的严格、沟通和时长，员工操作体验较差；
6. 对于远程登录服务器运维的需求，需登录VPN、连接办公终端或登录堡垒机、再连接需运维的服务器，过程需要多个步骤、多次双因素验证，操作体验较差；

3.1.2 子场景1-2：外包供应商访问场景

1、场景描述

为加强外包人员管理，外包人员供应商与甲方之间的推荐简历、筛选、考勤、付款等流程都在甲方的外包管理系统上完成，为此供应商人员只能通过VPN远程登录进入甲方内网、访问部署在甲方网络环境中的外包管理系统，为保证安全效果，供应商员工用手机短信验证后方可登录VPN，并只能访问外包管理系统。

2、本场景的问题和风险分析

1. VPN登录帐号由外包供应商员工保管，无法监测、控制供应商员工网络访问情况，也无法控制帐号是否被借用、盗用；
2. 很难控制供应商员工电脑的安全基线达标，也更加无法监测、控制其被利用后通过攻破外包管理系统服务器进而拥有进入同网段内网权限；
3. 基于IP+端口5元组的授权模型，即便是精细化授权，但IP上承载的实际可能是多组应用，并且随时运营时间推移，精细化的管控成本会越来越高；

3.1.3 子场景1-3：分支机构与总部连接、访问场景

1、场景描述

分支机构与总部的连接、访问控制关系如下图：

1. 分支机构终端需要访问数据中心的应用系统，开展业务和经营活动；
2. 在分支机构终端遇到故障、需要远程支持的时候，总部终端需远程连接分支机构终端进行排障；分支机构终端在少数特殊情况下（包括一些不规范使用的情况），可能也需要访问总部终端的文件共享、服务；

2、本场景的问题和风险分析

1. 分支机构IT管理较薄弱、技术能力较弱、终端类型较多，可能导致被攻陷后攻入应用系统所在内网，或造成分支机构终端上数据被窃取、泄露。
2. 分之机构往往存在大量到总部的访问授权，由于机构复杂性，授权通常会基于IP网段来进行，并不能真正准确授权给真正所需使用业务系统的员工；
3. 分支机构即便有权限访问总部系统，但实际访问过程中可能存在恶意的访问或是攻击，如何及时、有效发现分支机构对总部终端的访问，控制这类访问场景中可能存在的安全风险。
4. 分支机构到总部的网络可能是通过NAT范围进行，这样一旦发生安全事件后，往往看到的IP仅仅是NAT后的IP，难以快速溯源；

3.2 场景2：特殊终端访问内网应用

3.2.1 子场景2-1：类终端设备连接服务端场景

1、场景描述

1.VTM设备实质上就是一台windows终端，连接了多种用于业务办理的外设如摄像头、扫描仪、身份证读卡器。设备存放在分支机构，日常由分支机构IT人员操作、管理；设备通过各种方式连接数据中心的应用系统，执行业务办理的任务；

本场景下采取如下安全防护措施：

1）安装防病毒程序；

2）终端准入采取MAB认证；

3）SSL VPN采用静态密码+硬件特征码的双因素认证；

4）通过VPN限制VTM设备仅可访问应用系统的前端服务资源；

5）安装VTM监控和运维程序；

6）VTM设备的鼠标、键盘默认上锁，仅分支机构IT人员可打开；

2.一线运维人员使用iPad通过机房WiFi接入数据中心应用系统（运维值班系统、统一身份认证），执行巡检、值班任务后，在iPad上登记。目前做了MAC和IP绑定，仅允许特定IP直接访问数据中心（办公区）。

本场景下采取如下安全防护措施：

1）在准入控制上实施iPad设备MAC和IP绑定；

2）iPad设置访问密码；

3）加强宣贯、管理，要求妥善保管iPad，无人使用时应上锁保管；

2、本场景的问题和风险分析

1. VTM设备及其使用存在如下安全风险：

1）MAB认证存在MAC地址被仿冒的风险；静态密码+硬件特征码的方式存在被仿冒的风险；如果上述接入认证被仿冒，攻击者可以借助该通道以正常用户授权方式接入网络中，进行持续攻击，而后端系统只能被动挨打无法主动防护；

2）VTM设备操作系统为win7，不支持安全补丁更新，厂家的维护更新较慢；

3）VTM设备存放在分支机构的开放空间，设备自带多种外设接口，管理困难，如被物理入侵则会被直接用于攻击；

4）基于VPN的以IP端口方式的授权模型，一旦建立连接后，该IP上所承载的所有业务均可被访问，比如多域名绑定一个IP的情况，实际授权难以精细化；

5）VPN通道建立后就拥有了访问该BS应用的权限，并不能防止在这个过程中，利用该传输通道对BS应用发起攻击；

2.使用iPad开展值班、巡检任务时存在如下安全风险：

1）MAC地址和IP绑定措施的效果较弱，无法规避MAC地址冒用；

2）iPad上无法安装现有的安全软件，无法保障设备安全性，也无法保证安全基线策略的有效性；

3）无法防止攻击者在iPad上启用网络代理方式，利用iPad的通道去发起攻击；

4）VPN通道建立后就拥有了访问该BS应用的权限，并不能防止在这个过程中，利用该传输通道对BS应用发起攻击；

3.2.2 子场景2-2：IOT设备联入内网场景

1、场景描述

1.机房巡检机器人通过部署在机房的WiFi接入内网后，向后台的应用系统传送数据、并接受来自后台应用系统的控制指令。

2.门禁机使用了人脸识别设备，该设备本质上是个精简后的安卓系统，上运行了人脸识别程序。人脸识别设备需要连接后台的门禁管理系统、门禁开关，人脸识别设备、门禁管理系统均部署在独立网段、与办公网、交易网之间有防火墙隔离；因需要识别人脸，门禁管理系统需要从办公网的应用系统单向获取人脸、人员基本信息，系统之间的访问控制采取防火墙基于IP、端口的访问控制措施；

3.类似场景还有智能会议设备，一般是自带安卓系统和Windows系统，可以无线投屏、可以同时使用投屏和白板功能，并能在联网后将白板内容邮件发送给员工指定邮箱；

4.本场景的特点是IOT设备的计算能力和存储容量均有限，较难安装安全软件。

2、本场景的问题和风险分析

1.使用智能巡检机器人的场景存在如下安全风险：

1）Wifi信号可以在机房外部被接收到、连接，并进入内网；

2）采用MAC地址白名单的访问控制措施，MAC地址容易被仿冒；

3）机器人的控制系统本质上就是一个带简化操作系统的工控机，这个工控机/单板4）如果被攻破，攻击者可以以此为跳板，进入内网；

2.使用人脸识别门禁机的场景存在如下安全风险：

1）门禁机的安卓系统是否采取了足够的安全保护措施，未知且不可控；

2）门禁机遍布各楼层出入口，无人进行日常管理，门禁机的接入很容易被仿冒和利用；

3）门禁机上可能会存储人脸和人员基本信息，极其遭到攻击并入侵到门禁管理后台，造成门禁管理后台的数据泄漏，或进一步入侵、攻入数据中心内网；

3.2.2 场景3：基于互联网的业务测试

1、场景描述

1. 手机证券App、PC客户端发版后，为测试在不同终端、网络环境下的功能、网络连通性，需由测试人员、外包人员、分支机构在不同终端、网络运营商、地点进行测试；测试活动为集中开展，但属于长期测试需要；
2. 某些柜台系统、行情系统、接入系统在接入数据中心的生产环境前，需在合作商、客户的开发环境中进行联调，这时需调用柜台、行情、接入系统的API、接口，有时还是使用私有化协议的接口；客户网络所在互联网IP地址不固定，客户需求响应要快，测试活动为长期。
3. 如果执行的是兼容性测试，目前普遍采用类似Testin或Testbird的服务模式，这种服务模式通常是在服务商的机房内有多台、各种型号的手机，其上运行被测试的App，测试期间手机App需要访问部署在公司内网的系统。服务商的机房有固定IP地址，客户需求响应要快，测试活动为长期。

2、本场景的问题和风险分析

基于互联网的业务测试场景中，主要存在以下安全风险：

1. 由于发布在互联网的测试系统的版本变化仍较频繁、且未处于生产使用状态，一般尚未经过安全检测，因此可能存在较多漏洞；如果完全放开互联网访问权限，则可能导致被入侵、攻击进入内网；如果采取基于IP地址的防火墙白名单控制策略，则由于此场景中，测试用户的互联网IP不固定，很难使用白名单方式控制访问源；安全风险控制和业务开展处于两难境地；
2. 无论是否放开测试系统的互联网访问权限，由于测试用户的终端类型多样性（PC和手机并存，多种操作系统并存）也无法安装安全软件或VPN软件，对测试用户的终端安全状态完全不可知；
3. 大部分客户、合作商都没有固定的互联网IP，因此客户在开发环境对接测试系统时，需要频繁开通互联网白名单；开通白名单需要走审批流程，且开市期间无法操作，造成客户长时间等待，影响客户体验和工作效率；
4. 测试业务系统也是业务系统，系统一样会被监管等第三方机构扫描检测，但由于开发测试过程不会过多投入资源在安全上，往往容易会被扫出大量风险，事后监管解释成本很高；

3.4 场景4：客户托管系统接入场景

1、场景描述

1. 客户将自研的交易系统托管在券商的数据中心，出于安全考虑，通常券商会将该系统放在一个单独、隔离的网络区域内；个别特殊情况下，客户托管系统会与券商的高速行情、极速交易系统、报盘系统在同一个区域内；
2. 客户出于投研、风控和资金管理的需要，需要直接登录托管系统，或通过在客户本地的管理端连接托管系统，开展业务操作，比如策略设置、交易参数优化、监控交易成交进展等；客户在交易过程中的数据、日志可能还需要回传到客户本地的管理端；
3. 客户出于维护托管系统的需求，需要远程运维托管系统及其所处的主机；
4. 客户出于优化托管系统交易功能、性能的目的，或维护、升级托管系统的需求，还需要上传策略文件、程序升级文件到所托管的主机
5. 客户登录的环境通常在家中或办公室，使用个人电脑或其公司电脑；根据客户自身环境和条件的不同，可能通过互联网登录，可能通过券商提供的VPN通道登录，可能通过客户办公室与券商数据中心之间的专线登录；
6. 此类客户有的擅长软件开发、有的具有较强的运维能力，但普遍安全意识薄弱，客户的系统代码、策略配置属于其商业秘密，券商既无法参与其系统架构设计、软件开发，也无法获得其软件代码进行审计；

2、本场景的问题和风险分析

1. 通过采取“防火墙上加IP白名单+MAC地址控制+PVLAN”的风险控制措施，可以隔离客户与客户之间的访问控制风险，但无法控制由客户侧引入的风险；
2. 由于此类客户往往具有较大的资金量和交易量，券商在对其采取安全管控措施的时候，往往处于弱势一方，很容易造成安全管控的薄弱和风险的引入；
3. 无论客户使用的是其公司电脑还是个人电脑，访问客户托管系统时所在的网络环境在哪里，安全状态均不可监测、不可控制；如果客户的终端、网络被攻破，可做为攻击跳板、被恶意利用，会对券商的交易系统、核心交易内网产生攻击、破坏，严重者被恶意利用、影响资本市场秩序；
4. 客户委托系统及其访问方式有基于http/https的BS架构的，也有基于私有化协议的CS架构的；客户运维托管系统所在主机、程序的时候，有的习惯于用SSH，有的习惯用RDP，造成访问协议、访问方式多样化，采取基于防火墙IP+端口白名单方式的控制措施很容易被绕过；
5. 某些情况下，客户还要求将部分数据回传到客户本地的环境中，则会在券商的网络中建立出向链路，但这个出向链路用于什么用途、做了什么操作、传输了什么内容，完全属于不可监测的黑盒子；
6. 客户出于优化托管系统交易功能、性能的目的，或维护、升级托管系统的需求，还需要上传策略文件、程序升级文件到所托管的主机；如果不对文件进行安全检测，策略文件、程序升级文件可能存在恶意代码；

3.5 场景5：传统网络环境下，跨网络域东西向访问控制场景

1、场景描述

绝大部分券商的生产内网分为办公网和交易网，分别存放不同类型的应用系统；按照监管要求，办公网和交易网之间处于强逻辑隔离的状态，两网之间的访问控制非常严格，但是随着业务的发展、系统设计的复杂度增加、技术形态的演进，两网之间的数据交互日益频繁，让我们不得不反思现有的网络架构和监管规范的适用性，以下为课题组从行业内了解到的典型需求场景：

1. 业务部门的人员越来越强势、也有开发能力，不得不在生产环境里面给他们单独开辟了一块网络区域，部署业务人员自己开发程序、探索数据应用，这些程序和生产环境产生了大量的交互；
2. DevOps流水线和容器云模式的推广，使得设计、开发、测试、部署过程实现完全自动化成为可能，这种模式极大地提高了研发人员的交付效率和质量，必然导致两网之间的强隔离界限最终被打通；
3. 固收业务交易员需要在办公网使用QQ、OA等与交易对手沟通、处理流程审批等，使用交易终端在固收系统上操作（部署在交易网），因此需要在办公网、交易网两台电脑间切换，操作便捷性会下降，因此固收业务交易员习惯在办公电脑连接vpn”的方式登录进入交易网、使用固收系统，这样的做法虽然违反了现有管理规定，但也反映出在这个操作场景下业务人员对操作便捷性的需求；
4. 某些场景下两网数据交互有性能要求，如运维日志大数据系统要收集很多应用系统的运行日志，就必须在交易网、办公网各部署一套采集节点，但是运维日志大数据系统的用户终端只能部署在一个网络区域，在查询、排障的时候往往需要同时分析办公网、交易网的日志数据，对数据传递性能有较高要求；类似情况在很多安全软件、安全系统部署时均存在；
5. 信息技术部门都有智能大屏，背后有个架构较简单的智能大屏系统支撑。智能大屏系统单项接收从办公网、交易网传递的数据或接收数据后加以统计分类，并予以展现；如果有些指标是实时性较强的，则需要采集准实时数据，并予以展现；

2、本场景的问题和风险分析

随着业务模式的发展导致越来越多业务人员参与IT工作，系统设计的复杂度增加导致系统之间的信息流、控制流越来越多，技术形态的演进导致以往的内网以网络分区为边界的控制措施越来越难以维护，办公网、交易网两网之间的数据交互日益频繁，让我们不得不反思现有的网络架构和监管规范的适用性。课题组认为，未来办公网、交易网之间基于防火墙策略的、强隔离的访问控制措施可能会被打破，代之以控制粒度更细致、控制维度更全面、管控体验更好、运维和运营效率更高的控制措施。

3.6 场景6：私有云内、容器云内、多云环境内访问控制场景

1、场景描述

2、本场景的问题和风险分析

1. 私有云、容器云、行业云之间所采用的技术栈不同，采用云防火墙的访问控制策略导致运维成本高、复杂度高；
2. 容器云的动态拉起、释放Pod的特性，以及动态分配IP地址的特性，使用mac+vlan方式进行访问控制会影响云的动态扩展能力，策略管理成本高、效率低。容器被攻破时无法快速处置，无法防御攻击者横向移动。容器的端口、服务的暴露面无法收敛；
3. 应用系统采用微服务架构后，会引入API安全的一系列风险，包括API配置问题、API安全漏洞（注入）、API未授权访问，API接口越权访问，API异常调用（撞库、暴力破解、数据泄露、DDos）等风险；

3.7 场景7：访问内网敏感数据；保护老旧系统场景

3.7.1 子场景7-1：访问内网敏感数据

1、场景描述

1. 数据开发人员通过交易网终端、或通过堡垒机、或通过云桌面，直连HUE、访问大数据平台进行开发。通过大数据平台可访问大量、敏感客户信息和经营信息，一般通过数据开发人员对应的大数据平台帐号限制其数据访问权限。
2. 投研人员需要通过一个投研平台访问大数据平台的数据、行情数据、万得数据，每个投研人员在投研平台上都有一个IDE（类似于Web应用的操作界面），并在这个IDE里面编写算法程序、调取各类数据、运行程序、获得各类投研因子数据。这类投研因子属于敏感信息，仅投研人员掌握。
   
   

2、本场景的问题和风险分析

1. 大数据平台承载了大量的客户信息，开发人员对客户信息的访问无法被有效控制，异常&违规操作无法被发现、回溯。
2. 大数据平台用的KDC认证组件，不用IAM；投研平台使用自身的身份认证体系，不用IAM。无法施加更强的双因素认证及控制策略，认证体系有可能被突破。
3. 大数据平台自身可能存在系统漏洞，存在被攻击的风险，以及突发漏洞出现可能导致平台要在下线修复漏洞影响业务，还是带漏洞运行中进行取舍。

3.7.2 子场景7-2：外审场景

1、场景描述

1. 外部审计人员来公司，审计期内，需要登录各种系统查阅资料：总体需求是既要让外部审计人员可查看，又不希望外部审计人员带走、拷走资料，有时甚至连拍照都不可接受。
2. 一般审计人员以现场审计为主，则主要处理方式是给每位外审人员分配一台电脑，用桌管软件禁用所有外设端口、开启桌面水印，通过这台电脑登录相应系统查阅资料。如需访问应用系统，则提出权限申请的流程，审批通过后分配权限。
3. 也存在审计人员进行远程审计的情形，此时审计人员使用自己的电脑、远程拨入VPN再访问公司内部资源。

2、本场景的问题和风险分析

1. 对于现场审计情形，目前控制措施基本满足需求，但每次都要提前装机、审计结束后再清除，审计结束后再关闭帐号，有一定的运维、沟通成本，如果外审人员对时间、效率有要求则体验较差。
2. 对于远程审计情形，问题和风险等同于场景1-1。

3.7.3 子场景7-3：老旧系统的访问保护场景

1、场景描述

1. 某重要系统版本老、要1-2年后才更换；该版本有很多漏洞，但不敢打补丁、怕影响稳定运行；各分支机构都有1-2个用户可访问该系统、提交数据，全公司有近300个用户。系统是BS方式访问。

2、本场景的问题和风险分析

1. 系统版本老旧，不打补丁、不升级则存在很大的被入侵、攻击风险；一旦从分支机构薄弱点突入，则可以直接获取企业重要经营数据。
2. 既要保护系统不被入侵和攻击，也要保障各分支机构用户可持续访问、操作，还要保障在实施安全控制措施的过程中用户体验好、尽量无感知。

四、对零信任本质和未来应用的思考

在交流、调研、测试以及撰写本课题报告的过程中，课题组对什么是零信任进行了大量的讨论和交流，也深入学习了Google和微软对于零信任思想的阐述。我们认为作为甲方在应用零信任思想进行安全架构、技术选型的时候，不应该被厂家牵着鼻子走，市面上不少厂家对于零信任思想的解读大体没错，但是在产品交付、场景实践中往往基于自身的技术沉淀、方案交付容易度以及概念包装的考虑，并未完全符合零信任思想的本质。甲方在选择、应用零信任产品、解决方案的时候，要沉下心来、擦亮眼睛。

4.1 零信任的本质

1. 零信任不是一种或多种产品，也不是方案；零信任是一种安全架构思想，其核心在于打破了传统边界隔离等思想中的隐性信任关系，提出了“持续验证、永不信任”的理念。信任是信息安全的核心思想之一，从这一点看，零信任不是一个新概念，但确实“老瓶装新酒，味道更醇厚”。
2. “永不信任”的内涵在于，不再基于传统安全的“先访问再验证”模型（类似IAM认证过程），而是先进行拦截（默认拒绝）后进行可信验证，通过后数据包才可以到达目标，实现了“先验证再访问”。
3. “持续验证”的内涵不以传统的特征对抗为基础，而是以持续验证中的可信验证机制进行对抗，跳出了传统攻击者所能操控构建各类特征攻击包的，用多维度的可信验证进行对抗，实现可以防护0day等攻击、形成降维对抗的效果；可信验证中的重要要素就是用户、设备、应用、进程的身份。
4. 零信任不再以访问位置作为安全依据，不关心你是在公司内发起访问还是公司外，而是以访问对象的应用为控制，不以网络层控制为主，而是以应用层业务身份为基础的精细化控制；
5. 零信任的本质是技术进步之后，我们可以在访问控制层面做的比以前效果更好，这个“好”包括维度更多粒度更细、场景覆盖更全面、用户体验更好、投入产出比更高。在这个本质之上，是用SDP，还是SPA，还是微隔离，都只是手段、不是目的。
6. 零信任不是一副安全领域的万能药，依然有其解决不了的场景和问题。

4.2 应用零信任的思考

1. 在选择零信任产品、方案时，应牢牢把握“永不信任、持续验证”的核心特征，并且深入理解到，永不信任是不基于来源网络位置进行隐形信任，而是每一次对应用和资源的访问过程，以动态决策来判断，持续验证是对应用访问过程的数据为目标进行持续验证，而非接入网络前后的接入验证。课题组观察到业内有些厂家提供的方案，只是在接入层面针对身份和多维度的设备信息进行了验证，但是在获得认证通过之后并没有持续对应用访问请求，结合动态策略中定义的业务身份、终端环境、时间、位置等维度的持续监测和验证，我们认为这并不符合零信任的思想。
2. 零信任产品、方案可在不改变网络架构的基础上，基于“用户+实体”身份 + 应用 + 访问行为，构建更有效的访问控制体系，值得投入；
3. 零信任应该充分考虑基于应用层的零信任方案，实现类似BeyondCorp效果，可以抵御0day、1day攻击大幅降低应用和业务安全风险；
4. 零信任充不单需要考虑安全，更需要考虑业务效率，让安全和业务可以取得更好的平衡，实现安全支撑业务的目标。
5. 零信任建设过程，最终会和传统安全路径一样，从基础的网络层、再深入到更复杂的应用层、最后再到业务数据层，最终会实现以数据为最小颗粒度的零信任；
6. 在恰当的企业环境下，零信任技术架构可以成为IT基础设施之一，但这取决于企业IT环境以及管理者采用新架构思想的魄力与勇气；
7. 未来在一家企业内，很可能会存在多套零信任产品、方案，但最后应通过一套统一的决策引擎进行决策、协调和控制；
8. 零信任产品如在终端上部署agent，则可增加终端维度的数据，“持续验证”的思想也要求持续获取终端上的身份和行为，并交给后台决策引擎在对应用放过程中，对每一个请求基于请求目标状态和来源终端安全状态进行持续验证。零信任产品与终端安全产品（如沙箱、EDR、桌管程序、DLP）、SASE最终可能在产品形态上会不同程度地整合，如果不能整合、则至少要做到数据复用、决策引擎复用。
9. 在混合云、容器云环境下，微隔离是一个可选的技术方案，但是否为最佳方案仍有争议。在这种环境下是不是仍有必要对四层协议进行控制，仍有争议。