A key management method and system based on a multi-tenant technology architecture

Abstract

The application provides a key management method and system based on a multi-tenant technology architecture, the method comprising creating a plurality of mutually independent accounts and configuring an access control policy, creating a tenant key and storing the tenant key in a cryptographic device; initiating a cryptographic operation request through a client calling a cryptographic operation interface and automatically generating a first request message; performing tenant identity authentication and policy verification; if the verification is passed, extracting a logical key label to obtain an associated cryptographic object and a physical key label thereof, and determining a cryptographic service instance; the cryptographic service instance generating a cryptographic operation instruction according to the physical key label and delivering the cryptographic operation instruction to the cryptographic device; and the cryptographic device searching for the tenant key and performing a cryptographic operation on tenant encrypted data. Through key layering and access control policy design, the logical and physical keys of different tenants are isolated in the case of shared cryptographic devices, and strict policy authentication information is provided to avoid the risk of large-scale cross-tenant data leakage.

Description

Technical Field

[0001] This invention relates to the field of key management technology, and specifically to a key management method and system based on a multi-tenant technology architecture. Background Technology

[0002] With the popularization of cloud computing, big data and microservice architecture, multi-tenancy technology architecture has become the core architecture pattern of cloud services and Platform as a Service (PaaS). Applying multi-tenancy technology architecture can enable multiple independent tenants to provide services simultaneously through a single software instance or hardware infrastructure. Different tenants achieve data isolation, secure access, and independence of configuration and operation through independently managed encryption keys.

[0003] However, existing key management systems are typically built around a single organization. The management systems provided by hardware security modules or encryption machines mostly serve only a single group of users within a trusted boundary, and do not address multi-tenant applications. Such key management schemes often allow unrestricted use of keys once authentication is complete; that is, once identity is authenticated, the entity is considered fully trusted and can access and manage all keys stored in the encryption machine without restriction, and perform various cryptographic operations. In a multi-tenant environment, this key management scheme cannot achieve data isolation in a multi-tenant technical architecture, posing security risks such as large-scale, cross-tenant data leakage and fault propagation. Therefore, there is an urgent need for a key management method and system that can support multiple tenants working independently and provide tenants with strict policy authentication information. Summary of the Invention

[0004] To address the common problems in existing technologies, the present invention aims to provide a key management method and system based on a multi-tenant technology architecture. This invention achieves the isolation of logical and physical keys of different tenants in the case of shared cryptographic devices through key layering and access control policy design, and provides tenants with strict policy authentication information to avoid the risk of large-scale leakage of cross-tenant data.

[0005] The present invention achieves the above objectives through the following technical solutions: A key management method based on a multi-tenant technology architecture includes: Create multiple independent accounts, add tenant information and configure corresponding access control policies for each account, create tenant keys and store them in a cryptographic device.

[0006] The client initiates a password operation request by calling the password operation interface and automatically generates a first request message. After parsing the first request message, tenant authentication is performed. If the authentication is successful, the corresponding access control policy is obtained and the policy is validated.

[0007] If the policy verification passes, the logical key tag in the first request message is extracted, the associated cryptographic object is obtained based on the logical key tag, the physical key tag in the cryptographic object is extracted and a second request message including the physical key tag is generated, and the cryptographic service instance to which the cryptographic operation request applies is determined based on the cryptographic object and the cryptographic service routing rules.

[0008] The cryptographic service instance receives the second request message, parses the second request message, generates a cryptographic operation instruction based on the physical key tag, and sends it to the cryptographic device; the cryptographic device searches for the corresponding tenant key based on the cryptographic operation instruction, and uses the tenant key to perform corresponding cryptographic operations on the tenant encrypted data.

[0009] A further approach is to use a random number generator or security identifier to create multiple accounts with unique system IDs.

[0010] The account is bound to specific tenant information, which includes tenant identity identifier, business line identifier, account status, and isolation domain information; wherein, the isolation domain information includes data isolation domain and resource isolation domain.

[0011] The access control policy is configured based on an attribute-based access control model, and the access control policy is associated with the corresponding tenant identity.

[0012] A further approach is that the configuration of the access control policy includes: The attribute set is defined based on the tenant information, and the attribute set includes subject attributes, resource attributes, operation attributes, and environment attributes.

[0013] Define access rules, including rules for accessible network addresses, accessible time periods, accessible key tags, and operable cryptographic interfaces; if the access rules are met, access is allowed; otherwise, access is denied.

[0014] A further solution is that the system automatically associates the corresponding tenant information after the account logs in.

[0015] Extract the isolation domain information, automatically inject and transmit tenant context information through dynamic SQL based on the data isolation domain, and attach query filtering conditions based on the tenant context information.

[0016] Resource groups are assigned to tenants based on the resource isolation domain via database accounts. These resource groups are used to limit the upper limit of tenant resource usage.

[0017] A further approach is that the first request message includes a tenant identity identifier, identity credentials, a client network address, a logical key tag, and the password operation interface. The identity credentials are used to authenticate the tenant identity identifier. If authentication fails, an authentication failure message is generated and returned to the client.

[0018] If the identity authentication is successful, the corresponding access control policy is obtained based on the tenant identity identifier, and the client network address, the logical key tag, and the password operation interface are verified by the policy. If the access rules are met, the verification is successful; otherwise, a policy authentication failure message is generated and returned to the client.

[0019] A further approach is to extract the subject attributes, resource attributes, operation attributes, and environment attributes of the first request message, and match them with the corresponding attributes defined in the attribute set. If a match is found, the access control policy is triggered and policy verification is performed.

[0020] The main attributes include tenant identity identifier and tenant role; the resource attributes include the tenant identity identifier to which the resource belongs, resource type, and data sensitivity tag; the operation attributes include read, write, and delete; and the environment attributes include access time and client network address.

[0021] A further approach involves providing a configuration database that stores the mapping relationship between the logical key tag and the password object; a composite key is generated based on the tenant identity identifier and the logical key tag to query the configuration database to obtain the corresponding password object.

[0022] The cryptographic object includes the physical key tag, key algorithm, key status, historical cryptographic service instance ID, and key version number.

[0023] A further approach is to determine the cryptographic service instance using key affinity routing or load balancing routing.

[0024] The key affinity routing steps include: reading the historical cryptographic service instance ID in the cryptographic object, using the cryptographic service instance corresponding to the historical cryptographic service instance ID as the access target, and routing the cryptographic operation request to the cryptographic service instance.

[0025] The load balancing routing steps include: constructing a hash ring, using a consistent hashing algorithm to calculate a hash value with the tenant identity identifier and the physical key tag as input, and locating the cryptographic service instance on the hash ring based on the hash value.

[0026] A further approach is that, after receiving the second request message, the cryptographic service instance calls the corresponding standard interface for adaptation based on the type of the cryptographic device.

[0027] After the cryptographic operation is completed, the cryptographic device returns the cryptographic operation result to the cryptographic service gateway via the cryptographic service instance. The cryptographic service gateway generates a KMIP response message and sends it back to the security gateway. The security gateway is used to update the operation log according to the KMIP response message, generate a structured response message, and return it to the client.

[0028] A key management system based on a multi-tenant architecture, employing the aforementioned key management method, includes a client, a security gateway, a cryptographic service gateway, and a server. The client initiates a cryptographic operation request by calling a cryptographic operation interface and generates a structured first request message based on the interface. The security gateway receives the first request message, parses it, performs tenant authentication and access control policy verification, and forwards the first request message to the cryptographic service gateway upon successful verification. The server includes a cryptographic service instance and a cryptographic device. The cryptographic service gateway extracts a logical key tag from the first request message, obtains an associated cryptographic object based on the logical key tag, extracts a physical key tag from the cryptographic object, generates a second request message, determines the cryptographic service instance corresponding to the cryptographic operation request based on the cryptographic object and cryptographic service routing rules, and forwards the second request message to the cryptographic service instance. The cryptographic service instance generates a cryptographic operation instruction based on the physical key tag and sends it to the cryptographic device. The cryptographic device performs corresponding cryptographic operations based on the cryptographic operation instruction. Therefore, compared with the prior art, the present invention has the following beneficial effects: 1. This invention, through key layering and access control strategy design, compared with the existing single-tenant cryptographic machine management mode, achieves the isolation of logical and physical keys of different tenants in the case of shared cryptographic devices, avoiding the risk of large-scale leakage of cross-tenant data.

[0029] 2. The present invention uses an attribute-based access control model to configure the access control policy, which can flexibly formulate dynamic combination strategies of multi-dimensional attributes to achieve fine-grained dynamic access control.

[0030] 3. This invention queries a unique cryptographic object by using a composite key of tenant identity identifier and logical key tag, and then obtains the physical key tag, which can achieve secure isolation of operations between tenants.

[0031] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0032] Figure 1 This is a flowchart of a key management method based on a multi-tenant technology architecture according to the present invention.

[0033] Figure 2 This is a system architecture diagram in an embodiment of the key management system based on multi-tenant technology architecture of the present invention. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0035] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0036] See Figure 1 The present invention provides a key management method based on a multi-tenant technology architecture, comprising: Create multiple independent accounts, add tenant information and configure corresponding access control policies for each account, create tenant keys and store them in a cryptographic device.

[0037] The client initiates a password operation request by calling the password operation interface and automatically generates a first request message. After parsing the first request message, tenant authentication is performed. If the authentication is successful, the corresponding access control policy is obtained and the policy is validated.

[0038] If the policy verification passes, the logical key tag in the first request message is extracted, the associated cryptographic object is obtained based on the logical key tag, the physical key tag in the cryptographic object is extracted and a second request message including the physical key tag is generated, and the cryptographic service instance to which the cryptographic operation request applies is determined based on the cryptographic object and the cryptographic service routing rules.

[0039] The cryptographic service instance receives the second request message, parses the second request message, generates a cryptographic operation instruction based on the physical key tag, and sends it to the cryptographic device; the cryptographic device searches for the corresponding tenant key based on the cryptographic operation instruction, and uses the tenant key to perform corresponding cryptographic operations on the tenant encrypted data.

[0040] In this embodiment, multiple accounts with unique system IDs are created using a random number generator or a security identifier.

[0041] The account is bound to specific tenant information, which includes tenant identity identifier, business line identifier, account status, and isolation domain information; wherein, the isolation domain information includes data isolation domain and resource isolation domain.

[0042] The access control policy is configured based on an attribute-based access control model, and the access control policy is associated with the corresponding tenant identity.

[0043] In this embodiment, the configuration of the access control policy includes: The attribute set is defined based on the tenant information, and the attribute set includes subject attributes, resource attributes, operation attributes, and environment attributes.

[0044] Define access rules, including rules for accessible network addresses, accessible time periods, accessible key tags, and operable cryptographic interfaces; if the access rules are met, access is allowed; otherwise, access is denied.

[0045] In this embodiment, after the account logs in, the system automatically associates the corresponding tenant information.

[0046] Extract the isolation domain information, automatically inject and transmit tenant context information through dynamic SQL based on the data isolation domain, and attach query filtering conditions based on the tenant context information.

[0047] Specifically, in this embodiment, the system identifies the data isolation domain of the tenant to which the current password operation belongs. Based on this data isolation domain, an AOP interceptor dynamically rewrites the SQL statement at runtime, automatically injecting tenant filtering conditions, such as adding a tenant identity filtering condition with "tenant_id". Simultaneously, during inter-microservice calls, the tenant identity is passed through tenant context information to ensure that cross-service data access always maintains the correct tenant context information, achieving end-to-end data isolation.

[0048] Resource groups are assigned to tenants based on the resource isolation domain via database accounts. These resource groups are used to limit the upper limit of tenant resource usage.

[0049] Specifically, in this embodiment, the system assigns a dedicated database account to each tenant based on a resource isolation domain and binds the tenant's account to a specific database resource group. Through the database resource management function, quota limits such as CPU, memory, I / O bandwidth, and concurrent connections are preset for each resource group, thereby ensuring that the resource usage of any tenant is limited to a predetermined range and preventing the excessive consumption of a single tenant from affecting the service quality of other tenants.

[0050] In this embodiment, the first request message includes a tenant identity identifier, identity credentials, client network address, logical key tag, and the password operation interface. The identity credentials are authenticated based on the tenant identity identifier. If authentication fails, an authentication failure message is generated and returned to the client.

[0051] Specifically, in this embodiment, the first request message also includes a user password. When the client sends the first request message to the security gateway, the security gateway records the log of the password operation request and parses the message to obtain the tenant identity identifier and user password, and confirms the legitimacy of the tenant identity through the authentication center.

[0052] If the identity authentication is successful, the corresponding access control policy is obtained based on the tenant identity identifier, and the client network address, the logical key tag, and the password operation interface are verified by the policy. If the access rules are met, the verification is successful; otherwise, a policy authentication failure message is generated and returned to the client.

[0053] Specifically, this embodiment configures accessible addresses, accessible time periods, password label black / white lists, accessible password services, and operable password interfaces in the access control policy. One or more accessible addresses and accessible time periods can be configured. The policy verification steps include: verifying whether the client's network address is among the configured accessible addresses, whether the current time period is within the accessible time period, whether the logical key label is in the password label whitelist or not in the password label blacklist, whether the password service containing the key is accessible, and whether the operation uses the password in the message. If the above policy verifications are not met, a policy authentication failure message is generated and returned to the client.

[0054] In this embodiment, the subject attribute, resource attribute, operation attribute, and environment attribute of the first request message are extracted and matched with the corresponding attributes defined in the attribute set. If a match is found, the access control policy is triggered and policy verification is performed.

[0055] The main attributes include tenant identity identifier and tenant role; the resource attributes include the tenant identity identifier to which the resource belongs, resource type, and data sensitivity tag; the operation attributes include read, write, and delete; and the environment attributes include access time and client network address.

[0056] Specifically, this embodiment configures the access control policy based on the attribute-based access control model, which can flexibly formulate dynamic combination policies of multi-dimensional attributes to achieve fine-grained dynamic access control.

[0057] In this embodiment, a configuration database is provided, which stores the mapping relationship between the logical key tag and the password object; a composite key is generated based on the tenant identity identifier and the logical key tag to query the configuration database to obtain the corresponding password object.

[0058] The cryptographic object includes the physical key tag, key algorithm, key status, historical cryptographic service instance ID, and key version number.

[0059] Specifically, the execution statement for the composite key in this embodiment is: SELECT * FROM key_metadata WHERE tenant_id = 'tenant_abc' AND logical_label = 'prod_payment_aes_key_v1', where key_metadata is the configuration database, tenant_id = 'tenant_abc' is the tenant ID 'tenant_abc', and logical_label = 'prod_payment_aes_key_v1' is the logical key label 'prod_payment_aes_key_v1'.

[0060] Among them, the same tenant identity can have different logical key tags. For example, in the scenario where the same tenant creates multiple keys for different business purposes, different tenant identities can have the same logical key tag. In the scenario where different tenants create keys for the same business purposes, the unique password object can be queried by using the composite key of the tenant identity and logical key tag, and then the physical key tag can be obtained, which can achieve secure isolation of operations between tenants.

[0061] In this embodiment, the cryptographic service instance is determined using either key affinity routing or load balancing routing.

[0062] The key affinity routing steps include: reading the historical cryptographic service instance ID in the cryptographic object, using the cryptographic service instance corresponding to the historical cryptographic service instance ID as the access target, and routing the cryptographic operation request to the cryptographic service instance.

[0063] Specifically, in this embodiment, the historical cryptographic service instance ID is set when the tenant key is used for the first time or migrated. To improve performance, the cryptographic service instance caches the metadata and session handle of commonly used tenant keys in local memory. In this way, when the cryptographic service instance receives the second request message, it can immediately select the local cache and start a session with the cryptographic device to avoid the overhead of establishing a new session with the cryptographic device every time.

[0064] Specifically, this embodiment also includes health status routing rules. The cryptographic service gateway periodically sends heartbeat data packets to all cryptographic service instances, determines the health status of the instances based on the responses, and updates the status cache in real time according to the health status. When a historical cryptographic service instance ID is read, the health status of its corresponding instance is checked. If it is healthy, the instance is used as the access target; if it is unhealthy, failover is triggered, and a suitable cryptographic service instance is reselected from the health status pool according to the load balancing routing method.

[0065] The load balancing routing steps include: constructing a hash ring, using a consistent hashing algorithm to calculate a hash value with the tenant identity identifier and the physical key tag as input, and locating the cryptographic service instance on the hash ring based on the hash value.

[0066] Specifically, in this embodiment, the address range is 0~ The hash value space is mapped to a virtual hash ring; the unique identifier of each cryptographic service instance is hashed and mapped onto the hash ring, and each cryptographic service instance corresponds to multiple virtual nodes hashed on the hash ring; the tenant identity identifier and the physical key tag are used as inputs to calculate the hash value using a consistent hashing algorithm, and the first virtual node on the hash ring is found in a clockwise direction starting from the position of the hash value on the hash ring, which is the corresponding target cryptographic service instance.

[0067] In this embodiment, after receiving the second request message, the cryptographic service instance calls the corresponding standard interface for adaptation according to the type of the cryptographic device.

[0068] Specifically, the standard interfaces in this embodiment include the JCE interface, the PKCS#11 interface, and the SDF interface. The JCE interface is suitable for Java applications to call the cryptographic service environment; the PKCS#11 interface is suitable for cross-platform, multi-language applications to access cryptographic devices; and the SDF interface is suitable for the Chinese national cryptographic server cryptographic machine.

[0069] Specifically, after the cryptographic operation is completed, the cryptographic device returns the cryptographic operation result to the cryptographic service gateway via the cryptographic service instance. The cryptographic service gateway generates a KMIP response message and sends it back to the security gateway. The security gateway is used to update the operation log according to the KMIP response message, generate a structured response message, and return it to the client.

[0070] Specifically, this embodiment also includes a key rotation strategy to reduce the risk of key leakage. The key rotation strategy is set with triggering conditions, including time conditions, usage conditions, or manual triggering. For example, the time condition is set to rotate automatically every 90 days; the usage condition is set to trigger when the number of encryption or signing operations of the tenant key reaches a threshold; and key rotation is manually triggered when a security event such as key leakage occurs.

[0071] Specifically, the key rotation steps in this embodiment include: After the key rotation mechanism is triggered, the system instructs the cryptographic device to generate a new tenant key, which has a new physical key tag. The new tenant key is registered in the configuration database, and a new mapping relationship is established between it and the logical key tag. At this point, the logical key tag is associated with both the new and old versions of the physical key tag.

[0072] The new mapping relationship is synchronized to the cryptographic service gateway, which then updates the cryptographic object, which includes both new and old versions of the physical key tag, to ensure that existing cryptographic operations are not interrupted. The new version is only used when a new cryptographic operation request is received.

[0073] Specifically, this embodiment also includes a verification phase for the new tenant key. The verification phase supports dual-key operation. The steps include: starting a background task for the encrypted existing data, gradually reading the existing data and decrypting it using the old tenant key, and then re-encrypting the decrypted data using the new tenant key and updating the storage.

[0074] See Figure 2A key management system based on a multi-tenant architecture, employing the aforementioned key management method, includes a client 10, a security gateway 20, a cryptographic service gateway 30, and a server 40. The client 10 initiates a cryptographic operation request by calling a cryptographic operation interface and generates a structured first request message based on the interface. The security gateway 20 receives the first request message, parses it, performs tenant authentication and access control policy verification, and forwards the first request message to the cryptographic service gateway 30 upon successful verification. The server 40 includes a cryptographic service instance and a cryptographic device. The cryptographic service gateway 30 extracts a logical key tag from the first request message, obtains an associated cryptographic object based on the logical key tag, extracts a physical key tag from the cryptographic object, generates a second request message, determines the cryptographic service instance corresponding to the cryptographic operation request based on the cryptographic object and cryptographic service routing rules, and forwards the second request message to the cryptographic service instance. The cryptographic service instance generates a cryptographic operation instruction based on the physical key tag and sends it to the cryptographic device. The cryptographic device performs corresponding cryptographic operations based on the cryptographic operation instruction.

[0075] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0076] The above embodiments are merely preferred embodiments of the present invention and should not be construed as limiting the scope of protection of the present invention. Any non-substantial changes and substitutions made by those skilled in the art based on the present invention shall fall within the scope of protection claimed by the present invention.

Claims

1. A key management method based on a multi-tenant technology architecture, characterized in that, include: Create multiple independent accounts, add tenant information to each account and configure corresponding access control policies, create tenant keys and store them in a cryptographic device; The client initiates a password operation request by calling the password operation interface and automatically generates a first request message, which includes the tenant identity identifier, identity credentials, client network address, logical key label, and the password operation interface. After parsing the first request message, tenant authentication is performed. If the authentication is successful, the corresponding access control policy is obtained and the policy is verified. If the policy verification passes, the logical key tag in the first request message is extracted, a unique password object is queried by the tenant identity identifier and the logical key tag composite key, the physical key tag in the password object is extracted and a second request message including the physical key tag is generated, and the password service instance to which the password operation request applies is determined according to the password object and the password service routing rules. The cryptographic service instance receives the second request message, parses the second request message, generates a cryptographic operation instruction based on the physical key tag, and sends it to the cryptographic device. The cryptographic device searches for the corresponding tenant key according to the cryptographic operation instruction, and uses the tenant key to perform corresponding cryptographic operations on the tenant encrypted data.

2. The key management method based on a multi-tenant technical architecture according to claim 1, characterized in that: Create multiple accounts with unique system IDs using a random number generator or security identifier; The account is bound to specific tenant information, which includes tenant identity identifier, business line identifier, account status, and isolation domain information; wherein, the isolation domain information includes data isolation domain and resource isolation domain. The access control policy is configured based on an attribute-based access control model, and the access control policy is associated with the corresponding tenant identity.

3. The key management method based on a multi-tenant technical architecture according to claim 2, characterized in that, The configuration of the access control policy includes: An attribute set is defined based on the tenant information, and the attribute set includes subject attributes, resource attributes, operation attributes, and environment attributes; Define access rules, including rules for accessible network addresses, accessible time periods, accessible key tags, and operable cryptographic interfaces; if the access rules are met, access is allowed; otherwise, access is denied.

4. The key management method based on a multi-tenant technical architecture according to claim 2, characterized in that: After the account logs in, the system automatically associates the corresponding tenant information; Extract the isolation domain information, automatically inject and transmit tenant context information via dynamic SQL based on the data isolation domain, and attach query filtering conditions based on the tenant context information; Resource groups are assigned to tenants based on the resource isolation domain via database accounts. These resource groups are used to limit the upper limit of tenant resource usage.

5. The key management method based on a multi-tenant technical architecture according to claim 3, characterized in that: The identity credential is authenticated based on the tenant identity identifier. If the authentication fails, an authentication failure message is generated and returned to the client. If the identity authentication is successful, the corresponding access control policy is obtained based on the tenant identity identifier, and the client network address, the logical key tag, and the password operation interface are verified by the policy. If the access rules are met, the verification is successful; otherwise, a policy authentication failure message is generated and returned to the client.

6. The key management method based on a multi-tenant technical architecture according to claim 5, characterized in that: Extract the subject attributes, resource attributes, operation attributes, and environment attributes of the first request message, and match them with the corresponding attributes defined in the attribute set. If a match is found, the access control policy is triggered and policy verification is performed. The main attributes include tenant identity identifier and tenant role; the resource attributes include the tenant identity identifier to which the resource belongs, resource type, and data sensitivity tag; the operation attributes include read, write, and delete; and the environment attributes include access time and client network address.

7. The key management method based on a multi-tenant technical architecture according to claim 5, characterized in that: A configuration database is provided, which stores the mapping relationship between the logical key label and the password object; a composite key is generated based on the tenant identity identifier and the logical key label to query the configuration database to obtain the corresponding password object; The cryptographic object includes the physical key tag, key algorithm, key status, historical cryptographic service instance ID, and key version number.

8. The key management method based on a multi-tenant technical architecture according to claim 7, characterized in that: The cryptographic service instance is determined using either key affinity routing or load balancing routing. The key affinity routing steps include: reading the historical cryptographic service instance ID in the cryptographic object, using the cryptographic service instance corresponding to the historical cryptographic service instance ID as the access target, and routing the cryptographic operation request to the cryptographic service instance; The load balancing routing steps include: constructing a hash ring, using a consistent hashing algorithm to calculate a hash value with the tenant identity identifier and the physical key tag as input, and locating the cryptographic service instance on the hash ring based on the hash value.

9. The key management method based on a multi-tenant technical architecture according to claim 1, characterized in that: After receiving the second request message, the cryptographic service instance calls the corresponding standard interface for adaptation according to the type of the cryptographic device. After the cryptographic operation is completed, the cryptographic device returns the cryptographic operation result to the cryptographic service gateway via the cryptographic service instance. The cryptographic service gateway generates a KMIP response message and sends it back to the security gateway. The security gateway is used to update the operation log according to the KMIP response message, generate a structured response message, and return it to the client.

10. A key management system based on a multi-tenant technology architecture, characterized in that, The key management method as described in any one of claims 1-9 includes: The system comprises a client, a security gateway, a cryptographic service gateway, and a server. The client initiates a cryptographic operation request by calling a cryptographic operation interface and generates a structured first request message based on the interface. This first request message includes a tenant identity identifier, identity credentials, the client's network address, a logical key tag, and the cryptographic operation interface. The security gateway receives the first request message, parses it, performs tenant authentication and access control policy verification, and forwards the message to the cryptographic service gateway upon successful verification. The server includes a cryptographic service instance and a cryptographic device. The cryptographic service gateway extracts the logical key tag from the first request message, queries a unique cryptographic object using the tenant identity identifier and the logical key tag composite key, extracts the physical key tag from the cryptographic object, generates a second request message, determines the cryptographic service instance corresponding to the cryptographic operation request based on the cryptographic object and cryptographic service routing rules, and forwards the second request message to the cryptographic service instance. The cryptographic service instance generates a cryptographic operation instruction based on the physical key tag and sends it to the cryptographic device. The cryptographic device performs corresponding cryptographic operations based on the instruction.

Images