Hybrid deployment information management system, method, and electronic device

Abstract

This application discloses a hybrid-deployed information management system, method, and electronic device, relating to the field of information management technology. It includes: a public service module for storing and processing non-sensitive information; a local service module for storing and processing sensitive information; and a gateway module for responding to business requests, parsing the business requests, identifying the business scenario of the business requests, obtaining the functional attributes of the business requests, and obtaining the privacy attributes of the business requests based on the functional attributes. When the privacy attribute is sensitive, the business request is transmitted to the local service module via a preset private network; when the privacy attribute is non-sensitive, the business request is transmitted to the public service module via the public network. This application achieves a deep integration of data security, compliance requirements, and low-cost operation and maintenance through progressive identification from functional attributes to privacy attributes, and differentiated transmission channels between private and public networks.

Description

Technical Field

[0001] This application relates to the field of information management technology, and in particular to information management systems, methods and electronic devices for hybrid deployment. Background Technology

[0002] With the deepening of digital transformation, information management systems have become the core carrier for various organizations to carry out business processes and store data. The system deployment mode directly affects data security, construction costs and compliance, and is the foundation for ensuring the organization's data compliance and smooth business operation.

[0003] Current information management systems are mainly divided into three models: full SaaS (Software as a Service), full private deployment, and hybrid deployment. However, all of them have significant drawbacks. Full private deployment can ensure data security, but the hardware investment cost exceeds 100,000 yuan, resulting in high implementation costs. Full SaaS deployment relies on public network transmission and cloud storage for data, posing a high risk of data leakage and failing to meet data localization compliance requirements. While existing hybrid deployments with public and private modules can store and process sensitive information locally, they also face the risk of data leakage. Therefore, existing system deployment models cannot simultaneously address data security, compliance requirements, and low-cost operation and maintenance, resulting in an inability to achieve a balanced approach to security, cost, and operation and maintenance.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a hybrid deployment information management system, method and electronic device, which aims to solve the technical problem that the existing system deployment mode cannot take into account data security, compliance requirements and low-cost operation and maintenance, and there is a lack of overall balance between security, cost and operation and maintenance.

[0006] To achieve the above objectives, this application proposes a hybrid deployment information management system, which includes: The public service module is used to store and process various non-sensitive information; The local service module is used to store and process various sensitive information; The gateway module is used to respond to business requests, parse the business requests, identify the business scenarios of the business requests, obtain the functional attributes of the business requests, and obtain the privacy attributes of the business requests based on the functional attributes. When the privacy attribute is sensitive, the business request is transmitted to the local service module through a preset private network. When the privacy attribute is non-sensitive, the business request is transmitted to the public service module through the public network.

[0007] In one embodiment, the gateway module is further configured to: Extract the interface name, request parameter fields, and data flow direction characteristics of the business request; When the interface name can identify the business scenario of the business request, the functional attributes of the business request are identified by the interface name. When the interface name cannot identify the business scenario of the business request, the functional attributes of the business request are identified by combining at least one of the request parameter fields and the data flow direction features.

[0008] In one embodiment, the gateway module is further configured to: By using a preset privacy classification model, the privacy classification and classification confidence of the functional attributes are obtained; When the privacy classification is greater than or equal to the preset confidence level, the privacy classification is used as the privacy attribute of the service request; When the classification confidence level is less than the preset confidence level, the privacy classification is further calibrated to obtain the privacy attributes of the business request, and when the privacy classification is inconsistent with the privacy attributes, the preset privacy classification model is optimized.

[0009] In one embodiment, the local service module includes: The business intent verification module is used to parse the business request transmitted by the gateway module, obtain the business scenario and user identity identifier of the business request, determine whether the business scenario and the user identity identifier are consistent, and intercept the business request when the business scenario and the user identity identifier are inconsistent.

[0010] In one embodiment, the local service module includes: The encrypted database module includes a sensitive information storage module and a key storage module, wherein the sensitive information storage module and the key storage module are physically isolated. The key storage module is used to store the key for each business scenario. The sensitive information storage module is used to store the sensitive information, wherein the sensitive information is encrypted by the scenario key.

[0011] In one embodiment, the sensitive information storage module is further configured to store business scenario identifiers for each of the sensitive information items; The local service module also includes: The sensitive data processing module is used to obtain sensitive information and a business scenario identifier from the sensitive information storage module according to the business request, obtain a scenario key from the key storage module according to the business scenario identifier, and decrypt the sensitive information using the scenario key to obtain decrypted sensitive information. The data transmission module is used to transmit the decrypted sensitive information through the preset private network.

[0012] In one embodiment, the public service module includes: Each sharding module is isolated from the others, and each sharding module is used independently to store and process non-sensitive information of the target tenant. The sharding routing module is used to parse the tenant identifier in the service request transmitted by the gateway module and dynamically map the service request to the target sharding module using a preset routing strategy.

[0013] In one embodiment, each sharding module is further configured to: Analyze the historical query logs and real-time access patterns of the target tenant, identify the unique query hotspots of the target tenant, and construct a composite index structure adapted to the business characteristics of the target tenant; When a service request mapped by the sharding routing module is received, the data requested by the service request is located according to the composite index structure.

[0014] Furthermore, to achieve the above objectives, this application also proposes a hybrid deployment information management method applied to an information management system, wherein the hybrid deployment information management method includes: In response to a business request, the business request is parsed, the business scenario of the business request is identified, the functional attributes of the business request are obtained, and the privacy attributes of the business request are obtained based on the functional attributes. When the privacy attribute is sensitive, the business request is transmitted to the local service module of the information management system through a preset private network. The local service module is used to store and process various sensitive information. When the privacy attribute is non-sensitive, the business request is transmitted over the public network to the public service module of the information management system. The public service module is used to store and process various non-sensitive information.

[0015] In addition, to achieve the above objectives, this application also proposes an electronic device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the hybrid deployment information management method as described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: In this embodiment, a hybrid deployment architecture comprising a public service module, a local service module, and a gateway module is first constructed. The storage and processing of non-sensitive and sensitive information are independently handled by the public and local service modules, respectively. This achieves physical isolation of data with different privacy levels at the system's underlying layer, directly embedding data security and compliance requirements into the system's operational logic. Next, the gateway module parses business requests and identifies business scenarios to obtain functional attributes. Based on these functional attributes, privacy attributes are then obtained, replacing the traditional method of judgment based on data field types. This effectively avoids classification errors caused by dynamic changes in data structure (such as field additions / deletions or business logic evolution), providing accurate path decision-making for subsequent data transmission. Then, based on the privacy attribute determination results, business requests with sensitive privacy attributes are transmitted to the local service module via a pre-set private network, while business requests with non-sensitive privacy attributes are transmitted to the public service module via the public network. This achieves strict matching between the transmission channel and the data privacy level, effectively eliminating the risk of sensitive data being intercepted and leaked during public network transmission. Finally, while ensuring data localization compliance, only local hardware resources need to be configured for sensitive information, significantly reducing the hardware investment costs associated with a fully private deployment.

[0017] This embodiment achieves a deep integration of data security, compliance requirements, and low-cost operation and maintenance through the gateway module's parsing of business requests, scenario identification, and progressive attribute judgment mechanism, as well as the differentiated transmission channel design for private and public networks. It solves the problems of high data leakage risk and inability to meet compliance requirements in full SaaS deployment, overcomes the high implementation cost of full private deployment, and makes up for the security shortcomings of direct public network transmission of sensitive data in existing hybrid deployment solutions. It deeply adapts to the dual demands of institutions for data security and cost control, breaks the limitations of existing system deployment models in that they cannot balance security, cost, and operation and maintenance, and provides reliable support for the compliant, stable, and low-cost operation of the institution's information management system. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a first schematic diagram of the module structure of the information management system with hybrid deployment according to an embodiment of this application; Figure 2This is a schematic diagram of the gateway module in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of the local service module in an embodiment of this application; Figure 4 This is a service flow diagram of the public service module in an embodiment of this application; Figure 5 This is a first schematic diagram of the module structure of the information management system with hybrid deployment according to an embodiment of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the hybrid deployment information management method in this application embodiment.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] The main solution in this application embodiment is: Current information management systems primarily rely on either full SaaS or full private deployment models, both of which suffer from systemic flaws. The full SaaS deployment model stores all data (including sensitive information) in the cloud and transmits it via the public internet, significantly increasing the risk of data breaches, leading to a higher rate of security incidents, and failing to meet compliance requirements for local data storage. While the full private deployment model ensures data security, it requires enterprises or organizations to purchase servers and establish maintenance teams, with hardware costs exceeding 100,000 RMB per enterprise or organization, which is unaffordable for most. Furthermore, the database lacks a dynamic partitioning mechanism based on tenants, supporting only time or geographical partitioning, resulting in query response times exceeding 20 seconds for millions of data entries. Data redundancy reduces backup efficiency by 40% and system throughput by 25%. Some systems employ hybrid deployments, but the private and SaaS modules are directly connected via the public internet without an encrypted channel, making data transmission vulnerable to man-in-the-middle attacks and increasing security risks by 50%. Manual firewall rule configuration is also required, increasing operational complexity by 30%. In addition, existing technologies cannot achieve independent management of multi-tenant data, further exacerbating performance bottlenecks.

[0025] In summary, existing technologies cannot simultaneously resolve the three major contradictions of data security, cost control, and big data performance: full SaaS sacrifices security, full privatization sacrifices cost, hybrid deployment sacrifices communication security, and the lack of database partitioning leads to performance bottlenecks. As a result, enterprises or organizations face multiple dilemmas when deploying information management systems, such as poor security compliance, high deployment costs, and slow system response.

[0026] This application provides a hybrid deployment information management system, comprising: a public service module for storing and processing various non-sensitive information; a local service module for storing and processing various sensitive information; and a gateway module for responding to business requests, parsing the business requests, identifying the business scenario of the business requests, obtaining the functional attributes of the business requests, and obtaining the privacy attributes of the business requests based on the functional attributes. When the privacy attribute is sensitive, the business requests are transmitted to the local service module via a preset private network; when the privacy attribute is non-sensitive, the business requests are transmitted to the public service module via the public network.

[0027] As can be seen from the above embodiments, this embodiment achieves a deep integration of data security, compliance requirements, and low-cost operation and maintenance through the gateway module's parsing of business requests, scenario identification, and attribute progressive judgment mechanism, as well as the differentiated transmission channel design for private networks and public networks. It not only solves the problems of high data leakage risk and inability to meet compliance requirements in full SaaS deployment, but also overcomes the shortcomings of high implementation costs in full private deployment. At the same time, it makes up for the security shortcomings of direct public network transmission of sensitive data in existing hybrid deployment solutions. It deeply adapts to the dual demands of institutions for data security and cost control, breaks the limitations of existing system deployment models in that they cannot balance security, cost, and operation and maintenance, and provides reliable support for the compliant, stable, and low-cost operation of the institutional information management system.

[0028] Specifically, embodiments of this application provide a hybrid deployment information management system, referring to... Figure 1 The hybrid-deployed information management system includes a public service module 10, a local service module 20, and a gateway module 30. Public service module 10 is used to store and process various non-sensitive information; It should be noted that the public service module 10 refers to the information storage and processing unit deployed in the public cloud environment, which is responsible for carrying general business data and functional logic in the system that do not involve user privacy or core business secrets; non-sensitive information refers to information categories that do not contain personal identification, core business secrets, privacy data protected by laws and regulations, etc., which are subject to restricted circulation.

[0029] Specifically, the public service module 10 can be built using infrastructure such as object storage services, relational databases, and function computing services provided by cloud service providers. It provides standard RESTful API interfaces to the public internet, receiving non-sensitive business requests forwarded from the gateway module 30 and performing corresponding data queries, business logic processing, and result returns. The public service module 10 benefits from the high elasticity and scalability of the public cloud environment and its low-cost operation and maintenance advantages, making it suitable for handling high-concurrency, high-throughput non-sensitive business traffic.

[0030] Local service module 20 is used to store and process various sensitive information; It should be noted that the local service module 20 refers to a private information storage and processing unit deployed locally on the enterprise or institution's premises. It is responsible for carrying sensitive business data and functional logic in the system that involve user privacy, trade secrets, or are subject to compliance requirements. Sensitive information includes categories of information that require restricted circulation, such as personal identification, core business secrets, and privacy data protected by laws and regulations.

[0031] Specifically, the local service module 20 is deployed in the enterprise or organization's own data center, dedicated private cloud, or local server with secure isolation capabilities. It establishes an encrypted communication link with the gateway module 30 through a pre-set private network and does not directly connect to the public network. The local service module 20 is equipped with an independent data storage system and computing resources. Sensitive information undergoes full lifecycle management locally, including collection, storage, processing, archiving, and destruction, and does not flow out of the local controllable domain. The local service module 20 can employ security mechanisms such as encrypted data storage, access control, and operation audit logs to ensure the confidentiality, integrity, and availability of sensitive information.

[0032] Gateway module 30 is used to respond to business requests, parse the business requests, identify the business scenarios of the business requests, obtain the functional attributes of the business requests, and obtain the privacy attributes of the business requests based on the functional attributes. When the privacy attribute is sensitive, the business requests are transmitted to the local service module through a preset private network. When the privacy attribute is non-sensitive, the business requests are transmitted to the public service module through the public network.

[0033] It should be noted that the gateway module 30 refers to the intelligent routing and security scheduling unit deployed at the entrance of the information management system. As the unified access point for all business requests, it is responsible for classifying, identifying, and routing business requests in a differentiated manner.

[0034] Additionally, it's important to clarify that "business scenario" refers to the actual business operation context corresponding to a business request. It describes the stage of the request within a specific business process and the type of operation performed, such as financial settlement, identity verification, or personal information file management. "Functional attribute" refers to the business function type identifier that the business request points to, describing the type of operation the request intends to perform. Compared to directly judging based on the data field types in the request, parsing functional attributes based on the business scenario effectively avoids classification errors caused by dynamic changes in data structure (such as field additions / deletions, parameter adjustments, or business logic evolution).

[0035] As an example, by extracting the interface name, request parameter fields, and data flow direction features of the business request, the interface name, request parameter fields, or data flow direction features are used as functional attributes of the business request. It is understandable that the interface name, request parameter fields, and data flow direction features can be used as functional attributes because: the interface name reflects the type and direction of the business operation; different interfaces correspond to different business functions at the design level. For example, " / api / payroll / disburse" naturally points to payroll processing, and " / api / account / balance / query" naturally points to account balance query. The interface name is the most direct identifier of the functional attribute. The request parameter fields reflect the specific object and content of the business operation. The parameter names and their combinations reveal the actual business entity processed by the request. For example, parameters containing "employeeName" and "bankAccount" usually point to human resources and finance operations, while parameters containing "noticeType" and "publishDate" usually point to announcement query operations. The parameter fields supplement the connotation of the functional attribute from the perspective of the operation object. The data flow direction features reflect the context of the business request. The source of the request, the target service node, and the data flow path can reconstruct the business process stage in which the request occurs. For example, a data flow pointing to a payroll transaction link indicates that the request is in the fund settlement process, while a data flow pointing to a public information query link indicates that the request is in the public service process. The data flow direction verifies the accuracy of the functional attributes from the perspective of business processes. These three elements, from the dimensions of operation type, operation object, and operation context, together constitute a complete expression of the functional attributes, enabling the same interface to be accurately distinguished under different parameter combinations or different data flow paths, thus achieving refined identification of business functions.

[0036] Additionally, it should be noted that privacy attributes refer to hierarchical labels obtained based on functional attribute mapping, used to identify the sensitivity of information involved in the service request; a pre-established private network refers to a secure dedicated network channel that is pre-established and physically or logically isolated from the public network. For example, a pre-established private network is an MPLS physical leased line, which adopts a dedicated fiber optic network architecture with physical layer isolation, and is completely separated from the public Internet network topology to avoid any public network nodes interfering with the transmission path.

[0037] Specifically, after receiving a business request from a client, the gateway module 30 first parses the function identifier field in the request message to obtain the functional attributes of the business request. The gateway module 30 internally maintains a preset mapping table between functional attributes and privacy attributes, which records the information sensitivity level corresponding to each business function type. Based on the obtained functional attributes, the gateway module 30 queries the mapping table to obtain the privacy attribute determination result of the business request. When the privacy attribute is sensitive, the gateway module 30 activates a preset private network encrypted link to securely transmit the business request to the local service module 20 deployed on the enterprise or organization's local machine for processing, ensuring that sensitive information does not leave the local domain. When the privacy attribute is non-sensitive, the gateway module 30 transmits the business request through the public network to the public service module 10 for processing, fully utilizing the elasticity and low-cost advantages of cloud resources. The gateway module 30 can also integrate additional functions such as protocol conversion, traffic control, identity authentication, and request log auditing to further enhance the system's security and manageability.

[0038] For example, when a bank's individual customer initiates a "check personal account balance" request through a mobile banking client, the gateway module 30 parses the function attribute as "account balance query" and determines that the privacy attribute is "sensitive." The request is then encrypted and transmitted via the financial private network to the local service module 20 deployed in the bank's internal computer room for processing. When an individual customer initiates a "check the latest foreign exchange rate" request, or a school finance staff member initiates a "check the bank's corporate business handling guide" request, the gateway module 30 determines that the privacy attributes of the above requests are "non-sensitive." The requests are then routed via the public internet to the public service module 10 for processing, and the corresponding data is quickly returned.

[0039] The hybrid information management system provided in this application embodiment stores and processes non-sensitive information through a public service module, stores and processes sensitive information through a local service module, and responds to business requests and performs differentiated routing based on the privacy attributes of the business requests, thus constructing a cloud-ground hybrid distribution and processing architecture based on information sensitivity levels. The gateway module first obtains the functional attributes of the business request and then obtains its privacy attributes based on those attributes, realizing a classification mechanism that automatically determines the information sensitivity level from the business function dimension. When the privacy attribute is sensitive, the gateway module transmits the business request through a pre-set private network to the local service module deployed on the enterprise or organization's premises. Sensitive information completes its full lifecycle management within a local closed loop, ensuring the security, compliance, and privacy protection of core data. When the privacy attribute is non-sensitive, the gateway module transmits the business request through the public network to the public service module, allowing non-sensitive services to enjoy the high elasticity, low cost, and wide coverage advantages of the public cloud. Therefore, this system achieves a balance between localized security control of sensitive information and efficient cloud processing of non-sensitive information. It is suitable for the differentiated information processing needs of individual customers and institutional customers such as schools in banking business scenarios. Under the premise of meeting data security and compliance requirements, it effectively reduces the overall system operation and maintenance costs and improves business response efficiency and resource utilization.

[0040] In one feasible implementation, the gateway module 30 is further configured to perform steps S1 to S3: Step S1: Extract the interface name, request parameter fields, and data flow direction characteristics of the business request; It should be noted that the interface name refers to the path identifier of the server-side interface called by the business request. The request parameter fields refer to the names and meanings of the parameters passed in the business request. The data flow direction characteristics refer to the source of the business request, the target service, and the data flow path. The business scenario refers to the actual business operation context corresponding to the request. Specifically, after receiving the business request, the gateway module extracts the three-dimensional information of the interface name, request parameter fields, and data flow direction characteristics from the request message.

[0041] Step S2: When the interface name can identify the business scenario of the business request, the functional attributes of the business request are identified by the interface name; It should be noted that when the interface name can identify the business scenario of the business request, it means that the interface name has been designed to correspond one-to-one with a specific business scenario. The business scenario and corresponding functional attributes can be uniquely determined by the interface name alone, without the need for other dimensions of information to assist in the determination.

[0042] Specifically, the gateway module maintains a direct mapping table between interface names and functional attributes. When the interface name corresponding to the business scenario identified in step S1 has a unique correspondence in this mapping table, the functional attributes of the request are directly obtained from the mapping table by the interface name, enabling rapid determination.

[0043] Step S3: When the interface name cannot identify the business scenario of the business request, the functional attributes of the business request are identified by combining at least one of the request parameter fields and the data flow direction features.

[0044] It should be noted that when the interface name cannot identify the business scenario of the business request, it means that the interface name corresponds to multiple candidate business scenarios, or the interface is a general interface reused by multiple business scenarios, or the interface cannot be associated with a business scenario, and the business scenario and functional attributes cannot be determined solely by the interface name. In this case, request parameter fields and data flow direction characteristics need to be introduced as supplementary discriminative dimensions to pinpoint the actual business scenario.

[0045] Specifically, the gateway module queries the list of candidate functional attributes corresponding to the interface name. If there are multiple candidates or no corresponding item in the list, it further analyzes the specific parameter combinations and data flow direction characteristics of the request parameter fields, and performs a secondary matching with the feature templates of each candidate functional attribute to finally determine the functional attribute of the request. This hierarchical determination mechanism effectively solves the business ambiguity problem in general interface reuse scenarios and newly added interfaces.

[0046] This implementation employs a hierarchical determination mechanism to identify the functional attributes of business requests. When the interface name can identify the business scenario, it is used directly for quick determination, ensuring efficiency. When the interface name cannot identify the business scenario, request parameter fields and data flow direction characteristics are introduced for secondary determination, thereby locking in the functional attributes. This mechanism effectively solves the business ambiguity caused by the reuse of new and general interfaces, while avoiding the risk of misjudgment based on a single field due to dynamic changes in data structure, thus balancing determination efficiency and accuracy.

[0047] In one feasible implementation, the gateway module 30 is further configured to perform the following steps: jointly match the interface name, the request parameter fields, and the data flow direction features with a preset multi-dimensional business scenario template to identify the business scenario in which the business request is located; and based on the business scenario, obtain the functional attributes of the business request from a preset scenario and function mapping table. Specifically, after receiving a business request initiated by a client, the gateway module 30 extracts three dimensions of identification information from the request message: first, it parses the API interface name of the request to obtain the path identifier of the server interface called by the request; second, it parses the request parameter fields to obtain the names and meanings of each parameter passed in the request; and third, it analyzes the data flow direction features of the request to obtain the call source, target service, and data flow path of the request. Subsequently, the gateway module 30 jointly matches the above three-dimensional information with the preset multi-dimensional business scenario template. The multi-dimensional business scenario template predefines the feature rules of each business scenario in the above three dimensions. When the three-dimensional information simultaneously matches the matching conditions of a certain business scenario template, it is determined that the request is in that business scenario. The gateway module 30 does not simply judge based on data field type, such as only checking whether the request contains sensitive field names like "ID number" or "bank account number." Instead, it performs multi-dimensional joint identification from the semantic level of the business scenario, effectively avoiding classification errors based on a single field caused by dynamic changes in the data structure of the business system (such as field additions, deletions, parameter adjustments, or business logic evolution). Based on this, the gateway module 30 queries a preset scenario-function mapping table to obtain the standardized functional attribute identifier corresponding to the identified business scenario. For example, in a banking system, a school's finance staff initiates a salary disbursement request for faculty members through corporate online banking. The gateway module 30 extracts the API interface of this request as " / api / payroll / disburse," and the request parameters include fields such as "employeeName," "bankAccount," and "salaryAmount," with the data flow pointing to the disbursement transaction processing link. The gateway module 30 performs joint matching of the above three-dimensional information with a preset multi-dimensional business scenario template, identifying the business scenario of the request as a "salary disbursement scenario," and then obtains the corresponding functional attribute "salary disbursement" from the preset scenario-function mapping table. When the same finance personnel initiates another request, the API interface is " / api / account / info / query", and the request parameters also include the "employeeName" field, but the data flow points to the public account information query link. After the three-dimensional information is combined and matched, the business scenario is identified as "public account information query scenario", and the obtained functional attribute is "public account information query".Both requests mentioned above contained the "employeeName" field. Using a traditional single-field-based judgment method, both requests might be misjudged as sensitive requests due to the presence of this field. However, this solution, through three-dimensional joint matching of API interface, parameter field combination, and data flow direction, accurately identified the different business scenarios of the two requests. The former was correctly judged as a sensitive operation, while the latter was correctly judged as a non-sensitive operation, demonstrating the significant advantage of multi-dimensional joint matching based on semantic understanding of business scenarios compared to single-field judgment. It is understandable that when a bank's corporate online banking system renames the "employeeName" field to "empName" due to a version upgrade, the traditional single-field-based judgment method might miss sensitive requests due to the field name change, leading to sensitive information being incorrectly routed to the public service module. This solution, through three-dimensional information joint matching, ensures that even if the parameter field name changes, the API interface name " / api / payroll / disburse" and data flow direction characteristics can still accurately reflect the payroll disbursement business scenario of the request. The gateway module 30 can still correctly identify the business scenario and obtain functional attributes, avoiding the risk of misjudgment caused by dynamic changes in data structure.

[0048] In one feasible implementation, the gateway module 30 is further configured to perform steps S4-S6: Step S4: Obtain the privacy classification and classification confidence of the functional attribute by using a preset privacy classification model; It should be noted that the preset privacy classification model refers to an automated classification model pre-built and deployed in the gateway module 30, used to determine the sensitivity level of information involved in a business request based on its functional attributes. The preset privacy classification model can be a mapping table or a neural network classification model. When the preset privacy classification model is a mapping table, the mapping table maintains a record of the correspondence between functional attributes and privacy level labels. Each record includes a functional attribute identifier, a corresponding privacy classification label, a mark indicating whether the record originated from manual calibration, and a confidence weight for the calibration record. The gateway module 30 inputs the functional attributes into the mapping table for query matching: if there is an exact matching record for the functional attribute in the mapping table, the corresponding privacy classification is directly output, and the classification confidence is calculated based on the source attribute of the record—records originating from manual calibration are assigned high confidence, and records originating from the initial rule configuration are assigned medium confidence; if there are only fuzzy matching records with similar functional attributes in the mapping table or no matching records exist, a privacy classification based on inference from similar records is output and assigned low confidence. When the preset privacy classification model is a neural network classification model, a machine learning-based classifier structure can be adopted. This classifier learns the correlation between functional attribute features and corresponding privacy labels in historical business data, establishing a classification decision boundary from functional attribute features to privacy level labels. The gateway module 30 inputs the feature vectors corresponding to the functional attributes into the neural network classification model. The neural network classification model performs forward inference based on the learned decision boundary, outputs the privacy classification result, and simultaneously calculates the classification confidence corresponding to the classification result. Compared to a mapping table, the neural network classification model can capture deep semantic relationships between functional attributes and has better generalization inference capabilities for new business function types that do not appear in the mapping table but are semantically similar to other known functional attributes.

[0049] Specifically, regardless of whether a mapping table or a neural network classification model is used, the calculation of classification confidence comprehensively considers the following factors: the degree of matching of the functional attribute in the model, the frequency of the functional attribute being manually calibrated in the past and the consistency of the calibration results, and the number of samples in the training dataset where the functional attribute appears. When a functional attribute has an exact matching record or has been verified by historical manual calibration, the model assigns a high classification confidence; when a functional attribute appears for the first time and lacks historical sample support, the model assigns a low classification confidence and actively triggers the subsequent manual calibration process.

[0050] For example, when the preset privacy classification model uses a mapping table, a school's finance staff initiates a request to "inquire about the bank's corporate business handling guide." This functional attribute has an exact match record in the mapping table and is marked as originating from manual calibration. The model outputs a privacy classification of "non-sensitive" with a classification confidence score of 0.98. When a network model is used, for the first "batch query of faculty and staff account status" request, the network model can, based on learned semantic associations, find that this functional attribute is close to the sensitive functional attribute "account information query" in the feature space and outputs a privacy classification of "sensitive." However, due to the lack of historical training samples for this specific functional attribute, the classification confidence score is only 0.65, and manual calibration is still triggered. After administrator calibration and confirmation, if a mapping table is used, the system adds the corrected result to the exact match record in the mapping table and marks it as the source of manual calibration; if a network model is used, the system feeds the corrected result back to the training dataset and triggers online incremental training, updating the model's classification decision boundary for this type of functional attribute. Subsequent similar requests can then obtain high-confidence judgments.

[0051] Step S5: When the privacy classification is greater than or equal to the preset confidence level, the privacy classification is used as the privacy attribute of the service request; It should be noted that the pre-set confidence level refers to a pre-defined classification confidence threshold. When the classification confidence level is greater than or equal to this threshold, it indicates that the pre-set privacy classification model has sufficient reliability for the current classification result and can be directly adopted as the final judgment result without human intervention.

[0052] Step S6: When the classification confidence is less than the preset confidence, the privacy classification is further calibrated to obtain the privacy attributes of the service request, and when the privacy classification is inconsistent with the privacy attributes, the preset privacy classification model is optimized.

[0053] It should be noted that further calibration of privacy classification refers to the mechanism whereby, when the model's classification confidence is insufficient, the dynamic manual calibration module integrated into the gateway is triggered, allowing administrators to manually review and correct low-confidence classification results. Optimizing the preset privacy classification model refers to the mechanism where, when the manual calibration result is inconsistent with the model's original classification, the corrected result is immediately fed back to the model's rule base or training dataset, triggering a self-evolutionary mechanism for online incremental optimization of the model.

[0054] Specifically, when the classification confidence level is lower than the preset confidence level, the gateway module 30 determines that the classification result has a high risk of misjudgment and triggers a dynamic manual calibration process. First, the gateway module 30 pushes the low-confidence classification result and related request details (including the timestamp of the misjudged event, request content, API interface, parameters, and system judgment result, etc.) to the classification log module in the management backend. Administrators can view detailed classification logs in real time through the management backend to understand the complete context of each misjudged event. For misjudged cases that need to be corrected, the administrator selects the correct privacy tag from the candidate business tag list through the intuitive graphical interface provided by the management backend and submits it for review. After the review is approved, the corrected result becomes the privacy attribute of the business request, and the gateway module 30 performs routing forwarding accordingly.

[0055] Furthermore, the system automatically compares the manually calibrated privacy attributes with the original privacy classification output of the preset privacy classification model. When the two are inconsistent, it indicates that there is a deviation in the model's classification decision boundary for that type of functional attribute. The system immediately feeds the correction result back to the business function label mapping library or training dataset of the preset privacy classification model, triggering online incremental training or rule updates of the model to adjust the classification decision boundary for that type and similar types of functional attributes. It is worth noting that the location of the corresponding business request service in the public service module and the local service module also needs to be adjusted at the same time.

[0056] In this implementation, a preset privacy classification model outputs the privacy classification and classification confidence level of functional attributes, providing a quantitative assessment of the reliability of each classification decision. This allows the model to have a clear understanding of the boundaries of its classification capabilities. High-confidence results are directly adopted and automatically routed, ensuring efficient flow of known business function types. Low-confidence results trigger a closed-loop mechanism of "intelligent classification → manual calibration → rule optimization," where administrators manually intervene to correct misclassified cases and immediately feed the correction results back to the model, achieving online dynamic optimization of the classification model. As a result, the system's classification accuracy continuously improves over time, significantly reducing the probability of misclassification. Simultaneously, it can adapt to business changes without system downtime, ensuring the continuous evolution of the classification model and providing reliable support for large-scale data processing.

[0057] As an example, refer to Figure 2The user terminal transmits business requests to the hybrid cloud gateway (gateway module). The hybrid cloud gateway identifies the business function of the request. This identification embeds intelligent audit data review (obtaining the functional attributes of the business request and, based on those attributes, determining its privacy attributes) and manual calibration data correction (further calibration). When the privacy attribute of the business request is sensitive, it is classified as a sensitive data request and transmitted via a dedicated network (pre-set dedicated network) to the enterprise's or organization's local private deployment service (local service module). When the privacy attribute of the business request is non-sensitive, it is classified as a non-sensitive data request and transmitted via the public network to the public cloud service (public service module). This ensures that while enterprises enjoy the elastic computing power of the public cloud, they also safeguard core data security through local private deployment.

[0058] In one feasible implementation, the local service module 20 includes a business intent verification module 21: The business intent verification module 21 is used to parse the business request transmitted by the gateway module, obtain the business scenario and user identity identifier of the business request, determine whether the business scenario and the user identity identifier are consistent, and intercept the business request when the business scenario and the user identity identifier are inconsistent.

[0059] It should be noted that the business intent verification module 21 refers to the security verification unit deployed in the local service module 20, serving as the first intelligent verification barrier for sensitive data processing. The business scenario refers to the actual business operation context corresponding to the business request. The user identity identifier refers to the identity and role label of the user initiating the business request within the enterprise or organization. Determining whether the business scenario and the user identity identifier match means forcibly binding the association between the business scenario and the user identity, verifying whether the current user has the permission to execute the operation corresponding to that business scenario.

[0060] Specifically, after receiving a sensitive business request transmitted via a pre-defined private network by the gateway module 30, the business intent verification module 21 uses a dynamic semantic parsing engine to deconstruct the request content in real time, extracting business scenario information and user identity identifiers from the request message. The business intent verification module 21 maintains a pre-defined business rule base, which records the binding relationship between various business scenarios and authorized user identities. Administrators can customize the business rule base based on the actual needs of the enterprise or organization, such as setting policies like "financial settlement is limited to finance department personnel" and "personnel files are limited to human resources department access." The business intent verification module 21 performs association matching and verification between the parsed business scenario and the user identity identifier: when they match, the business request is allowed to proceed to subsequent processing; when they do not match, the request is deemed to have an unauthorized operation risk, and the business request is immediately intercepted, eliminating the risk of misoperation and illegal operation from the source, ensuring that sensitive data processing is limited to compliant business scope.

[0061] For example, a finance department staff member of a school initiates a payroll disbursement request through a bank's corporate online banking. Gateway module 30, after identifying it as a sensitive request, transmits it to local service module 20 via a dedicated network. Business intent verification module 21 parses the request and obtains the business scenario as "payroll disbursement" and the user identity as "finance department staff member." It queries the business rule base to confirm that the "payroll disbursement" business is already bound to the "finance department staff member" identity; since the two match, the request is allowed. When a staff member from the school's academic affairs office also initiates a payroll disbursement request, business intent verification module 21 parses the request and obtains the same business scenario as "payroll disbursement" and user identity as "academic affairs staff member." This does not match the rule base's policy that "payroll disbursement is limited to finance department staff," and is therefore deemed an unauthorized operation. The request is intercepted, and an alarm log is recorded, effectively mitigating the risks of accidental operations and data leakage.

[0062] In this implementation, a business intent verification module is deployed in the local service module as the first intelligent verification barrier for sensitive data processing. This module enforces identity and scenario binding verification before sensitive information enters the business processing flow. The business intent verification module uses a dynamic semantic parsing engine to deconstruct request content in real time, accurately identifying the business scenario and user identity, and then matching them with a preset business rule base. If the business scenario and user identity do not match, the request is immediately blocked. This mechanism eliminates the risk of unauthorized and erroneous operations at the source, ensuring that sensitive data processing is limited to compliant business operations and effectively avoiding data leakage and unauthorized operations. Simultaneously, administrators can customize the business rule base based on the actual needs of the enterprise or organization, flexibly adapting to the permission management strategies of different organizations, thereby improving the system's security control capabilities and business adaptability.

[0063] In one feasible implementation, the local service module 20 includes an identity authentication module, used to perform dual authentication on the service request based on a preset network permission whitelist. The network permission whitelist includes a list of authorized terminal IP addresses and a unique device identifier. When both the source IP address and the source device identifier of the service request match the network permission whitelist, the service request is allowed; when either the source IP address or the source device identifier does not match, the service request is rejected. It should be noted that the network permission whitelist refers to a security policy list pre-configured by an enterprise or organization that records the IP address range and device identifier of all authorized access terminals. The device identifier refers to a hardware or software identifier used to uniquely identify the terminal device initiating the service request, such as a device serial number, MAC address, or security chip identifier. Dual authentication means simultaneously verifying the identity information of both the IP address and the device identifier from which the request originates; only if both match can the request pass. Specifically, the identity authentication module is deployed at the entry point of the local service module, performing mandatory identity verification before sensitive service requests enter the service processing stage. When the gateway module transmits sensitive business requests to the local service module via a pre-defined private network, the authentication module extracts the source IP address and unique device identifier from the request and compares them one by one with a pre-defined network permission whitelist. Only when both dimensions match is the requester considered an authorized terminal and allowed to proceed to subsequent processing; if either dimension does not match, the request is directly rejected and an alarm log is recorded. For example, a school's finance department only allows specific office computers in the finance office to access the payroll function. The administrator configures the fixed IP address and device MAC address of this computer in the network permission whitelist. When a finance staff member initiates a request from this computer, the source IP address and device identifier match, and the authentication module allows the request; when the same staff member attempts to initiate a request using a personal mobile phone, the device identifier does not match, and the request is rejected, effectively preventing unauthorized terminals from accessing the local service module.

[0064] In one feasible implementation, the local service module 20 includes an encrypted database module 22: The encrypted database module 22 includes a key storage module 221 and a sensitive information storage module 222, wherein the sensitive information storage module and the key storage module are physically isolated. It should be noted that the encrypted database module 22 refers to the data security storage unit deployed within the local service module 20. As the core of sensitive data protection, it employs a two-layer encryption strategy. The sensitive information storage module refers to the conventional storage medium used to store encrypted sensitive data. The key storage module refers to the independent secure storage medium used to store decryption keys, such as a hardware security module. Physical isolation means that both are deployed in physically independent storage devices, with the key and data separated and without a direct physical connection. Even if an attacker obtains the data storage medium, they cannot simultaneously obtain the key, fundamentally preventing the risk of data and key being stolen together.

[0065] The key storage module 221 is used to store the key for each business scenario. It should be noted that the scenario key refers to the encryption key that corresponds uniquely to each business scenario. Different business scenarios use different keys for data encryption to achieve encryption isolation between business scenarios. The key storage module centrally stores the scenario keys in an independent hardware security module, providing key query and retrieval services only through an internal security interface, and is not exposed to the public network or external systems.

[0066] The sensitive information storage module 222 is used to store the sensitive information, wherein the sensitive information is encrypted by the scenario key.

[0067] It should be noted that the encryption of sensitive information by scenario-specific keys means that each sensitive data record is encrypted using the corresponding scenario key based on its business scenario when it is written. The ciphertext is then stored with a business scenario identifier attached, forming a logical association between the data and the key. Decryption requires both the ciphertext data and the corresponding scenario key; neither can be missing. This ensures that even if the data is illegally obtained, it cannot be decrypted without the key, significantly improving the data protection level and meeting financial-grade security standards.

[0068] Specifically, the write process of the encrypted database module is as follows: When sensitive information needs to be stored, the business scenario to which the sensitive information belongs is first identified. The scenario key corresponding to the business scenario is obtained from the key storage module. The sensitive information is then encrypted using this scenario key. The encrypted ciphertext data is appended with a business scenario identifier and stored in the sensitive information storage module. The read process is as follows: When sensitive information needs to be read, the business scenario identifier of the data is obtained. The corresponding scenario key is obtained from the key storage module. After decryption, the original sensitive information is restored. The business scenario identifier establishes a logical association between the data and the key, and also allows for tracing the source of the operation, facilitating security auditing and data traceability.

[0069] In this implementation, the encrypted database module employs a two-layer, hierarchical encryption strategy that physically separates the key from the data. The sensitive information storage module and the key storage module are deployed on independent physical media, physically preventing the risk of data and keys being stolen together. Each business scenario is configured with an independent scenario key, and each piece of sensitive data is encrypted using the corresponding scenario key and appended with a business scenario identifier, forming a logical association between data and key, facilitating decryption authorization and operation traceability. This design ensures that even if data is illegally obtained, it cannot be decrypted without the key, significantly improving the data protection level and meeting financial-grade security standards.

[0070] In one feasible implementation, the sensitive information storage module 222 is further used to store the business scenario identifiers of each of the sensitive information; It should be noted that the business scenario identifier refers to the tag information attached to each sensitive data record to identify the business scenario to which the data belongs, such as "payroll processing", "employee file", "project reward application", etc. By storing the business scenario identifier together with the encrypted sensitive information, a logical association between data and key is established, providing an index for locating the corresponding scenario key during subsequent decryption, while also tracing the business source of the data, facilitating security auditing and operational traceability.

[0071] Specifically, during the sensitive information writing phase, the encrypted database module 22 encrypts the sensitive information and stores the encrypted data along with the business scenario identifier to which the data belongs in the sensitive information storage module 221. During the reading phase, the system can quickly locate the data record based on the business scenario identifier and retrieve the scenario key corresponding to the identifier from the key storage module 222 for decryption.

[0072] The local service module 20 also includes a sensitive data processing module 23: Sensitive data processing module 23 is used to obtain sensitive information and business scenario identifier from the sensitive information storage module according to the business request, obtain scenario key from the key storage module according to the business scenario identifier, and decrypt the sensitive information using the scenario key to obtain decrypted sensitive information; It should be noted that the sensitive data processing module 23 refers to the data processing unit deployed in the local service module 20. It is responsible for responding to sensitive business requests that have passed the verification by the business intent verification module 21, and performing sensitive information reading, decryption, and business processing operations. Decrypting sensitive information refers to restoring the original plaintext data after decrypting the ciphertext sensitive information using the scenario key.

[0073] Specifically, when the sensitive data processing module 23 receives a business request approved by the business intent verification module 21, it first parses the request content to determine the sensitive data record to be read. Then, the sensitive data processing module 23 retrieves the corresponding encrypted data and the attached business scenario identifier from the sensitive information storage module. Based on the business scenario identifier, the sensitive data processing module 23 initiates a key query request to the key storage module through an internal security interface to obtain the scenario key corresponding to the identifier. Finally, the sensitive data processing module 23 uses the scenario key to decrypt the encrypted data, restoring the decrypted sensitive information for subsequent business logic processing. The entire decryption process is completed within the secure computing environment of the local service module 20, and the decrypted plaintext data does not leave the local controllable domain.

[0074] The data transmission module 24 is used to transmit the decrypted sensitive information through the preset private network.

[0075] It should be noted that the data transmission module 24 refers to the secure transmission unit deployed in the local service module 20, which is responsible for transmitting decrypted sensitive information encrypted via a pre-established private network to the party initiating the business request or the designated target system. The pre-established private network refers to a secure dedicated network channel that is pre-established and physically or logically isolated from the public network to ensure the confidentiality and integrity of the decrypted sensitive information during transmission.

[0076] Specifically, after completing the decryption operation, the sensitive data processing module 23 hands over the decrypted sensitive information to the data transmission module 24 for return transmission. The data transmission module 24 performs transport layer encryption on the decrypted sensitive information and securely transmits the encrypted data to the requester via a pre-set private network. Through the physical or logical isolation characteristics of the pre-set private network, combined with the transmission encryption mechanism, it ensures that sensitive information is not eavesdropped on or tampered with during network transmission, achieving secure end-to-end data delivery.

[0077] For example, a school's finance staff initiates a request to query payroll details via a bank's corporate online banking. After the gateway module 30 determines the request to be sensitive and the business intent verification module 21 verifies it, the sensitive data processing module 23 retrieves the encrypted data and the business scenario identifier "payroll disbursement" from the sensitive information storage module based on the request content, and obtains the "payroll disbursement scenario key" from the key storage module. After decryption, the plaintext data of the staff's payroll details is obtained. The data transmission module 24 securely transmits the decrypted payroll details to the finance staff's client via a dedicated financial network. Throughout the process, the plaintext data remains within the local secure computing environment and is protected by the pre-set dedicated network.

[0078] In this implementation, a business scenario identifier is stored in a sensitive information storage module, establishing a logical association between data and keys. The sensitive data processing module retrieves the ciphertext and business scenario identifier from the storage module based on the business request, and then retrieves the corresponding scenario key from the key storage module based on the identifier, performing decryption locally. The data transmission module transmits the decrypted sensitive information back via a pre-set private network. This constructs a complete data security processing chain: "physical isolation of data keys, logical association of scenario identifiers, local decryption, and secure transmission via a private network." This ensures that the plaintext data of sensitive information does not leave the local controllable domain and is protected by encryption via a pre-set private network during transmission, achieving end-to-end secure data delivery and further enhancing the data protection level.

[0079] In one feasible implementation, the local service module 20 includes a business scenario optimization service module: The business scenario optimization service module is used to analyze changes in business models in real time, identify off-peak periods or batch operation periods of business requests, and automatically trigger a resource elastic contraction mechanism based on the analysis results to dynamically adjust the server resource allocation of the local service module.

[0080] It should be noted that the business scenario optimization service module refers to the performance and cost optimization unit deployed in the local service module 20. The resource elastic shrinkage mechanism refers to an automated scheduling mechanism that dynamically adjusts the server's computing resource usage based on business load.

[0081] Specifically, the business scenario optimization service module continuously collects business request traffic data to identify the current business load status. When a low-peak period is identified, idle computing resources are automatically released for background tasks; when a peak period or batch operation period arrives, resources are rescheduled to the core business processing link to ensure that response efficiency is not affected during peak periods.

[0082] This implementation uses a business scenario optimization service module to analyze changes in business models in real time, automatically triggering a resource elastic contraction mechanism to dynamically adjust server resource allocation. This releases idle computing power during off-peak hours for other tasks, while rescheduling during peak hours ensures the efficiency of core business processing. This design significantly improves the concurrency support capabilities of standard servers and reduces single-point maintenance costs caused by continuous full-capacity operation.

[0083] As an example, see Figure 3The local service module adopts a lightweight three-module architecture consisting of a business intent verification service (business scenario optimization service module), a dynamic encrypted database (encrypted database module), and a business scenario optimization service (business scenario optimization service module). The cloud hybrid cloud gateway sends business requests to the local system via a dedicated line. The business intent verification service first performs security verification of the business request, and the verified data is stored in the dynamic encrypted database. The business scenario optimization service outputs scenario adaptation optimization strategies and synchronizes them to the dynamic encrypted database. All three core modules can be deployed on general standard servers without dedicated hardware, reducing deployment costs by 60% compared to traditional fully private solutions. Modules communicate internally via a local bus, eliminating cross-network latency and external dependencies, reducing operational complexity by 50%. The entire architecture achieves full-process local verification, encrypted storage, and scenario-based optimization of sensitive data, balancing data compliance and security, business performance, and deployment and maintenance costs. It can be adapted to large-scale deployments of organizations with millions of data volumes, meeting the compliant, economical, and efficient digital transformation needs of various entities.

[0084] In one feasible implementation, the public service module 10 includes sharding modules 11 and routing modules 12: Each sharding module 11 is isolated from each other, and each sharding module is used to independently store and process non-sensitive information of the target tenant; It should be noted that a sharding module refers to an independent data storage and processing unit within a public service module, divided according to tenants. Each sharding module corresponds to one or more tenants. Data isolation means that the data between sharding modules is physically or logically completely independent; one sharding module cannot access the data of another sharding module. A target tenant refers to an enterprise or organization uniquely identified by a tenant identifier that uses the services of this system.

[0085] Understandably, each sharding module is strictly isolated through database-level access control policies, and the application layer also provides double protection through tenant context verification mechanisms. This ensures that even if a sharding module suffers an SQL injection attack or data corruption, the attack surface or failure surface is strictly limited to within that shard, and the data of other tenants' sharding modules remains completely unaffected.

[0086] In one feasible implementation, the public service module 10 is further configured to: respond to a new tenant access instruction, create a sharding module for the new tenant, and register the sharding module of the new tenant to the routing table of the sharding routing module.

[0087] Specifically, when a new tenant first accesses the hybrid-deployed information management system, the system automatically executes the sharding initialization process: First, an independent sharding module instance is created for the tenant in the resource pool of the public service module, a dedicated database schema and storage space are allocated, and a unique sharding identifier is generated for the sharding module; then, a bidirectional mapping relationship is established between the sharding identifier and the tenant identifier and registered in the routing table of the sharding routing module. During system operation, the sharding module only receives and processes non-sensitive information business requests from the corresponding tenant, and all data addition, deletion, modification, and query operations are completed within the data boundary of the sharding module.

[0088] It is understandable that the new tenant access method in this embodiment can ensure business continuity without downtime or data migration, while also increasing the data uniformity rate to over 95%, eliminating the bottleneck of full database scanning, and providing elastic support for high-concurrency scenarios.

[0089] The sharding routing module 12 is used to parse the tenant identifier in the service request transmitted by the gateway module and dynamically map the service request to the target sharding module using a preset routing strategy.

[0090] It should be noted that the tenant identifier refers to a field carried in the business request that uniquely identifies the tenant to which the request belongs. The preset routing strategy refers to a pre-configured mapping algorithm used to locate the request to the corresponding sharding module based on the tenant identifier, such as an adaptive hash routing strategy.

[0091] Specifically, after receiving a non-sensitive business request forwarded by the gateway module, the sharding routing module deeply analyzes the tenant identifier in the request, quickly calculates the location of the target sharding module corresponding to the tenant through a preset routing strategy, and accurately forwards the request to the sharding module for processing, avoiding the performance overhead caused by full database scanning.

[0092] For example, see Figure 4 The sharding routing engine (sharding routing module) is the scheduling core of the public service module. After receiving business requests carrying shard IDs (tenant identifiers), it can accurately locate shards based on adaptive hash routing and supports online expansion, improving the data uniformity distribution rate to over 95% and eliminating the bottleneck of full database scanning. The sharding routing engine distributes requests to the corresponding independent index optimization modules (each shard module) based on the shard ID. Each independent index optimization module builds a dedicated composite index for its own shard tenant business characteristics. Each shard index system runs independently without cross-shard collaboration overhead, avoiding additional performance loss. After processing by each module, the query results are uniformly summarized and output. This architecture not only achieves balanced sharding traffic and elastic expansion, but also significantly reduces query IO overhead and business latency through shard-specific customized indexes, taking into account both high concurrency processing capabilities and tenant personalized query needs, and achieving simultaneous optimization of database performance and deployment costs.

[0093] In this implementation, the public service module achieves data isolation between tenants through each sharding module, constructing a tenant-level security boundary to ensure that a single shard failure does not affect other tenants. The sharding routing module accurately maps requests to the target shard based on the tenant identifier, replacing full database scans with hash routing to eliminate query performance bottlenecks; it also enables elastic scaling. This design significantly improves data security isolation capabilities and query efficiency in multi-tenant scenarios, achieving dual optimization of performance and cost.

[0094] As an example, refer to Figure 5 The architecture uses a hybrid cloud gateway (gateway module) as the unified access node for user terminal transmission of service requests. The gateway connects to the local private deployment layer (local service module) and SaaS cloud service layer (public service module) of multiple enterprises and institutions through dedicated encrypted leased lines (pre-set private networks). Each institution's local layer deploys a private data information module and is equipped with a local encrypted database (encrypted database module) to retain sensitive data such as ID cards and financial information to meet local compliance requirements. The SaaS cloud service layer sets up non-sensitive information modules and uses a tenant-level sharding routing engine (sharding routing module) to allocate independent data shards (each sharding module) to different institutions and carries a dedicated independent index optimization mechanism. The architecture relies on leased lines to complete the data transmission between the cloud and local sides, avoiding the man-in-the-middle attack risk brought about by direct public network connection. The system leverages universal standard servers for all local business processing modules, reducing deployment costs by 60% compared to traditional fully private solutions. Modules interact via a local bus, minimizing operational overhead. The cloud-based sharding architecture uses adaptive hash sharding based on institution IDs, with each shard independently executing customized index optimizations. This reduces the response time for queries on millions of data points to within 5 seconds. The overall architecture integrates four innovative mechanisms: local private storage, dedicated encrypted transmission, modular hybrid deployment, and tenant-sharded databases. It simultaneously addresses four major technical pain points in existing systems: data compliance, deployment costs, transmission security, and big data query performance. While meeting financial-grade data security standards, it achieves a comprehensive balance between security, cost, network transmission efficiency, and big data processing performance, adapting to the needs of large-scale digital management implementation for multiple enterprises and institutions.

[0095] In a feasible implementation, each segmentation module 11 is further configured to perform steps A1-A2: Step A1: Analyze the historical query logs and real-time access patterns of the target tenant, identify the unique query hotspots of the target tenant, and construct a composite index structure adapted to the business characteristics of the target tenant; It should be noted that historical query logs refer to all query request records generated by this tenant in its past usage. Real-time access patterns refer to the regular characteristics of this tenant's current query requests in terms of field combinations, filtering conditions, etc. Query hotspots refer to the frequently used query field combinations in this tenant's business, such as one tenant frequently querying announcements by time range, and another tenant frequently filtering employee information by department. Composite index structure refers to a customized indexing scheme that optimizes multiple high-frequency fields into composite index keys based on this tenant's query hotspots.

[0096] Specifically, each sharding module continuously collects historical query logs from its corresponding tenant and, combined with real-time access patterns, identifies unique high-frequency query field combinations for that tenant through statistical analysis. Based on the identification results, a composite index structure adapted to the tenant's business characteristics is automatically constructed, optimizing core business fields into efficient index keys. The index systems of different sharding modules operate completely independently and are not dependent on each other. Each module is customized and optimized according to the business characteristics of the tenant it serves, avoiding the cross-tenant adaptability issues caused by a "one-size-fits-all" approach to general indexes. When a tenant's business model changes, the sharding module continuously monitors and automatically adjusts its indexing strategy to ensure that the index structure always remains consistent with the tenant's actual business needs.

[0097] Step A2: When a service request mapped by the sharding routing module is received, the data requested by the service request is located according to the composite index structure.

[0098] It should be noted that the mapped business requests refer to query requests that are deemed non-sensitive by the gateway module and routed to the target shard module by the sharding routing module. Locating data based on the composite index structure means that the database query optimizer automatically matches the constructed composite index based on the field combinations in the query conditions, quickly locating the target data through the index key value and avoiding a full table scan.

[0099] Specifically, after receiving a business request, the sharding module calculates the matching degree between the query conditions and the existing composite index, selects the optimal index as the execution path, and quickly locates the target data page through the index key value, reducing the number of data retrieval I / O operations from O(n) of a full table scan to O(log n) of an index lookup. When the query conditions cannot match the existing composite index, execution falls back to the general index path, and the query pattern is recorded in the log for reference in the next index adjustment cycle.

[0100] In this implementation, each sharding module automatically identifies tenant-specific query hotspots by analyzing tenant historical query logs and real-time access patterns, constructing a dedicated composite index structure to overcome the limitations of a generic index's "one-size-fits-all" approach. The index systems of different sharding modules operate independently, eliminating cross-shard collaboration overhead. When a business request arrives, the composite index quickly locates the data, reducing query response time from seconds to milliseconds. Simultaneously, it continuously monitors changes in business models and automatically adjusts indexing strategies, achieving dynamic synchronization between the index and business needs, significantly improving query efficiency in multi-tenant heterogeneous business scenarios.

[0101] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the hybrid deployment information management system of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0102] This application also provides a hybrid deployment information management method, applied to an information management system, the hybrid deployment information management method comprising: In response to a business request, the business request is parsed, the business scenario of the business request is identified, the functional attributes of the business request are obtained, and the privacy attributes of the business request are obtained based on the functional attributes. When the privacy attribute is sensitive, the business request is transmitted to the local service module of the information management system through a preset private network. The local service module is used to store and process various sensitive information. When the privacy attribute is non-sensitive, the business request is transmitted over the public network to the public service module of the information management system. The public service module is used to store and process various non-sensitive information.

[0103] The hybrid deployment information management method provided in this application, applied to the hybrid deployment information management system in the above embodiments, can solve the technical problem that existing system deployment models cannot simultaneously address data security, compliance requirements, and low-cost operation and maintenance, resulting in an inability to comprehensively balance security, cost, and operation and maintenance. Compared with the prior art, the beneficial effects of the hybrid deployment information management method provided in this application are the same as those of the hybrid deployment information management system provided in the above embodiments, and other technical features in the hybrid deployment information management method are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0104] This application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the hybrid deployment information management method in the above embodiments.

[0105] The following is for reference. Figure 6 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of this application. The electronic devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0106] like Figure 6 As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. The communication device 1009 allows the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although the diagrams show electronic devices with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0107] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0108] The electronic device provided in this application, employing the hybrid deployment information management method described in the above embodiments, can solve the technical problem that existing system deployment models cannot simultaneously address data security, compliance requirements, and low-cost operation and maintenance, resulting in an inability to comprehensively balance security, cost, and operation and maintenance. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the hybrid deployment information management method provided in the above embodiments, and other technical features of this electronic device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0109] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0110] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0111] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A hybrid deployment information management system, characterized in that, The hybrid deployment information management system includes: The public service module is used to store and process various non-sensitive information; The local service module is used to store and process various sensitive information; The gateway module is used to respond to business requests, parse the business requests, identify the business scenarios of the business requests, obtain the functional attributes of the business requests, and obtain the privacy attributes of the business requests based on the functional attributes. When the privacy attribute is sensitive, the business request is transmitted to the local service module through a preset private network. When the privacy attribute is non-sensitive, the business request is transmitted to the public service module through the public network.

2. The hybrid deployment information management system as described in claim 1, characterized in that, The gateway module is also used for: Extract the interface name, request parameter fields, and data flow direction characteristics of the business request; When the interface name can identify the business scenario of the business request, the functional attributes of the business request are identified by the interface name. When the interface name cannot identify the business scenario of the business request, the functional attributes of the business request are identified by combining at least one of the request parameter fields and the data flow direction features.

3. The hybrid deployment information management system as described in claim 1, characterized in that, The gateway module is also used for: By using a preset privacy classification model, the privacy classification and classification confidence of the functional attributes are obtained; When the privacy classification is greater than or equal to the preset confidence level, the privacy classification is used as the privacy attribute of the service request; When the classification confidence level is less than the preset confidence level, the privacy classification is further calibrated to obtain the privacy attributes of the business request, and when the privacy classification is inconsistent with the privacy attributes, the preset privacy classification model is optimized.

4. The hybrid deployment information management system as described in claim 1, characterized in that, The local service module includes: The business intent verification module is used to parse the business request transmitted by the gateway module, obtain the business scenario and user identity identifier of the business request, determine whether the business scenario and the user identity identifier are consistent, and intercept the business request when the business scenario and the user identity identifier are inconsistent.

5. The hybrid deployment information management system as described in claim 1, characterized in that, The local service module includes: The encrypted database module includes a sensitive information storage module and a key storage module, wherein the sensitive information storage module and the key storage module are physically isolated. The key storage module is used to store the key for each business scenario. The sensitive information storage module is used to store the sensitive information, wherein the sensitive information is encrypted by the scenario key.

6. The hybrid deployment information management system as described in claim 5, characterized in that, The sensitive information storage module is also used to store the business scenario identifiers of each of the sensitive information; The local service module also includes: The sensitive data processing module is used to obtain sensitive information and a business scenario identifier from the sensitive information storage module according to the business request, obtain a scenario key from the key storage module according to the business scenario identifier, and decrypt the sensitive information using the scenario key to obtain decrypted sensitive information. The data transmission module is used to transmit the decrypted sensitive information through the preset private network.

7. The hybrid deployment information management system as described in claim 1, characterized in that, The public service module includes: Each sharding module is isolated from the others, and each sharding module is used independently to store and process non-sensitive information of the target tenant. The sharding routing module is used to parse the tenant identifier in the service request transmitted by the gateway module and dynamically map the service request to the target sharding module using a preset routing strategy.

8. The hybrid deployment information management system as described in claim 7, characterized in that, Each of the segmentation modules is also used for: Analyze the historical query logs and real-time access patterns of the target tenant, identify the unique query hotspots of the target tenant, and construct a composite index structure adapted to the business characteristics of the target tenant; When a service request mapped by the sharding routing module is received, the data requested by the service request is located according to the composite index structure.

9. A hybrid deployment information management method, characterized in that, The hybrid deployment information management method, applied to an information management system, includes: In response to a business request, the business request is parsed, the business scenario of the business request is identified, the functional attributes of the business request are obtained, and the privacy attributes of the business request are obtained based on the functional attributes. When the privacy attribute is sensitive, the business request is transmitted to the local service module of the information management system through a preset private network. The local service module is used to store and process various sensitive information. When the privacy attribute is non-sensitive, the business request is transmitted over the public network to the public service module of the information management system. The public service module is used to store and process various non-sensitive information.

10. An electronic device, a computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the hybrid deployment method for the information management system as described in claim 9.

Images