Distributed API (Application Program Interface) key management and access control method and system based on zero-trust architecture

Abstract

The invention discloses a distributed API key management and access control method and system based on a zero-trust architecture, and relates to the technical field of computer network security, and the method comprises the steps: calling an API key according to a user request; carrying out encryption storage on the complete key based on a multilayer encryption storage mechanism, and extracting a part of keys for plaintext storage; extracting a target plaintext key of the API key based on a ParalKey rapid matching and selective decryption mechanism, and rapidly positioning a potentially matched encryption record through a database index to perform first-stage verification; and after the first-stage verification is passed, a complete key corresponding to the target plaintext key is acquired and decrypted, and the decrypted complete key is completely compared with the key input by the user to perform second-stage verification until the verification is passed, and the key is stored in the two-stage cache. Even if the DBA can completely access the database, the security of the API key and the sensitive data can be ensured, the key verification of high-frequency access is ensured to be completed rapidly, and resource optimization is realized.

Description

Technical Field

[0001] The present invention relates to the field of computer network security technology, and in particular to a distributed API key management and access control method and system based on a zero-trust architecture. Background Art

[0002] Traditionally, there is no partial plaintext storage. Existing solutions, such as those for compliance requirements, encrypt key user fields in the database. This results in each request requiring the user's plaintext to be first encrypted and then compared with the ciphertext, which is time-consuming and inefficient. Similarly, in the current cloud computing and AI service environment, API key management faces the following challenges: 1. Traditional systems typically store API keys in plaintext or with simple hashes in the database; 2. Database administrators (DBAs) can directly view and modify sensitive information; 3. The lack of fine-grained access control and resource isolation mechanisms makes it impossible to address internal threats, especially the abuse of privileged accounts.

[0003] In summary, the limitation of existing technologies is that once the database is breached or internal personnel (such as DBAs) gain access, all API keys and sensitive information are immediately exposed, and true data security cannot be provided. Summary of the Invention

[0004] This application proposes a distributed API key management and access control method and system based on zero-trust architecture. Through the design of zero trust and layered defense, combined with a two-stage mechanism of "coarse-grained initial screening + fine-grained verification", it can ensure the security of API keys and sensitive data even when the DBA has full access to the database.

[0005] The present invention provides a distributed API key management and access control method based on a zero-trust architecture, comprising: Call the API key based on user request; Based on a multi-layer encryption storage mechanism, the complete key is encrypted and stored, and part of the key is extracted and stored in plain text, so that the encryption key and the encrypted data are stored separately; Extract the target plaintext key of the API key based on the PartialKey fast matching and selective decryption mechanism, and quickly locate potential matching encrypted records through the PostgreSQL database index for the first stage of verification; After the first stage of verification is passed, the complete key corresponding to the target plaintext key is obtained and decrypted. The decrypted complete key is fully compared with the user-entered key for the second stage of verification until the verification is passed and stored in a two-level cache consisting of the primary memory and the secondary storage redis; In the first run mode, the trigger request falls into the third-level storage PostgreSQL. Once verified, it is immediately written to the cache in the first-level memory and the second-level storage Redis. Subsequent requests are directly verified in the first-level memory. In normal operation mode, key verification is performed in the order of primary memory, secondary storage redis cache, and finally tertiary storage postgreSQL.

[0006] Preferably, the method of encrypting and storing the complete key and extracting a portion of the key for plaintext storage based on a multi-layer encryption storage mechanism so that the encryption key and the encrypted data are stored separately includes: Receive user registration request and generate API key with target digits; Encrypt the complete key using ChaCha20Poly1305 to obtain the encrypted ciphertext; Extract the target number of bits of the key as the target plaintext key; Store the generated final key in the database; The final key record includes the complete ciphertext and the target plaintext key as an index.

[0007] As a preference, it also includes: In cold start mode, initiate an API request to call the API key; The plaintext key of the target number of bits is extracted through a two-stage verification. The decrypted complete key is fully compared with the user-entered key, and the verification is passed after the comparison is consistent.

[0008] As a preference, it also includes: In cache hit mode, Extract the target number of plaintext keys; Check whether there is a mapping relationship between the target plaintext key and the complete key in the memory cache; If the corresponding mapping relationship is found in the memory, the verification is passed directly.

[0009] As a preference, it also includes: In memory cache expiration mode, Check whether there is a mapping relationship between the target plaintext key and the complete key in the memory cache; If no corresponding mapping is found in the memory cache, the Redis cache is checked to find the mapping between the target plaintext key and the complete key. When verification is successful, the mapping relationship is rewritten into the memory cache.

[0010] As a preference, it also includes: In Redis cache expiration mode, Check whether there is a mapping relationship between the target plaintext key and the complete key in the memory cache and Redis cache; If no corresponding mapping relationship is found in the memory cache or Redis cache, the database is accessed to search for the corresponding ciphertext data using the target plaintext key; Completely compare the decrypted ciphertext data with the user-entered key; After verification is passed, the verification results are rewritten into the memory cache and Redis cache.

[0011] Preferably, the method of extracting the target plaintext key of the API key based on the PartialKey fast matching and selective decryption mechanism further includes: Extract the partial key PartialKey from the input key provided by the user; Use PartialKey to quickly locate candidate records in the database and return only matching encryption keys; If the input key already exists in the cache, directly return the cached user information to avoid repeated calculations; Only the encrypted records matching the PartialKey are fully decrypted and compared with the input key; If the decrypted key matches the input key, the user information is returned and the cache is updated; otherwise, the next candidate record is checked.

[0012] The present invention also provides a distributed API key management and access control system based on a zero-trust architecture, comprising: Request module, used to call API keys based on user requests; A storage module is used to encrypt and store the complete key based on a multi-layer encryption storage mechanism and extract part of the key for plain text storage, so that the encryption key and the encrypted data are stored separately; The first-stage verification module is used to extract the target plaintext key of the API key based on the PartialKey fast matching and selective decryption mechanism, and quickly locate potential matching encrypted records through the postgreSQL database index for the first-stage verification; The second-stage verification module is used to obtain the complete key corresponding to the target plaintext key and decrypt it after the first-stage verification is passed. The decrypted complete key is fully compared with the user-entered key for the second-stage verification until the verification is passed and stored in the two-level cache consisting of the primary memory and the secondary storage redis; In the first run mode, the trigger request falls into the third-level storage PostgreSQL. Once verified, it is immediately written to the cache in the first-level memory and the second-level storage Redis. Subsequent requests are directly verified in the first-level memory. In normal operation mode, key verification is performed in the order of primary memory, secondary storage redis cache, and finally tertiary storage postgreSQL.

[0013] The present invention also provides an electronic device, comprising: a memory for storing a processing program; A processor, which implements the distributed API key management and access control method based on zero trust architecture as described in an embodiment of the present invention when executing the processing program.

[0014] The present invention also provides a readable storage medium, on which a processing program is stored. When the processing program is executed by a processor, the distributed API key management and access control method based on the zero trust architecture as described in an embodiment of the present invention is implemented.

[0015] Compared with the prior art, the present invention has at least one of the following beneficial effects: (1) The present invention encrypts the complete key with ChaCha20Poly1305 and stores it, retaining only part of the plaintext (PartialKey) as an index, thereby achieving "separation of encryption key and data". Even if the plaintext is leaked, the attacker cannot directly obtain the complete key. It is necessary to break through the encryption algorithm and store the encryption key and plaintext separately to reduce the risk of single point leakage.

[0016] (2) The present invention adopts the first stage (PartialKey matching): quickly screening candidate records through lightweight string comparison to reduce subsequent decryption overhead; and adopts the second stage (complete comparison): only decrypting candidate records and comparing them with the user-entered key to ensure the strictness of the final verification.

[0017] (3) The present invention uses PartialKey as an index field to quickly locate candidate records through database indexes, avoiding full table scans and decrypting only records that match the PartialKey. This significantly reduces the frequency of CPU-intensive decryption operations and reduces CPU consumption through PartialKey initial screening and caching mechanisms.

[0018] (4) The present invention adopts a multi-level cache mechanism: memory cache: accelerates high-frequency requests, directly returns the mapping relationship, and avoids repeated calculations; Redis cache: shares the cache across nodes, supports distributed deployment, and reduces database pressure; database: serves as the final backup storage, triggering decryption and comparison only when the cache misses.

[0019] (5) The first request of the present invention requires a complete two-stage verification to ensure security. Subsequent requests will first obtain results from the memory or Redis cache to reduce latency, support efficient management of massive API keys, and horizontal expansion through database indexing and cache layering.

[0020] (5) The present invention is based on a distributed API key management and access control method based on a zero-trust architecture and a multi-layered encrypted storage mechanism to achieve efficient verification: in most cases, verification is completed in memory without the need for decryption; secure storage: only ciphertext and part of the plaintext are stored in the database; layered caching: to ensure that frequently accessed key verification is completed extremely quickly; resource optimization: to reduce the frequency of CPU-intensive encryption and decryption operations. This achieves the goal of ensuring the security of API keys and sensitive data even when the DBA has full access to the database. The system is suitable for high-security scenarios such as cloud service API management, AI service access control, and multi-tenant SaaS systems, and has significant technical innovation and practical value. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 This is a flowchart of the steps of the distributed API key management and access control method based on zero trust architecture of the present invention. DETAILED DESCRIPTION

[0022] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0023] Those skilled in the art will appreciate that, unless otherwise stated, the singular forms "a," "an," "said," and "the" used herein may also include plural forms. It should be further understood that the term "comprising" used in the specification of the present invention refers to the presence of the stated features, integers, steps, operations, elements, and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0024] Traditionally, there is no partial plaintext storage. In existing solutions, such as those for compliance requirements, the key fields of users are encrypted in the database. This leads to a problem that each time a user requests something, the user's plaintext must be first encrypted and then compared with the ciphertext, which is time-consuming and inefficient. If there are 1,000 requests, decryption must be repeated 1,000 times. If this solution is not used, each call must be decrypted once. This process is time-consuming because it involves the length of the algorithm. The present invention proposes a distributed API key management and access control method based on a zero-trust architecture that only requires decryption once, and all the rest is done directly in the memory. This process is no longer necessary.

[0025] like Figure 1 As shown, an embodiment of the present invention provides a distributed API key management and access control method based on a zero-trust architecture, including: S1: Calls the API key based on user request; S2: Based on a multi-layered encryption storage mechanism, the full key is encrypted and stored in plaintext, separating the encryption key from the encrypted data. The API key encryption mechanism employed in this solution specifically includes: 1. Initializing the Encryptor (aead): Using a fixed encryptionKey (this key should be pre-configured and securely stored), an encryptor instance in AEAD (Authenticated Encryption with Associated Data) mode is created. Chacha20poly1305.NewX is used here, which typically refers to the ChaCha20-Poly1305 algorithm. X may represent a variant with an extended nonce size (NonceSizeX). If the key length does not meet the requirements, NewX returns an error. 2. Generating a Random Nonce: A unique random value, called a nonce (a one-time counter), is generated for each encryption operation. The nonce size is specified by Chacha20poly1305.NonceSizeX. Bytes are read from a cryptographically secure random source, rand.Reader, to fill the nonce. Nonces are crucial for AEAD encryption; reusing the same nonce and key combination can lead to serious security issues. 3. Performing Encryption (Seal): Use the aead.Seal method to encrypt the actual secretKey (the API key to be encrypted). The Seal method not only encrypts the data but also generates an authentication tag for subsequent verification. A nil first parameter indicates no additional associated data. The nonce and []byte(secretKey) are required inputs. 4. Combining the Nonce and Ciphertext: The result of ChaCha20-Poly1305 encryption is the combination of the ciphertext and the authentication tag. To enable decryption, the nonce used must be stored or transmitted along with the ciphertext. The code concatenates the nonce and ciphertext and stores them in the result slice. 5. Base64 Encoding: The concatenated bytes (nonce + ciphertext) often contain non-ASCII characters, making direct storage or transmission unsuitable. Base64 URL-safe encoding (base64.URLEncoding) is used to convert these bytes into a printable ASCII string. The encryptedSecretKey is the returned Base64-encoded string. 6. Cache the encrypted result (optional): The code finally uses the encrypted result (Base64 string) as the cache key and the original secretKey as the cache value in secretCache. The cache duration is 120 minutes (2 hours).This solution uses the ChaCha20-Poly1305AEAD encryption algorithm to protect the confidentiality and integrity of API keys. It generates a random nonce for each encryption operation to ensure security and Base64-encodes the nonce along with the ciphertext for storage and transmission. The decryption process first checks the cache; if a match is missed, the decryption algorithm is executed, ensuring that sensitive data remains secure even if the database is fully accessed. Because the encryption key exists only in the application server's memory, DBAs cannot obtain complete information.

[0026] S3: Extracts the target plaintext key of the API key based on the PartialKey fast matching and selective decryption mechanism, and quickly locates potential matching encrypted records through the PostgreSQL database index for the first stage of verification; S4: After the first phase of verification passes, the complete key corresponding to the target plaintext key is obtained and decrypted. The decrypted complete key is fully compared with the user-entered key for the second phase of verification. Once verification passes, it is stored in a two-level cache consisting of primary memory and secondary storage (redis). This means that once data is read from the third-tier PostgreSQL database, the system immediately writes the data to primary memory and secondary storage (redis). The first layer: local memory cache, implemented using the Go language's sync.Map and a custom cache structure, offers exceptional read performance. The second layer: Redis distributed cache, serving as the distributed cache layer, provides data sharing across clusters and high read and write performance. The third layer: PostgreSQL persistent storage, with the PostgreSQL database serving as the final persistent storage, ensuring long-term data reliability.

[0027] In the first run mode, the trigger request falls into the third-level storage PostgreSQL. Once verified, it is immediately written to the cache in the first-level memory and the second-level storage Redis. Subsequent requests are directly verified in the first-level memory. In normal operation, key verification is performed in the order of primary memory, secondary storage (Redis cache) and finally tertiary storage (PostgreSQL). This means that most requests are verified in secondary storage (Redis) and rarely reach tertiary storage (PostgreSQL). Only when a new user authenticates for the first time will a request be triggered to tertiary storage (PostgreSQL). Once verified, the key is cached in both memory and secondary storage (Redis). Subsequent requests are then passed in memory.

[0028] In a typical internet application, these three types of storage work together: PostgreSQL serves as the underlying persistent storage, storing all core business data; Redis acts as a middle-tier cache, storing frequently accessed data and alleviating database pressure; and memory, as the top layer, stores runtime data for a single application instance. The data flow pattern is as follows: reads follow a fast-to-slow path: memory → Redis → PostgreSQL; writes follow a fast-to-slow path: memory → PostgreSQL → Redis, updating to ensure consistency. This multi-tiered storage architecture balances performance, reliability, and cost, and is a common design pattern for modern internet applications.

[0029] In the system of this embodiment, Redis is actually also used as a persistent storage method. The design of Redis + PostgreSQL achieves the characteristics of both speed and data reliability. The usage scenario of this embodiment is different from other scenarios in that both Redis and PostgreSQL storage completely store all business data. In most other business usage scenarios, Redis stores frequently accessed data and PostgreSQL stores infrequently accessed data. The combination of the two is the complete data, making them indispensable. In the business scenario of this embodiment, even if PostgreSQL is shut down, it will not affect business use because Redis has complete data.

[0030] The zero-trust architecture in this embodiment: Default Distrust: In a zero-trust architecture, no user or device is trusted by default, and every access request is subject to strict verification. Principle of Least Privilege: Each user and device is granted only the minimum privileges required to complete their work, reducing the risk of unauthorized access. With the above solution, under the zero-trust architecture, each access request must undergo strict verification, even in the internal network. This method significantly reduces the risk of internal and external attacks. Through a multi-layer encryption storage mechanism, the complete key is encrypted and stored, while partial keys are stored in plain text, so that the encryption key is stored separately from the encrypted data. Even if part of the key is leaked, the attacker cannot directly obtain the complete key, which increases the security of the system. The complete key is decrypted only after the first-stage verification is passed, reducing the risk of key exposure. Based on the PartialKey fast matching mechanism, the potential matching encrypted records are quickly located through the database index, which improves the verification speed. The verified keys are stored in a two-level cache consisting of the primary memory and the secondary storage redis, which reduces the overhead of repeated verification and improves the response speed of the system. The complete ciphertext and partial plaintext keys are stored in the database, which simplifies the management and maintenance of keys. Through the automated two-stage verification mechanism, manual intervention is reduced, and the reliability and consistency of the system are improved.

[0031] In one embodiment, the step of encrypting and storing the complete key and extracting a portion of the key for plaintext storage based on a multi-layer encryption storage mechanism so that the encryption key and the encrypted data are stored separately includes: Receive user registration requests and generate a target number of bits, such as 51, for an API key to ensure randomness and complexity, making it more difficult to crack. Encrypt the complete key using ChaCha20Poly1305 to obtain the encrypted ciphertext; Extract the target number of bits of the key as the target plaintext key. For example, extract the last 20 bits of the key as partial plaintext. This portion of the key is used as an index for fast retrieval and verification. Selecting the last 20 bits ensures the randomness and uniqueness of this portion of the key, while reducing the length of plaintext storage and lowering the risk of leakage. Store the generated final key in the database; The final key record includes a complete ciphertext, such as the encrypted 51-bit key, and a target plaintext key as an index, such as the last 20 bits of the key. The complete key is encrypted and stored, and only a portion of the key is extracted for plaintext storage, thus achieving separate key storage. Even if a portion of the key is leaked, the attacker cannot directly obtain the complete key, thereby increasing the security of the system. The complete key is encrypted using the ChaCha20Poly1305 encryption algorithm, providing strong encryption protection, making the key more secure during storage and transmission. Extracting a portion of the key as a plaintext index allows for rapid retrieval and verification of the key without exposing the complete key. This design can improve the system's response speed in scenarios where frequent key access is required. Storing the complete ciphertext and partial plaintext keys in a unified database simplifies key management and maintenance. Administrators can quickly locate and operate keys through indexes without having to deal with complex key mapping relationships.

[0032] In this embodiment, the key storage process is as follows: 1. Key prefix part is encrypted and stored User API key example: sk-abcdef1234567890xyzabc; The key prefix is ​​encrypted and stored using the ChaCha20Poly1305 encryption algorithm.

[0033] The encrypted key format is: sk-abcdef12345***$#@@@*12encrypted1.

[0034] 2. The last 10 digits of the key are stored in plain text Store the last 10 digits of the key (i.e., 7890xyzabc) in plain text.

[0035] Those skilled in the art can understand that the storage process is as follows: the API key is called according to the user request, the full text of the key is encrypted and stored in the database (the DB administrator cannot obtain user information) and put into the out-queue (complete key + partial plaintext); for example, all 51 bits are encrypted and stored in one copy, and the last 20 bits of the key are stored in another copy as plaintext, that is, one key and two pieces of data are stored, and the index is broken through the second step; the partial plaintext destination index finds the ciphertext. If the partial plaintext method is not used, the user's K needs to be encrypted first, encrypted again, and then compared with the ciphertext. This process is now unnecessary.

[0036] In this embodiment, the key verification process is as follows: 1. Verify the last 10 digits of the key When a user requests a key, the system first verifies that the last 10 digits of the key (7890xyzabc) match the plaintext portion stored in the database.

[0037] 2. Decrypt the prefix and compare it completely If the last 10 digits are verified, the system decrypts the prefix portion of the key and obtains the complete key.

[0038] Finally, the decrypted complete key is compared with the key entered by the user to confirm its validity.

[0039] Those skilled in the art can understand that: 1) after the user request comes, the last 20 bits of the plaintext of the key are obtained, and the first stage of verification compares the last 20 bits of the plaintext with the last 20 bits of the plaintext in the database. After the comparison is consistent, the second stage of verification decrypts the corresponding ciphertext, and performs a complete comparison on the decrypted complete key to determine whether the complete comparison is consistent. If the 51-bit length is exactly the same and the content of each field is the same, the authentication is passed, and the key is directly stored in the memory. This process is not required for the next request, and the existence of the key is directly determined in the memory; 2) once the comparison is successful, there is a corresponding mapping relationship between the last 20 bits of plaintext + the complete key in the memory. Once the mapping relationship is found in the memory, the corresponding value after mapping is directly taken to K to determine whether the two are exactly the same. If they are exactly the same, the authentication is passed directly without the need for encryption and decryption process. 3) If there is no mapping in memory, it means the account has not been logged in for a long time. In this case, the Redis cache is first checked. If the key can be read in the cache, the data can be found in the cache and a copy is immediately written to the memory. The judgment logic is the same as step 1. If the data is not read in the cache, it means the user has not logged in for a long time or the account has expired. The database is accessed and the ciphertext in the database is decrypted and reversely compared with the plaintext. The processing logic of the cache and database is consistent, so the cache is faster.

[0040] The core concept of this embodiment is to store the prefix of the key encrypted and the last 10 digits in plain text, thereby ensuring security while also facilitating rapid verification of the key's validity. In this way, the system can effectively prevent key leakage and quickly perform identity verification when needed.

[0041] In one embodiment, in cold start mode, an API request is initiated to call an API key; Extracting the target number of bits of plaintext key requires two-stage verification. The decrypted complete key is fully compared with the user-entered key, and verification is passed if the comparison is consistent. For example, a user initiates an API request with a complete API key. The system extracts the last 20 digits of the key. The first stage of verification: the system searches the database for the existence of this partial plaintext. The second stage of verification: the system obtains the corresponding complete ciphertext, decrypts it, and fully compares it with the key provided by the user. The system stores the verification results in a two-level cache consisting of primary memory and secondary storage Redis: memory cache: valid for 1 day, Redis cache: valid for 1 year, and database: persistent storage.

[0042] Those skilled in the art will appreciate that the cold start mode uses a partial key (e.g., the last 20 digits) for a first-stage rapid screening, followed by a second-stage precise verification using a decrypted comparison of the full key. This dual verification mechanism significantly reduces the risk of false positives or counterfeit keys passing verification, ensuring the security of initial access. Even for the first request, multi-layer encryption and separate storage prevent direct exposure of the full key, upholding the core principle of "never trust, always verify" within the Zero Trust architecture. After successful verification, the verification result (or key information) is stored in a two-level cache (memory, Redis, and database) consisting of primary memory and secondary Redis storage. Subsequent requests from the same user, if the cache is valid, can directly retrieve the verification result from memory or Redis, eliminating the need to repeat the time-consuming database query, key decryption, and comparison process. This significantly improves API call response speed and system throughput. The memory cache (one day) provides the highest speed and is suitable for high-frequency access; the Redis cache (one year) provides persistent and fast access and is suitable for medium-frequency authentication or cross-service sharing. The database (persistent) serves as the final storage to ensure data is not lost. This layered strategy balances speed, cost, and reliability. For frequent API calls, caching effectively reduces the number of direct database accesses, reduces the database load, helps extend the database life, and may reduce related costs. Only in the event of a cache miss is a full key decryption and comparison operation required, reducing the consumption of computing resources. The status of the verification results (success / failure) is centrally managed and stored to facilitate subsequent auditing, monitoring, or decision-making. In summary, this solution, while ensuring secure verification of the first request, provides significant performance improvements for subsequent requests by introducing a multi-level caching mechanism, achieving a balance between security and efficiency, and meeting the requirements of distributed systems and zero-trust architectures.

[0043] In one embodiment, in cache hit mode, i.e., a second request within a short period of time, a second API request is made to invoke the API key; the target number of digits of the plaintext key is extracted; a check is made in the memory cache to determine whether a mapping relationship exists between the target plaintext key and the complete key; and verification is directly passed if a corresponding mapping relationship is found in the memory. For example, if a user makes another API request, the system extracts the last 20 digits of the key, checks the memory cache, finds the corresponding mapping relationship, and directly passes verification without the need for decryption. Because the mapping between the target plaintext key and the full key is already stored in the memory cache, time-consuming decryption operations are unnecessary. This significantly reduces the computational burden and improves the processing speed of API requests. The memory cache provides extremely fast access, making the verification process almost instantaneous, greatly improving the user experience and system throughput. It avoids unnecessary encryption / decryption operations, reducing CPU load and memory resources. Since verification results are read directly from memory, access to external storage (such as Redis or databases) is reduced, reducing I / O overhead. By rapidly processing verification requests through the memory cache, the system can better support high-concurrency scenarios and improve overall scalability. It avoids database or Redis access bottlenecks caused by a large number of requests in a short period of time, ensuring that the system maintains good performance under high load. In cache hit mode, the verification process becomes very simple, requiring only a check of the memory cache, simplifying system design and implementation. In summary, the cache hit mode solution, by utilizing the memory cache to store the mapping between the target plaintext key and the full key, achieves fast verification, significantly improving system response speed and performance, reducing resource consumption, improving system scalability, and simplifying system design. This design is particularly suitable for scenarios that require frequent verification and high performance, such as highly concurrent API calls.

[0044] In one embodiment, in the memory cache expiration mode, that is, the memory cache has expired, a third API request is initiated to call the API key; the memory cache is checked to see whether there is a mapping relationship between the target plaintext key and the complete key; when the corresponding mapping relationship is not found in the memory cache, the Redis cache is checked to find the mapping relationship between the target plaintext key and the complete key; and when the verification is passed, the mapping relationship is rewritten into the memory cache.

[0045] In one embodiment, in the Redis cache expiration mode, the fourth API request is initiated to call the API key; the memory cache and the Redis cache are checked to see whether there is a mapping relationship between the target plaintext key and the complete key; when no corresponding mapping relationship is found in either the memory cache or the Redis cache, the database is accessed to search for the corresponding ciphertext data using the target plaintext key; the decrypted ciphertext data is fully compared with the key input by the user; and after verification, the verification result is rewritten into the memory cache and the Redis cache. Although the in-memory cache expires, the system doesn't jump directly to the slowest full decryption verification path. Instead, it utilizes the lower-level Redis cache, which is typically much faster than direct database access. Compared to the extremely fast in-memory cache hit, a Redis cache hit provides suboptimal but still relatively fast verification speed, avoiding time-consuming decryption operations for every expired request and ensuring a better user experience. Using Redis as a secondary cache: The presence of the Redis cache (valid for one year) means that verification information remains available during brief in-memory cache expiration periods, significantly increasing the likelihood of a cache hit and reducing the need for direct database access. The in-memory cache is fast but volatile, the Redis cache is fast and relatively durable, and the database is the slowest but most durable. This three-tiered architecture effectively balances speed, cost, and durability. Even if the in-memory cache expires or becomes invalid for other reasons, the system can still quickly complete verification by accessing the Redis cache, ensuring service continuity and availability, and preventing service interruptions or significant performance degradation due to cache issues. After a Redis cache hit and verification, the mapping is rewritten to the in-memory cache. This process is called cache backfilling or prewarming. It ensures that the next (fourth) request using the same key can use the high-speed memory cache again, effectively "repairing" the expired memory cache state and maintaining efficient processing of subsequent requests. By giving priority to the use of Redis cache, the frequency of direct access to the database for decryption and verification is significantly reduced, the load on the database is reduced, and it contributes to the stable operation and cost control of the database. In summary, by introducing Redis as a backup layer for the memory cache, this solution provides a performance-optimized degradation path when the memory cache expires. It ensures that even if the memory cache is temporarily unavailable, the system can still respond quickly to user requests, and quickly restore the effectiveness of the memory cache through an automatic backfill mechanism, further enhancing the efficiency, reliability and overall performance of the entire key verification process, while optimizing resource usage.

[0046] The traditional API key verification system has a significant performance bottleneck: each request requires the user-provided API key to be fully encrypted and then compared with the ciphertext stored in the database. This method has a huge computational overhead in high-frequency call scenarios.

[0047] The embodiment of the present invention proposes an innovative PartialKey fast matching and selective decryption mechanism, which works as follows: Extract the partial key PartialKey from the input key provided by the user. It can be a prefix or fingerprint for fast lookup. For example, extract the first 16 bits of the key as PartialKey; Use PartialKey to quickly locate candidate records in the database and return only matching encryption keys. This is achieved through database indexing to improve search speed. If no matching records are found, an error is quickly returned, indicating that the provided API key is invalid. The cache is checked first to avoid repeated decryption. If a matching record exists in the cache, the user information in the cache is directly returned. If the input key already exists in the cache, directly return the cached user information to avoid repeated calculations; Only the encrypted records matching the PartialKey are fully decrypted and compared with the input key. If they match, the verification is successful. If the decrypted key matches the input key, the user information is returned and the cache is updated; otherwise, the next candidate record is verified. This solution significantly improves database query efficiency, reduces computing overhead, improves cache utilization, enhances security, and improves system scalability through the PartialKey fast matching and selective decryption mechanism. These improvements enable the system to process API key verification requests more efficiently and securely, especially in scenarios with high concurrency and large-scale key management. The core advantages of this embodiment are as follows: 1. Two-stage verification: First, a low-cost PartialKey match is performed, and computationally intensive full decryption is performed only when there is a potential match; 2. Index optimization: PartialKey is stored as an index field, which greatly improves database search efficiency; 3. Cache acceleration: Combined with a multi-level cache strategy, repeated decryption operations are reduced; 4. Computing resource optimization: significantly reduces the frequency of CPU-intensive encryption and decryption operations; 5. Scalability: supports efficient management and verification of millions of API keys.

[0048] The embodiments of the present invention adopting the above scheme have the following technical advantages: extremely high data security: even if the database is fully accessed, the API key remains safe and the DBA cannot obtain the key required for decryption; zero trust architecture: the system does not trust any component or participant, and all access requires a complete verification process; fine-grained access control: a multi-dimensional access control matrix ensures precise permission management and resource isolation; high performance: an innovative caching mechanism significantly reduces encryption and decryption overhead and improves system response speed; self-adaptation: the system can automatically adjust resource allocation and access policies according to real-time conditions.

[0049] Based on the same inventive concept, the present invention also provides a distributed API key management and access control system based on a zero-trust architecture, including: Request module, used to call API keys based on user requests; A storage module is used to encrypt and store the complete key based on a multi-layer encryption storage mechanism and extract part of the key for plain text storage, so that the encryption key and the encrypted data are stored separately; The first-stage verification module is used to extract the target plaintext key of the API key based on the PartialKey fast matching and selective decryption mechanism, and quickly locate potential matching encrypted records through the postgreSQL database index for the first-stage verification; The second-stage verification module is used to obtain the complete key corresponding to the target plaintext key and decrypt it after the first-stage verification is passed. The decrypted complete key is fully compared with the user-entered key for the second-stage verification until the verification is passed and stored in the two-level cache consisting of the primary memory and the secondary storage redis; In the first run mode, the trigger request falls into the third-level storage PostgreSQL. Once verified, it is immediately written to the cache in the first-level memory and the second-level storage Redis. Subsequent requests are directly verified in the first-level memory. In normal operation mode, key verification is performed in the order of primary memory, secondary storage redis cache, and finally tertiary storage postgreSQL. The implementation principle of the above modules can be referred to the distributed API key management and access control method based on zero trust architecture described in the embodiment, and will not be repeated here.

[0050] In some embodiments of the present application, an electronic device is provided. This electronic device includes a memory and a processor, wherein the memory is used to store a processing program; when the processor executes the processing program, the distributed API key management and access control method based on a zero-trust architecture as described in the embodiments of the present invention is implemented. When the processor executes the processing program, the distributed API key management and access control method based on a zero-trust architecture as described in the aforementioned embodiments is implemented.

[0051] The present invention provides a computer-readable storage medium having a processing program stored thereon. When executed by a processor, the processing program implements the distributed API key management and access control method based on a zero-trust architecture as described in an embodiment of the present invention. A computer-readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanical encoding device, such as a punch card or a raised structure within a recess on which instructions are stored, and any suitable combination thereof. Computer-readable storage media as used herein is not to be construed as transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0052] While various embodiments of the present disclosure have been described above, the foregoing description is intended to be illustrative, non-exhaustive, and not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, their practical applications, or technological improvements in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A distributed API key management and access control method based on zero trust architecture, characterized in that: include: Call the API key based on user request; Based on a multi-layer encryption storage mechanism, the complete key is encrypted and stored, and part of the key is extracted and stored in plain text, so that the encryption key and the encrypted data are stored separately; Extract the target plaintext key of the API key based on the PartialKey fast matching and selective decryption mechanism, and quickly locate potential matching encrypted records through the PostgreSQL database index for the first stage of verification; After the first stage of verification is passed, the complete key corresponding to the target plaintext key is obtained and decrypted. The decrypted complete key is fully compared with the user-entered key for the second stage of verification until the verification is passed and stored in a two-level cache consisting of the primary memory and the secondary storage redis; In the first run mode, the trigger request falls into the third-level storage PostgreSQL. Once verified, it is immediately written to the cache in the first-level memory and the second-level storage Redis. Subsequent requests are directly verified in the first-level memory. In normal operation mode, key verification is performed in the order of primary memory, secondary storage redis cache, and finally tertiary storage postgreSQL.

2. The distributed API key management and access control method based on zero trust architecture according to claim 1, characterized in that: The method of encrypting and storing the complete key and extracting a portion of the key for plaintext storage based on a multi-layer encryption storage mechanism so that the encryption key and the encrypted data are stored separately includes: Receive user registration request and generate API key with target digits; Encrypt the complete key using ChaCha20Poly1305 to obtain the encrypted ciphertext; Extract the target number of bits of the key as the target plaintext key; Store the generated final key in the database; The final key record includes the complete ciphertext and the target plaintext key as an index.

3. The distributed API key management and access control method based on zero trust architecture according to claim 1, characterized in that: Also includes: In cold start mode, initiate an API request to call the API key; The plaintext key of the target number of bits is extracted through a two-stage verification. The decrypted complete key is fully compared with the user-entered key, and the verification is passed after the comparison is consistent.

4. The distributed API key management and access control method based on zero trust architecture according to claim 1, characterized in that: Also includes: In cache hit mode, Extract the target number of plaintext keys; Check whether there is a mapping relationship between the target plaintext key and the complete key in the memory cache; If the corresponding mapping relationship is found in the memory, the verification is passed directly.

5. The distributed API key management and access control method based on zero trust architecture according to claim 1, characterized in that: Also includes: In memory cache expiration mode, Check whether there is a mapping relationship between the target plaintext key and the complete key in the memory cache; If no corresponding mapping is found in the memory cache, the Redis cache is checked to find the mapping between the target plaintext key and the complete key. When verification is successful, the mapping relationship is rewritten into the memory cache.

6. The distributed API key management and access control method based on zero trust architecture according to claim 1, characterized in that: Also includes: In Redis cache expiration mode, Check whether there is a mapping relationship between the target plaintext key and the complete key in the memory cache and Redis cache; If no corresponding mapping relationship is found in the memory cache or Redis cache, the database is accessed to search for the corresponding ciphertext data using the target plaintext key; Completely compare the decrypted ciphertext data with the user-entered key; After verification is passed, the verification results are rewritten into the memory cache and Redis cache.

7. The distributed API key management and access control method based on zero trust architecture according to claim 1, characterized in that: The method of extracting the target plaintext key of the API key based on the PartialKey fast matching and selective decryption mechanism further includes: Extract the partial key PartialKey from the input key provided by the user; Use PartialKey to quickly locate candidate records in the database and return only matching encryption keys; If the input key already exists in the cache, directly return the cached user information to avoid repeated calculations; Only the encrypted records matching the PartialKey are fully decrypted and compared with the input key; If the decrypted key matches the input key, the user information is returned and the cache is updated; otherwise, the next candidate record is checked.

8. A distributed API key management and access control system based on zero trust architecture, characterized in that: Implementing the distributed API key management and access control method based on zero-trust architecture as described in any one of claims 1 to 7, comprising: Request module, used to call API keys based on user requests; A storage module is used to encrypt and store the complete key based on a multi-layer encryption storage mechanism and extract part of the key for plain text storage, so that the encryption key and the encrypted data are stored separately; The first-stage verification module is used to extract the target plaintext key of the API key based on the PartialKey fast matching and selective decryption mechanism, and quickly locate potential matching encrypted records through the postgreSQL database index for the first-stage verification; The second-stage verification module is used to obtain the complete key corresponding to the target plaintext key and decrypt it after the first-stage verification is passed. The decrypted complete key is fully compared with the user-entered key for the second-stage verification until the verification is passed and stored in the two-level cache consisting of the primary memory and the secondary storage redis; In the first run mode, the trigger request falls into the third-level storage PostgreSQL. Once verified, it is immediately written to the cache in the first-level memory and the second-level storage Redis. Subsequent requests are directly verified in the first-level memory. In normal operation mode, key verification is performed in the order of primary memory, secondary storage redis cache, and finally tertiary storage postgreSQL.

9. An electronic device, characterized in that: include: a memory for storing a processing program; A processor, wherein when executing the processing program, the processor implements the distributed API key management and access control method based on the zero trust architecture as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that: The readable storage medium stores a processing program, which, when executed by the processor, implements the distributed API key management and access control method based on the zero-trust architecture as described in any one of claims 1 to 7.

Images