文档标题;基于零信任架构的企业网络动态访问控制系统的设计与实现

文档介绍：

1 绪论

1.1 研究背景与意义

云计算，移动互联网以及物联网技术极速发展之际，现代企业的网络环境产生了质变，远程办公，移动办公成了新的常态，企业数据与应用资源不再受限于传统且边界清晰的内部网络。这样的改变既优化了业务的灵活性，又大幅模糊了企业的安全边界，传统的网络安全框架，防火墙，VPN之类，秉持“边界守护”观念，默许信任内部网络里的全部用户及设备，但是近些年来安全事件频繁发生，这显示“内网即是安全”的想法已然行不通，一旦入侵者冲破外层防护，就可以在内部网络里随心所欲地横向移动，盗取机密资料，带来不小的损害，所以，企业急需一种可以应对无边界网络环境，并打破原有信任的新式安全框架。

在此种背景之下，零信任架构就此诞生，很快变成网络安全领域的核心话题，零信任的核心观念在于“绝不信任，持续校验”。这完全打破了依靠位置的隐式信任模式，此架构认定网络时刻存在风险，不论用户或者设备处在内部网还是外部网，均不会赋予任何信任，每一个访问请求都要经过严格的认证，授权以及加密，这样的观念从本质上弥补了传统边界守护模型的不足，可以有效地防范内部威胁，凭证盗用和横向移动打击，所以，规划并且达成一个依托零信任架构的动态访问控制系统，对于优化现代企业的整体安全防护能力，捍卫核心业务和数据资产的安全来说，有着非常关键的理论意义和实际价值。

本研究的意义并非仅仅是对零信任理念实施理论层面的探究，更深层次来说是一种技术应用上的操作行为，经由形成起一个覆盖全面度信任考量，具有动态策略执行能力并且存在持续验证机制的系统，文章给企业由传统安全模型迈向零信任模型给予了具象而实用的技术路线，如果这个系统得以达成，则能助力企业做到精准细致的访问控制，依照用户，终端设备，操作行为以及所在环境所处风险级别自动调整相应权限设置，如此一来既能保证信息安全，又不会干扰到合法用户正常展开访问活动，这对推进零信任框架在企业内部的实际执行有着积极意义，也利于引导相关安全软件的研发工作，并充实网络安全方面的工程操作经验储备。

1.2 国内外研究现状

1.2.1 国外研究现状

国外对于零信任架构的研究开始得比较早，现在已经由理论探讨阶段迈进大规模操作与标准化阶段，2010年，Forrester研究机构初次提出零信任概念，给后面的研究形成了基础。真正把零信任理念投入到实际应用当中去的是Google公司，它在2014年前后启动并且达成的BeyondCorp项目，完全不再依靠对内部网络的预先信任，把所有的应用程序都安排在公共网络上，凭借用户和设备的凭证执行动态访问控制，BeyondCorp项目有所成果，这便向全行业表明零信任架构在极为庞大的系统环境下具有可行性与优势，成了后来所有零信任解决方案的关键参照。

美国国家标准与技术研究院于2020年发布了SP 800-207《零信任架构》标准，这是零信任领域的里程碑式文件，该标准详细阐述了零信任架构的核心模块，逻辑模块，部署场景以及潜在威胁，给企业和安全厂商赋予了权威，客观的执行指导。在商业市场上，许多国际安全巨头也都推出了成熟的零信任产品，比如思科的Duo Security主要依靠零信任的多因素认证和终端可见性；帕拉卢托网络公司的Prisma Access将自身的零信任理念同安全访问服务边缘（SASE）架构相融合；Okta身为身份云领域的领军者，其身份即服务（IDaaS）平台是做到零信任身份管理的关键部分，这些研究和操作一同形成了当下国外零信任领域的繁盛局面。

1.2.2 国内研究现状

国外对零信任架构的研究及落地起步较国内早些，不过国内后来居上，发展速度飞快，形成起“产学研”共同推进的良好态势，奇安信，腾讯安全，阿里云这些国内顶尖的安全厂商，均把零信任当作关键战略，并推出自身拥有专利权的解决方案，奇安信提出“内生安全”概念，把零信任架构深入结合到安全能力当中，重视安全与业务的紧密联系；腾讯安全的iOA重点在于终端环境的感知以及动态访问控制，在腾讯内外客户那里已得到大面积应用；阿里云也把自己零信任能力纳入云原生安全体系，从而给云端用户赋予身份和网络方面的精准控制能力。

国内高校与研究机构的学者针对零信任关键技术展开了深入探究，其研究热点主要聚集于信任评定模型的创建，属性依赖访问控制策略的改良以及与人工智能技术融合以达成自适应安全等事项，纵使研究热度十分高涨，不过比起国外来，国内在零信任核心理论革新以及大型度，跨行业且已成气候的实际应用范例上还是存在一些差距的，诸多研究成果只是处于实验室内，并未出现可以同国外成熟商业产品正面抗衡，在业内颇具影响力的综合性平台，于是，本研究期望经由规划并形成起一个功能完备，逻辑条理的动态访问控制系统，进而为国内零信任的技术化运作添砖加瓦。

1.3 研究内容

本文主要研究内容在于设计与完成依托零信任架构的企业网络动态访问控制体系，此体系力求冲破传统以网络位置确立信任的模式，经由针对每次访问请求开展全面且持续不断的安全考量，做到动态又精准的授权判定，具体研究内容可拆解成如下几个关键模块：形成一种立体度信任考量模型，该模型要从身份，设备，行为以及环境这四个方面共同评定一次访问请求所处的风险级别，并给出一个定量的信任评分，这便是整个体系达成动态访问控制的决定依照。

设计并完成一个灵活高效的动态策略引擎，此引擎需具备依照规则设定策略的能力，管理员可遵照信任等级，用户角色，设备状态，访问时间等诸多条件的拼合情况来制订访问控制策略。策略引擎要随时考量每一个访问请求，并按照预先设定好的优先顺序以及适配规则，立即给出“准许”或者“阻止”的判断结果，其三是做到一套完备的身份验证及会话守护系统，凭借JWT技术达成无状态且具扩展性的认证服务，还要探寻怎样把信任评分动态纳入到令牌的生存时段管理当中，而且，该系统须要给予诸如用户管理，设备守护，访问日志审查以及安全状况可视化之类的辅助功能，从而方便系统的日常运行维护和安全检测，经过前面内容的探究与执行，最终创建起一个完备且能运行的零信任动态访问控制系统的雏形。

2 相关技术介绍

2.1 零信任架构

零信任架构属于新的网络安全范式，其核心原则为“永不信任，始终验证”，这彻底颠覆了传统以边界为基础的信任模型。传统模型当中，处于企业防火墙内部的用户，设备以及流量被视作“可信”的，外部的就全是“不可信”的，但是零信任却觉得，威胁有可能出自内部，也有可能出自外部，所以不能把网络位置当作信任的依照，所有想要访问企业资源的请求，不论是来自公司内部的工位，还是远处的咖啡厅，都要通过同样严格的身份认证，授权和加密。 这种架构把网络环境当作“敌对”的来假定，促使我们任何时候都不能松懈警觉。

NIST SP 800 - 207标准为落实这种理念，定义了零信任架构几个关键的逻辑部件，策略引擎（PE），策略守护（PA）和策略执行点（PEP）最为重要。策略引擎如同系统中枢，负责作出关乎访问的终极判定，它按照企业安全策略，由外部源头得来的信息，以及当下的信任评价情况，来判断是否认可某个具体的访问请求，策略守护充当执行角色，其职责在于形成或者阻断主体和资源之间的数据通道，依照策略引擎所作出的决定，向策略执行点发出指示命令，而策略执行点起到像关卡一样的作用，会实际去拦截并且处理从用户端发送到资源端的访问请求，它可以是网关，或者是某个代理程序，亦或是部署于终端之上的相关软件，这些部件相互配合，从而形成了零信任架构“持续核查，动态授权”的核心根基。

本系统的设计与完成严格按照这种架构理念来执行，把系统的核心决策逻辑分离出来，形成控制平面；把API网关和前端界面当作策略执行点，经由这样设计，保证所有针对后端资源的访问请求都要先被控制平面仔细核验，控制平面会每次请求时重新计算信任分，而且随时评定策略，从而达成真正的“动态访问控制”，既改善了系统的安全性，又让其具备较好的适应能力，可以灵活应对始终处于变化中的企业网络环境与安全威胁，这是零信任理念在实际工程应用中的全面落实。

2.2 Spring Boot框架

Spring Boot属于当下 Java 生态系统当中用来塑造微服务以及独立应用比较热门的框架之列，它依托于功能强劲的 Spring Framework，凭借“约定优于配置”这种想法，大幅精简了创建 Spring 应用及执行开发流程的步骤，Spring Boot关键的优点就源于自身包含的自动配置功能，开发人员要做的只是加上一些指定的“起步依赖”，然后框架就会自行分析判断，并设置好运行一个 Web 应用所必需的各类元件，比如内置的 Tomcat 服务器，Spring MVC，JSON 格式化工具等等，从而做到近乎无需任何设置就能顺利启动起一个具备完整功能的 Web 项目。

Spring Boot还具备一系列生产环境中可用的功能，健康检测，指标观察，外部化设置等等，这些都非常利于应用程序的部署与维护。它内置了Servlet容器，这样应用就能被打包成单独的JAR文件，用java - jar命令就可以运行起来，免去了传统部署时把WAR包放到外部Web容器里的那些复杂操作，如此简单方便明显优化了开发和交付的速度，对当前这个系统来说，Spring Boot这些特点很适合创建稳定的高效后端服务。

在本系统的后端完成过程中，我们全面运用了Spring Boot及其生态体系，把Spring Boot当作基本框架，迅速创建起RESTful API服务，采用Spring Security框架去解决身份验证与授权问题，凭借Spring Data JPA来简化数据库访问流程。Spring Boot具备自动设置的功能，它让我们可以较为轻松地把这些不同的技术模块融合起来，免去大量编写XML设置文件的麻烦，最后，整个后端服务被封装成一个可执行的JAR文件，其部署过程变得非常简单，这恰是Spring Boot框架“简化开发，提升交付”这一核心价值的显现。

2.3 Vue 3框架

Vue 3 是一个渐进式的 JavaScript 框架，可用于创建用户界面和单页应用，相比于 Vue 2，Vue 3 在性能，类型支持和开发体验方面均有明显的改善，它采用了合成式 API，这是一种新的，更为灵活的代码组织及逻辑复用方法，与 Vue 2 中传统选项式 API 不同，合成式 API 让开发者可依循逻辑关注点来安排代码，无需像从前那样被迫按照 data，methods，computed 等选项去分割代码，这样就能把复杂组件相关的逻辑归结到一起，从而突出优化代码的可读性和可守护性。

Vue 3 的又一改良之处在于它对 TypeScript 的良好支持，整套框架的源码皆重新编写为 TypeScript 版本，这给开发者赋予了完备的类型定义以及优秀的代码建议能力，对于利用 TypeScript 做大规模项目开发而言，可以缩减因类型而产生的失误，加强开发速度并使代码更为稳固可靠，就性能来说，Vue 3借助改良虚拟 DOM 算法，采用静态提升以及树晃动等手段，达成了更快速的渲染效果并且压缩了打包之后的文件大小，而且包含了 Teleport 和 Suspense 这类新颖功能，可以针对某些指定的 UI 情况给予更精致的应对办法。

在当前这个系统当中，前端部分依靠 Vue 3 框架搭建起来，利用组合式 API 来编写各个功能模块的业务逻辑，这样代码结构就很清晰，也好懂，也好拓展。拿用户管理模块来说，有关用户列表显示，搜索，新增，编辑的全部逻辑都被归纳在一起，而且用 Vue Router 的官方路由库去管页面路由，凭借 Pinia 这个状态守护工具来保存用户信息，令牌之类的状态，在 UI 组件上，采用 Element Plus 组件库，此库包含很多适合企业级应用风格的 UI 组件，极大地提升界面开发的速度，把这些技术融合之后，就形成一个反应灵敏，交互顺畅又比较容易守护的前端应用。

2.4 JWT技术

JSON Web Token 是一种开放标准，它用于在网络应用环境之间安全地传递声明，因为具备紧凑又自包含的特点，JWT 在分布式系统和单点登录场景里被全面采用。一个 JWT 令牌包含三部分：Header， Payload 和 Signature，这三部分经 Base64Url 编码并用点号串联起来，Header 大多会体现令牌类型和签名算法，Payload 是关键部分，其中载有必要的声明信息，比如用户 ID，用户名，过期时间和若干自定义的业务数据，而 Signature 是把 Header 和 Payload 按照指定算法并结合某个密钥得出的，目的在于确认令牌在传送时未遭篡改。

JWT最大的优点就是它的“无状态”特点，传统的依靠Session的认证方法要在服务器端保存会话信息，在分布式系统当中会出现Session共享以及扩展困难的情况。不过JWT会把用户的状态直接融入到令牌里面，服务器不需要保存任何会话信息，一旦用户经过了认证，服务器就会给出一个JWT给客户端，之后每次客户端发起请求的时候都会带上这个JWT，服务器只要验证一下令牌的签名和是否有效就行了，这样就可以知道用户的身份，这种方法明显简化了服务器的体系结构，使得服务器能够轻易执行水平扩展，而且，JWT这种自身具备完整性的特性，很适合微服务架构，各个服务可以用JWT便捷地传递用户上下文。

在当前这个系统当中，JWT充当着关键的身份认证凭证，当用户完成登录操作之后，后端就会向前端传递一个包含用户身份信息的JWT令牌。在这个令牌的Payload里，除了存有用户的身份资料外，还会加入当次会话的设备标识符以及经过即时计算得出的信任分值，之后每一次发起API请求的时候，都务必在HTTP头里附上这个JWT令牌才行。而后端设置了专门的JWT认证过滤器来拦截所有传来的请求，去核实JWT是否有效，而且从中获取用户的相关信息以及信任环境数据，这样就使得我们的认证体系具备了无状态特性，免去了要在服务器端保留大规模的Session数据库的必要，进而增强了系统的运行效率及其拓展能力，把像信任分之类的动态参数融入到JWT之中，给后面执行动态权限检查带来了方便。

2.5 MySQL数据库

MySQL 是当前全球范围内广受追捧的开源关系型数据库管理操作系统之一，其具有高性能，高可靠性，易用性以及跨平台性等特点而知名。MySQL 支持标准的 SQL 语法，并且包含 InnoDB，MyISAM 等多种存储引擎，从而满足不同场景下的需求，其中 InnoDB 是默认的存储引擎，它具备 ACID 事务，行级锁定以及外键约束等功能，非常适宜应对那些要求较强的数据完整性和并发控制的企业级应用，凭借自身这些特点，MySQL 成为了形成 Web 应用，数据仓库以及电子商务平台等各种系统稳固的数据存储备案。

MySQL有另一个很重要之处，即它的性能优良且具备可扩展性，经由合理规划索引，改良查询，并采用主从复制，读写分离之类的架构方案之后，MySQL能够应对海量数据并且满足非常高的并发访问需求。MySQL有着规模宏大而且十分活跃的开源社群，这样以来，开发者就能轻易寻获大量文档，教程以及解决各种问题的办法，而且，MySQL还供应很多管理工具，譬如MySQL Workbench之类的东西，这给数据库守护者执行数据库设计，开展SQL相关事务以及实施服务器守护带来了便利，如此繁多的生态体系资源把开发和运维方面的成本大幅削减了。

本系统当中，MySQL 8.0 版本被当作持久化存储方案，用它来保存那些必要长期保留的结构化数据，包含用户的基本资料，设备注册信息，访问控制策略的设定信息，还有大量的访问审核日志，Spring Data JPA 框架给我们供应了对象关系映射功能，这样我们就可以经由操作 Java 对象间接地操作数据库，从而不需要写很多 JDBC 和 SQL 代码，这种分层设计既能保障数据访问的效率，又能使数据层的代码变得更为简练，便于管理，进而很好地符合系统对于数据持久化和查询方面的要求。

3系统需求分析

3.1 功能需求分析

3.1.1 用户管理功能

用户经营属于任何安全系统的根基部分，本系统也一样。这个功能的关键需求在于形成起一套完备的用户身份生命时段维持机制，其一，系统要支撑用户的注册及登录操作，注册的时候，用户得供应相关的身份资料，系统会对像用户名，邮箱这样的重要信息执行唯一性检查，而且要把经过强力加密处理后的密码存起来以保障数据安全，至于登录功能，则须要证实用户凭据是否有效，只要验证过程没问题，系统就会向其发放一个用来表明身份的令牌，其二，系统应当赋予用户信息经营方面的充足功能，使得用户能够自行查看并修改自身的基本资料，不过管理员所具有的权力更大一些，其既可以查阅也能创建，修改或者彻底删除任意一个用户账号。

用户管理功能要想达成精准化的权限控制，就要具备角色与权限的运作能力，系统得要预先设定大量角色，比如具有全部权限的管理员，专职处理日常设置的操作员，还有只能查看数据的审查员，把权限分配给角色，再把角色分配给用户，就可以有效地创建起依靠角色的访问控制模型。管理员能够自如地设定各个角色可访问的菜单，页面以及 API 接口，如此一来既简化了权限分配时的管理难度，又能让安全策略同组织架构相适应，保证承担不同职责的人只能在自己的权限范围内做事，这是符合企业合规性要求的关键前提。

3.1.2 设备管理功能

在零信任架构当中，设备安全状态和用户身份同样重要，所以设备运作也是系统的一项关键功能，此功能首先要完成的任务便是设备注册，当用户第一次利用新设备去访问系统的时候，要在系统里把设备信息记录下来，注册信息一般包含独一无二的设备ID，设备名称，设备种类以及操作系统版本等等内容，等到注册过程结束之后，这个设备就会被绑定到某个特定的用户账号上面，从而变成持有其访问资源的一个载体，系统要有这样一个专门用来管理设备信息的界面，使得用户或者管理员能够看到系统里全部已注册设备的详细情况，而且可以对设备名称，备注之类的可以更改的地方执行修改操作。

设备运作功能的深层需求在于不断执行状态观察并展开合规性核查，系统需具备感知设备在线状况及最后活动时间的能力，对于长时间未上报状态或者行为出现异常的设备，系统应当自动减小其信任层级。系统还要制定出一套设备合规性核查准则，其中涵盖诸如检查设备是否安装了指定杀毒软件，是否启用了系统防火墙以及是否开启了磁盘加密等情况，这些合规性核查的成果会直接左右设备的最终信任评分，针对不符合规范的设备，系统应该自动缩减其访问权限，甚至将其标记为“已阻止”状态，直至相关问题得到解决，这样一种持续评定设备安全形势的机制，体现了零信任架构“永不信任，始终核验”的原则在设备层面的具体表现形式。

3.1.3 信任评估功能

零信任架构的关键所在是信任评定功能，这一功能令“动态”访问控制得以实现，其核心要点在于从大量维度入手综合考量单次访问请求的风险级别，该系统设定了四个重要的评定维度，其一为身份信任，重点在于评判用户凭证是否可靠，所考虑的因素涵盖用户是否开启了多因素认证，自身历史行为的信任程度以及近段时间有没有出现异常登录失败的情况等，其二则是设备信任，关注点放在评价发起请求的终端是否安全之上，相关的依照包含设备过往的信任水平，合规性检测的结果以及是否具备必要的安全防护手段等等。

行为信任重点在于考察用户获取资源时的行为模式是否偏离其常规特征，拿个员工来说，他总是在上班时间段登录内部文档系统，一旦系统察觉他在凌晨四点由外地IP执行针对核心数据库的高频访问操作，这种情况就极有可能存在安全隐患，所以应当减小信任度。上下文信任会考虑访问产生之时的诸多外围要素，譬如说，从公司局域网开始的操作就比下班后用公共无线网络做的访问可信度更高，系统得要随时收集这四个方面的情况，按照事先制定好的框架以及重要程度自动算出一个合成的信任值，再遵照此数值划分成不同级别来作为后续战略安排的参考指标。

3.1.4 策略管理功能

策略运作功能是给安全运作人员供应的一种设置工具，用以描绘怎样应对不同信任等级的访问请求，其主要需求就是给予一种灵活而有力的策略设置框架，运作人员应当可以创建，编辑，删除并开启或者停止访问控制策略，每条策略须要有基本资料，包含名称，描述以及优先级等信息，优先级是决定策略评价先后顺序的重要特性，系统要按照优先级从高到低的顺序来依次适配策略，而且，每条策略也要规定一个默认操作，一旦策略里面的全部规则均不相符时，就会执行这个默认操作，策略的关键就在于“规则”这个概念，一条策略可能包含很多条规则，每条规则又由条件和动作这两部分构成。

规则的条件需十分充足，从而涵盖零信任考量的各类场景，这些条件包含用户属性，设备属性，资源属性，环境属性等。经由将这些条件加以结合，管理者能够制定出诸如“只准许信任等级为‘高’的设备在工作时段访问财务系统”之类的精准策略，策略考量引擎要即时解读这些规则，把当下访问请求的相关背景同规则条件做对照，只要找到契合的规则，便立刻按照该规则所界定的操作予以执行，倘若系统当中所有策略的所有规则均未相符，则会依循“默认拒绝”的安全准则来拒掉此请求，这样一种较为灵活的设计，给系统顺应各个企业的专属化安全需求形成了根基.

3.1.5 访问日志功能

访问日志功能是安全审查，事后追溯以及识别威胁的关键依照，它最核心的需求在于能够自动且细致地记录针对系统资源的所有访问行为，每当下一个 API 请求得到处理的时候，系统都要在日志里体现一些重要信息，其中涉及：访问的确切时间戳，执行访问的用户 ID 和用户名，所用设备 ID，请求源 IP 地址，开展的操作类型，访问的目标资源 URL，系统针对此请求的终极决策结果，还有当时的综合信任分数，这些信息形成起完整的事件证据链，对于复原攻击场景，分析安全事件十分关键。

访问日志模块除具备记录功能外，其应有的强大查询及分析能力也不容忽视，管理者需经由一款友好型界面，遵照各类条件的复合情况执行检索操作，按照指定用户，专门设备，具体时段以及访问成果等等，如此一来有益于立即找到问题所在或者实施安全检查工作。更为关键的是，系统要针对大量的原始日志展开统计分析并实施可视化展示，譬如计算出每个小时的访问请求数量，描绘出访问趋向曲线；依照用户权限或者设备种类来统计访问分布状况；而且还要核算不同信任层级请求所占比例及其变动趋势等，这些统计资料能清晰显示系统的全局安全状况，便于安全小组察觉到不正常的数据峰值或者潜藏的破坏迹象，进而由消极防护转为积极通报。

3.1.6 安全态势可视化功能

安全态势可视化功能期望把系统后台繁杂又零散的安全数据以图形化形式清楚显现给管理者，从而达成对全局安全情况的“一清二楚”，此功能的关键需求在于创建起一个集约度较高的仪表盘页面，在这个页面当中，系统管理员可以马上看见最为核心的安全概要指标，比如当下的系统总用户数，注册设备总数，近24小时的访问总量以及即时告警事件数量等等，这些关键指标是以卡片样式表现出来的，给予了系统良好程度的大致景象。

为更深层次地探寻安全趋势，仪表盘需用诸多图表表现数据，利用折线图体现近7天或者30天的访问请求数量变动趋势，可利于察觉业务高峰期或是潜在破坏波。凭借饼图或者环形图显示当前全部活跃设备的信任等级分布状况，会使得经营者清楚地评判企业整体的设备安全基本水平，采用柱状图表现不同种类操作系统或者设备的访问所占比例，有益于认识终端的丰富程度情况，经由这些可视化部件，经营者不必仔细阅读很多原始日志或者报表，就可以立即知道系统的安全动向，而且，系统还具备数据的导出能力，给予经营者把仪表盘上的统计图表或者数据表格导出成Excel或者PDF格式，方便在内部述职或者安全核查的时候加以运用。

3.2 非功能需求分析

3.2.1 性能需求

实际运作的企业级系统要想保障用户体验并维持业务连续性，良好的性能很关键，该系统需符合一些明确的性能指标，首个指标就是响应时间，系统核心API接口的平均响应时间要控制在500毫秒之内，而且至少有95%的请求响应时间不超过1秒，在常态负载情况下，当用户执行登录，开启页面以及开展操作的时候，不应该察觉到较为明显的迟缓，信任考量和策略决策属于每个请求必定经过的核心环节，其自身的处理迟缓须要很小，常常得改良到十几毫秒甚至更低的水平，从而防止成为整条请求链路上的障碍点。

系统应具有良好的并发处理能力，要能同时为至少100个并发用户服务，而且不会发生服务崩溃或者响应时间大幅变差的情形。这便要求后端服务在设计之时需考量多线程处理，数据库连接池改良等要素，系统还得对自身的数据处理能力作出规定，格外是对访问日志而言，出于安全审查的需求，系统每日也许会生成数万条乃至十万条级别的日志记录，所以，数据库和日志服务必要能够承担如此规模的数据写入负荷，并且还要确保在这么大的数据量情况下，复杂的日志查询操作仍旧可以在合理时限之内达成。 系统若想要在真实的企业环境下稳定运行，就务必得具备这些性能需求，否则就无法做到。

3.2.2 安全需求

安全产品自身安全性极为关键，要从大量层面加以保障，其一，身份认证需谨慎，系统应对各类访问请求执行身份验证，杜绝未授权访问情况发生，除基本的用户名/密码认证外，还应支持多因素认证，给高价值账户带来更多层次的安全防护，其二，密码存储务必采用强哈希算法（像 bcrypt）并施加加盐处理，决不允许明文存储，其三，访问控制应当有效，系统要达成依靠角色的访问控制，保证前端页面显示以及后端 API 接口均受同权限规则约束，规避越权操作，也就是普通用户不可直接调用 API 来读取或者更改管理级别数据。

数据加密属于另一核心安全诉求，敏感数据传送时需采用HTTPS协议执行加密，避免出现中间人窃听情况。数据库里存有的敏感设置信息也要考量加密存储，完备的审查日志是达成安全合规性以及事后追寻的必备要素，系统应当详尽记载各类关乎安全的事件，特别像认证是否通过，权限变动，规则调整，重要资源访问等活动，这些日志务必得到保护，不能被篡改或者清除，只有符合这些严格的安全要求之后，系统才会被放心地置于企业环境当中，并成为其安全架构里值得信赖的一部分。

3.2.3 可用性需求

系统的可用性同管理员和终用户使用的意愿及效率休戚相关，其一，用户界面需具备友好性，前端界面要依照清晰度，直观性的设计准则，其布局应当合理，色彩搭配也要让人感觉舒适，而且交互反馈得及时，操作流程最好能简化至极，剔除那些毫无必要的复杂环节，当添加或者修改信息的时候，表单就应该立刻执行校对功能，一旦提交出现差错，就要清楚地显示出具体的失误之处，从而辅助用户快速加以改正，针对那些重要或者极具危害性的行为（比如删除策略，冻结用户之类的事务），系统务必给出二次确认窗口，以防发生误操作的情况。

系统要有完备的错误处理机制，一旦用户输入非法数据或者后端服务出现异常，系统就不能直接暴露出技术细节，比如堆栈跟踪信息，而是应该给用户显示一个既友好又信息充足的错误提示页面，诸如“操作失败，请稍后再试”或者“您没有权限访问此资源”。后端还要把完整的错误日志记录下来，以便开发或者运维人员来查找问题，而且，为了让用户尽快熟悉操作，系统应当给予必要的文档支撑，比如一份简明扼要的用户操作手册，里面包含主要功能的阐述，执行步骤的图片以及解决常见问题的办法，出色的在线帮助或者指引提示会极大改善系统的易用程度。 如果满足了这些可用性需求，就可以减小系统的学习成本并优化用户满意度，进而推动系统的全面推广应用，良好的在线帮助或者引导提示会突出改善系统的易用性。

3.2.4 可扩展性需求

在设计之初就要考虑可扩展性，这样就能保证系统在未来业务增长或者需求变更的时候，可以低成本地发展，架构的可扩展性首先表现在水平扩展能力方面。系统中的关键服务，尤其是无状态的后端API服务，应当能够经由增加服务器节点并且部署相同代码来改善整体处理能力，这便要求系统不能存在妨碍水平扩展的瓶颈，比如将会话状态存储于本地内存当中，本系统采用依靠 JWT 的无状态认证设计，就是为了解决这个问题，从而让 API 服务器集群得以轻易地横向扩展。

功能上的可扩展性非常重要，系统要有模块化，低耦合的设计，这样将来添加新功能模块的时候，对当前系统的影响就会很小。比如说，以后也许想要整合威胁情报服务，从而充实信任评定的依照，还可能会增添对OAuth2.0这种第三方身份源的支持，一个好的系统应当凭借预先保留好的接口或者插件机制来平和地做到这些扩充，不需要重新构造大量的现存代码，从数据方面来说，其可扩展性同样不可漠视，数据库设计要考虑到数据量极速增长的情况，比如访问日志表之类的，可以经由合理设置索引，采取分区表策略，甚至日后采用数据仓库或者Elasticsearch之类的大数据储存方案来进行应对。 提前考量这些可扩展性需求，属于塑造长期又稳定的，可持续发展的系统的战略保障。

4系统设计

4.1 系统架构设计

本系统采取前后端分离这种架构模式，按照零信任架构中的逻辑部分划分情况，把系统明确地分成控制平面，数据平面和前端显示层，控制平面位于整个系统的核心地位，承担着全部有关安全逻辑的处理事务，其包含诸多经过微服务化改造的组件，认证服务，用户服务，设备服务，信任评定服务，策略服务以及日志服务等，这些服务相互配合，一起达成了“持续考察，动态授权”这一关键逻辑。

数据平面为系统供应基本支撑，重点在于数据的持久化存储及高速缓存，我们选定 MySQL 作为关系型数据库来存储用户，设备，策略，日志等需长期保存而且具备结构化特征的数据，而且，为改善系统性能，我们采用 Redis 作缓存数据库。Redis 主要用来缓存会话信息，经常被访问的策略规则以及 JWT 令牌的黑名单，把热点数据存入内存之后，就能大幅减轻对数据库的访问压力，加快策略评价和令牌验证的速度，控制平面中的各项服务会经由统一的数据访问接口和数据平面开展交互。

前端表现层充当用户与系统交互的窗口，依靠 Vue 3 框架创建为单页应用，前端应用经由 RESTful API 向控制平面发送消息，用户所做的一系列操作，包含登录，查看仪表盘，经营用户及设备，设置策略等，都被打包成 API 调用来处理，前端应用自身并不具备任何业务逻辑或者安全决策逻辑，其职责仅仅局限于显示数据以及传递用户指令而已。这样一种前后端分离的设计，一方面让开发工作得以同步推进，从而优化开发速度，另一方面令系统内部结构变得更为明晰，各自责任界定得也愈发清楚，控制平面能够单独布置与扩充，前端应用同样可以借助 CDN 等途径达成高速度流传，整个系统的可保全性与可扩充性也因此而明显改善。

4.2 数据库设计

数据库设计属于系统设计的关键部分，其关乎到系统的数据完整性，查询效率以及拓展能力，经由对系统功能需求加以分析之后，我们规划出一种关系型数据库模型，其中的主要实体包含用户，角色，权限，设备，访问策略，策略规则，访问日志以及信任分数，用户表保存着用户的登录凭据，基本档案以及安全状况信息，比如账户有没有被锁住，当前处于哪个信任级别等，设备表会记载每个已注册设备的详细情况，运行状态，最新的符合性得分和信任等级，而且依靠外键同用户表相联系，这便显示了设备属于某个特定用户的逻辑含义。

为达成灵活的访问控制目标，我们规划了策略表与策略规则表，其中策略表主要用于存储策略的元数据信息，比如名称，优先级以及默认操作等内容，而策略规则表经由外键与策略表形成关联关系，每条规则会记录具体的契合条件及其对应的操作内容，如此一来就形成了前述的一对多结构，从而使得管理员能够针对某条策略设置诸多规则，从而大幅提升了策略的表现力，系统中的访问日志表是数据增量最为迅猛的一张表，该表被安排纳入大量的查询角度信息，包含用户ID，设备ID，访问资源，决策成果以及时间戳等等要素，为了优化查询效率，我们在这些常见查询字段之处创建适合的索引，整套数据库设计依照第三范例准则展开，目的在于削减数据重复现象并守住数据一致性，而且借助外键限制手段维持各个实体之间相互依存的完整性状态，进而给位于高层的应用供应稳固且可信度高的数据支撑功能。

用户表（users）结构如表4-1所示：

字段名	类型	说明
id	BIGINT	主键
username	VARCHAR(50)	用户名，唯一
password	VARCHAR(255)	密码（加密）
email	VARCHAR(100)	邮箱，唯一
full_name	VARCHAR(100)	姓名
department	VARCHAR(100)	部门
job_title	VARCHAR(100)	职位
status	ENUM	状态（ACTIVE/INACTIVE/LOCKED）
trust_level	ENUM	信任等级（HIGH/MEDIUM/LOW/UNTRUSTED）
mfa_enabled	BOOLEAN	是否启用MFA
created_at	DATETIME	创建时间
updated_at	DATETIME	更新时间

设备表（devices）结构如表4-2所示：

字段名	类型	说明
id	BIGINT	主键
device_id	VARCHAR(100)	设备ID，唯一
user_id	BIGINT	所属用户ID
device_name	VARCHAR(100)	设备名称
device_type	VARCHAR(50)	设备类型
os_type	VARCHAR(50)	操作系统类型
os_version	VARCHAR(50)	操作系统版本
ip_address	VARCHAR(45)	IP地址
mac_address	VARCHAR(17)	MAC地址
status	ENUM	状态（ACTIVE/INACTIVE/PENDING/BLOCKED）
trust_level	ENUM	信任等级
compliance_score	INT	合规分数
is_compliant	BOOLEAN	是否合规
registered_at	DATETIME	注册时间

 策略表（access_policies）结构如表4-3所示：

字段名	类型	说明
id	BIGINT	主键
name	VARCHAR(100)	策略名称
description	VARCHAR(500)	描述
priority	INT	优先级
default_action	ENUM	默认动作（ALLOW/DENY）
enabled	BOOLEAN	是否启用
created_at	DATETIME	创建时间
updated_at	DATETIME	更新时间

 访问日志表（access_logs）结构如表4-4所示：

字段名	类型	说明
id	BIGINT	主键
user_id	BIGINT	用户ID
username	VARCHAR(50)	用户名
device_id	VARCHAR(100)	设备ID
action	VARCHAR(50)	操作类型
target_resource	VARCHAR(255)	目标资源
decision	ENUM	决策（ALLOW/DENY）
trust_score	INT	信任分数
source_ip	VARCHAR(45)	来源IP
timestamp	DATETIME	时间戳

4.3 信任评估模型设计

信任评价模型处于零信任架构的核心地位，它的设计关乎到系统动态决策的准确性与有效性，这个系统创建起一种立体度加权评价模型，从身份，设备，行为和上下文这四个方面来全方位考量访问请求并给予综合评分，每一个维度下面存在许多具体的评价指标，身份信任维度会探究用户是否开启了多因素认证，用户的账户以往的信任等级还有近来的登录失败笔数等情况，设备信任维度则会关注设备之前的信任等级，即时合规检测的结果以及设备是否处在活跃使用之中，各个评价指标都有自己的分值，系统会自动去采集这些指标当前的状况，并且算出属于此维度的总计分数。

模型重点在于综合信任分数的计算，这依靠加权平均算法来完成，各维度对于安全影响的权重存在差别，所以每个维度均被分配不同的权重系数。经由理论分析与实际操作考虑之后，把设备信任的权重设置得比较高，这是因为终端设备是安全事件发生的现场，其安全性非常关键，身份信任的权重排在第二位，身份乃是授权的基础，而行为信任和上下文信任属于动态风险的辅助评定部分，因而其权重就比较低一些，系统会先把设备信任，身份信任，行为信任以及上下文信任这四个方面所得到的分数分别乘以其对应的权重系数，然后再把这些数值相加，从而得出一个处于百分制范围内的综合信任分数，按照这个分数落在哪个区间，系统就会自动把用户的信任等级分成“高度信任”，“中度信任”，“低度信任”和“不可信”这四级别，此模型输出的信任等级将会成为后面策略引擎执行访问控制决策时非常关键的一项输入要素。

根据综合信任分数，将信任等级划分为四个级别：

信任等级	分数范围	说明
HIGH	80-100	高信任，可访问所有资源
MEDIUM	50-79	中等信任，可访问普通资源
LOW	30-49	低信任，仅可访问基本资源
UNTRUSTED	0-29	不可信，拒绝访问

4.4 访问控制策略设计

访问控制策略的设计目的在于创建一种既有力又灵活的机制，从而让安全运作人员遵照信任评价结果以及其他上下文信息来精准地管理对企业资源的访问，我们设计出一种依靠规则的策略模型，各条单独的策略均涵盖若干关键要素：基本元数据，用以显示评价顺序的优先级数字，预设动作以及包含大量具体规则的集合，规则充当策略实际执行的载体，其由一组条件和动作构成，这些条件可针对用户属性，设备属性，资源属性，环境属性等各类要素执行任何形式的合成，譬如某条规则的条件就可界定为：用户角色为“财务” 且 资源路径以“/api/finance”开头 且 信任等级为“高”，该规则的动作是准许。

策略考量的流程具有关键意义，系统收到访问请求之后，策略引擎先从数据库当中调取那些处于激活状态的策略，接着按照优先级从高到低来执行排序操作。引擎依照顺序去遍历这些策略，针对每一条策略而言，它会逐一浏览其内部包含的所有规则，查看当前访问请求的相关背景信息能否完全符合某条规则所规定的条件，只要发现了相符的规则，引擎就会马上实施这条规则指定的操作，并终止对后面所有策略及规则展开考量活动，倘若当下的策略当中没有任何一条规则能够与之对应，那么引擎将会转而去考量优先级更高的策略，直至全部被激活的策略均无法找到与之契合之处为止，此时才会采用该策略预先设定好的默认处理方式；从安全方面来说，一般我们会把这种情况下的默认操作设为“予以阻止”，这样一种明了又具备稳定性的考量过程能够保障访问控制决策既可靠又统一。

5系统实现

5.1 开发环境

为使开发过程具备高效性，规范性并保证团队成员意见统一，我们创建起一套统一的开发环境，在操作系统的层面上，大部分开发工作都在 Windows 平台完成，代码还经由在 Linux 和 macOS 上的交叉验证，从而保障良好的跨平台适应能力，就开发工具而言，后端开发采用的是行业主流产品 IntelliJ IDEA ，此工具具有很强的代码提示，重构以及调试功能，极大地优化了 Java 的开发效率；前端开发选用轻巧却功能强劲的 Visual Studio Code，并加上 Vue 专用插件，这样就给 Vue 3 和 TypeScript 的开发带来了出色助力。

在选择核心技术栈的版本时，我们坚持“稳定优先”原则，后端采用Java 8作为运行环境，这是一个长期支持版本，具备很高的稳定性，而且得到广泛社区支持。创建工具用的是Maven 3. 8，经由pom. xml文件来统一管理全部后端依赖项，前端采用Node. js 18. x作运行环境，并把npm当做一个包管理器，从数据库来说，我们选择了MySQL 8. 0，此版本包含像 JSON字段支持这样的新特性，其性能与安全性能均有所明显改善，项目当中各种开发环境的设置，从IDE的代码样式，Maven的settings. xml一直到Node. js的版本等等，全都以文档的形式存入项目仓库之中，如此一来便能保证各个开发者能够立即营造出相同配置的开发环境，进而削减由于环境差别而产生的各类问题，促使项目进度得以有序推进下去。

5.2 后端实现

后端严格按照分层架构及“控制反转”设计原则来执行，其项目结构较为清晰，大致可分成控制器层，服务层，数据访问层以及实体层，控制器层需接住前端发来的 HTTP 请求，先做些基本的参数校验，然后再去唤起服务层的接口，此层务必要做到“轻薄化”，也就是仅仅承担协议和路由方面的处理任务，万不可掺杂任何业务逻辑，服务层属于整个后端的关键部分，这里面蕴含了用户管理，设备管理，策略管理以及可信度评定等所有的业务逻辑，该层会制订出用例的执行步骤，并安排众多数据访问层组件一起协同完成复杂的业务事务。

在安全方面，我们依托Spring Security达成了JWT认证过滤器，该过滤器会拦截绝大部分API请求，从HTTP头里获取JWT令牌，接着校验其签名与有效期。校验完毕之后，它会从令牌当中解构出用户信息，然后把一个经过认证的Authentication对象存储到SecurityContext里面，如此一来，后面的业务逻辑就可以轻松得到当前的用户信息。

代码下面显示的是JWT令牌的生成流程，在用户登录认证完成之后，系统会调用此方法来生成访问令牌，该方法把用户名当作主题，而且把设备ID以及即时计算得出的信任分数这些自定义声明存储到令牌载荷当中，经由设定恰当的过期时限，既可以保障会话具备时效性，又能防止因长期有效的令牌而产生的安全风险，令牌生成完毕之后还要用密钥执行签名操作，以此保证它在传送过程中不会遭到篡改。

 图5-1 JWT Token生成

该过滤器是Spring Security框架的核心组件，用于拦截每个API请求并提取JWT令牌进行验证。过滤器首先从HTTP请求头的Authorization字段中获取令牌，验证其签名有效性和是否过期。验证通过后，从令牌中解析出用户信息，并创建认证对象存入安全上下文，使得后续的业务处理流程能够直接获取当前认证用户的信息，实现了无状态的认证机制。

 图5-2 JWT认证过滤器

该配置类定义了系统的安全策略。通过禁用CSRF保护以适配前后端分离架构，配置了各类API接口的访问权限规则，例如认证相关的接口允许所有用户访问，而用户管理接口仅限管理员角色。同时将会话管理策略设置为无状态，这与JWT的无状态认证机制相契合。最后将自定义的JWT认证过滤器添加到Spring Security的过滤器链中，确保在每个请求到达业务控制器之前都经过身份验证。

 图5-3 Spring Security配置

信任评估引擎和策略引擎作为两个核心服务被独立实现。信任评估引擎在每次请求时都会被调用，它从多个服务获取最新的用户、设备、行为等上下文信息，然后执行预设的加权评分算法，计算出本次请求的实时信任分数。

 图5-4 信任评估引擎

该枚举类定义了系统的四个信任等级及其对应的分数区间。高信任对应80至100分，中等信任对应50至79分，低信任对应30至49分，不可信对应0至29分。通过提供静态方法fromScore，可以根据任意信任分数快速获取对应的信任等级，这种设计使得信任等级的判定逻辑集中且易于维护，便于后续根据实际需求调整分数区间划分。

 图5-5 信任等级计算

该方法根据设备的合规性检查分数自动计算其信任等级。合规分数达到80分以上为高信任设备，50至79分为中等信任，30至49分为低信任，低于30分为不可信。该逻辑在设备信息更新或周期性合规检查时被触发，实现了设备信任等级的自动化管理，确保设备信任状态能够及时反映其安全状况的变化。

 图5-6 设备信任等级自动计算

策略引擎则根据该分数和其他请求属性，按照优先级顺序匹配预设的策略规则，最终生成“允许”或“拒绝”的授权决策。整个后端的实现高度模块化，各个服务之间通过接口进行通信，使得代码易于测试和维护。

策略评估引擎是实现访问控制决策的核心组件。该方法首先从数据库加载所有启用状态的策略，并按优先级进行排序。然后遍历每个策略，对策略内的规则逐一进行条件匹配检查。一旦找到匹配的规则，立即执行该规则定义的动作并返回决策结果。如果所有策略的所有规则均未匹配，则遵循“默认拒绝”的安全原则，返回拒绝决策。这种逐级匹配的评估流程确保了访问控制决策的准确性和一致性。

 图5-7 访问策略评估

5.3 前端实现

前端实现基于Vue 3的组合式API和单文件组件，构建了一个功能完善、交互友好的单页应用。项目采用了模块化的目录结构，将API接口定义、公共组件、路由配置、状态存储和页面视图等分开管理。在路由层面，我们配置了Vue Router，实现了页面间的无刷新跳转。更重要的是，我们实现了全局前置路由守卫，这是前端安全的第一道关口。守卫会检查本地存储中是否存在JWT令牌，如果用户未登录而试图访问受保护的页面，则会将其强制重定向到登录页。

 图5-8前端路由守卫

在用户交互这个层面，我们采用了Element Plus 组件库，这个做法让我们迅速创建起布局，表单，表格，弹窗之类的界面元素，从而保障了 UI 的一致性与专业性，在状态经营这块，我们挑选了 Pinia，它把用户信息，JWT 令牌等全局状态归集起来储存起来，免除开各个组件经由繁杂的事件链来传递数据。比如用户登录完毕之后，前端就会调用登录 API，把得到的令牌存放到本地存储里面，而且还要把用户信息存入到 Pinia store 里面，这样以后不论哪个组件想要获取有关用户信息的时候，都会十分便捷，至于 API 交互这一块儿，我们对 Axios HTTP 客户端执行了封装，利用请求拦截器，我们可以给每条送出的请求自动加上 JWT 令牌到 Authorization 头部当中。 经由响应拦截器，我们统一去处理后端反馈的错误码，要是收到 401 未授权状态码，那么就会自动清除本地存储里的令牌，并跳转到登录页面，这样做以后，业务组件里的代码就变得更为纯粹，只需关注数据展示和用户交互即可。

图5-9 Axios请求拦截器

5.3.1 仪表盘模块实现

仪表盘模块是用户登录之后最先看到的页面，其用来表现系统的总体安全状况，此模块重点包含系统概览统计卡片，上面显示总用户数，总设备数，当日访问量等重要指标。而且，利用ECharts图表库去绘制访问趋势折线图，清晰地表现出近7天或者30天访问请求的变动趋势，从而协助管理员辨别业务高峰期或者潜在的破坏行为，信任等级分布饼图则显示出当下所有设备的信任等级所占比例的情况，使得管理员可以立即知晓企业整体的设备安全基准水平。

图5-11 系统仪表盘界面

上图展示了系统仪表盘的主要界面。从图中可以看到，页面顶部展示了核心统计指标卡片，中间部分为访问趋势折线图，下方左侧为信任等级分布饼图，右侧为最近访问记录列表。这种布局使得管理员能够在一个页面上全面掌握系统的运行状态和安全态势。

5.3.2 用户管理模块实现

用户经营模块具备用户身份全生命时段的经营能力，此模块用表格形式表现全部用户的基本信息，包含用户名，邮箱，姓名，部门，状态，信任等级等等字段，经营者可经由上方的搜索框按照用户名，邮箱，状态等条件立即筛选用户，在表格每行右侧设有编辑和删除的操作按钮，便于经营者执行用户信息的维持工作，页面还供应“新增用户”的按钮，点击之后会跳出表单对话框，经营者可以填写用户信息来达成创建。

图5-12 用户管理界面

上图展示了用户管理模块的主要界面。从图中可以看到，用户列表表格清晰展示了用户的各项属性信息，顶部搜索框支持多条件组合查询，分页组件便于浏览大量用户数据。用户的状态和信任等级通过不同颜色的标签进行区分，提升了界面的可读性和用户体验。

5.3.3 设备管理模块实现

设备经营模块承担着企业终端设备的注册，监测与经营职责，此模块会显示全部已注册设备的相关信息，设备ID，设备名称，设备种类，操作系统，合规得分，信任等级以及状态等内容均包含在内，经营者能够执行对设备的编辑及删除操作，而且系统具备设备信任等级的自动计算能力，按照设备所报合规检测得分自动对其信任等级实施更新，设备状态设定为四类，即活跃，不活跃，待审核和已被禁止，并由不同色彩的标签加以区分。

图5-13 设备管理界面

上图展示了设备管理模块的主要界面。从图中可以看到，设备列表包含了设备的详细信息，合规分数和信任等级字段能够直观反映每台设备的安全状况。系统还提供了设备注册功能，管理员可以手动添加新设备或通过终端自动注册，注册时需填写设备的基本信息和初始合规分数。

5.3.4 策略管理模块实现

策略守护模块属于零信任架构的关键设置单元，其功能在于制定访问控制规则，此模块会以列表形式显示系统内预先设定的所有访问策略，其中涵盖策略名称，优先层级，预设动作，启停状态等相关信息。管理员能够制定新的策略，而且每条策略可包含诸多规则，规则条件具备用户属性，设备属性，资源属性以及时间条件等各类合成形式，策略的优先层级影响着考量的先后顺序，数值越小，则优先层级越高，管理员可随时启动或关闭这些策略，不必经由删除操作即可使之生效。

图5-14 策略管理界面

上图显示了策略运作模块的主要界面，由图可知，策略列表按照优先级顺序展示出来，各条策略的默认动作以及启用状态十分直观。当点击策略名称的时候，可以扩展显示此策略所包含的详细规则，并且支持针对规则执行增，删，改等操作，如此一来，管理者便能较为灵活地设置较为细致的访问控制策略。

5.3.5 访问日志模块实现

访问日志模块负责记录并查询针对系统资源的所有访问行为，其为安全审核及事后追溯提供重要依照，此模块包含每次访问的时间戳，用户名，设备ID，操作类型，访问资源，决策结果以及信任分数等关键信息，经营人员可凭借多种条件的关联执行日志搜索，按照用户名，设备，时间区间，访问结果等来筛选日志条目，而且，日志数据具备导出能力，利于执行离线分析或者安全合规检查。

图5-15 访问日志界面

上图表现了访问日志模块的主要界面，从图里可看出，日志表格按照时间倒序来排版，最新访问记录位于前面。每条记录包含完整的访问上下文信息，决策结果列用“允许”或者“拒绝”的标签直观表现访问是否得到授权，信任分数列显示此次访问时的信任分数，利于分析访问决策和信任分数之间的联系。

5.3.6 信任评估模块实现

信任考量模块属于零信任架构的关键核心部分，其职责在于显现用户及设备的信任度评定情况，此模块可全方位展示信任分数，涉及身份信任分，设备信任分，行为信任分，上下文信任分，还有综合信任分及其对应等级，管理员能够查看某位特定用户或者设备过往的信任度评定状况，并知晓信任分处于何种动态走向，一旦信任等级出现变动，系统便会自动生成改动日志，如此一来就方便探寻导致信任状态产生变化的根源所在。

图5-16 信任评估界面

上图表现了信任考量模块的关键界面，由图可知，该页面以仪表盘样式显 示着四个维度的信任分数及其所占权重，综合信任分数用大号字体着重显示出来，而且用不同颜色标注对应的信任等级，下方列出了信任分数的详细计算依照，包含各评定指标的得分状况，这样管理员就能明晰掌握信任分数的合成及其变化缘由。

5.4 关键技术实现

系统的达成需把握几个关键技术点，这些点关乎系统的核心能力，其一为动态信任评价引擎的达成情况，该引擎非单纯执行加权求和即可，它要能即时从诸多异构的数据源获取数据。譬如说计算设备的信任分数时，此引擎不但得向设备表询问以得到合规分数，而且也许还要经由调用操作系统接口来得知终端当前的安全状况，为提升考量效率，我们针对考量指标执行了分级处理，那些变化较慢的指标预先加载到缓存当中，而动态指标则于运行时加以计算，如此一来既能确保准确无误又做到了性能上的改善。

策略引擎的规则符合达成需借助一种高效模式符合算法来分析并执行策略规则，每条规则视为一棵表达式树，其叶节点为原子条件，非叶节点是逻辑运算符。遇评价请求时，引擎会游览该表达式树，针对每个原子条件加以求值，再遵照逻辑运算符得出整个表达式的布尔结果，要加快符合速度，可将所有启用的策略提前加载进内存，并按优先级排列合成一条规则链，除非规则链里的策略或者规则有所改变，否则无需再次加载与编译规则链，此类内存化策略大幅优化了策略考量的吞吐量。

设备信任等级的自动计算属于该应用的一个亮点之处，我们达成了一个异步任务，此任务定时执行或者在设备状态发生改变的时候启动，按照从设备获取的各种合规性核查指标来做综合评分。这个任务依照事先设置好的映射规则，自主更新数据库里该设备的信任等级信息，这个过程不会让用户察觉，不过设备信任等级一旦有所变动，就会即刻影响到下次访问请求时的综合信任度分数以及相关的策略判断，进而达成了针对设备安全状况改变的快速应对。

图5-17 仪表盘信任分布图表