Api interface permission control system and control method thereof

Abstract

The application relates to the technical field of API authority management and control, and discloses an API interface authority control system, which comprises an API gateway layer, an authentication center service, a trust evaluation engine, a dynamic security domain management module, an attack detection module, a cache and data synchronization module and an authority management background; the API gateway layer serves as a unified inlet for south-north traffic, deploys a global authentication filter, is used for receiving a client access request, and performs whitelist verification, token validity verification and authority preliminary judgment. The API interface authority control system and the control method thereof, the API gateway layer and the authentication center service adopt a separated deployment architecture for authentication, cooperate with the trust evaluation engine to build a multi-dimensional trust evaluation system, dynamically calculate the trust degree of each interface request in combination with an integrated neural network model, and then execute rapid authentication through a multi-level cache mechanism built by the cache and data synchronization module, so that the security requirements of zero-trust continuous verification are met, and the authentication performance bottleneck in a high-concurrency scene is effectively relieved.

Description

Technical Field

[0001] This invention relates to the field of API permission management technology, specifically to an API interface permission control system and its control method. Background Technology

[0002] In a microservices architecture, enterprise business systems are split into multiple independent microservices. All external accesses need to go through a unified entry point, the API gateway. The core function of API interface permission control is to determine whether a user's identity is legitimate, whether they can access the corresponding interface, and whether they can perform the corresponding operation.

[0003] Currently, the mainstream API permission control solutions in the industry are mainly divided into three categories. The first category is the static role-based permission solution, which assigns different roles such as administrator and ordinary user to users, and uses stateless tokens to complete identity verification. As long as the system verifies that the token is valid and the role matches, access is allowed. The second category is the service mesh full encryption solution, which deploys a proxy program next to each microservice to perform full two-way certificate verification and data encryption on all internal calls between services, and uniformly adopts the strongest protection standard. The third category is the gateway overlay rule firewall solution, which relies on fixed regular expression rules to match attack characteristics at the gateway layer and intercept common injection-type network attacks.

[0004] However, existing API access control technologies still have the following problems in practical applications:

[0005] 1. The authorization mechanism is fixed and rigid, relying solely on static judgment based on user identity and lacking dynamic trust assessment based on request context. It cannot cope with the risk of abnormal unauthorized access after account theft, and centralized authentication is prone to performance bottlenecks in high-concurrency scenarios.

[0006] Second, the isolation granularity between microservices is too simple, and the protection strength cannot be dynamically adjusted according to the real-time threat level. Full strong verification will consume too many system resources, while reducing the protection strength will bring security risks. It is difficult to balance security capabilities and resource consumption.

[0007] Third, the modules of access control, attack detection, and transmission encryption are independent of each other and cannot form a coordinated protection system. Security policies cannot be automatically arranged according to the real-time operation of the system, resulting in low overall protection efficiency.

[0008] Therefore, an API interface permission control system and its control method are proposed. Summary of the Invention

[0009] (a) Technical problems to be solved

[0010] To address the shortcomings of existing technologies, this invention provides an API interface permission control system and its control method. It possesses advantages such as efficient authentication through dynamic trust assessment combined with multi-level caching, dynamic security domain partitioning to balance security protection and resource consumption, and multi-module collaborative linkage to construct a full-link protection system. It solves the problems of existing API interface permission control technologies, including static and rigid authorization mechanisms, lack of dynamic trust assessment based on request context leading to high risks of abnormal privilege escalation, performance bottlenecks in authentication under high concurrency scenarios, single granularity of isolation between microservices making it difficult to balance protection strength and system resource overhead, and the independent nature of permission control, attack detection, and transmission encryption modules, resulting in low overall protection efficiency due to the inability to form collaborative protection.

[0011] (II) Technical Solution

[0012] To achieve the goals of efficient authentication through dynamic trust assessment combined with multi-level caching, dynamic security domain partitioning to balance security protection and resource consumption, and multi-module collaborative linkage to build a full-link protection system, this invention provides the following technical solution: an API interface permission control system, including an API gateway layer, an authentication center service, a trust assessment engine, a dynamic security domain management module, an attack detection module, a caching and data synchronization module, and a permission management backend;

[0013] The API gateway layer serves as a unified entry point for north-south traffic, deploying a global authentication filter to receive client access requests, perform whitelist verification, token validity verification, and initial permission assessment, and forward compliant requests to the target microservice. The API gateway layer shares a control plane with the micro-agents in the service mesh, with the micro-agents deployed on each microservice side to manage east-west traffic between microservices.

[0014] The authentication center service is deployed independently and is used to receive user login requests, verify user identity credentials, generate stateful access tokens and refresh tokens, synchronously complete session key negotiation and lifecycle management, write token and key information into a persistent database and synchronize it to the cache and data synchronization module.

[0015] The trust assessment engine is connected to the API gateway layer and the authentication center service respectively. It is used to build a multi-dimensional trust assessment index system, calculate the trust level of the request based on the integrated neural network model, and output it to the authorization execution unit of the API gateway layer.

[0016] The dynamic security domain management module is connected to the service registry center and is used to collect service topology, call chain and security threat level data of the microservice cluster. It performs security domain division based on a multi-objective optimization algorithm, generates isolation policies for weak authentication within domains and strong authentication between domains, and distributes them to each micro-agent for execution. A quantitative two-way feedback mechanism is set up between the dynamic security domain management module and the trust assessment engine. The security domain threat status dynamically corrects the trust assessment index, and the trust assessment results inversely optimize the security domain division weight.

[0017] The attack detection module is deployed in the request preprocessing link of the API gateway layer. It is used to convert the request text into a word embedding matrix based on pre-trained word vectors, extract attack features through deep networks, and output classification results. The attack detection module is linked with the trust evaluation engine to dynamically adjust the detection and classification threshold according to the trust level of the request.

[0018] The caching and data synchronization module adopts a multi-level caching architecture. It captures database change logs based on the change data capture component, asynchronously synchronizes permission data, token status and security domain policies through message queues, and ensures eventual data consistency by combining a version number mechanism.

[0019] The permission management backend is connected to the authentication center service, the dynamic security domain management module, and the attack detection module, respectively, and is used to perform user management, role management, service permission configuration, security domain policy adjustment, and attack detection rule update operations.

[0020] Preferably, the trust assessment engine includes an indicator preprocessing submodule, an integrated assessment submodule, and a trust constraint authorization submodule;

[0021] The indicator preprocessing submodule quantifies qualitative indicators using a hierarchical assignment method and maps quantitative indicators to the [0,1] interval using an extremum normalization method. The integrated evaluation submodule consists of multiple weak learners cascaded with one strong learner. The output of the weak learner is concatenated with the original feature vector and then input into the strong learner to output the final trust value. The trust constraint authorization submodule sets a minimum trust threshold for each service interface and allows access when the request simultaneously meets the role permissions and the trust threshold.

[0022] The attack detection module's classification threshold is calculated in real time based on the user's cached historical trust level, and is adjusted in conjunction with the global security posture baseline to achieve a dynamic balance between security protection and business availability.

[0023] Preferably, the dynamic security domain management module includes a domain partitioning calculation submodule, a domain policy execution submodule, and a service status awareness submodule;

[0024] The domain partitioning calculation submodule constructs a security performance evaluation function and a resource consumption evaluation function with normalization constraints as optimization objectives, and uses a multi-objective evolutionary algorithm to solve for the optimal partitioning scheme. The solution with the best security performance is selected from the Pareto optimal solution set as the partitioning result. The domain policy execution submodule distributes the partitioning result to each micro-agent. Intra-domain communication only performs mTLS certificate verification, while cross-domain communication calls the trust evaluation engine to perform a complete trust evaluation and authorization verification.

[0025] The quantitative two-way feedback mechanism includes: in the positive feedback, the dynamic security domain management module generates a correction coefficient based on the average threat level of the domain, and dynamically corrects the service sensitivity level index in the trust assessment; in the negative feedback, the trust assessment engine calculates the average trust level, the proportion of unauthorized requests and the proportion of attack interception for each security domain, and calculates the service threat weight factor as the dynamic weight for the next round of security domain division.

[0026] Preferably, the attack detection module includes a pre-rule engine submodule, a word embedding submodule, a feature extraction submodule, and a classification output submodule;

[0027] The pre-rule engine submodule loads emergency rule patches and deploys them at the front end of the deep learning detection link, directly intercepting when a rule is hit; the word embedding submodule adopts a character-sub-word hybrid word segmentation mechanism and uses a dynamic weight truncation strategy for high-incidence attack areas for ultra-long requests; the feature extraction submodule extracts local features through convolutional networks and models temporal dependencies through recurrent neural networks; the classification output submodule uses a loss function that adapts to dynamic threshold adjustment for model training.

[0028] Preferably, the caching and data synchronization module includes a three-level caching unit, a change capture unit, a message queue unit, and a data synchronization service unit;

[0029] The three-level caching unit includes a gateway local cache, a distributed cache, and persistent database storage; the change capture unit listens to the database change log, captures change events, and increments the version number; the message queue unit receives change events and stores them in partitions according to user dimensions; the data synchronization service unit consumes change messages, distinguishes between ordinary permission changes and core forced changes, performs differentiated synchronization, updates the cache in real time for online users, temporarily stores changes for offline users in a queue to be synchronized, and triggers compensation synchronization by comparing version numbers when a user comes online;

[0030] The system is configured with a fault tolerance and degradation module. When the cache cluster fails, the gateway retrieves the session key archive from the database based on the user identifier associated with the token and rebuilds the cache.

[0031] An API interface access control method includes the following steps:

[0032] S1. User authentication: The client sends a login request to the API gateway layer, which forwards it to the authentication center service to verify the identity, generate an access token and a refresh token, complete the session key negotiation, write the token and key information to the database and synchronize it to the cache;

[0033] S2. Access Request Verification: The client sends a business access request with a token. The API gateway layer verifies the validity of the whitelist and the token. If the token is invalid, the request is rejected.

[0034] S3. Pre-processing rules and attack detection: Requests are matched with rule patches by the pre-processing rule engine, and if a match is found, the request is blocked; for requests that do not match, the attack detection module sets a classification threshold based on cache history trust and global security posture, performs word segmentation and feature extraction on the request text, and uses a deep model to determine whether it is an attack request.

[0035] S4. Trust Assessment and Authorization: The API gateway layer extracts the request subject attributes, behavioral characteristics, and target service information, sends them to the trust assessment engine to calculate the real-time trust level and update the cache baseline; and performs authorization judgment by combining role permissions and trust level thresholds.

[0036] S5. East-West Traffic Control: When a call is initiated between microservices, the micro-proxy determines whether the two parties to the call belong to the same security domain; within the same domain, mTLS certificate verification is performed before forwarding; when a call is made across domains, the trust assessment engine completes trust assessment and authorization verification before forwarding.

[0037] S6. Seamless Token Refresh: After the access token expires, the client automatically applies for a new token using the refresh token. After the authentication center verifies the token, it issues a new dual token and a new session key, and invalidates the old token and old key.

[0038] Preferably, the trust assessment in step S4 includes: quantifying and normalizing the trust assessment indicators, obtaining the threat level correction coefficient of the security domain to which the target service belongs, correcting the service sensitivity level indicator, and forming an input feature vector; inputting the input feature vector into multiple weak learners to obtain multiple preliminary trust outputs; concatenating the multiple preliminary trust outputs with the original input feature vector to form a fused feature vector, inputting it into a strong learner to calculate the real-time trust; querying the minimum trust threshold corresponding to the target service, and allowing access if the user has role permissions and the trust level is greater than or equal to the threshold, otherwise denying access.

[0039] The attack detection in step S3 includes: splitting and filtering the request URL and request body; performing dynamic weight truncation of high-incidence areas for excessively long requests; performing character-level word segmentation on the URL path and request parameter names; performing sub-word-level word segmentation on the long parameter values ​​of the request body to obtain a fixed-length sequence; calling a pre-trained word vector model to convert the sequence into a word embedding matrix; obtaining a one-dimensional feature vector after feature extraction from the word embedding matrix; combining the global security posture baseline and the dynamic classification threshold corresponding to the cached historical trust level to determine whether the request is an attack based on the attack probability; and using a default medium trust level as the initial threshold when the first request has no historical trust level.

[0040] Preferably, the dynamic partitioning of security domains in step S5 includes: collecting the basic threat level of all microservices at the current moment and the call chain data of the previous cycle, correcting the threat level of each service by combining the threat weight factor fed back by the trust assessment engine, and constructing a weighted undirected network topology graph; generating an initial partitioning population based on the similarity of security threats between services through a label propagation algorithm; iteratively optimizing using a multi-objective evolutionary algorithm, with the optimization objectives including a security performance evaluation function and a resource consumption evaluation function with normalization constraints, and selecting the partitioning scheme with the best security performance from the Pareto optimal solution set after iteration; generating a security domain isolation policy and setting a smooth transition period before distributing it to each micro-agent for execution; and adopting a dynamic update mechanism that combines periodic full partitioning with triggered incremental adjustment.

[0041] A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the API interface access control method.

[0042] (III) Beneficial Effects

[0043] Compared with the prior art, the present invention provides an API interface permission control system and its control method, which has the following beneficial effects:

[0044] 1. The API interface permission control system and its control method adopt an authentication separation deployment architecture for the API gateway layer and the authentication center service. It is equipped with a trust evaluation engine to build a multi-dimensional trust evaluation system. It combines an integrated neural network model to dynamically calculate the trust level of each interface request. Then, it uses a multi-level caching mechanism built through caching and data synchronization modules to perform fast authentication. This not only meets the security requirements of zero-trust continuous verification, but also effectively alleviates the authentication performance bottleneck in high-concurrency scenarios.

[0045] 2. The API interface permission control system and its control method: The dynamic security domain management module collects service topology and operational threat data of the microservice cluster, completes the dynamic division of security domains through a multi-objective optimization algorithm, and builds a quantitative two-way feedback mechanism with the trust assessment engine. It adjusts the trust assessment standard according to the threat status within the domain, optimizes the domain division weight according to the trust data, realizes differentiated isolation verification, and balances security protection capabilities and system resource consumption.

[0046] 3. The API interface permission control system and its control method achieve dynamic linkage between the attack detection module and the trust assessment engine. The sensitivity of attack detection is adjusted in real time according to the trust level of the request. A two-level detection architecture is built by combining the front-end rule engine and the deep learning model. It is equipped with the forward security encryption mechanism of the authentication center service and the fault return fallback of the cache and data synchronization module to form a multi-layer collaborative protection system that fully covers the security protection needs of the entire interface access link. Attached Figure Description

[0047] Figure 1 This is a schematic diagram of the overall architecture of the API interface permission control system of the present invention;

[0048] Figure 2 This is a flowchart illustrating the internal structure and bidirectional feedback processing of the trust assessment engine of the present invention.

[0049] Figure 3 This is a flowchart illustrating the execution and feedback process of the dynamic security domain partitioning algorithm of the present invention.

[0050] Figure 4 This is a schematic diagram illustrating the network structure and dynamic threshold linkage of the two-level attack detection model of the present invention;

[0051] Figure 5 This is a flowchart illustrating the overall steps of the API interface permission control method of the present invention. Detailed Implementation

[0052] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments and accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0053] Example 1:

[0054] This embodiment elaborates on the overall deployment architecture of the system of the present invention, the connection relationship and collaborative logic of each core module, and explains the system's cold start initialization process, high availability degradation and extreme disaster recovery strategies, and backend management capabilities.

[0055] This system is built on the Spring Cloud microservice ecosystem and is divided into four layers from top to bottom: access layer, control layer, service layer, and data layer.

[0056] The access layer consists of an API gateway and a client. The API gateway is implemented using Spring Cloud Gateway and serves as the sole entry point for all north-south traffic. It has a built-in global authentication filter with a priority of -1 to ensure that security checks are completed before requests enter the routing logic.

[0057] The control layer consists of four independent microservices: authentication center service, trust assessment engine, dynamic security domain management module, and attack detection module. Each service interacts through a RESTful interface to achieve functional decoupling and independent deployment, while modules collaborate through linkage interfaces.

[0058] The service layer is a cluster of business microservices. Envoy micro-agents are deployed next to each business microservice. All micro-agents share the security policies of the control layer and form the data plane of the service mesh, which is responsible for managing east-west traffic between microservices.

[0059] The data layer includes a persistent MySQL database, a Redis cache cluster, a Kafka message queue, and a Nacos service registry, providing data storage and communication support for upper-layer modules.

[0060] System cold start initialization process:

[0061] Step 1: When the system is deployed for the first time or restarted for the entire system, the preset baseline security policy is loaded first, including the default trust assessment index weights, initial security domain division rules, basic attack detection rules and general permission templates;

[0062] Step 2: The authentication center generates the initial key pair and administrator account for the system; the trust assessment engine loads the pre-trained basic model weights and completes the initialization using general baseline data; the dynamic security domain management module generates the initial security domain division scheme based on the initial service list of the service registry and the preset baseline threat level, and distributes it to all micro-agents.

[0063] Step 3: The cache layer performs a full data load, synchronizing basic permissions and policy data to Redis and the gateway's local cache, completing system initialization.

[0064] During operation, iterative optimizations are made based on real business data to achieve a smooth transition from cold start to adaptive protection.

[0065] When the system is running, the north-south traffic processing chain is as follows: the client encrypts the request body using the negotiated session key and sends the request to the API gateway; the gateway sequentially performs five security checks: whitelist verification, token validity verification, pre-rule interception, deep learning attack detection, and dynamic trust assessment authorization. After all checks are passed, the API gateway forwards the request to the target business microservice through the mTLS channel.

[0066] By adopting a processing order of detecting attacks first and then granting authorization, malicious attack traffic can be filtered in advance, preventing malicious requests from consuming the computing resources of the trust assessment engine and improving the overall effective throughput of the system.

[0067] The processing chain for east-west traffic is as follows: When the source microservice initiates a call request, the side-by-side micro-proxy first queries the local cached security domain partitioning table to determine whether the target microservice belongs to the same security domain as itself; for same-domain calls, only mTLS two-way certificate verification is performed, and a connection is established directly after the verification is successful; for cross-domain calls, the request information is reported to the trust assessment engine, and a communication connection is established only after a complete trust assessment and authorization verification is completed.

[0068] The token refresh and seamless renewal process is embedded in the interaction logic between the authentication center and the gateway:

[0069] The access token issued by the certification center is valid for 2 hours, and the refresh token is valid for 7 days. The refresh token supports single rotation.

[0070] If the client receives a 401 token expired response from the gateway when making a request, it automatically calls the token refresh interface of the authentication center along with a refresh token. The authentication center verifies the validity of the refresh token and whether it is on the revocation blacklist. If the verification is successful, it generates a new access token and a new refresh token, and simultaneously generates a new session key. At the same time, it invalidates the old refresh token and the old session key, and updates the Redis cache and the gateway's local cache. The client updates the dual tokens and the corresponding session key locally, and subsequent requests use the new access token. The user is completely unaware of this process.

[0071] When key negotiation fails, a retry mechanism is automatically executed. If the failure occurs three times consecutively, an identity re-authentication process is triggered to ensure the reliability of the encrypted link.

[0072] In scenarios such as user logout and password change, the system will add the corresponding refresh token to the Redis blacklist to force it to become invalid.

[0073] The system is configured with a complete fault tolerance, degradation, and automatic recovery mechanism, covering extreme cache failure scenarios to ensure the availability of core business operations.

[0074] When the trust assessment engine is unavailable, the gateway automatically downgrades to static RBAC authorization mode, with the trust level set to the user's historical 7-day average trust value by default. At the same time, all authorization logs are recorded, and an alarm is triggered to notify the administrator. After the service is restored, it automatically switches back to the full trust assessment mode, and the trust assessment data during the downgrade period is synchronously supplemented to ensure policy continuity.

[0075] When the Redis cache cluster crashes or all session keys are lost, the gateway prioritizes using the hot permissions and key data from the local memory cache. If no corresponding data is available locally, the gateway queries the MySQL database for the session key archive based on the user ID associated with the token. The archived key is encrypted and stored using the system master key. After verification, the key is decrypted and the local cache and Redis cache are rebuilt to continue processing requests. If no valid key is available in the database, the gateway directly connects to the database to perform basic authentication, automatically lowering the interface rate limit to avoid database overload. Only when the database also lacks a corresponding key record will the user be prompted to log in and authenticate again. This mechanism can ensure uninterrupted service for the vast majority of online users in the event of a full cache failure, significantly reducing the impact of extreme failures on business operations.

[0076] When Kafka message backlog or CDC synchronization anomalies occur, core permission changes will use a dual-write degradation mode with database and cache to ensure real-time effectiveness; non-core changes will be synchronized after the backlog is cleared, without affecting eventual consistency.

[0077] When the attack detection module fails, it automatically enters the bypass detection mode, requests normal passage, and mirrors the traffic to the detection module for post-event backtracking, without affecting business availability, and triggers an alarm.

[0078] The access control backend is developed using the Vue frontend framework, providing a visual management interface that allows administrators to configure user accounts, role permissions, service interfaces, security domain policies, and attack detection rules. The attack detection management supports configuring dynamic threshold mapping parameters, global security posture baselines, custom attack blacklists and whitelists, issuing emergency rule patches, marking false positives and false negatives, and switching model versions. All configuration changes are written to the MySQL database and automatically synchronized to the cache and each execution node through the CDC data synchronization mechanism, taking effect without restarting the service.

[0079] Example 2:

[0080] This embodiment details the internal structure, indicator system, model implementation method, and bidirectional feedback quantification mechanism of the trust assessment engine with the security domain module, and elaborates on the label verification and quality control process for model updates.

[0081] The trust assessment indicator system comprises 3 main categories and 12 secondary indicators, as detailed below:

[0082] The first category is trust in the access request subject, which includes three qualitative indicators: operating system, communication protocol, and client version.

[0083] The second category is access request behavior trust, which includes seven indicators: device matching degree, user activity status, access frequency per unit time, number of unauthorized accesses per unit time, number of authentication failures per unit time, access time deviation, and access IP deviation. Among them, user activity status is a qualitative indicator, and the rest are quantitative indicators.

[0084] The third category is service trust, which includes two qualitative indicators: service sensitivity level and service operation status.

[0085] In the indicator preprocessing stage, qualitative indicators are quantified using a tiered assignment method: the operating system is assigned a value based on the number of publicly disclosed CVE vulnerabilities; encrypted communication protocols are assigned higher values, while unencrypted ones are assigned lower values; client versions are quantified using a Gaussian distribution; active users are assigned higher values, while inactive users are assigned lower values; service sensitivity levels and operating status are both divided into three levels, corresponding to different assignments; quantitative indicators are mapped to the 0-1 range using the extreme value normalization method, with device matching degree, time deviation degree, and IP deviation degree using the linear proportional method, and access frequency, number of unauthorized accesses, and number of authentication failures using the extreme value method.

[0086] Meanwhile, the service sensitivity level indicator receives positive vectorized feedback from the dynamic security domain management module: after the security domain is divided, the average threat level of each domain is calculated, and a correction coefficient is calculated, which can be adjusted according to the business security level; the original sensitivity level value of the target service is multiplied by the correction coefficient, and the result is truncated to the range of 0 to 1 to obtain the corrected service sensitivity level indicator; for services in high-threat domains, the service sensitivity level is automatically increased, and the minimum trust threshold of the corresponding interface is increased synchronously to strengthen the protection strength of high-risk areas.

[0087] The training process of the AdaBoost-BP ensemble model is as follows:

[0088] Step 1. Initialize the training set weights; all training samples should have the same initial weights.

[0089] Step 2. Train the k-th weak learner. Use the weighted training set to train the BP neural network, obtain the output of the weak learner, and calculate the total error of the weak learner.

[0090] Step 3. Calculate the weight coefficients of the weak learner, update the sample weights according to the error, and the samples with larger errors have higher weights in the next round;

[0091] Step 4. Repeat the above steps until the preset number of weak learners have been trained;

[0092] Step 5. Concatenate the output values ​​of all weak learners with the original input feature vector to form a fused feature vector, which is then used as the input to the strong learner to train the strong learner BP neural network. By fusing the original features with the output of the weak learners, the feature reuse capability and nonlinear fitting effect of the model are enhanced, resulting in the final confidence output model.

[0093] As a preferred implementation, the number of weak learners is set to 5. Ablation experiments have verified that when the number of weak learners is 5, the accuracy of model trust assessment reaches a high level. Further increasing the number of weak learners results in limited improvement in accuracy, but significantly increases the time consumed for single-sample inference. Therefore, 5 is selected as the optimal balance point between performance and effectiveness.

[0094] A single BP neural network weak learner contains a corresponding number of input layer neurons, hidden layer neurons, and output layer neurons. The hidden layer uses the tanh activation function, and the output layer uses the sigmoid activation function. The number of hidden layer neurons is calculated based on an empirical formula. Combined with multiple sets of comparative experiments, it is verified that the model's fitting ability and generalization ability reach the optimal number of neurons, with no obvious overfitting or underfitting.

[0095] Using the Sigmoid activation function can strictly constrain the output value to the range of 0 to 1, which perfectly matches the probabilistic physical meaning of the confidence level, ensuring that the confidence level has a clear upper and lower bound.

[0096] The execution logic of the TCRBAC authorization mechanism is as follows: each service interface is pre-configured with a role permission list and a minimum trust threshold; during authorization, the user's role is first checked to see if it is in the permission list. If the role does not match, the request is directly rejected; after the role matches, the trust level of the current request is compared with the minimum trust threshold. If the trust level meets the threshold, access is allowed; otherwise, access is rejected and an unauthorized access log is recorded.

[0097] Trust assessment results are synchronously updated to the user's cached trust baseline, which is used for dynamic threshold linkage with the attack detection module.

[0098] The classification threshold is calculated using a power function mapping. Under the default parameters, the curve is convex downwards. The threshold decreases faster in the low trust interval and rises more gradually in the high trust interval, balancing security protection and performance overhead.

[0099] During the attack detection phase, the historical trust score in the cache is read to calculate the threshold. The real-time trust score calculated for this request is updated in the cache after authorization and used for threshold adjustment for the next request. When there is no historical trust score for the first request, the default medium trust score is used as the initial threshold.

[0100] Simultaneously, a global security posture baseline adjustment is introduced: when the number of attack events across the entire network exceeds the preset baseline within a unit of time, the threshold is shifted downwards to improve detection sensitivity across the entire domain; when the number of requests during peak business periods exceeds the preset threshold, the threshold is shifted upwards to ensure the availability of core businesses; when a single user continuously triggers low-trust judgments, the user is automatically added to the key monitoring list, the classification threshold is further lowered, and full feature verification is enabled.

[0101] The model employs a weekly incremental fine-tuning mechanism for continuous iteration, coupled with a rigorous sample quality control process: each week, normal access, unauthorized access interception, and abnormal behavior data from the previous week are extracted, along with false positives and missed positives marked by the administrator; all corrected samples undergo dual review by automated quality verification and manual verification to exclude incorrectly labeled, duplicate, and adversarial contamination samples, preventing malicious labeling from poisoning the model; verified samples are used for incremental training of the weak learner weights of the AdaBoost-BP model, and after training, they are released to some nodes for verification in a gray-scale manner, and if no anomalies are found, they are deployed to the entire network; multiple historical versions are also retained, supporting one-click rollback to adapt to slow changes in user behavior and address data drift issues.

[0102] Example 3:

[0103] This embodiment elaborates on the system modeling method of dynamic security domain, multi-objective optimization algorithm with normalization constraints, dynamic adjustment mechanism, and quantitative bidirectional feedback logic with trust assessment engine.

[0104] First, a system model of the microservice cluster is performed: the microservice cluster is abstracted as a weighted undirected connected graph, where the vertices are sets of microservice nodes, and each node contains a security threat level attribute; the edge weight matrix represents the degree of communication between services, which is calculated by combining the number of service calls and the proportion of calls on the same link.

[0105] Construct two optimization objective functions with normalization constraints to balance their numerical scales and avoid single-objective dominance in the optimization:

[0106] Step 1. The security performance evaluation function is normalized by dividing by the total variance of the entire network and the number of domains, with a fixed value range between -1 and 0. According to the variance decomposition theorem, the normalized value directly reflects the proportion of inter-domain variance to the total variance. The smaller the value, the greater the difference in threats between domains, the higher the homogeneity of service threats within the same domain, the higher the efficiency of security control, and the more significant the protection benefits of strong inter-domain verification. In multi-objective optimization, minimizing this function is equivalent to maximizing the difference in threats between domains, which is consistent with the business design logic.

[0107] Step 2. Resource consumption evaluation function: Combines the resource consumption of strong inter-domain authentication and weak intra-domain authentication, and calculates the total consumption based on the degree of inter-service communication tightness. Verification in the actual test environment shows that the resource consumption of strong inter-domain authentication is much higher than that of weak intra-domain authentication. This parameter is configurable and can be dynamically adjusted according to the hardware performance and network latency of the deployment environment. The smaller the value, the lower the overall network resource consumption of the system.

[0108] The constraints for security domain partitioning are: the number of security domains is greater than 1 and less than the total number of services; each security domain contains at least 1 service; and any two security domains have no overlap.

[0109] The execution steps of the L-NSGA algorithm are as follows:

[0110] Step 1. Population Initialization: Construct an adjacency matrix based on service security threat similarity, generate an initial population through a label propagation algorithm, and perform reordering character encoding standardization on each individual to eliminate the identification differences of isomorphic solutions; during the cold start phase, generate an initial population based on the baseline threat level.

[0111] Step 2. Evolutionary operation: A bidirectional crossover operator is used to perform the crossover operation, and a Logistic adaptive mutation rate is used to perform the mutation operation. The mutation rate is gradually increased with population iteration.

[0112] Step 3. Population selection: Merge the parent and offspring into a temporary population, perform fast non-dominated sorting and crowding calculation, and select the top N individuals to form the next generation population;

[0113] Step 4. Iteration Termination: Stop after reaching the set maximum number of iterations, and output the Pareto optimal solution set;

[0114] Step 5. Solution selection: Select the individual with the best security performance from the optimal solution set as the final security domain partitioning scheme.

[0115] The security domain adopts a dynamic update mechanism that combines periodic full partitioning with triggered incremental adjustments.

[0116] Regular periodic adjustments: A full security domain re-partition is performed every 24 hours, and the optimal partitioning scheme is calculated based on the service calls and threat data throughout the day to ensure that the policy matches the business status;

[0117] Triggered incremental adjustment: When three scenarios occur, such as service going offline or going online, attack events in a single domain exceeding a set threshold, or service call link topology changes exceeding a certain proportion, incremental re-division is automatically triggered. Only the domain of the affected service is adjusted, without the need for full calculation, thus improving response speed.

[0118] Transitional handling: After the new domain policy is issued, a 5-minute transition period is set. During the transition period, the old and new policies run in parallel. Existing connections maintain the original domain policy, while newly established connections adopt the new domain policy to avoid service connection interruption and achieve a smooth switch.

[0119] After the isolation policy is issued, the micro-proxy caches the domain partitioning table locally; intra-domain communication only verifies the validity of the mTLS certificate, and the communication latency is the same as that of ordinary mTLS; cross-domain communication requires reporting the request metadata to the trust assessment engine to complete the trust assessment and authorization verification of all indicators, and a connection can be established only after the verification is passed.

[0120] The trust assessment engine employs a reverse quantitative feedback mechanism: it statistically analyzes three indicators within each security domain—average trust level, percentage of unauthorized requests, and percentage of attack interceptions—and calculates a threat weight factor for each service through weighted summation. These weights can be adjusted based on business scenarios. The threat weight factor is periodically synchronized to the dynamic security domain management module, replacing the base threat level value in the next round of classification. Services with high-incidence threat events automatically have their threat weight increased, making them more likely to be classified into high-security-level domains during the classification process, thus achieving closed-loop optimization of security protection.

[0121] Example 4:

[0122] This embodiment details the two-level attack detection architecture, rule patching mechanism, deep learning model details, ultra-long request truncation strategy, dynamic threshold and global situation linkage mechanism, and the complete two-stage encryption process of ECDHE forward security.

[0123] The attack detection adopts a two-level detection architecture of front-end rule engine plus CNN-LSTM deep learning, which balances emergency response speed and unknown attack identification capability.

[0124] The front-end rule engine submodule is deployed at the very front of the detection chain to load emergency rule patches. The rule forms include three categories: regular expressions, feature keywords, and special character combinations. It is mainly used to deal with sudden new attacks and can be quickly deployed to intercept without waiting for model iteration and training.

[0125] Requests that match the rules are directly marked as attacks and blocked, preventing them from entering subsequent deep learning detection and reducing the engine's computational burden; requests that do not match the rules continue to enter deep learning model detection; rule patches can be distributed in real time through the permission management backend, take effect with hot updates, and have a higher priority than model detection results.

[0126] Deep learning detection employs a character-sub-word hybrid segmentation text classification scheme. The model input is a text sequence concatenated with the request URL and request body. The segmentation mechanism is as follows:

[0127] Character-level word segmentation is used for URL paths and request parameter names to accurately capture character deformation features of injection attacks; BPE sub-word-level word segmentation is used for long parameter values ​​in JSON request bodies to improve the information density and semantic capture capability of long attack payloads.

[0128] The two word segmentation results are concatenated and input into the word embedding layer, balancing detection accuracy and adaptability to long texts.

[0129] The input sequence is set to a fixed length, which is based on statistics from real business scenarios and can cover most regular API requests. For excessively long requests, a dynamic weight truncation strategy is adopted for high-incidence attack areas: priority is given to retaining content from high-incidence attack locations such as the complete URL path, core parameter names, parameter value prefixes, and areas with dense special symbols, while low-risk redundant content at the end is truncated. At the same time, excessively long requests automatically trigger increased detection sensitivity and lower classification thresholds to avoid missed detections due to the loss of attack features caused by truncation, thus balancing performance and security.

[0130] The model training uses a multi-source dataset to construct the training set, which includes multiple types of publicly available attack datasets and API attack sample sets from real business scenarios of enterprises, covering a variety of modern web attack types; at the same time, data augmentation techniques such as payload obfuscation and mutation are used to expand the samples and improve the model's generalization ability to mutated attacks.

[0131] The Word2vec word vector model is pre-trained based on the above dataset, covering all printable characters and common subwords that may appear in URLs and request bodies.

[0132] The CNN-LSTM model's network structure consists of an input layer, an embedding layer, a random dropout layer, a one-dimensional convolutional layer, a one-dimensional max pooling layer, a two-layer LSTM layer, a fully connected layer, and an output layer. Multiple sets of comparative experiments have verified that the corresponding configuration extracts the most local attack features and achieves the highest overall model performance.

[0133] The model training uses the FocalLoss loss function, which reduces the weight of easily classified samples and increases the attention to difficult-to-distinguish samples, thus alleviating the imbalance between positive and negative samples. This ensures that the probability value output by the model still has good discriminative power in the low confidence interval, adapts to the needs of dynamic threshold adjustment, and avoids a non-linear surge in the false alarm rate after the threshold is lowered.

[0134] The detection and classification thresholds are dynamically calculated based on the user's cached historical trust level. Combined with the global security posture baseline shift, the thresholds are adjusted in real time through a continuous mapping function to achieve differentiated protection.

[0135] The message encryption uses an ECDHE elliptic curve temporary key negotiation plus a two-stage encryption scheme, which has forward security. The complete process is as follows:

[0136] Step 1. Temporary Key Negotiation During Login: The client generates a temporary ECDH key pair and sends its public key to the authentication center along with the login request. The authentication center generates a new server-side temporary key pair for this login, negotiates a session key based on the client's public key, and returns the server-side public key to the client along with the login success response and token. The client calculates the same session key based on the server-side public key. The server-side temporary private key is only stored during the login negotiation phase and is destroyed immediately after negotiation; it is not stored long-term. Even if the server-side master key is leaked, historical sessions cannot be decrypted, ensuring forward security.

[0137] Step 2. Session Key Lifecycle: The session key is bound to the current access token. When the token expires, the key becomes invalid. When the token is refreshed, a new session key is generated synchronously, and the old key is immediately cleared from the cache and memory to ensure that the key lifecycle is strictly bound to the token. The recently valid session key ciphertext is persistently stored in the database and is encrypted and protected by the system master key. It is only used as a fallback for the origin server in extreme cache failure scenarios and does not affect the core attributes of forward security.

[0138] Step 3. Two-stage encrypted transmission: The client encrypts the request body using the session key and sends it to the API gateway; during the request preprocessing stage, the gateway first retrieves the corresponding user's session key from the cache, decrypts the request body to obtain plaintext, and then performs attack detection; after the detection passes and authorization is completed, the gateway forwards the request to the target microservice through the service mesh mTLS encrypted channel; the backend service response data is also encrypted using mTLS and returned to the gateway, which then encrypts it again using the session key and returns it to the frontend, which decrypts and displays it.

[0139] The model adopts a continuous update mechanism of sample accumulation and monthly iteration: the system automatically collects false positives and false negatives in the request samples, and the administrator can mark and correct them in the permission management backend. After quality verification and manual review, the samples are stored in the incremental sample library. A small version training is performed every month by mixing the basic dataset and the incremental samples. After verifying that the accuracy meets the standard, the online model is updated. For new attack payloads, it supports the rapid implementation of emergency rule patches through the backend to deal with the risk of zero-day attacks.

[0140] Example 5:

[0141] This embodiment details the three-level caching architecture, version number mechanism, online status determination logic, hierarchical permission synchronization strategy, offline user compensation synchronization mechanism, as well as the back-to-origin logic under extreme cache failures, the near real-time data synchronization mechanism based on Binlog, and the abnormal degradation strategy.

[0142] The system adopts a three-level caching architecture, balancing performance and consistency:

[0143] Level 1 Cache: Gateway local memory cache, storing permission data, trust thresholds, session keys and security domain policies for hot users. When a hit occurs, the authentication time is reduced to the microsecond level. It adopts an LRU eviction policy, and the cache capacity can be adjusted according to the gateway memory configuration. At the same time, a maximum lifespan is set as a consistency fallback. Even if the cache expiration notification is lost, the local cache will automatically expire after the expiration date, and requests will pull the latest data from the distributed cache to ensure eventual consistency.

[0144] Second-level cache: Redis distributed cache, storing full tokens, permissions, security domain policies, session keys and permission version number data, supporting shared access by all gateway nodes in the cluster;

[0145] Level 3 storage: A persistent MySQL database stores all configuration data, historical logs, audit data, and session key archives, serving as the ultimate trusted source of data. All changes are based on database writes.

[0146] Redis caching is divided into two parts: token cache and permission cache, both of which use a hash structure for storage. The token cache uses the access token string as the key and stores fields such as expiration time, refresh token, user ID, and session key identifier. The cache expiration time is the same as the refresh token's validity period. The permission cache uses the access token string as the key and the service URL path as the field, storing the corresponding permission identifier and version number. During authentication, it can directly query whether the specified URL exists, resulting in extremely high query efficiency.

[0147] The system introduces a globally incrementing permission version number mechanism: each user corresponds to a permission version stamp, which is stored in the database and Redis cache; every time a user's permissions or roles change, the database version number is automatically incremented by 1 and updated synchronously to Redis; the gateway's local cache also stores the version number of the corresponding data, and version consistency can be quickly compared during request processing.

[0148] Data synchronization employs the CDC change data capture scheme, implemented using the Debezium connector:

[0149] 1. Enable Binlog logging in the MySQL database and set the format to row mode to ensure that changes to each row of data are fully captured;

[0150] 2. The Debezium connector connects to MySQL, monitors data changes in core business tables, converts various data change events into structured messages, and carries the version number after the change;

[0151] 3. Change messages are sent to the Kafka permission synchronization topic, which is partitioned by user ID to ensure that change messages of the same user are consumed in order;

[0152] 4. The data synchronization service consumes Kafka messages and first distinguishes between permission change types, categorizing them into ordinary permission changes and core mandatory changes. High-risk changes such as user disabling, sensitive role deletion, and permission revocation fall under core mandatory changes. These changes ignore user online status, directly update the Redis cache, and push cache expiration notifications to ensure that high-risk operations take effect immediately, eliminating the security window for permission changes in offline states. Ordinary permission changes, on the other hand, first determine the user's online status based on the most recent active timestamp of the access token in Redis. Changes for online users are immediately updated in the cache and expiration notifications are pushed. Changes for offline users are temporarily stored in a synchronization queue to avoid writing invalid cache for long-term offline users, thus saving cache resources.

[0153] Offline user compensation and synchronization mechanism: When an offline user initiates a request for the first time, the gateway first retrieves the user's permission version number from Redis and compares it with the local cache version. If the versions are inconsistent, the gateway directly loads the latest permission data from Redis, updates the local cache, and then performs authentication. For offline user caches that do not exist in Redis, the gateway automatically triggers the retrieval of the latest permissions from the database and writes them to both Redis and the local cache, ensuring that users always obtain the latest permissions after coming online, thus eliminating the security risk of offline users exceeding their privileges after permission is revoked.

[0154] Extreme cache failure origin pull mechanism: When a full Redis cluster failure or data wipe leads to the loss of session key cache, the gateway first checks if a valid key exists in the local cache. If no valid key exists locally, it queries the database for the session key archive based on the user ID associated with the request token. The session key archived in the database is encrypted and stored using the system master key, retaining only the key records within their validity period. After obtaining the ciphertext, the gateway decrypts it using the system master key, verifies the validity of the binding relationship between the token and the key, rebuilds the local cache, and continues to process requests. Simultaneously, it synchronously writes back to the cache after the Redis cluster recovers. Only when there is no corresponding valid key record in the database will an authentication failure be returned, prompting the user to log in again. This mechanism minimizes the business impact of a full cache failure without compromising forward security.

[0155] Complete process for backend data synchronization and model update:

[0156] Step 1: When the permission management backend changes permission configuration, role information, or security domain policy, the database generates a change log and increments the version number. The change capture component captures the event and sends it to the message queue.

[0157] Step 2: After consuming messages, the data synchronization service distinguishes between ordinary changes and core mandatory changes and performs differentiated synchronization. It combines user online status and version number comparison mechanism to ensure eventual data consistency.

[0158] During the model update phase, the system collects false positive and false negative samples, and after double verification by manual annotation and automated quality check, they are stored in the incremental sample library. The system periodically mixes the basic dataset to perform model retraining. Once the accuracy is verified to meet the standard, the model is launched in a grayscale version to prevent model poisoning caused by sample annotation errors.

[0159] When the CDC synchronization link fails or Kafka messages accumulate, the system automatically executes a degradation strategy: core permission change operations use a dual-write mode of database and Redis to ensure that core policies take effect in real time; non-core changes are synchronized after the link is restored, so that eventual consistency is not affected, balancing security and availability in abnormal scenarios; the Nacos service registry synchronizes the online and offline status of microservices in real time, and the dynamic security domain management module periodically pulls the latest service list from Nacos to ensure the accuracy of security domain division.

[0160] In summary, this API interface permission control system and its control method adopt an authentication-separated deployment architecture for the API gateway layer and authentication center service. It uses a trust evaluation engine to build a multi-dimensional trust evaluation system, integrates a neural network model to dynamically calculate the trust level of each interface request, and uses a multi-level caching mechanism built through caching and data synchronization modules to perform fast authentication. This not only meets the security requirements of zero-trust continuous verification, but also effectively alleviates the authentication performance bottleneck in high-concurrency scenarios.

[0161] Furthermore, the API interface permission control system and its control method, the dynamic security domain management module collects service topology and operational threat data of the microservice cluster, completes the dynamic division of security domains through a multi-objective optimization algorithm, and builds a quantitative two-way feedback mechanism with the trust assessment engine. It adjusts the trust assessment criteria according to the threat status within the domain, optimizes the domain division weights according to the trust data, realizes differentiated isolation verification, and balances security protection capabilities and system resource consumption.

[0162] Furthermore, this API interface permission control system and its control method dynamically link the attack detection module and the trust assessment engine, adjusting the sensitivity of attack detection in real time according to the trust level of the request. It combines a front-end rule engine and a deep learning model to build a two-level detection architecture, coupled with the forward security encryption mechanism of the authentication center service, and the fault return fallback of the caching and data synchronization modules, forming a multi-layered collaborative protection system that fully covers the security protection needs of the entire API access chain. This solves the problems of existing API interface permission control technologies, such as static and rigid authorization mechanisms, lack of dynamic trust assessment based on request context leading to high risk of abnormal privilege escalation, performance bottlenecks in authentication under high concurrency scenarios, single isolation granularity between microservices making it difficult to balance protection strength and system resource overhead, and the independent nature of permission control, attack detection, and transmission encryption modules, resulting in low overall protection efficiency.

[0163] The relevant modules involved in this system are all hardware system modules or functional modules that combine computer software programs or protocols with hardware in the prior art. The computer software programs or protocols involved in these functional modules are technologies known to those skilled in the art and are not improvements to this system. The improvement of this system lies in the interaction or connection between the modules, that is, in improving the overall structure of the system to solve the corresponding technical problems that this system aims to address.

[0164] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. An API interface access control system, characterized in that, It includes an API gateway layer, authentication center service, trust assessment engine, dynamic security domain management module, attack detection module, caching and data synchronization module, and permission management backend; The API gateway layer serves as a unified entry point for north-south traffic, deploying a global authentication filter to receive client access requests, perform whitelist verification, token validity verification, and initial permission judgment, and forward compliant requests to the target microservice. The API gateway layer shares a control plane with the micro-agents in the service mesh. The micro-agents are deployed on each microservice side to manage east-west traffic between microservices. The authentication center service is deployed independently and is used to receive user login requests, verify user identity credentials, generate stateful access tokens and refresh tokens, synchronously complete session key negotiation and lifecycle management, write token and key information into a persistent database and synchronize it to the cache and data synchronization module. The trust assessment engine is connected to the API gateway layer and the authentication center service respectively. It is used to build a multi-dimensional trust assessment index system, calculate the trust level of the request based on the integrated neural network model, and output it to the authorization execution unit of the API gateway layer. The dynamic security domain management module is connected to the service registry center and is used to collect service topology, call chain and security threat level data of the microservice cluster. It performs security domain division based on a multi-objective optimization algorithm, generates isolation policies for weak authentication within domains and strong authentication between domains, and distributes them to each micro-agent for execution. The dynamic security domain management module and the trust assessment engine are set up with a quantitative two-way feedback mechanism. The security domain threat status dynamically corrects the trust assessment index, and the trust assessment results inversely optimize the security domain division weight. The attack detection module is deployed in the request preprocessing link of the API gateway layer. It is used to convert the request text into a word embedding matrix based on pre-trained word vectors, extract attack features through a deep network, and output classification results. The attack detection module works in conjunction with the trust assessment engine to dynamically adjust the detection classification threshold based on the trust level of the request. The caching and data synchronization module adopts a multi-level caching architecture. It captures database change logs based on the change data capture component, asynchronously synchronizes permission data, token status and security domain policies through message queues, and ensures eventual data consistency by combining a version number mechanism. The permission management backend is connected to the authentication center service, the dynamic security domain management module, and the attack detection module, respectively, and is used to perform user management, role management, service permission configuration, security domain policy adjustment, and attack detection rule update operations.

2. The API interface access control system according to claim 1, characterized in that, The trust assessment engine includes an indicator preprocessing submodule, an integrated assessment submodule, and a trust constraint authorization submodule. The indicator preprocessing submodule quantifies qualitative indicators using a hierarchical assignment method and maps quantitative indicators to the [0,1] interval using an extremum normalization method. The integrated evaluation submodule consists of multiple weak learners cascaded with one strong learner. The output of the weak learner is concatenated with the original feature vector and then input into the strong learner to output the final trust value. The trust constraint authorization submodule sets a minimum trust threshold for each service interface and allows access when the request simultaneously meets the role permissions and the trust threshold. The attack detection module's classification threshold is calculated in real time based on the user's cached historical trust level, and is adjusted in conjunction with the global security posture baseline to achieve a dynamic balance between security protection and business availability.

3. The API interface access control system according to claim 1, characterized in that, The dynamic security domain management module includes a domain partitioning calculation submodule, a domain policy execution submodule, and a service status awareness submodule. The domain partitioning calculation submodule constructs a security performance evaluation function and a resource consumption evaluation function with normalization constraints as optimization objectives, and uses a multi-objective evolutionary algorithm to solve for the optimal partitioning scheme. The solution with the best security performance is selected from the Pareto optimal solution set as the partitioning result. The domain policy execution submodule distributes the partitioning result to each micro-agent. Intra-domain communication only performs mTLS certificate verification, while cross-domain communication calls the trust evaluation engine to perform a complete trust evaluation and authorization verification. The quantitative two-way feedback mechanism includes: in the positive feedback, the dynamic security domain management module generates a correction coefficient based on the average threat level of the domain, and dynamically corrects the service sensitivity level index in the trust assessment; In the reverse feedback, the trust assessment engine calculates the average trust level, the proportion of unauthorized requests, and the proportion of attack interception for each security domain, and calculates the service threat weight factor as the dynamic weight for the next round of security domain division.

4. The API interface access control system according to claim 1, characterized in that, The attack detection module includes a pre-rule engine submodule, a word embedding submodule, a feature extraction submodule, and a classification output submodule; The pre-rule engine submodule loads emergency rule patches and deploys them at the front end of the deep learning detection link, directly intercepting when a rule is hit; the word embedding submodule adopts a character-sub-word hybrid word segmentation mechanism and uses a dynamic weight truncation strategy for high-incidence attack areas for ultra-long requests; the feature extraction submodule extracts local features through convolutional networks and models temporal dependencies through recurrent neural networks; the classification output submodule uses a loss function that adapts to dynamic threshold adjustment for model training.

5. The API interface access control system according to claim 1, characterized in that, The caching and data synchronization module includes a three-level caching unit, a change capture unit, a message queue unit, and a data synchronization service unit; The three-level caching unit includes a gateway local cache, a distributed cache, and persistent database storage; the change capture unit listens to the database change log, captures change events, and increments the version number; the message queue unit receives change events and stores them in partitions according to user dimensions; the data synchronization service unit consumes change messages, distinguishes between ordinary permission changes and core forced changes, performs differentiated synchronization, updates the cache in real time for online users, temporarily stores changes for offline users in a queue to be synchronized, and triggers compensation synchronization by comparing version numbers when a user comes online; The system is configured with a fault tolerance and degradation module. When the cache cluster fails, the gateway retrieves the session key archive from the database based on the user identifier associated with the token and rebuilds the cache.

6. An API interface access control method, characterized in that, Includes the following steps: S1. User authentication: The client sends a login request to the API gateway layer, which forwards it to the authentication center service to verify the identity, generate an access token and a refresh token, complete the session key negotiation, write the token and key information to the database and synchronize it to the cache; S2. Access Request Verification: The client sends a business access request with a token. The API gateway layer verifies the validity of the whitelist and the token. If the token is invalid, the request is rejected. S3. Pre-processing rules and attack detection: Requests are matched with rule patches by the pre-processing rule engine, and if a match is found, the request is blocked; for requests that do not match, the attack detection module sets a classification threshold based on cache history trust and global security posture, performs word segmentation and feature extraction on the request text, and uses a deep model to determine whether it is an attack request. S4. Trust Assessment and Authorization: The API gateway layer extracts the request subject attributes, behavioral characteristics and target service information, sends them to the trust assessment engine to calculate the real-time trust level and update the cache baseline; Authorization decisions are made by combining role permissions with trust thresholds. S5. East-West Traffic Control: When a call is initiated between microservices, the micro-proxy determines whether the two parties to the call belong to the same security domain; within the same domain, mTLS certificate verification is performed before forwarding; when a call is made across domains, the trust assessment engine completes trust assessment and authorization verification before forwarding. S6. Seamless Token Refresh: After the access token expires, the client automatically applies for a new token using the refresh token. After the authentication center verifies the token, it issues a new dual token and a new session key, and invalidates the old token and old key.

7. The API interface access control method according to claim 6, characterized in that, The trust assessment in step S4 includes: quantifying and normalizing the trust assessment indicators, obtaining the threat level correction coefficient of the security domain to which the target service belongs, correcting the service sensitivity level indicator, and forming an input feature vector; inputting the input feature vector into multiple weak learners to obtain multiple preliminary trust outputs; concatenating the multiple preliminary trust outputs with the original input feature vector to form a fused feature vector, inputting it into a strong learner to calculate the real-time trust; querying the minimum trust threshold corresponding to the target service, allowing access if the user has role permissions and the trust level is greater than or equal to the threshold, otherwise denying access. The attack detection in step S3 includes: splitting and filtering the request URL and request body; performing dynamic weight truncation of high-incidence areas for excessively long requests; performing character-level word segmentation on the URL path and request parameter names; performing sub-word-level word segmentation on the long parameter values ​​of the request body to obtain a fixed-length sequence; calling a pre-trained word vector model to convert the sequence into a word embedding matrix; obtaining a one-dimensional feature vector after feature extraction from the word embedding matrix; combining the global security posture baseline and the dynamic classification threshold corresponding to the cached historical trust level to determine whether the request is an attack based on the attack probability; and using a default medium trust level as the initial threshold when the first request has no historical trust level.

8. The API interface permission control method according to claim 6, characterized in that, The dynamic partitioning of security domains in step S5 includes: collecting the basic threat levels of all microservices at the current moment and the call chain data of the previous cycle; correcting the threat level of each service by combining the threat weight factor fed back by the trust assessment engine; constructing a weighted undirected network topology graph; generating an initial partitioning population based on the similarity of security threats between services through a label propagation algorithm; iteratively optimizing using a multi-objective evolutionary algorithm, with the optimization objectives including a security performance evaluation function and a resource consumption evaluation function with normalization constraints; selecting the partitioning scheme with the best security performance from the Pareto optimal solution set after iteration; generating a security domain isolation policy and setting a smooth transition period before distributing it to each micro-agent for execution; and adopting a dynamic update mechanism that combines periodic full partitioning with triggered incremental adjustment.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the API interface access control method as described in any one of claims 6 to 8.

Images