Zero trust based access risk assessment method

Abstract

The application discloses a zero-trust-based access risk assessment method and belongs to the technical field of Internet information security management and access control. In order to solve the problems of scattered access behavior sources, difficulty of static permission rules in reflecting abnormal login, over-authorization calling and session hijacking risks in time, a heterogeneous time sequence access graph is constructed, behavior deviation vectors and relationship risk vectors are extracted, and permission, resource, terminal and token states are fused to output risk values, risk levels and risk evidence chains, so that continuous access risk assessment and dynamic control are realized.

Description

Technical Field

[0001] This invention relates to the field of Internet information security management and access control technology, and in particular to a zero-trust-based access risk assessment method. Background Technology

[0002] With the application of zero-trust security architecture in internet information security management scenarios, systems such as identity authentication, endpoint management, API gateways, business systems, session management, and security logs continuously generate access-related data. Existing access control methods typically rely on static rules such as account roles, interface permissions, and resource policies to determine whether a user is qualified to access the system, and in some scenarios, they combine login location, endpoint status, or security logs for auxiliary verification.

[0003] However, the sources of access behavior from users, terminals, interfaces and business systems are scattered, and there is a lack of continuous correlation between security logs and identity status, terminal status and session status. Traditional static permission rules are unable to reflect dynamic risks such as abnormal logins, unauthorized calls and session hijacking in a timely manner. At the same time, a single log or a single permission matching result is difficult to explain the risk transmission relationship across entities and across time, which makes risk assessment easy to lag and affect the access security of core data and business systems.

[0004] Therefore, a zero-trust-based access risk assessment method is needed to address the shortcomings of existing technologies. Summary of the Invention

[0005] One objective of this invention is to propose a zero-trust-based access risk assessment method. Addressing the problems in existing technologies such as scattered access data sources, the inability of static permission rules to promptly reflect risks like abnormal logins, unauthorized calls, and session hijacking, and the lack of continuous correlation between security logs and identity status, this invention proposes a technical solution: collecting multi-source access data and standardizing it into access event units; constructing heterogeneous temporal access graphs and session evidence subgraphs; extracting behavioral deviation vectors and relational risk vectors; and fusing permission resource terminal tokens and abnormal evidence to output control instructions according to risk. This invention has the technical effect of improving the ability to continuously assess access risks, identify anomalies, and dynamically handle them.

[0006] This invention provides a zero-trust-based access risk assessment method, comprising: S1, collecting access data from an identity authentication system, terminal management system, application interface gateway, business system, session management system, and security log system, and obtaining access event units through field mapping, time alignment, and entity identifier normalization; S2, constructing a heterogeneous temporal access graph based on the access event units, extracting a session evidence subgraph centered on the active session, the session evidence subgraph containing session nodes and connected users, terminals, tokens, interfaces, business systems, and resource nodes, and determining edge weights according to edge type, time decay coefficient, resource sensitivity level, terminal security status, and authentication method level; S3, inputting the user access sequence into a self-monitoring system. The behavior sequence model obtains the behavior deviation vector, and the session evidence subgraph is input into the time sequence graph attention model to obtain the relationship risk vector. An abnormal evidence set is generated according to token consistency, terminal status, network location, role permissions, and access sequence baseline. S4: The static permission matching result, resource sensitivity level, terminal security status, token consistency result, behavior deviation vector, relationship risk vector, and abnormal evidence set are fused to obtain the access risk value, and group conformal calibration is performed to obtain the risk level, risk upper bound, uncertainty level, and risk evidence chain. S5: Access control instructions are generated and executed according to the risk level, risk upper bound, and uncertainty level, and the handling results are written to the user, terminal, and session history state.

[0007] Optionally, S1 includes:

[0008] A unified event field is established for the access data. The unified event field includes user identifier, terminal identifier, session identifier, token identifier, interface identifier, business system identifier, resource identifier, access time, network location, authentication method, request action, and processing tag.

[0009] Convert timestamps from different data sources to the same time base;

[0010] Eliminate the differences in multi-source identifiers for the same entity based on the account mapping table, terminal certificate, and session identifier table;

[0011] Missing fields are marked with missing tags and the data source identifier is retained to form the access event unit.

[0012] Optionally, S2 includes:

[0013] The user, terminal, session, token, interface, business system and resource in the access event unit are respectively regarded as nodes, and the authentication, holding, calling, accessing, ownership and disposal relationships are regarded as directed edges;

[0014] Write timestamps according to access time and form the heterogeneous time-series access graph;

[0015] The session evidence subgraph is formed by retrieving adjacent nodes and edges within the same session window using the session identifier of the active session.

[0016] The edge weights are obtained by normalizing and weighting the edge type baseline weight, time decay coefficient, resource sensitivity level corresponding weight, terminal security status corresponding weight, and authentication method level corresponding weight.

[0017] Optionally, S3 includes:

[0018] The access event units are sorted according to user identifier and access time, and encoded to obtain a user access sequence;

[0019] The self-supervised behavior sequence model outputs the deviation component between the current access segment and the user's historical access baseline, and concatenates each deviation component into the behavior deviation vector.

[0020] The attention coefficients of adjacent entities are calculated by the temporal graph attention model based on node type, edge type, edge weight, and edge timestamp, and then aggregated to obtain the relationship risk vector;

[0021] The behavioral deviation vector and the relationship risk vector are used as inputs to generate the abnormal evidence set;

[0022] Furthermore, the self-supervised behavior sequence model is trained in the following way: user access sequence samples are constructed from historical access event units, and event masking, adjacent event order prediction and in-session next action prediction are performed on the user access sequence samples to form a self-supervised training task.

[0023] Using event field embedding, time interval embedding, and resource sensitivity level embedding as input, and the weighted sum of mask event reconstruction error, sequence prediction error, and next action prediction error as training loss, model parameters for outputting the behavior deviation vector are obtained.

[0024] Furthermore, the abnormal evidence set is generated in the following way: by comparing the current terminal proof with the terminal proofs already registered in the same session window, terminal change evidence is generated;

[0025] The current network location is compared with the set of adjacent location transitions in the historical location sequence to generate evidence of network location jumps.

[0026] Compare the token fingerprint with the terminal proof binding table to generate token-terminal inconsistency evidence;

[0027] Compare role permission levels with interface sensitivity levels to generate evidence of unauthorized calls;

[0028] The current access sequence segment is compared with the user's historical access baseline to generate sequence deviation evidence;

[0029] The abnormal evidence set is input into the risk fusion function and written into the risk evidence chain.

[0030] Optionally, S4 includes:

[0031] The static permission matching result is obtained by matching the role permission table, interface access policy, and resource access policy.

[0032] The static permission matching result, resource sensitivity level, terminal security status, token consistency result, behavior deviation vector, relationship risk vector and abnormal evidence set are input into the risk fusion function. The risk fusion function outputs the access risk value using preset feature weights and evidence missing mask.

[0033] The calibration groups are divided according to user roles, interface types and resource sensitivity levels. The group conformal calibration is performed on the access risk value to obtain the risk level, the risk upper bound, the uncertainty level and the risk evidence chain.

[0034] Furthermore, the group conformal calibration includes: within each calibration group, using the absolute value of the difference between the risk label of a historically labeled access sample and the corresponding access risk value as the non-compliance score;

[0035] The calibration quantile value is determined from the distribution of the non-compliant scores according to the preset target coverage.

[0036] The sum of the current access risk value and the calibration quantile value is truncated to a preset risk value range to obtain the upper bound of the risk.

[0037] The uncertainty level is determined based on the comparison results between the calibration quantile value and the preset first uncertainty threshold and the preset second uncertainty threshold, and the uncertainty level is used as the input of the control mapping table.

[0038] Optionally, S5 includes:

[0039] Input the risk level, the risk upper bound, and the uncertainty level into the control mapping table;

[0040] A release instruction is generated when the risk level does not reach the preset authentication threshold.

[0041] An enhanced authentication instruction is generated when the risk level reaches a preset authentication threshold but does not reach a preset downgrade threshold.

[0042] When the risk level reaches a preset downgrade threshold but does not reach a preset termination threshold, a permission reduction instruction or a resource restriction instruction is generated.

[0043] A session termination instruction is generated when the risk level reaches a preset termination threshold but does not reach a preset blocking threshold.

[0044] When the risk level reaches a preset blocking threshold, an access blocking instruction is generated.

[0045] Furthermore, the processing results include control instruction type, execution time, execution object, authentication result, permission change result, resource access result, and session termination result;

[0046] The processing results are appended to the user's historical state, terminal's historical state, and session's historical state, respectively, and a state version number is written to the appended historical state.

[0047] When generating a new access event unit, the historical state corresponding to the state version number is read, so that the previous handling result can be used in the next access risk assessment.

[0048] The beneficial effects of this invention are:

[0049] 1. By unifying the access data of the identity authentication system, terminal management system, application interface gateway, business system, session management system and security log system into access event units, and constructing a heterogeneous time-series access graph that includes users, terminals, sessions, tokens, interfaces, business systems and resources, it is possible to continuously associate dispersed access behaviors with identity, terminal and session status, and reduce the judgment lag caused by relying solely on static permission rules.

[0050] 2. By outputting a behavior deviation vector through a self-supervised behavior sequence model and a relationship risk vector through a time sequence graph attention model, and combining token consistency, terminal status, network location, role permissions, and access sequence baseline to generate an abnormal evidence set, it can simultaneously characterize user behavior deviation and cross-entity relationship anomalies, making risks such as abnormal login, unauthorized calls, and session hijacking have a traceable risk evidence chain.

[0051] 3. By performing conformal calibration on access risk values ​​grouped according to user roles, interface types, and resource sensitivity levels, the upper bound of risk and uncertainty level are obtained. These are then input into the control mapping table to generate instructions for granting access, enhancing authentication, narrowing permissions, restricting resources, terminating sessions, or blocking access. This enables access control results to be dynamically adjusted according to the risk status, and the feedback of handling results supports continuous assessment of subsequent access risks. Attached Figure Description

[0052] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0053] Figure 1 This is a flowchart of a zero-trust-based access risk assessment method.

[0054] Figure 2 This is a flowchart of step S3 of the present invention, which involves extracting risk vectors using a dual-model approach and generating anomaly evidence sets using a diamond-shaped approach. Detailed Implementation

[0055] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0056] refer to Figures 1-2 The zero-trust-based access risk assessment method includes: S1, collecting access data from the identity authentication system, terminal management system, application interface gateway, business system, session management system, and security log system, and obtaining access event units through field mapping, time alignment, and entity identifier normalization; S2, constructing a heterogeneous temporal access graph based on access event units, extracting a session evidence subgraph centered on the active session, the session evidence subgraph containing session nodes and their connected users, terminals, tokens, interfaces, business systems, and resource nodes, and determining edge weights according to edge type, time decay coefficient, resource sensitivity level, terminal security status, and authentication method level; S3, inputting user access sequences into self-supervised behavior. The sequence model obtains the behavior deviation vector, and the session evidence subgraph is input into the time sequence graph attention model to obtain the relationship risk vector. An abnormal evidence set is generated according to token consistency, terminal status, network location, role permissions, and access sequence baseline. S4: The static permission matching result, resource sensitivity level, terminal security status, token consistency result, behavior deviation vector, relationship risk vector, and abnormal evidence set are fused to obtain the access risk value, and group conformal calibration is performed to obtain the risk level, risk upper bound, uncertainty level, and risk evidence chain. S5: Access control instructions are generated and executed according to the risk level, risk upper bound, and uncertainty level, and the handling results are written to the user, terminal, and session history state.

[0057] In this specific embodiment, S1 includes:

[0058] The access risk assessment server establishes an access event collection channel on the enterprise zero-trust gateway side. It reads raw access records from the identity authentication system, terminal management system, application interface gateway, business system, session management system, and security log system. After the raw records enter the source buffer, the collection batch number, data source identifier, and reception time are written into them. The server maps the accounts, device certificates, session numbers, token digests, interface paths, business system numbers, resource numbers, access times, network locations, authentication methods, request actions, and log handling tags of different systems to a unified event field according to the source field mapping table. The log handling tag corresponds to the handling tag generated by the access data source. The source field mapping table stores the original field name, unified field name, data type, required field flag, parsing rules, source priority, and table version. The table version is incremented by the security operation and maintenance platform when the policy is released and is written into the access event unit with the collection batch.

[0059] The access risk assessment server generates an event receiving key for each original access record. The event receiving key consists of a data source identifier, an original primary key, and an original time summary. Type validation is performed according to the data type in the field mapping table. Account-type fields retain a two-level structure of tenant identifier and user identifier. Terminal-type fields retain the certificate serial number, device management number, and device fingerprint. Interface-type fields retain the request method and interface identifier. Resource-type fields retain the resource identifier and resource sensitivity level index. For missing fields, the record is not deleted, but a missing flag, missing field name, and source identifier are written, so that the subsequent risk fusion function can use the evidence missing mask to distinguish between true low risk and data unavailable data.

[0060] The access risk assessment server aligns access times according to a unified time base. Before deployment, the clock synchronization service writes a source clock offset table for each data source, and during runtime, it follows the formula. Calculate the alignment time, where For the first The source system time of the original record. For data source Offset in the source clock offset table, For the alignment time of the write access event unit, if the offset of the same source exceeds three seconds and is not recovered within two synchronization cycles, the source record retains the original time and writes a time low confidence mark. The time decay calculation of subsequent graph edges reads this mark and reduces the time confidence of the source edge.

[0061] When accessing the risk assessment server to convert timestamps from different data sources to the same time base, it first identifies the time zone, millisecond precision, log write latency, and gateway reception latency of the source timestamp. Then, it generates alignment time and alignment confidence based on the source clock offset table. The alignment confidence is calculated using the formula... Calculation, where This is the average offset within the most recent synchronization window of the data source. This refers to the maximum allowable offset in the time alignment parameter table. Write a low-trust time marker and retain the source timestamp when the time alignment threshold is below.

[0062] During the entity normalization phase, the access risk assessment server reads the account mapping table, terminal certificate table, and session identifier table. The records in the account mapping table include tenant identifier, account alias, unified user identifier, effective time, and revocation time. The records in the terminal certificate table include certificate serial number, device management number, device fingerprint, terminal security status, and certificate validity period. The records in the session identifier table include session identifier, user identifier, terminal identifier, token identifier, first authentication time, and most recent activity time. The server replaces the differences in multi-source identifiers with unified user identifier, unified terminal identifier, and unified session identifier, and retains the original identifier list for risk evidence chain backtracking.

[0063] When multiple candidate records exist in the account mapping table, terminal certificate table, or session identifier table, the access risk assessment server performs arbitration in the following order: effective time overriding access time, certificate not revoked, and the smallest difference between the session's most recent activity time and the alignment time. The arbitration score is calculated using the formula... Calculation, where This represents the hit value of the candidate record's validity period. This indicates the closeness of the time difference after normalization. Represents the historical homology hit value, weight. , and From the entity arbitration parameter table and sum to one. The larger the value, the more credible the candidate. When the highest score is lower than the entity arbitration threshold, the entity is not merged and is marked as pending review.

[0064] The access risk assessment server performs deduplication on duplicate records under the same event receiving key. The deduplication rule is to retain the record with the highest source priority and the greatest field completeness. Field completeness is calculated by dividing the number of filled uniform event fields by the total number of uniform event fields. When the log handling label comes from the security log system, it overrides the default handling status of the business system. The override action is written to the field source list. Therefore, the access event unit retains the uniform field value, field source, missing flag, time low trust flag and normalized entity identifier at the same time to avoid subsequent steps using the merged fields when the source cannot be traced.

[0065] The access risk assessment server performs consistency cleaning on records after field mapping, time alignment, and entity identifier normalization. The cleaning rules include prohibiting merging to existing user nodes when the unified user identifier is empty; generating temporary session identifiers using token identifiers, terminal fingerprints, first event time buckets, interface request chain digests, and source system random salts when the unified session identifier is empty; writing time reverse order markers when the access time is earlier than the token issuance time; and when the business system's handling status conflicts with the security log system's log handling label, the security log system's log handling label takes precedence and the business system's handling status is written into the alternative field. The field source list records the business system's handling status field name and the security log system's log handling label field name, respectively. All cleaning results are written into the event cleaning field and S2 and S3 are used as candidate sources of abnormal evidence.

[0066] Temporary session identifier according to formula Generate, where For token identifier digest, For terminal fingerprint digest, The first event time bucket, This is a summary of the API request chain. The source system is a random salt digest, and the time bucket is set to five minutes in this specific implementation. When the subsequent session management system provides a real unified session identifier, the access risk assessment server writes the real unified session identifier, temporary session identifier, merging time and merging source into the temporary session mapping table, and migrates the temporary session node and its edges in S2 to the real session node, while retaining the temporary session identifier as an alias to support risk evidence chain backtracking.

[0067] The access risk assessment server writes access event units into the event unit table and the streaming message queue. The primary key of the event unit table is the unified session identifier, alignment time, and event receiving key. The index fields include the unified user identifier, unified terminal identifier, unified token identifier, interface identifier, business system identifier, resource identifier, network location, authentication method, and request action. The message queue is partitioned according to the unified session identifier, which is used by S2 to build a heterogeneous time-series access graph and by S3 to form a user access sequence.

[0068] When generating a new access event unit, the access risk assessment server reads the most recent risk control action result corresponding to the current state version number from the user historical state, terminal historical state, and session historical state written by S5, and writes the previous control instruction type, authentication result, permission change result, resource access result, and session end result into the historical risk control action field of the access event unit. The historical risk control action field comes from the control execution result backfilled by S5 rather than the log action label. This access event unit serves as the common input for S2 graph construction and S3 behavior deviation calculation.

[0069] In this specific embodiment, S2 includes:

[0070] The graph maintenance module takes the access event unit table written by S1 and the same partition message queue as input. It creates nodes for users, terminals, sessions, tokens, interfaces, business systems and resources in the graph database. The node record includes node type, unified entity identifier, source identifier set, first appearance time, last update time, status version number and node attribute summary. Among them, terminal nodes read terminal security status, resource nodes read resource sensitivity level, interface nodes read interface sensitivity level, token nodes read token issuance time and binding terminal proof. The node primary key is composed of node type and unified entity identifier.

[0071] The graph maintenance module generates directed edges based on the authentication method, token holding relationship, interface call relationship, resource access relationship, business system affiliation relationship, and risk control processing result in the access event unit. The edge record includes the starting node, ending node, edge type, alignment time, unified session identifier, request action, log processing label, source batch number, missing field mask, and edge status. Authentication edges include user authentication session edges and session source terminal edges. User authentication session edges connect user nodes and session nodes, and session source terminal edges connect session nodes and terminal nodes. Holding edges include terminal holding token edges and session using token edges. Terminal holding token edges connect terminal nodes and token nodes, and session using token edges connect session nodes and token nodes. Call edges connect session nodes and interface nodes. Access edges connect interface nodes and resource nodes. Affiliation edges connect interface nodes and business system nodes. Processing edges are directed edges that start from a session node and end at a user node, terminal node, session node, interface node, or resource node selected according to the execution object type of the risk control processing result. The corresponding risk control processing result is recorded in the edge attributes.

[0072] The generation sources of the session source terminal edge are the terminal identifier in the session identifier table, the terminal proof in the application interface gateway log, and the authentication terminal record in the identity authentication system. The generation sources of the session token edge are the token identifier in the session identifier table, the token issuance record in the authentication system, and the token digest in the gateway log. The timestamps of the two types of session binding edges preferentially adopt the aligned time of the access event unit. When the authentication system only provides the issuance time, the issuance time is used and the source timestamp is written. When there is a time difference between the gateway log and the session identifier table, a reliable time is selected according to the time alignment confidence of S1, and an alternative time is reserved.

[0073] The handling edge does not add new node types. Its starting point is the session node, and the ending point is selected according to the execution object of the risk control handling result: user node, terminal node, session node, interface node, or resource node. Enhanced authentication, user blocking, and account-level permission adjustment point to the user node, terminal isolation or terminal status restriction point to the terminal node, session termination instruction forms a self-loop handling edge of the session node, interface permission reduction points to the interface node, and resource restriction instruction points to the resource node. The edge attributes include control execution result identifier, control instruction type, execution object, execution time, execution status, failure reason, and status version number. The log handling tag generated by the security log system is only used as the access event unit field and handling edge attribute. The risk control handling result backfilled by S5 is used as the source for updating the handling edge attribute and session node attribute summary. The handling edge indicates that the session triggered the corresponding control action on the existing user, terminal, session, interface, or resource object.

[0074] The graph maintenance module writes a timestamp for each edge and maintains an edge window index. The edge window index uses a unified session identifier and alignment time as a joint key. The current active session is at the evaluation time. The evidence window is set to ,in For the initial authentication time, the inner borders of the window are sorted in ascending order by alignment time; for arrival times later than [time value missing], [the window will be filled in]. However, for late events whose edge timestamps fall within this closed interval, the graph maintenance module sets a five-minute late event compensation window. If the lateness incident is If the arrival occurs before the session evidence subgraph is filled, S4 will be triggered to generate a revised version of the corresponding risk result;

[0075] The graph maintenance module calculates edge weights based on edge type baseline weights, time decay coefficients, resource sensitivity level corresponding weights, terminal security status corresponding weights, and authentication method level corresponding weights. The time decay coefficient is calculated using the formula... Calculation, where The time difference in seconds between the current evaluation time and the edge timestamp. The decay time constant is in the graph weight parameter table, and the edge weights are calculated according to the formula. Write the edge record, where As the baseline weight for edge type, The weights corresponding to resource sensitivity levels The weights corresponding to the terminal's security status. The weights corresponding to the authentication method levels to These are the normalized weighted coefficients;

[0076] The baseline for edge weight normalization is uniformly provided by the graph weight parameter table. The baseline weight for edge type, the weight corresponding to resource sensitivity level, the weight corresponding to terminal security status, and the weight corresponding to authentication method level are all pre-mapped to a dimensionless risk contribution range of zero to one, with a time decay coefficient. It also falls within the zero to one range; during calculation, the sum of all weighted components is divided by the denominator. The denominator is the sum of the weight coefficients under the same parameter version, and the final result is... Even after truncation, the value remains between zero and one; the higher the value, the higher the risk propagation contribution of that edge in the session evidence subgraph.

[0077] The graph weight parameter table is published by the security policy management module and stored in the graph database configuration area. The table records include edge type, authentication method level, terminal security status, resource sensitivity level, corresponding weight, effective time, weight version and update trigger conditions. In this specific implementation, the weight corresponding to interactive strong authentication is set to 0.2, the weight corresponding to long-term token authentication is set to 0.8, the weight corresponding to managed and compliant terminals is set to 0.1, and the weight corresponding to unmanaged terminals is set to 0.9. The larger the weight, the greater the contribution of the edge to risk propagation.

[0078] When the access event unit is missing the resource sensitivity level, terminal security status, or authentication method level, the graph maintenance module reads the default value from the resource policy table, the terminal management default status table, and the authentication method level table, and writes the default source into the edge default tag. If the default value is still not hit, the corresponding component is set to the risk conservative value and written into the reason for the miss. The edge weight calculation result is still entered into the session evidence subgraph, but the S4 risk fusion function increases the uncertainty input synchronously after reading the default tag.

[0079] The graph maintenance module retrieves the edge window index using the unified session identifier of the active session, extracting users, terminals, tokens, interfaces, business systems, and resource nodes that are directly connected to the session node by one hop. Among them, terminal nodes are directly connected by the terminal edge from the session source, token nodes are directly connected by the token edge used by the session, and interface nodes are directly connected by the calling edge. Business systems and resource nodes are included in the subgraph through the ownership edge and access edge within the same session window, and the authentication, holding, calling, access, ownership, and disposal relationships with these nodes within the same session window are retained to form a session evidence subgraph. The subgraph records include the subgraph identifier, central session identifier, node list, edge list, edge weight list, window start and end time, missing field mask summary, and graph weight version.

[0080] When extracting session evidence subgraphs, the graph maintenance module uses a subgraph matching threshold to control cross-session expansion. Candidate edges must simultaneously meet the following conditions: identical unified session identifier, edge timestamp falling within the session evidence window, and edge weight not lower than the subgraph retention threshold. The subgraph retention threshold is retrieved from the graph weight parameter table according to resource sensitivity level and interface type. In this specific implementation, the threshold for ordinary resources is set to 0.15, and the threshold for high-sensitivity resources is set to 0.05. When a candidate edge is below the threshold but carries a token conflict, authentication chain break, or resource level incomplete flag, the edge is still retained and the threshold exemption reason is written.

[0081] The graph maintenance module performs consistency pruning on the session evidence subgraph. If the same token connects to multiple terminals in the same window and the terminal proofs are different, all holding edges are retained and a token conflict flag is written. If the interface call edge does not have a traceable authentication edge, the call edge is retained and an authentication chain break flag is written. If the sensitivity level of a resource node is missing, the resource node is retained and a resource level to be completed flag is written. These flags do not give risk conclusions in advance but serve as inputs for S3 abnormal evidence generation and S4 risk evidence chain.

[0082] The graph maintenance module incrementally writes the heterogeneous temporal access graph into the graph database and writes the session evidence subgraph into the session graph cache. The cache key is the central session identifier and the evaluation time. The cached content is also sent to the temporal graph attention model of S3. The sequential record of the access event unit is still read by S3 according to the user identifier and access time.

[0083] In this specific embodiment, S3 includes:

[0084] The behavior analysis module reads the access event units output by S1 and the session evidence subgraph output by S2, sorts the access event units according to the unified user identifier and alignment time, and forms a user access sequence. The sequence elements include interface identifier, business system identifier, resource identifier, access time interval, network location, authentication method, request action, resource sensitivity level, terminal security status, log processing label and historical risk control processing field. The time interval is obtained from the alignment time difference of adjacent events and truncated to the six-hour upper limit set in this specific implementation. Events exceeding the upper limit are used as the starting point of a new segment.

[0085] The behavior analysis module encodes user access sequences as a sum of event field embeddings, time interval embeddings, and resource sensitivity level embeddings. The event field embedding is obtained by adding the interface identifier embedding, business system identifier embedding, resource identifier embedding, authentication method embedding, request action embedding, network location embedding, terminal security status embedding, log processing tag embedding, and historical risk control processing field embedding and then linearly projecting them. The time interval is normalized to zero to one with a six-hour upper limit and obtained by looking up a table. The token issuance duration, risk component, and other continuous features are truncated and normalized according to the fifth quantile and ninety-fifth quantile of the training set. The normalization parameters are stored in the feature parameter table of the model release package.

[0086] In this specific implementation, the self-supervised behavioral sequence model employs a two-layer sequence encoder with a hidden dimension of 128. Training samples are derived from historical access event units from the past 90 days. During the training phase, interface identifiers, business system identifiers, resource identifiers, authentication methods, request actions, network locations, and resource sensitivity levels are used to perform event masking, adjacent event sequence prediction, and prediction of the next action within a session. Log processing tags and historical risk control processing fields are not used as self-supervised prediction targets but are instead incorporated into the event field embedding as context fields during the inference phase. The training loss is calculated using the formula... Calculation, where For mask event restoration error, For sequential prediction error, The error is the prediction error for the next action. , and The training weights are given by the model training configuration table;

[0087] The self-supervised behavior sequence model reads the current access segment and the historical access baseline of the same user during inference. The historical access baseline is obtained by aggregating access segments that have been allowed within the last thirty days and have not been subsequently marked as abnormal. The model outputs the hidden vector of the current segment and the hidden vector of the baseline. The behavior deviation component is calculated according to the formula. Calculation, where For the current segment in the 1st... Encoded values ​​on each behavioral feature and The mean and standard deviation of the historical visit baseline. For the same unit's zero-prevention quantity, The larger the value, the greater the deviation of that component. The behavior deviation vector is constructed by concatenating the interface changes, time intervals, network locations, resource sensitivity levels, and request action sequences.

[0088] When the number of historical access baseline samples for a user is less than twenty segments, the behavior analysis module does not delete the current access segment. Instead, it reads the group baseline of the same role and interface type as a replacement baseline and writes the baseline source mark into the behavior deviation vector. If the group baseline is still insufficient, the components related to the baseline in the behavior deviation vector are written with a missing value of 0.5 and an evidence missing mask is set. The S4 risk fusion function reduces the weight of the corresponding component and increases the uncertainty input based on the mask.

[0089] The relationship analysis module inputs the session evidence subgraph of S2 into the time-series graph attention model. Node input features include node type embedding, node state field, resource sensitivity level, terminal security status, token issuance duration, and historical processing summary. Edge input features include edge type, edge weight, edge timestamp, and missing field mask. Attention coefficients are calculated according to the formula... Calculation, where Query vector for the central session node. The key vector of adjacent nodes For border rights, For edge time decay characteristics, the function Add nonlinear activation to the linear score determined by the model parameters. Normalize on adjacent entities within the same central session;

[0090] The time-series graph attention model is based on the formula. Aggregating adjacent entities yields a relational risk vector, where Features of adjacent nodes The weight matrix for the graph attention model. The relationship risk vector of the central session node is used. The model parameters are trained by the historical session evidence subgraph and its post-event risk labels. The training set is segmented according to time and the samples of the most recent seven days are retained as the validation set. When the risk recall rate in the validation set is lower than the release threshold, the new model version is not enabled and it is rolled back to the previous model version.

[0091] The tagging closed-loop module generates post-event risk tags from security alarm work orders, intrusion event confirmation records, manual review records, and session control execution results. The tags are aligned with the historical session evidence subgraph through a unified session identifier, user identifier, terminal identifier, and evaluation time window. In this specific implementation, the tag confirmation window is set to 72 hours after the risk assessment. When automatic alarm tags conflict with manual review tags, the manual review tags take precedence. When multiple security systems provide different levels, the tag with the highest level value is used as the training tag. Samples without confirmed tags do not enter supervised training and conformal calibration, but only participate in the training of the self-supervised behavior sequence model.

[0092] The evidence generation module takes the behavior deviation vector and relationship risk vector as input, and simultaneously reads the token consistency, terminal state, network location, role permissions, and access sequence baseline from the session evidence subgraph. The token consistency result is calculated jointly by the token fingerprint, token issuance time, binding terminal proof, session token usage edge, and session source terminal edge, using the following formula: ,in For token fingerprint hit value, The time consistency value is the time of issuance falling within the session window. To prove the consistency value for the bound terminal, , and The token consistency weights sum to one. The larger the value, the more consistent the token is with the current session;

[0093] Token consistency results As a continuous fusion feature written into the session risk feature cache, token terminal inconsistency evidence is only... When the token consistency threshold is lowered, an abnormal evidence set is generated and written. The relationship between the two is that the consistency score participates in S4 risk fusion, and the evidence items after the threshold is triggered participate in the risk evidence chain display and evidence confidence summary. When the current terminal proof is inconsistent with the terminal proof registered in the same session window, terminal change evidence is generated. When the current network location transfer does not belong to the adjacent location transfer set in the historical location sequence, network location jump evidence is generated. When the role permission level is lower than the interface sensitivity level, unauthorized call evidence is generated. When the behavior deviation vector component of the current access sequence segment exceeds the sequence deviation threshold, sequence deviation evidence is generated.

[0094] The evidence generation module writes the evidence type, trigger field, trigger rule, threshold source, current value, baseline value, evidence confidence level, related nodes, related edges, and generation time for each piece of abnormal evidence. The evidence confidence level is calculated using the formula... Calculation, where To trigger the original credibility of the rule output, As a valid mask for evidence, This indicates that both the threshold and the input field are valid. This indicates that a parameter or input is missing. For the confidence level of evidence, all three are dimensionless values ​​normalized to zero to one using the abnormal evidence threshold table. A larger value indicates more credible evidence; if the evidence threshold is not met, a parameter missing flag is written, and... Set it to zero, and write the evidence only to the Risk Evidence Chain Presentation field without including it in the Evidence Confidence Summary in S4;

[0095] The evidence generation module performs candidate transfer selection on network location jump evidence. The candidate set consists of registered location transfers adjacent to the current network location in the historical location sequence. Each candidate transfer records the starting location, target location, number of occurrences, most recent occurrence time, and role type. The matching distance is calculated according to three rules: same location category, same geographical region, and same autonomous region. The smaller the distance, the closer it is to the historical baseline. If multiple candidates have the same distance, the candidate with the largest most recent occurrence time is selected as the comparison object, and the transfer threshold of the candidate is written into the evidence record.

[0096] The evidence generation module performs conflict arbitration on the comparison results of role permissions and interface sensitivity levels. The candidate evidence set includes evidence of unauthorized calls, evidence of missing policies, and evidence of temporary authorization. The arbitration order is as follows: first, evidence of explicit policy rejection is retained; then, evidence of unauthorized calls with an interface sensitivity level higher than the role permission level is retained; finally, evidence of expired temporary authorization is retained. When two pieces of evidence have the same trigger priority, the evidence confidence level is selected. Evidence with high values ​​is added to the abnormal evidence set; if the confidence levels are the same, evidence updated with the generation time is retained and the covered evidence is added to the evidence candidate list.

[0097] The behavior analysis module performs version consistency checks on the model output. The current self-supervised behavior sequence model version, time sequence graph attention model version, and abnormal evidence threshold table version are all written to the session risk feature cache. If any model version is in a rollback state, the behavior deviation vector and relationship risk vector are still output according to the previous stable version, and model rollback evidence is added to the abnormal evidence set. The model rollback evidence does not directly increase the access risk value, but S4 participates in the control mapping through evidence missing mask and uncertainty level.

[0098] Model version rollback is controlled by the model registry. Triggering conditions include validation set risk recall rate being lower than the release threshold, inference failure rate being higher than the failure threshold for three consecutive evaluation windows, or model input field version being inconsistent with access event unit field version. Rollback parameters include the previous stable model version, the corresponding normalization parameter version, and the abnormal evidence threshold table version. When the inference failure rate is lower than the recovery threshold and validation sampling passes for two consecutive hours, the model registry is deactivated from rollback and the recovery time is written to the session risk feature cache.

[0099] The behavior analysis module writes the behavior deviation vector components of the current access segment into the vector field according to interface changes, time intervals, network locations, resource sensitivity levels, and request action order. It also writes the relationship risk vector into the vector field according to user adjacency, terminal adjacency, token adjacency, interface adjacency, resource adjacency, and disposal adjacency. The dimensions, model versions, normalization parameter versions, and low-confidence markers of the two vectors are used as inputs to the S4 risk fusion function to prevent the outputs of different version models from being mixed and calculated during the fusion stage.

[0100] The behavior analysis module writes the behavior deviation vector, relationship risk vector, abnormal evidence set, token consistency result, terminal state summary, network location transfer result, and role permission comparison result into the session risk feature cache. The cache key is the central session identifier and the evaluation time. The cached object serves as the direct input to the S4 risk fusion function. At the same time, the evidence identifier of the abnormal evidence set is passed to the S4 risk evidence chain construction process.

[0101] In this specific embodiment, S4 includes:

[0102] The risk fusion module reads the session risk feature cache written by S3, and reads the role permission table, interface access policy and resource access policy from the permission policy library. The role permission table records the role identifier, permission level, allowed interface set and validity period. The interface access policy records the interface identifier, interface sensitivity level, allowed request actions and authentication strength requirements. The resource access policy records the resource identifier, resource sensitivity level, access conditions and policy version. The risk fusion module performs matching with unified user identifier, role identifier, interface identifier, resource identifier and request action to obtain static permission matching results.

[0103] The risk fusion module generates permission differences based on role permission levels, interface sensitivity levels, resource sensitivity levels, and request actions. These permission differences are calculated using the formula... Calculation, where It is the highest numerical level among the interface sensitivity level and resource sensitivity level. User role permission levels, This represents the maximum level difference in the permission level table. The larger the value, the less likely the static permissions are to match. If any record in the role permission table, interface access policy, or resource access policy is not matched, the static permission matching result will be written as a policy missing and the value will be set to zero. Set to one;

[0104] The risk fusion module constructs a fused feature vector, which includes static permission matching results, resource sensitivity levels, terminal security status, token consistency results, behavior deviation vectors, relationship risk vectors, and a summary of evidence confidence for anomaly evidence sets. Resource sensitivity levels, terminal security status, and authentication method levels are all mapped to risk components ranging from zero to one according to corresponding parameter tables. Token consistency results... According to the formula Transformed into a token inconsistency risk component, where and All are in the range of zero to one. A higher value indicates a higher risk of token inconsistency; when token consistency results are missing or the time alignment confidence level is below the token trust threshold, the risk fusion module will... Set the token component effective mask to one, and write the token low-trust flag into the fusion feature record, so that the token low-trust case participates in the access risk value calculation with the conservative token inconsistency risk component. The behavior deviation vector and relationship risk vector are first normalized according to the validation set quantile values ​​saved when the model is released.

[0105] The risk fusion module calculates the access risk value using preset feature weights and a missing evidence mask. The risk fusion function is based on the formula... Output, where For the first Each normalized risk component includes a token inconsistency risk component. , For the first Effective mask for each component For the first The confidence level of evidence for anomalous evidence. and These are the non-negative weights in the risk weight table. For bias terms, It is a monotonic compression function. The value ranges from zero to one, and the larger the value, the higher the access risk. Static permission mismatch, resource sensitivity, terminal non-compliance, token inconsistency, behavior deviation, relationship risk and abnormal evidence in the formula are all risk penalty items rather than benefit items. The weight table is fitted by historical labeled access samples and released after security policy review.

[0106] The risk fusion module simultaneously calculates the incompleteness input when there is significant evidence deficiency. The incompleteness is calculated using the formula... Calculation, where The value ranges from zero to one, and the larger the value, the less available evidence there is. It does not directly replace access risk values, nor does it change the comparison calibrated quantile values ​​used to determine the level of uncertainty in claim 9. Instead, it is written as an evidence integrity marker and audit field in the risk evidence chain to ensure that missing fields are not misinterpreted as low-risk evidence.

[0107] The calibration module divides calibration groups according to user roles, interface types, and resource sensitivity levels. Each calibration group stores the access risk value, risk label value, sample time, policy version, and model version of historically labeled access samples. In this specific implementation, the risk label uses a binary classification value. Where zero represents a verified normal access, and one represents a verified abnormal access, representing the access risk value. The non-compliance score is calculated using the formula for the probability of an anomaly. calculate, For the non-compliance score of this sample, the calibration module determines the calibration quantile value from the distribution of non-compliance scores in the same group according to the target coverage. In this specific implementation, the target coverage rate is set at 95 percentage points;

[0108] Within each calibration group, the calibration module first removes historical samples whose policy version, model version, or risk label source is inconsistent with the current session. Then, it retains the labeled access samples from the most recent 30 days according to the sample time. If the same session has multiple log handling labels, automatic alarm labels, or manual review labels, the final risk label value is determined in the order of manual review label, intrusion event confirmation label, security alarm ticket label, and log handling label. The calibration group records and saves user roles, interface types, resource sensitivity levels, number of samples, sample time range, policy version, model version, and calibration group status. Unlabeled samples are not included in the non-compliance score distribution of the calibration group.

[0109] When the number of historical samples in the calibration group of the currently accessed sample is less than one hundred, the calibration module merges adjacent role groups according to interface type and resource sensitivity level. If the number of samples after merging is still less than one hundred, the global calibration group is read and a substitute calibration group flag is written. The substitute calibration group uses the same target coverage, the same risk value range, and the non-compliance score distribution under the current policy version. When the number of historical samples in the same group reaches more than one hundred and the sample integrity check is met for a consecutive calibration update cycle, the calibration module reuses the original calibration group and calibrates the quantile values. The source, sample size, target coverage, and strategy version are all written into the risk evidence chain;

[0110] The calibration module adds the current access risk value to the calibration quantile value and then truncates it to the risk range to obtain the upper bound of the risk. The formula is as follows: ,in As the upper limit of risk, To access risk values, To calibrate quantile values, risk levels are determined according to the risk level threshold table, starting from the upper risk bound. The mapping results show that the risk level threshold table in this specific implementation is set as follows: low risk less than 0.25, medium risk not less than 0.25 and less than 0.5, high risk not less than 0.5 and less than 0.75, and extremely high risk not less than 0.75. The S5 basic control instruction uses this risk level as the threshold judgment object.

[0111] The calibration module determines the uncertainty level based on the calibration quantile value, when Write "low uncertainty" when the uncertainty is less than the first uncertainty threshold; write "medium uncertainty" when the uncertainty is not less than the first uncertainty threshold and less than the second uncertainty threshold; write "high uncertainty" when the uncertainty is not less than the second uncertainty threshold. Both the first and second uncertainty thresholds are within the zero-to-one risk range and are derived from the uncertainty threshold table. (Incompleteness input) As an evidence integrity marker, it is written into the risk evidence chain and risk outcome audit field along with the uncertainty level, and is not used as a comparison object for S5 control thresholds;

[0112] The risk fusion module sorts the contributing items in the risk evidence chain, using the risk component contribution value, evidence confidence level, and trigger priority as the sorting keys. The contribution value is calculated according to the formula... Calculation, where For the first Each risk component's contribution value , and These are risk weight, effective mask, and normalized risk component, respectively. The larger the contribution value, the greater the impact of the component on the access risk value. If the contribution values ​​are the same, evidence items with high confidence in anomaly evidence and updated policy versions will be retained first.

[0113] The risk fusion module performs boundary checks on the fusion feature records; if a risk value is accessed... If the value is less than zero or greater than one, it is truncated according to the risk value range and written as a numerical truncation mark. If a certain weight in the risk weight table is missing, the corresponding valid mask is set to zero and the incompleteness input is increased. If the risk weight table version does not match the model version, the output of new risk levels is stopped and the previous stable risk result is read. The reading condition is that the strategy version of the previous stable risk result is compatible with the current control mapping table and the generation time does not exceed five minutes. If it exceeds five minutes, the risk fusion module writes the risk fusion unavailable status for S5 to generate enhanced authentication instructions.

[0114] The calibration module saves a calibration snapshot before outputting the upper bound of risk. The calibration snapshot includes the calibration group identifier, non-compliance score quantile, target coverage, first uncertainty threshold, second uncertainty threshold, sample size, and alternative calibration group label. The calibration snapshot is written to the calibration field of the session risk results table and read by S5, enabling the control execution module to distinguish between control actions triggered by high-risk values ​​and conservative control actions triggered by high uncertainty.

[0115] The risk fusion module generates a risk evidence chain, which records static permission matching results, resource sensitivity level, terminal security status, token consistency results, behavior deviation vector summary, relationship risk vector summary, abnormal evidence identifier, risk weight version, access risk value, calibration group, risk upper bound, uncertainty level, and fields involved in control mapping. The risk level, risk upper bound, uncertainty level, and risk evidence chain are written into the session risk result table and passed to S5.

[0116] In this specific embodiment, S5 includes:

[0117] The control execution module reads the session risk result table written by S4 and inputs the risk level, risk upper bound, and uncertainty level into the control mapping table. The control mapping table records the risk level code, risk upper bound reference range, uncertainty level, control instruction type, execution object, secondary authentication method, permission narrowing scope, resource limit parameters, session processing action, blocking duration, table version, and effective time. The risk level uses integer encoding, with low risk encoded as one, medium risk as two, high risk as three, and extremely high risk as four. The authentication threshold, downgrade threshold, termination threshold, and blocking threshold are all risk level encoding thresholds, with values ​​ranging from one to four and released with the same version of the control mapping table. Reaching a threshold indicates that the current risk level code is not less than the corresponding threshold code.

[0118] The control execution module first determines the basic control instructions based on the risk level code. When the risk level code is less than the preset authentication threshold code, a permission instruction is generated. When the risk level code is not less than the preset authentication threshold code and is less than the preset degradation threshold code, an enhanced authentication instruction is generated. When the risk level code is not less than the preset degradation threshold code and is less than the preset termination threshold code, a permission reduction instruction or resource restriction instruction is generated. When the risk level code is not less than the preset termination threshold code and is less than the preset blocking threshold code, a session termination instruction is generated. When the risk level code is not less than the preset blocking threshold code, an access blocking instruction is generated. The basic control instructions are written to the instruction candidate record, and the risk upper bound is retained. As a validation field;

[0119] After the basic control instructions are generated, the control execution module performs risk upper bound and uncertainty verification in this specific embodiment. This verification does not replace the aforementioned process of generating basic control instructions according to risk level thresholds. Instead, it selects the execution instruction from the same control strength or a more stringent control strength allowed by the control mapping table, and the correction rule is based on the formula. Execution, in which The control strength mapped to the risk level. The control strength mapped from the upper bound reference interval of risk. This represents the lower limit of control strength corresponding to high uncertainty. The larger the value, the stricter the control. If the upper limit of risk or the level of uncertainty requires stricter control, the upper limit verification or the reason for the uncertainty trigger should be written into the risk control handling result.

[0120] The control execution module takes session risk results, active session status, interface policy status, and target system reachability status as control state inputs, and sets control actions such as granting access, enhanced authentication, reduced privileges, resource restrictions, session termination, and access blocking. The control objective is to select the minimum executable action with a strength no less than that required by the risk, while satisfying policy hard constraints and session validity constraints. The control cycle is consistent with the session risk result generation cycle. If the target system is unreachable or policy hard constraints are not met, the granting action is prohibited, and the action set is reduced to enhanced authentication, session termination, or access blocking.

[0121] When the S2 late event compensation window triggers S4 to generate a revised version of the risk result, the control execution module performs idempotency verification based on the unified session identifier, risk result version number, and control instruction type. The control strength of control actions already executed in the same session is only allowed to remain monotonically constant. The revised version... Only enhanced authentication is allowed to be upgraded to reduced privileges, resource restrictions, session termination, or access blocking. It is not allowed to downgrade existing reduced privileges, resource restrictions, session termination, or access blocking to allow access. Once session termination and access blocking are executed, they will not be revoked due to the patch version. The patch version only updates the risk evidence chain, the risk result table version number, and the patch source field in the historical status.

[0122] Before sending control commands, the control execution module performs cleaning and consistency verification on the command candidate records. The verification includes whether the execution object is still in an active session, whether the token identifier is bound to the session identifier, whether the interface identifier belongs to the current business system, whether the resource identifier is still within the validity period of the resource access policy, and whether the control mapping table version is consistent with the S4 risk result version. If any verification fails, the module does not perform permission or downgrade access, but instead generates an enhanced authentication command and writes the verification failure field into the disposal result.

[0123] The control execution module selects instructions based on the lookup results of the control mapping table. If multiple control rules match the same risk level, risk upper bound interval, and uncertainty level, it first selects the record with the latest table version and effective time covering the current assessment time, and then selects the control strength. If the highest record is selected and the control strength is the same, the record with the finer granularity of the execution object is selected. The granularity of the execution object is compared in the order of session, interface, resource, and user. If the control rule is not hit, an enhanced authentication instruction is generated and the hit key is written into the handling result.

[0124] When control strength When responding to the enhanced authentication command, the control execution module sends a secondary authentication request to the identity authentication system. The command fields include unified user identifier, unified terminal identifier, unified session identifier, authentication method, authentication timeout time and risk evidence chain summary. The authentication method is retrieved from the control mapping table according to role type and terminal security status. When the authentication is successful, the original access request is maintained and the authentication result is written. When the authentication fails or times out, the control strength of the same session is increased to the session termination command and the failure reason is written.

[0125] When control strength When a permission reduction instruction or resource restriction instruction is issued, the control execution module calls the application interface gateway and the resource access gateway. The permission reduction instruction writes the set of allowed interfaces, the set of allowed request actions, and the effective duration. The resource restriction instruction writes the resource identifier, bandwidth limit, download prohibition flag, sensitive field desensitization flag, and the effective duration. If the interface access policy prohibits downgraded access, the control execution module directly generates a session termination instruction and writes the reason for the policy prohibition into the handling result.

[0126] When control strength When a session termination command or access blocking command is received, the control execution module sends a session termination command to the session management system or a blocking command to the application interface gateway. The session termination command includes a unified session identifier, a token identifier, an end time, and a termination reason. The blocking command includes a unified user identifier, a unified terminal identifier, a network location, a blocking duration, and a release condition. If the command execution returns a failure, the control execution module resends the command once within a three-second retry window. If the retry still fails, an execution failure status is written and a security alarm event is sent.

[0127] The control execution module sets recovery conditions for permission reduction instructions and resource restriction instructions. The recovery conditions are given by the control mapping table and include enhanced authentication passing, the risk upper bound of the next assessment cycle being lower than the downgrade threshold, and the uncertainty level not being higher than medium uncertainty. The recovery judgment reads the latest session risk result according to a fixed assessment cycle. When the recovery conditions are met, a permission recovery instruction is generated and the recovery reason is written. When the conditions are not met, the restriction status is maintained and a restriction continuation record is added.

[0128] The control execution module feeds back the execution status of the control command to the risk assessment server. The feedback fields include the target system receiving status, actual effective time, current status of the target object, failure reason and recovery condition status. The risk assessment server updates the control closed-loop record according to the feedback fields. If the actual effective time is later than the execution time and exceeds the control execution delay threshold, the delay exceedance is written into the terminal history status and session history status. The delay exceedance will participate in the access risk assessment the next time S1 generates an access event unit.

[0129] The control execution module writes each outgoing command to the instruction execution queue. The queue records include the command sequence number, target system, request message digest, response code, response time, number of retries, and final execution status. The authentication result, permission change result, resource access result, and session end result returned by the target system are all filled back into the disposal result record according to the unified session identifier. When the response time exceeds the control execution timeout threshold, the queue writes the command status as timeout and triggers a security alarm event.

[0130] Before appending historical states, the historical state maintenance module checks the continuity of the state version number. If the current state version number is inconsistent with the latest version number in the state index table, the latest state is read and the processing results are merged again. The merging rule is that session termination results and access blocking results take precedence over permission recovery results, and permission restriction results take precedence over permission release results. After the merging is completed, the new version number is written. If the state index table is not writable, the processing results are first put into the append queue and S1 is prohibited from reading incomplete version numbers.

[0131] The control execution module generates risk control handling result records, which include control instruction type, execution time, execution object, authentication result, permission change result, resource access result, and session end result. The execution time adopts the S1 unified time base, and the execution object retains the user, terminal, session, token, interface, and resource identifier. The risk control handling result is also written to the access event unit backfill queue, so that the subsequent security log system can associate the risk evidence chain and control execution result according to the same session identifier.

[0132] The historical status maintenance module appends the risk control processing results to the user's historical status, terminal's historical status, and session's historical status, respectively. The status version number is calculated using the formula... Increasing, among which To add the previous version number, To append the version number, the user's historical status records the most recent risk level, the most recent authentication result, and the summary of permission changes; the terminal's historical status records the most recent terminal security status, the most recent blocking time, and the conditions for release; and the session's historical status records the most recent control command, the session end result, and the summary of the risk evidence chain.

[0133] Once the historical status is added, the historical status maintenance module writes the status version number, risk control handling result identifier, and risk evidence chain identifier back to the status index table. When generating a new access event unit, S1 reads the historical status corresponding to the status version number according to the unified user identifier, unified terminal identifier, and unified session identifier, so that the previous risk control handling result can participate in the next access risk assessment.

[0134] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

[0135] This invention organizes access information that was originally scattered across identity, terminal, interface, resource, and log systems into a computable, continuous risk assessment chain through the synergistic effect of access event units, heterogeneous temporal access graphs, session evidence subgraphs, behavioral deviation vectors, relational risk vectors, abnormal evidence sets, and risk fusion functions. This enables risk values, risk levels, and risk evidence chains to directly serve the generation of access control instructions.

[0136] This invention constructs a session evidence subgraph centered on the active session and determines the edge weights based on edge type, time decay, resource sensitivity level, terminal security status, and authentication method level. At the same time, it introduces group conformal calibration to obtain the risk upper bound and uncertainty level, making the technical structure more suitable for real-time identification, interpretation, and dynamic handling of abnormal logins, unauthorized calls, and session hijacking.

Claims

1. A zero-trust-based access risk assessment method, characterized in that, include: S1. Collect access data from the identity authentication system, terminal management system, application interface gateway, business system, session management system, and security log system. Obtain access event units through field mapping, time alignment, and entity identifier normalization. S2. Construct a heterogeneous temporal access graph using access event units. Extract a session evidence subgraph centered on the active session. The session evidence subgraph contains session nodes and their connected users, terminals, tokens, interfaces, business systems, and resource nodes. Edge weights are determined according to edge type, time decay coefficient, resource sensitivity level, terminal security status, and authentication method level. S3. Input the user access sequence into a self-supervised behavior sequence model to obtain a behavior deviation vector. Input the session evidence subgraph into a temporal graph attention model to obtain a relationship risk vector. Generate an abnormal evidence set based on token consistency, terminal status, network location, role permissions, and access sequence baseline. S4. The access risk value is obtained by integrating the static permission matching result, resource sensitivity level, terminal security status, token consistency result, behavior deviation vector, relationship risk vector and abnormal evidence set, and grouped conformal calibration is performed to obtain the risk level, risk upper bound, uncertainty level and risk evidence chain. S5. Generate and execute access control instructions based on risk level, risk upper bound, and uncertainty level, and write the handling results to the user, terminal, and session history.

2. The zero-trust-based access risk assessment method according to claim 1, characterized in that, S1 includes: A unified event field is established for the access data. The unified event field includes user identifier, terminal identifier, session identifier, token identifier, interface identifier, business system identifier, resource identifier, access time, network location, authentication method, request action, and processing tag. The timestamps from different data sources are converted to the same time base; the differences in multi-source identifiers for the same entity are eliminated based on the account mapping table, terminal certificate, and session identifier table; missing fields are marked with missing flags and the data source identifier is retained to form the access event unit.

3. The zero-trust-based access risk assessment method according to claim 1, characterized in that, S2 includes: The user, terminal, session, token, interface, business system, and resource in the access event unit are respectively treated as nodes, and the authentication, holding, calling, accessing, attribution, and disposal relationships are treated as directed edges; timestamps are written according to the access time to form the heterogeneous time-series access graph; adjacent nodes and edges within the same session window are retrieved using the session identifier of the active session to form the session evidence subgraph; the edge weights are obtained by normalizing and weighting the edge type base weight, time decay coefficient, resource sensitivity level corresponding weight, terminal security status corresponding weight, and authentication method level corresponding weight.

4. The zero-trust-based access risk assessment method according to claim 1, characterized in that, S3 includes: sorting the access event units according to user identifier and access time, and encoding them to obtain a user access sequence; outputting the deviation component between the current access segment and the user's historical access baseline by the self-supervised behavior sequence model, and concatenating each deviation component into the behavior deviation vector; calculating the adjacent entity attention coefficient by the temporal graph attention model according to node type, edge type, edge weight and edge timestamp, and aggregating it to obtain the relationship risk vector; and using the behavior deviation vector and the relationship risk vector as inputs to generate the abnormal evidence set.

5. The zero-trust-based access risk assessment method according to claim 1, characterized in that, S4 includes: The static permission matching result is obtained by matching the role permission table, interface access policy, and resource access policy. The static permission matching result, resource sensitivity level, terminal security status, token consistency result, behavior deviation vector, relationship risk vector and abnormal evidence set are input into the risk fusion function. The risk fusion function outputs the access risk value using preset feature weights and evidence missing mask. The calibration groups are divided according to user roles, interface types, and resource sensitivity levels. The group conformal calibration is performed on the access risk value to obtain the risk level, the risk upper bound, the uncertainty level, and the risk evidence chain.

6. The zero-trust-based access risk assessment method according to claim 1, characterized in that, S5 includes: inputting the risk level, the risk upper bound, and the uncertainty level into a control mapping table; generating a release instruction when the risk level does not reach a preset authentication threshold; generating an enhanced authentication instruction when the risk level reaches a preset authentication threshold but does not reach a preset downgrade threshold; generating a permission reduction instruction or a resource restriction instruction when the risk level reaches a preset downgrade threshold but does not reach a preset termination threshold; generating a session termination instruction when the risk level reaches a preset termination threshold but does not reach a preset blocking threshold; and generating an access blocking instruction when the risk level reaches a preset blocking threshold.

7. The zero-trust-based access risk assessment method according to claim 4, characterized in that, The self-supervised behavior sequence model is trained in the following way: user access sequence samples are constructed from historical access event units, and event masking, adjacent event order prediction and session next action prediction are performed on the user access sequence samples to form a self-supervised training task. Using event field embedding, time interval embedding, and resource sensitivity level embedding as input, and the weighted sum of mask event reconstruction error, sequence prediction error, and next action prediction error as training loss, model parameters are obtained for outputting the behavior deviation vector.

8. The zero-trust-based access risk assessment method according to claim 4, characterized in that, The abnormal evidence set is generated in the following ways: comparing the current terminal proof with the terminal proofs registered in the same session window to generate terminal change evidence; comparing the current network location with the adjacent location transfer set in the historical location sequence to generate network location jump evidence; comparing the token fingerprint with the terminal proof binding table to generate token-terminal inconsistency evidence; and comparing the role permission level with the interface sensitivity level to generate unauthorized call evidence. The current access sequence fragment is compared with the user's historical access baseline to generate sequence deviation evidence; the abnormal evidence set is input into the risk fusion function and written into the risk evidence chain.

9. The zero-trust-based access risk assessment method according to claim 5, characterized in that, The grouped conformal calibration includes: within each calibration group, using the absolute value of the difference between the risk label of a historically labeled access sample and the corresponding access risk value as the non-compliance score; determining the calibration quantile value from the distribution of the non-compliance scores according to a preset target coverage; truncating the sum of the current access risk value and the calibration quantile value to a preset risk value range to obtain the upper bound of the risk; determining the uncertainty level based on the comparison results of the calibration quantile value with a preset first uncertainty threshold and a preset second uncertainty threshold, and using the uncertainty level as the input of the control mapping table.

10. The zero-trust-based access risk assessment method according to claim 6, characterized in that, The handling results include control instruction type, execution time, execution object, authentication result, permission change result, resource access result, and session end result; the handling results are appended to the user's historical state, terminal's historical state, and session's historical state, and a status version number is written to the appended historical state; when a new access event unit is generated, the historical state corresponding to the status version number is read, so that the previous handling result participates in the next access risk assessment.

Images