Data resource management system and method based on dynamic hierarchical desensitization

Abstract

The application discloses a middle platform data resource management system and method based on dynamic hierarchical desensitization, and the system comprises a privacy hierarchical modeling module, a middle platform resource scheduling module, a dynamic desensitization strategy engine module and an access control and auditing module. The privacy hierarchical modeling module is used for acquiring multi-source data and generating data privacy hierarchical labels based on multi-dimensional hierarchical standards. The middle platform resource scheduling module is connected with the privacy hierarchical modeling module, the dynamic desensitization strategy engine module and the access control and auditing module, respectively, and is used for receiving a data access request, acquiring the data privacy hierarchical labels, calling a desensitization engine to perform a desensitization operation, and triggering the auditing module to perform permission verification and record. The dynamic desensitization strategy engine module is used for matching and executing a desensitization strategy based on the data privacy hierarchical labels and a request context, and returning data after desensitization. The access control and auditing module is used for performing permission verification on the data access request, recording access and desensitization logs, and forming auditing trace information. The application can improve data security protection capability and business adaptation flexibility.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a platform-based data resource management system and method based on dynamic hierarchical desensitization. Background Technology

[0002] As enterprises deepen their digital transformation, the number of various business systems (such as ERP, CRM, OA, etc.) continues to increase. Data is scattered across multiple independent databases, forming numerous "data silos" that make cross-business system data collaboration and unified governance difficult. To revitalize data assets, the current mainstream approach is to build a data platform to achieve unified access, aggregation, and distribution of multi-source data. However, traditional data platforms generally focus on building data sharing and distribution capabilities, neglecting data privacy and security control. This results in sensitive privacy data being mixed with ordinary business data, which can easily lead to data leakage and unauthorized access risks.

[0003] To address the aforementioned issues, existing technologies typically employ static data masking, completing the masking process once during the data entry phase and relying on conventional foreign encryption algorithms for data encryption. Their technical architecture is often based on outdated JDK versions and fragmented development frameworks, lacking a systematic privacy classification and end-to-end auditing mechanism. Therefore, existing technologies still suffer from the following shortcomings: they cannot dynamically adjust the masking strength based on runtime context such as user roles, application scenarios, access times, and data usage purposes; they do not comply with domestic compliance requirements; they have weak system concurrency capabilities and poor scalability; and they struggle to meet the traceability requirements of data security regulations.

[0004] Therefore, how to achieve unified management and sharing of multi-source data, dynamically execute de-identification strategies based on data privacy classification and access context, and simultaneously meet the requirements of domestic technology stack and regulatory compliance, thereby improving data security protection capabilities and business adaptability flexibility, is a technical problem that urgently needs to be solved. Summary of the Invention

[0005] In view of this, the embodiments of this application provide a platform-based data resource management system and method based on dynamic hierarchical desensitization, which can realize unified management and sharing of multi-source data, and can dynamically execute desensitization strategies according to data privacy classification and access context, while meeting the requirements of domestic technology stack and compliance supervision, thereby improving data security protection capabilities and business adaptability flexibility.

[0006] Firstly, this application provides a platform-based data resource management system based on dynamic hierarchical data anonymization, comprising: The privacy classification modeling module is used to acquire multi-source data, generate data privacy classification labels based on preset multi-dimensional classification standards and multi-source data, and perform privacy classification annotation on multi-source data. The middle platform resource scheduling module communicates with the privacy classification modeling module, the dynamic de-identification strategy engine module, and the access control and auditing module, respectively. It is used to receive data access requests initiated by business systems, obtain data privacy classification labels, call the dynamic de-identification strategy engine module to perform de-identification operations, and trigger the access control and auditing module to perform permission verification and auditing records. The dynamic de-identification strategy engine module also communicates with the privacy classification modeling module. It is used to match and execute the corresponding de-identification strategy based on the data privacy classification label and the request context when the data access request is executed, to obtain the de-identified data, and return the de-identified data to the middle platform resource scheduling module so that the de-identified data can be fed back to the business system through the middle platform resource scheduling module. The access control and auditing module also communicates with the dynamic masking strategy engine module to verify the permissions of data access requests, receive and record the data access records reported by the middle platform resource scheduling module, and the masking operation logs reported by the dynamic masking strategy engine module, so as to form audit traceability information. The audit traceability information is used to trace behavior, analyze anomalies and conduct compliance reviews of the entire process of data access and masking operations.

[0007] Secondly, this application provides a platform-based data resource management method based on dynamic hierarchical desensitization, including: The privacy classification modeling module acquires multi-source data, generates data privacy classification labels based on preset multi-dimensional classification standards and multi-source data, and performs privacy classification annotation on the multi-source data. When the central resource scheduling module receives a data access request from the business system, it obtains the data privacy classification label and triggers the access control and audit module to perform permission verification. After the permission verification is passed, the middle platform resource scheduling module calls the dynamic de-identification strategy engine module. The dynamic de-identification strategy engine module matches the corresponding de-identification strategy and executes it based on the data privacy classification label and the request context when the data access request is executed, so as to obtain the de-identified data and return the de-identified data to the business system. The access control and auditing module receives and records the data access records reported by the middle platform resource scheduling module, as well as the de-identification operation logs reported by the dynamic de-identification strategy engine module, forming audit traceability information to conduct behavior traceability, anomaly analysis, and compliance review of the entire process of data access and de-identification operations.

[0008] By employing the above technical solutions, this application provides a platform-based data resource management system and method based on dynamic hierarchical desensitization. Through the establishment of a privacy-leveling modeling module, data privacy-leveling labels are generated and annotated for multi-source data based on preset multi-dimensional hierarchical standards, thereby establishing a quantitative privacy-leveling system and achieving refined classification and control of sensitive and ordinary data from the source. A platform resource scheduling module, communicatively connected to the privacy-leveling modeling module, the dynamic desensitization strategy engine module, and the access control and auditing module, obtains the data privacy-leveling labels upon receiving data access requests from business systems. It then calls the dynamic desensitization strategy engine module to match and execute corresponding desensitization strategies based on the data privacy-leveling labels and the request context during request execution. This achieves dynamic, on-demand adjustment of desensitization intensity according to the user role, application scenario, and other runtime contexts, avoiding the problems of over- or under-desensitization caused by static desensitization, ensuring both data security and business availability. Simultaneously, the access control and auditing module verifies permissions for data access requests and records data access records and desensitization operation logs to form audit traceability information, achieving full-process traceability and anomaly analysis, and meeting the compliance requirements of data security regulations. Therefore, this invention effectively solves the problems of lack of dynamic desensitization capability, lack of privacy classification and unsound audit mechanism in the prior art, and improves data security protection capability and business adaptability flexibility.

[0009] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0010] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This illustration shows a schematic diagram of a platform-based data resource management system based on dynamic hierarchical desensitization provided in an embodiment of this application; Figure 2 This illustration shows a schematic diagram of the structure of a privacy-level modeling module 100 provided in an embodiment of this application; Figure 3 This illustration shows a structural diagram of a dynamic desensitization strategy engine module 300 provided in an embodiment of this application; Figure 4 This illustration shows a structural diagram of an access control and auditing module 400 provided in an embodiment of this application; Figure 5This illustration shows an architecture diagram of a platform-based data resource management system based on dynamic hierarchical desensitization provided in an embodiment of this application; Figure 6 The illustration shows a flowchart of a platform-based data resource management method based on dynamic hierarchical desensitization provided in an embodiment of this application; Figure 7 A schematic diagram of the system structure of a computer device provided in an embodiment of this application is shown. Detailed Implementation

[0011] The present application will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present application can be combined with each other.

[0012] This invention provides a platform-based data resource management system based on dynamic hierarchical de-identification, such as... Figure 1 As shown, the system includes: a privacy classification modeling module 100, a middleware resource scheduling module 200, a dynamic de-identification strategy engine module 300, and an access control and auditing module 400.

[0013] Among them, the privacy classification modeling module 100 is used to acquire multi-source data, generate data privacy classification labels based on preset multi-dimensional classification standards and multi-source data, and perform privacy classification annotation on multi-source data.

[0014] It should be noted that in this embodiment, the preset multi-dimensional classification standard does not judge the sensitivity of data from a single perspective, but comprehensively considers multiple dimensions such as the sensitivity of data content (whether it contains personal identity information such as ID card, mobile phone number, bank account, etc.), the scope of impact of leakage, the importance of business, and compliance requirements. It also assigns corresponding weights to each dimension, and then comprehensively evaluates each piece of data through weighted calculation, thereby classifying the data into different privacy levels.

[0015] Multi-source data refers to heterogeneous data sets that originate from multiple different business systems within an enterprise (such as ERP systems, CRM systems, OA systems, financial systems, customer management systems, etc.) and are originally stored in their respective independent databases.

[0016] Data privacy classification labels refer to the level identifiers (such as non-privacy level L1, ordinary privacy level L2, core privacy level L3, etc.) generated by the privacy classification modeling module 100 after comprehensively judging the privacy level of multi-source data based on preset multi-dimensional classification standards. These labels are associated with the original multi-source data and serve as the core basis for the subsequent dynamic de-identification strategy engine to match de-identification strategies.

[0017] In some embodiments, such as Figure 2As shown, the privacy classification modeling module 100 includes: a data access unit 101, a classification determination unit 102, and a label annotation unit 103.

[0018] The system includes a data access unit 101, which accesses the database of a multi-source business system to obtain multi-source data; a classification and determination unit 102, which determines the privacy level of multi-source data based on a multi-dimensional classification standard and through weighted calculation. The privacy level includes core privacy level, ordinary privacy level, and non-privacy level. The multi-dimensional classification standard includes data sensitivity, compliance requirements, business importance, and the scope of impact of leakage; and a labeling unit 103, which labels the multi-source data with corresponding privacy classification labels and establishes an association mapping between multi-source data and privacy classification labels.

[0019] In this embodiment, the data access unit 101 connects to the databases of multiple business systems within the enterprise, such as ERP, CRM, OA, finance, and customer management, to obtain multi-source data stored in a dispersed manner. The classification and judgment unit 102 is based on a preset multi-dimensional classification standard, which comprehensively considers the sensitivity of data, compliance requirements, business importance, and the scope of impact of leakage, and configures corresponding weights for each dimension, such as 40%, 30%, 20%, and 10% respectively. Then, it performs a comprehensive evaluation of each data item through linear weighted calculation to obtain the score result of each data item, and finally classifies the privacy level based on the score result.

[0020] Specifically, the formula for calculating the score for each data point is: S = A × a + B × b + C × c + D × d. Where S is the score, A is the data content sensitivity, B is the scope of the impact of the leak, C is the business importance, and D is the compliance requirement. a, b, c, and d are the weights corresponding to the data content sensitivity, the scope of the leak's impact, the business importance, and the compliance requirement, respectively.

[0021] It should be noted that after obtaining the score for each data point, the score is compared with a preset threshold to determine the privacy level. Specifically, when the score is greater than the first threshold, the privacy level of the corresponding data is determined to be core privacy level L1; when the score is greater than the second threshold and less than or equal to the first threshold, the privacy level of the corresponding data is determined to be ordinary privacy level L2; and when the score is less than or equal to the second threshold, the privacy level of the corresponding data is determined to be non-core privacy level L3.

[0022] It should be noted that after the privacy classification modeling module 100 acquires multi-source data through the data access unit 101, and before the classification judgment unit 102 performs privacy level determination, the multi-source data acquired by the data access unit 101 can also undergo data cleaning and standardization processing. This data cleaning and standardization processing includes parsing multi-source data from different business systems, identifying the business meaning and data type of each data field, removing duplicate data, correcting erroneous data, completing missing data, and unifying the data format, encoding standards, and units of measurement between different data sources. It also extracts key attribute features for privacy classification determination (such as whether the data contains sensitive fields like ID card numbers, mobile phone numbers, and bank account numbers, the business domain to which the data belongs, the data storage location, and access frequency), thereby transforming the original multi-source data into standardized multi-source data with a clear structure, unified format, and well-defined features. This provides a high-quality and comparable data foundation for the classification judgment unit 102 to perform weighted calculations and privacy level assessments based on multi-dimensional classification standards.

[0023] Furthermore, after the classification and determination unit 102 outputs the privacy level of the multi-source data, the labeling unit 103 generates a corresponding privacy classification label for each piece of data according to the privacy level output by the classification and determination unit 102, and establishes an association mapping between the label and the original data to complete the automated privacy classification labeling of the multi-source data, providing a core basis for the subsequent dynamic de-identification strategy engine to match de-identification rules on demand.

[0024] In some embodiments, the privacy classification modeling module 100 is also used to monitor changes in data resources and / or compliance policies, and based on the changes in data resources and / or compliance policies, update the multi-dimensional classification standards, and synchronously update the data privacy classification labels, and synchronize the updated data privacy classification labels to the middleware resource scheduling module 200 and / or the dynamic desensitization strategy engine module 300.

[0025] Specifically, the privacy classification modeling module 100 is also used to continuously monitor changes in data resources (such as new business system access, changes in existing data table structure, and adjustments to data field attributes), and / or changes in compliance policies (such as updates to the definition of sensitive data in laws and regulations such as the Personal Information Protection Law, or adjustments to industry regulatory requirements). Based on the above changes, it automatically triggers the update process of the multi-dimensional classification standard, which specifically includes readjusting the weight configuration of each dimension (such as the weight ratio of dimensions such as data content sensitivity, scope of leakage impact, business importance, and compliance requirements) or resetting the preset threshold for privacy level determination. Subsequently, based on the updated multi-dimensional classification standard, the affected data is re-weighted and the privacy level is determined, the privacy classification label is updated synchronously, and the updated privacy classification label is actively pushed or synchronized to the middle platform resource scheduling module 200 and the dynamic desensitization strategy engine module 300.

[0026] The middleware resource scheduling module 200 is communicatively connected to the privacy classification modeling module 100, the dynamic de-identification strategy engine module 300, and the access control and auditing module 400, respectively. It is used to receive data access requests initiated by business systems, obtain data privacy classification labels, call the dynamic de-identification strategy engine module 300 to perform de-identification operations, and trigger the access control and auditing module 400 to perform permission verification and auditing records.

[0027] In this embodiment, the middleware resource scheduling module 200, as the core scheduling hub of the middleware data resource management system, establishes bidirectional communication connections with the privacy classification modeling module 100, the dynamic de-identification strategy engine module 300, and the access control and auditing module 400, respectively. When a data access request initiated by any business system (such as an ERP system, CRM system, or OA system) in the business access layer via a RESTful API is received, the middleware resource scheduling module 200 first obtains the data privacy classification label corresponding to the requested data from the privacy classification modeling module 100, and simultaneously triggers the access control and auditing module 400 to perform permission verification on the requesting entity, that is, to verify whether the user or application has the access rights to the data resource (target data) requested by the data access request. After the permission verification is passed, the middleware resource scheduling module 200 forwards the data access request, along with the data privacy classification label and the request context (including the accessing user role, accessing application scenario, access time, data usage purpose, and accessing terminal information) to the dynamic de-identification strategy engine module 300, and calls it to perform the de-identification operation. The desensitization process includes: allowing non-privacy-level data to pass directly in plaintext; using character masks and format replacements for lightweight desensitization of ordinary privacy-level data; employing the domestic SM4 encryption algorithm for high-strength encryption of core privacy-level data; and directly blocking sensitive content for high-risk unauthorized access requests.

[0028] In some embodiments, the middleware resource scheduling module 200 is also used to return the de-identified data received from the dynamic de-identification strategy engine module 300 to the business system that initiated the data access request.

[0029] Specifically, after the dynamic de-identification strategy engine module 300 completes the de-identification operation and returns the de-identified data, the middle platform resource scheduling module 200 also uses the de-identified data as the response result of the data access request and returns it to the business system that initiated the request through RESTful API. This allows the business system to directly obtain dynamically de-identified data that matches the current user role, application scenario, and data usage purpose. Under the premise of ensuring the security of sensitive and private data, this maximizes the satisfaction of the business system's normal data usage needs and avoids the problems of over- or under-identification caused by static de-identification methods.

[0030] The dynamic de-identification strategy engine module 300 is also connected to the privacy classification modeling module 100. It is used to match and execute the corresponding de-identification strategy based on the data privacy classification label and the request context when the data access request is executed, to obtain the de-identified data, and return the de-identified data to the middle platform resource scheduling module 200, so that the middle platform resource scheduling module 200 can feed the de-identified data back to the business system.

[0031] It should be noted that in this embodiment, the dynamic de-identification strategy engine module 300 receives data access requests forwarded by the middleware resource scheduling module 200, and extracts privacy classification tags (such as core privacy level L1, ordinary privacy level L2, or non-core privacy level L3) and the request context when the data access request is executed. Then, based on these two pieces of information, the dynamic de-identification strategy engine module 300 matches the corresponding de-identification strategy from a preset de-identification strategy library. For example, for core privacy level L1 data and the accessing user is an ordinary user, full de-identification is performed (such as replacing all ID card numbers with ""). For ordinary privacy-level L2 data accessed by administrators, partial de-identification is performed (e.g., retaining the first four and last four digits of the ID number); for non-core privacy-level L3 data or high-privilege access scenarios, no de-identification or light de-identification is performed; after a successful match, the dynamic de-identification strategy engine module 300 calls the corresponding de-identification algorithm to perform the de-identification operation, obtains the de-identified data, and returns the de-identified data to the middle platform resource scheduling module 200.

[0032] In some embodiments, such as Figure 3 As shown, the dynamic de-identification strategy engine module 300 includes: a strategy configuration unit 301, a request parsing unit 302, a strategy matching unit 303, a de-identification execution unit 304, and a strategy update unit 305.

[0033] The system includes the following components: a policy configuration unit 301, which configures de-identification policies corresponding to each privacy level to form a de-identification policy library; a request parsing unit 302, which receives data access requests forwarded by the middleware resource scheduling module 200 and extracts the request context of the data access requests, including at least one of the following: access user role, access application scenario, access time, and access terminal information; a policy matching unit 303, which matches the corresponding de-identification policy from the de-identification policy library based on the data privacy classification label and the request context; a de-identification execution unit 304, which performs de-identification operations on multi-source data based on the matched de-identification policy to obtain the de-identified data; and a policy update unit 305, which receives privacy level update messages from the privacy classification modeling module 100 and updates the de-identification policy library.

[0034] Specifically, the policy configuration unit 301 is used to configure corresponding de-identification policies for each privacy level (such as core privacy level L1, ordinary privacy level L2, and non-core privacy level L3). For example, it configures a complete de-identification policy for L1 data, a partial de-identification policy for L2 data, and a no-de-identification or light-de-identification policy for L3 data, forming a dynamically expandable de-identification policy library. The request parsing unit 302 is used to receive data access requests forwarded by the middle platform resource scheduling module 200 and extract the request context from the request. The request context includes at least the access user role (such as administrator, ordinary user, auditor, etc.), access application scenario (such as query statistics, business processing, data analysis, etc.), access time (such as working hours or non-working hours), data usage purpose (such as for report generation, customer service, marketing analysis, etc.), and access terminal information (such as terminal device type, operating system type, network access method, and terminal security status). One or more of the following: ; Strategy matching unit 303, used to match the most suitable de-identification strategy from the de-identification strategy library based on the data privacy classification label and the above request context. For example, when the data privacy classification label is L2 and the accessing user role is a regular user, a partial de-identification strategy is matched; when the data privacy classification label is L2 but the accessing user role is an administrator, a no-de-identification strategy is matched; De-identification execution unit 304 is used to call the corresponding de-identification algorithm (such as masking, replacement, hashing, encryption, etc.) to perform dynamic de-identification operation on the target data according to the matched de-identification strategy, obtain the de-identified data, and return it to the middle platform resource scheduling module 200; Strategy update unit 305 is used to receive the privacy level update message sent by the privacy classification modeling module 100 after detecting changes in data resources or compliance policies, and automatically update the de-identification strategy corresponding to the privacy level in the de-identification strategy library accordingly, ensuring that the de-identification strategy can adapt to the iteration of business scenarios and the dynamic adjustment of compliance policies in the long term.

[0035] To further enhance the security of core privacy data during dynamic desensitization and meet national cryptographic management and domestic substitution compliance requirements, in some embodiments, the dynamic desensitization strategy engine module 300 uses the national cryptographic SM4 algorithm to encrypt and desensitize privacy data that meets preset sensitivity level conditions during the desensitization operation. Privacy data meeting preset sensitivity level conditions includes: data whose privacy classification labels reach or exceed preset thresholds (e.g., setting the preset threshold to core privacy level L1 or ordinary privacy level L2; all data reaching this level or above triggers national cryptographic SM4 encryption protection), and / or data containing personally identifiable information (such as ID card numbers, mobile phone numbers, bank account numbers, customer names, etc., which can directly or indirectly identify an individual).

[0036] It should be noted that this embodiment introduces the Chinese national cryptographic algorithm SM4 to replace traditional foreign encryption algorithms (such as AES, DES, etc.), which not only achieves strong encryption protection for highly sensitive privacy data, but also meets the mandatory compliance requirements of industries such as finance, government and enterprises for the application of domestic cryptographic algorithms, effectively avoiding the compliance risks and potential security problems caused by the use of foreign encryption algorithms.

[0037] In some embodiments, the dynamic desensitization strategy engine module 300 is also used to update the corresponding desensitization strategy based on the updated data privacy classification label.

[0038] For example, if a certain type of customer data is upgraded from ordinary privacy level L2 to core privacy level L1 due to new compliance policy requirements, the policy update unit 305 of the dynamic de-identification policy engine module 300 will capture the change message and automatically adjust the de-identification policy associated with the data in the de-identification policy library, such as upgrading the original partial de-identification policy to a complete de-identification policy or a national cryptographic SM4 encryption de-identification policy.

[0039] The access control and audit module 400 is also connected to the dynamic masking strategy engine module 300 to perform permission verification on data access requests, receive and record data access records reported by the middle platform resource scheduling module 200, and masking operation logs reported by the dynamic masking strategy engine module 300, so as to form audit traceability information. The audit traceability information is used to trace behavior, analyze anomalies and conduct compliance reviews of the entire process of data access and masking operations.

[0040] In this embodiment, the access control and auditing module 400 is used to perform permission verification on data access requests forwarded by the middleware resource scheduling module 200, verifying whether the requesting entity (such as a user or application system) has legitimate access rights to the target data; simultaneously, the module 400 receives and records the data access records reported by the middleware resource scheduling module 200 (including information such as accessing entity, access time, accessed data resources and operation type), as well as the de-identification operation logs reported by the dynamic de-identification strategy engine module 300 (including de-identification strategy matching results, de-identification algorithm execution status, and de-identified data summary information), integrating the above information to form a complete... The audit traceability information is used for end-to-end behavior tracing, anomaly analysis, and compliance review of the entire process of data access and de-identification operations. This includes the entire process from user-initiated access requests, permission verification, acquisition of hierarchical tags, matching and execution of de-identification strategies, to the return of de-identified data to the business system. In the event of data leakage, unauthorized access, or illegal operations, the audit traceability information can be used to quickly locate the problematic link and the responsible party, fully meeting the compliance and regulatory requirements of laws and regulations such as the Cybersecurity Law, the Personal Information Protection Law, and data security level protection for the traceability and auditability of the entire data operation process.

[0041] In some embodiments, such as Figure 4 As shown, the access control and auditing module 400 includes: a permission verification unit 401, a log recording unit 402, an exception alarm unit 403, and an alarm push unit 404.

[0042] The system includes: an access verification unit 401, which verifies whether the entity initiating the data access request has access rights to the target data, where the target data is the data resource requested by the data access request; a log recording unit 402, which records data access logs, de-identification operations, and data flow logs; an anomaly alarm unit 403, which monitors access behavior in real time and generates alarm information; and an alarm push unit 404, which pushes alarm information to the management terminal.

[0043] In this embodiment, the permission verification unit 401 is used to verify whether the subject initiating the data access request (such as a user or application system) has legitimate access rights to the target data (i.e., the data resource specifically requested by the data access request). Only after the verification is passed can the subsequent de-identification and data return process be continued. The log recording unit 402 is used to record all data access logs (including access subject, access time, accessed data resource and operation type, etc.), de-identification operation logs (including de-identification strategy matching results, de-identification algorithm execution status and execution time, etc.), and data flow logs (including data transmission path and processing status between different modules). The system comprises four units: an alarm unit 403 and an alarm push unit 404. The former is used to monitor access behavior in real time, such as detecting large-scale access to sensitive data within a short period, abnormal access outside of working hours, and unauthorized attempts to access unauthorized data. When an anomaly is detected, an alarm is automatically generated, including key elements such as the anomaly type, time of occurrence, data resources involved, and the accessing entity. The latter pushes the alarm information generated by the former to management terminals (such as system administrator email, SMS gateway, or unified monitoring platform) in real time, enabling administrators to be aware of security risks and take timely action. The collaborative work of these four units achieves a closed-loop security control system across the entire data access process, from permission verification and logging to anomaly monitoring and alarm push, effectively supporting behavior traceability and compliance review throughout the data access process.

[0044] It should be noted that the Taihua Data Resource Management System provided in this application uses JDK17 and SpringBoot 3.2 as the basic technology stack, and is equipped with caching middleware, message queue middleware and log analysis middleware to build a highly stable enterprise-level technical architecture, effectively replacing the traditional system solution built on old JDK versions and scattered development frameworks.

[0045] Specifically, it adopts JDK 17 Long Term Support version to provide a stable Java runtime environment and performance optimization, uses Spring Boot 3.2 as the core development framework to achieve modular and configurable rapid development and deployment, uses MySQL database for persistent storage, and integrates caching middleware, message queue middleware and log analysis middleware to run in a coordinated manner.

[0046] In some instances, Redis is used as the caching middleware to cache frequently accessed data and de-identification policy configurations, improving system response speed and concurrent processing capabilities. RabbitMQ is used as the message queue middleware to implement asynchronous communication such as privacy-graded update messages and de-identification policy change notifications, decoupling direct dependencies between modules and enhancing system scalability and stability. The log analysis middleware uses the ELK (Elasticsearch, Logstash, Kibana) stack for centralized collection, storage, retrieval, and analysis of data access logs, de-identification operation logs, and audit traceability information, supporting real-time querying and visualization of massive logs. It should be noted that the technology stack configuration in this application embodiment abandons traditional outdated technology systems, adapts to the requirements of domestic IT innovation transformation, and boasts strong system stability, high concurrency response capabilities, good scalability, and low post-maintenance costs. It can fully meet the enterprise-level needs for high concurrency, multi-business, multi-scenario differentiated data access, and real-time de-identification management.

[0047] It should be noted that, as Figure 5 As shown, the platform-based data resource management system provided in this application adopts a layered architecture design, which includes, from top to bottom, a business access layer 510, a platform core layer 520, a data storage layer 530, and an infrastructure layer 540.

[0048] Among them, the business access layer 510 includes various business systems (such as ERP system, CRM system, OA system, etc.), which communicate with the core layer of the middle platform through RESTful API to send data access requests and receive anonymized data.

[0049] The core layer 520 of the middle platform includes the privacy classification modeling module 100, the middle platform resource scheduling module 200, the dynamic de-identification strategy engine module 300, and the access control and auditing module 400. It is the core functional layer of the management system and is used to realize privacy classification, dynamic de-identification, access control and audit traceability.

[0050] The data storage layer 530 includes a MySQL database (used to store data resources, hierarchical tags, de-identification rules, audit logs, etc.) and a Redis cache (used to cache high-frequency data and configure de-identification strategies).

[0051] The infrastructure layer 540 includes a Java development environment, the Spring Boot 3.2 framework, the RabbitMQ message middleware, the Elasticsearch search engine, the ELK log analysis platform, and the Spring Security framework, providing basic operational support for the system. This four-layer architecture achieves separation and decoupling of responsibilities among layers, effectively improving the scalability, maintainability, and overall operational stability of the management system.

[0052] In summary, the platform-based data resource management system based on dynamic hierarchical desensitization provided in this application establishes a quantitative privacy hierarchical system by setting a privacy hierarchical modeling module to generate and label data privacy hierarchical tags for multi-source data based on preset multi-dimensional hierarchical standards. This enables refined classification and control of sensitive and ordinary data from the source. A platform resource scheduling module, which is communicatively connected to the privacy hierarchical modeling module, the dynamic desensitization strategy engine module, and the access control and auditing module, acquires the data privacy hierarchical tags upon receiving a data access request from a business system. The module then calls the dynamic desensitization strategy engine module to match and execute the corresponding desensitization strategy based on the data privacy hierarchical tags and the request context. This allows for dynamic, on-demand adjustment of desensitization intensity based on the user role, application scenario, and other runtime contexts, avoiding the problems of over- or under-desensitization caused by static desensitization. This ensures both data security and business availability. Simultaneously, the access control and auditing module verifies permissions for data access requests and records data access records and desensitization operation logs to form audit traceability information. This achieves full-process traceability and anomaly analysis, meeting the compliance requirements of data security regulations. Therefore, this invention effectively solves the problems of lack of dynamic desensitization capability, lack of privacy classification and unsound audit mechanism in the prior art, and improves data security protection capability and business adaptability flexibility.

[0053] After introducing the platform-based data resource management system, this application will now introduce a platform-based data resource management method based on dynamic hierarchical desensitization, which is applied to the platform-based data resource management system provided in the above embodiments. Figure 6 As shown, the method includes: S601 acquires multi-source data through the privacy classification modeling module, generates data privacy classification labels based on preset multi-dimensional classification standards and multi-source data, and performs privacy classification annotation on multi-source data.

[0054] S602 When the platform resource scheduling module receives a data access request from the business system, it obtains the data privacy classification label and triggers the access control and audit module to perform permission verification.

[0055] S603 After the permission verification is passed, the middle platform resource scheduling module calls the dynamic de-identification strategy engine module. The dynamic de-identification strategy engine module matches the corresponding de-identification strategy and executes it based on the data privacy classification label and the request context when the data access request is executed, so as to obtain the de-identified data and return the de-identified data to the business system.

[0056] S604 The access control and auditing module receives and records the data access records reported by the middle platform resource scheduling module and the de-identification operation logs reported by the dynamic de-identification strategy engine module, forming audit traceability information to conduct behavior traceability, anomaly analysis and compliance review of the entire process of data access and de-identification operation.

[0057] The platform-based data resource management method provided in this application first acquires multi-source data from multiple business systems such as ERP, CRM, and OA through a privacy-level modeling module. Based on preset multi-dimensional grading standards, it generates data privacy grading labels (such as core privacy level L1, ordinary privacy level L2, and non-core privacy level L3) and automatically labels the multi-source data with privacy grading. When the platform resource scheduling module receives a data access request initiated by a business system, it obtains the corresponding data privacy grading label and triggers the access control and auditing module to verify the permissions of the requesting entity. After the permission verification is passed, the platform resource scheduling module calls the dynamic de-identification strategy engine module. This dynamic de-identification strategy engine module matches and executes the corresponding de-identification strategy from the de-identification strategy library based on the data privacy grading label and the request context during the data access request (including the accessing user role, accessing application scenario, access time, data usage purpose, and accessing terminal information). For example, full anonymization is performed on core privacy-level L1 data accessed by ordinary users; partial anonymization is performed on ordinary privacy-level L2 data accessed by administrators; and no anonymization or mild anonymization is performed on non-core privacy-level L3 data or high-privilege access scenarios. The anonymized data is then returned to the business system. Simultaneously, the access control and auditing module receives and records data access records reported by the middleware resource scheduling module and anonymization operation logs reported by the dynamic anonymization strategy engine module, integrating them to form complete audit traceability information. This information is used for end-to-end behavior tracing, anomaly analysis, and compliance review of the entire data access and anonymization operation process. The implementation methods of the privacy classification modeling module, middleware resource scheduling module, dynamic anonymization strategy engine module, and access control and auditing module are the same as those of the corresponding modules in the above embodiments, and will not be repeated here.

[0058] After introducing the platform-based data resource management system and platform-based data resource management method provided in the embodiments of this application, the following section takes the data management scenario of a large financial technology company as an example to first introduce the implementation method of deploying the platform-based data resource management system.

[0059] First, the system is developed using Java and the mainstream stable version of Spring Boot 3.2, adapted to the JDK 17 runtime environment, to improve system performance, security, and long-term compatibility. It is then deployed with optimal middleware to create a centralized data resource management system, thereby achieving centralized management, privacy-level control, and dynamic data masking for data from multiple enterprise business systems. The specific implementation process is as follows: First, based on Figure 5 The four-layer architecture shown completes system deployment and environment configuration. The deployment details of each layer and the selection of middleware follow the implementation method described above, as follows: (1) Deployment at the infrastructure layer The infrastructure layer serves as the fundamental support for system operation, and its deployment and configuration are as follows: Java development environment: Deploy JDK 17 Long Term Support version to ensure the Spring Boot framework runs normally, supports cross-platform deployment, and is compatible with the enterprise's existing server environment.

[0060] SpringBoot Framework: Utilizing the mainstream version of SpringBoot, the application.yml configuration file enables unified configuration of data sources, caches, message middleware, etc., simplifying system deployment and maintenance. Key configuration examples are as follows: server: port: 8080 (system port) spring: datasource: url: jdbc:mysql: / / localhost:3306 / data_center?useUnicode=true&characterEncoding=utf-8 (MySQL connection address) redis: host: localhost:6379 (Redis cache address) rabbitmq: host: localhost:5672 (RabbitMQ address).

[0061] RabbitMQ message middleware: Deploy RabbitMQ version 3.13.x, creating three queues (data_access_queue, desensitization_queue, update_queue), respectively used for forwarding business access requests, asynchronous processing of desensitization operations, and pushing hierarchical and policy update messages, ensuring smooth asynchronous communication between modules. Figure 5 Communication links between the infrastructure layer and the core layer of the middle platform.

[0062] Elasticsearch Search Engine: Deploy Elasticsearch version 8.13.x, create indexes (data_resource_index, audit_log_index) for data resource retrieval and audit log retrieval respectively, and support precise queries based on privacy-level tags and data types. Figure 5 The collaboration between the infrastructure layer and the data storage layer.

[0063] ELK Log Analysis Platform: Deploys Logstash 8.13.x and Kibana 8.13.x, working in conjunction with the Logback logging framework. Logback is responsible for collecting system operation logs, data access logs, and de-identified operation logs, Logstash is responsible for log filtering and parsing, and Kibana is responsible for log visualization and retrieval.

[0064] Spring Security framework: Integrated into Spring Boot applications, it configures user authentication methods (account and password authentication), and presets three roles: administrator, business operator, and ordinary user, corresponding to different data access permissions, thus completing the basic configuration of permission control.

[0065] (2) Data storage layer deployment The deployment configuration is as follows: MySQL Database: Deploy MySQL version 8.0, create the database data_center, and create 5 core data tables: data_resource (data resource table, storing data asset catalog and attribute characteristics), privacy_level (privacy level table, storing level standards and level labels), desensitization_rule (desensitization rule table, storing desensitization rules corresponding to each level), audit_log (audit log table, storing access and desensitization operation logs), and user_role (user role table, storing user information and role permissions). All data tables have primary keys and indexes to improve query efficiency.

[0066] Redis caching: Deploy Redis version 7.0+, set cache expiration time (1 hour for normal cache, 24 hours for frequently accessed data), cache content includes: frequently accessed non-privacy-level data, de-identified normal privacy-level data, privacy-level tags, and de-identification rules, corresponding to... Figure 5 The cache interaction between the data storage layer and the core layer of the middle platform improves system response speed.

[0067] (3) Deployment of the core layer of the middle platform The core layer of the middle platform deploys four core modules (i.e. Figure 1The various modules in the application are integrated into the Spring Boot application, deployed on the same application server, communicate between modules through Spring Context, perform asynchronous operations using RabbitMQ, and share caches using Redis.

[0068] (3) Deployment of the service access layer The business access layer interfaces with the enterprise's existing ERP, CRM, and OA systems. It communicates with the core layer of the middle platform via RESTful APIs. Each business system calls the core layer's interfaces via HTTP requests, sending data access requests (e.g., a CRM system requesting customer information, an ERP system requesting financial data), and receives anonymized data returned by the middle platform. Figure 5 The communication relationship between the middle service access layer and the middle platform core layer.

[0069] After introducing the implementation method of deploying the platform-based data resource management system, the following section describes the specific operation of the privacy classification modeling module, the platform resource scheduling module, the dynamic de-identification policy engine module, and the access control and auditing module: (1) Privacy-based modeling module Data Access: Through Spring Boot's RestTemplate interface, we connect to the data sources of ERP, CRM, and OA systems respectively. The ERP system provides financial data (such as transaction records and account information), the CRM system provides customer data (such as names, mobile phone numbers, and ID card numbers), and the OA system provides office data (such as employee basic information and approval records). We obtain various data resources through HTTP requests and transmit them to this module.

[0070] Data cleaning and standardization: The acquired data is parsed using FastJson tools to clean invalid data (such as null values ​​and duplicate data), standardize the data format (such as unifying mobile phone numbers to 11 digits and dates to yyyy-MM-dd format), and extract the attribute features of each type of data. For example, the attribute features of customer data include: data name (customer information), data type (structured data), business domain (CRM), and sensitive fields (mobile phone number, ID card number).

[0071] Privacy grading criteria matching: Based on preset multi-dimensional privacy grading standards, the privacy level of multi-source data is determined through weighted calculation (total score = data sensitivity × 40% + compliance requirements × 30% + business importance × 20% + scope of leakage impact × 10%), with each dimension scored from 0 to 10. Specific examples are as follows: Customer ID number: Sensitivity 10 points, Compliance requirements 10 points, Business importance 8 points, Scope of leakage impact 10 points, total score 9.4 points, classified as core privacy level; Customer name: Sensitivity 6 points, Compliance requirements 7 points, Business importance 6 points, Scope of leakage impact 6 points, total score 6.3 points, classified as ordinary privacy level; OA office approval records: Sensitivity 2 points, Compliance requirements 3 points, Business importance 4 points, Scope of leakage impact 2 points, total score 2.8 points, classified as non-privacy level.

[0072] Hierarchical labeling: The attribute features of various types of data are extracted through Java reflection mechanism, and a unique hierarchical label is automatically assigned to each type of data. For example, customer ID numbers are labeled "core privacy level-001", customer names are labeled "normal privacy level-002", and OA approval records are labeled "non-privacy level-003". A mapping between data and hierarchical labels is established and stored in the privacy_level table in MySQL, and simultaneously synchronized to the Redis cache.

[0073] Tiered updates (corresponding) Figure 3 Step 5): Based on Spring scheduled tasks, monitor data changes, business requirement adjustments, and compliance policy updates every day at 1:00 AM. For example, when regulatory authorities add new requirements for customer privacy protection, adjust the compliance requirement dimension scoring standards for customer data, recalculate the classification, update the classification labels, and synchronize them to MySQL and Redis. At the same time, push update messages to the dynamic de-identification strategy engine module through RabbitMQ's update_queue to notify it to update the de-identification rule library.

[0074] (2) Dynamic desensitization strategy engine module Policy Configuration: Based on privacy-level labels, pre-defined desensitization rules for each level are stored in the `desensitization_rule` table in MySQL and cached in Redis. Specific rule configurations are as follows: Core privacy level (e.g., ID card number): Encryption is performed using the domestic SM4 encryption algorithm. The encryption key is managed through a Spring Boot configuration class, and only administrators can view the complete encrypted data. Ordinary privacy level (e.g., mobile phone number): Partial masking is used, retaining the first 3 and last 4 digits, while replacing the middle 4 digits with "". (e.g., 138) 5678); Non-privacy level (such as OA approval records): No anonymization operation is performed, and the original data is returned directly.

[0075] Request reception: Receive access requests and request context information forwarded by the middleware resource scheduling module through the desensitization_queue. For example, a customer information query request sent by a regular user of the CRM system. The request context includes: access user role (regular user), access application scenario (customer information query), access time (2026-03-24 10:30:00), and access terminal information (Windows 10, IP address 192.168.1.100).

[0076] Strategy matching: Using Java multi-threading, quickly read the hierarchical tags of the data corresponding to the request from the Redis cache (e.g., "normal privacy level - 002" for customer mobile phone numbers), combine them with the request context (normal user role), match the corresponding de-identification rules (partial masking), and determine the de-identification strength to be the normal strength.

[0077] Masking Execution: Based on the matching masking rules, a partial masking operation is performed to mask the customer's mobile phone number "13812345678" to "138". If "5678" is a core privacy-level ID number (such as 110101199001011234), then the national cryptographic standard SM4 encryption will be performed to generate an encrypted ciphertext string; Results feedback: The de-identified data is fed back to the middle platform resource scheduling module through the desensitization_queue, and then forwarded to the business system by the middle platform resource scheduling module.

[0078] Policy Update: Receive privacy classification update messages pushed by the privacy classification modeling module through the update_queue. For example, after the classification of customer name is adjusted from ordinary privacy level to core privacy level, the de-identification rule library is updated synchronously, and the de-identification rule of customer name is changed from partial masking to national cryptographic SM4 encryption to ensure that the de-identification policy is synchronized with the classification label.

[0079] (3) Mid-platform resource scheduling module and access control and auditing module The middle-platform resource scheduling module receives access requests from business systems, parses request parameters using the SpringMVC framework, extracts request context information, and sends it to the access control and auditing module for permission verification. After successful permission verification, it retrieves the corresponding data resources from MySQL or Redis and forwards them to the dynamic de-identification strategy engine module for de-identification processing. It receives the de-identified data and asynchronously feeds it back to the business system via RabbitMQ. At the same time, it caches frequently accessed non-privacy data (such as OA approval records) in Redis and performs cache verification periodically to ensure data consistency.

[0080] Access Control and Auditing Module: Receives access requests and context information from the resource scheduling module of the middle platform. Based on the RBAC model of Spring Security, it performs permission verification. For example, if a regular user requests access to a core privacy-level customer ID number, the verification fails, the request is intercepted, and an "insufficient permissions" message is returned. For requests that pass verification, access logs (including operator, access time, data type, hierarchical tags, and de-identification methods) are recorded via Logback and stored in the `audit_log` table in MySQL. The logs are also visualized through the ELK platform. Real-time monitoring of data access behavior is also implemented. When high-frequency access is detected (e.g., multiple requests for core privacy data by the same user within one minute), an alarm mechanism is triggered, pushing alarm messages to the administrator terminal via RabbitMQ, recording anomaly details, and supporting traceability and handling.

[0081] After introducing the specific operation steps of the privacy classification modeling module, the middle platform resource scheduling module, the dynamic de-identification strategy engine module, and the access control and auditing module, the following describes the implementation process of the middle platform-based data resource management method in the above scenario.

[0082] S1, the middle platform resource scheduling module automatically configures the data source of ERP, CRM and OA systems through Spring Boot's DataSource, uses MyBatis-Plus to read data in batches, cleans and standardizes the data with FastJson tool, completes the data asset sorting, forms a unified data resource catalog, stores it in the data_resource table of MySQL, and caches the basic data information (such as data name and business domain) in Redis.

[0083] S2, the privacy classification modeling module is based on a preset multi-dimensional privacy classification standard. It uses Java reflection mechanism to extract data attribute features, calculates data classification by weight, labels each type of data with classification tags, establishes association mapping, and synchronously stores it in the privacy_level table of MySQL and Redis cache. For specific implementation details, please refer to the above embodiment, which will not be repeated here.

[0084] S3, the dynamic desensitization strategy engine module, establishes matching logic between desensitization strategies and request contexts based on preset desensitization rules corresponding to each level, stores the information in the MySQL desensitization_rule table and Redis cache, and sends the strategy information to the middle platform resource scheduling module through the RabbitMQ data_access_queue queue, ensuring that the middle platform resource scheduling module can quickly obtain the desensitization strategy.

[0085] In S4, ordinary users of the CRM system send customer information query requests via RESTful API. The middle platform resource scheduling module parses the request context and performs permission verification through Spring Security. After successful verification, the request and customer data (such as mobile phone number and name) are forwarded to the dynamic de-identification strategy engine module. The dynamic de-identification strategy engine module reads the de-identification strategy from Redis, matches the corresponding rules, and performs de-identification operations (such as partial masking of mobile phone number and SM4 encryption of name).

[0086] S5, the dynamic data masking strategy engine module will mask the data (e.g., 138) 5678 (encrypted name) is fed back to the middle platform resource scheduling module, which then asynchronously feeds back to the CRM system via RabbitMQ; at the same time, the access control and auditing module records access logs through Logback, stores them in the audit_log table, and displays the logs through the ELK platform to form an audit ledger.

[0087] In S6, the privacy classification modeling module detects adjustments to customer name classifications (such as changing from ordinary privacy level to core privacy level), updates classification tags, synchronizes them to MySQL and Redis, and pushes update messages to RabbitMQ; the dynamic de-identification strategy engine module receives messages and updates the de-identification rule base (such as adjusting name de-identification rules to national cryptographic SM4 encryption); the access control and auditing module analyzes audit logs and discovers that ordinary users frequently request core privacy data, optimizes permission configurations, restricts the frequency of ordinary users' access to core privacy data, and further improves data security.

[0088] It should be noted that by deploying the above system and implementing the corresponding management methods, the fintech company achieved data platform management, privacy classification control, and dynamic anonymization. The verification results are as follows: Data security management: Core privacy data (ID card number, bank card number) is encrypted and de-identified using the domestic commercial encryption algorithm SM4, which meets national data security compliance and domestic substitution requirements. Ordinary privacy data is partially masked, and non-privacy data is shared normally. No data leakage has occurred, which meets the compliance requirements of the Personal Information Protection Law and the Guidelines for Data Security Classification of Financial Data Security.

[0089] System response efficiency: Compared with existing static data masking systems, this application embodiment reduces the data access response time from 500ms to less than 80ms by using Redis to cache high-frequency data and employing data masking strategies; at the same time, it achieves asynchronous communication through RabbitMQ to avoid system blocking and can be adapted to high-concurrency access scenarios in enterprises.

[0090] Data management efficiency: It eliminates data silos from ERP, CRM, and OA systems, enabling unified data access and management, reducing data governance costs, and automating privacy grading and dynamic desensitization, thereby reducing manual intervention and improving management efficiency.

[0091] Controllable permissions and auditing: Based on Spring Security, permission management enables precise authorization for different roles. The ELK log analysis platform enables full traceability of access and de-identification operations, and abnormal behavior can be quickly alerted and handled, improving system security.

[0092] This application also provides a computer device, which may specifically be a personal computer, a server, a network device, etc. Figure 7 As shown, the computer device includes a bus, a processor, memory, and a communication interface, and may also include an input / output interface and a display device. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores location information. The network interface allows communication with external terminals via a network connection. When the computer program is executed by the processor, it implements the steps in the above method embodiments.

[0093] Those skilled in the art will understand that Figure 7 The structure shown is only a part of the structure related to the solution of this application and does not constitute a limitation on the computer device on which the solution of this application is applied. The specific computer device may include more or fewer components, or combine certain components, or have different component arrangements.

[0094] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, having stored thereon a computer program that, when executed by a processor, implements the steps in the above method embodiment.

[0095] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the method embodiments described above.

[0096] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, graphics processors, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

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

[0098] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A platform-based data resource management system based on dynamic hierarchical data anonymization, characterized in that, include: The privacy classification modeling module is used to acquire multi-source data, generate data privacy classification labels based on preset multi-dimensional classification standards and the multi-source data, and perform privacy classification annotation on the multi-source data. The middle platform resource scheduling module is communicatively connected to the privacy classification modeling module, the dynamic de-identification strategy engine module, and the access control and auditing module, respectively. It is used to receive data access requests initiated by the business system, obtain the data privacy classification label, call the dynamic de-identification strategy engine module to perform de-identification operation, and trigger the access control and auditing module to perform permission verification and auditing records. The dynamic de-identification strategy engine module is also connected to the privacy classification modeling module. It is used to match and execute the corresponding de-identification strategy based on the data privacy classification label and the request context when the data access request is executed, to obtain the de-identified data, and return the de-identified data to the middle platform resource scheduling module so that the middle platform resource scheduling module can feed the de-identified data back to the business system. The access control and auditing module is also connected to the dynamic de-identification strategy engine module to perform permission verification on the data access request, receive and record the data access records reported by the middle platform resource scheduling module, and the de-identification operation logs reported by the dynamic de-identification strategy engine module, so as to form audit traceability information. The audit traceability information is used to trace behavior, analyze anomalies and conduct compliance review of the entire process of data access and de-identification operation.

2. The system according to claim 1, characterized in that, The privacy-level modeling module includes: A data access unit is used to access the database of a multi-source business system and obtain the multi-source data. The classification and determination unit is used to determine the privacy level of the multi-source data by weighted calculation based on the multi-dimensional classification standard. The privacy level includes core privacy level, ordinary privacy level and non-privacy level. The multi-dimensional classification standard includes data sensitivity, compliance requirements, business importance and scope of impact of leakage. The labeling unit is used to label the multi-source data with corresponding privacy-level labels and establish an association mapping between the multi-source data and the privacy-level labels. The privacy-level labels include core privacy-level labels, ordinary privacy-level labels, and non-privacy-level labels.

3. The system according to claim 2, characterized in that, The dynamic desensitization strategy engine module includes: The policy configuration unit is used to configure the de-identification policies corresponding to each privacy level, forming a de-identification policy library; The request parsing unit is used to receive the data access request forwarded by the middle platform resource scheduling module and extract the request context of the data access request. The request context includes at least one of the following: access user role, access application scenario, access time, data usage purpose, and access terminal information. The strategy matching unit is used to match the corresponding de-identification strategy from the de-identification strategy library based on the data privacy classification label and the request context; The de-identification execution unit is used to perform de-identification operations on the multi-source data based on the matched de-identification strategy to obtain de-identified data; The policy update unit is used to receive privacy level update messages from the privacy classification modeling module and update the de-identification policy library.

4. The system according to claim 1, characterized in that, The access control and auditing module includes: The permission verification unit is used to verify whether the entity that initiates the data access request has access rights to the target data, wherein the target data is the data resource requested to be accessed by the data access request. The log recording unit is used to record data access logs, de-identification operations, and data flow logs; The anomaly alarm unit is used to monitor access behavior in real time and generate alarm information; An alarm push unit is used to push the alarm information to the management terminal.

5. The system according to claim 1, characterized in that, The platform-based data resource management system uses JDK17 and Spring Boot 3.2 as its basic technology stack, and is equipped with caching middleware, message queue middleware and log analysis middleware.

6. The system according to claim 5, characterized in that, The caching middleware is Redis, the message queue middleware is RabbitMQ, and the log analysis middleware is ELK.

7. The system according to claim 1, characterized in that, When performing the desensitization operation, the dynamic desensitization strategy engine module uses the national cryptographic SM4 algorithm to encrypt and desensitize privacy data that meets the preset sensitivity level conditions. The privacy data that meets the preset sensitivity level conditions includes: data whose privacy classification label reaches or exceeds the preset level threshold, and / or data containing personal identification information.

8. The system according to claim 1, characterized in that, The privacy classification modeling module is also used to monitor changes in data resources and / or compliance policies, and based on the changes in data resources and / or compliance policies, update the multi-dimensional classification standard, and synchronously update the data privacy classification label, and synchronize the updated data privacy classification label to the middle platform resource scheduling module and / or the dynamic de-identification strategy engine module. The dynamic desensitization strategy engine module is also used to update the corresponding desensitization strategy based on the updated data privacy classification label.

9. The system according to claim 1, characterized in that, The middleware resource scheduling module is also used to return the de-identified data received from the dynamic de-identification strategy engine module to the business system that initiated the data access request.

10. A platform-based data resource management method based on dynamic hierarchical desensitization, applied to the system described in any one of claims 1 to 9, characterized in that, include: The privacy classification modeling module acquires multi-source data, generates data privacy classification labels based on preset multi-dimensional classification standards and the multi-source data, and performs privacy classification annotation on the multi-source data. When the platform resource scheduling module receives a data access request from the business system, it obtains the data privacy classification label and triggers the access control and audit module to perform permission verification. After the permission verification is passed, the middle platform resource scheduling module calls the dynamic de-identification strategy engine module. The dynamic de-identification strategy engine module matches the corresponding de-identification strategy and executes it based on the data privacy classification label and the request context when the data access request is executed, so as to obtain the de-identified data and return the de-identified data to the business system. The access control and auditing module receives and records the data access records reported by the middle platform resource scheduling module and the de-identification operation logs reported by the dynamic de-identification strategy engine module, forming audit traceability information to conduct behavior traceability, anomaly analysis and compliance review of the entire process of data access and de-identification operation.

Images