Background permission management system and method for adaptive risk control

Abstract

The application provides a background permission management system and method of adaptive risk control. It includes a data acquisition module for collecting behavior data and environment data associated with an account and converting the data into an event stream; a context management module for associating a context attribute set with the event stream; a feature construction module for generating a multi-dimensional feature vector based on the event stream and the context attribute set; an adaptive risk assessment module for calling at least two heterogeneous models to perform parallel reasoning on the multi-dimensional feature vector; a decision engine module for mapping risk weights to access control instructions and audit instructions; an audit module for recording audit data according to the audit instructions; and a permission management module for calculating permission weights according to decay parameters and generating permission recovery instructions or maintenance instructions according to threshold judgments. The application can realize event stream unification and context binding, real-time risk assessment and strategy linkage, and permission adaptive recovery closed loop.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an adaptive risk control background permission management system and method. Background Technology

[0002] As enterprise information systems expand and job positions change frequently, backend permissions need to be dynamically managed across multiple dimensions, including accounts, roles, resources, operations, and data domains. Employees' access needs continuously change throughout their entire lifecycle, from onboarding and job transfers to departures, making timely and traceable authorization and revoke mechanisms crucial for effective access control.

[0003] Existing technologies generally adopt a role-based static authorization model (RBAC), which mainly relies on OA / ITSM applications, manual approval, and manual authorization. Fine-grained permissions are scattered across various business systems. Auditing relies heavily on log export and report verification. Although single sign-on and privileged account management are introduced in some scenarios, a unified permission relationship model across systems has not been formed, and it is difficult to incorporate behavioral context and real-time risks into authorization decisions.

[0004] Existing technologies still have the following problems: rigid permissions, failure to trigger automatic revoke of permissions due to job changes and resignations, resulting in a drift of permissions that only increases and never decreases; widespread over-authorization and redundancy, making it difficult to pre-verify separation of duties rules; lagging auditing, lacking real-time judgment and interception of unauthorized access; and the invisibility of multi-source data and permission topology, resulting in a scattered chain of evidence and difficulty in ensuring cross-system consistency and idempotency, leading to slow authorization, incomplete revokeability, and difficulty in tracing problems. Summary of the Invention

[0005] In view of this, embodiments of this application provide an adaptive risk control background permission management system and method to solve the problems of existing technologies, such as the difficulty in unifying cross-system behavior and environment data and binding them to context, the difficulty in real-time assessment and policy linkage of access risks based on multi-dimensional features, and the lack of adaptive revocation and parameterized threshold management of permission lifecycle.

[0006] The first aspect of this application provides an adaptive risk control backend access control management system, comprising: a data acquisition module for collecting behavioral data and environmental data associated with an account, and converting the behavioral data and environmental data into a unified event stream; a context management module for maintaining an account identifier and a set of context attributes, and associating the set of context attributes with the event stream; a feature construction module for generating a multi-dimensional feature vector based on the event stream and the set of context attributes; an adaptive risk assessment module for calling at least two heterogeneous models to perform parallel reasoning on the multi-dimensional feature vector and generating normalized risk weights; a decision engine module for mapping the risk weights to access control instructions and audit instructions according to configurable threshold ranges and policy rules; an audit module for executing access control instructions in the access control channel and recording audit data according to the audit instructions; and an access control module for maintaining the lifecycle state of access objects, calculating access weights according to decay parameters, and generating access revoke instructions or retention instructions according to thresholds; wherein, the output of the feature construction module serves as the input of the adaptive risk assessment module, the audit data and account status changes generated by the audit module are fed back to the feature construction module and the access control module for update calculations, and the access revoke instructions are executed by the audit module in the access control channel.

[0007] The second aspect of this application provides a backend permission management method for adaptive risk control based on the system of the first aspect, comprising: collecting behavioral data and environmental data associated with an account, and converting the behavioral data and environmental data into a unified event stream; maintaining an account identifier and a set of context attributes, and associating the set of context attributes with the event stream to form an event-context binding record; generating a multi-dimensional feature vector based on the event-context binding record, wherein the multi-dimensional feature vector includes one or more of context features, temporal features, aggregate features, and derived features; invoking at least two heterogeneous models to perform parallel inference on the multi-dimensional feature vector, and generating a normalized risk weight through fusion; mapping the risk weight to access control instructions and audit instructions according to a configurable threshold range and policy rules; issuing and executing access control instructions in the access control channel, and recording audit data according to the audit instructions; calculating permission weights according to attenuation parameters, generating permission revoke instructions or retention instructions according to thresholds, and executing permission revoke instructions in the access control channel; and feeding back audit data and account status changes to update the generation of multi-dimensional feature vectors and the calculation of permission weights.

[0008] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0009] The system comprises several modules: a data acquisition module to collect behavioral and environmental data associated with accounts and convert them into a unified event stream; a context management module to maintain account identifiers and context attribute sets and associate these sets with the event stream; a feature construction module to generate multi-dimensional feature vectors based on the event stream and context attribute sets; an adaptive risk assessment module to invoke at least two heterogeneous models to perform parallel inference on the multi-dimensional feature vectors and generate normalized risk weights; a decision engine module to map risk weights to access control and audit instructions according to configurable threshold ranges and policy rules; an audit module to execute access control instructions in the access control channel and record audit data based on these instructions; and a permission management module to maintain the lifecycle state of permission objects, calculate permission weights based on decay parameters, and generate permission revoke or retain instructions based on threshold values. The output of the feature construction module serves as the input to the adaptive risk assessment module. Audit data and account status changes generated by the audit module are fed back to the feature construction and permission management modules for update calculations. Permission revoke instructions are executed by the audit module in the access control channel. This application enables unified event flow and context binding, real-time risk assessment and policy linkage, and closed-loop adaptive permission revocation. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of the structure of the adaptive risk control backend permission management system provided in the embodiments of this application;

[0012] Figure 2 This is a flowchart illustrating the adaptive risk control backend permission management method provided in the embodiments of this application. Detailed Implementation

[0013] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0014] With the increasing number of backend permissions and the adjustment of personnel positions within enterprises, each time an employee requests permissions, various processes must be followed. The existing process includes: submitting an OA application, filling in the permission path, and manual authorization. When an employee is transferred to a department or leaves the company, permissions may not be revoked in a timely manner, resulting in employees still retaining permissions and potentially leading to data leaks and other related problems. Therefore, traditional backend permission management systems have the following shortcomings:

[0015] 1. Rigid permissions and untimely changes: Role permissions are manually configured, and manual adjustments are required when job positions change;

[0016] 2. Over-authorization leads to abuse of permissions: Permissions are only increased and never decreased, with 90% of employees having redundant permissions;

[0017] 3. Weak auditing, problems are only discovered after they occur: Logs are reviewed after the fact, but unauthorized access cannot be intercepted in real time.

[0018] The existing backend permission management system has the aforementioned defects, which leads to the following problems:

[0019] When changing employee permissions, an application must first be submitted through the OA system. Once approved, the administrator will re-grant the employee the new permissions. The problem is that this method relies on the employee's application. If an employee changes jobs (job adjustment / resignation) and the administrator fails to reclaim previous permissions when applying for new ones, the employee may have excessive permissions, leading to a risk of data leakage and financial losses for the company.

[0020] Existing technologies lead to abuse of permissions, untimely revocation of permissions, and difficulty in tracing problems. Because existing technologies rely too heavily on human intervention and lack detection capabilities, they result in slow permission granting, redundant employee permissions, and weak auditing.

[0021] In view of the problems existing in the prior art, this application provides a backend permission management system and method based on multi-dimensional attribute awareness and adaptive risk control, which is particularly suitable for systems requiring dynamic fine-grained permission control. This application relates to an automated, intelligent, and highly flexible permission warning and revoke system, which can improve permission security and protect enterprise data security.

[0022] The following detailed description, in conjunction with the accompanying drawings and specific embodiments, illustrates the specific framework and functions of the adaptive risk control backend permission management system provided in this application. Figure 1 This is a schematic diagram of the structure of the adaptive risk control backend permission management system provided in the embodiments of this application, as shown below. Figure 1 As shown, the adaptive risk control backend access management system may specifically include the following modules:

[0023] Data acquisition module 101 is used to collect behavioral data and environmental data associated with the account, and convert the behavioral data and environmental data into a unified event stream;

[0024] Context management module 102 is used to maintain account identifiers and context attribute sets, and associate the context attribute sets with event streams;

[0025] Feature construction module 103 is used to generate multidimensional feature vectors based on event stream and context attribute set;

[0026] The adaptive risk assessment module 104 is used to call at least two heterogeneous models to perform parallel inference on multidimensional feature vectors and generate normalized risk weights.

[0027] The decision engine module 105 is used to map risk weights into access control instructions and audit instructions according to configurable threshold ranges and policy rules.

[0028] The audit module 106 is used to execute access control instructions on the access control channel and record audit data according to the audit instructions;

[0029] The permission management module 107 is used to maintain the lifecycle status of permission objects, calculate permission weights based on decay parameters, and generate permission revoke instructions or retention instructions according to thresholds.

[0030] The output of the feature construction module serves as the input of the adaptive risk assessment module. The audit data and account status changes generated by the audit module are fed back to the feature construction module and the permission management module for updating calculations. The permission revoke command is executed by the audit module in the access control channel.

[0031] In some embodiments, behavioral data and environmental data associated with an account are collected, and the behavioral data and environmental data are converted into a unified event stream, including:

[0032] The multi-source acquisition adapter standardizes data from business systems, network boundaries, databases, and terminals into a unified event pattern.

[0033] The data is time-aligned and sequenced based on a global time base and water level control, and a globally unique event identifier and a unified account identifier are generated for each record.

[0034] Deduplication and integrity checks are performed based on idempotent keys, and fields containing sensitive information are anonymized or tokenized at the field level while retaining controlled recovery identifiers.

[0035] The processed structured event records are output as a unified event stream using a streaming publishing mechanism with transaction commit and replay protection, which is then called by the feature construction module.

[0036] Specifically, this embodiment focuses on the technical solution of "collecting behavioral data and environmental data associated with accounts and converting them into a unified event stream". The system consists of a multi-source acquisition adapter, an event standardization and semantic annotation unit, a time alignment and watermark control unit, an identifier normalization and deduplication verification unit, a sensitive field desensitization and tokenization unit, and a transactional streaming publishing unit, providing a continuous and traceable unified event stream for the feature construction module.

[0037] The implementation of the key technical means involved in this embodiment is described below, and the specific content is as follows:

[0038] Multi-source acquisition adapter: Deploy adapters at the business system, network boundary, database and terminal sides to access business operation logs, network session metadata, database audit changes and terminal interaction events respectively; the adapter outputs raw event fragments that follow a unified event pattern.

[0039] Event standardization and semantic annotation: Perform field mapping and value range validation on the original event fragments, supplement the necessary fields such as event time, account identifier, resource identifier, operation type, source channel, device fingerprint, network address, and write semantic tags according to the source channel.

[0040] Time alignment and watermark control: The event time is calibrated based on a global time base, out-of-order and late events are handled based on watermark control, and events within the same account session are rearranged in sequence.

[0041] Identifier normalization and deduplication verification: Generate a unified account identifier through the account identifier mapping relationship, generate a globally unique event identifier ID for each record; calculate the idempotent key and perform deduplication, integrity and structural consistency verification.

[0042] Sensitive field desensitization and tokenization: Perform field-level desensitization or tokenization on sensitive fields such as personal identifiers, device identifiers, and network addresses, and generate controlled recovery identifiers, which can only be restored within the audit domain according to the authorization rules.

[0043] Transactional streaming deployment: The processed structured event records are written to the event buffer, and a unified event stream is output using a streaming deployment mechanism with transaction commit and replay protection to ensure the order and idempotency in fault and retry scenarios; the unified event stream serves as the input to the feature construction module.

[0044] The following explains the concepts of important technical terms used in this embodiment, in detail as follows:

[0045] Unified event pattern: A set of patterns that define the field set, encoding method and value range of multi-source events at a higher level, so that business systems, network boundaries, databases and terminal sources are comparable and computable under the same semantics.

[0046] Water level control: During the flow processing, the time boundary of the determinable sequence is defined by advancing the water level marker, handling out-of-order and late events and triggering window calculation closure.

[0047] Unified account identifier: Map heterogeneous account identifiers of the same natural person from different sources to globally unique account identifiers, maintaining consistent references across systems.

[0048] Idempotent key: Composed of elements such as source channel identifier, unified account identifier, and event time sequence number, it is used for deduplication and consistency verification across retry and across partitions.

[0049] Field-level desensitization and tokenization: At the field level, sensitive values ​​are irreversibly masked or replaced with controllable and reversible tokens, and then limited to restoration within the audit domain with a controlled restoration identifier, reducing the minimum exposure surface of the data.

[0050] Transactional streaming publishing: It achieves ordered reachability and exactly-once semantics of a unified event stream through commit confirmation, offset management and replay protection, avoiding duplicate consumption or loss.

[0051] For example, in some examples, the operation logs generated by the business system, the session metadata collected by the network boundary, the change records of the database audit, and the interaction events of the terminal embedding are respectively accessed by four types of adapters and output as raw event fragments; the standardization and semantic annotation unit uniformly maps the four types of fragments into event records composed of fields such as event time, account identifier, resource identifier, operation type, source channel, device fingerprint, and network address.

[0052] Furthermore, the time alignment and water level control unit calibrates the event time based on the global time reference and rearranges out-of-order events of the same account within the window period; the identifier normalization and deduplication verification unit generates a unified account identifier through the account mapping relationship and generates an event identifier ID for each record. At the same time, it uses the source channel identifier + unified account identifier + time sequence number to form an idempotent key to complete the removal of duplicate events and structural consistency verification.

[0053] Furthermore, the sensitive field desensitization and tokenization unit performs field-level tokenization on device fingerprints and network addresses, generates controlled recovery identifiers, and writes them into the audit domain. Finally, the transactional streaming publishing unit outputs structured event records as a unified event stream with a commit confirmation and replay protection mechanism, continuously supplying the feature construction module with stable input required for the generation of subsequent context features, temporal features, aggregate features, and derived features.

[0054] The above embodiments define the key technical features and operation procedures from multi-source acquisition to unified event stream output, and provide implementation points such as field normalization, time series alignment, identifier deduplication and transactional publishing, to ensure that the feature construction module can perform multi-dimensional feature generation and subsequent parallel inference processing under unified semantics and consistent timing.

[0055] In some embodiments, maintaining an account identifier and a set of context attributes, and associating the set of context attributes with an event stream, includes:

[0056] Establish a context attribute namespace and attribute dictionary, uniformly register the attribute categories and encoding methods of account identifiers, and assign context model version numbers;

[0057] Data from multiple sources is aggregated based on account identifiers, and a set of context attributes is generated. The associated attributes are merged and labeled according to the preset conflict resolution rules and the separation of responsibilities constraint matrix.

[0058] Generate a context snapshot of the context attribute set at a point in time, assign a context snapshot identifier, and maintain the mapping relationship between account identifiers and context snapshot identifiers;

[0059] When processing the event stream, the corresponding context snapshot identifier is retrieved based on the event time and account identifier. The context snapshot identifier is then injected into the context field of the event record to form an event-context binding record for use by the feature building module.

[0060] Specifically, this embodiment focuses on the technical solution of "maintaining account identifiers and context attribute sets, and associating the context attribute sets with event streams". The implementation of this embodiment is as follows:

[0061] Establishment of context attribute namespace and attribute dictionary: Create a unified namespace and attribute dictionary in the context management module, uniformly register the attribute categories, encoding methods and value ranges associated with account identifiers, and generate a context model version number to distinguish attribute definition changes.

[0062] Multi-source data aggregation and attribute merging: Using account identifier as the primary key, attribute fragments are pulled from multiple sources such as personnel directory, organizational adjustment, resource directory, and asset and equipment list to generate a context attribute set; attributes with the same name are prioritized and merged according to preset conflict resolution rules, and conflict groups and incompatible groups are marked according to the responsibility separation constraint matrix.

[0063] Context Snapshot Generation and Identifier Mapping: At key points in time, the set of context attributes is solidified into a context snapshot, a context snapshot identifier (CSID) is assigned, and account identifiers are maintained. The mapping relationship and effective range are used to trace back the context when any event occurs.

[0064] Context injection during the event processing phase: When the unified event stream is input from the data acquisition module, the corresponding CSID is retrieved based on the event time and account identifier. The CSID and the context model version number are then injected into the context field of the event record to form an event-context binding record, which serves as the upstream input for context features, time-series features, aggregate features, and derived features.

[0065] Output to the feature building module: Event and context binding records are continuously output through a standardized interface, providing a consistent and traceable context input for parallel sub-models.

[0066] The following explains the concepts of important technical terms used in this embodiment, in detail as follows:

[0067] Context attribute namespace: A collection that provides a unified name and hierarchy for the categories, codes, and value ranges of account-related attributes, used for consistent referencing across systems.

[0068] Attribute dictionary: A metadata dictionary that registers the semantics, origin, and version strategy of each attribute, providing a foundation for context model version management.

[0069] Context model version number: A version marker that identifies the current attribute definition and is used to maintain the stability of the definition of historical events when the attribute definition is adjusted.

[0070] Context snapshot and CSID: A set of context attributes and their unique identifiers fixed at a specific point in time, used to ensure the temporal consistency between event playback and model training.

[0071] Separation of Duties Constraint Matrix: A set of rules that matrix-label non-coexistent permission groups or duty groups, directly marking conflict relationships at the context attribute layer for reference by subsequent feature construction and decision engine.

[0072] Event and context binding records: In the unified event stream, each event is supplemented with a record format that includes the CSID and the context model version number, ensuring context consistency between feature engineering and real-time prediction stages.

[0073] For example, in some cases, an employee's account identifier is adjusted to a new department and a new resource domain label is added. The context management module first registers the employee's organizational unit, job category, resource domain, device fingerprint set, network access range, and other attributes in the namespace using the latest dictionary and generates a new context model version number. Then, it aggregates fragments from the personnel directory and resource directory using the account identifier, retains the resource domain identifier of the new department according to the conflict resolution rules, marks "Settlement Approval Group" and "Cashier Payment Group" as incompatible based on the separation of duties constraint matrix, and writes them into the context attribute set.

[0074] Furthermore, the module generates a context snapshot and assigns a CSID at the zero point when the organization takes effect, while also recording the account identifier. The mapping and effective range are defined. Subsequently, when login and download events generated by the data acquisition layer enter the unified event stream, the event processing unit retrieves the corresponding CSID based on the event time and account identifier, injects the CSID and context model version number into the event record, forms an event and context binding record, and outputs it to the feature construction module; the context features are directly extracted from this binding record, the time series and aggregate features are calculated using this record as a benchmark, and the derived features are generated by combining them; finally, these features are consumed in parallel by the multi-model fusion module for risk weight assessment and linkage with the decision engine.

[0075] Furthermore, through snapshot-based context binding, when the permission management module calculates permission weights or triggers revocation commands based on lifecycle and decay parameters, it can reference the same context as when the event occurred, thereby ensuring consistency and traceability of the entire process from feature construction to policy execution.

[0076] In some embodiments, generating a multidimensional feature vector based on the event stream and the set of context attributes includes:

[0077] Event and context-bound records are sequentially organized according to multi-granularity time windows, and session boundaries are adaptively determined based on behavior intervals;

[0078] Generate contextual features, including one or more of the following: account attribute tags, resource sensitivity identifiers, or access environment identifiers;

[0079] Generate time-series features, including one or more of the following: operation frequency within a time window, rate of change across a window, or work period markers;

[0080] Generate aggregate features, including one or more of the following: counts by account or resource dimension, deduplication counts, or threshold comparison results;

[0081] Generate derived features, including one or more of the composite features obtained based on contextual features, temporal features, and aggregated features.

[0082] Specifically, this embodiment focuses on the technical solution of "generating multi-dimensional feature vectors based on event streams and context attribute sets", which corresponds to the data acquisition and feature engineering in the aforementioned embodiment and serves as the upstream input for parallel sub-model inference.

[0083] First, it receives event and context binding records obtained from unified event stream and context management, and organizes them into sequences according to multi-granularity time windows such as second, minute and hour. It then adaptively determines the session boundary by combining the event interval distribution and account activity mode, so that events within the same session are consistent in terms of time and context.

[0084] Secondly, based on the bound records, context elements are directly extracted to form a set of context features. Account attribute tags, resource sensitivity identifiers and access environment identifiers are mapped to computable fields and labeled together with the context model version number and context snapshot identifier.

[0085] Then, the event sequence is statistically analyzed within each time window to generate time-series features, including fields such as operation frequency, cross-window change rate, and working period markers, and an index is created for cross-window indicators for subsequent model reference.

[0086] Subsequently, aggregated features are generated around the account or resource dimension to obtain fields such as count, deduplication count and threshold comparison results, where the threshold comparison is consistent with the rule elements.

[0087] Finally, based on contextual features, temporal features, and aggregate features, combined transformations, ratio calculations, and sliding statistics are performed to form derived features, outputting a multidimensional feature vector composed of four types of features, which is provided to the adaptive risk assessment module through a standardized interface.

[0088] The following explains the concepts of important technical terms used in this embodiment, in detail as follows:

[0089] Multi-granularity time windows refer to maintaining second-level, minute-level, and hour-level window views simultaneously on the same pipeline, in order to accommodate both short-term sudden changes and daily patterns.

[0090] Adaptive session boundaries refer to dynamically determining the start and end points of a session based on the distribution of event intervals and the near-terminal activity of the account, avoiding the fragmentation of business processes by fixed thresholds.

[0091] Account attribute tags are used to characterize the organization and responsibilities of an account, resource sensitivity tags are used to indicate the access level of a resource object, and access environment tags are used to identify whether the IP belongs to the company network segment, whether the device is a commonly used device, and the network source category.

[0092] The work period marking classifies events into time periods based on the company's workday and time period criteria, and the cross-window change rate is used to measure the relative change of indicators in adjacent time windows.

[0093] The threshold comparison result is a thresholded Boolean field, derived from the structured representation of the rule elements.

[0094] Derived features are composite fields obtained by combining and sliding statistics on the three basic features, and are used to characterize higher-order behavioral relationships.

[0095] For example, in some cases, an account logs in at 21:30 and continuously accesses sensitive resources and downloads 60 data entries within 10 minutes, while simultaneously paging through the same URL 12 times from non-company IPs and uncommon devices. Event and context binding records are first sequenced within minute and hourly windows, and then adaptively grouped into a single session based on event intervals.

[0096] Contextual features are directly extracted from the binding records. Account attribute tags indicate the job category and scope of responsibilities of the account. Resource sensitivity identifiers mark the accessed resource as high-sensitivity. Access environment identifiers indicate that the IP is not in the company network segment and the device is not frequently used.

[0097] The time-series features generate operation frequencies in minute-level windows and calculate cross-window change rates in adjacent windows. At the same time, based on the company's standards, 21:30 is marked as a working period outside of working hours.

[0098] The aggregation feature counts download counts as 60 at the account level and determines "download count > 50" as true when comparing thresholds. At the resource level, it counts deduplication counts and records page turn counts as 12 at the URL level, determining "page turn count > 10" as true.

[0099] Based on the above, derived features are calculated such as the ratio of download count to session duration, the combined index of cross-window change rate triggered by unused devices, and the joint Boolean field of non-working hours and access to high-sensitivity resources.

[0100] Ultimately, the context features, temporal features, aggregate features, and derived features corresponding to the session are packaged into a multi-dimensional feature vector with a context model version number and a context snapshot identifier. This vector is then fed into the parallel sub-model pipeline through the feature engineering interface to generate normalized risk weights, and subsequently linked with the decision engine's automatic permission revocation mechanism.

[0101] The above embodiments fully disclose the key technical features and implementation methods from input binding, time organization, generation of four types of features to standardized output, ensuring consistency with the content shown in feature engineering and that it can be directly consumed by subsequent models.

[0102] In some embodiments, at least two heterogeneous models are invoked to perform parallel inference on multidimensional feature vectors and generate normalized risk weights, including:

[0103] Based on feature type, multidimensional feature vectors are divided into context feature sub-vectors, temporal feature sub-vectors, aggregate feature sub-vectors, and derived feature vectors;

[0104] All sub-vectors are input into at least two heterogeneous sub-models for parallel inference. The heterogeneous sub-models include at least two of the following: a first sub-model for context and aggregation evaluation, a second sub-model for time-series behavior evaluation, and a third sub-model for anomaly measurement, to obtain the basic risk score set.

[0105] Gating selection is performed on the sub-models participating in the fusion based on the set of context attributes, and the fusion weight of each basic risk score is determined. Weighted or stacked fusion is then performed to generate the initial risk score.

[0106] The initial risk score is mapped to a normalized risk weight that takes values ​​within a preset range, and the normalized risk weight is provided to the decision engine module.

[0107] Specifically, the adaptive risk assessment module receives the multi-dimensional feature vectors output by the feature construction module, divides them into context feature sub-vectors, time-series feature sub-vectors, aggregate feature sub-vectors and derived feature sub-vectors according to feature type, and attaches a context model version number and a context snapshot identifier to each sub-vector to ensure consistency.

[0108] Furthermore, following the real-time prediction path, all sub-vectors are fed into at least two heterogeneous sub-models for parallel inference. The heterogeneous sub-models include at least two of the following: a first sub-model for context and aggregation evaluation, a second sub-model for time-series behavior evaluation, and a third sub-model for anomaly measurement. Each sub-model independently generates a basic risk score and outputs it to the fusion layer.

[0109] Furthermore, the fusion layer performs gating selection on the sub-models participating in the fusion based on the set of context attributes, enabling or inhibiting the participation of specific sub-models; within the set of enabled sub-models, the fusion weight of each basic risk score is determined according to preset weight rules or online learning weights.

[0110] Furthermore, the fusion layer executes a weighted summation or stacking strategy based on the fusion weight, outputs an initial risk score in a single dimension, and includes a corresponding fusion configuration identifier for subsequent backtracking.

[0111] Finally, the calibration unit maps the initial risk score to a normalized risk weight that takes values ​​within a preset range, forming an inference result object carrying an account identifier, a context snapshot identifier, and a fusion configuration identifier, and provides the normalized risk weight to the decision engine module for policy mapping.

[0112] The following explains the concepts of important technical terms used in this embodiment, in detail as follows:

[0113] Gating selection: refers to the fusion layer controlling the participation of sub-models based on account attribute tags, resource sensitivity identifiers, or access environment identifiers in the context attribute set, so that fusion only occurs between sub-models related to the current scenario.

[0114] Fusion weight determination: refers to the process of assigning weights to each basic risk score within the set of gated sub-models. The weights can be derived from configuration rules or online learning updates, but in this embodiment they are limited to configurable parameters.

[0115] Stacked fusion: refers to a multi-layered fusion method that takes a basic risk score as input and then outputs an initial risk score through an upper-level fusion unit, which is different from simple weighting.

[0116] Calibration Unit and Preset Range: The calibration unit is responsible for mapping the initial risk score to a range value with a unified dimension. The preset range can be selected as [0,1], which facilitates the connection with the threshold range of the decision engine.

[0117] Fusion Configuration Identifier: Identifies the gating results and weight configurations used in a single fusion, which are used for the traceability and replayability of inference results.

[0118] For example, in some examples, the multidimensional feature vector output by the feature construction module includes contextual feature sub-vectors (job category, resource sensitivity identifier, access environment identifier), time-series feature sub-vectors (minute-level operation frequency, cross-window change rate, working period marker), aggregated feature sub-vectors (download count at the account level, deduplication count at the URL level, threshold comparison result), and derived feature sub-vectors (download count to session duration ratio, joint Boolean field of non-working period and high-sensitivity access). The adaptive risk assessment module simultaneously inputs all sub-vectors into the first and second sub-models for parallel inference, and uses the third sub-model to perform anomaly measurement on the derived feature sub-vectors, obtaining three basic risk scores.

[0119] During the fusion phase, the gating selection determines that the current resource sensitivity is high and the access environment is an infrequently used device based on the context attribute set. It then enables higher participation of the second and third sub-models while reducing the weight of the first sub-model. The fusion layer uses a weighted strategy to fuse the three basic risk scores to generate an initial risk score. The calibration unit maps this initial score to normalized risk weights and attaches a fusion configuration identifier and a context snapshot identifier.

[0120] Finally, the normalized risk weight, along with the account identifier, is sent to the decision engine module. The decision engine matches the threshold range of the risk weight according to the policy rule set, generates access control instructions and audit instructions, and issues them to the access control channel and audit storage, maintaining consistency with the real-time prediction and policy linkage process, and providing subsequent reference signals for permission lifecycle management.

[0121] The above embodiments disclose the necessary technical features and implementation processes for the chain from subvector partitioning, parallel inference, gated fusion to normalized output, ensuring compatibility with the aforementioned unified event flow, context binding, and feature engineering.

[0122] In some embodiments, risk weights are mapped to access control instructions and audit instructions according to configurable threshold ranges and policy rules, including:

[0123] Load the policy rule set with version identifier. The policy rule set includes threshold ranges and action templates.

[0124] The target strategy view is selected based on the set of contextual attributes and resource sensitivity, and the corresponding threshold range is matched according to the risk weight to determine the set of access control actions and the set of audit actions.

[0125] The system performs validation on the set of access control actions and the set of audit actions, and generates an execution sequence of access control instructions and audit instructions. The access control instructions include one or more of the following: allow, secondary authentication, monitoring, review, and blocking.

[0126] Specifically, firstly, the strategy rule set is loaded and versioned. During the initialization of the decision engine module, a strategy rule set with version identifiers is loaded. This set includes at least threshold range definitions and a set of action templates, and records the strategy identifier and its effective scope. To support online adjustments, the rule set is maintained in a versioned manner, and the old version is retained in a read-only state for rollback during switching.

[0127] Further, the target strategy view is selected. The system receives normalized risk weights, contextual attribute sets, and resource sensitivity identifiers from the adaptive risk assessment module. Based on resource category, sensitivity level, and account attributes, a target strategy view is selected, ensuring that subsequent threshold matching and action selection occur within the corresponding strategy subspace.

[0128] Further, threshold matching and action set determination are performed. Under the target policy view, preset threshold ranges are matched according to risk weights, and access control action sets and audit action sets are parsed from the action template library. The candidates for the access control action set include one or more of the following: allow, secondary authentication, monitoring, review, and blocking. The audit action set is used to record the required audit fields and collection methods.

[0129] Furthermore, dependency and conflict checks are performed. Dependency and conflict checks are conducted on the two sets of actions. If mutual exclusion is found, actions are pruned according to policy priority. If a dependency exists, a prerequisite action is inserted and the execution order is determined. At the same time, actions that may cause permission conflicts are removed or replaced in conjunction with the separation of duties constraint matrix.

[0130] Further, the instructions are orchestrated and output. The validated set of actions is orchestrated into an execution sequence, labeled with policy identifiers and rule set version numbers, and access control instructions and audit instructions are generated. Access control instructions are executed in the access control channel, while audit instructions are used to standardize and record fields such as account identifier, context snapshot identifier, risk weight, policy identifier, and execution status. Finally, the execution sequence and related identifiers are output to the audit module for distribution and retention.

[0131] The following explains the concepts of important technical terms used in this embodiment, in detail as follows:

[0132] Strategy rule set: Defines the combination of threshold ranges, action templates and priority relationships, with version identifier and effective scope attributes, used to support online adjustment and historical playback.

[0133] Target strategy view: A subspace selected within the strategy rule set based on the context attribute set and resource sensitivity, used to limit the scope of threshold matching and action parsing.

[0134] Action Templates: A collection of templates that provide parameterized descriptions of access control actions and auditing actions, including metadata on dependencies, mutual exclusions, and priorities.

[0135] Dependency and conflict verification: Constraint checks are performed on the sequential dependencies and mutual exclusion relationships between action templates, and the separation of duties constraint matrix is ​​used to avoid generating instruction combinations that cause permission conflicts.

[0136] Execution sequence: A sequence of instructions arranged according to defined priorities and dependencies, carrying policy identifiers and rule set version numbers to ensure that they can be executed sequentially and can be traced back in the access control channel.

[0137] For example, in some examples, the decision engine module loads a policy rule set of version V3, where the threshold ranges are defined as [0, 0.3), [0.3, 0.6), [0.6, 0.8), and [0.8, 1.0). An account's contextual attribute set includes a job category of external collaboration, an access environment of infrequently used devices, and a resource sensitivity flag of high. The normalized risk weight output by the adaptive risk assessment module is 0.78.

[0138] In response to this request, the decision engine selects the target policy view of "High-Sensitive Resource Access" and matches 0.78 to the range [0.6, 0.8). The access control action set is parsed from the action template corresponding to this range, which includes manual review and monitoring. The audit action set includes recording access fingerprints and screen recording summaries. During the dependency and conflict verification phase, it is confirmed that monitoring should be triggered before manual review, and no secondary authentication is required under this view.

[0139] The instructions, after being orchestrated, form the following execution sequence: start monitoring → notify the security team → initiate manual review. Simultaneously, audit instructions are generated to record the account identifier, context snapshot identifier, risk weight, policy identifier, and execution status. This execution sequence, along with the policy identifier and version V3, is output to the audit module for sequential distribution and recording by the access control channel.

[0140] Through the above process, the decision engine module completes the mapping from risk weights to access control instructions and audit instructions in the end-to-end link, connects with the real-time prediction results of the aforementioned embodiments, and provides referable policy identifiers and execution records for permission lifecycle management.

[0141] In some embodiments, access control instructions are executed on the access control channel, and audit data is recorded according to audit instructions, including:

[0142] Access control instructions are issued and executed one by one according to the execution sequence;

[0143] For each access control instruction, generate an execution idempotent key consisting of a global event identifier, a policy identifier, and a sequence number, and submit it according to the instruction dependency relationship to obtain the execution status;

[0144] For commands related to secondary authentication, monitoring, and blocking, the system respectively invokes the authentication service, initiates screen recording and behavior analysis, and performs session termination and account freezing operations.

[0145] The audit record is generated according to the audit instructions, written to the audit storage and assigned an evidence chain identifier, and published along with the account status change.

[0146] Specifically, firstly, instruction reception and sequence loading. The audit module receives the execution sequence carrying the policy identifier and rule set version from the decision engine module, establishes the execution context in the access control channel, loads the access control instructions and audit instructions in the sequence, and locks the sequence order and dependencies.

[0147] Furthermore, the system implements a step-by-step delivery and status feedback mechanism. The audit module delivers access control instructions one by one according to the execution sequence. Each time an instruction is delivered, an execution idempotent key is generated based on the policy identifier, global event identifier, and sequence number, serving as the unique submission credential for that instruction. The system also records the execution status (submission, acceptance, completion, or failure) in the access control channel.

[0148] Furthermore, the processing of typed instructions is as follows: For secondary authentication instructions, the authentication service is invoked to generate a challenge and retrieve the authentication digest; for monitoring instructions, operation recording and behavior analysis are initiated and a recording index is generated; for blocking instructions, session termination is executed and account freezing or deactivation is triggered, and a notification is issued to initiate the investigation process if necessary.

[0149] Furthermore, audit log generation and persistence are performed. Audit logs are generated for each submitted or completed access control instruction based on the audit instructions. Each log includes at least one or more of the following: account identifier, global event identifier, context snapshot identifier, signature, risk weight, policy identifier, instruction type, execution status, timestamp, device fingerprint, network address, and screen recording index or authentication digest. Evidence chain identifiers are assigned to this batch of logs and written to the audit storage.

[0150] Furthermore, the process involves publishing and reverting data. Evidence chain identifiers and account status changes are published together as events for consumption by the feature construction module and the permission management module. These events are then used for subsequent feature updates and permission weight calculations, forming a closed loop.

[0151] The following explains the concepts of important technical terms used in this embodiment, in detail as follows:

[0152] Access control channel. This refers to a dedicated channel used to carry out access control command issuance and session control, completing command submission, status feedback, and evidence retention within the same context.

[0153] Execute the idempotent key. A unique key generated by combining the policy identifier, global event identifier, and sequence number is used for deduplication and consistent commit across retry and replay scenarios, ensuring that the same instruction is counted only once.

[0154] Evidence chain identifier. An identifier used to link multiple audit records within the same execution sequence, supporting subsequent backtracking, comparison, and evidence collection.

[0155] Screen recording index and authentication summary. The screen recording index is used to locate the video and behavior analysis results generated by monitoring, and the authentication summary is used to record the verifiable fingerprint of the challenge and response elements of secondary authentication within the audit domain.

[0156] Account status change events. Account status update messages triggered by blocking or freezing, used to synchronize with the permission management module to drive lifecycle judgment and revocation execution.

[0157] For example, in some examples, the normalized risk weight output by the adaptive risk assessment module is 0.85, and the decision engine module generates an execution sequence based on the high-sensitivity resource policy view as terminating access → deactivating the account → initiating an investigation, along with a policy identifier and rule set version.

[0158] The audit module loads this sequence into the access control channel. First, it issues a termination access command and generates an execution idempotent key K1. After receiving a successful session termination feedback, it generates an audit record R1 and writes it to the audit storage. Then, it issues a deactivation account command and generates an execution idempotent key K2. The account status is updated to frozen, and an audit record R2 is generated and written to the audit storage. Next, it issues an investigation start command and generates an execution idempotent key K3, triggering the evidence collection process on the monitoring side. An audit record R3 is generated and associated with the screen recording index or investigation number.

[0159] This batch of records is assigned a unified evidence chain identifier C and is released along with the account status change of account freezing. Based on this, the feature construction module updates the account's context and derived features, and the permission management module, under the automatic permission revocation mechanism, continues to calculate permission weights by combining idle days, activity level, and behavioral factors, and executes revocation or retention after threshold determination.

[0160] Through the above process, the audit module completes the step-by-step distribution of execution sequences, the unique identification of execution idempotent keys, the dedicated processing of typed instructions, the generation and persistence of audit records and evidence chains within the access control channel, and feeds back the results as events, providing continuous input for feature engineering and automatic permission revocation mechanisms, so as to maintain consistency and traceability in the end-to-end link.

[0161] In some embodiments, the permission management module includes:

[0162] The permission lifecycle management unit is used to configure activation period, idle period and recycling period for each permission, and store the stage weight;

[0163] The weight calculation and decay unit is used to calculate the current permission weight based on the initial weight, idle days, user activity, behavioral factors, and decay base.

[0164] The scanning and threshold judgment unit is used to compare the current permission weight with the revoke threshold according to a preset scanning frequency, and generate a permission revoke instruction or a permission retention instruction.

[0165] The recycling execution unit is used to notify the corresponding user and revoke permissions according to the permission recycling command, and write the recycling result to the audit module.

[0166] Specifically, firstly, there is the permission lifecycle management unit. For each permission object, three lifecycle segments are configured: activation period, idle period, and reclamation period. The weight of each segment is registered, and the effective period is recorded. When a permission is granted, it enters the activation period. If it is not invoked within a preset time period, it transitions to the idle period. Upon reaching the reclamation period, a reclamation evaluation is triggered. This unit generates timestamps and stage tags for stage transitions, which are used for subsequent weight calculations and auditing.

[0167] Further, the weight calculation and decay unit. Using an initial weight of 1.0 as a baseline, variables such as idle days (threshold > 5 days), user activity (frequency of operations in the past 7 days), and behavioral factors (weight 0.2) are collected. Monotonic decay calculation is performed using a decay base λ = 0.03. When a legitimate call or authorized secondary authentication is detected, the weight is replenished according to the phase rules, not exceeding the phase limit. This unit outputs the current permission weight, along with the variable values ​​and calculation batch identifier.

[0168] Further, the scanning and threshold judgment unit performs batch evaluations on a 24-hour schedule based on the scanning frequency. During peak business periods, scanning is automatically skipped and postponed to off-peak periods. The current permission weight is compared with the warning threshold of 0.6 and the revoke threshold of 0.3, respectively, generating a hold instruction, a warning flag, or a permission revoke instruction. This unit generates only one final instruction for the same permission within a single scanning cycle and records the threshold version number to ensure traceability.

[0169] Further, the revocation execution unit. Upon receiving the permission revocation instruction, it synchronously notifies the corresponding user and the superior, sets a short transition period, and then invokes the cross-system revocation process in the access control channel to revoke role mapping and resource item authorization; the revocation result, affected account identifier, and timestamp are written to the audit module, an evidence chain identifier is assigned, and archived; if the revocation fails, a compensation retry and manual review path are triggered. This unit also reports the status to the permission lifecycle management unit, sets the permission to be revoked, and disables subsequent scanning.

[0170] The following explains the concepts of important technical terms used in this embodiment, in detail as follows:

[0171] Stage weight: The upper limit weight boundary bounded to the activation period, idle period, and recovery period, used to constrain the value range and recovery magnitude of the weight calculation.

[0172] Decay base λ: A parameter used to control the decay rate driven by time and behavior. It combines the number of idle days and activity level to form a decreasing curve, with λ = 0.03 being preferred.

[0173] User activity: A usage intensity metric measured by the frequency of operations over the past 7 days, serving as a positive variable to suppress excessively rapid decay.

[0174] Behavioral factors: The aggregated value of behavioral signals generated by the AI ​​risk control and decision-making chain, which serves as an additional adjustment to the weights, with a preferred weight of 0.2.

[0175] Warning threshold and retrieval threshold: The boundaries for determining whether to generate a warning mark or retrieval instruction within the scan cycle, preferably 0.6 and 0.3.

[0176] Peak-hour skipping strategy: Pause scanning during peak business hours to reduce disruption to online systems and ensure the stability and predictability of scanning operations.

[0177] Evidence chain identifier: An identifier that unifies the association of multiple audit records and account status changes involved in a single execution of audit, supporting playback and evidence collection.

[0178] For example, in some cases, an account holds permission P. It is granted activation on the same day, with a maximum stage weight of 1.0. After six consecutive days of inactivity, the idle days threshold is triggered. The scanning and threshold judgment unit performs an evaluation during the off-peak hours of the seventh day: the weight calculation and decay unit decays the initial weight based on λ = 0.03, and combines activity (0 operations in the past 7 days) and behavioral factors (0.2) to obtain a current permission weight of approximately 0.55. Since this is below the warning threshold of 0.6 and above the recycling threshold of 0.3, a warning flag is generated and a notification is issued, and the lifecycle remains in the idle period.

[0179] After three days of no further calls, the weight further decreased to approximately 0.28 during the tenth day of scanning, triggering the revoke threshold of 0.3. The scanning and threshold judgment unit generated a permission revoke instruction. The revoke execution unit notified the user and superiors, set a short transition period, and then revoked the role mapping and resource item authorization corresponding to permission P in the access control channel. It generated a revoke result and wrote it to the audit module, assigned an evidence chain identifier C and an event timestamp, and simultaneously published an account status change event. Upon receiving the write-back information, the permission lifecycle management unit marked permission P as revoked and terminated subsequent scanning.

[0180] If a user completes an approved business call and passes secondary authentication during the transition period, the weight calculation and attenuation unit can perform a limited replenishment of the weight according to the activation period upper limit, and the scanning and threshold judgment unit will downgrade the revoke instruction to a retention instruction; this adjustment and its evidence are recorded by the audit module and associated with the identifier C. The above process is consistent with the automatic permission revoke mechanism, ensuring that the stage definition, weight calculation, threshold judgment and revoke execution operate in a closed loop within the same link.

[0181] In some embodiments, the system further includes:

[0182] The parameter adaptive module is used to dynamically adjust the eviction threshold, scanning frequency and attenuation base according to permission sensitivity, permission usage rate and business period, and provide the adjusted parameters to the decision engine module and permission management module.

[0183] Specifically, firstly, parameter baselines and policy sets are loaded. The parameter adaptation module loads a parameter policy set with a version identifier at startup. The policy set contains baseline configurations for the eviction threshold, scan frequency, and decay base λ (e.g., eviction threshold 0.3, scan frequency 24 hours, λ = 0.03) and hierarchical adjustment rules, records the policy set version and effective scope, and establishes a parameter subscription relationship with the permission lifecycle management unit.

[0184] Further, signal acquisition and measurement modeling are performed. The module periodically receives three types of signals from context management and feature construction: permission sensitivity (derived from resource sensitivity identifiers and separation of duties constraint matrix), permission usage rate (calculated by sliding window to count call frequency / authorized on-duty duration), and business time period (labeled as peak / off-peak / low peak based on historical request volume and weekday criteria). At the same time, it receives account status and policy identifiers issued by the audit module to ensure consistency.

[0185] Furthermore, hierarchical calculation and candidate parameter generation are performed. For each permission set, candidate retrieval thresholds t′ are first generated hierarchically according to sensitivity, then candidate attenuation bases λ′ are generated according to usage rate, and finally candidate scanning frequencies f′ are generated according to business time period. If multiple rules are triggered simultaneously for the same permission set, they are merged according to the priority of "sensitivity priority > usage rate priority > time period priority".

[0186] Furthermore, stability control and legality verification are implemented. Rate of change limits and hysteresis windows are applied to t′, λ′, and f′ to prevent frequent fluctuations within adjacent evaluation periods. Subsequently, interval truncation is performed according to parameter protection boundaries to ensure that the recovery threshold, scan frequency, and λ fall within the allowable range, and parameter version numbers and effective time windows are generated.

[0187] Further, parameter publishing and injection. The validated parameter set is published to the decision engine module and the permission management module in the form of events: the decision engine receives the revoke threshold for alignment of policy range configuration, and the permission management module receives the scan frequency and λ for scanning and weight calculation; at the same time, the parameter version number is written to the audit field for backtracking.

[0188] Furthermore, rollback and grayscale control are implemented. Grayscale indicators and rollback points are set for new parameters. When abnormal fluctuations are detected or the strategy set is replaced, the system can roll back to the previous stable version, ensuring timing consistency with the aforementioned implementation chain.

[0189] The following explains the concepts of important technical terms used in this embodiment, in detail as follows:

[0190] Permission sensitivity stratification: Based on resource sensitivity identifiers and the separation of duties constraint matrix, permissions are divided into low / medium / high / ultra-high levels to drive the stratified adjustment of eviction thresholds.

[0191] Permission usage rate: The ratio of the frequency of actual permission calls to the authorized on-duty time is measured within the sliding window, and is used as the basis for adjusting λ.

[0192] Business period labeling: Based on historical request volume and the enterprise's working day criteria, peak / off-peak / low-peak periods are defined, and a peak period skip scan signal is provided.

[0193] Rate of change limit and hysteresis window: Set the maximum step size and minimum hold period for parameter changes to avoid frequent switching back and forth.

[0194] Parameter protection boundaries: set minimum and maximum boundaries for t, λ, and f to ensure that the parameters operate within a controllable range.

[0195] Parameter version and effective domain: Generates a version number and effective time window for each parameter calculation, and marks the hierarchical permission set that applies to it, for consistency injection and audit backtracking.

[0196] For example, in some examples, the baseline when policy set version V5 is loaded is a revoke threshold of 0.3, a scan frequency of 24 hours, and λ = 0.03. A certain high-sensitivity permission set has a permission usage rate of 0.04 within the past 30-day window, currently during peak business periods. The parameter adaptation module first lowers the revoke threshold based on sensitivity to generate t′ = 0.25; then it raises the attenuation base based on usage rate to generate λ′ = 0.05; finally, it adjusts the scan frequency to f′ = 48 hours based on business periods and marks peak periods as skipped scans.

[0197] During the stability control phase, rate-of-change limits are applied to t′, λ′, and f′ to ensure that single-cycle changes relative to the previous version V4 do not exceed a preset step size, and a hysteresis window of 72 hours is set. After legality verification, parameter version V5.1 and the effective time window are generated. The module publishes {t=0.25, λ=0.05, f=48 hours} and version V5.1 to the decision engine module and the permission management module: the decision engine receives t and updates the policy interval configuration mapping, and the permission management module receives λ and f and adopts new decay and scheduling parameters in the next scan cycle accordingly; at the same time, parameter version V5.1 and the effective time window are recorded in the audit domain. If abnormal fluctuations are subsequently detected, triggering rollback conditions, the module switches back to version V5 according to the rollback point and broadcasts the update to ensure consistency of references by all modules.

[0198] Through the above implementation methods, the parameter adaptation module runs upstream of the permission lifecycle mechanism, maintaining consistency with the context and policy identifier of feature engineering and real-time prediction in the aforementioned embodiments, thus completing a closed-loop process from signal acquisition, hierarchical calculation, stability control to parameter injection and rollback.

[0199] The above embodiments have described in detail the specific modules and functions of the adaptive risk control background permission management system of this application. The implementation process of the adaptive risk control background permission management method of this application will be described in detail below with reference to specific embodiments. Figure 2 This is a flowchart illustrating the adaptive risk control backend permission management method provided in this application embodiment, as shown below. Figure 2 As shown, the background permission management method for adaptive risk control may specifically include the following steps:

[0200] S201, collect behavioral and environmental data associated with the account, and convert the behavioral and environmental data into a unified event stream;

[0201] S202, maintain the account identifier and context attribute set, and associate the context attribute set with the event stream to form an event-context binding record;

[0202] S203, Generate a multi-dimensional feature vector based on event and context binding records. The multi-dimensional feature vector includes one or more of the following: context features, temporal features, aggregate features, and derived features.

[0203] S204, invoke at least two heterogeneous models to perform parallel inference on multidimensional feature vectors, and generate normalized risk weights by fusion;

[0204] S205 maps risk weights to access control instructions and audit instructions according to configurable threshold ranges and policy rules;

[0205] S206, issue and execute access control instructions in the access control channel, and record audit data according to the audit instructions;

[0206] S207, calculate the permission weight based on the attenuation parameter, determine the permission revoke instruction or retain instruction according to the threshold, and execute the permission revoke instruction in the access control channel;

[0207] S208, the audit data and account status change are fed back to update the generation of multidimensional feature vectors and the calculation of permission weights.

[0208] Specifically, S201 data acquisition and event stream construction involves: accessing data from business systems, network boundaries, databases, and terminals via multi-source acquisition adapters; standardizing fields and semantically annotating them according to a unified event model; performing time alignment and out-of-order processing based on a global time base and watermark control; generating a globally unique event identifier and a unified account identifier for each record; performing deduplication and integrity verification based on idempotent keys; performing field-level desensitization or tokenization on sensitive fields while retaining controlled restoration identifiers; and outputting a unified event stream with a streaming publishing mechanism that provides transaction commit and replay protection for subsequent calls.

[0209] S202 Context Maintenance and Binding: In the context management module, establish a context attribute namespace and attribute dictionary; uniformly register and assign context model version numbers to the attribute categories and encoding methods of account identifiers; aggregate multi-source data based on account identifiers to generate a context attribute set, and merge and label it according to conflict resolution rules and the separation of responsibilities constraint matrix; generate context snapshots at specific points in time and assign context snapshot identifiers, maintaining account identifiers. Mapping of context snapshot identifiers; when processing the event stream, retrieve the corresponding snapshot based on the event time and account identifier, and inject the snapshot identifier into the event record to form an event-context binding record.

[0210] S203 Multidimensional Feature Construction: Event and context binding records are sequenced by time windows of multiple granularities such as seconds, minutes, and hours, and session boundaries are adaptively determined based on behavior intervals; context features (one or more of account attribute tags, resource sensitivity identifiers, and access environment identifiers), time-series features (one or more of operation frequency within a time window, cross-window change rate, and working period markers), aggregation features (one or more of account or resource dimension counts, deduplication counts, and threshold comparison results), and derived features (one or more of the combination transformation based on the first three types of features, ratio calculations, or sliding statistics); after standardization, a multidimensional feature vector is formed for use by the adaptive risk assessment module.

[0211] S204 Parallel Inference and Fusion: Based on feature type, the multidimensional feature vector is divided into context feature sub-vectors, temporal feature sub-vectors, aggregate feature sub-vectors, and derived feature sub-vectors; the sub-vectors are input into at least two heterogeneous sub-models for parallel inference. The heterogeneous sub-models include at least two of the following: a first sub-model for context and aggregate evaluation, a second sub-model for temporal behavior evaluation, and a third sub-model for anomaly measurement, to obtain a basic risk score set; the fusion layer performs gating selection based on the context attribute set and determines the fusion weights, and performs weighted or stacked fusion to generate an initial risk score; the calibration unit maps the initial risk score to a normalized risk weight that takes values ​​within a preset range, and outputs a fusion configuration identifier and a context snapshot identifier.

[0212] S205 Policy Mapping and Instruction Orchestration: Load policy rule sets with version identifiers. The policy rule sets contain threshold ranges and action templates and support online adjustment; select target policy views based on context attribute sets and resource sensitivity, and match corresponding threshold ranges according to normalized risk weights to determine access control action sets and audit action sets; perform dependency and conflict checks on the action sets and perform trimming and sorting in conjunction with the separation of duties constraint matrix to generate access control instructions and audit instructions execution sequences carrying policy identifiers and rule set version numbers.

[0213] S206 Access Control Execution and Audit Retention: Access control commands are issued sequentially in the access control channel according to the execution sequence. An execution idempotent key consisting of a policy identifier, a global event identifier, and a sequence number is generated for each command, and the execution status is recorded. For secondary authentication, monitoring, and blocking commands, the authentication service is invoked, operation screen recording and behavior analysis are started, and session termination and account freezing are executed, respectively. Audit records are generated according to audit commands and written to the audit storage, and evidence chain identifiers are assigned and published together with account status changes.

[0214] S207 Permission Weight Assessment and Revocation Execution: The permission management module maintains the lifecycle and stage weights of the activation period, idle period, and revoke period; the weight calculation and decay unit calculates the current permission weight based on the initial weight, idle days, user activity, behavioral factors, and decay base λ; the scanning and threshold judgment unit compares the current permission weight with the revoke threshold according to the scanning frequency and generates permission revoke instructions or retention instructions; the revoke execution unit executes the revoke in the access control channel and writes it to the audit module; the parameter adaptive module dynamically adjusts the revoke threshold, scanning frequency, and λ according to permission sensitivity, permission usage rate, and business time period, and injects the effective parameters into the decision engine and permission management module.

[0215] S208 Result Feedback and Update: The audit data and account status change events are fed back to the feature construction and permission management module to update the feature generation criteria and subsequent permission weight calculations, and to record parameter versions and policy identifiers to support playback and consistency verification.

[0216] For example, in some cases, account A logged in from an unused device at 21:30 and accessed highly sensitive resources, downloading 60 data entries within 10 minutes and paging through the same URL 12 times, with the source IP address not belonging to the company's network segment.

[0217] 1) According to S201, the four types of adapters generate logs, session metadata, audit changes and terminal events respectively. After standardization, time alignment, deduplication and desensitization, they are output in a unified event stream.

[0218] 2) According to S202, the context management module writes A's job category, resource domain and access environment into the context attribute set. When the organizational adjustment takes effect, a context snapshot is generated and a snapshot identifier is assigned. The identifier is injected into the above events to form an event and context binding record.

[0219] 3) Based on S203, time-series features (operation frequency, cross-window change rate, and marking working hours as non-working hours) are generated for minute-level and hour-level windows. Aggregated features (download count 60, page count 12, and corresponding threshold comparison results are true) are generated for account and resource dimensions. At the same time, contextual features (job tags, high-sensitivity resource identifiers, unused devices, and non-company IPs) are extracted and combined to form derived features.

[0220] 4) According to S204, the evaluation module inputs the sub-vectors in parallel into the first sub-model and the second sub-model and combines them with the anomaly measurement of the third sub-model to obtain the basic risk score. The fusion layer performs gating and weighting based on high-sensitivity resources and uncommon equipment. The calibration unit outputs a normalized risk weight of 0.78 and attaches a fusion configuration identifier.

[0221] 5) According to S205, the decision engine loads the policy rule set V3, selects the policy view of "high-sensitivity resource access", matches 0.78 to the interval [0.6, 0.8), and parses the access control action set as monitoring and review, and the audit action set as recording access fingerprint and screen recording summary; after dependency and conflict verification, the execution sequence is generated and marked with policy identifier.

[0222] 6) In accordance with S206, the access control channel sequentially issues commands to start monitoring and manual review, generates execution idempotent keys for each command, and records the execution status; generates audit records containing account identifiers, global event identifiers, context snapshot identifiers, risk weights, policy identifiers, and screen recording indexes, writes them to the audit storage, assigns evidence chain identifiers, and publishes them together with possible account status changes.

[0223] 7) According to S207, the permission management module continuously evaluates the permission weight of A. If there are no calls in the following days, the weight is decayed according to λ during the scanning cycle and compared with the revoke threshold. A permission revoke instruction is triggered and the relevant authorization is revoked in the access control channel. The parameter adaptation module adjusts the revoke threshold and λ in a versioned manner according to the high sensitivity level and low utilization rate of the resource and puts it into effect.

[0224] 8) According to S208, the audit data and account status change event feedback trigger the feature construction module to update the context and derived features of A, and the permission management module uses the latest parameters to evaluate and make decisions in the next scanning cycle accordingly.

[0225] The above embodiments use unified event flow, context snapshot identification and multi-model gating fusion as core technical means to form a replayable and verifiable end-to-end process according to S201 to S208, ensuring that the method steps are connected with clear input and output relationships and maintain consistency with the modular system.

[0226] It should be understood that the sequence number of each step in the above method embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0227] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although the technical solutions of this application have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A background access control system with adaptive risk control, characterized in that, include: The data acquisition module is used to collect behavioral data and environmental data associated with the account, and convert the behavioral data and environmental data into a unified event stream; The context management module is used to maintain account identifiers and context attribute sets, and associate the context attribute sets with the event stream; The feature construction module is used to generate multi-dimensional feature vectors based on the event stream and the context attribute set; An adaptive risk assessment module is used to invoke at least two heterogeneous models to perform parallel inference on the multidimensional feature vector and generate normalized risk weights; The decision engine module is used to map the risk weights into access control instructions and audit instructions according to configurable threshold ranges and policy rules; An audit module is used to execute the access control instructions in the access control channel and record audit data according to the audit instructions; The permission management module is used to maintain the lifecycle status of permission objects, calculate permission weights based on decay parameters, and generate permission revoke instructions or retention instructions according to thresholds. The output of the feature construction module serves as the input of the adaptive risk assessment module. The audit data and account status changes generated by the audit module are fed back to the feature construction module and the permission management module for update calculations. The permission revoke instruction is executed by the audit module in the access control channel. The maintenance of the account identifier and context attribute set, and the association of the context attribute set with the event stream, includes: Establish a context attribute namespace and attribute dictionary, uniformly register the attribute categories and encoding methods of account identifiers, and assign context model version numbers; Based on account identifiers, multi-source data is aggregated and the aforementioned context attribute set is generated. The associated attributes are merged and labeled according to preset conflict resolution rules and responsibility separation constraint matrix. A context snapshot is generated for the set of context attributes at a given time point, and a context snapshot identifier is assigned. The mapping relationship between the account identifier and the context snapshot identifier is maintained. When processing the event stream, the corresponding context snapshot identifier is retrieved based on the event time and account identifier, and the context snapshot identifier is injected into the context field of the event record to form an event-context binding record for the feature construction module to call.

2. The system according to claim 1, characterized in that, The process of collecting behavioral and environmental data associated with accounts and converting this data into a unified event stream includes: The multi-source acquisition adapter standardizes data from business systems, network boundaries, databases, and terminals into a unified event pattern. The data is time-aligned and sequenced based on a global time base and water level control, and a globally unique event identifier and a unified account identifier are generated for each record. Deduplication and integrity checks are performed based on idempotent keys, and fields containing sensitive information are anonymized or tokenized at the field level while retaining controlled recovery identifiers. The processed structured event records are output as the unified event stream using a streaming publishing mechanism with transaction commit and replay protection, which is then called by the feature construction module.

3. The system according to claim 1, characterized in that, The generation of multidimensional feature vectors based on the event stream and the context attribute set includes: The event and context binding records are sequentially organized according to multi-granularity time windows, and the session boundaries are adaptively determined based on the behavior interval; Generate contextual features, including one or more of the following: account attribute tags, resource sensitivity identifiers, or access environment identifiers; Generate time-series features, including one or more of the following: operation frequency within a time window, rate of change across a window, or work period markers; Generate aggregate features, including one or more of the following: counts by account or resource dimension, deduplication counts, or threshold comparison results; Generate derived features, including one or more of the composite features obtained based on the context features, the temporal features, and the aggregated features.

4. The system according to claim 1, characterized in that, The step of invoking at least two heterogeneous models to perform parallel inference on the multidimensional feature vector and generating normalized risk weights includes: Based on feature type, the multidimensional feature vector is divided into context feature sub-vectors, temporal feature sub-vectors, aggregate feature sub-vectors, and derived feature vectors; All sub-vectors are input into at least two heterogeneous sub-models for parallel inference. The heterogeneous sub-models include at least two of the following: a first sub-model for context and aggregation evaluation, a second sub-model for time-series behavior evaluation, and a third sub-model for anomaly measurement, to obtain a basic risk score set. Based on the aforementioned set of context attributes, the sub-models participating in the fusion are selected by gating, and the fusion weights of each basic risk score are determined. Weighted or stacked fusion is then performed to generate an initial risk score. The initial risk score is mapped to a normalized risk weight that takes values ​​within a preset range, and the normalized risk weight is provided to the decision engine module.

5. The system according to claim 1, characterized in that, The step of mapping the risk weights to access control instructions and audit instructions according to configurable threshold ranges and policy rules includes: Load a policy rule set with version identifier, the policy rule set including threshold range and action template; The target policy view is selected based on the set of context attributes and resource sensitivity, and the corresponding threshold range is matched according to the risk weight to determine the set of access control actions and the set of audit actions. The set of access control actions and the set of audit actions are validated, and an execution sequence of access control instructions and audit instructions is generated, wherein the access control instructions include one or more of the following: allow, secondary authentication, monitoring, review, and blocking.

6. The system according to claim 5, characterized in that, The step of executing the access control instruction on the access control channel and recording audit data according to the audit instruction includes: Access control instructions are issued and executed one by one according to the execution sequence; For each access control instruction, generate an execution idempotent key consisting of a global event identifier, a policy identifier, and a sequence number, and submit it according to the instruction dependency relationship to obtain the execution status; For commands related to secondary authentication, monitoring, and blocking, the system respectively invokes the authentication service, initiates screen recording and behavior analysis, and performs session termination and account freezing operations. An audit record is generated according to the audit instruction, written into the audit storage and assigned an evidence chain identifier, and published together with the account status change.

7. The system according to claim 1, characterized in that, The access control module includes: The permission lifecycle management unit is used to configure activation period, idle period and recycling period for each permission, and store the stage weight; The weight calculation and decay unit is used to calculate the current permission weight based on the initial weight, idle days, user activity, behavioral factors, and decay base. The scanning and threshold judgment unit is used to compare the current permission weight with the revoke threshold at a preset scanning frequency, and generate a permission revoke instruction or a retention instruction. The revocation execution unit is used to notify the corresponding user and revoke permissions according to the permission revocation instruction, and write the revocation result into the audit module.

8. The system according to claim 7, characterized in that, The system also includes: The parameter adaptive module is used to dynamically adjust the retrieval threshold, scanning frequency and attenuation base according to permission sensitivity, permission usage rate and business period, and provide the adjusted parameters to the decision engine module and the permission management module.

9. A background access control method based on the adaptive risk control of the system as described in any one of claims 1 to 8, characterized in that, include: Collect behavioral and environmental data associated with the account, and convert the behavioral and environmental data into a unified event stream; Maintain an account identifier and context attribute set, and associate the context attribute set with the event stream to form an event-context binding record; A multidimensional feature vector is generated based on the event and context binding record. The multidimensional feature vector includes one or more of the following: context features, temporal features, aggregate features, and derived features. At least two heterogeneous models are invoked to perform parallel inference on the multidimensional feature vectors, and normalized risk weights are generated by fusion. Based on configurable threshold ranges and policy rules, the risk weights are mapped to access control instructions and audit instructions; The access control instructions are issued and executed through the access control channel, and audit data is recorded according to the audit instructions. The permission weight is calculated based on the attenuation parameter, and a permission revoke instruction or retention instruction is generated according to the threshold. The permission revoke instruction is then executed in the access control channel. The audit data and account status change feedback are used to update the generation of the multidimensional feature vector and the calculation of the permission weight.

Images