Big data security storage and backup method based on hierarchical authority

Abstract

The invention discloses a big data security storage and backup method based on hierarchical authority, and relates to the technical field of data storage and backup, and the method comprises the steps: S1, constructing a user access behavior collection module, and collecting the access time, data access frequency, operation type, terminal environment information and access IP address when a user accesses a big data system in real time; by constructing the user access behavior portrait model, dynamic linkage of the authority and the user real-time behavior is realized, the problem of authority distribution rigidness in the prior art is solved, the data leakage risk caused by over-wide authority is avoided, the service efficiency under the compliance behavior is guaranteed, and the user experience is improved. A differential key generation and verification mechanism is matched for different permission levels, a fixed key form is replaced, the key leakage risk is reduced, safety and usability are both considered, and collaborative optimization of permission change and data storage and backup is achieved by designing a storage and differential backup strategy matched with dynamic permission.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data storage and backup, in particular to a big data security storage and backup method based on hierarchical permissions. BACKGROUND

[0002] Big data refers to a large-scale, multi-type, fast-flowing and high-value massive data set, covering business data, user information and other core content in multiple fields such as government affairs, finance and medical treatment. Deep mining and reasonable application of big data can provide data support for enterprise decision-making and provide direction for public service optimization, which is of great significance to promote industry upgrading and improve social operation efficiency. Big data security storage and backup is the core link to ensure the safety of big data throughout its life cycle. It realizes the confidentiality, integrity and availability of big data in the storage process through a series of technical means, and prevents data loss, damage and other risks through backup mechanism to ensure that data can be quickly recovered in the event of sudden failure, malicious attack and other situations. This link is not only the key to protect data assets, but also the important basis for maintaining business continuity and complying with data security related regulations.

[0003] However, the prior art still has some defects. The hierarchical permission allocation is mostly based on preset roles, lacks dynamic linkage with user real-time access behavior, cannot flexibly adjust permissions according to user behavior compliance, is prone to cause data leakage due to excessive permissions or affect business efficiency due to strict permissions, and the permissions and key management are disconnected, mostly using fixed key form, with high risk of key leakage, and different permission levels are not matched with differentiated key verification mechanism, which is difficult to balance security and ease of use, and the corresponding storage and backup coordination strategy is not designed for dynamically adjusted permissions based on user behavior, which cannot realize the adaptation of permission change and data storage security and backup efficiency, affecting the overall data security protection effect. Therefore, it is of great significance to develop a big data security storage and backup method based on hierarchical permissions. SUMMARY

[0004] The purpose of the present application is to overcome the shortcomings of the prior art and provide a big data security storage and backup method based on hierarchical permissions. It can build a user access behavior portrait model to realize dynamic linkage between permissions and user real-time behavior, avoid data leakage risk caused by excessive permissions, ensure business efficiency under compliant behavior, match differentiated key generation and verification mechanism for different permission levels, replace fixed key form, reduce key leakage risk, balance security and ease of use, design storage and differentiated backup strategies adapted to dynamic permissions, realize collaborative optimization of permission change and data storage and backup, and improve the overall protection capability of big data security storage and backup.

[0005] The application provides the following technical scheme to solve the above technical problems: a big data security storage and backup method based on hierarchical authority, which comprises the following steps: S1, a user access behavior collection module is constructed to collect access time, data access frequency, operation type, terminal environment information and access IP address when the user accesses the big data system in real time; S2, a user access behavior portrait model is constructed based on the collected data, the user access behavior compliance is judged through feature extraction and analysis, non-regular access to high-sensitive data of ordinary users is detected, the authority is degraded and an alarm is pushed to the administrator, regular access of the management layer in the trusted terminal and office IP range is detected, batch data viewing authority is temporarily opened and the authority validity period is adjusted according to the subsequent behavior compliance; S3, a hierarchical key management module is established, the keys are generated for core authority users in a combination of biological characteristics and hardware keys, the keys are generated for ordinary authority users in a lightweight dynamic token, the keys are generated for basic authority users in a dynamic password, and the keys are stored in combination with the user authority level; S4, a heterogeneous storage cluster is configured according to the current authority level of the user, high-sensitive data is stored in a private distributed storage cluster and is independently encrypted after data block and binding with the user unique identifier, medium-sensitive data is stored in a hybrid cloud storage cluster, and low-sensitive data is stored in a public cloud cluster; when the user authority is changed, the corresponding data is automatically migrated to the matching storage cluster; S5, backup strategies are formulated for data sources corresponding to different authority levels, high-sensitive data is backed up in real time with multiple copies and is synchronized to a remote disaster recovery node through two independent network links, medium-sensitive data is incrementally backed up with differential verification, and low-sensitive data is periodically backed up in batches; the recovery authority of the backup data is bound with the original data authority.

[0006] Further, when the user access behavior portrait model is constructed and the user access behavior compliance is judged in the step S2, the following steps are included: The collected access time data is regularly analyzed to identify the user's regular access period and abnormal period; The operation type frequency is counted to determine whether the high-sensitive data operation exceeds the user's daily business range; It is verified whether the device identifier in the terminal environment information is in the system preset trusted device list, whether the security patch is updated to the latest version, and whether the access IP address belongs to the office IP segment; The above results are comprehensively judged to determine the user access behavior compliance and execute corresponding authority adjustment operation.

[0007] Further, when the keys are generated for users with different authority levels in the step S3, the key generation for core authority users includes the following steps: Collecting the user's biological feature data and comparing it with the system's pre-stored biological feature template, after the comparison, the hardware key device receives the random seed value sent by the system; The hardware key device generates a dynamic key based on the random seed value and feeds it back to the hierarchical key management module; The hierarchical key management module binds the generated dynamic key to the user's core permission level and stores it; For ordinary permission users, the dynamic token updates the token value every pre-set time interval when generating the key, and the user generates the key by inputting the token value combined with the account password. For basic permission users, the system sends a temporary password to the user through SMS or email when generating the dynamic password, and the user inputs the temporary password combined with the fixed password to generate the key.

[0008] Further, when executing the differentiated backup strategy in step S5, the backup of high-sensitive data includes the following steps: When the data changes, the system captures the changed data segments in real time, and in the second step, the changed data segments are transmitted through two independently configured network links, one of which is a dedicated data backup optical fiber link, and the other is a backup wireless transmission link; The changed data segments transmitted by the two links are respectively stored in two independent storage partitions of the off-site disaster recovery node; At a fixed time every day, two core permission administrators log in to the off-site disaster recovery node system respectively, and perform consistency verification on the backup data in the two storage partitions. Verification requires two people to input their respective keys to complete identity authentication before starting the verification program; For the scheduled incremental backup of medium-sensitive data, set to capture data changes every hour and store them. At dawn every day, all incremental backup data and original data of the day are compared for full difference, and the difference data location is recorded and marked for correction.

[0009] Further, the user access behavior collection module in step S1 is deployed at the access gateway of the big data system, and the module has a built-in data filtering unit that automatically filters redundant fields in terminal environment information that are not related to security when collecting data, retaining only device identification, operating system type, and security patch status. At the same time, the module is synchronized with the system clock to ensure that the access time data collected has an error of no more than a pre-set range from the system time.

[0010] Furthermore, when user permission changes trigger data migration in step S4, the system first performs integrity verification on the data to be migrated. After the verification passes, a data migration list is generated, which includes the data identifier, original storage location, target storage location, and encryption status. Then, the data is transmitted to the target storage cluster according to the migration list. End-to-end encryption is used during the transmission process. After the data arrives at the target storage cluster, integrity verification is performed again and the data is re-encrypted and bound to the current user's unique identifier. After the verification passes, the corresponding data in the original storage cluster is deleted and a migration log is recorded.

[0011] Furthermore, after the key is bound to the user permission level in step S3, the hierarchical key management module periodically performs security checks on the stored key. The checks include the integrity of the key storage file and whether there are any unauthorized access traces. When the user permission level changes, the hierarchical key management module automatically invalidates the original key and regenerates and binds the key according to the key generation method corresponding to the changed permission level. The invalidated original key is added to the key blacklist and is no longer used for authentication.

[0012] Furthermore, the binding of backup data recovery permissions with original data permissions in step S5 specifically involves the following: when a user requests to restore backup data, the system first verifies whether the user's current permission level is consistent with the original permission level corresponding to the backup data. If the user's current permission level is consistent with the original permission level corresponding to the backup data, the system further verifies the user's identity information. After the identity information verification is successful, the system generates a recovery task order. The recovery task order includes the backup data identifier, the recovery target location, and the recovery time. The system executes the recovery operation according to the recovery task order and sends a recovery completion notification to the user and the administrator after the recovery is completed.

[0013] Furthermore, the temporarily granted batch data viewing permission in step S2 has a maximum data viewing limit. When the amount of data viewed by the management level through the temporary permission reaches the limit, the system automatically suspends the data viewing function and sends a reminder to the management level. When the management level needs to continue viewing, it needs to submit a permission extension application to the administrator. After the administrator approves the application, the maximum data viewing limit of the temporary permission is adjusted and the data viewing function is reactivated. The permission extension application and the approval result are recorded in the permission operation log.

[0014] Compared with existing technologies, this big data security storage and backup method based on hierarchical permissions has the following advantages: This invention constructs a user access behavior profile model to achieve dynamic linkage between permissions and real-time user behavior, solving the problem of rigid permission allocation in existing technologies. It avoids the risk of data leakage caused by overly broad permissions while ensuring business efficiency under compliant behavior. By matching differentiated key generation and verification mechanisms to different permission levels, it replaces the fixed key form, reducing the risk of key leakage and balancing security and ease of use. Through the design of storage and differentiated backup strategies adapted to dynamic permissions, it achieves coordinated optimization of permission changes and data storage and backup, ensuring that data storage security and backup efficiency are matched, improving the overall protection capability of big data security storage and backup, and ensuring the security, integrity, and availability of data assets.

[0015] Other advantages, objectives and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination or study, or may be learned from the practice of the invention. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a method for secure storage and backup of big data based on hierarchical permissions; Figure 2 This is a flowchart of a big data security storage and backup method based on hierarchical permissions; Figure 3 This is a flowchart illustrating the key generation process for core privilege users in a hierarchical big data security storage and backup method. Detailed Implementation

[0018] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structure, features and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below.

[0019] This invention provides a method for secure storage and backup of big data based on hierarchical access control. See also... Figure 1 , Figure 2 and Figure 3 The core content is as follows: This solution comprises five core steps: building a user access behavior collection module, which is deployed at the big data system access gateway to collect access time, data access frequency, operation type, terminal environment information, and access IP address in real time; filtering redundant fields during collection; and synchronizing the system clock to ensure time accuracy.

[0020] Based on the collected data, a user access behavior profile model is constructed. Compliance is determined by analyzing access time patterns, operation types, terminal environment trustworthiness, and IP address compliance. When ordinary users irregularly access highly sensitive data, permission downgrades and alerts are triggered. When management regularly accesses data from trusted terminals and office IPs, temporary batch viewing permissions with a data volume limit are granted, and the validity period of these permissions is adjusted according to compliance requirements.

[0021] A tiered key management module is established to generate differentiated keys according to preset permission levels. Core-level users generate keys using a combination of biometrics and hardware keys; ordinary-level users generate keys using a combination of a lightweight dynamic token and their account password; and basic-level users generate keys using a combination of a temporary password and a fixed password. Keys are stored in a manner that is bound to permission levels, and the original key is invalidated and a new key is generated when permissions change.

[0022] Configure heterogeneous storage clusters according to permission levels. High-sensitivity data is stored in a private distributed storage cluster and encrypted in blocks and bound to user identifiers. Medium-sensitivity data is stored in a hybrid cloud cluster. Low-sensitivity data is stored in a public cloud cluster. Data is automatically migrated when permissions change. The migration process is verified for integrity and encrypted end-to-end. After migration, the original data is deleted and logged.

[0023] Implement differentiated backup strategies. Highly sensitive data is backed up in real-time with multiple copies, synchronized to an off-site disaster recovery node via two independent network links, requiring dual-key verification for consistency. Medium-sensitive data is backed up incrementally on a regular schedule with daily differential verification. Low-sensitive data is backed up in batches periodically. Data recovery requires verification of the user's current and original permissions and identity information. Notifications are sent to both the user and administrator upon successful recovery.

[0024] The entire solution achieves secure collaborative optimization of data storage and backup through dynamic permission adjustment, hierarchical key management, heterogeneous storage adaptation, and differentiated backup.

[0025] Example 1 This embodiment is applied to a big data security storage and backup scenario in the financial industry. The financial industry involves a large amount of highly sensitive data such as customer account information and transaction data, and there are differentiated access needs for data from different levels of users (such as core management, general business personnel, and basic maintenance personnel). Existing fixed permission allocation methods easily lead to a mismatch between permissions and actual business needs. Either overly broad permissions cause data leakage risks, or overly strict permissions affect business processing efficiency. Furthermore, fixed key methods have a high risk of leakage and cannot meet the high security and high availability requirements of financial data. Therefore, the big data security storage and backup method based on hierarchical permissions of this invention has significant application value in this scenario. See [link to relevant documentation]. Figure 1 and Figure 2 The specific details are as follows: First, a user access behavior collection module was built and deployed at the access gateway of the financial big data system. This module has a built-in data filtering unit that collects access time, data access frequency, operation type, terminal environment information, and access IP address in real time when a user accesses the system. During the collection process, redundant fields unrelated to security in the terminal environment information are automatically filtered out, retaining only device identifiers, operating system types, and security patch status. Simultaneously, the module is synchronized with the system clock to ensure that the collected access time data and system time error are controlled within a preset range, providing an accurate data foundation for subsequent behavior compliance analysis.

[0026] Next, a user access behavior profile model is built based on the collected data. First, the access time data is analyzed for patterns to identify regular and abnormal access periods. Then, the frequency of operation types is counted to determine whether the user's operations on highly sensitive financial data (such as customer account balances and transaction records) exceed the scope of daily business. Subsequently, the device identifier in the terminal environment information is verified to ensure it is in the system's preset trusted device list, that security patches are updated to the latest version, and that the access IP address belongs to the financial institution's office IP segment.

[0027] Based on the above analysis results, in the specific implementation of this embodiment, a behavior compliance score is used to quantitatively calculate and determine the compliance of access behavior. The calculation method is as follows: ,in, Assign compliance scores to user access behavior. This is the access time regularity coefficient, with a value of 1 during normal access periods and a value of 0 during abnormal access periods. For operation type compliance coefficients, highly sensitive data operations are assigned a value of 1 within the scope of daily business operations, and a value of 0 outside the scope. The terminal environment trust factor is set to 1 if the device is listed in the trust list and its security patches are updated to the latest version; otherwise, it is set to 0. This is the IP address compliance coefficient; a value of 1 is assigned to the office IP range, and a value of 0 is assigned otherwise. , , , The weights for each dimension are obtained by training a machine learning algorithm on historical compliant access behavior samples in the financial industry and optimized in combination with the differences in financial data security requirements.

[0028] When the system detects that ordinary business personnel are accessing highly sensitive data irregularly, it automatically triggers a downgrade of permissions and pushes an alarm message to the administrator. When the system detects that core management personnel are regularly accessing data within the trusted terminal and office IP range, it temporarily grants batch data viewing permissions. The validity period of this permission is dynamically extended and retracted according to the compliance of subsequent behaviors. At the same time, the temporary permission has a maximum data viewing limit. When the limit is reached, the system suspends the viewing function and issues a reminder. The system requires the submission of a permission extension application, which is reactivated after being approved by the administrator. The relevant application and approval results are recorded in the permission operation log.

[0029] Then, a hierarchical key management module is established, and key generation methods are divided according to preset permission levels. For core-level users, such as senior executives of financial institutions, their biometric data is collected and compared with pre-stored biometric templates in the system. In the specific implementation of this embodiment, the comparison uses a weighted similarity algorithm, and the formula is as follows: ,in, The overall similarity is calculated based on biological characteristics. This refers to the number of dimensions in a biometric feature, such as the number of minutiae in a fingerprint or the dimension of a facial feature vector. For the first Weights of each feature dimension, For the first Single-dimensional similarity of each feature dimension; weight The discrimination of each dimension was determined by analyzing historical biometric verification data.

[0030] After successful verification, the hardware key device of a core-level user receives a random seed value sent by the system, generates a dynamic key based on this value, and feeds it back to the hierarchical key management module. The module binds and stores the dynamic key with the user's core privilege level. For ordinary-level users, such as business supervisors, a lightweight dynamic token is used to generate the key. The dynamic token updates its value every preset interval, and the user inputs the token value and combines it with their account password to generate the key. For basic-level users, such as frontline maintenance personnel, the system sends a temporary password via SMS or email, and the user inputs the temporary password and combines it with a fixed password to generate the key. The hierarchical key management module periodically performs security checks on the stored keys, including the integrity of the key storage file and the presence of unauthorized access traces. When a user's privilege level changes, the original key is automatically invalidated and added to the blacklist, and a new key is generated and bound to the storage according to the method corresponding to the changed privilege level.

[0031] Next, a heterogeneous storage cluster is configured based on the user's current permission level. High-sensitivity financial data is stored in a private distributed storage cluster, with data blocks independently encrypted and bound to a unique user identifier; medium-sensitivity data is stored in a hybrid cloud storage cluster; and low-sensitivity data is stored in a public cloud cluster. When user permissions change, the system first performs an integrity check on the data to be migrated. After the check passes, a data migration list is generated, containing data identifiers, original storage locations, target storage locations, and encryption status. Data is then transmitted to the target storage cluster via end-to-end encryption according to the list. Upon arrival, the data undergoes another integrity check and is re-encrypted and bound to the current user's unique identifier. After the check passes, the corresponding data in the original storage cluster is deleted, and a migration log is recorded. See [link to relevant documentation]. Figure 3 .

[0032] Finally, differentiated backup strategies were developed for data sources corresponding to different permission levels. Highly sensitive financial data employed real-time backup plus multiple copies. When data changes, the system captures the changed data fragments in real time and transmits them to the off-site disaster recovery node via two independent network links: a dedicated data backup fiber optic link and a backup wireless transmission link. The data is then stored in two independent storage partitions. At fixed times each day, two core-level administrators log into the off-site disaster recovery node system, enter their respective keys to complete authentication, and then initiate a consistency verification process. Specifically, the verification uses a hash-weighted verification algorithm, the formula of which is... ,in, This is the final backup integrity check value. The hash value for data transmitted via a dedicated fiber optic link. The hash value for data transmitted via the backup wireless link. , These are the weighting coefficients for the two link data, which are determined based on the historical transmission stability data of the links.

[0033] Medium-sensitive data is backed up using a combination of scheduled incremental backups and differential verification. Changes are captured and stored hourly, and a full comparison is performed daily at midnight on all incremental backups and the original data, recording the location of discrepancies and marking items requiring correction. Low-sensitivity data is backed up periodically in batches. Recovery permissions for backup data are tied to permissions for the original data. When a user requests recovery, the system first verifies if the user's current permission level matches the original permission level corresponding to the backup data. If they match, the system further verifies the user's identity information. Upon successful verification, a recovery task order is generated, containing the backup data identifier, the target recovery location, and the recovery time. The recovery operation is executed according to the task order, and a recovery completion notification is sent to the user and administrator upon completion.

[0034] In summary, this embodiment, through its specific application in the financial industry, achieves dynamic linkage between permissions and real-time user access behavior, effectively avoiding data leakage risks or low business efficiency caused by unreasonable permission allocation; the differentiated key generation and verification mechanism reduces the risk of key leakage, balancing security and ease of use; and the storage and backup strategy adapted to dynamic permissions achieves coordinated optimization of permission changes and data storage and backup, ensuring the confidentiality, integrity, and availability of big data in the financial industry, and providing strong data security support for the stable operation of financial businesses.

[0035] Example 2 This embodiment is applied to a big data security storage and backup scenario in the medical industry. The medical industry encompasses highly sensitive and private data such as patient electronic medical records, examination and test reports, and genetic testing data. Simultaneously, there are differentiated access needs for data from different levels of users, including medical staff, administrative personnel, and researchers. Existing technologies with fixed permission allocation are ill-suited to the dynamic business needs of medical scenarios. For example, emergency room medical staff need to repeatedly apply for permissions to temporarily access patient medical records from different departments, impacting treatment efficiency. Fixed key systems are prone to key management chaos due to staff rotation and handover, posing a risk of data leakage. These methods fail to meet the multiple requirements of medical data security, timeliness, and compliance. Therefore, the big data security storage and backup method based on hierarchical permissions of this invention has crucial application significance in this scenario. See [link to relevant documentation]. Figure 1 and Figure 2 The specific details are as follows: First, a user access behavior collection module was constructed and deployed at the access gateway of the medical big data system. This module has a built-in data filtering unit that collects access time, data access frequency, operation type, terminal environment information, and access IP address in real time when a user accesses the system. During the collection process, redundant fields unrelated to security in the terminal environment information are automatically filtered out, retaining only device identifiers, operating system types, and security patch status. Simultaneously, the module is synchronized with the system clock to ensure that the collected access time data and system time error are controlled within a preset range, providing accurate data support for subsequent behavioral compliance analysis in medical scenarios.

[0036] Next, based on the user access behavior profiling model constructed in the aforementioned embodiments, the compliance judgment logic is optimized in combination with the characteristics of the medical industry. First, the access time data is analyzed for patterns to identify the regular outpatient hours of medical staff, the office hours of administrative staff, and abnormal times. Then, the frequency of operation types is statistically analyzed to determine whether operations on highly sensitive medical data such as patient electronic medical records and genetic data comply with the diagnostic or management needs of the position. Subsequently, it is verified whether the device identifier in the terminal environment information is within the hospital's preset trusted device list, whether the security patch is updated to the latest version, and whether the access IP address belongs to the hospital's intranet or the designated medical collaboration platform IP segment. Based on the above analysis results, in the specific implementation process of this embodiment, a behavior compliance score is used to quantitatively calculate and determine the compliance of access behavior. The calculation method is as follows: .

[0037] When the system detects that regular medical staff access highly sensitive patient medical records from other departments outside of their designated treatment hours, it automatically triggers a downgrade of permissions and sends an alert to the department administrator and the IT department. When the system detects that emergency medical staff urgently access cross-department patient data within the hospital's trusted terminals and intranet, it temporarily grants batch medical record viewing permissions. The validity period of these permissions is dynamically extended or retracted as the emergency treatment process progresses and subsequent compliance is assessed. The temporary permissions have a maximum data viewing limit. When the limit is reached, the system suspends the viewing function and sends a reminder. The system requires submitting a permission extension application, which must be approved by the department head before reactivation. The relevant application and approval results are recorded in the medical data permission operation log.

[0038] Then, a hierarchical key management module is established, classifying key generation methods according to user permission levels in the healthcare industry. For core-level users, such as the head of the hospital's information department and department directors, their biometric data is first collected and compared with pre-stored biometric templates in the system. In this specific implementation, a weighted similarity algorithm is used for comparison, and the formula is as follows: .

[0039] After successful verification, the hardware key device of core-level users receives a random seed value sent by the system, generates a dynamic key based on this value, and feeds it back to the hierarchical key management module. The module binds and stores the dynamic key with the user's core privilege level. For ordinary-level users, such as attending physicians and nurses, a lightweight dynamic token is used to generate the key. The dynamic token updates its value every preset time interval. The user inputs the token value and combines it with their employee ID password to generate the key. For basic-level users, such as interns and administrative assistants, the system sends temporary passwords through both hospital office system messages and SMS. The user inputs the temporary password and combines it with a fixed password to generate the key.

[0040] The hierarchical key management module periodically performs security checks on the stored keys, including the integrity of the key storage file and whether there are any unauthorized access traces. When a user's position is changed or they leave the company, the original key is automatically invalidated and added to the blacklist. A new key is generated and bound to the storage according to the method corresponding to the changed permission level.

[0041] Then configure the heterogeneous storage cluster according to the user's current permission level, see [link / reference]. Figure 3 High-sensitivity medical data is stored in the hospital's private distributed storage cluster. After data is segmented, it is independently encrypted and bound to a unique user ID. Medium-sensitivity medical data is stored in a dedicated medical hybrid cloud storage cluster. Low-sensitivity medical data is stored in a public cloud cluster. When user permissions change, the system first performs an integrity check on the data to be migrated. After the check passes, a data migration list is generated, including the data identifier, original storage location, target storage location, and encryption status. The data is then transmitted to the target storage cluster via end-to-end encryption according to the list. Upon arrival, the data undergoes another integrity check and is re-encrypted and bound to the current user's unique identifier. After the check passes, the corresponding data in the original storage cluster is deleted, and a migration log is recorded.

[0042] Finally, differentiated backup strategies were developed for medical data sources corresponding to different permission levels. Highly sensitive medical data was backed up in real-time with multiple copies. When data changes occurred, the system captured the changed data fragments in real time and transmitted them to the off-site disaster recovery node via two independent network links: a dedicated hospital data backup fiber optic link and a backup 5G private network link. The data was then stored in two separate storage partitions. At fixed times each day, two core-permission administrators logged into the off-site disaster recovery node system, entered their respective keys to complete authentication, and then initiated a consistency verification process. In this specific implementation, the verification used a hash-weighted verification algorithm, the formula of which is... .

[0043] Medium-sensitivity medical data is backed up using a timed incremental backup and difference verification method. Data changes are captured and stored every two hours. Every morning, a full comparison is performed between all incremental backups and the original data, recording the location of discrepancies and marking items requiring correction. Low-sensitivity medical data is backed up daily in batches. Recovery permissions for backup data are bound to the permissions for the original data. When a user requests recovery, the system first verifies if the user's current permission level matches the original permission level corresponding to the backup data. If they match, the system further verifies the user's identity information. Upon successful verification, a recovery task order is generated, containing the backup data identifier, the target recovery location, and the recovery time. The recovery operation is executed according to the task order. After recovery is complete, a recovery completion notification is sent to the user, department administrator, and IT department.

[0044] In summary, this embodiment, through its specific application in the medical industry, builds upon the aforementioned embodiments to achieve dynamic adaptation of permissions and real-time user diagnosis and treatment behavior in medical scenarios. This not only ensures the privacy and security of patient data but also meets the needs for rapid data access in scenarios such as emergency rooms. Differentiated key management adapts to the characteristics of medical personnel's roles, reducing security risks caused by chaotic key management. Storage and backup strategies that match the sensitivity of medical data ensure the secure storage and efficient recovery of medical data in scenarios involving changes in permissions, complying with the data security regulations of the medical industry and providing reliable data security guarantees for the standardized operation of medical services.

[0045] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for secure storage and backup of big data based on hierarchical access control, characterized in that, The method includes the following steps: S1. Construct a user access behavior collection module to collect in real time the user's access time, data access frequency, operation type, terminal environment information and access IP address when accessing the big data system; S2. Based on the collected data, construct a user access behavior profile model, and judge the compliance of user access behavior through feature extraction and analysis. If the irregular access of ordinary users to highly sensitive data is detected, the permission will be downgraded and an alarm will be pushed to the administrator. If the management is detected to be regularly accessing the trusted terminal and office IP range, the batch data viewing permission will be temporarily granted and the validity period of the permission will be extended and extended according to the compliance of subsequent behaviors. S3. Establish a hierarchical key management module, which divides users into preset permission levels. For core permission users, keys are generated by combining biometrics and hardware keys. For ordinary permission users, keys are generated by lightweight dynamic tokens. For basic permission users, keys are generated by dynamic passwords. Keys are stored in a binding manner with user permission levels. S4. Configure heterogeneous storage clusters according to the user's current permission level. High-sensitivity data is stored in a private distributed storage cluster and the data is independently encrypted and bound to the user's unique identifier after being divided into blocks. Medium-sensitivity data is stored in a hybrid cloud storage cluster and low-sensitivity data is stored in a public cloud cluster. When the user's permissions change, the corresponding data is automatically migrated to the matching storage cluster. S5. Develop backup strategies for data sources corresponding to different permission levels. Highly sensitive data is backed up in real time with multiple copies and synchronized to the off-site disaster recovery node through two independent network links. Mediumly sensitive data is backed up at regular intervals with differential verification. Lowly sensitive data is backed up in batches at regular intervals. The recovery permissions of the backup data are bound to the permissions of the original data.

2. The method for secure storage and backup of big data based on hierarchical permissions according to claim 1, characterized in that, When constructing the user access behavior profile model and determining the compliance of user access behavior in step S2, the following steps are included: Perform pattern analysis on the collected access time data to identify regular and abnormal access periods for users; Analyze the frequency of statistical operation types to determine whether highly sensitive data operations exceed the scope of users' daily business operations; Verify whether the device identifier in the terminal environment information is in the system's preset trusted device list, whether the security patch is updated to the latest version, and confirm whether the access IP address belongs to the office IP segment; Based on the above results, the user's access behavior was determined to be compliant, and the corresponding permission adjustment operation was performed.

3. The method for secure storage and backup of big data based on hierarchical permissions according to claim 1, characterized in that, In step S3, when generating keys for users with different permission levels, the key generation for core permission users includes the following steps: The system collects user biometric data and compares it with the biometric templates stored in the system. After the comparison is successful, the hardware key device receives a random seed value sent by the system. The hardware key device generates a dynamic key based on a random seed value and feeds it back to the hierarchical key management module. The hierarchical key management module binds and stores the generated dynamic key with the user's core permission level; When generating keys for lightweight dynamic tokens for users with ordinary privileges, the dynamic token value is updated every preset time interval. Users generate keys by combining the token value with their account password. When generating keys for dynamic passwords for users with basic privileges, the system sends a temporary password to the user via SMS or email. Users generate keys by combining the temporary password with their fixed password.

4. The method for secure storage and backup of big data based on hierarchical permissions according to claim 1, characterized in that, When implementing the differentiated backup strategy in step S5, the backup of highly sensitive data includes the following steps: When data changes, the system captures the changed data segments in real time. The second step is to transmit the changed data segments through two independently configured network links, one of which is a dedicated data backup fiber optic link and the other is a backup wireless transmission link. The changed data segments transmitted through the two links are stored in two independent storage partitions on the off-site disaster recovery node; At fixed times each day, two core-level administrators log into the off-site disaster recovery node system to perform consistency verification on the backup data in the two storage partitions. During the verification, both individuals must enter their respective keys to complete identity authentication before the verification process can be started. For timed incremental backups of sensitive data, the system is set to capture and store data changes every hour. Every day at midnight, a full comparison of all incremental backup data and the original data is performed, and the location of the differences is recorded and items to be corrected are marked.

5. A method for secure storage and backup of big data based on hierarchical permissions as described in claim 1, characterized in that, The user access behavior collection module in step S1 is deployed at the access gateway of the big data system. The module has a built-in data filtering unit that automatically filters out redundant fields unrelated to security in the terminal environment information when collecting data, retaining only the device identifier, operating system type and security patch status. At the same time, the module is synchronized with the system clock.

6. A method for secure storage and backup of big data based on hierarchical permissions according to claim 1, characterized in that, When user permission changes trigger data migration in step S4, the system first performs integrity verification on the data to be migrated. After the verification is passed, a data migration list is generated, which includes the data identifier, original storage location, target storage location, and encryption status. Then, the data is transmitted to the target storage cluster according to the migration list. End-to-end encryption is used during the transmission process. After the data arrives at the target storage cluster, integrity verification is performed again and the data is re-encrypted and bound to the current user's unique identifier. After the verification is passed, the corresponding data in the original storage cluster is deleted and the migration log is recorded.

7. A method for secure storage and backup of big data based on hierarchical permissions as described in claim 1, characterized in that, In step S3, after the key is bound to the user's permission level and stored, the hierarchical key management module periodically performs security checks on the stored key. The checks include the integrity of the key storage file and whether there are any unauthorized access traces. When the user's permission level changes, the hierarchical key management module automatically invalidates the original key and regenerates and binds the key according to the key generation method corresponding to the changed permission level. The invalidated original key is added to the key blacklist and is no longer used for authentication.

8. A method for secure storage and backup of big data based on hierarchical permissions according to claim 1, characterized in that, In step S5, the binding of backup data recovery permissions with original data permissions specifically involves the following steps: When a user requests to restore backup data, the system first verifies whether the user's current permission level is consistent with the original permission level corresponding to the backup data. If the user's current permission level is consistent with the original permission level corresponding to the backup data, the system further verifies the user's identity information. After the identity information verification is successful, the system generates a recovery task order. The recovery task order includes the backup data identifier, the recovery target location, and the recovery time. The system executes the recovery operation according to the recovery task order and sends a recovery completion notification to the user and the administrator after the recovery is completed.

9. A method for secure storage and backup of big data based on hierarchical permissions according to claim 1, characterized in that, In step S2, the temporarily granted batch data viewing permission has a maximum data viewing limit. When the amount of data viewed by the management level through the temporary permission reaches the limit, the system automatically suspends the data viewing function and sends a reminder to the management level. When the management level needs to continue viewing, it needs to submit a permission extension application to the administrator. After the administrator approves the application, the maximum data viewing limit of the temporary permission is adjusted and the data viewing function is reactivated. The permission extension application and the approval result are recorded in the permission operation log.

Images