Big data information security management method based on blockchain

Abstract

This invention discloses a blockchain-based big data information security management method, comprising: constructing a layered blockchain architecture, including a core chain and multiple sub-chains, wherein the core chain records the chain head hash value, data storage location, and access permissions of the sub-chains; collecting features of the data to be stored and generating a feature dataset by combining Geohash encoding; constructing a priority partitioning model based on a linear weighted algorithm and the TOPSIS algorithm to prioritize the data features in the feature dataset and generate priority scores; dynamically allocating the data to be stored to high-security-level sub-chains or low-security-level sub-chains through a cold / hot separation storage strategy; recording the data storage index and access permissions to the core chain; parsing user query requests using the core chain, distributing them to the corresponding sub-chains, where the sub-chains process the query requests in parallel and return the query results to the core chain; and verifying the user's access permissions through the core chain, and upon successful verification, reading the data stored in the corresponding sub-chain based on the query results.

Description

Technical Field

[0001] This invention relates to the technical field of blockchain and big data management, and in particular to a blockchain-based method for big data information security management. Background Technology

[0002] In big data application scenarios, the demand for generating, storing, and processing massive amounts of data is increasing day by day. How to improve storage efficiency and query performance while ensuring data security has become a research hotspot. Currently, using blockchain technology for data storage can not only enhance data security but also improve data credibility. However, traditional blockchain faces problems of low storage efficiency and insufficient query performance when dealing with massive amounts of data. In addition, because blockchain adopts a single chain structure, data storage on the chain is easily limited by performance bottlenecks, making it difficult to meet the flexible management of different data types and security requirements.

[0003] Existing research mainly focuses on improving blockchain storage architecture and optimizing consensus mechanisms, but there is still a lack of effective technical means for dynamically adjusting storage strategies based on data characteristics to improve the efficiency and accuracy of big data security management.

[0004] While existing big data storage technologies, such as distributed storage systems (e.g., HDFS, Ceph) and databases (e.g., ClickHouse), have achieved distributed storage and query optimization for massive amounts of data, they still fall short in terms of security and transparency.

[0005] Meanwhile, some blockchain-based storage solutions, such as IPFS, while providing decentralized storage capabilities, have relatively weak support in areas such as data priority management and dynamic storage strategy adjustment. In particular, for scenarios that need to consider multiple dimensions such as access frequency, security level, and sensitivity, traditional technologies lack a unified and efficient framework to achieve accurate data storage and management. In addition, existing technologies mostly adopt static policies for access control, which cannot flexibly adjust permission rules according to user roles and data characteristics, resulting in a failure to simultaneously meet the security and efficiency requirements of storage and retrieval.

[0006] In summary, existing big data storage management technologies have the following shortcomings: First, the storage architecture is too simplistic, making it difficult to dynamically adjust storage strategies based on data characteristics; second, data characteristics are not fully utilized for priority allocation, resulting in unreasonable allocation of storage resources; and third, the access control mechanism is rigid and lacks flexibility.

[0007] To address these issues, this invention proposes a blockchain-based big data information security management method that combines a layered blockchain architecture, a dynamic priority partitioning model, and a cold / hot storage separation strategy to achieve a comprehensive improvement in data storage security and management efficiency. Summary of the Invention

[0008] The purpose of this section is to outline some aspects of the embodiments of the present invention and to briefly introduce some preferred embodiments. Some simplifications or omissions may be made in this section, as well as in the abstract and title of the present application, to avoid obscuring the purpose of this section, the abstract and title of the invention. Such simplifications or omissions shall not be used to limit the scope of the present invention.

[0009] In view of the aforementioned existing problems, the present invention is proposed.

[0010] Therefore, the technical problem solved by this invention is that existing big data information security management technologies suffer from low data storage efficiency, insufficient security, and rigid access control.

[0011] To solve the above technical problems, the present invention provides the following technical solution: constructing a layered blockchain architecture, including a core chain and multiple sub-chains, wherein the core chain records the chain head hash value, data storage location and access permissions of the sub-chains;

[0012] Collect features of the data to be stored, including at least access frequency, field type, data size, sensitive tags, security level, and geographic location features, and generate a feature dataset by combining Geohash encoding;

[0013] A priority partitioning model is constructed based on the linear weighted algorithm and the TOPSIS algorithm to prioritize the data features in the feature dataset and generate priority scores.

[0014] Based on the priority score, the data to be stored is dynamically allocated to a high-security-level subchain or a low-security-level subchain using a hot-cold separation storage strategy.

[0015] Record data storage indexes and access permissions to the core chain;

[0016] The core chain is used to parse the user's query request and distribute it to the corresponding sub-chain. The sub-chain processes the query request in parallel and then returns the query result to the core chain.

[0017] The user's access rights are then verified through the core chain. Once the verification is successful, the data stored in the corresponding sub-chain is read based on the query results.

[0018] As a preferred embodiment of the blockchain-based big data information security management method of the present invention, the core chain is set at the top layer of the layered blockchain architecture and serves as a global index and control layer for managing and coordinating the states of multiple sub-chains. The core chain stores the hash value of the sub-chain head, the data storage location, and the access permissions. The hash value of the sub-chain head is used to verify the integrity of the sub-chain data. The data storage location includes the physical or logical location of the storage node. The access permissions record user permission information for data access control.

[0019] The sub-chains are located at the bottom layer of the layered blockchain architecture and serve as the data storage and processing layer. They are used to store data of different types and priorities. Each sub-chain is built independently and uses distributed storage.

[0020] The core chain is linked to each sub-chain through an index, and the sub-chains collaborate with each other through a cross-chain protocol.

[0021] Each subchain registers with the core chain, which records its chain head hash value and storage location. When the load of an existing subchain exceeds a threshold T... load The core chain generates a new sub-chain, Sub. new And migrate some data to the new subchain.

[0022] As a preferred embodiment of the blockchain-based big data information security management method of the present invention, the features of the collected data to be stored include:

[0023] The mathematical formula for calculating the access frequency per unit time by statistically analyzing the system logs is as follows:

[0024]

[0025] Among them, F i Let ε be the access frequency of the i-th data item, and ε be the access count, which is the total number of requests for the data within the time period T, where T is the time period.

[0026] Read field types directly from the metadata of the file to be stored;

[0027] Read the metadata of the file to be stored to directly obtain the data size;

[0028] Based on business rules, sensitive data is labeled with sensitive tags, and non-sensitive data is labeled with 0.

[0029] Security levels are set for metadata through business rules, defining three security levels: low, medium, and high.

[0030] Extract the location field, including latitude and longitude, from the data table or log to obtain the geographic location characteristics.

[0031] As a preferred embodiment of the blockchain-based big data information security management method described in this invention, a feature dataset is generated by combining Geohash encoding, including:

[0032] The Geohash encoding generates a binary sequence by performing a binary search on latitude and longitude.

[0033] By alternating the binary bits, the final encoded string G is generated. geo ;

[0034] Collect the above-mentioned feature information for all data entries;

[0035] Convert latitude and longitude to Geohash encoding;

[0036] By merging the collected feature information and Geohash encoding, a feature dataset D is generated. tag Feature dataset D tag The expression is:

[0037] D tag ={(F i ,T i ,X i M i ,L i G i )|i=1,2,…,n}

[0038] Among them, F i Let T be the access frequency of the i-th data item. i Let X be the field type of the i-th data entry. i M represents the size of the i-th data item. i L is the sensitive label for the i-th data item. i G represents the security level of the i-th data item. i The geolocation of the i-th data is encoded using Geohash.

[0039] As a preferred embodiment of the blockchain-based big data information security management method of the present invention, the generation of priority scores includes:

[0040] The features are assigned weights using a linear weighting method, and a comprehensive score is calculated to obtain a linear weighted score, which reflects the contribution of each feature to the priority.

[0041] The proximity of each data point is obtained by calculating the distance between the data and the ideal solution and the negative ideal solution;

[0042] Combining the linearly weighted score and the TOPSIS proximity score, the final priority score is generated:

[0043] P i=λS i +(1-λ)C i

[0044] Among them, S i For linearly weighted scores, C i For the degree of closeness, λ is the weight balance coefficient of the linear weighted sum and TOPSIS, with a value range of 0≤λ≤1.

[0045] As a preferred embodiment of the blockchain-based big data information security management method of the present invention, it further includes:

[0046] When P i Data that is ≥ the threshold is considered high-priority data.

[0047] When P i Data below the threshold is considered low-priority data.

[0048] As a preferred embodiment of the blockchain-based big data information security management method described in this invention, it specifically includes:

[0049] When P i When the threshold is reached, the high-priority data is marked as hot data and assigned to a high-security subchain;

[0050] When P i When the threshold is reached, the low-priority data is marked as cold data and assigned to a low-security subchain;

[0051] Then store the data in location L data The security level is recorded in the core chain index.

[0052] As a preferred embodiment of the blockchain-based big data information security management method described in this invention, after receiving a query request Q, the core chain parses the query target ID and user U; the core chain receives the query request Q and searches for the corresponding storage index L based on the query target ID. data Subchain number SC:

[0053] Based on the query target ID, obtain the corresponding subchain number SC and storage location L. data ;

[0054] The core chain generates a sub-chain query task Q. sub This includes the target data location and query operations;

[0055] The core chain is based on the storage location L data Query task Q sub Distribute to the corresponding subchain:

[0056] The subchain is based on the storage location L data Determine the data location and execute the task;

[0057] The query task Q sub Distribute to the subchain corresponding to the subchain number SC;

[0058] If the query involves multiple subchains, the core chain sends tasks to multiple subchains simultaneously:

[0059] Each subchain processes the query independently and returns the result R. sub,i ;

[0060] After the subchain completes the query task, it will output the result R. sub Return to the core chain:

[0061] The core chain aggregates the results returned by all sub-chains to generate the final query result R. final :

[0062]

[0063] Where n is the number of subchains involved in the query;

[0064] The core chain will ultimately query the result R. final Return it to the user.

[0065] The beneficial effects of this invention are as follows: By constructing a layered blockchain architecture and combining data feature collection, priority division, cold and hot storage separation, permission management and query optimization technologies, this invention addresses the problems of low data storage efficiency, insufficient security and rigid permission management in existing big data information security management technologies, thereby improving data security, storage efficiency, storage reliability and access security. Attached Figure Description

[0066] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments 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. Wherein:

[0067] Figure 1 This is a flowchart illustrating the blockchain-based big data information security management method of the present invention. Detailed Implementation

[0068] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0069] Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without inventive effort should fall within the scope of protection of this invention.

[0070] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0071] According to an embodiment of the present invention, in combination Figure 1 The flowchart shown illustrates a blockchain-based big data information security management method, which specifically includes the following steps:

[0072] S1. Construct a layered blockchain architecture, including a core chain and multiple sub-chains. The core chain records the chain head hash value, data storage location, and access permissions of the sub-chains. Note the following in this step:

[0073] The core chain, located at the top of the layered blockchain architecture, serves as the global index and control layer. It manages and coordinates the state of multiple sub-chains. The core chain stores the following information:

[0074] Subchain head hash value H head Used to verify the integrity of sub-chain data;

[0075] Data storage location L data This includes the physical or logical location of the storage node;

[0076] Access Permissions R perm Record user permission information for data access control;

[0077] In an optional implementation, the core chain employs an improved PBFT consensus algorithm to ensure rapid consensus in a multi-node collaborative environment, reducing network communication latency. For example, if the system has N nodes, of which at most f are malicious, the system fault tolerance requirement is N≥3f+1, and the consensus threshold is...

[0078] Where N is the total number of nodes, and f is the number of tolerable malicious nodes;

[0079] In an optional implementation, the block structure of the core chain is defined:

[0080] Block core ={H head Index, Permissions}

[0081] Among them, H headThe index includes the block hash and the previous block hash, and stores the subchain index information {H}. head ,L data}, Permissions refers to the access permission rules R perm ;

[0082] It should be noted that the core chain records the storage location L of all child chains. data According to user permission rule R perm Verify access requests; when processing user requests, parse and locate relevant sub-chains.

[0083] Furthermore, the subchains are located at the bottom layer of the layered blockchain architecture and serve as the data storage and processing layer. They are used to store data of different types and priorities. Each subchain is built independently, uses distributed storage, and supports dynamic expansion. For example, when the storage pressure is too high, the core chain dynamically creates new subchains through a scheduling protocol to share the storage task.

[0084] The core chain links to each sub-chain via an index, and the sub-chains collaborate through a cross-chain protocol, defining the block structure of each sub-chain:

[0085] Block sub ={H zhead ,Data,EncryptionInfo}

[0086] Among them, H zhead For including the hash value H of the sub-chain head zhead Data stores the specific data content, and EncryptionInfo stores the data encryption strategy.

[0087] Each subchain is registered with the core chain, and the core chain records its chain head hash value and storage location;

[0088] When the load of the existing subchain exceeds the threshold T load The core chain generates a new subchain, Sub. new And some data will be migrated to the new subchain, the architecture of which is shown below:

[0089] Core Blockchain

[0090] Subchain 1 (Subchain 1-High Security)

[0091] Subchain 2 (Low Cost)

[0092] Subchain n (Subchain n-Dynamic Extension)

[0093] Subchains are used to store specific data blocks, support distributed storage, encrypt and store data and verify permissions, process query requests distributed by the core chain and return results;

[0094] As an example, suppose a blockchain system contains data A (high security requirement, financial data) and data B (low priority, log data). A core chain needs to be built and a global index defined. Based on data priority, data A is stored in sub-chain 1 (high security), and data B is stored in sub-chain 2 (low cost). The core chain records the hash values ​​of the chain heads of sub-chain 1 and sub-chain 2.

[0095] Index core ={H 1,head H 2,head ,L A ,L B}

[0096] For example, the final architecture is as follows:

[0097] Core chain:

[0098] Subchain 1 (Data A: High security level)

[0099] Subchain 2 (Data B: Low security level)

[0100] It should be noted that this step, by constructing a layered blockchain architecture, achieves a hierarchical design for blockchain storage, which facilitates global management of the state and data of different sub-chains, ensuring the efficiency and security of data storage. The layered architecture divides the storage and management responsibilities of the blockchain into global management (core chain) and specific data operations (sub-chains), reducing storage bottlenecks, adapting to the diverse storage needs of big data, improving the system's flexibility and scalability for large-scale data storage, and enhancing the management capabilities of data with different security levels.

[0101] S2. Collect the features of the data to be stored. These features should include at least access frequency, field type, data size, sensitive tags, security level, and geographic location. Combine these features with Geohash encoding to generate a feature dataset. Note the following in this step:

[0102] In order to prioritize the data to be stored, the following characteristics need to be collected:

[0103] Access frequency: This is calculated by tracking the number of accesses through system logs and determining the access frequency per unit of time; its mathematical formula is:

[0104]

[0105] Among them, F iLet ε be the access frequency of the i-th data item, and ε be the access count, which is the total number of requests for the data within the time period T, where T is the time period.

[0106] Field type: Read field types directly from metadata (e.g., extract from database metadata tables, such as text, numeric, log, and location information);

[0107] Data size: Read the metadata of the stored file to directly obtain the data size;

[0108] Sensitive Labels: Label data with sensitive labels (Personal Privacy Data (PII), Financial Data) according to business rules. Sensitive data is labeled with 1, and non-sensitive data is labeled with 0.

[0109] Security Level: Set the security level for data through business rules or system security policies (e.g., low, medium, high, corresponding to values ​​of 0.1, 0.5, and 1.0 respectively);

[0110] Geographic location features: Extract location fields (latitude, longitude) from data tables or logs;

[0111] It should be noted that Geohash is a spatial encoding method based on geographic latitude and longitude, encoding two-dimensional latitude and longitude data into a string to facilitate fast spatial indexing and querying, for example:

[0112] Input: Latitude and longitude coordinates (lat, lon);

[0113] Output: String encoding of the geographic location G geo ;

[0114] Furthermore, Geohash generates binary sequences by performing a binary search on latitude and longitude, and finally converts them into strings, that is, normalizing lat and lon to the range [0,1] respectively:

[0115]

[0116] By alternating the binary bits, the final encoded string G is generated. geo ;

[0117] Collect the above-mentioned feature information for all data entries;

[0118] Convert latitude and longitude to Geohash encoding;

[0119] By merging the collected feature information and Geohash encoding, a feature dataset D is generated. tag Feature dataset D tag The expression is:

[0120] D tag ={(F i,T i ,X i M i ,L i G i )|i=1,2,…,n}

[0121] Wherein: F i Let T be the access frequency of the i-th data item. i Let X be the field type of the i-th data entry. i M represents the size of the i-th data item. i L is the sensitive label for the i-th data item. i G represents the security level of the i-th data item. i The geolocation of the i-th data item is encoded using Geohash.

[0122] As an example, the data to be stored is defined as shown in Table 1 below:

[0123] Table 1. Data to be stored

[0124]

[0125]

[0126] Set T = 1 day, F A =120, F B =10, F C =300, read the data size from the table in MB, and obtain the security level and sensitivity label directly from the values ​​in the table;

[0127] Generating Geohash codes using latitude and longitude:

[0128] A: (34.05,-118.25)→Geohash 9qh2gj;

[0129] B: (40.71,-74.01)→Geohash dr5reg;

[0130] C: (37.77,-122.42)→Geohash 9q8yy3;

[0131] Combining collected features with Geohash encoding:

[0132] D tag ={(120,wdwj,50,1,1.0,"9qh2gj"),

[0133] (10,xtrz,200,0,0.5,"dr5reg"),(300,sswz,20,0,0.1,"9q8yy3")}

[0134] Among them, wdwj is the document file, xtrz is the system log, and sswz is the real-time location information;

[0135] Table 2. Feature Data Generation Table

[0136]

[0137] After the feature dataset is formatted, it is input into the next step for priority allocation.

[0138] Preferably, this step collects multidimensional features of the data to be stored (including access frequency, field type, data size, sensitive tags, security level, and geographic location features) and generates a feature dataset by combining it with Geohash encoding. This achieves accurate labeling and classification of the data to be stored. These features reflect the key attributes of data security, storage requirements, and access frequency. Geohash encoding provides efficient indexing capabilities for geographic location data, facilitating subsequent storage allocation and query optimization. It realizes the digitization and spatial indexing of multidimensional data features, improves the accuracy of data management and query efficiency, and provides a foundation for subsequent priority allocation and dynamic storage.

[0139] S3. Construct a priority partitioning model based on the linear weighted algorithm and the TOPSIS algorithm to prioritize the data features in the feature dataset and generate priority scores. Note the following in this step:

[0140] Each feature obtained in step S2 is assigned a weight using a linear weighting method, and a comprehensive score is calculated to reflect the contribution of each feature to the priority. The mathematical formula is as follows:

[0141]

[0142] Among them, S i F is the comprehensive score of the i-th data point. i,j w represents the value of the i-th data point on feature j. j Let the weights of feature j satisfy the following condition: n is the number of features;

[0143] The proximity of each data point is obtained by calculating the distance between the data and the ideal solution (PIS) and the negative ideal solution (NIS).

[0144] Calculate the ideal solution A + and negative ideal solution A - :

[0145] A + ={max(F i,j )∣j∈J1;min(F i,j )∣j∈J2}

[0146] A - ={min(F i,j )∣j∈J1;max(F i,j )∣j∈J2}

[0147] Among them, J1 is a revenue-related feature (such as access frequency and security level), and J2 is a cost-related feature (such as data size);

[0148] Calculate the distance from data i to the positive and negative ideal solutions:

[0149]

[0150] Calculate the closeness C i :

[0151]

[0152] Among them, C i The closer the value is to 1, the higher the priority of the data;

[0153] The final priority score is generated by combining the linearly weighted score and the TOPSIS similarity score:

[0154] P i =λS i +(1-λ)C i

[0155] Where λ is the weight balance coefficient of the linear weighted sum and TOPSIS, and its value ranges from 0 to 1.

[0156] Furthermore, to avoid the influence of different feature units on the results, the features need to be normalized, as shown in the following formula:

[0157]

[0158] Among them, F′ i,j These are the normalized eigenvalues;

[0159] The comprehensive score S is calculated using the normalized eigenvalues ​​and weights. i ;

[0160] Based on the normalized eigenvalues, the distance between each data point and the positive and negative ideal solutions is calculated, and the closeness C is obtained. i ;

[0161] Comprehensive linear weighted score S i And proximity C i Calculate the final priority score P i ;in:

[0162] When Pi When the number is ≥60, it is considered high-priority data and is stored in a high-security subchain;

[0163] When P i When the priority is less than 60, it is considered low-priority data and is stored in a low-security subchain.

[0164] As an example, see Table 3 below:

[0165] Table 3. Input Data Table

[0166] Data Identifier Access frequency Data size Sensitive Labels Security level Geohash encoding A 120 50 1 1.0 9qh2gj B 10 200 0 0.5 dr5reg C 300 20 0 0.1 9q8yy3

[0167] Set w F =0.4 (access frequency weight), w X =0.2 (data size weight), w M =0.2 (weight of sensitive tags), w L =0.2 (security level weight);

[0168] Based on the above formula, feature normalization yields the following result:

[0169] A: F′ F =0.4, F′ X =0.875, F′ M =1.0, F′ L =1.0;

[0170] B: F′ F =0.0, F′ X =0.0, F′ M =0.0, F′ L =0.5;

[0171] C:F′ F =1.0, F′ X =1.0, F′ M =0.0, F′ L =0.1;

[0172] The linear weighted score S is calculated using the above formula. i The following results were obtained:

[0173] A: 0.4·0.4+0.2·0.857+0.2·1.0+0.2·1.0=0.6914

[0174] B: 0.4·0.0+0.2·0.0+0.2·0.0+0.2·0.5=0.1

[0175] C: 0.4·1.0+0.2·1.0+0.2·0.0+0.2·0.1=0.76

[0176] Define A+ = (1.0, 1.0, 1.0, 1.0), A - = (0.0, 0.0, 0.0, 0.0), and the distance and proximity are calculated according to the above formula, yielding the following results:

[0177] A: C i =0.68

[0178] B: C i =0.16

[0179] C: C i =0.91

[0180] Calculate the priority score P according to the above formula. i The following results were obtained:

[0181] A: 0.7·0.6914+0.3·0.68=0.6878

[0182] B: 0.7·0.1+0.3·0.16=0.118

[0183] C: 0.7·0.76+0.3·0.91=0.799

[0184] The final result is expressed as:

[0185] A:P i =68.78, allocated to the high-security subchain;

[0186] B:P i =11.8, allocated to the low-security subchain;

[0187] C:P i =79.9, allocated to the high-security subchain;

[0188] After the data is allocated to a high-security or low-security subchain, it enters the S4 cold and hot separation storage step.

[0189] Preferably, the linear weighted algorithm combines the weights of each feature to ensure the controllability of feature contributions. The TOPSIS algorithm improves the accuracy of priority scores by calculating the distance between positive and negative ideal solutions. The priority scores comprehensively consider the importance of data, access requirements, and security levels, laying the basis for the dynamic allocation of subchains with different security levels. This effectively optimizes the storage resource allocation strategy, enabling high-priority data to receive higher security protection and access speed, while saving storage costs for low-priority data.

[0190] S4. Based on priority scores, dynamically allocate the data to be stored to high-security-level sub-chains or low-security-level sub-chains using a hot / cold storage separation strategy. Note that the following points should be noted in this step:

[0191] The data priority score P is calculated based on step S3. i ;

[0192] If P i Data ≥ the threshold is marked as hot data (processing method: replicated to multiple nodes and stored encrypted), and allocated to a high-security sub-chain;

[0193] If P i If the threshold is exceeded, the data is marked as cold data (processing method: compressed storage to a single node) and allocated to a low-security sub-chain;

[0194] Then store the data in location L data Security levels are recorded in the core chain index;

[0195] Furthermore, the final distribution of data storage is divided into high-security sub-chains (hot storage) and low-security sub-chains (cold storage), with the storage location and security level of each piece of data recorded through the core chain index structure.

[0196] It should be noted that the hot and cold storage separation strategy dynamically allocates data to different storage tiers based on data priority scores:

[0197] High-security-level subchains (hot storage): Used to store high-priority data, offering higher security and faster access speeds, such as P... high ≥ Threshold, the threshold is determined by the business scenario (e.g., 60), suitable for frequently accessed and highly sensitive data;

[0198] Among them, redundant storage: adopts a multi-replica redundancy strategy N replica Improve fault tolerance;

[0199] Encrypted storage: Data must be encrypted (e.g., AES-256 or RSA);

[0200] Low-security-level subchains (cold storage): Used to store low-priority data, with low storage costs, such as P... low <Threshold, suitable for data that is not frequently accessed or has low sensitivity;

[0201] Among them, compressed storage: compression algorithms (such as Zstd) are used to reduce storage space;

[0202] No redundancy required: Single-node storage, no additional replicas.

[0203] As an example, see Table 4 below:

[0204] Table 4. Priority Score Table for Data to be Stored

[0205]

[0206] The priority scores, P, are calculated using step S3. A =68.78, P B =11.8, P C =79.9;

[0207] Based on the threshold (set to 60):

[0208] Data A and C are assigned to a high-security-level sub-chain (hot storage);

[0209] Data B is allocated to a low-security-level sub-chain (cold storage);

[0210] Specifically, data A and C are stored in subchain 1 (high-security subchain), replicated 3 times, and encrypted using AES-256. Data B is stored in subchain 2 (low-security subchain), compressed using Zstd, and has no redundancy.

[0211] The core chain records are as follows:

[0212] Subchain 1 (High-Security Subchain): Data A and C, stored in {L} A ,L C Security level: High;

[0213] Subchain 2 (low-security subchain): Data B, stored at {L} B Security level: Low;

[0214] Table 5. Storage Data Structure Table

[0215]

[0216] By using a hot and cold storage separation strategy, data A and C are protected with high security, while data B optimizes storage costs and completes dynamic allocation and indexing records.

[0217] Preferably, this step dynamically allocates data to high-security-level subchains or low-security-level subchains based on priority scores using a hot-cold separation storage strategy. This achieves hierarchical management of data storage. High-priority data is stored in high-security-level subchains and uses encryption and redundancy strategies, while low-priority data is stored in low-security-level subchains and uses compressed storage. The hot-cold separation storage strategy dynamically adjusts the storage method according to data characteristics, which not only ensures the security of sensitive data but also reduces the storage cost of low-priority data. This achieves a dynamic balance between storage efficiency and data security, and significantly improves the system's adaptability to complex big data scenarios.

[0218] S5. Record data storage indexes and access permissions to the core chain. Note the following about this step:

[0219] Based on the hot and cold separation storage strategy in step S4, determine the sub-chain number SC of the data. i and storage location L data ;

[0220] The core chain records and stores the index information for each piece of data according to the following rules:

[0221] Index core ={(ID) i ,SC i ,L data E data )|i=1,2,,n}

[0222] Among them, ID i SC serves as a unique identifier for the data. i L is the corresponding subchain number. data The storage location of the data is typically represented by the storage node address and the block offset:

[0223] L data ={Node,Block Index ,Offset}

[0224] Among them, E data : Marked as "AES-256", "RSA" or "unencrypted";

[0225] Data storage index content includes:

[0226] Data Identifier ID i A unique identifier for each piece of data, used to locate the data;

[0227] Subchain number SC i : Pointer to the target subchain number of the data storage;

[0228] Storage location L data The physical or logical location of the data in the subchain (such as block number and offset address);

[0229] Data encryption state E data Record whether the data is encrypted, and the encryption algorithm used;

[0230] The system analyzes data sensitivity and security level based on business rules, and generates an access permission matrix R. perm Access permissions include:

[0231] Permission rule R permRecord access permissions for each piece of data, specifying which users or roles can access that data;

[0232] For example, in this embodiment of the invention, permission rules are represented by a Boolean matrix:

[0233]

[0234] Among them, U1, U2, ..., U m This represents a user or role. A value of 1 in the matrix indicates that the corresponding user has access to the data, while a value of 0 indicates that the user does not have access.

[0235] Role hierarchy: such as Administrator (Admin), Regular User (User), Service Role (ServiceRole);

[0236] Permission scope: This includes the permission levels for operations such as read, write, modify, and delete;

[0237] Furthermore, the generated storage index will be... core and access permissions R perm When written to the core chain, the block record format is as follows:

[0238] Block core ={H prev H head Index core ,R perm}

[0239] Among them, H prev H is the hash value of the previous block. head The hash value of the current block, Index core For storing indexes, R perm Access permission rules;

[0240] Core chain index:

[0241] Index core ={(ID) i ,SC i ,L data E data )|i=1,2,,n}

[0242] Core chain block representation:

[0243] R perm ={(ID) i U k As an example, the following table 6 shows the following: (i = 1, 2, ..., n; k = 1, 2, ..., m)

[0244] Table 6. Data Content Record Table

[0245]

[0246] As an example, the core chain stores the index:

[0247]

[0248] in, Indicates none;

[0249] As an example, access permission rules:

[0250]

[0251] Where dx represents read and write, and dd represents read;

[0252] As an example, core chain block records:

[0253]

[0254]

[0255] Through the above processes and records, the core chain achieves comprehensive management of data storage indexes and access permissions, laying the foundation for subsequent data queries and permission verification.

[0256] Preferably, this step achieves unified management of the global location of data and permission rules by recording data storage indexes and access permissions in the core chain. The storage index ensures rapid location of distributed storage data, and the access permission rules realize dynamic binding of user roles and operation scopes. The index and permission management constitute the foundation of blockchain storage and access, which not only improves the efficiency of data query, but also strengthens the system's access control capabilities, simplifies the coordination process of data storage and access, and ensures the compliance and security of user access operations.

[0257] S6. Parse the user's query request using the core chain, distribute it to the corresponding sub-chains, and have the sub-chains process the query requests in parallel before returning the query results to the core chain. Note the following in this step:

[0258] After receiving a query request Q, the core chain parses the query target ID and user U;

[0259] The structured representation of user query request Q is as follows:

[0260] Q = {ID, U, T} query O query}

[0261] Where ID is the unique identifier of the target data being queried, U is the user identifier that initiated the query request, and T... queryFor query types (such as read, modify, delete), O query For query operations (such as returning the full text or returning a summary);

[0262] The core link is to receive QQ; the corresponding storage index L is found based on the ID. data Subchain number SC:

[0263] L data =Index core (ID)

[0264] Among them, Index core It is the index table of the core chain storage;

[0265] Index table structure:

[0266] Index core ={(ID,SC,L data ,R perm )}

[0267] Retrieve the corresponding subchain number SC and storage location L based on the ID. data ;

[0268] Core chain generates sub-chain query task Q sub This includes the target data location and query operations;

[0269] Core chain based on L data Query task Q sub Distribute to the corresponding subchain:

[0270] Q sub ={L data ,U,T query O query}

[0271] Subchain according to L data Determine the data location and execute the task;

[0272] Q sub Distribute to the subchain corresponding to SC;

[0273] If the query involves multiple subchains, the core chain sends the task to multiple subchains simultaneously:

[0274] Q sub,i ={L data,i ,U,T query O query}, i = 1, 2, ..., n, R sub,i

[0275] Each subchain processes the query independently and returns the result R. sub,i ;

[0276] After the subchain completes the query task, it will return the result R. sub Return to the core chain:

[0277] R sub =Result sub (Q sub )

[0278] Among them, Result sub This is the query result after the subchain has executed its task;

[0279] The core chain aggregates the results returned by all sub-chains to generate the final query result R. final :

[0280]

[0281] Where n is the number of subchains involved in the query;

[0282] The core chain will R final Return it to the user.

[0283] As an example, user U=Admin initiates a query request targeting data ID=A,C;

[0284] Table 7. Core Chain Index Table

[0285]

[0286] Parse ID = A and C, and find the corresponding subchain SC = 1;

[0287] Find storage location L data ={Node1,Block5,Offset1} and {Node3,Block2,Offset6};

[0288] Generating subchain tasks:

[0289] Subchain Task 1:

[0290] Q sub,A ={{Node1,Block5,Offset1},Admin,Read,Full Text Return}

[0291] Subchain Task 2:

[0292] Q sub,C ={{Node3,Block2,Offset6},Admin,Read,Full Text Return}

[0293] Subchain 1 executes the task and returns the result:

[0294] R sub,A ={file content: financial statement data}, R sub,C={File content: Logistics data}

[0295] Summary results:

[0296] R final ={File content: Financial statement data, File content: Logistics data}

[0297] User Admin received the query result R final ;

[0298] The final result is expressed as:

[0299] A: Query result R final For financial statement data;

[0300] C: Query result R final For logistics data;

[0301] Through the core chain's parsing and task distribution, users successfully obtained the data they needed.

[0302] Preferably, this step parses the user query request through the core chain, distributes it to the corresponding sub-chain, and the sub-chain processes the query request in parallel, realizing the dynamic decomposition and efficient execution of the query task. The core chain quickly locates the target sub-chain based on the data storage index, and the sub-chain improves the query response speed through the parallel processing mechanism.

[0303] Preferably, the multi-subchain parallel query mechanism avoids the performance bottleneck problem of single-chain storage, and is especially suitable for high-concurrency query needs in massive data scenarios, improving query response speed and system throughput.

[0304] S7. Next, verify the user's access permissions through the core chain. After successful verification, read the data stored in the corresponding sub-chain based on the query results. Note the following in this step:

[0305] Access permission verification is based on user identity U and permission rule matrix R. perm In the matching process, the core chain determines whether the query should continue by verifying whether the user has the necessary permissions. The structure of the permission rule matrix is ​​as follows:

[0306] R perm ={(ID) i U k ,P op |i=1,2,,n;k=1,2,,m}

[0307] Among them, ID i U is a data identifier. k For users k, P op Access levels (e.g., read, write, modify);

[0308] Query permission rules:

[0309]

[0310] If Match(Q) = True, then the user has access rights;

[0311] The core chain extracts the following information from query request Q:

[0312] Q = {ID, U, T} query O query}

[0313] Where ID is the identifier of the target data being queried, U is the user initiating the query, and T... query For query types (such as read), O query For query operations;

[0314] From the permission rule matrix R in the core chain perm Retrieve rules that match ID and U;

[0315] Compare T query Is it within user U's permission scope for ID data? op Inside;

[0316] If the match is successful, the verification passes; otherwise, an access denial is returned.

[0317] Verification successful: Returns a "Verification successful" status;

[0318] Verification failed: "Insufficient permissions" status returned;

[0319] The storage location L of the target data is parsed from the index table of the core chain. data :

[0320] L data =Index core (ID)

[0321] Among them, L data Includes subchain number SC, storage node Node, and block number Block. Index and offset;

[0322] Subchain according to L data Locate the storage node and specific storage location of the target data, and perform data read operations;

[0323] If data is stored using encryption, decryption is required, based on the encryption algorithm type E recorded in the core chain index. data Choose a decryption method (such as AES-256), and the decryption formula is as follows:

[0324] D out=Decrypt(D enc ,K)

[0325] Among them, D out For the decrypted data, D enc K is the decryption key for encrypting data;

[0326] The subchain returns the raw or decrypted data it reads to the core chain, which then returns the query result requested by the user.

[0327] Permission verification result:

[0328] Result perm ={Success,Failed}

[0329] Data read results:

[0330] Result data ={D out |Decrypt(D enc ,K)}

[0331] Final query results:

[0332] Result final ={Result perm ,Result data}

[0333] As an example, define

[0334] A: User U is Admin, with permissions P op Including reading and modifying;

[0335] B: User U is User, with permissions P op Including reading;

[0336] C: User U is the Manager, with permissions P op Including reading and writing;

[0337] Table 8. Core Chain Storage Index Table

[0338]

[0339] Query request:

[0340] Q = {ID = A, U = Admin, T} query =Read, O query =Full text}

[0341] Parsing the query request: Target data ID=A, User U=Admin;

[0342] Search permission rule matrix:

[0343] R perm (A, Admin) = {Read, Modify}

[0344] Match T query = Reading, within the permission range, verification passed;

[0345] Core chain storage location:

[0346] L data (A) = {Node1, Block5, Offset1}

[0347] Subchain 1 locates the target data and reads the encrypted data D. enc ;

[0348] The data is encrypted using AES-256 and decrypted using key K:

[0349] D out =Decrypt(D enc ,K)

[0350] The core chain returns the decrypted query results;

[0351] Permission verification result:

[0352] Result perm =Success

[0353] Query results:

[0354] Result data ={Financial Statement Content}

[0355] Final result:

[0356] Result final ={Permission verification successful, financial statement content}

[0357] Through the core chain's permission verification and the sub-chain's data reading and processing, users successfully obtain the data they need. The entire process is logically clear and secure.

[0358] Preferably, permission verification ensures the legitimacy of user query behavior, and data reading combined with encryption and decryption mechanisms improves the security of data storage. This step decouples permission management from data access, while ensuring the efficiency and security of data reading, realizing full-process security control of data access, preventing unauthorized access behavior, and optimizing the user's access experience.

[0359] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A blockchain-based big data information security management method, characterized in that, include: A layered blockchain architecture is constructed, comprising a core chain and multiple sub-chains. The core chain records the chain head hash value, data storage location, and access permissions of each sub-chain. Collect features of the data to be stored, including at least access frequency, field type, data size, sensitive tags, security level, and geographic location features, and generate a feature dataset by combining Geohash encoding; A priority partitioning model is constructed based on the linear weighted algorithm and the TOPSIS algorithm to prioritize the data features in the feature dataset and generate priority scores. The generation of priority scores includes: assigning weights to the features using a linear weighting method, calculating a comprehensive score to obtain a linear weighted score, reflecting the contribution of each feature to the priority; calculating the proximity of each data point to the ideal solution and the negative ideal solution; and combining the linear weighted score and the TOPSIS proximity score to generate the final priority score. wherein, is a linear weighted score, is a closeness, is a weight balancing coefficient of linear weighted sum TOPSIS, and the value range is ; Based on the priority score, the data to be stored is dynamically allocated to a high-security-level subchain or a low-security-level subchain using a hot-cold separation storage strategy. When threshold, for high priority data, the high priority data marked as hot data, assigned to a high security sub-chain; When When the threshold value is reached, low priority data, which is marked as cold data, is assigned to the low security sub-chain; Record the data storage index and access permissions to the core chain; that is, the data storage location. Security levels are recorded in the core chain index; The core chain is used to parse the user's query request and distribute it to the corresponding sub-chain. The sub-chain processes the query request in parallel and then returns the query result to the core chain. The user's access rights are then verified through the core chain. Once the verification is successful, the data stored in the corresponding sub-chain is read based on the query results. 2.The blockchain-based big data information security management method of claim 1, wherein, The core chain is located at the top layer of the layered blockchain architecture and serves as a global index and control layer. It is used to manage and coordinate the state of multiple sub-chains. The core chain stores the hash value of the sub-chain head, the data storage location, and the access permissions. The hash value of the sub-chain head is used to verify the integrity of the sub-chain data. The data storage location includes the physical or logical location of the storage node. The access permissions record user permission information and are used for data access control. The sub-chains are located at the bottom layer of the layered blockchain architecture and serve as the data storage and processing layer. They are used to store data of different types and priorities. Each sub-chain is built independently and uses distributed storage. The core chain is linked to each sub-chain through an index, and the sub-chains collaborate with each other through a cross-chain protocol. Each subchain registers with the core chain, which records its chain head hash value and storage location. When the load on an existing subchain exceeds a threshold... The core chain generates new sub-chains. And migrate some data to the new subchain. 3.The blockchain-based big data information security management method of claim 1, wherein, The characteristics of the collected data to be stored include: The mathematical formula for calculating the access frequency per unit time by statistically analyzing the system logs is as follows: wherein, is the access frequency of the ith data, is the access frequency of the ith data, is the access frequency of the ith data, is the access frequency of the ith data, is the access frequency of the ith data, is the access frequency of the ith data, is the access frequency of the ith data, is the access frequency of the ith data, is the access Read field types directly from the metadata of the file to be stored; Read the metadata of the file to be stored to directly obtain the data size; Based on business rules, sensitive data is labeled with sensitive tags, and non-sensitive data is labeled with 0. Security levels are set for metadata through business rules, defining three security levels: low, medium, and high. Extract the location field, including latitude and longitude, from the data table or log to obtain the geographic location characteristics. 4.The blockchain-based big data information security management method of claim 1, wherein, The feature dataset is generated by combining Geohash encoding, including: The Geohash encoding generates a binary sequence by performing a binary search on latitude and longitude. Alternately taking the binary bits, generating the final encoded string ; Collect the characteristics of the data to be stored for all data entries; Convert latitude and longitude to Geohash encoding; By merging the collected feature information and Geohash encoding, a feature dataset is generated. Feature dataset The expression is: in, Let i be the access frequency of the i-th data item. Let i be the field type of the i-th data. Let i be the size of the i-th data item. The sensitive label for the i-th data item. The security level of the i-th data item. The geolocation of the i-th data item is encoded using Geohash.

5. The blockchain-based big data information security management method according to claim 1, characterized in that, After receiving query request Q, the core chain parses the query target ID and user U; upon receiving the query request Q, the core chain looks up the corresponding storage index based on the query target ID. Subchain number SC: Based on the query target ID, obtain the corresponding subchain number SC and storage location. ; The core chain generates a sub-chain query task. This includes the target data location and query operations; The core chain is based on the storage location. query task Distribute to the corresponding subchain: The sub-chain is based on the storage location. Determine the data location and execute the task; The query task Distribute to the subchain corresponding to the subchain number SC; If the query involves multiple subchains, the core chain sends tasks to multiple subchains simultaneously: Each subchain processes queries independently and returns results. ; After the subchain completes the query task, it will display the results. Return to the core chain: The core chain aggregates the results returned by all sub-chains to generate the final query result. : Where n is the number of subchains involved in the query; The core chain will ultimately retrieve the query results. Return it to the user.

Images