Data desensitization processing and access methods, devices, equipment and media

Abstract

The present invention relates to the fields of data security technology and financial technology, and discloses a data desensitization processing and access method, which comprises deploying a data query service in a production data processing platform, receiving a request and returning desensitized data; applying predefined tag annotations in a development and testing platform, configuring a dynamic proxy mechanism; intercepting a data access interface call, constructing and sending a hypertext transfer protocol request; and executing a query and returning desensitized data after the production data processing platform receives the request, and the test environment receives and processes the desensitized data. The present invention simplifies the process of the test environment accessing the production environment data through a dynamic proxy mechanism, realizes automated data calling and desensitization processing, and improves the real-time and efficiency of data acquisition. It protects data privacy, meets the needs of rapid iterative development, and significantly improves the work efficiency of development and testing.

Description

Technical Field

[0001] The present invention relates to the fields of data security technology and financial technology, and in particular to a data desensitization processing and access method, device, equipment and storage medium. Background Art

[0002] In the financial sector, agile system development and testing are crucial for quickly responding to market demands and improving competitiveness. Production environments in financial systems typically store large amounts of sensitive data, including user personal information, transaction data, and financial records. To ensure data security, production data is often masked in development and testing environments. This allows developers and testers to use secure, masked data when debugging and verifying system functionality, preventing sensitive data leaks.

[0003] However, existing technologies present numerous difficulties in obtaining and desensitizing production data for testing environments. First, the traditional production environment launch process requires multiple complex approval processes and stringent compliance requirements, making it difficult to directly use production data for testing. This lengthy and cumbersome review process conflicts with the agile development model of current projects and cannot meet the needs of rapid iteration and changing requirements. Development teams at financial institutions often face the challenge of lengthy system rollout times, making it difficult to flexibly respond to market changes.

[0004] Furthermore, current development and testing processes often use proxy classes to simulate production data calls within the test environment. However, as system scale and business complexity increase, a large amount of proxy code needs to be written and maintained in the test environment to call production data. This excessive accumulation of proxy classes not only increases the difficulty of code maintenance but can also lead to system inefficiencies, code redundancy, and other issues, further reducing the flexibility and iteration efficiency of development and testing.

[0005] At the same time, existing production data desensitization methods often lack real-time performance and flexibility. Most desensitization operations require batch data export, making it difficult to meet the real-time data requirements of the testing process. Furthermore, existing desensitization methods cannot fully guarantee the security of sensitive information throughout the development and testing process, increasing the risk of data leakage. Summary of the Invention

[0006] The main purpose of the present invention is to provide a data desensitization processing and access method, device, equipment and storage medium, aiming to solve the technical problem in the prior art that the test environment cannot safely and efficiently access and process desensitized data in the production environment in an automated manner.

[0007] To achieve the above objectives, the present invention provides a data desensitization processing and access method, comprising:

[0008] Deploy a data query service in the production data processing platform, wherein the data query service is used to receive requests based on the Hypertext Transfer Protocol and return query results after desensitization processing;

[0009] In the development and testing platform, apply predefined marker annotations to the data access interfaces that require proxies;

[0010] During the service container startup process of the development and testing platform, a post-processor is registered, and a dynamic proxy mechanism in the development and testing platform is configured through the post-processor;

[0011] Intercepting calls to data access interfaces annotated with predefined markers through the dynamic proxy mechanism;

[0012] Constructing a request based on the Hypertext Transfer Protocol based on the parameters passed when calling the data access interface with the predefined markup annotation, and sending the request to the data query service;

[0013] The data query service performs a data query operation according to the request and obtains query result data;

[0014] The data query service performs desensitization processing on the sensitive data in the query result data to obtain desensitized result data;

[0015] Returning the desensitization result data to the development and testing platform through a response based on the Hypertext Transfer Protocol;

[0016] The dynamic proxy mechanism in the development and testing platform receives the desensitized result data and passes the desensitized result data to the caller of the data access interface for business logic processing.

[0017] Furthermore, to achieve the above-mentioned purpose, the present invention provides a data desensitization processing and access device, comprising:

[0018] A data query service module is used to deploy a data query service in the production data processing platform. The data query service is used to receive requests based on the Hypertext Transfer Protocol and return query results after desensitization processing;

[0019] The data access interface module is used to apply predefined marker annotations to the data access interfaces that need to be proxied in the development and testing platform;

[0020] A post-processor module is used to register a post-processor during the startup of the service container of the development and testing platform, and configure the dynamic proxy mechanism in the development and testing platform through the post-processor;

[0021] A dynamic proxy module, configured to intercept calls to data access interfaces annotated with predefined markers through the dynamic proxy mechanism;

[0022] A request building module, configured to build a request based on the Hypertext Transfer Protocol based on the parameters passed when calling the data access interface with the predefined markup annotation, and send the request to the data query service;

[0023] A data query module, configured for the data query service to execute a data query operation according to the request and obtain query result data;

[0024] A data desensitization module is used for the data query service to perform desensitization processing on sensitive data in the query result data to obtain desensitized result data;

[0025] A response generation and transmission module is used to return the desensitization result data to the development and testing platform through a response based on the Hypertext Transfer Protocol;

[0026] The result processing module is used to develop a dynamic proxy mechanism in the test platform to receive the desensitized result data and pass the desensitized result data to the caller of the data access interface for business logic processing.

[0027] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and a data desensitization processing and access program stored in the memory and runnable on the processor. When the data desensitization processing and access program is executed by the processor, the steps of the data desensitization processing and access method described above are implemented.

[0028] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which a data desensitizing processing and access program is stored. When the data desensitizing processing and access program is executed by a processor, the steps of the data desensitizing processing and access method described above are implemented.

[0029] Beneficial effects: The present invention relates to the fields of data security technology and financial technology, and discloses a data desensitization processing and access method, which deploys a data query service in a production data processing platform, receives requests and returns desensitized data; applies predefined tag annotations in a development and testing platform, configures a dynamic proxy mechanism; intercepts data access interface calls, constructs and sends Hypertext Transfer Protocol requests; the production data processing platform executes queries and returns desensitized data after receiving the request, and the test environment receives and processes the desensitized data. The present invention simplifies the process of the test environment accessing the production environment data through a dynamic proxy mechanism, realizes automated data calling and desensitization processing, and improves the real-time and efficiency of data acquisition. It protects data privacy, meets the needs of rapid iterative development, and significantly improves the work efficiency of development and testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0031] Figure 1 A schematic diagram of an application environment of a data desensitization processing and access method according to an embodiment of the present invention;

[0032] Figure 2 This is a flow chart of an embodiment of a data desensitization processing and access method of the present invention;

[0033] Figure 3 This is a functional module diagram of a preferred embodiment of the data desensitization processing and access device of the present invention;

[0034] Figure 4 A schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0035] Figure 5 FIG. 2 is another structural diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0036] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0037] The data desensitization processing and access method provided by the embodiment of the present invention can be applied in Figure 1In an application environment, the user end communicates with the server end through a network. The server end can deploy a data query service in the production data processing platform through the user end, receive requests and return desensitized data; apply predefined tag annotations in the development and testing platform, configure a dynamic proxy mechanism; intercept data access interface calls, build and send Hypertext Transfer Protocol requests; after receiving the request, the production data processing platform executes the query and returns desensitized data, and the test environment receives and processes the desensitized data. The present invention simplifies the process of the test environment accessing the production environment data through the dynamic proxy mechanism, realizes automated data calling and desensitizing processing, and improves the real-time and efficiency of data acquisition. It guarantees data privacy, meets the needs of rapid iterative development, and significantly improves the work efficiency of development and testing. Among them, the user end can be but is not limited to various personal computers, laptops, smart phones, tablet computers and portable wearable devices. The server end can be implemented with an independent server or a server cluster consisting of multiple servers. The present invention is described in detail below through specific embodiments.

[0038] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of the data desensitization processing and access method provided by the present invention. It should be noted that although a logical order is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than here.

[0039] like Figure 2 As shown, the data desensitization processing and access method proposed by the present invention includes the following steps:

[0040] S10, deploying a data query service in the production data processing platform, wherein the data query service is used to receive requests based on the Hypertext Transfer Protocol and return query results after desensitization processing;

[0041] In this embodiment, the production data processing platform is part of the core business system deployed in enterprises such as financial institutions, specifically processing data requests from other environments (such as test environments). The data query service is a module on this platform responsible for obtaining business data from the database based on query conditions. This service needs to have high concurrency processing capabilities, be able to quickly respond to a large number of requests, and be able to access data sources in the production environment. It also needs to cooperate with the desensitization processing module to ensure that sensitive data is desensitized before being returned.

[0042] Data query services can be developed using mainstream web frameworks, such as Java's Spring Framework. Typical implementations include: using the Spring Boot framework to quickly build the service; exposing the data query interface through a RESTful API; using MyBatis or JPA for database operations to query data in the production database; and, after the service is started, listening on a specific port for incoming query requests. The service also requires configuring a connection pool (such as HikariCP) to handle high concurrency and ensure data query performance.

[0043] The data query service must support HTTP-based communication. This means that external systems (such as the test environment) can send query requests via HTTP. HTTP is the most commonly used application layer protocol on the internet, allowing clients to communicate with servers using request methods such as GET and POST. In this technical architecture, the test environment sends query requests via HTTP, and the production data processing platform receives and processes these requests via HTTP.

[0044] Use Spring MVC's @RequestMapping annotation to configure the service interface to receive HTTP requests. Requests can be either GET or POST, depending on the data type and complexity of the request. Parse the HTTP request header, query parameters, and data in the request body. When processing HTTP requests, use the HttpServletRequest object to retrieve request details and extract query conditions. The service needs to support authentication and authorization (such as through JWT tokens or OAuth) to ensure that only authorized requests can query data. When the service responds, it constructs an HTTP response object and returns data in JSON or XML format based on the query results.

[0045] After the production data processing platform obtains raw data from the database, it must desensitize sensitive information (such as personal identity information and financial data). The purpose of desensitization is to protect user privacy and prevent the leakage of sensitive information when the data is transmitted to the test environment. Desensitization methods can include data masking (such as partial character replacement), encryption, or obfuscation.

[0046] Implement a desensitization module, and you can select different desensitization methods (such as regular expression matching, data masking algorithm, etc.) through the strategy mode. This module is responsible for processing sensitive fields (such as ID number, bank card number). After obtaining the query results through ORM frameworks such as MyBatis or JPA, the service will process the sensitive fields in the data; the processed data is returned in JSON or XML format, and the Spring framework supports automatic serialization of Java objects into JSON responses; the service returns the desensitized data as a response body to the test environment via HTTP, and usually uses the ResponseEntity object to set the HTTP status code, response header, and response body.

[0047] Example: In financial institutions, production data often contains sensitive data such as customer personal information and transaction records. To protect data privacy, developers in test environments cannot directly access this data. By deploying a data query service in the production data processing platform and receiving HTTP requests from the test environment, desensitized data can be securely transferred to the test environment. For example, when developing new risk control models, the financial institution's testing team can use this query service to access desensitized historical transaction data in real time without worrying about leaking sensitive customer information. This not only improves development and testing efficiency but also ensures data security.

[0048] By deploying data query services within the production data processing platform, we can efficiently process query requests from the test environment and automatically desensitize query results, ensuring data privacy while improving the real-time and security of data acquisition. The request and response mechanism based on the Hypertext Transfer Protocol ensures system compatibility and data transmission stability, avoids complex manual operations, and simplifies the development and testing process.

[0049] S20, in the development and testing platform, applying predefined marker annotations to the data access interface that requires a proxy;

[0050] In this embodiment, in the development and testing platform, certain data access interfaces need to access data query services in the production environment through a proxy. To implement automatic proxying, predefined marker annotations are used. This annotation is used to identify which interfaces need to call external services through a proxy instead of directly accessing the database. Marker annotations are a declarative approach that removes the need for developers to manually modify code logic by marking data access interfaces or methods. The annotations themselves do not change the implementation logic of the interface, but rather provide information for the subsequent dynamic proxy mechanism to facilitate proxy access to production data.

[0051] Use a predefined annotation mechanism to mark data access interfaces that need to be proxied in the development and testing platform. Annotations are usually defined as metadata that identify methods or interfaces that require special processing. The actual implementation will rely on runtime processing, using frameworks (such as Spring) to automatically scan and identify interfaces or methods marked with this annotation. The main function of the annotation is to serve as an identifier, indicating that the method does not directly access the data source, but instead calls the data query service of the production environment through a proxy mechanism. In specific implementation, the service dynamically scans these marking annotations at runtime, identifies the interfaces that need to be proxied, and then redirects the call to the proxy module for processing. The proxy module is responsible for communicating with the services in the production environment, directly accessing the data instead of the test environment.

[0052] Predefined annotations are used to clearly indicate that the marked data access interface needs to access the data query service in the production data processing platform through a cross-domain proxy. The core function of the cross-domain proxy is to solve the problem of data access between different network domains. For example, the test environment and the production environment are usually located in different network areas, and direct access is limited. The proxy can act as an intermediate layer to securely forward requests in the test environment to the production environment. Through the annotation mechanism, developers can instruct specific data access operations to be completed through the proxy. The cross-domain proxy is not only a bridge for data transmission, but also increases security, ensuring that sensitive data is protected and controlled when transmitted across the network. At the same time, this annotation helps automatically identify which interfaces require proxy access and which can be processed directly, making the development and testing process more flexible and automated.

[0053] During implementation, the system automatically scans all interfaces or methods marked with this annotation at startup and generates the corresponding proxy logic. These annotated methods do not communicate directly with the database, but instead forward requests to the production environment's services through the proxy module. The proxy module uses the HTTP protocol through a cross-domain mechanism to interact with the production environment's data query service. Cross-domain proxy can be implemented by configuring a reverse proxy server or by calling the backend service layer (such as HTTPClient). After receiving the request from the development and testing platform, the proxy module packages the request data and sends it to the data query service in the production environment. The proxy module can also perform security operations such as identity authentication and request signing when necessary to ensure the security and reliability of data transmission.

[0054] For example, in the development and testing platform, testers only need to call annotated data access interfaces, such as getUserTransactionData(), without having to understand the complex proxy mechanism behind them. The system automatically recognizes the annotations and, using the cross-domain proxy mechanism, securely forwards the query request to the production environment. The production environment's data query service then returns desensitized user transaction data (such as hiding some account information or obfuscating amounts) to the tester.

[0055] By applying predefined annotations to the development and testing platform, data access operations are made more automated and flexible. Developers no longer need to manually modify code or configure complex proxy logic; they can simply implement the proxy mechanism through annotations, reducing development workload. The introduction of cross-domain proxies ensures secure data access between test and production environments, improving testing efficiency while ensuring data privacy and security.

[0056] S30, during the startup of the service container of the development and testing platform, registering a post-processor, and configuring a dynamic proxy mechanism in the development and testing platform through the post-processor;

[0057] In this embodiment, in the development and testing platform, when the service container starts, all components (or "Beans") in the system will be loaded and initialized. The purpose of registering the post-processor is to add an additional processing step in this initialization process. The post-processor is an extension mechanism that allows developers to further process the Bean after initialization is completed. Through the post-processor, the system can automatically scan all data access interfaces in the system when the service container starts, and apply a proxy mechanism to them without manual intervention or modification of the original code logic. The post-processor is the basis for implementing dynamic proxies, which ensures that all interfaces marked with annotations can be proxied.

[0058] The post-processor is automatically registered when the service container starts and is triggered after each bean is loaded. During this process, it scans each data access interface, checking for annotations (such as @ProxySqlId) that indicate that access should be made through a proxy. If an interface requires proxies, the post-processor records it and configures proxy logic for it in subsequent steps. This mechanism allows the system to dynamically proxy the required interfaces without modifying the actual business code or manually configuring proxy logic.

[0059] The dynamic proxy mechanism allows the system to dynamically generate proxy classes at runtime to intercept calls to annotated data access interfaces. Through automatic registration of post-processors, the system is able to configure dynamic proxies after Bean initialization to implement proxy processing of data access interfaces. The core function of the dynamic proxy is to intercept requests and execute customized logic (such as forwarding requests to the production data processing platform) when the interface is called. In this way, when developers call certain data access interfaces in a test environment, the system automatically intercepts the call and sends the request to the production environment through the dynamic proxy mechanism, rather than directly calling the local service.

[0060] Once the dynamic proxy mechanism is configured, any calls to annotated data access interfaces will be intercepted by the dynamic proxy. The proxy mechanism automatically replaces the original interface call logic and forwards the call request to the data query service in the production data processing platform. The proxy mechanism uses remote call technologies (such as HTTP) to package the request data into a remote request format and send it to the production environment's data service. The production environment then processes the request and returns the data, which the proxy mechanism then returns to the caller in the test environment.

[0061] By automatically registering post-processors during service container startup, we can automatically scan and process data access interfaces marked with specific annotations and dynamically configure proxy mechanisms for these interfaces. This dynamic proxy mechanism eliminates the complexities of manually configuring proxy classes and enables automated access to production data from test environments. Automatically configuring proxy logic at startup simplifies development and testing processes, improving system flexibility and efficiency.

[0062] S40, intercepting the call to the data access interface with the predefined tag annotation through the dynamic proxy mechanism;

[0063] In this embodiment, the core of the dynamic proxy mechanism is to dynamically generate a proxy object at runtime to replace the implementation of the original data access interface. When the system recognizes that there is a predefined marker annotation on the data access interface (for example, used to indicate that the interface needs to access production data through a proxy), the proxy mechanism will intercept all calls to the interface. Interception means that when the caller attempts to execute a method in the marker annotation interface, the call will not directly execute the logic of the original method, but will execute the alternative logic through the proxy mechanism. The task of the proxy mechanism is to first capture this method call, and then process the call according to the predefined logic, such as forwarding it to the production data query service.

[0064] The dynamic proxy mechanism is usually implemented in conjunction with Java's reflection mechanism or bytecode generation technology. When the system starts, the dynamic proxy scans and identifies data access interfaces marked with predefined annotations. When an interface method marked with this annotation is called, the proxy mechanism intercepts the call and processes the logic in the proxy object. This mechanism can be implemented through AOP (Aspect-Oriented Programming) or a dynamic proxy library (such as Java's Proxy class or the third-party CGLIB library). In actual calls, the proxy class generated by the dynamic proxy mechanism replaces the original interface implementation and redirects the request to the proxy logic when the interface is called.

[0065] When a user calls an annotated data access interface, the dynamic proxy mechanism is responsible for intercepting the call. After interception, the proxy class can choose to execute predefined business logic, such as forwarding the request to the production environment via HTTP, or performing some processing locally. After the proxy logic is executed, the result is returned to the caller, making the entire process transparent to the developer.

[0066] By intercepting calls to data access interfaces marked with predefined annotations through a dynamic proxy mechanism, the system automatically processes and redirects interface requests to the production environment or other services. This mechanism simplifies the process of calling production data from the test environment, eliminating the need to manually configure each interface or modify existing code, ensuring flexibility and efficiency in the development process. Furthermore, by intercepting calls, the proxy mechanism enables the inclusion of additional logic, such as security verification and logging, improving the system's scalability and security.

[0067] S50, constructing a request based on the Hypertext Transfer Protocol based on the parameters passed when calling the data access interface with the predefined markup annotation, and sending the request to the data query service;

[0068] In this embodiment, when the system calls a data access interface marked with a predefined annotation, the caller typically passes a series of parameters, which may include query conditions, filter conditions, paging information, etc. The proxy mechanism captures these parameters passed during the call and uses them for subsequent remote request construction. These parameters are an important basis for constructing the request and directly affect the response result of the data query service. Therefore, the system needs to obtain and retain these parameters during the proxy process and ensure that they are correctly encapsulated into the HTTP request.

[0069] When the dynamic proxy mechanism intercepts a call, it uses reflection to obtain the parameters passed during the call, including the method parameter list and specific values. The proxy mechanism captures these parameters and constructs the query portion or request body of the HTTP request based on their content. For example, when querying a user's transaction information, the parameters might include the user ID and the query time period. After capturing these parameters, the proxy mechanism converts them into HTTP query parameters or encapsulates them in JSON format as the request body of a POST request.

[0070] Based on the captured interface call parameters, the system needs to construct a request based on the Hypertext Transfer Protocol (HTTP). HTTP is a protocol used for communication between clients and servers. When constructing an HTTP request, the system needs to encapsulate the parameters passed by the interface into the request URL (GET request) or the request body (POST request). In addition, the HTTP request may also need to include authentication information, request header information (such as Content-Type), etc. to ensure that the request can be correctly processed by the data query service in the production environment.

[0071] When constructing an HTTP request, the system can decide to use a GET or POST request based on the parameters passed:

[0072] GET request: Add the passed parameters to the query string portion of the URL (e.g., / query?userId=123&startDate=2023-01-01).

[0073] POST request: Encapsulate the passed parameters in JSON or XML format in the request body (for example, {"userId":123,"startDate":"2023-01-01"}).

[0074] During the request construction process, the system also needs to set appropriate HTTP header information, such as Content-Type (indicating the data format) and Authorization (if authentication is required).

[0075] The constructed HTTP request needs to be sent to the production environment's data query service. The data query service receives the request, executes the query based on the passed parameters, and ultimately returns the data to the caller. During this step, the proxy mechanism sends the encapsulated request to the production environment's server through an HTTP client (such as Java's HttpClient or RestTemplate), completing remote access to production data.

[0076] When sending an HTTP request, the system uses a network transport tool (such as HttpClient or RestTemplate in Java) to send the constructed request to the specified production data query service URL. Typically, the production environment's service address is defined in a configuration file or environment variable, and the proxy mechanism sends the request based on this address. The request is transmitted to the production environment via HTTP. The server executes the query based on the request parameters, generates response data, and returns the query results to the caller via an HTTP response.

[0077] By capturing call parameters for annotated data access interfaces, the proxy mechanism automatically constructs HTTP-based requests and sends them to the production data query service, greatly simplifying the data access process for developers in test environments. The automated process of constructing and sending HTTP requests ensures parameter integrity and security, improving the efficiency of remote calls to production data. This proxy mechanism also reduces the burden on developers to handle low-level communication details, making testing and development more efficient.

[0078] S60, the data query service performs a data query operation according to the request and obtains query result data;

[0079] In this embodiment, after receiving an HTTP request from the development and testing platform, the data query service performs a specific query operation based on the parameters carried in the request. This query operation typically involves accessing the production database system and retrieving data based on the passed query criteria (such as user ID, time range, etc.). The key to this step is that the data query service needs to accurately parse the parameters in the HTTP request and convert them into SQL queries or other database query languages ​​to ultimately obtain matching business data.

[0080] After receiving an HTTP request, the data query service parses the request parameters, such as the query string in the URL or the JSON fields in the request body. After parsing, the service converts these parameters into SQL queries or generates query operations through an object-oriented programming model (ORM) such as MyBatis or JPA. Based on the query conditions, the service accesses the production database and executes the corresponding query. To improve efficiency, the query service may use a connection pool to manage database connections, avoiding the creation of a new connection for each query. The service may also perform paging queries to ensure fast and efficient query responses even with large data volumes.

[0081] For example, if a user ID and a time range are passed in a request, the data query service generates the following SQL query: SELECT * FROM transactions WHERE user_id = ? AND transaction_date BETWEEN ? AND ? .

[0082] After the query operation is completed, the service extracts the results from the database and prepares them for subsequent processing.

[0083] After executing a query, the data query service encapsulates the business data retrieved from the database into query results. This data may consist of multiple data records, a single record, or aggregated statistical information, depending on the query type. Query result data may include sensitive fields, such as user personal information and transaction records, and therefore require further processing (e.g., desensitization) before being returned.

[0084] Retrieving query result data is the process of extracting the raw results from the database and storing them in a structured format after the query operation is completed. Query results are typically returned as lists or objects for subsequent desensitization and processing.

[0085] Query result data can be obtained in the following ways: directly query the database using SQL and encapsulate the results as Java objects or lists; or use an ORM framework (such as MyBatis or JPA) to simplify database interaction. The ORM automatically maps the query results to Java objects to facilitate subsequent operations.

[0086] The service stores the queried data in memory for subsequent processing (e.g., masking). Query results may need to be returned in pages, especially when processing large amounts of data. The data query service can perform preliminary data organization upon obtaining the results, such as sorting, filtering, or formatting some fields.

[0087] The data query service executes data queries based on HTTP requests, enabling accurate data retrieval. Parameterized queries enable the system to dynamically generate query conditions, flexibly addressing diverse query requirements. Query result data can be used for desensitization or other business logic after acquisition, achieving an automated data processing chain from request to result. This not only improves query efficiency but also lays a foundation for subsequent data security and processing operations.

[0088] S70, the data query service desensitizes the sensitive data in the query result data to obtain desensitized result data;

[0089] In this embodiment, in a production environment, query results may contain sensitive data fields (such as user personal identity information, financial data, etc.). To prevent sensitive data leakage, the system needs to desensitize the sensitive fields in the results before the data query service returns the query results. Desensitization refers to the use of technical means to cover, encrypt, or replace sensitive information so that even if the data is obtained by the test environment or other users, the original sensitive information cannot be inferred.

[0090] Target fields for desensitization may include user IDs, bank account numbers, transaction amounts, etc. These fields must have their sensitive parts removed or masked without affecting business functionality to ensure the data used in the test environment is secure.

[0091] Desensitization can be done using a variety of techniques, including:

[0092] Data masking: Cover or replace some sensitive data, such as displaying only the first six and last four digits of a bank card number and hiding the middle part (e.g., 123456******7890).

[0093] Encryption: Sensitive information is encrypted using an encryption algorithm so that even if the data is transmitted or stored, unauthorized persons cannot decrypt the original information.

[0094] Fuzzification: Fuzzify specific values, for example, display the actual transaction amount as a range (such as "200-300 yuan").

[0095] Random replacement: Use randomly generated virtual data to replace the original sensitive data, such as randomly generated user IDs or addresses, to ensure that the data structure is intact but the data content is false.

[0096] After receiving query results, the data query service automatically performs masking based on the type of sensitive data fields and predefined masking rules. The masked results are used for subsequent data transmission, ensuring that the data returned to the test environment is protected and does not contain any actual sensitive information.

[0097] After the masking process is complete, the original sensitive data in the query results is replaced or hidden, resulting in the masked result data. This masked result data has the same structure and format as the original data, but the sensitive information has been processed to an unrecognizable form. The masked result data ensures data security, meeting testing requirements without leaking sensitive information. The masked result data is ultimately returned to the caller (such as a system in a test environment), ensuring that secure data is used during development and testing, and preventing sensitive data from being leaked in non-production environments.

[0098] The system uses a predefined rule base to determine which fields to mask and what masking method to use. For example, masking can be used for ID card numbers and bank card numbers, while obfuscating transaction amounts. Masking can be dynamically selected based on different business scenarios. For example, in a test environment with higher data privacy requirements, a stronger masking policy can be implemented before returning the data.

[0099] The masked data retains the structure and format of the original data. For example, if the query result is a JSON object, the masked result is still a JSON object of the same format, except that the sensitive fields have been masked. The returned data can be directly used for business processing in the test environment.

[0100] By masking sensitive fields in query result data, we ensure that sensitive information is not leaked when production data is transferred to the test environment. Masking dynamically adapts to different data types, employing appropriate strategies for secure processing while ensuring that the returned data format and structure are consistent with the original data, enabling smooth testing without disrupting business logic. While ensuring security, the masked result data meets development and testing requirements and reduces the risk of data leakage.

[0101] S80, returning the desensitization result data to the development and testing platform through a response based on the Hypertext Transfer Protocol;

[0102] In the present embodiment, desensitization result data is query result data after processing, comprising the non-sensitive information in all original data and the sensitive information after desensitization processing. The core task of this step is to return the data after these desensitization to the development and test platform in a safe and standardized manner. In network communication, HyperText Transfer Protocol (HTTP, HyperText Transfer Protocol) is usually used to transmit data. This protocol is widely used in Web service communication, and supports the data of the various formats such as text, JSON, XML, etc. transmitted from the server to the client. Desensitization result data is returned to the development and test platform by HTTP response, ensuring that data is safely and reliably transmitted. In this process, the server needs to build an HTTP response object, using the desensitization result data as the main content of response, and setting the response header information according to the protocol standard to ensure that data can be correctly transmitted and parsed.

[0103] After executing the data query and desensitizing, the data query service encapsulates the result data into an HTTP response. This includes the following steps:

[0104] Response formatting: Encapsulate the masked result data into a structured data format, typically JSON or XML. This formatting operation ensures that the data can be correctly parsed and used in the client (development and testing platform).

[0105] Set HTTP response headers: To ensure data format and transmission compliance, the system needs to set the correct header information for the HTTP response. For example, Content-Type is set to application / json (if JSON data is returned) to inform the client how to parse the response content.

[0106] Return Response Data: The desensitized result data is transmitted over the network as part of the HTTP response body and returned to the development and testing platform. The server can also use a secure protocol (such as HTTPS) to encrypt the data during transmission to prevent it from being intercepted or tampered with.

[0107] For example, desensitized user transaction data will be returned in JSON format, with sensitive user information (such as transaction amount and user ID) already desensitized. After the development and testing platform receives this data, it can be directly used for business logic processing.

[0108] HTTP responses are the fundamental method of communication between web services and clients. When constructing responses, the system must ensure that the response content is structured and formatted correctly. The response header conveys metadata such as the response format and status code, while the response body contains the actual data. In this scenario, the response body is the de-encrypted query result data. The development and testing platform parses the response body to obtain the data and proceed to the next step of processing.

[0109] Set the appropriate response header based on the type of data returned. For example, when returning data in JSON format, the header should be set to Content-Type:application / json so that the development and testing platform can recognize and parse the data. The desensitized result data will be set as the HTTP response body. Java objects can be converted to JSON string format using the JSON serialization tool for easy transmission. Similarly, if XML format is used, the data needs to be converted into an XML string. The system transmits the response content to the development and testing platform via the HTTP protocol. To ensure the integrity and security of data transmission, the HTTPS protocol can be used for encrypted transmission.

[0110] Through a Hypertext Transfer Protocol (HTTP)-based response mechanism, desensitized data from the production data query service can be securely and efficiently returned to the development and testing platform. HTTP responses standardize the data transmission process, ensuring the standardization of data structure and transmission security. After desensitization, the development and testing platform can obtain secure and protected data, avoiding the risk of sensitive information leakage while ensuring system compatibility and scalability. This data transmission mechanism simplifies the development and testing process and improves data security.

[0111] S90, developing a dynamic proxy mechanism in the test platform to receive the desensitized result data, and passing the desensitized result data to the caller of the data access interface for business logic processing.

[0112] In this embodiment, the task of the dynamic proxy mechanism is to intercept the call of the data access interface, forward the request to the production data processing platform, and receive the returned desensitized result data after the query is completed. The desensitized result data is the processed security data returned by the production environment data query service, and the proxy mechanism needs to receive this data from the HTTP response. The dynamic proxy mechanism is not only responsible for forwarding requests, but also for passing the data returned by the production environment to the caller. Receiving desensitized result data means that the proxy mechanism parses the desensitized query result data from the response of the data query service of the production environment. This process usually includes parsing the HTTP response body and extracting the desensitized result data (such as business data in JSON format).

[0113] The dynamic proxy mechanism sends a request through an HTTP client (such as Java's HttpClient or RestTemplate) and waits for a response. Once the response is returned, the proxy mechanism extracts the decrypted data from the HTTP response body. This data is typically in JSON or XML format, and the system can use serialization tools to convert it into Java objects or other suitable data structures. This process includes: receiving the HTTP response; parsing the decrypted data (typically in JSON or XML format) from the response body; and storing the parsed data in an internal data structure for delivery to the caller.

[0114] After receiving the masked data, the dynamic proxy mechanism needs to pass it to the caller—the business code in the development and testing platform that initiated the data access request. The key to this step is passing the processed, masked data back to the calling interface, allowing the business logic to transparently process the returned data without having to worry about how the data was obtained from the production environment through the proxy.

[0115] The caller, perhaps a service or module within an application, retrieves the required data by invoking a data access interface. The proxy mechanism delivers the desensitized data to the caller, ensuring that the business logic can use the data for further processing, such as analysis, presentation, or storage.

[0116] After intercepting the call, the dynamic proxy mechanism handles data transmission and responses. Once the desensitized data is received, the proxy mechanism passes it to the caller of the data access interface as the method return value. This transfer process is typically automated; the caller simply calls the interface as they would a normal local method. The proxy mechanism handles the remote call and data transfer in the background, making the entire process transparent to the caller. The caller ultimately receives desensitized data that fully meets business requirements, without requiring additional processing of data privacy issues.

[0117] By receiving desensitized data through a dynamic proxy mechanism and passing it to the caller for business logic processing, the development and testing platform achieves secure access to production data without exposing sensitive information. This mechanism simplifies the development process, eliminating the need for the caller to understand the complexities of underlying data acquisition. The entire process is transparent to developers, improving development and testing efficiency. Furthermore, desensitization and secure transmission ensure the privacy of production data and reduce the risk of potential data leaks.

[0118] The present invention relates to the fields of data security technology and financial technology, and discloses a data desensitization processing and access method, which comprises deploying a data query service in a production data processing platform, receiving a request and returning desensitized data; applying predefined tag annotations in a development and testing platform, configuring a dynamic proxy mechanism; intercepting a data access interface call, constructing and sending a hypertext transfer protocol request; and executing a query and returning desensitized data after the production data processing platform receives the request, and the test environment receives and processes the desensitized data. The present invention simplifies the process of the test environment accessing the production environment data through a dynamic proxy mechanism, realizes automated data calling and desensitization processing, and improves the real-time and efficiency of data acquisition. It protects data privacy, meets the needs of rapid iterative development, and significantly improves the work efficiency of development and testing.

[0119] In one embodiment, the above S50 includes:

[0120] S501, generating an authentication token in the development and testing platform;

[0121] S502, constructing a request in accordance with the Hypertext Transfer Protocol format based on the parameters passed when calling the data access interface with the predefined markup annotation;

[0122] S503, during the request construction process, adding the authentication token to the header information of the request;

[0123] S504, sending the constructed request to the data query service;

[0124] S505, the data query service extracts and verifies the authentication token from the request;

[0125] S506: When the identity authentication token is verified, the data query service performs a data query operation.

[0126] In this embodiment, the authentication token (Token) is used to ensure the legitimacy of the identity of the request initiator and prevent unauthorized requests from accessing the production data query service. In the development and testing platform, the system will generate a unique authentication token for each request as a credential for the request. This token is usually generated based on a security algorithm and contains information such as a signature and validity period to ensure the legitimacy and validity of the request. The authentication token can be generated through OAuth2.0, JWT (JSON Web Token) or other encryption algorithms. The token is generated before the request is initiated and is securely stored in the header information of the request and sent to the production data query service along with the request. After the token is generated, it is valid for a limited time, and the system will encrypt the token to prevent tampering.

[0127] When intercepting calls to the data access interface, the dynamic proxy mechanism captures and parses the passed parameters. These parameters determine the conditions for data queries, such as user ID, query time period, etc. The system needs to construct a request that complies with the Hypertext Transfer Protocol (HTTP) based on these parameters. The request can be a GET request (parameters are in the URL) or a POST request (parameters are in the request body), depending on business needs and the amount of data. When the request is constructed, the system first determines the type of passed parameters and embeds these parameters into the URL or request body of the request in accordance with the HTTP specification. For GET requests, parameters are appended to the query string part of the URL; for POST requests, parameters are encapsulated as a data body in JSON or XML format. Regardless of the request method, the system needs to ensure that the parameters are correctly parsed and transmitted securely.

[0128] The authentication token must be passed through the HTTP header information of the request to ensure that the production data query service can identify and verify the legitimacy of the request. When building a request, the system needs to add the generated authentication token (such as JWT or OAuth token) to the HTTP header, usually in the Authorization field, so that the production environment can verify the token when the request arrives. When building a request, the system will set the Authorization field in the HTTP header with a value of "Bearer{token}" format (that is, the authentication token with a prefix). This token ensures that the request can be identified and verified when it is sent to the production data query service. The token is generated by an encryption algorithm, is tamper-proof and time-valid, and ensures the security of the data request.

[0129] The constructed HTTP request needs to be sent to the production data query service via network transmission. The system uses the HTTP client tool to send the request to the specified production environment URL. This step ensures that the data access request can reach the production data processing platform, and the server can perform corresponding operations based on the parameters in the request. Use HTTP Client (such as HttpClient or RestTemplate in Java) to send the constructed request. The request contains all necessary parameters, header information (including authentication tokens), and is transmitted over the network to the specified interface address of the production data query service. This process is usually performed through HTTP POST or GET, depending on specific business needs.

[0130] After receiving the request, the production data query service first needs to extract and verify the authentication token to ensure that the request is sent by a legitimate initiator. The verification process usually involves steps such as decrypting the token, checking the signature, and verifying the validity period of the token. If the token verification fails, the service will reject the request to prevent unauthorized access. The production data query service extracts the authentication token by parsing the Authorization field in the HTTP header. When verifying the token, the system uses a predefined key or algorithm for decryption and signature verification, and checks the validity period of the token. If the verification passes, the system allows the request to continue processing; if the verification fails, the system returns a corresponding error response.

[0131] Only after the authentication token is verified will the data query service execute the specific database query operation. At this point, the service will execute the corresponding data query based on the parameters carried in the request to obtain the business data in the production environment. This step ensures that data access operations are only executed after verification, ensuring the security of production data. Once the authentication is successful, the data query service will execute the database query operation based on the query conditions in the request. This step usually involves SQL queries or accessing the database through an ORM framework such as MyBatis or JPA. The query results are used for subsequent desensitization processing and then returned to the development and testing platform.

[0132] This embodiment ensures the security and legitimacy of requests by adding authentication tokens to requests, preventing unauthorized access to production environment data. Automating the process of generating and validating authentication tokens increases data transmission security and ensures that only legitimate requests can trigger data queries. This mechanism protects sensitive data, enhances system security, and provides a flexible cross-environment data access solution.

[0133] In one embodiment, the above S30 includes:

[0134] S301, during the startup of the service container of the development test platform, registering the post-processor;

[0135] S302, the post-processor scans all data access interfaces in the development and testing platform, and identifies data access interfaces marked with predefined tag annotations;

[0136] S303, when a data access interface marked with a predefined tag annotation is identified, a dynamic proxy mechanism is configured through the post-processor, and the dynamic proxy mechanism is used to generate a corresponding proxy class to intercept the call of the data access interface when the data access interface marked with the predefined tag annotation is called.

[0137] In this embodiment, when the service container of the development and testing platform is started, the system will load and initialize all service components. The post-processor (BeanPostProcessor) is a special component in the service container, which allows custom processing logic to be added after all beans (service components) are registered and initialized. The purpose of registering the post-processor is to expand the startup process of the service container and add a dynamic proxy mechanism for the data access interface in the development and testing platform. During the startup of the development and testing platform, the system will automatically load and register the custom post-processor. The post-processor is usually implemented through the BeanPostProcessor interface in the Spring framework, allowing the system to execute additional logic after the beans are initialized. Through the post-processor, the system can scan all data access interfaces and perform further processing according to specific tag annotations.

[0138] After the post-processor is registered and activated, its task is to scan all data access interfaces in the development and testing platform. The goal of the scan is to identify data access interfaces that are marked with specific predefined annotations. These annotations (such as @ProxySqlId) are used to indicate which interfaces need to be proxied to call the data query service of the production environment. The post-processor will automatically recognize these annotations and mark these interfaces as interfaces that need to be proxied. The post-processor uses reflection mechanisms or other scanning tools to traverse all registered beans in the development and testing platform and check whether their methods or interfaces have specific annotation tags. The marked data access interfaces will be recorded for dynamic proxy configuration in subsequent steps. This process is transparent to developers, and the system automatically completes identification and processing in the background.

[0139] When the post-processor identifies a data access interface marked with a predefined annotation, it triggers the configuration of the dynamic proxy mechanism. The role of the dynamic proxy is to generate proxy classes for these interfaces at runtime. The main task of the proxy class is to intercept calls to the data access interface and handle remote calls, data transmission and other operations in the background. Through dynamic proxy, the system can automatically forward call requests of the data access interface to the production data query service without modifying the business code. When the post-processor identifies an interface that needs to be proxied, it will dynamically generate proxy classes and replace the implementation of the original interface with these proxy classes. Dynamic proxy can be implemented using Java's Proxy class or bytecode enhancement libraries such as CGLIB. The proxy class is responsible for executing additional logic when the interface is called, such as capturing method parameters, generating HTTP requests, etc. Ultimately, the proxy class will forward the data query request to the data query service in the production environment.

[0140] The core function of the dynamic proxy mechanism is to intercept these calls and perform proxy operations when calling data access interfaces marked with specific annotations. The generated proxy class captures calls to the interface and executes them according to the predefined proxy logic, rather than directly calling the implementation of the original interface. The proxy class can build an HTTP request based on the call parameters, send the request to the production data query service, and process the returned response data. The dynamic proxy class is dynamically generated at runtime based on the marked annotations. The proxy class replaces the implementation of the original data access interface. When the method is called, the proxy class intercepts the call and executes custom logic, such as building an HTTP request or other remote call operations. The intercepted call result will be returned to the caller through the proxy class. The entire process is transparent to the caller, that is, the caller does not need to care about the underlying proxy implementation.

[0141] This embodiment implements automated proxy configuration and call interception by registering a postprocessor when the development and testing platform's service container starts. This postprocessor then configures a dynamic proxy mechanism, simplifying test environment access to production data. The postprocessor automatically scans and identifies data access interfaces requiring proxies, while the dynamic proxy mechanism ensures transparent processing of data requests. This automated process reduces developer workload and improves data access security and efficiency.

[0142] In one embodiment, the above S40 includes:

[0143] S401, generating a proxy class for a data access interface marked with a predefined tag annotation through a dynamic proxy mechanism;

[0144] S402, registering the proxy class into the service container of the development and testing platform to replace the implementation of the corresponding data access interface;

[0145] S403: In the development and testing platform, the proxy class intercepts the call to the data access interface marked with the predefined marker annotation.

[0146] In this embodiment, the task of the dynamic proxy mechanism is to generate a proxy class for a data access interface marked with a specific predefined marker annotation at runtime. The proxy class is used to replace the actual implementation of the original data access interface and is responsible for intercepting all calls to the interface. The proxy class can capture the call information of the interface (such as the parameters passed) and execute customized logic, such as forwarding the interface call to a remote data query service. The dynamic proxy class is generated based on the Java reflection mechanism or bytecode enhancement technology. When the system is running, the proxy mechanism identifies the interface marked with a predefined annotation (such as @ProxySqlId) and dynamically generates a corresponding proxy class based on the interface. The responsibility of the proxy class is to intercept calls to interface methods, capture parameters, execute proxy logic, and return the call results to the caller. Commonly used technologies in Java include java.lang.reflect.Proxy and CGLIB.

[0147] After generating the proxy class, the system registers it with the development and testing platform's service container, replacing the original data access interface implementation. This way, when the business code in the development and testing platform calls these interfaces, it actually calls the proxy class instead of the original interface implementation. The proxy class performs all necessary proxy operations behind the scenes, without requiring developers to modify business logic. Once the proxy class is generated, the system registers it as a service component with the development and testing platform's service container. This registration process can be implemented using the Spring container's Bean registration mechanism. The proxy class overwrites the original interface implementation, allowing proxy operations to be performed when called. The registered proxy class replaces the original interface and executes the customized logic without the caller being aware of the proxy.

[0148] Once the proxy class is registered and replaces the implementation of the original interface, it will intercept all calls to data access interfaces marked with predefined annotations at the time of invocation. Intercepted calls do not directly execute the original implementation logic of the interface, but instead execute the proxy logic through the proxy class. The proxy class can perform remote calls, data queries, and other operations based on the call parameters and return the results to the caller. The proxy class intercepts calls by implementing the same methods as the original interface. When the caller calls an interface marked with a predefined annotation, the proxy class automatically takes over the call and executes the customized proxy logic. The proxy class can capture the call parameters, execute the remote service call, process the response data, and pass the final result back to the caller. Developers do not need to modify the business code, and the proxy logic is executed transparently in the background.

[0149] This embodiment uses a dynamic proxy mechanism to generate a proxy class and register it with the service container. This allows for transparent interception of calls to annotated data access interfaces, enabling automated remote data access. The proxy class registration and call interception process are transparent to developers, simplifying proxy configuration while avoiding the complexity of manually creating proxy classes. The proxy mechanism improves the development and testing platform's access efficiency to production environment data while ensuring system security and maintainability.

[0150] In one embodiment, the above S50 includes:

[0151] S507, based on the proxy class corresponding to the data access interface with the predefined mark annotation, obtaining the calling parameters passed when the data access interface is called;

[0152] S508, the proxy class encapsulates the call parameters as part of the Hypertext Transfer Protocol request;

[0153] S509, the proxy class constructs a complete remote service request based on the partial content encapsulating the call parameters;

[0154] S510: The proxy class sends the remote service request to the data query service.

[0155] In this embodiment, when the dynamic proxy class intercepts the call to the data access interface, it captures all parameters passed during the call. The call parameters are the core of the business request and usually include query conditions, user ID, time range, etc. After being captured by the proxy class, these parameters need to be used to build a remote service request so that they can be forwarded to the production data query service. The proxy class obtains the passed parameters through the Java reflection mechanism. Through the interceptor or proxy mode, the proxy class can dynamically capture the call information of the interface method, including the actual parameters passed. The reflection mechanism enables the proxy class to traverse the parameter list and obtain the name and value of each parameter for subsequent use in the request.

[0156] After capturing the call parameters, the proxy class needs to encapsulate them as part of the HTTP request. HTTP request formatting involves converting the call parameters into a standardized request format. Specifically, GET request parameters are typically encapsulated as the URL's query string, while POST request parameters are encapsulated as JSON or XML in the request body.

[0157] The proxy class will choose to encapsulate the call parameters into different parts of the HTTP request based on the content of the call parameters:

[0158] For GET requests, the parameters are appended to the URL, forming a format similar to / query?userId=123&startDate=2023-01-01.

[0159] For POST requests, parameters are encapsulated as a JSON object in the request body, for example: {"userId":123,"startDate":"2023-01-01"}.

[0160] Constructing a complete HTTP request is one of the key tasks of the proxy class. In this step, the proxy class not only encapsulates the passed call parameters as the request content, but also needs to add the necessary HTTP header information (for example, Content-Type, Authorization, etc.) to ensure that the request can be correctly processed by the remote service. A complete request includes the URL, request method, request header, and request body. Using an HTTP client tool (such as HttpClient or RestTemplate in Java), the proxy class constructs a complete HTTP request. The specific steps include:

[0161] Set the request URL: determine the address of the remote service;

[0162] Add request header: add authentication token, content type and other information according to service requirements;

[0163] Set the request method: select a suitable request method such as GET or POST;

[0164] Set the request body: For POST requests, encapsulate the parameters as the request body content.

[0165] The fully constructed HTTP request needs to be sent over the network to the production data query service. The proxy class handles the request sending process, which is the core of the process. The proxy class is responsible for forwarding the constructed remote service request to the designated production data service interface via network communication. After the request is sent, the proxy class waits for the service's response and processes the returned data. The proxy class uses an HTTP client tool to send the constructed request to the production data query service URL. This request sending operation is typically implemented using libraries such as HttpClient and RestTemplate. The proxy class also handles both synchronous and asynchronous request processing and ensures data integrity and security during the request sending process (through the use of encrypted protocols such as HTTPS).

[0166] This embodiment uses a proxy class to capture call parameters and encapsulate them into HTTP requests, enabling transparent cross-environment data access. The proxy class automatically constructs and sends requests, eliminating the need for developers to manually construct complex remote requests, significantly improving development efficiency. The request encapsulation and transmission methods ensure data security, and the proxy class enables the test environment to securely and quickly access production data, meeting development and testing requirements.

[0167] In one embodiment, the above S70 includes:

[0168] S701, the data query service identifies sensitive data fields contained in the query result data based on preset field information;

[0169] S702, the data query service determines a corresponding desensitization method according to the type of the sensitive data field;

[0170] S703, the data query service performs a desensitization operation on the sensitive data field according to the desensitization method to generate a corresponding desensitized data field;

[0171] S704: Use the desensitized data field to replace the corresponding sensitive data field in the query result data to obtain desensitized result data.

[0172] In this embodiment, when processing the query results, the data query service first needs to identify which fields contain sensitive data. Sensitive data fields may include users' personal identity information, financial information, transaction records, etc. In order to automatically and accurately identify sensitive data fields, the system pre-defines a field information list, which lists which fields belong to sensitive data. In the data query service, the system maintains a field metadata table or configuration file to define which fields need to be desensitized. After obtaining the query results, the service matches the field name with the sensitive field information in the metadata table to identify the fields that need to be desensitized. For example, if the query results contain fields such as user_id and credit_card_number, these fields will be identified as sensitive data fields and marked as requiring desensitization.

[0173] Different types of sensitive data may require different desensitization methods. For example, a user's ID number may need to be partially masked, while the transaction amount may need to be blurred. Therefore, the data query service determines the specific desensitization method to be used based on the type of sensitive field to ensure that each type of sensitive data can be protected in the most appropriate way. In the preset field information, the system not only identifies which fields are sensitive fields, but also includes the type of each field (for example, string, number, date, etc.). The service selects the appropriate desensitization method based on the field type. Common desensitization methods include:

[0174] Partial masking: For example, for an ID card number or bank card number, only part of the characters are displayed, and the other characters are replaced with "*".

[0175] Fuzzy processing: Fuzzy processing is performed on numerical data, such as changing the specific transaction amount to a range.

[0176] Random replacement: Use randomly generated data to replace the original sensitive data, ensuring the same structure but different content.

[0177] Through the previous steps, the system has identified sensitive fields and their corresponding desensitization methods. Next, the data query service needs to perform desensitization operations on these fields. Desensitization operations will convert or replace the original data of sensitive fields to generate corresponding desensitized data. The service processes each sensitive field by calling different desensitization algorithms. For example:

[0178] For the ID number field, the system will use a masking algorithm to retain only the first two digits and the last two digits, and replace the remaining characters with "*"; for the transaction amount field, the system will convert the actual amount into a range, such as converting "1,000 yuan" to "500-1,500 yuan"; the desensitization processing result of each sensitive field will generate a new data field as the desensitization result.

[0179] After desensitization is complete, the data query service replaces the sensitive data fields in the original query results with the desensitized data fields. This way, the fields that originally contained sensitive information are replaced with secure desensitized data, forming the final desensitized result data.

[0180] The data query service traverses the query result data, identifies the sensitive fields that need to be replaced, and replaces them with the corresponding desensitized data fields. The replaced result data retains the original data structure and format, but the sensitive information has been desensitized. This desensitized result data can be securely returned to the development and testing platform for business logic processing.

[0181] This example effectively protects data privacy by selecting an appropriate desensitization method based on field type and replacing sensitive data fields in query results after processing. While ensuring the data structure remains unchanged, sensitive data is properly desensitized, making data use more secure during testing and development and avoiding the risk of data leakage. Automating the desensitization process improves system security and data processing efficiency.

[0182] In one embodiment, the above S80 includes:

[0183] S801, the production data processing platform encapsulates the desensitization result data into a structured format;

[0184] S802, the production data processing platform constructs a result response according to the Hypertext Transfer Protocol and configures response header information of the result response;

[0185] S803, setting the desensitization result data encapsulated in a structured format as the response body of the result response;

[0186] S804, the production data processing platform sends a result response including the desensitized result data to the development and testing platform.

[0187] In this embodiment, the result data after desensitization needs to be returned to the development and testing platform in a standard, easy-to-parse format. Structured formats (such as JSON, XML) ensure that the data can be effectively read and processed by the platform. By using a structured format, the production data processing platform can maintain the integrity and consistency of the data. The production data processing platform encapsulates the desensitized data according to a predetermined structured format, usually selecting JSON or XML format. These formats support nested structures and multi-field data representation, and are suitable for cross-system transmission and parsing. This encapsulation process ensures that the data content can be completely packaged into a unified format during transmission.

[0188] The Hypertext Transfer Protocol (HTTP) is used to transfer data between different platforms. When constructing an HTTP response, the platform must not only prepare the response content, but also set the response header to specify information such as the content type and data length. This information in the response header helps the recipient (i.e., the development and testing platform) correctly parse the response content. In the HTTP response, set the Content-Type (such as application / json or application / xml) to specify the format of the response data. Configuring the response header information (such as length, status code, etc.) ensures that the receiving platform can accurately interpret and use the data. When configuring the response header, you may also need to include additional security authentication information or other metadata.

[0189] The main body of the HTTP response (response body) carries the actual data content. In this step, the production data processing platform sets the structured, masked data as part of the HTTP response body. The response body is the primary carrier for transmitting data and contains the final processed data content. The masked data will be placed in the main body of the HTTP response. This data can be a JSON object, XML document, or other standardized format. The production data processing platform will ensure that the data content is complete and correct, and organize it according to the agreed format for easy parsing and use by the development and testing platform.

[0190] The production data processing platform sends the complete response to the development and testing platform via HTTP. This process ensures that data can be transmitted over the network from the production environment to the test environment. During transmission, the data maintains its structured format and content. The constructed response is sent to the designated receiving interface of the development and testing platform using HTTP or HTTPS. This step involves network transmission, and the production data processing platform must ensure the security and integrity of the data transmission. Encryption protocols (such as HTTPS) can be used during transmission to protect data privacy.

[0191] This embodiment ensures secure and standardized data transmission between the production and test environments by encapsulating the desensitized result data in a structured format and transmitting it using the HTTP protocol. The structured response format helps the development and testing platform accurately parse the data, while the response header information ensures the integrity and compatibility of the data transmission. In this way, the system can effectively protect sensitive data and ensure the security of data transmission.

[0192] In one embodiment, a data desensitization processing and access device is provided, which corresponds one-to-one with the data desensitization processing and access method in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of the data desensitization processing and access device of the present invention. It includes a data query service module 10, a data access interface module 20, a post-processor module 30, a dynamic proxy module 40, a request construction module 50, a data query module 60, a data desensitization module 70, a response generation and transmission module 80, and a result processing module 90. Each functional module is described in detail below:

[0193] The data query service module 10 is used to deploy a data query service in the production data processing platform. The data query service is used to receive requests based on the Hypertext Transfer Protocol and return query results after desensitization processing;

[0194] The data access interface module 20 is used to apply predefined tag annotations to data access interfaces that require proxies in the development and testing platform;

[0195] The post-processor module 30 is used to register the post-processor during the startup of the service container of the development and testing platform, and configure the dynamic proxy mechanism in the development and testing platform through the post-processor;

[0196] The dynamic proxy module 40 is used to intercept calls to data access interfaces with predefined tag annotations through the dynamic proxy mechanism;

[0197] A request building module 50 is used to build a request based on the Hypertext Transfer Protocol based on the parameters passed when calling the data access interface with the predefined markup annotation, and send the request to the data query service;

[0198] A data query module 60 is used for the data query service to perform a data query operation according to the request and obtain query result data;

[0199] A data desensitization module 70 is used for the data query service to perform desensitization processing on sensitive data in the query result data to obtain desensitized result data;

[0200] A response generation and transmission module 80 is used to return the desensitization result data to the development and testing platform through a response based on the Hypertext Transfer Protocol;

[0201] The result processing module 90 is used to develop a dynamic proxy mechanism in the test platform to receive the desensitized result data and pass the desensitized result data to the caller of the data access interface for business logic processing.

[0202] In one embodiment, the request construction module 50 is specifically configured to:

[0203] Generate an authentication token in the development test platform;

[0204] Constructing a request in accordance with the Hypertext Transfer Protocol format based on the parameters passed when calling the data access interface with the predefined markup annotation;

[0205] During the request construction process, the authentication token is added to the request header information;

[0206] Sending the constructed request to the data query service;

[0207] The data query service extracts and verifies the authentication token from the request;

[0208] When the authentication token is verified, the data query service performs a data query operation.

[0209] In one embodiment, the post-processor module 30 is specifically configured to:

[0210] During the service container startup process of the development test platform, register the post-processor;

[0211] The post-processor scans all data access interfaces in the development and testing platform and identifies data access interfaces marked with predefined tag annotations;

[0212] When a data access interface marked with a predefined tag annotation is identified, a dynamic proxy mechanism is configured through the post-processor, which is used to generate a corresponding proxy class to intercept the call of the data access interface when the data access interface marked with the predefined tag annotation is called.

[0213] In one embodiment, the dynamic proxy module 40 is specifically configured to:

[0214] Generate proxy classes for data access interfaces marked with predefined annotations through dynamic proxy mechanism;

[0215] Registering the proxy class in the service container of the development and testing platform to replace the implementation of the corresponding data access interface;

[0216] In the development and testing platform, the proxy class intercepts calls to the data access interface marked with the predefined marker annotation.

[0217] In one embodiment, the request construction module 50 is specifically configured to:

[0218] Based on the proxy class corresponding to the data access interface with the predefined mark annotation, obtaining the calling parameters passed when the data access interface is called;

[0219] The proxy class encapsulates the call parameters as part of the hypertext transfer protocol request;

[0220] The proxy class constructs a complete remote service request based on the partial content encapsulating the call parameters;

[0221] The proxy class sends the remote service request to the data query service.

[0222] In one embodiment, the data desensitization module 70 is specifically configured to:

[0223] The data query service identifies sensitive data fields contained in the query result data based on preset field information;

[0224] The data query service determines a corresponding desensitization method according to the type of the sensitive data field;

[0225] The data query service performs a desensitization operation on the sensitive data field according to the desensitization method to generate a corresponding desensitized data field;

[0226] The desensitized data field is used to replace the corresponding sensitive data field in the query result data to obtain desensitized result data.

[0227] In one embodiment, the response generation and transmission module 80 is specifically configured to:

[0228] The production data processing platform encapsulates the desensitized result data into a structured format;

[0229] The production data processing platform constructs a result response according to the Hypertext Transfer Protocol and configures response header information of the result response;

[0230] Setting the desensitized result data encapsulated in a structured format as the response body of the result response;

[0231] The production data processing platform sends a result response containing the desensitized result data to the development and testing platform.

[0232] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, memory, network interface and database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal via a network connection. When the computer program is executed by the processor, it realizes the functions or steps of a data desensitization processing and access method service side.

[0233] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, memory, network interface, display screen and input device connected via a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the user side of a data desensitization processing and access method.

[0234] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed:

[0235] Deploy a data query service in the production data processing platform, wherein the data query service is used to receive requests based on the Hypertext Transfer Protocol and return query results after desensitization processing;

[0236] In the development and testing platform, apply predefined marker annotations to the data access interfaces that require proxies;

[0237] During the service container startup process of the development and testing platform, a post-processor is registered, and a dynamic proxy mechanism in the development and testing platform is configured through the post-processor;

[0238] Intercepting calls to data access interfaces annotated with predefined markers through the dynamic proxy mechanism;

[0239] Constructing a request based on the Hypertext Transfer Protocol based on the parameters passed when calling the data access interface with the predefined markup annotation, and sending the request to the data query service;

[0240] The data query service performs a data query operation according to the request and obtains query result data;

[0241] The data query service performs desensitization processing on the sensitive data in the query result data to obtain desensitized result data;

[0242] Returning the desensitization result data to the development and testing platform through a response based on the Hypertext Transfer Protocol;

[0243] The dynamic proxy mechanism in the development and testing platform receives the desensitized result data and passes the desensitized result data to the caller of the data access interface for business logic processing.

[0244] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0245] Deploy a data query service in the production data processing platform, wherein the data query service is used to receive requests based on the Hypertext Transfer Protocol and return query results after desensitization processing;

[0246] In the development and testing platform, apply predefined marker annotations to the data access interfaces that require proxies;

[0247] During the service container startup process of the development and testing platform, a post-processor is registered, and a dynamic proxy mechanism in the development and testing platform is configured through the post-processor;

[0248] Intercepting calls to data access interfaces annotated with predefined markers through the dynamic proxy mechanism;

[0249] Constructing a request based on the Hypertext Transfer Protocol based on the parameters passed when calling the data access interface with the predefined markup annotation, and sending the request to the data query service;

[0250] The data query service performs a data query operation according to the request and obtains query result data;

[0251] The data query service performs desensitization processing on the sensitive data in the query result data to obtain desensitized result data;

[0252] Returning the desensitization result data to the development and testing platform through a response based on the Hypertext Transfer Protocol;

[0253] The dynamic proxy mechanism in the development and testing platform receives the desensitized result data and passes the desensitized result data to the caller of the data access interface for business logic processing.

[0254] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can be found in the relevant descriptions of the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0255] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0256] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0257] It should be noted that if any software tools or components other than those of the Company appear in the embodiments of this application, they are merely for illustration and do not represent actual use. The above embodiments are intended only to illustrate the technical solutions of the present invention, not to limit them. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some of the technical features therein with equivalents. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. A data desensitization processing and access method, characterized in that: The following steps are involved: Deploy a data query service in the production data processing platform, wherein the data query service is used to receive requests based on the Hypertext Transfer Protocol and return query results after desensitization processing; In the development and testing platform, apply predefined marker annotations to the data access interfaces that require proxies; During the service container startup process of the development and testing platform, a post-processor is registered, and a dynamic proxy mechanism in the development and testing platform is configured through the post-processor; Intercepting calls to data access interfaces annotated with predefined markers through the dynamic proxy mechanism; Constructing a request based on the Hypertext Transfer Protocol based on the parameters passed when calling the data access interface with the predefined markup annotation, and sending the request to the data query service; The data query service performs a data query operation according to the request and obtains query result data; The data query service performs desensitization processing on the sensitive data in the query result data to obtain desensitized result data; Returning the desensitization result data to the development and testing platform through a response based on the Hypertext Transfer Protocol; The dynamic proxy mechanism in the development and testing platform receives the desensitized result data and passes the desensitized result data to the caller of the data access interface for business logic processing.

2. The data desensitization processing and access method according to claim 1, characterized in that: Constructing a request based on a hypertext transfer protocol based on parameters passed when calling the data access interface with the predefined tag annotation, and sending the request to the data query service, including: Generate an authentication token in the development test platform; Constructing a request in accordance with the Hypertext Transfer Protocol format based on the parameters passed when calling the data access interface with the predefined markup annotation; During the request construction process, the authentication token is added to the request header information; Sending the constructed request to the data query service; The data query service extracts and verifies the authentication token from the request; When the authentication token is verified, the data query service performs a data query operation.

3. The data desensitization processing and access method according to claim 1, characterized in that: During the service container startup process of the development and test platform, a post-processor is registered, and the dynamic proxy mechanism in the development and test platform is configured through the post-processor, including: During the service container startup process of the development test platform, register the post-processor; The post-processor scans all data access interfaces in the development and testing platform and identifies data access interfaces marked with predefined tag annotations; When a data access interface marked with a predefined tag annotation is identified, a dynamic proxy mechanism is configured through the post-processor, which is used to generate a corresponding proxy class to intercept the call of the data access interface when the data access interface marked with the predefined tag annotation is called.

4. The data desensitization processing and access method as claimed in claim 1, characterized in that: By using the dynamic proxy mechanism, calls to data access interfaces with predefined annotations are intercepted, including: Generate proxy classes for data access interfaces marked with predefined annotations through dynamic proxy mechanism; Registering the proxy class in the service container of the development and testing platform to replace the implementation of the corresponding data access interface; In the development and testing platform, the proxy class intercepts calls to the data access interface marked with the predefined marker annotation.

5. The data desensitization processing and access method according to claim 1, characterized in that: Constructing a request based on a hypertext transfer protocol based on parameters passed when calling the data access interface with the predefined tag annotation, and sending the request to the data query service, including: Based on the proxy class corresponding to the data access interface with the predefined mark annotation, obtaining the calling parameters passed when the data access interface is called; The proxy class encapsulates the call parameters as part of the hypertext transfer protocol request; The proxy class constructs a complete remote service request based on the partial content encapsulating the call parameters; The proxy class sends the remote service request to the data query service.

6. The data desensitization processing and access method according to claim 1, characterized in that: The data query service performs desensitization processing on the sensitive data in the query result data to obtain desensitized result data, including: The data query service identifies sensitive data fields contained in the query result data based on preset field information; The data query service determines a corresponding desensitization method according to the type of the sensitive data field; The data query service performs a desensitization operation on the sensitive data field according to the desensitization method to generate a corresponding desensitized data field; The desensitized data field is used to replace the corresponding sensitive data field in the query result data to obtain desensitized result data.

7. The data desensitization processing and access method according to claim 1, characterized in that: Returning the desensitized result data to the development and testing platform through a response based on the Hypertext Transfer Protocol, including: The production data processing platform encapsulates the desensitized result data into a structured format; The production data processing platform constructs a result response according to the Hypertext Transfer Protocol and configures response header information of the result response; Setting the desensitized result data encapsulated in a structured format as the response body of the result response; The production data processing platform sends a result response containing the desensitized result data to the development and testing platform.

8. A data desensitization processing and access device, characterized in that: The data desensitization processing and access device includes: A data query service module is used to deploy a data query service in the production data processing platform. The data query service is used to receive requests based on the Hypertext Transfer Protocol and return query results after desensitization processing; The data access interface module is used to apply predefined marker annotations to the data access interfaces that need to be proxied in the development and testing platform; A post-processor module is used to register a post-processor during the startup of the service container of the development and testing platform, and configure the dynamic proxy mechanism in the development and testing platform through the post-processor; A dynamic proxy module, configured to intercept calls to data access interfaces annotated with predefined markers through the dynamic proxy mechanism; A request building module, configured to build a request based on the Hypertext Transfer Protocol based on the parameters passed when calling the data access interface with the predefined markup annotation, and send the request to the data query service; A data query module, configured for the data query service to execute a data query operation according to the request and obtain query result data; A data desensitization module is used for the data query service to perform desensitization processing on sensitive data in the query result data to obtain desensitized result data; A response generation and transmission module is used to return the desensitization result data to the development and testing platform through a response based on the Hypertext Transfer Protocol; The result processing module is used to develop a dynamic proxy mechanism in the test platform to receive the desensitized result data and pass the desensitized result data to the caller of the data access interface for business logic processing.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and a data desensitization processing and access program stored in the memory and runnable on the processor. When the data desensitization processing and access program is executed by the processor, the steps of the data desensitization processing and access method described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that The storage medium stores a data desensitization processing and access program, which, when executed by the processor, implements the steps of the data desensitization processing and access method according to any one of claims 1 to 7.

Images