Distributed API key management and access control method and system based on zero trust architecture

Abstract

The application discloses a kind of distributed API key management and access control method and system based on zero trust architecture, it is related to computer network security technical field, method includes: according to user request call API key;Based on multi-layer encryption storage mechanism, complete key is encrypted and stored and partial key is extracted and stored in plaintext;Based on PartialKey fast matching and selective decryption mechanism, the target plaintext key of API key is extracted, and the encrypted record of potential matching is quickly located by database index to carry out first stage verification;After first stage verification passes, the complete key corresponding to target plaintext key is obtained and decrypted, and the decrypted complete key is compared with user input key to carry out second stage verification until verification passes and is stored in two-level cache.Even in the case that DBA can access the database completely, API key and sensitive data security target can be guaranteed, high-frequency access key verification is ensured to be completed quickly, and resource optimization is realized.

Description

TECHNICAL FIELD

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

[0002] In the prior art, the key fields of a user are encrypted in a database under the requirements of compliance and the like, so that the user's plaintext needs to be encrypted each time and then compared with the ciphertext each time to respond to the user's request, which is time-consuming and low in efficiency. In the current cloud computing and AI service environment, API key management faces the following challenges: 1. The traditional system usually stores API keys in plaintext or in a simple hash in the database, 2. The database administrator (DBA) can directly view and modify sensitive information, 3. There is a lack of fine-grained access control and resource isolation mechanism, which cannot cope with internal threats, especially the problem of abuse of privileged accounts.

[0003] In summary, the limitation of the prior art is that once the database is broken or an internal personnel (such as a DBA) obtains access rights, all API keys and sensitive information are exposed immediately, and no real data security guarantee can be provided. SUMMARY

[0004] The application provides a distributed API key management and access control method and system based on a zero-trust architecture, which guarantees the security of API keys and sensitive data even in the case that a DBA can completely access the database through the design of zero trust and layered defense, combined with the two-stage mechanism of “coarse-grained preliminary screening + fine-grained verification”.

[0005] The application provides a distributed API key management and access control method based on a zero-trust architecture, which comprises the following steps:

[0006] Calling an API key according to a user request;

[0007] Based on a multi-layer encryption storage mechanism, the complete key is encrypted and stored, and part of the key is stored in plaintext, so that the encrypted key and the encrypted data are stored separately;

[0008] Based on a PartialKey fast matching and selective decryption mechanism, the target plaintext key of the API key is extracted, and the potential matching encrypted record is quickly located by a postgreSQL database index to perform first-stage verification;

[0009] After the first-stage verification is passed, the complete key corresponding to the target plaintext key is obtained and decrypted, and the decrypted complete key is compared with the user input key for complete comparison to perform second-stage verification until the verification is passed and the two-level cache composed of a primary memory and a secondary storage redis is stored.

[0010] In the initial run mode, the triggered request falls into the third-level storage PostgreSQL. Once the verification is successful, it is immediately written to the cache in the first-level memory and the second-level storage Redis. Subsequent requests will directly pass the verification through the first-level memory.

[0011] In normal operating mode, key verification is performed in the following order: first-level memory - second-level storage Redis cache - and finally third-level storage PostgreSQL.

[0012] Preferably, the method of encrypting and storing the complete key and extracting a portion of the key for plaintext storage based on a multi-layered encryption storage mechanism, thereby separating the encryption key from the encrypted data, includes:

[0013] Receive user registration requests and generate API keys of the target length;

[0014] The complete key is encrypted using ChaCha20Poly1305 to obtain the encrypted ciphertext.

[0015] Extract the target number of bits from the key as the target plaintext key;

[0016] The generated final key is stored in the database;

[0017] The final key record includes the complete ciphertext and the target plaintext key as an index.

[0018] As a preferred option, it also includes:

[0019] In cold start mode, initiate an API request to invoke the API key;

[0020] The plaintext key of the target number of bits is extracted through a two-stage verification process. The decrypted complete key is compared with the key entered by the user, and the verification is successful once the comparison is consistent.

[0021] As a preferred option, it also includes:

[0022] In cache hit mode,

[0023] Extract the plaintext key of the target length;

[0024] Check if a mapping relationship exists between the target plaintext key and the complete key in the memory cache;

[0025] If the corresponding mapping is found in memory, the verification is successful.

[0026] As a preferred option, it also includes:

[0027] In memory cache expiration mode,

[0028] Check whether the memory cache has a mapping relationship corresponding to the target plaintext key and the complete key;

[0029] When the corresponding mapping relationship is not found in the memory cache, the Redis cache is checked to find the mapping relationship corresponding to the target plaintext key and the complete key;

[0030] The verification is passed, and the mapping relationship is re-written into the memory cache.

[0031] As preferred, it further comprises:

[0032] In the Redis cache expiration mode,

[0033] Check whether the memory cache and the Redis cache have a mapping relationship corresponding to the target plaintext key and the complete key;

[0034] When the corresponding mapping relationship is not found in the memory cache and the Redis cache, the database is accessed to find the corresponding ciphertext data through the target plaintext key;

[0035] The decrypted ciphertext data is compared with the user input key in its entirety;

[0036] After the verification is passed, the verification result is re-written into the memory cache and the Redis cache.

[0037] As preferred, the target plaintext key of the API key extracted based on the PartialKey fast matching and selective decryption mechanism further comprises:

[0038] Extract a PartialKey from the input key provided by the user;

[0039] Use the PartialKey to quickly locate the candidate record in the database, and only return the encrypted key that can be matched;

[0040] If the input key already exists in the cache, directly return the user information in the cache to avoid repeated calculation;

[0041] Only the encrypted record matched by the PartialKey is decrypted in its entirety and compared with the input key;

[0042] If the decrypted key matches the input key, the user information is returned and the cache is updated; otherwise, the next candidate record is continuously verified.

[0043] The application also provides a distributed API key management and access control system based on a zero-trust architecture, comprising:

[0044] A request module is configured to call an API key according to a user request;

[0045] A storage module is configured to store a complete key in an encrypted manner based on a multi-layer encryption storage mechanism and store a partial key in a plaintext manner, so that the encrypted key and the encrypted data are stored separately.

[0046] A one-stage verification module is configured to extract a target plaintext key of an API key based on a PartialKey fast matching and selective decryption mechanism, quickly locate a potential matching encrypted record in a postgreSQL database index for first-stage verification.

[0047] A two-stage verification module is configured to, after the first-stage verification is passed, obtain a complete key corresponding to the target plaintext key and decrypt the complete key, and perform a complete comparison between the decrypted complete key and a user input key for second-stage verification until the verification is passed and the complete key is stored in a two-level cache composed of a first-level memory and a second-level storage redis.

[0048] A first running mode is configured to trigger a request to fall into a third-level storage postgreSQL, and once the verification is passed, the request is cached in a first-level memory and a second-level storage redis, and a second request is directly verified by the first-level memory.

[0049] A normal running mode is configured to perform key verification in the order of the first-level memory, the second-level storage redis cache and the final third-level storage postgreSQL.

[0050] The application further provides an electronic device, comprising:

[0051] A memory is configured to store a processing program.

[0052] A processor is configured to implement the distributed API key management and access control method based on the zero trust architecture when the processing program is executed.

[0053] The application further provides a readable storage medium having a processing program stored thereon, and the processing program is configured to implement the distributed API key management and access control method based on the zero trust architecture when the processing program is executed by a processor.

[0054] Compared with the prior art, the application has at least one of the following beneficial effects:

[0055] (1) The application stores a complete key after encryption by ChaCha20Poly1305, and only retains a partial plaintext (PartialKey) as an index, so as to realize "separation of encrypted key and data", even if the plaintext is leaked, an attacker cannot directly obtain the complete key, and needs to break through the encryption algorithm, so that the complete key and the plaintext are stored separately, and the risk of single-point leakage is reduced.

[0056] (2) The application adopts a first stage (PartialKey matching): candidate records are quickly screened through lightweight string comparison to reduce subsequent decryption overhead; a second stage (complete comparison) is adopted: only candidate records are decrypted and compared with the user input key to ensure the strictness of the final verification.

[0057] (3) The application uses PartialKey as an index field to quickly locate candidate records through database indexing, avoiding full table scanning, and only decrypting records matching PartialKey, significantly reducing the frequency of CPU-intensive decryption operations, and reducing CPU consumption through PartialKey preliminary screening and caching mechanisms.

[0058] (4) The application adopts a multi-level caching mechanism: memory caching: accelerates high-frequency requests, directly returns mapping relationships, and avoids repeated calculations; Redis caching: cross-node shared caching, supports distributed deployment, and reduces database pressure; database: as the final bottom storage, decryption and comparison are triggered only when the cache is not hit.

[0059] (5) The application requires complete two-stage verification for the first request to ensure security, and subsequent requests prefer to obtain results from memory or Redis cache to reduce latency, support efficient management of massive API keys, and expand horizontally through database indexing and caching.

[0060] (5) The application is based on a distributed API key management and access control method based on a zero-trust architecture, and a multi-layer encryption storage mechanism, achieving efficient verification: most cases are completed in memory without decryption; secure storage: only ciphertext and partial plaintext are stored in the database; layered caching: ensures that high-frequency access key verification is completed quickly; resource optimization: reduces the frequency of CPU-intensive encryption and decryption operations. Even in the case where the DBA can access the database completely, the API key and sensitive data security goal can be guaranteed. The system is suitable for cloud service API management, AI service access control, multi-tenant SaaS systems and other high-security demand scenarios, and has significant technical innovation and practical value. BRIEF DESCRIPTION OF DRAWINGS

[0061] Figure 1 The steps of the application are based on a distributed API key management and access control method based on a zero-trust architecture. DETAILED DESCRIPTION

[0062] In order to make the purposes, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0063] Those skilled in the art can understand that the singular forms "a", "an" and "the" used in this application can also include the plural forms unless specifically stated otherwise. It should be further understood that the use of the phrase "comprising" in the specification of the present application means that the features, integers, steps, operations, elements and / or components described exist, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.

[0064] The conventional plaintext storage without part, the existing scheme such as compliance needs the user's key field in the database to be encrypted, which causes a problem that each time the user's plaintext is requested, the plaintext is encrypted, and then compared with the ciphertext, which is time-consuming and low in efficiency; Assuming that the request is 1000 times, the decryption is repeated 1000 times, and now if the scheme is not used, the decryption is performed once each time the call is made, and the decryption is performed once each time the call is made, and the decryption process is time-consuming because it involves algorithm length. The present application proposes a distributed API key management and access control method based on zero trust architecture, which only needs to be decrypted once, and the remaining all are directly matched in the memory, and the process is completed, and the process is not needed after walking.

[0065] As shown in Figure 1 The embodiments of the present application provide a distributed API key management and access control method based on zero trust architecture, which comprises:

[0066] S1: calling an API key according to a user request;

[0067] S2: Based on the multi-layer encryption storage mechanism, the complete key is encrypted and stored, and part of the key is extracted and stored in plaintext, so that the encryption key and the encrypted data are stored separately; The API key encryption mechanism used in this scheme specifically includes: 1, Initialize encrypter (aead): use a fixed encryptionKey (this key should be pre-configured and needs to be stored securely) to create an AEAD (Authenticated Encryption with Associated Data) mode encrypter instance. Here, chacha20poly1305.NewX is used, which usually refers to the ChaCha20-Poly1305 algorithm, and X may indicate a variant of the extended nonce size (NonceSizeX). If the key length does not meet the requirements, NewX will return an error. 2, Generate random nonce: generate a unique random value called nonce (one-time counter) for each encryption operation. The size of the nonce is specified by chacha20poly1305.NonceSizeX. Read bytes from the cryptographically secure random source rand.Reader to fill the nonce. The nonce is crucial for AEAD encryption, and reusing the same nonce and key combination can cause serious security problems. 3, Perform encryption (Seal): use the aead.Seal method to encrypt the actual secretKey (API key to be encrypted). The Seal method not only encrypts the data, but also generates an authentication tag (tag) at the same time, which is used for subsequent verification. The first parameter nil indicates that no additional associated data is attached. The nonce and []byte(secretKey) are required inputs. 4, Combine nonce and ciphertext: the result of ChaCha20-Poly1305 encryption is the combination of ciphertext and authentication tag. In order to be able to decrypt, the nonce used must be stored or transmitted together with the ciphertext. The code concatenates the nonce and the ciphertext in the result slice. 5, Base64 encoding: the concatenated bytes (nonce+ciphertext) usually contain non-ASCII characters, which may not be convenient to store or transmit directly. Use Base64URL safe encoding (base64.URLEncoding) to convert these bytes to printable ASCII strings. The final returned encryptedSecretKey is this Base64 encoded string. 6, Cache encryption results (optional): finally, the code stores the encryption result (Base64 string) as the cache key and the original secretKey as the cache value in secretCache. The cache time is 120 minutes (2 hours).The scheme of using ChaCha20-Poly1305 AEAD encryption algorithm to protect the API key for confidentiality and integrity. It generates a random nonce for each encryption operation to ensure security, and Base64 encodes the nonce together with the ciphertext for storage and transmission. The decryption process correspondingly checks the cache first, and if it does not hit, it executes the decryption algorithm to ensure that even if the database is fully accessed, sensitive data is still safe. Since the encryption key only exists in the application server memory, the DBA cannot obtain the complete information.

[0068] S3: Based on the PartialKey fast matching and selective decryption mechanism, the target plaintext key of the API key is extracted, and the potential matching encrypted records are quickly located through the PostgreSQL database index to perform the first-stage verification.

[0069] S4: After the first-stage verification passes, the complete key corresponding to the target plaintext key is obtained and decrypted, and the decrypted complete key is compared with the user input key for the second-stage verification until the verification passes and is stored in the two-level cache composed of the first-level memory and the second-level storage Redis, that is, if the data is read from the third-level PostgreSQL database, the system immediately writes the data to the first-level memory and the second-level storage Redis. The first layer: local memory cache, which is implemented using Go language's sync.Map and custom cache structure, has ultra-high read performance; the second layer: Redis distributed cache, which provides data sharing and high read-write performance between clusters; the third layer: PostgreSQL persistent storage, which is the final persistent storage to ensure long-term reliability of data.

[0070] First run mode, trigger request to fall into three-level storage PostgreSQL, and once the verification passes, cache in the first-level memory and the second-level storage Redis, and the second request is directly verified by the first-level memory;

[0071] Normal operation mode, key verification in the order of first-level memory-second-level storage Redis cache (persistent storage)-third-level storage PostgreSQL (persistent storage). That is, in the actual process, most requests are verified by the second-level storage Redis, and it is difficult to trigger the third-level storage PostgreSQL. When a new user verifies for the first time, the request falls into the third-level storage PostgreSQL, and once the verification is passed, the cache is written in the memory and the second-level storage Redis, and the second request is passed in the memory layer.

[0072] In a typical Internet application, these three types of storage work together: PostgreSQL as the underlying persistent storage, holding all core business data; Redis as the intermediate layer cache, storing frequently accessed data to reduce database pressure; and memory as the uppermost layer, storing the runtime data of individual application instances. The data flow pattern is: read path: memory Redis PostgreSQL, from fast to slow, write path: memory PostgreSQL Redis update, to ensure consistency. This multi-layer storage architecture can balance performance, reliability, and cost, and is a common design pattern for modern Internet applications.

[0073] In the system of the present embodiment, redis is actually also used as persistent storage. The design of redis + PostgreSQL two storages realizes the characteristics of both speed and data reliability. The difference between the use of the present embodiment and other scenarios is that both redis and PostgreSQL store all business data, while in most other business scenarios, redis stores frequently accessed data, and postgres stores infrequently accessed data. The combination of the two is complete data, making them indispensable. However, in the business scenario of the present embodiment, even if postgres is turned off, it does not affect business use, because redis has complete data.

[0074] In the zero-trust architecture of the present embodiment: default distrust: in the zero-trust architecture, any user and device is not trusted by default, and each access request needs to be strictly verified. Principle of least privilege: each user and device is only granted the minimum privilege required to complete the work, reducing the risk of privilege escalation. With the above scheme, in the zero-trust architecture, each access request needs to be strictly verified, even in the internal network. This method significantly reduces the risk of internal and external attacks; through the multi-layer encryption storage mechanism, the complete key is stored in encrypted form, while the partial key is stored in plaintext, so that the encryption key and the encrypted data are stored separately. Even if part of the key is leaked, the attacker cannot directly obtain the complete key, increasing the security of the system; after the first stage of verification, the complete key is decrypted, reducing the risk of key exposure; based on the PartialKey fast matching mechanism, the database index is used to quickly locate the potential matching encrypted records, improving the verification speed; the verified key is stored in the two-level cache consisting of level one memory and secondary storage redis, reducing the overhead of repeated verification and improving the response speed of the system; the complete ciphertext and partial plaintext key are stored in the database, simplifying the management and maintenance of the key, and through the automated two-stage verification mechanism, reducing human intervention and improving the reliability and consistency of the system.

[0075] In one embodiment, the multi-layer encryption storage mechanism encrypts the complete key and stores part of the key in plaintext, so that the encryption key and the encrypted data are stored separately, including:

[0076] Receiving a user registration request, generating an API key with a target bit number such as 51 bits, ensuring the randomness and complexity of the key, and increasing the cracking difficulty;

[0077] Encrypt the complete key using ChaCha20Poly1305 to obtain the encrypted ciphertext;

[0078] Extract the target bit number of the key as the target plaintext key, such as the last 20 bits of the key as part of the plaintext, which is used as an index for quick retrieval and verification. Selecting the last 20 bits can ensure the randomness and uniqueness of this part of the key, while reducing the length of the plaintext storage and reducing the risk of leakage;

[0079] Store the generated final key in the database;

[0080] The final key record includes the complete ciphertext such as the encrypted 51-bit key and the target plaintext key such as the last 20 bits of the key as an index. The complete key is encrypted and stored, and only part of the key is stored in plaintext, achieving separate storage of the key. Even if part of the key is leaked, attackers cannot directly obtain the complete key, increasing the security of the system. Using the ChaCha20Poly1305 encryption algorithm to encrypt the complete key provides strong encryption protection, making the key more secure during storage and transmission. Extracting part of the key as a plaintext index allows quick retrieval and verification of the key without exposing the complete key. This design can improve the response speed of the system in scenarios that require frequent access to the key. Storing the complete ciphertext and part of the plaintext key in the database simplifies key management and maintenance, allowing administrators to quickly locate and operate the key through the index without dealing with complex key mapping relationships.

[0081] In this embodiment, the key storage process is as follows:

[0082] 1. Encrypt the key prefix part

[0083] User API key example: sk-abcdef1234567890xyzabc;

[0084] Use the ChaCha20Poly1305 encryption algorithm to encrypt the key prefix part.

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

[0086] 2. The last 10 bits of the key are stored in plaintext

[0087] The last 10 bits of the key (i.e. 7890xyzabc) are stored in plaintext.

[0088] As can be understood by those skilled in the art, the storage process is as follows: upon user request, the API key is called, the full text of the key is stored in the database (DB, the database administrator also cannot obtain user information) and put into the queue (complete key + partial plaintext); if 51 bits are all stored in encrypted form, the last 20 bits of the key are stored in plaintext, i.e. one key is stored in two pieces of data, and the second step is to break the index; the partial plaintext purpose index finds the ciphertext, and the partial plaintext method is needed to encrypt the user's K first, then encrypt again, and then compare the ciphertext, and the present process is not needed.

[0089] In this embodiment, the key verification process is as follows:

[0090] 1. Verify the last 10 bits of the key

[0091] When the user requests the key, the system first verifies whether the last 10 bits (7890xyzabc) of the key match the plaintext part stored in the database.

[0092] 2. Decrypt the prefix and complete comparison

[0093] If the last 10 bits are verified, the system will decrypt the prefix part of the key and obtain the complete key.

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

[0095] The skilled person in the art can understand that 1) after the user requests, the last 20 bits of the plaintext key are obtained, the first stage verification compares the last 20 bits of the plaintext with the last 20 bits of the plaintext in the database, and after the comparison is consistent, the second stage verification decrypts the corresponding ciphertext, compares the decrypted complete key, and judges whether the complete comparison is consistent. The length of 51 bits is completely the same, and the content is that each field is the same, then the authentication is passed, the key is directly stored in the memory, and the next request does not need this process, and the key is directly judged in the memory; 2) once the comparison is successful, the last 20 bits of the plaintext in the memory + the complete key have a corresponding mapping relationship, once the mapping relationship is found in the memory, the corresponding value of the mapping is directly taken to judge whether they are completely the same, and the authentication is passed directly without the encryption and decryption process. 3) If there is no mapping relationship in the memory, it means that the account has not been logged in for a long time, at this time, the redis cache is first gone, if the key can be read in the cache, the data in the cache can be found immediately. Write a copy in the memory, the judgment logic is step 1); if the cache is not read, that is, the user has not logged in for a long time or the account has expired, the database is entered, the ciphertext in the database is decrypted and compared with the plaintext, and the processing logic of the cache and the database is consistent. The cache is faster.

[0096] The core idea of the embodiment is to store the prefix part of the key in an encrypted form and store the last 10 bits in plaintext, so as to ensure security while facilitating fast verification of the validity of the key. In this way, the system can effectively prevent key leakage and quickly perform identity verification when needed.

[0097] In one embodiment, in the cold start mode, the API request is initiated to call the API key.

[0098] The plaintext key of the target bit number is extracted and verified by two stages, and the decrypted complete key is compared with the user input key. For example, the user initiates an API request, and the complete API key is attached. The system extracts the last 20 bits of the key, the first stage verification: the system searches the database to see if the part of the plaintext exists, the second stage verification: the system obtains the corresponding complete ciphertext, decrypts it, and compares it with the key provided by the user. The system stores the verification result in a two-level cache composed of a primary memory and a secondary storage redis: the memory cache: valid for 1 day, the Redis cache: valid for 1 year, and the database: persistent storage.

[0099] As can be understood by those skilled in the art, the cold start mode performs a first-stage rapid screening through part of the key (such as the last 20 bits), and a second-stage accurate verification through comparison after decryption of the complete key. The double verification mechanism greatly reduces the risk of false judgment or forged key passing the verification, ensuring the security of initial access. Even if it is the first request, the design of multi-layer encryption and separate storage can be used to avoid direct exposure of the complete key, and the core principle of "never trust, always verify" under the zero trust architecture is maintained. After successful verification, the verification result (or key information) is stored in the two-level cache (memory, Redis, database) composed of primary memory and secondary storage Redis. Subsequent requests from the same user can directly read the verification result from the memory or Redis if the cache is valid, without the need to repeat the time-consuming database query and key decryption, comparison process, greatly improving the response speed of API calls and system throughput. The memory cache (1 day) provides the highest speed and is suitable for high-frequency access; the Redis cache (1 year) provides persistent and relatively fast access and is suitable for medium-frequency or verification status sharing across services; 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, cache effectively reduces the number of direct database accesses, reducing the load on the database, helping to extend the life of the database and possibly reducing related costs. Only when the cache is not hit, complete key decryption and comparison operations are required, reducing the consumption of computing resources. The status of the verification result (success / failure) is uniformly managed and stored, facilitating subsequent auditing, monitoring, or decision-making. In summary, the scheme ensures the security of the first request while providing significant performance improvement for subsequent requests through the introduction of a multi-level cache mechanism, achieving a balance between security and efficiency, and meeting the requirements of distributed systems and zero trust architecture.

[0100] In one embodiment, in the cache hit mode, i.e., the second request in a short time, the second API request is initiated to call the API key; the target number of plaintext keys are extracted; it is checked whether the mapping relationship corresponding to the target plaintext key and the complete key exists in the memory cache; if the corresponding mapping relationship is found in the memory, the verification is passed directly. For example, the user initiates the API request again, the system extracts the last 20 bits of the key, the system checks the memory cache, finds the corresponding mapping relationship, and directly verifies the pass without decryption operation. Since the mapping relationship between the target plaintext key and the complete key has been stored in the memory cache, it is not necessary to perform the time-consuming decryption operation again, which significantly reduces the calculation burden, improves the processing speed of the API request, and the memory cache provides extremely fast access speed, so that the verification process can be completed almost instantaneously, greatly improving the user experience and system throughput; unnecessary encryption / decryption operations are avoided, the CPU burden is reduced, and the memory resources are also saved. Since the verification result is directly read from the memory, the access to the external storage (such as Redis or database) is reduced, and the I / O operation overhead is reduced; by quickly processing the verification request through the memory cache, the system can better support the high-concurrency scenario, improve the overall scalability of the system, avoid the database or Redis access bottleneck caused by a large number of requests in a short time, and ensure that the system can maintain good performance under high load; in the cache hit mode, the verification process becomes very simple, and only the memory cache needs to be checked, which simplifies the design and implementation of the system. In summary, the scheme in the cache hit mode stores the mapping relationship between the target plaintext key and the complete key by using the memory cache, realizes fast verification, significantly improves the response speed and performance of the system, reduces resource consumption, improves the scalability of the system, and simplifies the system design. This design is particularly suitable for scenarios that require frequent verification and have high performance requirements, such as high-concurrency API calls.

[0101] In one embodiment, in the memory cache expiration mode, i.e., the memory cache has expired, the third API request is initiated to call the API key; it is checked whether the mapping relationship corresponding to the target plaintext key and the complete key exists in the memory cache; when the corresponding mapping relationship is not found in the memory cache, the Redis cache is checked to find the mapping relationship corresponding to the target plaintext key and the complete key; the verification is passed, and the mapping relationship is written back to the memory cache.

[0102] In one embodiment, in the Redis cache expiration mode, the fourth API request is initiated to call the API key; it is checked whether the memory cache and the Redis cache have a mapping relationship corresponding to the target plaintext key and the complete key; when no corresponding mapping relationship is found in the memory cache and the Redis cache, the database is accessed to find the corresponding ciphertext data through the target plaintext key; the decrypted ciphertext data is compared with the user input key; and after verification, the verification result is written back to the memory cache and the Redis cache. Although the memory cache expires, the system does not directly jump to the slowest complete decryption verification path, but uses the lower-level Redis cache, which is usually much faster than directly accessing the database. Compared with the extremely fast speed of memory cache hit, Redis cache hit provides suboptimal but still fast verification speed, avoiding time-consuming decryption operation for each expired request, ensuring good user experience; using Redis as a secondary cache: the existence of Redis cache (validity period of 1 year) means that during the short expiration period of the memory cache, the verification information is still available, greatly increasing the possibility of cache hit and reducing the need to directly access the database. The memory cache is fast but volatile, the Redis cache is relatively fast and relatively persistent, and the database is the slowest but the most persistent. This three-layer structure effectively balances speed, cost and persistence. Even if the memory cache is invalid due to expiration or other reasons, the system can still quickly complete the verification by accessing the Redis cache, ensuring service continuity and availability, and preventing service interruption or performance degradation due to cache problems. After Redis cache hit and verification, the mapping relationship is written back to the memory cache. This process is called cache backfilling or preheating. It ensures that the next (fourth) request using the same key can again use the high-speed memory cache, effectively "repairing" the expired memory cache state and maintaining efficient processing of subsequent requests. By prioritizing the use of Redis cache, the frequency of directly accessing the database for decryption and verification is significantly reduced, reducing the load on the database and helping to stabilize the operation and cost control of the database. In summary, the scheme introduces Redis as a backup layer for the memory cache, providing a performance-optimized degradation path when the memory cache expires. It ensures that even in the case of temporary unavailability of the memory cache, the system can still quickly respond to user requests and quickly recover the effectiveness of the memory cache through an automatic backfilling mechanism, further enhancing the efficiency, reliability and overall performance of the entire key verification process, while optimizing resource usage.

[0103] The traditional API key verification system has obvious performance bottlenecks: each request needs to perform complete encryption on the API key provided by the user, and then compare it with the ciphertext stored in the database. This approach has huge computational overhead in high-frequency calling scenarios.

[0104] The embodiment of the application proposes an innovative PartialKey fast matching and selective decryption mechanism, and the working principle is as follows:

[0105] PartialKey is extracted from the input key provided by the user, which can be a prefix or a fingerprint, and is used for fast lookup. For example, the first 16 bits of the key are extracted as PartialKey;

[0106] PartialKey is used to quickly locate candidate records in the database, and only encrypted keys that can match are returned. This is achieved through database indexing to improve search speed. If no matching record is found, an error is returned quickly, indicating that the provided API key is invalid. The cache is checked first to avoid repeated decryption. If there is a matching record in the cache, the user information in the cache is returned directly;

[0107] If the input key already exists in the cache, the user information in the cache is returned directly to avoid repeated calculations;

[0108] Only the encrypted records matching PartialKey are fully decrypted and compared with the input key. If they match, the verification is successful;

[0109] 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 scheme significantly improves database query efficiency, reduces computational overhead, improves cache utilization, enhances security, and improves system scalability. These improvements enable the system to handle API key verification requests more efficiently and securely, especially in high-concurrency and large-scale key management scenarios. The core advantages of the embodiment are as follows: 1. Two-stage verification: first, perform low-cost PartialKey matching, and only perform computationally intensive full decryption when there is a potential match; 2. Index optimization: PartialKey is stored as an index field, which significantly improves database search efficiency; 3. Cache acceleration: combined with a multi-level cache strategy to reduce repeated decryption operations; 4. Computational 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.

[0110] The embodiment of the application has the following technical advantages: extremely high data security: even if the database is completely accessed, the API key is still 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 needs to go through a complete verification process; fine-grained access control: a multi-dimensional access control matrix ensures accurate permission management and resource isolation; high performance: the innovative caching mechanism significantly reduces encryption and decryption overhead, improving system response speed; self-adaptation: the system can automatically adjust resource allocation and access strategies according to real-time conditions.

[0111] Based on the same inventive concept, the application also provides a distributed API key management and access control system based on a zero trust architecture, comprising:

[0112] The request module is configured to call the API key according to a user request;

[0113] The storage module is configured to encrypt the complete key based on a multi-layer encryption storage mechanism and store the partial key in plaintext, so that the encryption key and the encrypted data are stored separately;

[0114] The one-stage verification module is configured to extract the target plaintext key of the API key based on a PartialKey fast matching and selective decryption mechanism, quickly locate the potential matching encrypted record through a PostgreSQL database index to perform first-stage verification;

[0115] The two-stage verification module is configured to, after the first-stage verification passes, obtain the complete key corresponding to the target plaintext key and decrypt it, and perform second-stage verification by comparing the decrypted complete key with the user input key until the verification passes and the key is stored in a two-level cache composed of a first-level memory and a second-level storage redis;

[0116] The first running mode triggers the request to fall into the third-level storage PostgreSQL, and once the verification passes, the cache is written in the first-level memory and the second-level storage redis, and the next request directly passes the first-level memory verification;

[0117] The normal running mode performs key verification in the order of the first-level memory, the second-level storage redis cache, and the final third-level storage PostgreSQL. The implementation principle of the above modules can refer to the method for managing and controlling access to a distributed API key based on a zero trust architecture described in the embodiments, and will not be described here.

[0118] In some embodiments of the present application, an electronic device is also provided. The electronic device comprises a memory and a processor, wherein the memory is configured to store a processing program; and the processor is configured to implement the method for distributed API key management and access control based on a zero trust architecture according to the embodiments of the present application when executing the processing program. When the processor executes the processing program, the method for distributed API key management and access control based on a zero trust architecture according to the aforementioned embodiments is implemented.

[0119] The present application provides a computer readable storage medium having stored thereon a processing program, the processing program being configured to implement the method for distributed API key management and access control based on a zero trust architecture according to the embodiments of the present application when executed by a processor. The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium include the following: a portable computer diskette, 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 disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or punched tape, as well as any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0120] The above has described the embodiments of the present disclosure, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes are obvious to those skilled in the art without departing from the scope and spirit of the described embodiments. The choice of terms used herein is intended to best explain the principles of the embodiments, practical applications, or improvements to the technology in the market, or to enable other ordinary skilled persons in the art to understand the embodiments disclosed herein.

Claims

1. A distributed API key management and access control method based on a zero-trust architecture, characterized in that, include: The API key is invoked based on the user's request; The system employs a multi-layered encryption storage mechanism to encrypt and store the complete key while extracting a portion of the key for plaintext storage, thus separating the encryption key from the encrypted data. This includes: receiving a user registration request and generating an API key with a first target number of bits; encrypting the complete key using ChaCha20Poly1305 to obtain encrypted ciphertext; extracting a second target number of bits from the key as a target plaintext key, where the first target number of bits is greater than the second target number of bits; and storing the generated final key record in a database. The final key record includes the complete ciphertext and the target plaintext key used as an index. The target plaintext key of the API key is extracted based on the PartialKey fast matching and selective decryption mechanism, and the potentially matching encrypted record is quickly located 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 then fully compared with the user-input key for the second stage of verification. Once the verification is passed, the key is stored in a two-level cache consisting of primary memory and secondary storage Redis. In the initial run mode, the triggered request falls into the third-level storage PostgreSQL. Once the verification is successful, it is immediately written to the cache in the first-level memory and the second-level storage Redis. Subsequent requests will directly pass the verification through the first-level memory. In normal operating mode, key verification is performed in the following order: first-level memory - second-level storage Redis cache - and finally third-level storage PostgreSQL.

2. The distributed API key management and access control method based on zero-trust architecture as described in claim 1, characterized in that, Also includes: In cold start mode, initiate an API request to invoke the API key; The plaintext key of the second target bit is extracted and verified in two stages. The decrypted complete key is compared with the key entered by the user. The verification is successful after the comparison is consistent.

3. The distributed API key management and access control method based on zero-trust architecture as described in claim 1, characterized in that, Also includes: In cache hit mode, Extract the plaintext key for the second target bit length; Check if a mapping relationship exists between the target plaintext key and the complete key in the memory cache; If the corresponding mapping is found in memory, the verification is successful.

4. The distributed API key management and access control method based on zero-trust architecture as described in claim 1, characterized in that, Also includes: In memory cache expiration mode, Check if a mapping relationship exists between the target plaintext key and the complete key in the memory cache; If the corresponding mapping is not found in the memory cache, check the Redis cache to find the mapping between the target plaintext key and the full key; Upon successful verification, the mapping relationship is rewritten to the memory cache.

5. The distributed API key management and access control method based on zero-trust architecture as described in claim 1, characterized in that, Also includes: Redis cache expiration mode Check whether there is a mapping relationship between the target plaintext key and the full key in the memory cache and Redis cache; If no corresponding mapping is found in either the memory cache or the Redis cache, the database is accessed to find the corresponding encrypted data using the target plaintext key. The decrypted ciphertext data is fully compared with the user-input key; After successful verification, the verification results will be rewritten to the memory cache and Redis cache.

6. The distributed API key management and access control method based on zero-trust architecture as described in claim 1, characterized in that, The target plaintext key for extracting the API key based on the PartialKey fast matching and selective decryption mechanism further includes: Extract a partial key (PartialKey) from the user-provided input key; Use PartialKey to quickly locate candidate records in the database and return only the encryption keys that can match; If the input key already exists in the cache, the cached user information is returned directly to avoid duplicate calculations. Only the encrypted records matched by 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.

7. A distributed API key management and access control system based on a 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 6, comprising: The request module is used to invoke the API key based on the user's request; The storage module is used to encrypt and store the complete key and extract 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. 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 to quickly locate the potentially matching encrypted records through the PostgreSQL database index for the first-stage verification. The two-stage verification module is used to obtain the complete key corresponding to the target plaintext key after the first-stage verification is passed, and decrypt it. The decrypted complete key is then compared with the user-input key to perform the second-stage verification until the verification is passed. The key is then stored in a two-level cache consisting of primary memory and secondary storage Redis. In the initial run mode, the triggered request falls into the third-level storage PostgreSQL. Once the verification is successful, it is immediately written to the cache in the first-level memory and the second-level storage Redis. Subsequent requests will directly pass the verification through the first-level memory. In normal operating mode, key verification is performed in the following order: first-level memory - second-level storage Redis cache - and finally third-level storage PostgreSQL.

8. An electronic device, characterized in that, include: The memory is used to store the processing program; A processor, which, when executing the processing program, implements the distributed API key management and access control method based on a zero-trust architecture as described in any one of claims 1 to 6.

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

Images