A large model API management method and system based on digital certificates

Abstract

The application provides a large model API management and control method and system based on digital certificates, relating to the technical field of data processing, the method comprising: issuing digital certificates for a client initiating an API call request and a server providing large model service capabilities respectively, and completing certificate distribution through a secure channel; based on the digital certificates, the client performs two-way authentication with the server when initiating an API request, and establishes a trusted communication link after the two-way authentication is passed. The application establishes a trusted link through two-way certificate authentication, clusters and divides security subdomains to realize precise behavior mapping, redundant monitoring and dynamic access control strategy to ensure call security, certificate life cycle management to avoid risks in a timely manner, and improves the security and risk response capability of large model API calls.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method and system for managing large-scale APIs based on digital certificates. Background Technology

[0002] In the current wave of artificial intelligence applications, large-scale models providing services through API interfaces are gradually becoming the mainstream model, especially in the field of intelligent customer service, where this service form is widely used. Currently, many such API interfaces rely on static credentials, such as API keys, for identity authentication and access control, which can meet basic security management needs under normal circumstances. However, in fields like intelligent customer service, which may face sudden traffic surges and where some business involves user privacy information, existing static control methods sometimes face challenges. In such systems, many may have preset fixed access frequency thresholds and data access ranges, and their flexibility needs to be improved when dealing with dynamic changes in client behavior.

[0003] For example, when a legitimate client experiences a temporary surge in calls due to business needs (such as a short-term spike in inquiries caused by a promotional activity), its call patterns may deviate from the normal baseline, and in some cases, it may be mistakenly identified as abnormal behavior and blocked. Conversely, if some malicious attackers use low-frequency, long-term "slow attacks" to simulate normal call behavior and gradually attempt to steal sensitive data, it may be difficult to identify such potential risks in real time in many cases by relying solely on static strategies. Summary of the Invention

[0004] The technical problem to be solved by this invention is to provide a method and system for managing large model APIs based on digital certificates, thereby improving the legitimacy of large model API calls and the efficiency of risk response.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0006] Firstly, a large-scale API management method based on digital certificates, the method comprising:

[0007] Step 1: Issue digital certificates to the client that initiates the API call request and the server that provides large model service capabilities, and complete the certificate distribution through a secure channel;

[0008] Step 2: Based on digital certificates, the client performs mutual authentication with the server when initiating an API request, and establishes a trusted communication link after successful mutual authentication.

[0009] Step 3: Based on the secure communication link, collect client API call behavior data sequences in real time, and extract feature parameters in six dimensions: call frequency, interface type, data sensitivity, request load, response latency, and access sequence. Based on the feature parameters, construct a six-dimensional security assessment matrix, divide the matrix into eight security subdomains through a clustering algorithm, and map the client behavior feature vectors to the corresponding security subdomains.

[0010] Step 4: Deploy two redundant monitoring nodes on the core service path of each security subdomain to collect API call behavior data of clients in each subdomain in real time, and generate dynamic access control policies based on the characteristic distribution of each subdomain; execute the policies to adjust the list of API interfaces accessible to clients in each subdomain, call frequency thresholds and data access range in real time, and generate policy execution logs and security posture data.

[0011] Step 5: Based on policy execution logs and security posture data, implement status monitoring and proactive management of issued digital certificates, track certificate validity in real time, and execute certificate revocation operations when certificates expire, permissions change, or security risk events are detected, and trigger certificate reissue and update processes.

[0012] Secondly, a large-scale API management system based on digital certificates includes:

[0013] The distribution module is used to issue digital certificates to the client that initiates the API call request and the server that provides large model service capabilities, and to complete the certificate distribution through a secure channel.

[0014] The authentication module is used to perform two-way authentication between the client and the server when initiating an API request based on digital certificates, and to establish a trusted communication link after successful two-way authentication.

[0015] The security subdomain module is used to collect client API call behavior data sequences in real time based on a secure communication link, and extract feature parameters in six dimensions: call frequency, interface type, data sensitivity, request load, response latency, and access sequence. Based on the feature parameters, a six-dimensional security evaluation matrix is ​​constructed, and the matrix is ​​divided into eight security subdomains through a clustering algorithm. The client behavior feature vectors are then mapped to the corresponding security subdomains.

[0016] The execution module is used to deploy two redundant monitoring nodes on the core service path of each security subdomain to collect API call behavior data of clients in each subdomain in real time, and generate dynamic access control policies based on the characteristic distribution of each subdomain; execute the policy to adjust the list of API interfaces accessible to clients in each subdomain, call frequency thresholds and data access range in real time, and generate policy execution logs and security posture data.

[0017] The proactive management module is used to monitor and proactively manage the status of issued digital certificates based on policy execution logs and security posture data. It tracks certificate validity in real time, performs certificate revocation operations when certificates expire, permissions are changed, or security risk events are detected, and triggers certificate re-issuance and update processes.

[0018] Thirdly, a computing device, comprising:

[0019] One or more processors;

[0020] A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method.

[0021] Fourthly, a computer-readable storage medium storing a program that, when executed by a processor, implements the method.

[0022] The above-described solution of the present invention has at least the following beneficial effects:

[0023] By issuing digital certificates to both the client and server, the legitimacy of both parties is verified from the source. Two-way authentication is then implemented using these certificates, establishing a trusted communication link only after successful authentication. This effectively blocks unauthorized access and prevents data tampering and theft during transmission, addressing the issues of weak authentication verification and lack of secure transmission. This lays a solid foundation for API call security. Real-time collection of multi-dimensional call behavior data via the secure link extracts key features such as call frequency and data sensitivity to construct an evaluation matrix. Clustering algorithms are used to divide security subdomains and map client behavior vectors, allowing for precise matching of different client characteristics to control measures. Redundant monitoring nodes are deployed in each subdomain, generating dynamic access control policies based on subdomain characteristics. Interface permissions, call frequency, and data range are adjusted in real-time to meet legitimate business needs while mitigating unauthorized access risks, overcoming the limitations of static control. Real-time monitoring of certificate status, based on policy execution logs and security posture data, proactively detects expired certificates, permission changes, or associated security risks. In the event of an anomaly, certificate revocation and reissue / update processes are quickly initiated, preventing security incidents caused by certificate expiration, permission mismatches, or risk spread. This enhances the security and risk response capabilities of large-scale API control. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating a large-scale API management method based on digital certificates, provided by an embodiment of the present invention.

[0025] Figure 2 This is a schematic diagram of a large-scale API management system based on digital certificates provided by an embodiment of the present invention. Detailed Implementation

[0026] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0027] like Figure 1 As shown, embodiments of the present invention propose a large-scale API management method based on digital certificates, the method comprising the following steps:

[0028] Step 1: Issue digital certificates to the client that initiates the API call request and the server that provides large model service capabilities, and complete the certificate distribution through a secure channel;

[0029] Step 2: Based on digital certificates, the client performs mutual authentication with the server when initiating an API request, and establishes a trusted communication link after successful mutual authentication.

[0030] Step 3: Based on the secure communication link, collect client API call behavior data sequences in real time, and extract feature parameters in six dimensions: call frequency, interface type, data sensitivity, request load, response latency, and access sequence. Based on the feature parameters, construct a six-dimensional security assessment matrix, divide the matrix into eight security subdomains through a clustering algorithm, and map the client behavior feature vectors to the corresponding security subdomains.

[0031] Step 4: Deploy two redundant monitoring nodes on the core service path of each security subdomain to collect API call behavior data of clients in each subdomain in real time, and generate dynamic access control policies based on the characteristic distribution of each subdomain; execute the policies to adjust the list of API interfaces accessible to clients in each subdomain, call frequency thresholds and data access range in real time, and generate policy execution logs and security posture data.

[0032] Step 5: Based on policy execution logs and security posture data, implement status monitoring and proactive management of issued digital certificates, track certificate validity in real time, and execute certificate revocation operations when certificates expire, permissions change, or security risk events are detected, and trigger certificate reissue and update processes.

[0033] In this embodiment of the invention, digital certificates and two-way authentication enhance the reliability of identity authentication for large-scale API calls, reducing the risk of credential leakage and providing better protection against dynamic security threats compared to static keys. A security subdomain is constructed based on six-dimensional behavioral characteristics, generating dynamic control policies that can adjust permissions in real time according to the client's actual call behavior. This prevents legitimate clients from being mistakenly blocked due to sudden business events, such as peak promotional inquiries, and also allows for more timely identification of abnormal behaviors such as "slow attacks." Full lifecycle management of certificates is achieved through policy logs and security posture data, proactively revoking and updating certificates when they expire, permissions change, or risks arise, reducing service interruptions and security vulnerabilities.

[0034] In a preferred embodiment of the present invention, step 1 includes:

[0035] In this embodiment of the invention, step 100 involves issuing a digital certificate for the client that initiates the API call request. The structured data fields embedded in the client's digital certificate include a unique identifier for client authentication and authorized service level information for defining client access permissions. A digital certificate is also issued for the server that provides large-scale model service capabilities. The structured data fields embedded in the server's digital certificate include a unique identifier for server authentication. Specifically, this includes: a Certificate Authority (CA) with industry-recognized authoritative qualifications acting as the sole issuing entity, responsible for issuing digital certificates for both the client and server. Before issuance, the CA must complete three preliminary tasks: first, establishing a key management system that meets security standards, using dedicated hardware encryption devices to store the root key for certificate signing, and setting up a backup mechanism for the root key to prevent key loss due to single point of failure; second, hardening the issuance system by closing unnecessary network ports and installing antivirus software and intrusion detection tools to prevent unauthorized intrusion or tampering; and third, developing standardized issuance process documents to define the operational requirements and responsible persons for each step from information collection to certificate output, ensuring that the entire issuance process is traceable, verifiable, and compliant with relevant network security regulations.

[0036] Certificate Authorities (CAs) collect identity verification materials from clients through a dedicated secure information collection channel. If the client is an enterprise, a copy of the business license, the legal representative's identity certificate, a power of attorney for the authorized representative, and a description of the business application for access to the large-scale API are required. If the client is an individual developer, personal ID information, developer platform registration account, and a description of the purpose of the API call are required. Based on these materials, a unique identifier for the client is generated. The generation rule is an enterprise or individual exclusive identifier plus a timestamp of information approval plus random characters. The enterprise exclusive identifier is the last ten digits of the business license registration number, and the individual exclusive identifier is the last six digits of the ID card number. The timestamp is accurate to the second and the format is year, month, day, hour, minute, second. The random characters are a combination of six uppercase and lowercase letters and numbers. These three parts are concatenated to form the unique identifier for the client. Then, the system's built-in deduplication function checks whether the identifier is duplicated in clients that have already been issued certificates. If duplicated, random characters are regenerated until the identifier is unique.

[0037] Simultaneously, authorization service level information is defined based on client requirements. First, the types of large model APIs that can be accessed are determined based on the business specifications provided by the client, such as text generation APIs and image analysis APIs. Then, the maximum number of calls per month is set based on the client's business scale. Finally, the data confidentiality level that can be processed is determined based on the sensitivity of the data processed by the client, divided into four levels: public, internal, secret, and confidential. Different levels correspond to different data transmission and storage requirements. The generated client unique identifier and the defined authorization service level information are embedded in the client digital certificate in the form of structured data fields. The client unique identifier field is named ClientUniqueID, and the field type is string. The authorization service level information field is named AuthorizationLevel, and the field type is structured, containing three sub-items: API type, maximum number of calls, and data confidentiality level, ensuring that the system can accurately read this information during subsequent authentication processes.

[0038] The certificate authority collects identity verification materials from the server's operator, including the server's business license, the server hosting room's qualification certificate, the server's hardware configuration list (such as CPU model, memory capacity, hard drive type and capacity), the server's fixed IP address and domain name information, and the technical documentation and service scope description of the large-scale services provided by the server. Based on these materials, a unique server identifier is generated. The generation rule is: the server's enterprise identifier plus the last eight digits of the server's IP address plus the device number. The enterprise identifier is the first eight digits of the business license registration number, the last eight digits of the server's IP address are the last two segments after splitting the IP address, and the device number is the last ten digits of the device serial number in the server's hardware configuration list. These three parts are concatenated to form the unique server identifier. The system's deduplication function is used to verify the identifier's uniqueness. If duplicates are found, two random numbers are added to adjust the identifier, and the verification is repeated until the identifier is unique. The unique server identifier is embedded in the server digital certificate as a structured data field named ServerUniqueID, with the field type being string. The naming rules and data format of the field are consistent with the client unique identifier field in the client digital certificate, completing the certificate signing and legality verification.

[0039] The Certificate Authority (CA) first encapsulates the client digital certificate (embedded with the client's unique identifier and authorized service level information) and the server digital certificate (embedded with the server's unique identifier) ​​according to the X.509 standard format. This ensures the certificate includes basic fields such as version number, serial number, signature algorithm identifier, issuer name, validity period, subject name, and subject public key information. The validity period is uniformly set to one year from the date of issuance, and the serial number is a unique 60-digit integer automatically generated by the system. Then, an asymmetric encryption algorithm conforming to national cryptographic standards is used to sign the encapsulated certificate. The CA's root private key is used to encrypt the certificate content, generating a digital signature which is then appended to a designated field in the certificate. After signing, two operations confirm the certificate's integrity and legitimacy: first, the digital signature is decrypted using the root public key to obtain the hash value of the certificate content, and then the hash value of the original certificate is calculated. The two hash values ​​are compared; if they match, the certificate content has not been tampered with. Second, the issuer name in the certificate is verified to match the official name of the CA, and the validity period is within a legal range. If both verifications pass, the certificate is confirmed as legitimate, and the issuance of the client and server digital certificates is completed.

[0040] Step 101: Distribute the client's digital certificate to the corresponding client through a secure channel; distribute the server's digital certificate to the corresponding server through a secure channel to complete the certificate distribution. Specifically, this includes: the certificate authority establishing a secure channel based on the TLS 1.3 protocol with each client and each server. The establishment process consists of four phases. The first phase is the handshake initiation, where the certificate authority sends a message to the client or server containing the supported TLS version, a list of cipher suites, and a random number R1 (a random number generated by the certificate authority to provide initial random input for subsequent session key generation). After receiving the message, the client or server replies with confirmation of the TLS version used, the cipher suite, and a random number R2 (a random number generated by the client or server, and a random number R3). The first phase involves two stages: 1) Joint participation in session key calculation to ensure the uniqueness of each session key; 2) Authentication: The Certificate Authority (CA) sends its root certificate to the client or server. The client or server verifies the root certificate's legitimacy using its built-in root certificate trust list. Upon successful verification, the client sends its previously generated client-unique identifier to the CA, and the server sends its previously generated server-unique identifier. The CA checks if these identifiers match the identification information in the issued certificate. If they match, authentication is complete. 3) Key negotiation: Both parties calculate the session key SK based on the exchanged random numbers R1 and R2, combined with the temporary key TK generated by the client or server, using the key derivation function KDF. The specific calculation method is as follows: ,in" This indicates that R1 and R2 will be concatenated. The parameter representing the length of the session key is pre-set to 256 bits based on actual encryption requirements. The generated session key SK contains a symmetric key SKenc for data encryption and a MAC key SKmac for message authentication. The validity period of the session key SK is set to 24 hours; after the expiration, the key negotiation process must be re-executed. The fourth stage is channel confirmation. The certificate authority first collects all messages M1, M2, ..., Mn generated in the previous handshake stages and calculates the hash value H of these handshake messages. The specific calculation method is as follows: ,in This represents a preset hash algorithm. During the calculation process, all handshake messages must be concatenated in the order they were generated before being substituted into the algorithm; subsequently, the certificate authority will assign the hash value... The message is encapsulated as an acknowledgment message Msg, which is then encrypted using the symmetric key SKenc from the session key to obtain the encrypted acknowledgment message Enc(Msg). Enc(Msg) is then sent to the client or server. Upon receiving Enc(Msg), the client or server decrypts it using the symmetric key SKenc from the session key to obtain the acknowledgment message Msg containing the hash value H. Simultaneously, the client or server collects all messages M1, M2, ..., Mn from the handshake phases and performs the same calculation. Recalculate the hash value of the handshake message ;like With Msg If they match, the client or server generates an acknowledgment message Msg' in the same format, encrypts it using SKenc, and sends the encrypted Enc(Msg') back to the certificate authority. Upon receiving Enc(Msg'), the certificate authority decrypts it and verifies the hash value against its own calculated hash. If the verification is successful, the secure channel is officially established.

[0041] The Certificate Authority (CA) first converts the issued client digital certificate into PKCS#12 format, which includes the certificate, private key, and certificate chain. It also sets a protection password for the certificate, consisting of eight characters: one uppercase letter, one lowercase letter, one number, and one special symbol. This password is sent to the client's authorized representative via SMS. The CA then encrypts the PKCS#12 certificate file using the previously negotiated session key, adding a message authentication code during encryption to verify data integrity during transmission. The encrypted certificate file is transmitted to the client via a secure channel, using a fragmented transmission method. The file is split into 1024-byte segments, each segment marked with an incrementing sequence number to ensure the client can reassemble the file according to the sequence number. Upon receiving the file... After all fragments are processed, they are reassembled into a complete encrypted file according to their sequence numbers. The client digital certificate in PKCS#12 format is obtained by decryption using the session key. The client then performs two verifications on the certificate: first, it verifies the integrity of the digital signature in the certificate by decrypting the signature using the certificate authority's root public key and comparing the hash value of the decrypted signature with that of the original certificate; second, it reads the client's unique identifier in the certificate and confirms that it matches its own identifier. After the verification is successful, the client stores the certificate in its local encrypted certificate store. After the digital certificate is distributed to the client or server, it is necessary to store the certificate in the corresponding designated directory according to the type of operating system installed on the device, and configure access permissions for the certificate store to ensure that only the currently logged-in user has certificate read permissions.

[0042] The Certificate Authority (CA) converts the issued server digital certificate into PEM format, which contains the certificate and private key. The private key is encapsulated in PKCS#8 format. The server administrator sets a private key protection password through the CA's management platform, requiring verification via the administrator's mobile phone verification code. The PEM certificate file is then encrypted using a session key, and a message authentication code is added to ensure integrity. The encrypted file is then sent to the server via a secure channel using fragmented transmission. The fragment size and sequence number rules are consistent with those used in client certificate transmission. Upon receiving all fragments, the server reassembles and decrypts the file to obtain the PEM-formatted server digital certificate. The server performs two verifications on the certificate: first, it reads the server's unique identifier in the certificate and confirms its consistency with its own identifier; second, it verifies the certificate's validity period and the legality of the digital signature by decrypting the signature using the root public key and comparing the hash value. If the verification passes, the server configures the certificate in the API service's SSL configuration file (e.g., in the specified certificate field on an Nginx server). The API service is then restarted to activate the certificate, which is used for authentication and client authentication responses when receiving API requests.

[0043] After the client and server complete the certificate reception, decryption, and verification processes respectively, the Certificate Authority (CA) sends a confirmation message to both the client and server indicating successful certificate distribution. This message includes the certificate number, a serial number matching the certificate number, the distribution time in UTC time accurate to milliseconds, and the certificate validity period. Upon receiving the confirmation message, the client and server generate a response message containing the locally stored certificate hash value and send it back to the CA via a secure channel. The CA verifies that the hash value in the response message matches the certificate hash value stored in its own database. If they match, the CA confirms successful certificate distribution. It then stores the distribution record for each certificate, including the certificate number, recipient identifier, distribution time, key negotiation time, response time, and certificate hash value, in an encrypted database. The database uses transparent data encryption technology to protect data security. Simultaneously, a distribution report is generated in PDF format with an electronic signature and sent to the responsible personnel on both the client and server, completing the entire certificate distribution process.

[0044] This embodiment determines the client's access permission scope by embedding a unique identifier and authorized service level information into the client's digital certificate and a unique identifier into the server's digital certificate. Compared with static credentials, which can only achieve basic identity verification, this improves the accuracy of identity authentication and the certainty of permission management. Encrypted transmission and integrity verification ensure that the certificate is not stolen or tampered with during transmission, guaranteeing the security of the digital certificate from issuance to receipt and solving the information leakage risk that may occur during credential distribution. The certificate authority uniformly performs certificate issuance and distribution operations, ensuring that the client and server digital certificates are formatted correctly, the information is complete, and they meet security standards, improving the standardization and efficiency of certificate management in the entire large-scale API control process.

[0045] In a preferred embodiment of the present invention, step 2 includes:

[0046] In this embodiment of the invention, step 200 involves the client sending its digital certificate to the server and requesting the server's digital certificate when initiating an API request; after receiving the request, the server sending its digital certificate to the client; and the client verifying the legality and validity of the server's digital certificate, specifically including: when the client needs to call a large model API, it first reads the stored client digital certificate from the local encrypted certificate store, converts the certificate into a binary stream format conforming to the X.509 standard, and simultaneously constructs an API request message, adding a "Certificate-Request" field to the message header. This field is used to indicate to the server that the client needs to obtain the server's digital certificate, and the field value is set to "Server-Cert-Required" to confirm the request for the server's digital certificate. Then, the binary stream of the client's digital certificate is included as a message attachment and encapsulated together with the API request parameters into a complete request data packet. Subsequently, the client establishes a network connection with the server through the TCP protocol and sends the request data packet to the server's API service port, which is port number 443 or a dedicated port pre-specified by the server.

[0047] The server's API service process listens to a specified port in real time. When it detects a request data packet sent by a client, it first performs an integrity check on the data packet. Then, it uses a preset hash algorithm, Hash, to sequentially substitute all bytes B1, B2, ..., Bn in the request data packet into the algorithm to generate the hash value Hreq of the request data packet. ,in" The process involves concatenating all bytes of data sequentially, comparing the calculated Hreq with the hash value Hreqheader carried in the packet header, and confirming that the packet has not been tampered with if they match. Then, the "Certificate-Request" field in the packet is parsed. This field identifies whether the client requires a server digital certificate. If a server digital certificate is required, the valid server digital certificate is read from the server's local SSL configuration file, converted to a binary stream format, and a response message containing the server digital certificate is constructed. A "Certificate-Type" field is added to the message header, indicating the type of certificate being transmitted. The field value is set to "Server-Cert" to identify the certificate type as a server digital certificate. The binary stream of the server digital certificate is then included as an attachment to the response packet and sent to the client via the existing TCP connection.

[0048] After receiving the response data packet from the server, the client first repeats the integrity verification step, using the same preset hash algorithm as the server. It then sequentially substitutes all bytes of data C1, C2, ..., Cm from the response data packet into the algorithm to generate the hash value Hres of the response data packet. The calculated Hres is compared with the hash value Hresheader carried in the response data packet header. Once a match is confirmed, the binary stream of the server's digital certificate is parsed and converted into a readable X.509 format certificate. The client extracts the issuing authority name from the certificate and compares it with the authority names in its locally built-in list of trusted root certificates. If no matching issuing authority name is found, the certificate is deemed invalid. If a matching issuing authority is found, the root public key of that issuing authority is retrieved from the list of trusted root certificates. The root public key is used to decrypt the digital signature in the server's digital certificate, obtaining the hash value Hcertsign of the certificate content. Simultaneously, the client uses the same preset hash algorithm Hash to sequentially substitute all bytes of the server's original digital certificate data D1, D2, ..., Dk into the algorithm to generate the original certificate hash value Hcertorigin. The Hcertsign is compared with Hcertorigin. If they are completely identical, it confirms that the certificate content has not been tampered with and the certificate is deemed valid.

[0049] The client extracts the certificate's effective date and expiration date from the server's digital certificate's validity field (one of the core fields of the server's digital certificate, specifically used to record the certificate's valid time range and determine the period during which the certificate can be used normally). Both dates are stored in UTC time format, containing information in six dimensions: year, month, day, hour, minute, and second. The client obtains the current system's UTC time and first checks if the current time is earlier than the certificate's effective date; if so, the certificate is considered invalid. Then, it checks if the current time is later than the certificate's expiration date; if so, the certificate is considered expired. Only when the current time is between the effective date and the expiration date is the certificate validity verification considered successful. If both validity and validity verifications pass, the client proceeds to the next step; if either verification fails, the client immediately terminates the API request and sends a message to the user indicating that the server certificate verification failed.

[0050] Step 202: After the client's digital certificate verification is successful, the server verifies the authenticity of the client's digital certificate and the validity of the authorization service level information contained in the client's digital certificate. Specifically, this includes: After sending its own digital certificate to the client, the server continuously listens for subsequent request data from the client. When it receives a subsequent data packet containing API call parameters from the client, it extracts the binary stream of the client's digital certificate, converts it to X.509 format, and first reads the issuer field in the certificate to confirm that the issuer of the certificate is consistent with the issuers in the server's trusted root certificate list. If they are inconsistent, the certificate authenticity verification is directly deemed to have failed, and the request processing is terminated. The server obtains the root public key of the client's certificate issuer from the trusted root certificate list, uses the root public key to decrypt the digital signature in the client's digital certificate, obtains the hash value of the certificate content, and simultaneously calculates the hash value of the client's original digital certificate. The server compares the two hash values ​​bit by bit. If all bits are the same, the certificate is confirmed to be tamper-proof. Then, the server reads the certificate's validity field, extracts the effective and expiration times, obtains the current system's UTC time, and determines if the current time falls between the effective and expiration times. If it does, the certificate is confirmed to be valid. Only when the certificate is tamper-proof and valid is the client's digital certificate authenticity verification considered successful. After successful authenticity verification, the server reads the permission level field from the client's digital certificate's extended fields. This field is in a structured format and includes three sub-items: interface type, maximum number of calls, and data confidentiality level. The server parses these three sub-items one by one, recording the list of large-scale API types accessible to the client, the maximum monthly call range, and the data confidentiality level that can be processed. Simultaneously, the server reads the parameters of the API request currently initiated by the client to determine the API type and data confidentiality level of the current call.

[0051] The server first checks if the API type being called is in the client's authorized API type list. If not, the permission is deemed invalid. If it is in the list, the server then checks if the confidentiality level of the data being processed is higher than the confidentiality level authorized by the client. The confidentiality level is determined by a pre-defined unified standard and is divided into four levels: public, internal, secret, and confidential. Public data can be publicly disseminated, such as publicly available product information. Internal data circulates only within the organization and is not publicly disclosed, such as ordinary internal work documents. Secret data involves the organization's core business and its disclosure would cause certain losses, such as unpublished business plans. Confidential data involves the organization's core secrets and its disclosure would cause serious losses, such as core technical parameters. Furthermore, there is a definite hierarchical relationship between the levels: Confidential is higher than Secret, Secret is higher than Internal, and Internal is higher than Public. The server compares the level of the data to be processed in this request with the confidentiality level of the client's authorized data. If the level of the requested data is higher than the authorized level, the permission is deemed invalid. Subsequently, the server queries the locally stored client API call statistics to count the total number of calls made by the client from 00:00:00 on the first day of the month to the current time, and determines whether the total number of calls exceeds the maximum monthly limit. If it does, the permission is deemed invalid. Only when all three of the above checks are met can the validity verification of the client's authorized service level information be considered successful. If the verification is successful, the server enters the API request processing flow; if the verification fails, the server sends a response message indicating insufficient permissions or invalid certificate to the client and terminates the request processing.

[0052] Step 203: After both the client's and server's digital certificate verifications are successful, a trusted communication link is established between the client and server. This includes: After completing the server's digital certificate verification, the client sends a confirmation message to the server, indicating that the client has successfully verified the server's digital certificate; after completing the client's digital certificate and permission verification, the server sends a confirmation message to the client, indicating that the server has successfully verified the client's digital certificate and permissions. After both parties receive the verification confirmation message from the other, the trusted communication link establishment process begins. The client first sends a list of its supported encryption algorithms to the server, including symmetric encryption algorithms that conform to security standards such as AES256GCM and SM4GCM. The server selects the highest priority encryption algorithm from the list as the link encryption algorithm and sends the selection result back to the client. Subsequently, the client generates a random number as a pre-master key, encrypts the pre-master key using the public key in the server's digital certificate, and sends it to the server. The server decrypts the encrypted pre-master key using its own private key to obtain the original pre-master key. Both parties use the pre-master key combined with the previously exchanged random number to calculate the session key through a key derivation function.

[0053] The client and server use a negotiated encryption algorithm and session key to encrypt all subsequent API request and response data. During encryption, a message authentication code is added to each data segment for the receiver to verify data integrity. To ensure link stability, the client sends test data to the server. After the server decrypts and verifies the message authentication code, it returns a confirmation message to the client. Upon receiving the confirmation message, the client confirms that the link transmission is normal, and the trusted communication link is officially established. After the trusted communication link is established, the client and server periodically send link heartbeat packets at a 30-second interval. The heartbeat packet contains the current link's session identifier and timestamp. Upon receiving the heartbeat packet, the receiver decrypts and verifies the validity of the session identifier, and checks whether the difference between the timestamp and the current time is less than 60 seconds. If both requirements are met, a heartbeat confirmation packet is sent to maintain the link connection. If no heartbeat packet is received within 60 seconds, or the heartbeat verification fails, the link is considered interrupted, and the two-way authentication and link establishment process needs to be re-executed.

[0054] This embodiment, through two-way certificate verification between the client and server, can not only accurately identify the legitimacy of both parties' identities, but also prevent risks such as certificate tampering and expired use through certificate validity period and signature verification. It solves the problems of easy leakage of static credentials and single identity verification, and improves the identity authentication security of large-scale API calls. The server's multi-dimensional permission verification of the client's authorized service level information can control API access behavior according to the client's actual authorization scope, avoiding the problems of over-authorization or insufficient permission verification in fixed access policies. It ensures that the client can only call the API within the authorized scope, reducing the security risks caused by unauthorized access or unauthorized calls. The trusted communication link achieves encrypted data transmission through negotiated encryption algorithms and session keys, and combines heartbeat packets to maintain link stability, ensuring the security of data transmission and link continuity during API calls. It solves the problems of easy data transmission theft and link interruption under static credentials, improves the security system of large-scale API management, and enhances the overall service reliability.

[0055] In a preferred embodiment of the present invention, step 3 includes:

[0056] In this embodiment of the invention, step 300 involves collecting and recording each API call behavior of the client in real time through a trusted communication link, forming a client API call behavior data sequence arranged in chronological order. Specifically, this includes: deploying a dedicated data collection component alongside the server's API request processing flow, relying on the established trusted communication link. This component needs to be started and run synchronously with the API processing process to ensure that for each API call initiated by the client, the collection component can capture relevant behavioral data simultaneously with the server receiving the call request. The collection frequency is set to be completely synchronized with the API call frequency; that is, for each call initiated by the client, the component completes a full data collection, without data omission, delayed collection, or duplicate collection. Furthermore, when a client initiates an API call request, the data collection component first captures the time information of the request initiation, accurate to milliseconds and recorded in UTC time format. Next, it extracts the API interface identifier from the request, which consists of the interface's base path, function name, and version number, ensuring unique identification of the API interface being called. Simultaneously, it records the client identifier from which the request originated, i.e., the unique client identifier embedded in the client's digital certificate. In addition, it also collects the server's response status code for the request, such as 200 indicating successful request, 400 indicating incorrect request parameters, 403 indicating insufficient permissions, and 500 indicating an internal server error, as well as the server's response time information, also accurate to milliseconds in UTC time.

[0057] The data collection component further parses the API request data packet, extracts all field names carried in the request, records the value type of each field (e.g., string, numeric, boolean), and generates a content summary for key fields, such as the `prompt` field containing user input. The summary is generated by taking the first 20 characters of the field content plus the field content length, avoiding direct collection of complete sensitive data. Simultaneously, the size of the request data packet is calculated in bytes by determining the total number of bytes in the binary stream. For the server's response data packet, the data collection component also calculates the size (again in bytes) and extracts summaries of core fields from the response content, such as the identifier field uniquely identifying the API call response result and the field recording the total length of the API call response data. This basic information and detailed data are then integrated into a structured call behavior record. Each record contains eight dimensions: time information, client identifier, interface identifier, response status code, request field information, request packet size, response packet size, and response field summary. The data collection component adds a timestamp index to each structured call behavior record, ensuring the timestamp is completely consistent with the request initiation time. Subsequently, all single call behavior records are arranged sequentially according to their timestamps from earliest to latest, forming a client API call behavior data sequence. Simultaneously, this data sequence is stored in real-time in a dedicated data storage area on the server, employing a daily partitioning strategy. That is, the call behavior data for each day is stored in a separate partition, named in the YYYY-MM-DD format. During storage, sensitive fields such as client identifier, request field summary, and response field summary are encrypted using a symmetric encryption algorithm. The key is centrally managed by the server's key management module to ensure data storage security.

[0058] Step 301: Process the client API call behavior data sequence and extract six feature parameters for each call. The call frequency feature parameter is the number of requests per unit time, the interface type feature parameter is the specific API endpoint identifier called, the data sensitivity feature parameter is the data confidentiality level in the request and response, the request load feature parameter is the size of the request data packet, the response latency feature parameter is the time taken for the server to process the request, and the access time sequence feature parameter is the timestamp sequence of the call. Specifically, this includes: first, setting the unit time to 5 minutes, and filtering out all call behavior records within each 5-minute time segment from the client API call behavior data sequence.

[0059] The number of records within each time segment is counted, and this count represents the number of requests within that unit of time, which is the call frequency feature parameter. If there are no call records within a 5-minute time segment, the call frequency feature parameter for that time segment is set to 0. All time segments are processed sequentially from morning to night to obtain the call frequency feature parameter corresponding to each unit of time. For each call record in the client API call behavior data sequence, the specific API endpoint identifier is extracted from the interface identifier dimension of the record. This endpoint identifier is consistent with the API interface identifier collected in step 300. It is ensured that a unique API endpoint identifier can be extracted for each call record, and this identifier is used as the interface type feature parameter for that call. The interface type feature parameters of all call records are arranged sequentially according to the chronological order of the call behavior data sequence to form an interface type feature parameter sequence, consistent with the chronological order of the original data sequence.

[0060] Establish data confidentiality level judgment rules in advance, defining the judgment criteria for four levels: Public, Internal, Secret, and Confidential. Public level refers to data that can be completely disclosed to the public without confidentiality requirements, such as publicly available product introduction text; Internal level refers to data that circulates only within the organization to which the server belongs and is not disclosed externally, such as ordinary business data within the organization; Secret level refers to data involving core business information of the organization, the leakage of which would cause a certain degree of business loss, such as undisclosed business planning data and basic user information (ID numbers, mobile phone numbers, etc.); Confidential level refers to data involving core technologies or core secrets of the organization, the leakage of which would cause serious losses, such as core training parameters of large models and sensitive user privacy data (medical records, financial information, etc.). For the request field summary and response field summary in each call behavior record, analyze the data types contained therein against the above rules. If only public-level data is included, the data sensitivity feature parameter is set to public level; if internal-level or lower data is included, but no higher-level data is included, it is set to internal level; if secret-level or lower data is included, but no confidential-level data is included, it is set to secret level; if confidential-level data is included, it is set to confidential level. The determined level is used as the data sensitivity feature parameter for this call. The statistical value of the request packet size dimension is read from each call behavior record, and this statistical value is in bytes. This statistical value is directly used as the request load feature parameter for this call. If the request packet size statistical value is missing in a certain record, the request packet binary stream of the call data packet is reread, the total number of bytes in the binary stream is calculated, the request packet size is obtained in bytes, and it is supplemented as the request load feature parameter for this call, ensuring that the request load feature parameter of all call records is complete.

[0061] For each call record, two timestamps are retrieved: the response completion time and the request initiation time. The time difference between the response completion time and the request initiation time represents the server's processing time for the request. This time difference is used as the response latency characteristic parameter for that call. If the calculated time difference is negative (due to a brief deviation in system time), the server's time calibration service is used to obtain standard UTC time, and the request initiation time and response completion time are recalibrated. The time difference is then calculated based on the calibrated time to ensure that the response latency characteristic parameter is non-negative. The "request initiation timestamp" corresponding to each call record is extracted from the client API call behavior data sequence. The timestamps are accurate to milliseconds in UTC time. These timestamps are arranged sequentially according to the order in which the calls occurred, forming an ordered set of timestamps. This set represents the client's access timing characteristic parameter. An index is added to this timestamp set, with index values ​​starting from 1 and incrementing, each index value corresponding to a timestamp.

[0062] Step 302 involves normalizing the six-dimensional feature parameters to form a six-dimensional security assessment matrix. Each row in the security assessment matrix represents a client behavior feature vector within a time unit. Specifically, this includes: setting the time unit to 5 minutes, consistent with the unit time of the call frequency feature parameter; for each 5-minute time unit, integrating the six-dimensional feature parameters of all call behavior records within that unit, i.e., for the call frequency feature parameter, directly using the number of requests per unit time already calculated within that time unit; for the interface type feature parameter, counting the frequency of occurrence of each API endpoint identifier in all call records within that time unit, selecting the API endpoint identifier with the highest frequency as the interface type feature parameter for that time unit, and if multiple identifiers have the same frequency and are all the highest, then selecting the one with the smallest lexicographical order of the interface identifier name.

[0063] For the data sensitivity characteristic parameter, the highest sensitivity level among all call records within the time unit is taken. For example, if a time unit contains both internal and secret level data, the data sensitivity characteristic parameter for that unit is set to secret level. For the request load characteristic parameter, the average request load of all call records within the time unit is calculated. The calculation method is to add the request load of all call records (in bytes), divide the sum by the number of call records within the time unit, and keep the result as an integer as the request load characteristic parameter for that time unit. For the response latency characteristic parameter, the highest sensitivity level among all call records within the time unit is taken. The average response latency of all call records within a time unit is calculated by adding the response latencies (in milliseconds) of all call records, dividing the sum by the number of call records, and keeping the result as an integer. This sum serves as the response latency feature parameter for that time unit. For access timing feature parameters, the request initiation timestamps of the first and last call records within the time unit are extracted to form a timestamp pair (start timestamp, end timestamp), which serves as the access timing feature parameter for that time unit. Through the above integration, each time unit corresponds to a complete set of six-dimensional feature parameters.

[0064] Normalize the feature parameters of each dimension to ensure that all feature parameters have a uniform value range of 0 to 1. This is done by first calculating the maximum and minimum call frequencies for all time units, then subtracting the minimum value from the call frequency for each time unit, and finally dividing the difference by (maximum minus minimum). The result is the normalized call frequency feature parameter for that time unit. If the call frequencies for all time units are the same (i.e., the maximum value equals the minimum value), then the normalization result for all time units is set to 0.5. Pre-assign a unique numerical code to each possible API endpoint identifier, with the encoding rule being based on the connection... The interface identifier names are sorted lexicographically and assigned integers 1, 2, 3, etc. The maximum and minimum values ​​of all codes are calculated. The minimum value is subtracted from the code corresponding to the interface type feature parameter for each time unit, and the difference is divided by (maximum minus minimum value). The result is the normalized interface type feature parameter. Fixed normalization values ​​are assigned according to public, internal, secret, and confidential levels: 0.25 for public level, 0.5 for internal level, 0.75 for secret level, and 1.0 for confidential level. The corresponding value is taken based on the data sensitivity level of each time unit as the normalization result.

[0065] Calculate the maximum and minimum values ​​of the average request load for all time units. Subtract the minimum value from the average request load for each time unit, and then divide the difference by (maximum minus minimum value). The result is the normalized request load characteristic parameter. If the maximum value equals the minimum value, the normalization result for all time units is set to 0.5. Calculate the maximum and minimum values ​​of the average response latency for all time units. Subtract the minimum value from the average response latency for each time unit, and then divide the difference by (maximum minus minimum value). The result is the normalized response latency characteristic parameter. If the maximum value equals the minimum value, the normalization result for all time units is set to 0.5. Calculate the difference (in milliseconds) between the end timestamp and the start timestamp within each time unit. Calculate the maximum and minimum values ​​of this difference for all time units. Subtract the minimum value from the difference for each time unit, and then divide the difference by (maximum minus minimum value). The result is the normalized access timing characteristic parameter. If the maximum value equals the minimum value, the normalization result for all time units is set to 0.5.

[0066] The six normalized feature parameters of each time unit are arranged in a fixed order: call frequency, interface type, data sensitivity, request load, response latency, and access sequence, forming a set of six-dimensional client behavior feature vectors. Using the time unit as the row index, starting from the earliest time unit, the six-dimensional behavior feature vectors corresponding to each time unit are sequentially used as rows of a matrix. The number of columns in the matrix is ​​fixed at 6, with each column corresponding to a feature parameter of one dimension. The column headers are, in order, call frequency, interface type, data sensitivity, request load, response latency, and access sequence. Finally, a six-dimensional security assessment matrix is ​​constructed, with rows representing time units and columns representing feature dimensions. Each element in the matrix is ​​a value between 0 and 1.

[0067] Step 303a: Randomly select eight feature vectors from the security assessment matrix as initial cluster centers; based on the eight initial cluster centers, calculate the spatial distance between each feature vector in the security assessment matrix and each initial cluster center to obtain the first round of spatial distance calculation results. Specifically, this includes: selecting eight initial cluster centers from the security assessment matrix. The specific method is to first count the total number of rows in the matrix, i.e., the total number of time units, denoted as M. Then, randomly generate eight unique integers from 1 to M as row indices. Extract the corresponding eight rows of six-dimensional feature vectors based on these indices. Each vector contains normalized parameters for six dimensions: call frequency, interface type, data sensitivity, request load, response latency, and access sequence. These selected vectors are the initial cluster centers and are labeled C1 to C8. Calculate the spatial distance between each feature vector and each initial cluster center using Euclidean distance. The spatial distance between the initial cluster centers is calculated as follows: for any two six-dimensional vectors X (where the six dimensions of X are x1 to x6) and Y (where the six dimensions of Y are y1 to y6), the process is as follows: first, calculate the difference between the corresponding dimensions (i.e., x1 - y1 to x6 - y6); then, square each difference and sum them up; finally, take the square root of the sum. The result is the Euclidean distance between vector X and vector Y (the smaller the distance, the higher the similarity between the two vectors). For all M feature vectors in the matrix, from row 1 to row M, calculate the Euclidean distance between each vector and the eight initial cluster centers C1 to C8. Each vector will have eight distance values, denoted as Di1 to Di8. These distance values ​​are stored in relation to the row index of the vector. After summing the distance records of all vectors, the first round of spatial distance calculation results are formed.

[0068] Step 303b: Based on the spatial distance calculation results of the first round, assign each feature vector to the first cluster category whose spatial distance meets the preset conditions, forming the feature vector assignment results of the first round, specifically including:

[0069] The cluster assignment is performed according to the rule that each feature vector belongs to the cluster center with the smallest distance. That is, for each feature vector Xi, the minimum value is found among its eight corresponding distance values, Di1 to Di8. The cluster center corresponding to this minimum value, for example, the cluster to which C3 belongs, i.e., cluster 3 is the category to which Xi belongs. C1 to C8 correspond to categories 1 to 8, respectively. During the assignment process, if multiple distance values ​​are the same minimum value, the cluster center number priority principle is followed, and the feature vector is assigned to the category corresponding to the cluster center with the smaller number. After all vectors are assigned, the number of vectors contained in each category is counted. If a category is empty, unassigned vectors are randomly selected from the matrix to supplement the category. Finally, the first round of assignment results is formed, which contains the row index, minimum distance value and category number of all vectors.

[0070] Step 303c: Based on the first round of feature vector allocation results, calculate the mean of all feature vectors in each category to obtain the first round of new cluster centers; calculate the offset between the first round of new cluster centers and the initial cluster centers, and determine whether the offset is less than a preset threshold; when the offset is greater than or equal to the preset threshold, calculate the second round of spatial distance between the feature vectors and each cluster center based on the first round of new cluster centers, and obtain the second round of spatial distance calculation results, specifically including:

[0071] Based on the first round of feature vector allocation results obtained in step 303b, new cluster center calculation operations are performed for each of the eight cluster categories (category 1 to category 8). The specific process is as follows:

[0072] From the first round of feature vector allocation results, filter and extract all feature vectors belonging to the same cluster category:

[0073] For category 1, query the allocation results for all feature vectors marked as belonging to category 1. These vectors are all six-dimensional structures, with the dimensions corresponding to call frequency, interface type, data sensitivity, request load, response latency, and access sequence, respectively. The parameter values ​​of each dimension have been normalized (the value range is 0-1).

[0074] Repeat the above steps to extract all feature vectors for each of categories 2 to 8, ensuring that the feature vectors for each category are complete and do not overlap with those for other categories.

[0075] For each cluster category, calculate the mean of all feature vectors within that category along each of the six dimensions. Taking category 1 as an example, the specific calculation method is as follows:

[0076] Call frequency dimension mean calculation: Collect the call frequency dimension parameter values ​​of all feature vectors in category 1, sum all parameter values ​​to obtain the sum of this dimension; count the total number of feature vectors in category 1 (denoted as N1), divide the above sum by N1 to obtain the mean of the call frequency dimension of category 1; Interface type dimension mean calculation: Collect the interface type dimension parameter values ​​of all feature vectors in category 1, sum the values ​​to obtain the sum of this dimension, and divide the sum by N1 to obtain the mean of the interface type dimension of category 1; Data sensitivity dimension mean calculation: Collect the data sensitivity dimension parameter values ​​of all feature vectors in category 1 (parameter values ​​are only one of the four preset values ​​of 0.25, 0.5, 0.75, and 1.0), sum them and divide by N1 to obtain the mean of the data sensitivity dimension of category 1; Request load dimension mean calculation: Collect the request load dimension parameter values ​​of all feature vectors in category 1, sum them and divide by N1 to obtain the mean of the request load dimension of category 1.

[0077] The mean of the response latency dimension is calculated by collecting the response latency dimension parameter values ​​of all feature vectors in category 1, summing them, and then dividing by N1 to obtain the mean of the response latency dimension for category 1. The mean of the access time sequence dimension is also calculated by collecting the access time sequence dimension parameter values ​​of all feature vectors in category 1, summing them, and then dividing by N1 to obtain the mean of the access time sequence dimension for category 1. For categories 2 to 8, the same method is used to calculate the mean of each of the six dimensions for each category. The total number of feature vectors in category 2 is denoted as N2, in category 3 as N3, and so on up to N8 for category 8.

[0078] The means of the six dimensions of each cluster are combined in a fixed order (call frequency, interface type, data sensitivity, request load, response latency, access sequence) to form a new cluster center for that cluster:

[0079] After combining the means of the six dimensions of category 1, we get C1 new (first round new cluster center 1).

[0080] After combining the means of the six dimensions of category 2, we get C2 new (first round new cluster center 2).

[0081] This process continues until the mean combinations of categories 3 to 8 are completed, resulting in C3 new, C4 new, C5 new, C6 new, C7 new and C8 new, ultimately forming 8 new cluster centers in the first round (C1 new to C8 new).

[0082] Calculate the offset between the new cluster centers and the initial cluster centers to determine the center correspondence:

[0083] Determine the one-to-one correspondence between the initial cluster centers and the new cluster centers in the first round: initial cluster center C1 corresponds to new cluster center C1 new, initial cluster center C2 corresponds to new cluster center C2 new, ..., initial cluster center C8 corresponds to new cluster center C8 new.

[0084] For each pair of corresponding centers, the offset between them is calculated using Euclidean distance. Taking the initial cluster center C1 and the new cluster center C1_new as an example, the specific calculation steps are as follows:

[0085] Calculate the differences in the corresponding dimensions. Specifically, calculate the differences between C1 and the new C1 in six dimensions: C1's call frequency value - C1's new call frequency value, C1's interface type value - C1's new interface type value, C1's data sensitivity value - C1's new data sensitivity value, C1's request load value - C1's new request load value, C1's response latency value - C1's new response latency value, and C1's access timing value - C1's new access timing value. This will yield the difference results for the six dimensions.

[0086] The differences in the above six dimensions are squared to obtain six squared values.

[0087] The six squared values ​​are summed to obtain the sum of squares. The square root of the sum of squares is then taken to obtain the new offset between the initial cluster center C1 and the new cluster center C1 (denoted as O1). Following the same steps, the new offsets between C2 and C2 (O2), C3 and C3 (O3), C4 and C4 (O4), C5 and C5 (O5), C6 and C6 (O6), C7 and C7 (O7), and C8 and C8 (O8) are calculated respectively, resulting in eight offsets (O1 to O8). The offset with the largest value is selected from the eight offsets (O1 to O8) and defined as the overall offset, denoted as Omax.

[0088] The preset threshold for determining the stability of cluster centers is 0.01. That is, when the overall offset Omax is less than 0.01, the cluster centers are determined to be in a stable state; when Omax is greater than or equal to 0.01, the cluster centers are determined to be unstable.

[0089] Stability assessment and subsequent procedures:

[0090] Case 1: Cluster centers are stable (Omax < 0.01): If the overall offset Omax is less than 0.01, it indicates that the positional changes of the 8 cluster centers have met the stability requirements, the cluster centers have reached a stable state, this step 303c is terminated, and the subsequent application of clustering results can be carried out.

[0091] Case 2: Unstable cluster centers (Omax ≥ 0.01): If the overall offset Omax is greater than or equal to 0.01, it indicates that the cluster centers still need iterative optimization. Using the first round of new cluster centers (C1 to C8) as a benchmark, calculate the second-round spatial distance between all feature vectors and the new cluster centers. The specific steps are as follows:

[0092] Determine the baseline centers for the second round: The new cluster centers C1, C2, C3, C4, C5, C6, C7, and C8 from the first round will be used as the baseline cluster centers for the second round of spatial distance calculation;

[0093] Extracting feature vectors to be calculated: Extract all feature vectors from the security assessment matrix (i.e., the six-dimensional behavioral feature vectors corresponding to all time units, denoted as the total number M).

[0094] Calculate the distance between a single feature vector and all baseline centers. For any feature vector in the security assessment matrix (e.g., the i-th feature vector, where i ranges from 1 to M), calculate the Euclidean distance between the vector and the eight second-round baseline centers (C1 new to C8 new). The calculation method is completely consistent with the method in step 303a for calculating the Euclidean distance between the feature vector and the initial cluster centers, i.e., first calculate the difference in the corresponding dimension, then square the difference, then sum it, and finally take the square root to obtain the eight distance values ​​between the feature vector and the eight baseline centers. Calculate the distance of all feature vectors in batches. For the 1st to Mth feature vectors in the security assessment matrix, perform the operation in step 3 one by one to obtain the eight distance values ​​between each feature vector and the eight second-round baseline centers. Generate the second-round spatial distance calculation results. Establish the vector row index and the corresponding eight distance values ​​for each feature vector. After summarizing the relationships of all feature vectors, the second-round spatial distance calculation results are formed. Step 303c terminates here, and the second-round feature vector allocation operation can be performed based on this result.

[0095] Step 303d: Based on the spatial distance calculation results of the second round, assign each feature vector to a second-round clustering category whose spatial distance meets preset conditions; repeat the cluster center update and feature vector assignment until the offset between the new cluster center in the Nth round and the cluster center in the (N-1)th round is less than a preset threshold, and finally determine the eight clustering regions as eight safe subdomains, specifically including:

[0096] Based on the second round of spatial distance calculation results obtained in step 303c, and referring to the feature vector category assignment rules in step 303b, a second round of category assignment is performed on all feature vectors. The specific process is as follows:

[0097] Continuing the allocation logic of step 303b, each feature vector is assigned to the category corresponding to the cluster center with the smallest spatial distance to itself; if there are multiple cluster centers with the same minimum distance to the feature vector, the feature vector is assigned to the category corresponding to the cluster center with the smaller number, following the principle of priority based on cluster center number.

[0098] For any feature vector in the security assessment matrix (e.g., the i-th feature vector, where i ranges from 1 to M, and M is the total number of feature vectors), extract the eight distance values ​​between this vector and the eight second-round baseline cluster centers (C1 new to C8 new) from the second-round spatial distance calculation results; select the minimum value among these eight distance values ​​and determine the cluster center number corresponding to the minimum value; assign the feature vector to the corresponding cluster category according to the number (e.g., if the minimum value corresponds to C3 new, then assign it to category 3); perform the above single feature vector assignment operation one by one for the 1st to Mth feature vectors in the security assessment matrix. First, ensure that all feature vectors are assigned to their corresponding cluster categories. Then, count the number of feature vectors in each cluster category after the second round of allocation. If a category is not assigned any feature vectors (i.e., an empty category), randomly select one feature vector that has been assigned from the security assessment matrix (this vector must be selected from a non-empty category, and the selection should not affect the integrity of the original category), and reassign it to the empty category until all eight cluster categories contain at least one feature vector. Record the row index, corresponding minimum distance value, and cluster category number of each feature vector, and summarize all records to form the second round of feature vector allocation results.

[0099] Initiate multiple iterations to update cluster centers and determine offsets:

[0100] Starting with the results of the second round of allocation, the process of updating cluster centers, calculating offsets, determining stability, calculating the distance for the next round (if unstable), and executing the next round of allocation is repeated. The specific operations are as follows:

[0101] Kth round of cluster center update (K≥3):

[0102] For the eight cluster categories (category 1 to category 8) in the K-1 round of allocation, extract all feature vectors contained in each category. For each category, calculate the mean of each dimension of all feature vectors in that category according to six dimensions: call frequency, interface type, data sensitivity, request load, response latency, and access sequence (the calculation method is exactly the same as the calculation of the mean of each category by dimension in step 303c, that is, summing the dimension values ​​and dividing by the number of vectors in that category). Combine the six dimension means of each category in a fixed order to generate new cluster centers in the K round, denoted as C1(K), C2(K), ..., C8(K) (e.g., the new center of category 1 is C1(K), and the new center of category 2 is C2(K)).

[0103] Calculation of offset in round K and determination of stability:

[0104] Determine the object of offset calculation. Using the cluster centers of round K-1 (C1(K-1) to C8(K-1)) as the reference, calculate the corresponding offset between them and the new cluster centers of round K (C1(K) to C8(K)). Calculate the Euclidean distance pairwise. For each pair of corresponding centers (e.g., C1(K-1) and C1(K), C2(K-1) and C2(K)), use the method for calculating the Euclidean distance (offset) in step 303c (first calculate the dimensional difference, then square it, sum it, and take the square root) to obtain the result. Eight offsets O1(K), O2(K), ..., O8(K) are used. The overall offset Omax(K) for the Kth round is determined by selecting the maximum value from the eight offsets. Omax(K) is then compared with a preset threshold of 0.01. If Omax(K) < 0.01, the cluster centers are considered to have reached a stable state, and the iteration stops. If Omax(K) ≥ 0.01, the cluster centers are considered to be unstable, and the next round of distance calculation and allocation begins.

[0105] Kth round spatial distance calculation and feature vector assignment (if not stable):

[0106] Using the new cluster centers (C1(K) to C8(K)) of the Kth round as a reference, and referring to the method of calculating the Euclidean distance between the feature vectors and the cluster centers in step 303a, calculate the distance between all feature vectors and these 8 centers to form the spatial distance calculation result of the Kth round; referring to the allocation rule of step 303b, perform the Kth round category allocation on all feature vectors based on the distance result of the Kth round to generate the allocation result of the Kth round; based on the allocation result of the Kth round, return to the cluster center update step of the K+1th round and continue iterating until the overall offset of a certain round is less than 0.01.

[0107] When the iteration reaches the Nth round (N≥2), if the overall offset Omax(N) of the Nth round is <0.01, satisfying the preset stability condition, the following operations are performed: The iteration process is terminated: subsequent cluster center updates, distance calculations, and vector assignment operations are stopped, and the Nth round is determined as the final iteration round; the 8 cluster categories formed in the Nth round assignment result are defined as 8 independent cluster regions; the boundary of each cluster region is determined by the distribution range of all feature vectors within that region, and all feature vectors within the region satisfy the condition of having the minimum distance to the corresponding Nth round cluster center; the above 8 final... The clustering regions are directly defined as 8 security subdomains. Each security subdomain corresponds to a type of client API call behavior with similar behavioral characteristics (i.e., the feature vectors within the subdomain all represent similar call frequencies, interface types, data sensitivity, and other behavioral characteristics). The 8 final cluster centers (C1(N), C2(N), ..., C8(N)) generated in the Nth round are defined as the center points of the corresponding 8 security subdomains. The six-dimensional parameters of each center point (call frequency, interface type, data sensitivity, request load, response latency, and access sequence) represent the average level of client behavioral characteristics within that security subdomain.

[0108] Step 304 involves calculating the spatial distance between the real-time collected client behavior feature vectors and the center points of the eight security subdomains to obtain the distance values ​​between the corresponding feature vectors and the center points of each security subdomain. Based on these distance values, the client behavior feature vectors are categorized into the security subdomains with the smallest distance values. This specifically includes:

[0109] Real-time collection of client API call data extracts six-dimensional feature parameters, which are then normalized. Parameters such as call frequency and request load are processed using the formula (parameter value - minimum value) / (maximum value - minimum value). Interface types are converted to normalized values ​​according to preset encoding rules (each interface type is assigned a fixed normalized value, e.g., data / query / version 1 is encoded as 0.6). Data sensitivity parameters are mapped to normalized values ​​according to their corresponding levels, such as 0.25 for public level and 0.5 for internal level, forming a six-dimensional client behavior feature vector. This client behavior feature vector is then correlated with eight security subdomain centroids (i.e., the eight final cluster centers). The Euclidean distance between the client behavior feature vector and the center point of a certain security subdomain is calculated in the same way as before: first, subtract the six-dimensional values ​​of the client behavior feature vector from the six-dimensional values ​​of the center point of a certain security subdomain to obtain the differences in the six dimensions; then square each of the six differences; sum the six squared results to obtain the total; finally, take the square root of the total to obtain the Euclidean distance between the client behavior feature vector and the center point of the security subdomain. Based on the calculation results, the client behavior feature vector is classified into the security subdomain with the smallest distance. If multiple security subdomains have the same distance from the vector and all have the smallest distance, the vector is assigned to the security subdomain with the smaller number according to the subdomain number priority principle.

[0110] This embodiment achieves a refined characterization of client call behavior by collecting all client API call behavior data in real time and extracting six-dimensional feature parameters. Compared with control methods that only focus on the frequency of a single call, it can capture the security association information of call behavior more comprehensively. From the dimension of clustering and dividing security subdomains, through normalization processing and multi-round iterative clustering, the client behavior feature vector is divided into eight security subdomains, so that call behaviors with different security attributes can be accurately classified. From the dimension of real-time classification and dynamic control, the distance between the client behavior feature vector and the center point of the security subdomain is calculated in real time and the classification is completed. It can quickly identify the security attribution of the client's current call behavior. Compared with static control, it can respond to changes in client behavior more promptly, effectively resist hidden abnormal behaviors such as slow attacks, and improve the real-time performance and security of large-scale API control.

[0111] In a preferred embodiment of the present invention, step 4 includes:

[0112] In this embodiment of the invention, step 400 involves deploying two parallel monitoring nodes on the API request processing path of each security subdomain. These two monitoring nodes collect API call request data from clients within their respective security subdomains and response data returned by the server. Specifically, this includes: determining the API request processing path corresponding to each security subdomain, which is the core link through which request data is transmitted from the client to the server after initiating an API call; deploying two monitoring nodes at the same level on the API request processing path for each security subdomain; the two nodes operating in parallel; and each node establishing a unique association with the security subdomain to ensure that each monitoring node only collects API call data within its own security subdomain and does not collect data from other security subdomains. Simultaneously, configuring the startup mechanism of the two monitoring nodes to ensure that they work in parallel with the API request processing path of each security subdomain. The server's API processing process starts synchronously to ensure that the monitoring nodes can collect data normally when the server starts receiving API requests. The API call request data to be collected by the two monitoring nodes includes the request initiation time information (accurate to milliseconds UTC time), the client identifier in the request header, which is consistent with the client unique identifier collected in step 300, the API interface identifier in the request line, including the interface path, function name and version number, all field names and field value types in the request body, and the size of the request data packet in bytes. The server response data to be collected includes the response completion time information (accurate to milliseconds UTC time), the response status code in the response header, the core field names and field value types in the response body, the size of the response data packet in bytes, and the encryption status of the response data (marking whether it is encrypted transmission).

[0113] Two monitoring nodes synchronously collect request and response data for every API call within their respective security subdomains, according to the set collection range. The collection frequency is completely synchronized with the API call frequency; that is, when a client initiates an API call, both nodes simultaneously complete a data collection. During the collection process, the two nodes perform a preliminary comparison of the collected data in real time. The comparison includes four core fields: request time, client identifier, API interface identifier, and response status code. If the core fields in the same call data collected by the two nodes are inconsistent, a data verification mechanism is triggered, and the call data is re-collected and compared again until the core fields collected by the two nodes are consistent, ensuring the accuracy of the collected data. At the same time, the two nodes store the complete collected data in chronological order, forming a double data backup to avoid data loss due to the failure of a single node.

[0114] Step 401: Based on API call request data and response data, extract the feature distribution data of the corresponding security subdomain to generate a dynamic access control policy that includes interface access control rules, frequency limit rules, and data range control rules. Specifically, this includes: collecting and verifying API call request data and response data from two monitoring nodes, and statistically analyzing the feature distribution data of the security subdomain according to a time period (set to 24 hours). This involves statistically analyzing the API interface identifiers and the number of calls to each interface within this period to form an interface call frequency distribution; statistically analyzing the maximum number of API calls per client per unit time (set to 5 minutes) within this period to form a client call frequency distribution; statistically analyzing the field types, field value ranges, and frequency of occurrence of sensitive fields in the request and response data within this period to form a data field distribution; and statistically analyzing the number of occurrences of all response status codes within this period, with a focus on the distribution of abnormal status codes such as 403 insufficient permissions and 400 parameter error to form a response status distribution. Integrating the above interface call frequency distribution, client call frequency distribution, data field distribution, and response status distribution constitutes the feature distribution data of the security subdomain.

[0115] Based on the API call frequency distribution in the feature distribution data, the top 90% of APIs in terms of call frequency within this security subdomain are selected and included in the list of allowed access APIs. For the bottom 10% of APIs, their corresponding response status codes are analyzed. If the percentage of abnormal status codes exceeds 50%, these APIs are included in the list of prohibited access APIs. If the percentage of abnormal status codes is less than 50%, they are included in the list of APIs requiring approval for access. Simultaneously, for each API in the list of allowed access APIs, a range of client identifiers (based on clients with no abnormal call records in the client call frequency distribution) is associated with it to form API access control rules. The rules include allowed API identifiers, the range of accessible clients, prohibited API identifiers, and API identifiers requiring approval for access. Based on the client call frequency distribution in the feature distribution data, the average number of calls made by all clients within this security subdomain per unit time is calculated. This is done by adding up the number of calls made by all clients within this security subdomain per unit time, dividing the sum by the total number of clients, and obtaining the average number of calls made by all clients per unit time.

[0116] Next, the deviation of all client call counts from the average is calculated. This is done by subtracting the average from the number of calls made by each client per unit time. The squares of all these differences are then summed. This sum is divided by the total number of clients to obtain the variance. The square root of this variance is then taken to obtain the deviation of all client call counts from the average. The average plus three times the deviation is used as the maximum allowed call frequency per unit time for this security subdomain. This is calculated by multiplying the deviation by 3, then adding three times the deviation to the average. Furthermore, clients with different call frequencies are further segmented. For clients with fewer calls per unit time than the average, their maximum allowed call frequency is set to the average plus one time the deviation. This is calculated by multiplying the deviation by 1, then adding one time the deviation to the average. The maximum allowed call frequency for each client is determined as follows: For clients whose call count per unit time falls between the average and the average plus twice the deviation, the maximum allowed call frequency is set to the average plus twice the deviation. This is calculated by multiplying the deviation by 2 to get twice the deviation, then adding the average to twice the deviation. For clients whose call count per unit time exceeds the average plus twice the deviation, the purpose of the calls must be verified. If the verification confirms a normal business requirement, the maximum allowed call frequency is set to the previously calculated maximum allowed call frequency per unit time, i.e., the average plus three times the deviation. If the verification reveals suspicious abnormal calls, the maximum allowed call frequency is set to the average plus one time the deviation (calculated by multiplying the deviation by 1 to get one time the deviation, then adding the average to one time the deviation). The calculated maximum allowed call frequency per unit time and the maximum allowed call frequencies for clients with different call frequencies are integrated to form a frequency restriction rule.

[0117] Based on the data field distribution in the feature distribution data, first determine the field types and corresponding value ranges of the request and response data under normal business conditions within this security subdomain. For non-sensitive fields, first extract all historical values ​​of the field from the feature distribution data, and statistically determine the maximum and minimum values ​​among these values. Set the allowed value range of the non-sensitive field to be between the maximum and minimum values ​​of the field in the feature distribution data to ensure that the values ​​of non-sensitive fields conform to normal business logic. For sensitive fields, there are two categories: fields containing user identity information and fields containing core business parameters. Fields containing user identity information include user ID card numbers, user-bound mobile phone numbers, etc. Fields containing core business parameters include permission identifiers related to core business logic, access codes related to core resources, and verification values ​​related to core rights, etc.

[0118] For these sensitive fields, on the one hand, the allowed transmission method is set to encrypted transmission to prevent data from being stolen or tampered with during transmission; on the other hand, their values ​​are required to conform to preset format requirements, such as user ID numbers needing to conform to 18-digit format (the last digit can be X), user mobile phone numbers needing to conform to 11-digit format, and permission identifiers in core business parameters needing to conform to preset alphanumeric combination formats, etc. At the same time, the return range of sensitive fields is restricted, that is, when returning response data to the client, only sensitive fields directly related to the current business request initiated by the client are filtered out and returned, and sensitive fields unrelated to the current business request are prohibited from being returned to prevent the leakage of irrelevant sensitive information. The above-determined non-sensitive field value range, sensitive field transmission method, and sensitive field return range are integrated to form a data range control rule; then the previously generated interface access control rules and frequency restriction rules are integrated with this data range control rule to finally form the dynamic access control policy for this security subdomain.

[0119] Step 402: Execute the dynamic access control policy, adjust the list of API interfaces allowed for client access, the maximum allowed call frequency, and the allowed data range within the corresponding security subdomain, and generate a policy execution log containing interface permission change records, frequency limit records, and data range control records. Specifically, this includes: configuring interface access permissions for the security subdomain in the server's API access control module according to the interface access control rules in the dynamic access control policy; adding interface identifiers from the allowed access interface list to the allowed access list to ensure that when a client initiates a call request to these interfaces, the request can proceed normally into the subsequent processing flow; adding interface identifiers from the prohibited access interface list to the prohibited access list, so that when a client initiates a call request to these interfaces, a 403 insufficient permissions response is returned directly; adding interface identifiers from the access-requiring interface list to the approval list, so that when a client initiates a call request to these interfaces, the approval process is triggered, and the request is allowed to proceed into the subsequent processing flow only after approval; each time the allowed access list, prohibited access list, and approval list are adjusted, the interface permission change content is recorded, including the interface permission status before the change, the interface permission status after the change, the change time, and the operator who performed the change, forming an interface permission change record.

[0120] Based on the frequency limiting rules in the dynamic access control policy, the frequency limiting parameters for this security subdomain are configured in the server's call frequency control unit. Specifically, the maximum allowed call frequency per unit time is set to the global frequency threshold. That is, the unit time is set to 5 minutes, and the global frequency threshold is set to 1000 calls. This means that the maximum number of calls allowed by all clients within this security subdomain within 5 minutes is 1000. When the total number of calls by all clients within this security subdomain reaches the global frequency threshold per unit time, accepting new call requests is suspended until the next unit time, i.e., the next 5-minute cycle begins. A personal maximum allowed call frequency is also configured for each client, such as 50 calls / 5 minutes for low-frequency clients and 100 calls / 5 minutes for medium-frequency clients. The frequency limit is set at 150 calls per 5 minutes, and 300 calls per 5 minutes for high-frequency clients in normal business operations. When a single client's number of calls per unit time reaches its maximum allowed call frequency, a 429 response is returned to that client for excessively frequent requests. During the frequency limit execution process, the circumstances of each frequency limit trigger are recorded in real time, including the client identifier that triggers the limit, the call frequency at the time of triggering (e.g., a client makes 51 calls within 5 minutes, reaching the personal threshold of 50 calls), the trigger time, and the returned response status code 429. At the same time, the adjustment of the frequency limit parameters is recorded, including the frequency threshold before adjustment (e.g., the original global threshold of 1000 calls per 5 minutes), the frequency threshold after adjustment (e.g., adjusted to 1200 calls per 5 minutes), and the adjustment time, forming a frequency limit record.

[0121] Based on the data range control rules in the dynamic access control policy, data validation and filtering parameters are configured in the server's data packet parsing unit. For request data, the system validates whether the values ​​of its fields are within the allowed range. For example, the allowed range for the order amount field is 0.01 yuan to 100,000.00 yuan. If a field value exceeds this range, such as an order amount of 150,000.00 yuan, a 400 parameter error response is returned. The system also validates whether sensitive fields are transmitted using encryption. For example, the user's bank card number field must be transmitted using the AES-256 algorithm. If it is not encrypted, a 400 parameter error response is returned. For response data, irrelevant sensitive fields are filtered out. For example, when a client requests to query order status, irrelevant sensitive fields such as the user's bank card number and payment key are filtered out, retaining only sensitive fields related to the client's business, such as the order payment time. The system also ensures that the format of sensitive fields meets the requirements. During the data range control process, each instance of data validation failure is recorded. The log records the following information: the client identifier that initiated the request, the name of the field that failed verification (e.g., order amount, actual value of 150,000.00 yuan, allowed value range of 0.01 yuan to 100,000.00 yuan), verification time, and the returned response status code 400. It also records data filtering information, including the names of filtered sensitive fields (e.g., user bank card number, payment key), filtering time, and the size of the filtered response data in bytes (e.g., 2048 bytes), forming a data range control record. The log integrates interface permission change records, frequency limit records, and data range control records in chronological order to form a policy execution log. Each record in the log includes the record type (e.g., frequency limit record, data range control record), execution content (e.g., client A triggers personal frequency threshold, returning a 429 response; order amount field value exceeds limit, returning a 400 response), execution time, and associated client or interface information (e.g., associated client A identifier, associated order creation interface identifier).

[0122] Step 403: Based on the policy execution logs and API call behavior data collected by monitoring nodes, generate security posture data including security event statistics and risk level analysis. Specifically, this includes: extracting abnormal events from interface permission change records, frequency restriction records, and data scope control records from the policy execution logs; classifying call attempts to interfaces in the prohibited access interface list and unapproved call attempts to interfaces in the approved access interface list as permission abnormal events; and counting the number of permission abnormal events, the number of clients involved, and the number of interfaces involved per unit time; classifying call requests that trigger frequency restrictions as frequency abnormal events; and counting the number of frequency abnormal events, the number of clients involved, and the number of clients involved per unit time. The system tracks the number of times the maximum consecutive trigger frequency of data anomalies occurs; requests that fail data validation are categorized as data anomaly events, and the number of data anomaly events occurring per unit time, the number of clients involved, and the distribution of various types of data anomalies (field value exceeding limits, unencrypted sensitive fields, etc.) are statistically analyzed; simultaneously, from the API call behavior data collected by the monitoring nodes, call records with response status codes of 500 Server Error and 404 Interface Not Found are extracted and categorized as service anomaly events, and the number of service anomaly events occurring per unit time and the number of interfaces involved are statistically analyzed. The statistical results of permission anomaly events, frequency anomaly events, data anomaly events, and service anomaly events are integrated to form security event statistics.

[0123] Risk level determination criteria are set based on security incident statistics. If the total number of abnormal events per unit time is less than 1% of the total number of calls within that time period, and there are no more than three consecutive abnormal events of the same type, the risk level is determined to be low risk. If the total number of abnormal events is between 1% and 5%, or there are three to five consecutive abnormal events of the same type, the risk level is determined to be medium risk. If the total number of abnormal events is greater than 5%, or there are more than five consecutive abnormal events of the same type, the risk level is determined to be high risk. Adjustments are made based on the severity of the security incident. If there are high-frequency permission abnormal events, such as more than 10 per unit time, or if the data abnormal events involve core sensitive fields, such as ID card numbers or core business parameters, the risk level is increased by one level. Based on the above determination criteria, a risk level assessment is conducted for each security subdomain, and the assessed risk level, assessment criteria (percentage of abnormal events, number of consecutive abnormal events, and severity of abnormal events), and assessment time are recorded to form risk level analysis data.

[0124] Security incident statistics and risk level analysis data are integrated according to a time period (set to 24 hours). Within each time period, the security incident statistics are presented first, including the number of occurrences, scope, and distribution of various abnormal events. Then, the risk level analysis results are presented, including the risk level of the security subdomain, the basis for the level determination, and a comparison with the risk level of the previous period. Finally, for medium and high risk levels, preliminary risk response suggestions are proposed, such as verifying the clients making abnormal calls, optimizing frequency limit parameters, and strengthening the validation of sensitive fields. The above content is arranged in chronological order to form the security posture data of the security subdomain, ensuring that the data can clearly reflect the trend of changes in the security status of API calls within the security subdomain.

[0125] This embodiment, from the perspective of data acquisition reliability, ensures the accuracy and integrity of API call request and response data through a dual-monitoring node parallel acquisition and data verification mechanism, avoiding data loss or errors caused by single node failure. Based on the characteristic distribution data of the security subdomain, dynamic access control policies are generated to achieve fine-grained control over API interface access, call frequency, and data scope. Compared with fixed control policies, this reduces restrictions on normal business calls while effectively intercepting abnormal call behavior, improving the accuracy of API access control. Security posture data is generated through policy execution logs and API call behavior data, clearly presenting the distribution of abnormal events and changes in risk levels within the security subdomain. This allows administrators to monitor the security status of API calls in real time, promptly identify potential security risks, and take countermeasures. The dynamic access control policy can be adjusted in real time according to changes in the characteristics of the security subdomain, and the security posture data can quickly reflect changes in risk levels, intercepting abnormal behavior in advance, reducing the probability of security incidents, and improving risk prevention and control capabilities during API calls.

[0126] In a preferred embodiment of the present invention, step 5 includes:

[0127] In this embodiment of the invention, step 500 involves real-time monitoring of permission change records in the policy execution log and security event statistics in the security posture data to obtain monitoring results; based on the monitoring results, identifying three status change scenarios for digital certificates, including certificate expiration, permission change, and security risk event; when a certificate expiration scenario is identified, sending a revocation request for the corresponding digital certificate to the certificate authority; when a permission change scenario is identified, sending a reissue request for the corresponding digital certificate to the certificate authority; and when a security risk event scenario is identified, sending an emergency revocation request for the corresponding digital certificate to the certificate authority. Specifically, this includes: first determining the specific content of the monitoring object, i.e., permission change records in the policy execution log, and monitoring the interface permission change type in the records, such as adding an allowed access interface, removing an allowed access interface, changing an access interface requiring approval, the digital certificate identifier involved in the change (consistent with the unique identifier in the certificate), and the change time; and monitoring the security posture data... Security incident statistics require monitoring the types of abnormal events (permission anomalies, frequency anomalies, data anomalies), the digital certificate identifiers involved in the events, the event occurrence time, and the cumulative number of occurrences. The monitoring frequency is set to once per second to ensure real-time capture of the latest records and statistical data, avoiding the omission of key information. According to the set monitoring rules and frequency, permission change records and security incident statistics are scanned in real time. Specifically, the latest generated permission change records are extracted from the policy execution log every second, recording the certificate identifier, change type, and change time for each record. Simultaneously, the latest security incident statistics are extracted from the security posture data, recording the certificate identifier, event count, and the most recent event occurrence time for each type of abnormal event. The extracted permission change record information and security incident statistics are then linked and integrated according to the certificate identifier to form a monitoring result centered on the certificate identifier. The monitoring result must include permission change details, abnormal event details, and time information for each certificate.

[0128] Based on the monitoring results, three scenarios are identified according to the following criteria:

[0129] Identifying certificate expiration: Extract the expiration time of each certificate from the basic information of the digital certificates associated with the monitoring results, which is pre-stored in the certificate management database, including the certificate's effective date, expiration date, and certificate identifier; obtain the current system's UTC time and compare the current time with the certificate's expiration date; if the current time is later than the certificate's expiration date and no re-issuance record for the certificate has been received, it is determined that a certificate expiration has been identified, and the certificate's identifier and expiration date are recorded.

[0130] Identify permission change scenarios: Check the permission change records corresponding to each certificate in the monitoring results. If there are records of interface permission change types such as adding an allowed access interface, removing an allowed access interface, or changing an access interface that requires approval, and the change time is within the last 24 hours, and the change has not triggered the certificate re-issuance process (confirmed by querying the certificate issuance log), then it is determined that a permission change scenario has been identified, and the certificate identifier, permission change type, and change content are recorded.

[0131] Identify security risk events: Review the security event statistics for each certificate in the monitoring results. If the number of permission-related abnormal events exceeds 5 in the past hour, or if the data abnormal events involve core sensitive fields such as user ID numbers or core business parameters and the number of occurrences exceeds 3 in the past hour, or if there are 10 consecutive records of frequency limit triggering in frequency abnormal events, then a security risk event is identified. Record the certificate identifier, abnormal event type, and cumulative number of occurrences.

[0132] Based on the identified scenarios, a corresponding request is generated and sent. Specifically, a revocation request is sent (for certificate expiration cases), generating a revocation request file containing the request type (regular revocation, certificate identifier, certificate expiration time, request initiation time (current UTC time), and initiator identifier (the server's unique organization identifier). This request file is then sent to the certificate authority's revocation request receiving port (port number pre-defined as 4443) via a pre-defined encrypted communication channel (using SSL / TLS protocol), recording the request sending time and request number. Finally, a reissue request is sent (for permission change cases), generating a reissue request file containing the request type (reissue, certificate identifier, latest permission change details, such as the list of newly added allowed access interfaces, the list of removed allowed access interfaces, the certificate's current validity period, and the request details). The process involves: initiating the request and sending it via an encrypted communication channel to the Certificate Authority's (CA) reissue request receiving port (port number pre-defined as 4444), recording the request sending time and request number; sending an emergency revocation request (for security risk events), generating an emergency revocation request file containing the request type (emergency revocation, certificate identifier, security risk event type and cumulative number, most recent event occurrence time, request initiation time, and initiator identifier); prioritizing the transmission of the request file to the CA's emergency request receiving port (port number pre-defined as 4445, which has higher processing priority than other ports) via an encrypted communication channel, recording the request sending time and request number, and immediately generating an emergency notification, which is simultaneously sent to the server's security management module to alert administrators to the security risk event.

[0133] Step 501: After receiving a revocation request, the Certificate Authority (CA) adds the corresponding digital certificate to the certificate revocation list. After receiving a reissue request, the CA regenerates the digital certificate based on the latest permission information. The regenerated digital certificate is distributed to the corresponding client or server through a secure channel, and the digital certificate status database is updated to record the entire process of certificate revocation, reissue, and distribution. Specifically, the CA's request receiving unit listens in real time on three ports: 4443 (regular revocation), 4444 (reissue), and 4445 (emergency revocation). When a request is received on a port, the CA first verifies the identity of the request initiator, queries the pre-stored initiator public key using the initiator identifier in the request file, and uses the public key to access the request. The system retrieves the digital signature in the file (the request file contains the initiator's digital signature for authentication) and decrypts it. If decryption is successful and the decryption result matches the hash value of the request file (the hash value of the request file is calculated and compared with the decrypted hash value), the request is deemed legitimate. If decryption fails or the hash values ​​do not match, the request is deemed illegitimate, and the system refuses to process it, returning an invalid response message to the initiator. For legitimate regular revocation requests (from port 4443) or emergency revocation requests (from port 4445), the system extracts the certificate identifier from the request file, queries the certificate authority's certificate database, and confirms the existence and current status of the certificate (not revoked). If the certificate does not exist or has been revoked, the system returns an invalid response message to the initiator.

[0134] If the certificate exists and has not been revoked, its identifier, revocation request type (regular / urgent), revocation request reception time (current UTC time), and request number are entered into the certificate revocation list. The certificate revocation list is sorted by revocation request reception time, with records corresponding to urgent revocation requests marked with an urgent identifier, giving them higher priority than regular revocation records. The updated certificate revocation list is synchronized to the public certificate revocation query server every hour to ensure that clients and servers can query the latest revocation information. Simultaneously, a response indicating that the revocation request has been accepted is returned to the request initiator, including the request number and processing time for verification. For legitimate reissue requests (from port 4444), the certificate identifier, latest permission changes, and current certificate validity information are extracted from the request file; certificate data is then queried. The system retrieves the original certificate information, including certificate holder information, public key information, and original permission information, confirming that the certificate has not expired or been revoked. If the certificate has expired or been revoked, it returns a response to the initiator indicating that the certificate status is abnormal and cannot be reissued. If a new allowed access interface is added, the list of new interfaces is added to the certificate's permission field. If an allowed access interface is removed, the corresponding interface list is deleted from the permission field. If an access interface requiring approval is changed, the approval interface list in the permission field is updated. The updated certificate information is signed using the certificate authority's root private key to generate a new digital certificate. The new certificate's effective date is set to the current UTC time, and the expiration date is extended by the original certificate's validity period. For example, if the original certificate's validity period is 1 year, the new certificate's expiration date is set to the current time plus 1 year to ensure continuous validity.

[0135] After the Certificate Authority (CA) generates a new certificate, it determines the certificate distribution recipient. This is done by querying the certificate holder information based on the certificate identifier in the request file. If the certificate is a client certificate, the distribution recipient is the corresponding client; if it is a server certificate, the distribution recipient is the corresponding server. Using an SSL / TLS encrypted communication channel, the new certificate is sent in binary stream format to the certificate receiving port of the distribution recipient (client port pre-defined as 4446, server port pre-defined as 4447). After distribution, the CA receives a certificate receipt confirmation message from the distribution recipient. If no confirmation message is received, the certificate is re-distributed within 5 minutes, up to a maximum of 3 times. If the re-distribution still fails, a distribution failure message is recorded and the initiator is notified. The original certificate status is updated in the database. For certificates that have been revoked, record the revocation time and reason (re-issuance due to permission change); for newly added certificates, record the new certificate identifier, effective time, expiration time, permission information, distribution recipients, distribution time, and issuing authority identifier; also record the entire process of certificate re-issuance, including request number, request receipt time, issuance completion time, distribution time, and confirmation of receipt time. Record the entire certificate operation process. Whether it is a revocation request or a re-issuance request, the certificate issuing authority must establish an operation log, recording the request number, request type, request receipt time, request initiator identifier, certificate identifier, processing result (success / failure), processing time, and relevant operators (if manual review is involved) for each operation; the operation log is stored in chronological order and retained for 3 years.

[0136] This embodiment accurately identifies three scenarios—certificate expiration, permission changes, and security risks—by monitoring permission changes and security events in real time, and triggers corresponding revocation or reissue processes. This avoids API call security risks caused by abnormal certificate status, such as permission mismatches. Compared to manual certificate management, it achieves automated and dynamic management of certificate status, improving the timeliness and accuracy of certificate management. For security risk events, it sends emergency revocation requests. The certificate authority prioritizes handling emergency requests and updates the revocation list promptly, quickly blocking API calls corresponding to certificates with security risks, reducing the impact of abnormal events on servers or clients, and improving the response speed and handling efficiency of security risks. The entire process of certificate revocation, reissue, and distribution is recorded, including request information, processing time, and results, forming a complete operation log and database record, improving the transparency and traceability of certificate management.

[0137] like Figure 2 As shown, embodiments of the present invention also provide a large-scale API management system based on digital certificates, comprising:

[0138] The distribution module is used to issue digital certificates to the client that initiates the API call request and the server that provides large model service capabilities, and to complete the certificate distribution through a secure channel.

[0139] The authentication module is used to perform two-way authentication between the client and the server when initiating an API request based on digital certificates, and to establish a trusted communication link after successful two-way authentication.

[0140] The security subdomain module is used to collect client API call behavior data sequences in real time based on a secure communication link, and extract feature parameters in six dimensions: call frequency, interface type, data sensitivity, request load, response latency, and access sequence. Based on the feature parameters, a six-dimensional security evaluation matrix is ​​constructed, and the matrix is ​​divided into eight security subdomains through a clustering algorithm. The client behavior feature vectors are then mapped to the corresponding security subdomains.

[0141] The execution module is used to deploy two redundant monitoring nodes on the core service path of each security subdomain to collect API call behavior data of clients in each subdomain in real time, and generate dynamic access control policies based on the characteristic distribution of each subdomain; execute the policy to adjust the list of API interfaces accessible to clients in each subdomain, call frequency thresholds and data access range in real time, and generate policy execution logs and security posture data.

[0142] The proactive management module is used to monitor and proactively manage the status of issued digital certificates based on policy execution logs and security posture data. It tracks certificate validity in real time, performs certificate revocation operations when certificates expire, permissions are changed, or security risk events are detected, and triggers certificate re-issuance and update processes.

[0143] It should be noted that this system is a system corresponding to the above method. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0144] Embodiments of the present invention also provide a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0145] Embodiments of the present invention also provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0146] This invention's technical solution is merely a technical control method and system design, aimed at improving the legality of large-scale API calls and the efficiency of risk response. It does not guarantee the complete avoidance of all security risks (including but not limited to system anomalies caused by extreme network attacks or force majeure). The handling of "user privacy information" mentioned in the solution (such as data sensitivity classification and sensitive field encryption) must be carried out by the implementing party in compliance with laws and regulations. This invention assumes no legal responsibility for privacy leaks or data security issues caused by the implementing party's non-compliant operations. The digital certificate issuance, revocation, data collection, and storage processes described in this invention rely on the implementing party building a hardware environment, key management system, and access control mechanism that meet security standards. This invention assumes no responsibility for security issues caused by defects in the implementing party's technical deployment (such as improper key storage or system vulnerabilities).

[0147] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for managing large-scale APIs based on digital certificates, characterized in that, The method includes: Step 1: Issue digital certificates to the client that initiates the API call request and the server that provides large model service capabilities, and complete the certificate distribution through a secure channel; Step 2: Based on digital certificates, the client performs mutual authentication with the server when initiating an API request, and establishes a trusted communication link after successful mutual authentication. Step 3: Based on the secure communication link, collect client API call behavior data sequences in real time, and extract feature parameters in six dimensions: call frequency, interface type, data sensitivity, request load, response latency, and access sequence. Based on the feature parameters, construct a six-dimensional security assessment matrix, divide the matrix into eight security subdomains through a clustering algorithm, and map the client behavior feature vectors to the corresponding security subdomains. Step 4: Deploy two redundant monitoring nodes on the core service path of each security subdomain to collect API call behavior data of clients in each subdomain in real time, and generate dynamic access control policies based on the characteristic distribution of each subdomain; execute the policies to adjust the list of API interfaces accessible to clients in each subdomain, call frequency thresholds and data access range in real time, and generate policy execution logs and security posture data. Step 5: Based on policy execution logs and security posture data, implement status monitoring and proactive management of issued digital certificates, track certificate validity in real time, and execute certificate revocation operations when certificates expire, permissions change, or security risk events are detected, and trigger certificate reissue and update processes.

2. The method for managing large-scale APIs based on digital certificates according to claim 1, characterized in that, Step 1 includes: Step 100: Issue a digital certificate for the client that initiates the API call request. The structured data fields embedded in the client's digital certificate contain a unique identifier for client authentication and authorization service level information for defining client access permissions. Issue a digital certificate for the server that provides large model service capabilities. The structured data fields embedded in the server's digital certificate contain a unique identifier for server authentication. Step 101: Distribute the client's digital certificate to the corresponding client through a secure channel; distribute the server's digital certificate to the corresponding server through a secure channel to complete the certificate distribution.

3. The method for managing large-scale APIs based on digital certificates according to claim 2, characterized in that, Step 2 includes: Step 200: When initiating an API request, the client sends its digital certificate to the server and requests the server's digital certificate; after receiving the request, the server sends its digital certificate to the client; the client verifies the validity and validity of the server's digital certificate. Step 202: After the client's digital certificate is verified, the server verifies the authenticity of the client's digital certificate and the validity of the permissions contained in the authorized service level information in the client's digital certificate. Step 203: After both the client's digital certificate verification and the server's digital certificate verification are successful, a trusted communication link is established between the client and the server.

4. The method for managing large-scale APIs based on digital certificates according to claim 3, characterized in that, Step 3 includes: Step 300: Collect and record each API call behavior of the client in real time through a trusted communication link to form a client API call behavior data sequence arranged in chronological order; Step 301: Process the client API call behavior data sequence and extract the six-dimensional feature parameters of each call. Among them, the call frequency feature parameter is the number of requests per unit time, the interface type feature parameter is the specific API endpoint identifier called, the data sensitivity feature parameter is the data confidentiality level in the request and response, the request load feature parameter is the size of the request data packet, the response latency feature parameter is the time taken for the server to process the request, and the access time sequence feature parameter is the timestamp sequence of the call. Step 302: Normalize the feature parameters of the six dimensions to form a six-dimensional security assessment matrix. Each row of the security assessment matrix represents a client behavior feature vector within a time unit. Step 303: The security assessment matrix is ​​processed using a clustering algorithm. Based on the similarity between feature vectors, the entire feature space is divided into eight different security subdomains. Each security subdomain represents an API call behavior pattern. Step 304: Calculate the spatial distance between the real-time collected client behavior feature vector and the center point of the eight security subdomains to obtain the distance value between the corresponding feature vector and the center point of each security subdomain; based on the distance value, classify the client behavior feature vector into the security subdomain with the smallest distance value.

5. The method for managing large-scale APIs based on digital certificates according to claim 4, characterized in that, Step 303 includes: Step 303c: Based on the first round of feature vector allocation results, calculate the mean of all feature vectors in each category to obtain the first round of new cluster centers; calculate the offset between the first round of new cluster centers and the initial cluster centers, and determine whether the offset is less than a preset threshold; when the offset is greater than or equal to the preset threshold, calculate the second round of spatial distance between the feature vectors and each cluster center based on the first round of new cluster centers to obtain the second round of spatial distance calculation results; Step 303d: Based on the spatial distance calculation results of the second round, assign each feature vector to the second round clustering category whose spatial distance meets the preset conditions; repeat the cluster center update and feature vector assignment until the offset between the new cluster center of the Nth round and the cluster center of the N-1th round is less than the preset threshold, and finally determine the eight clustering regions as eight safe subdomains.

6. The method for managing large-scale APIs based on digital certificates according to claim 5, characterized in that, Step 4 includes: Step 400: For each security subdomain, deploy two monitoring nodes that work in parallel on the API request processing path of the corresponding security subdomain. Through the two monitoring nodes, collect API call request data issued by clients within the security subdomain and response data returned by the server. Step 401: Based on API call request data and response data, extract the feature distribution data of the corresponding security subdomains and generate a dynamic access control policy that includes interface access control rules, frequency restriction rules and data range control rules; Step 402: Execute dynamic access control policies, adjust the list of API interfaces that clients are allowed to access, the maximum allowed call frequency, and the allowed data range within the corresponding security subdomain, and generate policy execution logs that include interface permission change records, frequency limit records, and data range control records; Step 403: Based on the policy execution logs and API call behavior data collected by monitoring nodes, generate security posture data that includes security event statistics and risk level analysis.

7. The method for managing large-scale APIs based on digital certificates according to claim 6, characterized in that, Step 5 includes: Step 500: Monitor the permission change records in the policy execution log and the security event statistics in the security posture data in real time to obtain monitoring results; based on the monitoring results, identify three status change scenarios for digital certificates, including certificate expiration, permission change, and security risk event; when a certificate expiration scenario is identified, send a revocation request for the corresponding digital certificate to the certificate authority; when a permission change scenario is identified, send a reissue request for the corresponding digital certificate to the certificate authority; when a security risk event scenario is identified, send an emergency revocation request for the corresponding digital certificate to the certificate authority. Step 501: After receiving the revocation request, the Certificate Authority (CA) adds the corresponding digital certificate to the certificate revocation list; after receiving the reissue request, the CA regenerates the digital certificate based on the latest permission information; the regenerated digital certificate is distributed to the corresponding client or server through a secure channel, and the digital certificate status database is updated to record the entire process of certificate revocation, reissue, and distribution.

8. A large-scale API management system based on digital certificates, the system implementing the method as described in any one of claims 1 to 7, characterized in that, include: The distribution module is used to issue digital certificates to the client that initiates the API call request and the server that provides large model service capabilities, and to complete the certificate distribution through a secure channel. The authentication module is used to perform two-way authentication between the client and the server when initiating an API request based on digital certificates, and to establish a trusted communication link after successful two-way authentication. The security subdomain module is used to collect client API call behavior data sequences in real time based on a secure communication link, and extract feature parameters in six dimensions: call frequency, interface type, data sensitivity, request load, response latency, and access sequence. Based on the feature parameters, a six-dimensional security assessment matrix is ​​constructed. The matrix is ​​divided into eight security subdomains by a clustering algorithm, and the client behavior feature vectors are mapped to the corresponding security subdomains. The execution module is used to deploy two redundant monitoring nodes on the core service path of each security subdomain to collect API call behavior data of clients in each subdomain in real time, and generate dynamic access control policies based on the characteristic distribution of each subdomain; execute the policy to adjust the list of API interfaces accessible to clients in each subdomain, call frequency thresholds and data access range in real time, and generate policy execution logs and security posture data. The proactive management module is used to monitor and proactively manage the status of issued digital certificates based on policy execution logs and security posture data. It tracks certificate validity in real time, performs certificate revocation operations when certificates expire, permissions are changed, or security risk events are detected, and triggers certificate re-issuance and update processes.

9. A computing device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images