Dynamic authority intelligent contract generation method and system based on data sensitivity self-adaption

Abstract

The invention provides a dynamic permission smart contract generation method and system based on data sensitivity self-adaption, and relates to the technical field of data security, the method comprises the following steps: classifying and marking multi-dimensional data in a business scene, and constructing a customer information classification matrix according to data types; based on data types of the client information classification matrix, sensitivity quantitative evaluation is carried out by utilizing a rule engine based on a decision tree, the engine takes a data use scene, a regulation constraint label and a timeliness weight label as input, a sensitivity result is judged and output according to a preset tree-shaped path, and a structured sensitivity level matrix is generated after all data types are traversed; and according to the data sensitivity level matrix, in combination with a preset post role permission rule, establishing a mapping relationship between data sensitivity and role permission, and generating a dynamic permission policy tree. According to the invention, through data classification and sensitivity evaluation, the data security is balanced and the protection capability is improved.

Description

Technical Field

[0001] This invention relates to the field of data security technology, and in particular to a method and system for generating dynamic permission smart contracts based on adaptive data sensitivity. Background Technology

[0002] With the development of digital business, data security and access control face many challenges; traditional data classification sometimes relies on static rules, which may have many problems in practical applications.

[0003] Taking the financial industry as an example, customer transaction data constantly changes with time and market conditions, and new transaction types and risk patterns emerge continuously. However, static classification rules cannot promptly include these newly emerging high-risk transaction data in the key regulatory scope, potentially leading to ineffective protection of sensitive data. Current access control is sometimes static, and manual authorization can be inefficient. In the vertical business processes of large enterprises, such as expense approval in the finance department, the multi-level access configuration from frontline employees to senior management involves a large amount of repetitive work due to manual operation, wasting manpower and time and prone to errors. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide a method and system for generating dynamic permission smart contracts based on data sensitivity adaptation, which balances data security and improves protection capabilities through data classification and sensitivity assessment.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows: Firstly, a method for generating dynamic permission smart contracts based on data sensitivity adaptation, the method comprising: Step S1: Classify and label the multidimensional data in the business scenario, and construct a customer information classification matrix based on the data type; Step S2: Based on the data type of the customer information classification matrix, use a decision tree-based rule engine to perform sensitivity quantitative evaluation. The engine takes the data usage scenario, legal constraint label, and timeliness weight label as input, judges according to the preset tree path, outputs the sensitivity result, and generates a structured sensitivity level matrix after traversing all data types. Step S3: Based on the data sensitivity level matrix and the preset job role permission rules, establish a mapping relationship between data sensitivity and role permissions, and generate a dynamic permission policy tree; Step S4: Compile the dynamic permission policy tree into executable smart contract code, deploy it to the distributed ledger network and generate a digital fingerprint for permission control; at the same time, construct smart contract execution entry parameters based on business process stages, timestamp thresholds and data update events; Step S5: When the smart contract execution entry parameters are met, the smart contract execution engine parses the current business scenario context, dynamically adjusts access permissions, and generates a temporary access token. Step S6: Based on the temporary access token, perform real-time pattern analysis on data access behavior through the anomaly detection unit built into the smart contract; when an out-of-bounds permission behavior is detected, trigger the permission revocation function and generate a security alarm event record.

[0006] Secondly, a dynamic permission smart contract generation system based on data sensitivity adaptation includes: The classification module is used to classify and label multidimensional data in business scenarios and construct a customer information classification matrix based on data types. The rank matrix module is used to classify data types based on customer information matrices. It uses a decision tree-based rule engine to perform sensitivity quantitative assessment. The engine takes data usage scenarios, legal constraint labels, and timeliness weight labels as inputs, judges according to a preset tree path, and outputs sensitivity results. After traversing all data types, it generates a structured sensitivity rank matrix. The mapping module is used to establish a mapping relationship between data sensitivity and role permissions based on the data sensitivity level matrix and the preset job role permission rules, and generate a dynamic permission policy tree. The module is used to compile the dynamic permission policy tree into executable smart contract code, deploy it to the distributed ledger network, and generate a digital fingerprint for permission control; it also builds smart contract execution entry parameters based on business process stages, timestamp thresholds, and data update events. The dynamic adjustment module is used to dynamically adjust access permissions and generate temporary access tokens when the smart contract execution entry parameters are met, by parsing the current business scenario context through the smart contract execution engine. The logging module is used to perform real-time pattern analysis of data access behavior based on temporary access tokens and through the anomaly detection unit built into the smart contract; when an out-of-bounds permission behavior is detected, the permission revocation function is triggered and a security alarm event record is generated.

[0007] Thirdly, a computing device includes: One or more processors; A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method.

[0008] Fourthly, a computer-readable storage medium storing a program that, when executed by a processor, implements the method.

[0009] The above-described solution of the present invention has at least the following beneficial effects: By constructing a customer information classification matrix, structured management of multi-dimensional data is achieved, solving the problem of data fragmentation and laying a unified framework for subsequent operations. Simultaneously, a decision tree engine integrates factors such as data usage scenarios, regulatory constraints, and timeliness to form a dynamic sensitivity measurement system, ensuring that assessment results meet compliance requirements. A fine-grained mapping mechanism between data sensitivity and role permissions is established through a dynamic permission policy tree, automating the execution of the principle of least privilege. Combined with smart contracts and temporary token mechanisms, permissions can be dynamically adjusted according to business process stages, timestamp thresholds, and data update events, balancing security and collaboration efficiency. Permission policies are compiled into smart contracts and deployed to a distributed ledger, leveraging the immutability of blockchain to ensure consistency in permission rule execution. Combined with the automated real-time execution capabilities of smart contracts, management costs and human error are reduced. Real-time blocking of out-of-bounds behavior is achieved through an anomaly detection unit built into the smart contract. Combined with on-chain storage of out-of-bounds records and digital fingerprints of permission control, an immutable audit traceability system is formed, meeting compliance requirements. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating a dynamic permission smart contract generation method based on data sensitivity adaptation, provided by an embodiment of the present invention.

[0011] Figure 2 This is a schematic diagram of a dynamic permission smart contract generation system based on data sensitivity adaptation, provided by an embodiment of the present invention. Detailed Implementation

[0012] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0013] like Figure 1 As shown, an embodiment of the present invention proposes a method for generating dynamic permission smart contracts based on data sensitivity adaptation, the method comprising the following steps: Step S1: Classify and label the multidimensional data in the business scenario, and construct a customer information classification matrix based on the data type; Step S2: Based on the data type of the customer information classification matrix, use a decision tree-based rule engine to perform sensitivity quantitative evaluation. The engine takes the data usage scenario, legal constraint label, and timeliness weight label as input, judges according to the preset tree path, outputs the sensitivity result, and generates a structured sensitivity level matrix after traversing all data types. Step S3: Based on the data sensitivity level matrix and the preset job role permission rules, establish a mapping relationship between data sensitivity and role permissions, and generate a dynamic permission policy tree; Step S4: Compile the dynamic permission policy tree into executable smart contract code, deploy it to the distributed ledger network and generate a digital fingerprint for permission control; at the same time, construct smart contract execution entry parameters based on business process stages, timestamp thresholds and data update events; Step S5: When the smart contract execution entry parameters are met, the smart contract execution engine parses the current business scenario context, dynamically adjusts access permissions, and generates a temporary access token. Step S6: Based on the temporary access token, perform real-time pattern analysis on data access behavior through the anomaly detection unit built into the smart contract; when an out-of-bounds permission behavior is detected, trigger the permission revocation function and generate a security alarm event record.

[0014] In this embodiment of the invention, classification and matrix construction are used to standardize and organize multidimensional data, facilitating the rapid identification of key data types. Based on a decision tree engine, combined with data usage scenarios, legal constraints, and timeliness weights, sensitivity is automatically quantified, avoiding subjective human judgment bias and ensuring the traceability and verifiability of evaluation results. By mapping sensitivity to role permissions, more refined management is achieved, with higher data sensitivity resulting in stricter permission control, preventing data leakage risks caused by excessive delegation of permissions. Permission policies are compiled into smart contracts and deployed to a distributed ledger. The immutability of blockchain ensures that permission rules cannot be maliciously tampered with, while smart contracts automatically execute permission logic, reducing human intervention. Smart contracts are triggered by parameters such as business process stages and timestamp thresholds to achieve on-demand authorization. An anomaly detection unit built into the smart contract analyzes access patterns in real time, and immediately triggers a revocation mechanism once permission overreach is detected.

[0015] In a preferred embodiment of the present invention, step S1 above: classifying and labeling multidimensional data in the business scenario, and constructing a customer information classification matrix according to data type, may include: Step S1.1: Extract multidimensional data from the business scenario and perform dual classification and labeling based on the data type dimension and the business attribute dimension; Step S1.2: Map the marked data types to preset fields to construct a structured matrix with the data subject identifier as the primary key and the data type label as the column attribute; Step S1.3: Embed data source identifiers and business scenario context labels into the matrix to form a customer information classification matrix containing complete metadata.

[0016] In this embodiment of the invention, dual-dimensional classification can improve classification accuracy, avoid data ambiguity caused by a single standard, and the business attribute dimension can directly relate to the data needs of different departments, improving the efficiency of cross-departmental data collaboration. When constructing the structured matrix, a standardized management foundation is achieved through preset field mapping to ensure data format uniformity. At the same time, using the data subject identifier as the primary key can optimize data retrieval efficiency, allowing all category data to be retrieved by entering the customer ID. After embedding data source identifiers and business scenario context tags in the matrix, the data traceability capability can be enhanced, and the data collection path can be traced through the source identifier to meet compliance audit requirements.

[0017] In this embodiment of the invention, when applied in a specific way, it can be implemented through the following technical solutions, for example: Step S1.1 above involves collecting raw data from business systems (such as CRM and ERP), including multi-dimensional data such as basic customer information (name, ID number), transaction records (order amount, time), and behavior logs (browsing history, operation frequency); classifying data by attributes, such as: personal privacy data (biometrics, bank accounts), commercial data (purchase contracts, pricing strategies), and operational data (login logs, permission change records); and labeling data by the business scenario to which it belongs, such as: sales business (customer contact information, order data), financial business (income and expenditure records, invoice information), and compliance business (identity verification materials, regulatory filing documents).

[0018] Step S1.2 above describes the pre-setting process of preset fields, which is based on a hierarchical field system constructed according to business scenarios and data types. The top-level classification is based on the enterprise's core business segments (such as sales, finance, and compliance) and data sensitivity levels (public, internal, and confidential) as the top-level dimensions, forming the basic framework for field classification. For example, the top-level field classification includes: personal information, transaction data, business logs, and compliance documents. The middle-level field subdivision is a further breakdown under the top-level classification based on data attributes or business process links. For example, personal information subdivision includes: basic information (name, ID number), contact information (mobile phone number, email), and biometric features (fingerprint, facial data). Transaction data subdivision includes: financial information (order amount, payment method), and logistics information (delivery address, delivery status). The bottom-level field definition clarifies the standard naming and format of specific data items to ensure uniqueness. For example, the bottom-level fields include: personal information_basic information_name, and transaction data_financial information_amount.

[0019] For sensitive data types (such as personal biometric financial account information) explicitly defined in regulations such as the Information Protection Law (A) and the Security Law (B), corresponding categories are forcibly defined in the preset fields. The field hierarchy is adjusted with reference to data classification standards in industries such as finance and healthcare (such as ISO27001 and HIPAA). For example, the preset fields in the healthcare industry must include health data, diagnosis records, and disease names to comply with patient privacy protection standards.

[0020] Set other classes or custom category nodes in the top-level or middle-level fields to allow the addition of fields when business changes occur. For example, when an enterprise adds blockchain transaction hash value data, a blockchain hash value field can be added under Transaction Data_Other Transaction Information; record the version number for changes to preset fields (such as field renaming or hierarchical adjustment).

[0021] The specific execution flow of the preset field mapping: Forward mapping matches the corresponding node of a preset field based on data classification tags (e.g., customer name belongs to Personal Information_Basic Information); reverse verification verifies the compliance of the data to be mapped by the semantic definition of the preset field (e.g., Personal Information_Basic Information_Name requires the field value to be Chinese characters or a combination of letters); for data that may belong to multiple fields (e.g., customer email belongs to both contact information and marketing data), business attribute tags are used for priority matching. For example, if the customer email is used for user registration, it is mapped to Personal Information_Contact Information_Email; if it is used for marketing push, it is mapped to Marketing Data_Customer Outreach_Email.

[0022] The core logic of the mapping engine is as follows: read the data after classification and labeling (e.g., order amount is labeled as transaction data_financial information); retrieve the matching field path (transaction data_financial information_amount) in the preset field library; verify the data format (e.g., order amount must be a numeric type, conforming to the preset decimal(10,2) format requirement); complete the mapping and record the mapping relationship (e.g., the binding record of data item order amount with field transaction data_financial information_amount); for complex mapping scenarios (e.g., field matching after parsing unstructured data text), a manual review interface is provided, allowing data administrators to adjust the mapping path.

[0023] The mapped data is converted according to the format requirements of the preset fields (e.g., ID card numbers are uniformly formatted as 18 digits, and mobile phone numbers are prefixed with the country code); check whether the mapped data is filled into all the required fields of the preset fields (e.g., personal information, basic information, and name are required, and an exception alarm is triggered if no data is mapped).

[0024] In step S1.3 above, embedding the data source identifier involves adding data source markers to the matrix, such as: marking that the customer's ID number comes from the public security system verification interface, and the transaction record comes from the payment system log; recording the specific business process in which the data is generated, such as: the context label for the customer's ID number is account opening registration - identity verification, and the label for the order amount is transaction payment - settlement process; associating the source identifier, context label, data subject, and type label to form a matrix record containing complete metadata.

[0025] In a preferred embodiment of the present invention, step S2 above: based on the data type of the customer information classification matrix, a sensitivity quantification assessment is performed using a decision tree-based rule engine. The engine takes data usage scenarios, regulatory constraint labels, and timeliness weight labels as inputs, judges according to a preset tree path, outputs sensitivity results, and generates a structured sensitivity level matrix after traversing all data types. This may include: Step S2.1: Extract data type labels, business scenario context labels, and data source identifiers from the customer information classification matrix to generate a basic label set; Step S2.2: Combine the basic tag set with the externally input regulatory constraint factor mapping tags and timeliness weight parameter rule tags to form the complete set of input tags for the rule engine; Step S2.3: Input the complete set of tags into the decision tree rule engine, and generate branch matching results by matching layer by layer through the preset tree rule path. The branch matching results include the scenario risk branch based on the business scenario context tag matching, the compliance constraint branch based on the regulatory constraint factor mapping tag matching, and the timeliness decay or enhancement branch based on the timeliness weight parameter ruleized tag matching. Step S2.4: Based on the branch matching results, locate the leaf node at the end of the decision tree and generate the sensitivity determination result for the current data type; Step S2.5: Traverse all data types in the customer information classification matrix, process them independently, aggregate the sensitivity judgment results, and generate a structured data sensitivity level matrix. This matrix inherits the data subject identifier primary key of the original matrix, adds a sensitivity level field, and associates it with scenario, regulation, and timeliness judgment basis tags.

[0026] In this embodiment of the invention, multi-dimensional label extraction ensures label integrity, providing comprehensive basic information for sensitivity assessment. Meanwhile, business scenarios and source identifiers expand the assessment dimensions, associating different risk scenarios. Automatic matching of regulatory constraint labels enables automated embedding of compliance requirements, preventing human error from overlooking compliance requirements such as special protection labels for biometric data, thus reducing legal risks. The timeliness weight introduces a dynamic time dimension, ensuring assessment results change with data updates. Multi-dimensional risk stratification assessment is conducted through decision tree branches, classifying regulations, scenarios, and time factors for hierarchical judgment. This avoids single-dimensional assessment biases such as considering only regulations while ignoring scenario risks. The tree-like path visualizes the assessment logic, allowing traceability of each judgment basis. Furthermore, associating judgment basis labels enhances the interpretability of the results. Finally, a matrix format enables global sensitivity visualization, intuitively presenting the sensitivity distribution of all data, including the proportion of highly sensitive data and risk concentration points across business lines.

[0027] In this embodiment of the invention, when applied in a specific way, it can be implemented through the following technical solutions, for example: In step S2.1 above, the data type label column (such as personal privacy data, transaction data) is read from the customer information classification matrix, and grouped and aggregated according to the data subject identifier (primary key) to form the type identifier of each data item. For example, for the ID card number data of customer ID C001, its type label is extracted as personal information_identity verification_ID card number; the business scenario context label field (such as account opening registration-identity verification, transaction payment-settlement process) is extracted from the matrix, and the scenario process (such as account opening registration) and operation type (such as identity verification) are separated; the data source identifier (such as public security system verification interface, payment system log) is read, and the system or interface name of the data collection path is recorded; the three types of labels are combined according to the data subject-data type-scenario-source dimension to generate a basic label set in JSON format.

[0028] Step S2.2 above includes the following: The basic regulatory layer includes general national regulations, such as the "B Security Law" and the "A Information Protection Law," with the scope of constraints divided according to data type. For example, Article N of the "A Information Protection Law" explicitly states that sensitive personal information includes biometrics and financial accounts, with the corresponding regulatory constraint label requiring anonymization and a storage period of ≤3 years. The industry-specific regulatory layer is further subdivided by industry (finance, healthcare, education, etc.) and superimposed with specific requirements. For example, the "Measures for the Management of Data Security of Banking Financial Institutions" in the financial industry requires that customer transaction data be transmitted in encrypted form and that cross-border transmission must pass a security assessment; the "Measures for the Management of Health and Medical Data" in the healthcare industry stipulates that medical record data must be stored on blockchain and that access requires two-factor authentication.

[0029] Data type-legal clause mapping: Establishing many-to-many mapping relationships, for example:

[0030] Transform regulatory provisions into enforceable labels. For example: sensitive personal information leaving the country requires a security assessment → cross-border transfer of labels requires a security assessment; financial data requires tiered protection → labels need to be managed according to sensitivity levels.

[0031] Dynamic matching process between data types and regulations: Extract data types (such as ID card number and bank account) from the basic tag set, and match them with the data type column of the regulatory mapping table. For example, if the data type is ID card number, locate Article N of the "Information Protection Law" and obtain the basic constraint tag that needs to be anonymized and stored for a period of ≤3 years. Check whether the matched regulatory clauses cover all mandatory constraints (such as whether they include requirements for storage, transmission, and use). If any are missing, trigger an alert (such as prompting manual addition of tags when a regulation does not define deletion rules).

[0032] Based on the business scenario context tags or enterprise attributes (such as financial enterprise identifiers), determine whether industry regulations need to be superimposed. For example, if the data belongs to financial transaction records and the enterprise is a bank, the "Banking Data Security Measures" will be triggered; if the data is patient medical records and the enterprise is a hospital, the "Health and Medical Data Management Measures" will be triggered. Add industry-specific requirements to the basic regulatory tags. For example, the basic tag for bank account information is anonymization. After superimposing industry tags for encrypted transmission and transaction tracking, the final set of constraint tags is {anonymization, storage ≤ 3 years, encrypted transmission, transaction tracking}.

[0033] Combine basic regulatory labels, industry labels, and regional labels in a format of "stage + action + requirement." For example, the final label for data type bank account information would be: Storage period ≤ 3 years, encrypted storage; cross-border transmission requires security assessment and encryption; access requires two-factor authentication; check whether the labels conform to the original wording of the regulations. Record the mapping relationship between data type, legal clause, and constraint label to the blockchain.

[0034] The time decay rule configuration sets the weight based on the data update frequency (e.g., transaction data has a weight of 1.0 for the last 7 days, 0.5 for 8-30 days, and 0.2 for more than 30 days); the business cycle association is for seasonal data (e.g., quarterly financial reports), which sets a weight of 1.0 for the first month after the financial report is released, and then decays to 0.3.

[0035] The basic tags, regulatory constraint tags, and timeliness weight tags are merged to form a three-dimensional tag set that includes data attributes, compliance requirements, and time factors.

[0036] Step S2.3 above: Construction of the core rule system of the decision tree engine: After receiving the complete set of tags, the root node forces priority to parse regulatory constraint tags to ensure that compliance requirements are the primary condition for sensitivity assessment. For example, if the data type matches sensitive personal information in Article N of the Information Protection Law, regardless of the scenario or timeliness, it directly enters the high-sensitivity data assessment path. The conditions of each branch node must cover all possible tag states to avoid blind spots where tags cannot be matched.

[0037] Branch conditions support AND and OR logic combinations. For example, the trigger condition for a high-risk scenario in the second-level branch is: the scenario tag includes online transactions and the scenario tag includes cross-border transmission. In the timeliness branch, a weight threshold is set as the branch condition. If the threshold is exceeded, the sensitivity enhancement (such as +1 level) is triggered.

[0038] High-risk scenarios (such as online transactions) or high time-sensitive weights (within the last 7 days) trigger an increase in sensitivity level, with each increment being 1 level (e.g., from level 3 to level 4); historical data (more than 180 days) or low-risk scenarios (offline archiving) trigger a decrease in sensitivity level, with each decrease being 1-2 levels.

[0039] Hierarchical design of pre-defined tree-like path rules: Receive the complete set containing regulatory constraint tags, scenario tags, and timeliness tags, and extract the key fields of sensitivity level (such as high sensitivity) from the regulatory constraint tags.

[0040] First-level branching: Branch A is a highly sensitive data branch. The regulatory constraint label contains keywords such as the need to anonymize highly sensitive personal information and confidential data. For example, ID card numbers and bank account information are triggered to enter this branch due to the regulatory label. Branch B is a general data branch. The regulatory labels do not indicate the sensitivity level, or it belongs to public data and non-sensitive business data, such as customer browsing history and public product introduction data.

[0041] Second-level branch (scenario risk dimension): Sub-branches under branch A (highly sensitive data): Branch A1 is a high-risk scenario branch. The scenario tag contains keywords such as online transmission, cross-border transactions, and third-party sharing. The sensitivity level is +1. For example, the scenario of using ID number for online account opening and cross-border authentication will trigger this branch. Branch A2 is a medium-risk scenario branch. The scenario tag contains keywords such as internal system storage and inter-departmental sharing. The sensitivity level remains unchanged. For example, storing ID numbers in the company's internal CRM system would trigger this branch. Branch A3 is a low-risk scenario branch. The scenario tags include keywords such as offline archiving for personal use, and the sensitivity level is -1. For example, the branch is triggered when historical ID numbers have been archived offline.

[0042] Sub-branches under branch B (general data): Branch B1 is a key business scenario branch. The scenario tags include keywords such as core business processes and financial settlement, and the sensitivity level is +1 (e.g., from level 1 to level 2). Branch B2 is a normal scenario branch, with the scenario label being auxiliary recording of non-core business, etc., and the level remains unchanged.

[0043] Third-level branches (timeliness dimension): Sub-branches under branch A1 (highly sensitive, high-risk scenario): Branch A 1-1 For real-time data branches, the timeliness weight label is ≥0.8 (e.g., updated within the last 7 days), and the level is +1 (e.g., upgraded from level 4 to level 5). For example: online transaction ID number data for the last 3 days. Branch A 1-2 For recent data branches, the timeliness weight is 0.5 ≤ timeliness < 0.8 (e.g., updated within 8-30 days), and the level remains unchanged (maintained at level 4). Branch A 1-3 For historical data branches, the timeliness weight is <0.5 (e.g., if it has not been updated for more than 30 days), and the level is -1 (downgraded from level 4 to level 3).

[0044] Parameterized configuration of the preset path: Branch condition parameters are configurable. For example, trigger keywords for high-risk scenarios can be added through the management backend (such as adding a cloud storage scenario tag) without modifying the code. The timeliness weight threshold (such as 0.8) and the level adjustment range (+1 level) can be dynamically configured according to business needs (such as setting it to +2 level for the financial industry).

[0045] When multiple branch conditions are met simultaneously, the priority is to execute according to regulations, which take precedence over scenarios, which take precedence over timeliness. For example, if data triggers both high-sensitivity and low-risk scenarios at the same time, the high-sensitivity branch is processed first, and the scenario risk is only slightly adjusted. A new version is generated after each modification of the preset path, and the old version path is retained in the historical data evaluation record to ensure traceability consistency.

[0046] Example of tree-structured path matching for typical data types, such as: Online account opening - ID card number data from the last 3 days, legal label: highly sensitive personal information → enter branch A (highly sensitive data), scenario label: online account opening includes online transmission keywords → enter branch A1 (high-risk scenario), sensitivity level tentatively set from basic level 4 to level 5 (+1 level); timeliness label: weight 1.0 ≥ 0.8 from the last 3 days → enter branch A 1-1 (Real-time data), Sensitivity level + 1 → Final level 6 (assuming the highest level is 6); Root node → A → A1 → A 1-1 The corresponding criteria for judgment are: highly sensitive regulatory requirements + high-risk online scenarios + real-time data.

[0047] In step S2.4 above, the sensitivity level corresponding to the leaf node is preset (e.g., high sensitivity - high risk - real-time corresponds to level 4, general data - low risk - historical corresponds to level 1); the branch matching result is mapped to the leaf node: according to the final branch path (e.g., compliance → high sensitivity → scenario risk → online transaction → timeliness → the last 3 days), the corresponding leaf node is located and the sensitivity level is obtained (e.g., level 4); the key tag that triggers the level is recorded (e.g., regulations: A. Article N of the Information Protection Law; scenario: online account opening and transmission risk; timeliness: updated in the last 3 days).

[0048] In step S2.5 above, loop through the primary key of the customer information classification matrix (e.g., customer ID), and independently execute steps S2.1 to S2.4 for each data type (e.g., ID number, order amount) to generate the corresponding sensitivity level; add a sensitivity level field (e.g., values ​​1-5) to the original matrix, and add a judgment basis tag set field (storing legal, scenario, and timeliness tags); aggregate the sensitivity levels of all data types, check for any uncovered data items (e.g., missing a certain type of business data), and generate a complete structured matrix.

[0049] In a preferred embodiment of the present invention, step S3 above: establishing a mapping relationship between data sensitivity and role permissions based on the data sensitivity level matrix and in conjunction with preset job role permission rules, and generating a dynamic permission policy tree, may include: Step S3.1: Load the preset job role permission rule library, which defines: the default operation permissions of each job role for critical, important, and basic sensitive data; the vertical job hierarchy in the organizational structure; and the data isolation boundary rules for cross-departmental collaboration. Step S3.2: Based on the data sensitivity level matrix, parse and generate a sensitivity label set; Step S3.3: Match the sensitivity tag set with the permission rule base and output the basic permission mapping table; Step S3.4: Construct a dynamic permission policy tree based on the basic permission mapping table. The dynamic permission policy tree includes vertical hierarchical permission inheritance relationships and horizontal cross-departmental permission isolation rules.

[0050] In this embodiment of the invention, a pre-defined job role permission rule library enables standardized permission management, avoiding arbitrary permission allocation and ensuring consistent permissions for the same job position. Simultaneously, job hierarchy relationships allow for automated permission inheritance, reducing manual configuration. Clear cross-departmental isolation rules prevent the leakage of sensitive data across departments. A structured set of sensitivity tags improves permission matching efficiency, supporting rapid location of corresponding permissions through key-level tags, reducing matching time. The accompanying legal provisions and other judgment criteria make permission allocation results interpretable. Two-way matching based on sensitivity and role ensures accurate permission allocation, guaranteeing the implementation of the principle of least privilege. Pre-defined conflict resolution rules standardize conflict handling. The dynamic permission policy tree provides dynamic adaptability, improving business efficiency while ensuring security. Its tree structure allows for visualized permission auditing, facilitating auditors to quickly identify abnormal permissions such as employees accessing cross-departmental data without authorization. Furthermore, the built-in cross-departmental isolation and hierarchical inheritance logic automatically verifies compliance, ensuring that permission allocation meets organizational structure and GDPR's principle of least privilege.

[0051] In this embodiment of the invention, when applied in a specific way, it can be implemented through the following technical solutions, for example: In step S3.1 above, the preset job role permission rule base is systematically preset through the following dimensions, deeply binding job roles, data sensitivity, operation permissions, and organizational structure relationships to form a structured permission control system, as follows: Based on data sensitivity, the rule base pre-defines job permissions, categorizing data into different sensitivity levels such as basic, important, and critical, with each level corresponding to different access control strengths. For each job role (e.g., sales manager, finance director), the rule base specifies their operational permissions for different data levels. For example: Sales Manager: Can query and export basic data; can only query important data; has no permissions for critical data; Finance Director: Can modify and export important financial data; can read and approve critical budget data; Compliance Specialist: Can read and audit critical compliance documents for the entire department, but has no modification permissions. The rule base covers various operation permission types, including read, write, modify, delete, export, share, approve, and audit, with each permission corresponding to a specific data operation scenario.

[0052] Based on organizational structure, the rule base loads the vertical hierarchy of the organizational structure (e.g., ordinary employee → department head → director → senior executive) to establish a clear hierarchical logic for permission inheritance. Automatic inheritance means that senior-level positions automatically inherit all permissions from lower-level positions. For example, a department head inherits the query and export permissions of an ordinary employee. Permission extension means that senior-level positions gain additional specific permissions. For example, a department head can add approval permissions, and a director can add cross-departmental data coordination permissions. The rule base allows setting permission exceptions for special positions. For example, although senior executives inherit all permissions from their subordinates, some core data (such as board resolutions) requires separate authorization.

[0053] Cross-departmental data access isolation rules: The rule base clearly defines data access restrictions between different departments to prevent unauthorized cross-departmental operations. For example, the sales department is prohibited from accessing the finance department's critical budget data, regardless of their job level; important customer research data of the marketing department is only allowed to be read-only accessed by the R&D department, and exporting or modification is prohibited; for necessary cross-departmental collaboration scenarios, the rule base sets up a temporary authorization mechanism. For example, when the R&D department needs to access important customer data of the sales department for a project, it must obtain temporary read access through a compliance approval process, and the access will be automatically revoked after the validity period expires.

[0054] The rule base uses job roles, data sensitivity, operation permissions, organizational levels, and departmental boundaries as core dimensions to form multi-dimensional relational data tables, facilitating quick querying and permission matching. When the organizational structure is adjusted (such as adding new positions or reorganizing departments) or data sensitivity changes, the rule base can be manually updated by the administrator or automatically synchronized by the system to ensure that permission rules are consistent with actual business needs. The rule base has built-in verification logic to avoid permission conflicts and complies with B security regulations.

[0055] In step S3.2 above, the sensitivity level field (e.g., numerical levels 1-5) is read from the data sensitivity level matrix and converted into labels according to a preset mapping, for example: level 4-5 → critical level, level 2-3 → important level, level 1 → basic level; a set containing sensitivity labels and judgment criteria is generated for each data type, for example: the label set for data ID numbers: [critical level, regulatory requirements + high-risk scenarios + real-time data]; check whether the labels cover all data types (if there are no omissions) and verify the accuracy of the level conversion (e.g., whether level 5 is correctly mapped to the critical level).

[0056] In step S3.3 above, the matching process between the sensitivity tag set and the permission rule base is achieved through a two-way verification mechanism of vertical and horizontal verification, and finally a structured mapping table is generated to intuitively present the correspondence between job roles and data permissions.

[0057] The core logic of tag-rule bidirectional matching is as follows: Vertical matching is a permission mapping that multiplies job role by sensitivity tag. Using job role and sensitivity tag as coordinates, it directly reads the preset default permissions from the rule base. For example, CFO and sales manager correspond to job identities in the organizational structure, such as key level, important level, and basic level, which identify the security level of the data. When a user is a CFO and accesses financial data with a key level tag, the vertical matching rule base results in: read, modify, and approve permissions are allowed. If a sales manager accesses important level customer data, the vertical matching result is: query permission is allowed only.

[0058] Horizontal matching is a cross-departmental permission isolation verification. Based on department affiliation and cross-departmental rules, it verifies whether the current position has permission to access target data across departments. It determines the main department to which the position belongs (e.g., the CFO belongs to the finance department) and the pre-set inter-departmental data access prohibition clauses in the rule base (e.g., the sales department cannot access key finance data). If the CFO attempts to access key data in the sales department, horizontal matching will trigger cross-departmental rules: First, it confirms that the CFO belongs to the finance department and the target data belongs to the sales department. According to the rule base, the finance department needs additional approval to access key sales data across departments, so the default permission is not effective.

[0059] Permission conflict handling mechanism: When the same position simultaneously meets multiple permission rules and the rules are contradictory (such as a position that oversees two departments), the conflict handling logic is triggered. For example, a director who belongs to both the sales and finance departments may conflict with the sales department's rules and cross-departmental rules when accessing key data in the sales department. If the position belongs to the department where the target data is located, the permission rules of that department will take precedence over the cross-departmental rules. For example, when a director who oversees both sales and finance accesses key data in the sales department, the internal permission rules of the sales department will apply (e.g., no permission), rather than the cross-departmental rules that require approval. If the conflict involves job level (e.g., senior management and ordinary employees), higher-level permissions can override lower-level restrictions, but the principle of least privilege must be followed.

[0060] The mapping table is structured as follows: the row dimension represents job roles (e.g., sales manager, finance director); the column dimension represents data sensitivity labels (critical, important, basic); and the cell content represents the allowed operation permissions for the corresponding job role at that level of data (e.g., no permission to read or modify).

[0061] Example table:

[0062] Extract the triplet data of job role-sensitivity tag-operation permission from the rule base and populate it by row and column dimensions; the results of cross-department rule and permission conflict handling will affect the final cell content (e.g., cross-department access requires labeling and approval); when the permission rules, job roles or sensitivity tags in the rule base change, the mapping table will be automatically updated to ensure that the permission configuration takes effect in real time.

[0063] The system intuitively displays the permission boundaries of each position, making it easy for administrators to quickly query and audit. The system can directly read the mapping table data to achieve real-time permission verification of user operations (such as prohibiting sales managers from exporting critical data).

[0064] The overall matching and mapping process is as follows: Input job roles, data sensitivity tags, and department affiliation information; obtain default permissions from the vertical matching rule base; verify cross-department rules horizontally; adjust permissions; handle permission conflicts; and determine the final permissions; generate a job-sensitivity-permission mapping table for permission control and management.

[0065] In step S3.4 above, the dynamic permission policy tree, by integrating vertical hierarchy, horizontal isolation, and dynamic factors, constructs a three-dimensional structure with the capabilities of permission inheritance, departmental blocking, and scenario adaptation. Its construction process uses job roles as nodes and the organizational structure as the framework, dynamically injecting permission variables based on business scenarios to form a real-time adjustable permission control network, as detailed below: Using job roles in the organizational structure as tree nodes, a vertical hierarchy is constructed according to job level. Root node: senior management (such as CEO, CFO), second-level node: department director (such as sales director, finance director), third-level node: department head (such as sales department head, finance head), leaf node: ordinary employee.

[0066] By default, child nodes inherit all permissions from their parent nodes. For example, a sales manager inherits the data query permissions of a sales specialist. Higher-level nodes can have exclusive permissions added. For example, a sales manager can add the permission to approve data export requests from subordinates, and a finance director can add the permission to modify departmental budget data.

[0067] Add isolation layers between nodes in different departments to block cross-departmental data access by default. For example, there is a cross-departmental blocking node between the sales department node and the finance department node to prevent sales managers from directly accessing the finance department's critical data; a read-only blocking node is set between the R&D department and the marketing department nodes to allow R&D personnel to read important marketing data, but prohibits them from modifying it.

[0068] When a user accesses cross-departmental data, the policy tree checks whether there is a blocking node in the path: if it exists and there is no additional authorization, access is directly denied (e.g., when a sales manager accesses financial budget data, the blocking is triggered); if it exists but the approval process is completed, the blocking node is temporarily bypassed (e.g., when a research and development director applies to access market customer data).

[0069] Business scenario factors trigger permission adjustments for scenarios such as temporary projects and cross-departmental collaborations. For example, when a sales manager participates in a temporary financial reconciliation project, the system injects a temporary financial collaboration factor, granting read-only access to important financial data. Time factors set the validity period of permissions. For example, temporary permissions take effect after approval and automatically expire after 72 hours. Operation context factors are dynamically adjusted based on user operation behavior. For example, when a user attempts to export a large amount of data, the approval level is automatically upgraded.

[0070] The system receives externally input factor parameters through dynamic nodes in the strategy tree: when a dynamic scenario is triggered (such as the creation of a temporary project), the system injects a temporary permission node into the corresponding job node in the strategy tree (such as sales manager → finance temporarily read-only); when the factor becomes invalid, the temporary node is automatically removed from the strategy tree and the permissions are restored to default.

[0071] When the organizational structure is adjusted (such as adding a new department) or the permission rules are modified, the strategy tree automatically reconstructs the node relationships. For example, after adding a compliance department, the strategy tree adds a compliance director node under the senior management level and establishes cross-departmental blocking rules between nodes of other departments. When injecting dynamic factors, the strategy tree automatically checks whether there is a conflict with the existing rules: if temporary permissions conflict with default permissions (such as temporarily allowing modification of data that is prohibited from being modified), the dynamic factor takes precedence and is overridden, but the conflict log is recorded for auditing.

[0072] In a preferred embodiment of the present invention, step S4 above: compiling the dynamic permission policy tree into executable smart contract code, deploying it to the distributed ledger network and generating a digital fingerprint for permission control; simultaneously constructing smart contract execution entry parameters based on business process stages, timestamp thresholds, and data update events, which may include: Step S4.1: Extract permission rule components from the dynamic permission policy tree, including: permission nodes and their associated role identifiers, vertical permission inheritance relationship chain, horizontal cross-departmental isolation rule set, and embedded sensitivity determination basis tags; Step S4.2: The permission rule component is transformed into an executable logical unit using a structured transformation algorithm; Step S4.3: Generate executable smart contract code based on executable logic units, deploy it to the distributed ledger network, and generate a unique digital fingerprint for access control; Step S4.4: Define business status triggering conditions based on business process stage identifiers, define timeliness triggering conditions based on timestamp thresholds, define data change triggering conditions based on data update event listeners, and construct a set of data access triggering conditions. Step S4.5: Bind the access control digital fingerprint to the set of trigger conditions to form the smart contract execution entry parameters.

[0073] In this embodiment of the invention, smart contracts are deployed to a distributed ledger, and permission rules are solidified in the blockchain in the form of code, avoiding human tampering or single point of failure. Trigger conditions automatically drive permission verification without manual intervention. The hierarchical inheritance, cross-departmental isolation, and sensitivity tags of the dynamic permission policy tree are extracted and transformed into smart contract logic, enabling fine-grained matching of job positions, data, and operations. Horizontal isolation rules are embedded in the contract to strictly block unauthorized cross-departmental access and reduce the risk of data leakage. The digital fingerprint of permission control is bound to the blockchain transaction record, and any permission change or access behavior is recorded by the distributed ledger, facilitating auditing and compliance traceability. Trigger conditions are designed based on business process stages, synchronizing permission control with actual business flow. Timestamp thresholds and data update events drive dynamic adjustment of permissions, supporting temporary collaboration scenarios.

[0074] In this embodiment of the invention, when applied in a specific way, it can be implemented through the following technical solutions, for example: Step S4.1 above starts with the root node of the tree structure (e.g., senior management) and traverses all permission nodes hierarchically to extract node attributes (e.g., job title, department affiliation) and associated role identifiers (e.g., unique ID). It traces back from the leaf nodes (ordinary employees) to the root node, recording the permission inheritance path at each level (e.g., sales specialist → sales supervisor → sales director → senior management), forming a chain-like data relationship. It scans the blocking nodes between department nodes, extracts the prohibition rules for cross-department access (e.g., sales department → finance department: access to critical data is prohibited), and records the rule triggering conditions. It binds a corresponding data sensitivity label (e.g., critical level, importance level) to each permission node, forming a job-sensitivity mapping relationship table.

[0075] Step S4.2 above converts permission nodes into condition-action logic units, for example: Condition: Job role = Sales Manager and Data Sensitivity = Basic level; Action: Allow query and export operations; converts vertical inheritance chains into permission stacking logic, such as child node permission = parent node permission + its own extended permissions, and automatically merges permission sets through hierarchical judgment; converts cross-department blocking rules into access control conditions, for example: if the current department ≠ the target department and the data sensitivity ≥ importance level, then the blocking logic is triggered; converts tags into comparable numerical values ​​or enumeration values ​​(such as critical level = 3, importance level = 2, basic level = 1) for level matching during permission verification.

[0076] In step S4.3 above, based on a standard smart contract template (such as Solidity), the logical units are converted into functions and state variables in the contract code. For example, a permission query function checkPermission(role, dataSensitivity) is defined, embedding the conditional logic from step S4.2. The code is compiled into bytecode using a smart contract compiler, gas consumption is optimized, and an interface ABI (Application Binary Interface) is generated. A deployment transaction is sent to the distributed network through a blockchain client (such as Web3.js), and after waiting for node consensus confirmation, a contract address and a unique hash value (digital fingerprint) are generated. The contract code and deployment parameters are hashed (such as SHA-256) to generate an irreversible permission control digital fingerprint, which is used to identify the permission rule version of the contract.

[0077] Step S4.4 above divides the business process (such as data application → approval → use → archiving) into different stages, sets a status identifier for each stage (such as stage=1 indicating the application stage), defines the stage transition conditions that trigger permission verification (such as triggering permission checks when switching stages), sets time-related trigger conditions, such as: temporary permission validity period: automatically expires when currentTime>startTime+validHours; triggers financial data permission reset at 0:00 on the 1st of each month; and deploys an event listener (such as DataUpdated(eventdataID,sensitivity)) in the smart contract, which automatically triggers permission re-verification logic when an external system calls the contract to update data.

[0078] In step S4.5 above, a parameter set in JSON format is constructed, including: a digital fingerprint for access control (used to locate the corresponding contract); trigger condition data (such as the current business stage, timestamp, and data update event parameters); the digital fingerprint and the trigger condition set are bound together by key-value pairs, and validation logic is added at the smart contract entry point to ensure that the digital fingerprint matches the contract and that the trigger conditions comply with preset rules (such as the timestamp not having expired and the business stage being valid).

[0079] In a preferred embodiment of the present invention, step S5 above: when the smart contract execution entry parameters are satisfied, the smart contract execution engine parses the current business scenario context, dynamically adjusts access permissions, and generates a temporary access token, which may include: Step S5.1: When the smart contract execution entry parameters are met, retrieve the latest data sensitivity level matrix from the blockchain, parse and generate a real-time sensitivity field; obtain the current business stage identifier through the business unit API; calculate the real-time digital fingerprint of the permission request, compare it with the pre-stored fingerprint to generate the permission verification result; Step S5.2: Based on the key dynamic parameter set composed of the real-time sensitivity field, the current business stage identifier, and the permission verification result, perform dynamic permission adjustment calculation to generate a dynamic permission configuration set; Step S5.3: Encapsulate the dynamic permission configuration set into a temporary access token, which includes: an encrypted data range identifier, an operation permission validity parameter, and a digital fingerprint binding signature.

[0080] In this embodiment of the invention, real-time data sensitivity synchronization is achieved by retrieving the latest data sensitivity level matrix through blockchain, avoiding permission lag. At the same time, business stage identifiers are obtained through business unit APIs, deeply binding permission control with business processes. The legality of permission requests is verified by comparing real-time digital fingerprints with pre-stored fingerprints. Dynamic permission adjustments are performed based on dynamic parameter sets to achieve adaptive permission optimization, and fine-grained control is achieved through precise matching. Risks are dynamically prevented and controlled based on changes in data sensitivity. Dynamic permissions are encapsulated as temporary access tokens, and secure encapsulation, tamper-proof verification, and efficient management of temporary permissions are achieved by encrypting data range identifiers, setting time-limit parameters, and binding signatures with digital fingerprints.

[0081] In this embodiment of the invention, when applied in a specific way, it can be implemented through the following technical solutions, for example: In step S5.1 above, a query request is sent to the distributed ledger network. Based on the data type (such as financial or customer data) and the current timestamp, the latest stored data sensitivity level matrix is ​​retrieved. The matrix contains the mapping relationship between data entities and sensitivity labels. The matrix data is parsed to extract the real-time sensitivity field of the target data. If a data update triggers an event (such as a version change), the data is retrieved again to ensure timeliness.

[0082] By passing in the business process ID associated with the current operation (e.g., sales order approval-001) through the pre-defined business unit API (e.g., approval in progress, archived), the stage status of the process (e.g., under approval, archived) is obtained; the stage description returned by the business system (e.g., PaymentApproval) is mapped to an enumeration value that the smart contract can recognize (e.g., stage=2).

[0083] Collect the context parameters of the current permission request (user role, data ID, operation type), combine them with the data sensitivity field and business stage identifier, and generate a real-time digital fingerprint using a hash algorithm (such as SHA-256); compare the real-time fingerprint with the permission control digital fingerprint pre-stored in the smart contract (generated in step S4.3): if they match, allow the permission verification process to continue; if they do not match, trigger exception handling (such as permission rule version inconsistency, access denied).

[0084] Step S5.2 above integrates real-time sensitivity fields (such as critical level), current business stage identifiers (such as stage=3 indicating data is in use), permission verification results (pass / reject, and the set of permissions inherited from the parent node); and queries the dynamic permission policy library based on the parameter set. For example, if the business stage is in approval and the data sensitivity is important, then approval permission is added on the basis of the default permissions; if the data sensitivity is upgraded from basic level to important level, then export permission is automatically revoked, and only query is retained.

[0085] According to the adjustment rules, add, delete, and modify permissions based on the default permissions: add temporary permissions, such as temporarily adding read-only permissions for financial data to sales managers during cross-departmental projects; restrict existing permissions, such as downgrading modification permissions to read-only after data is archived; and generate the final permission configuration set.

[0086] In step S5.3 above, the target data range corresponding to the permission is determined, and the data range identifier is encrypted using a symmetric encryption algorithm (such as AES). The key is bound to the user's public key to ensure that only authorized persons can decrypt it. The operation permission validity period parameter is set, which includes: startTime (current timestamp + 5 minutes, waiting for approval to be completed), expiration Time (expireTime) (temporary permission lasts for 72 hours and automatically expires upon expiration), and extension rules (if the business phase has not ended, an extension of the validity period can be applied for (permission verification needs to be retried).

[0087] The dynamic permission configuration set, encrypted data range identifier, and expiration parameters are combined into a JSON structure and signed using a smart contract private key (e.g., using the ECDSA algorithm). The signature result is bound to the permission control digital fingerprint to form a signature-fingerprint pair, which is used to verify the token's legitimacy. All fields are encapsulated in the standard JWT (JSON Web Token) format, including: Header: Algorithm identifier, token type; Payload: Encrypted data range, permission list, expiration parameters, digital fingerprint; Signature: Used for tamper-proof verification.

[0088] In a preferred embodiment of the present invention, step S6 above: based on the temporary access token, real-time pattern analysis of data access behavior is performed through the anomaly detection unit built into the smart contract; when an out-of-bounds permission behavior is detected, a permission revocation function is triggered and a security alarm event record is generated, which may include: Step S6.1: Based on the encrypted data range identifier and digital fingerprint binding signature in the temporary access token, the permission range decryption and signature verification are performed through the token parser built into the smart contract to generate real-time permission baseline rules. Step S6.2: Based on the real-time permission baseline rules, compare the access data identifier with the data range of the permission baseline rules to identify out-of-scope access; verify the operation timestamp and validity parameters to determine whether the access is within the validity period; match the operation instruction with the allowed operation set to check whether there is any unauthorized operation; construct the above detection results into a behavior feature vector, and use the association rule engine to determine whether there is a combined out-of-bounds; if any detection fails, trigger an anomaly flag and generate permission out-of-bounds behavior. Step S6.3: Based on the permission overreach behavior, trigger the permission revocation function of the smart contract to immediately terminate the access permissions of the current overreach session and generate a session termination certificate; freeze the validity of the temporary token of the associated account and generate an account freeze status object; Step S6.4: Based on the session termination credential and the account freeze status object, parse the permission revocation execution result and generate a security alarm event record. The record includes: the out-of-bounds behavior type and associated data identifier, the permission revocation operation timestamp and account status, and the business process stage identifier at the time of triggering.

[0089] In this embodiment of the invention, the encrypted data range identifier in the temporary access token is decrypted by the token parser built into the smart contract, and the digital fingerprint binding signature is verified to ensure the legality of the token while generating real-time permission benchmark rules to provide accurate basis for out-of-bounds detection. Based on the real-time permission benchmark rules, single out-of-bounds behaviors are identified from three dimensions: data range, operation timeliness, and operation instructions. The combined out-of-bounds risks are analyzed by the association rule engine to achieve real-time response to dynamic risks. Once an out-of-bounds behavior is detected, the permission revocation function is immediately triggered to terminate the out-of-bounds session and freeze the temporary token of the associated account, accurately isolating the risk. Information such as the out-of-bounds behavior type, data identifier, revocation time, account status, and business stage are recorded on the blockchain to generate security alarm event records. The immutability of the blockchain is used to meet compliance audit requirements, while providing data support for business scenario-based risk analysis.

[0090] In this embodiment of the invention, when applied in a specific way, it can be implemented through the following technical solutions, for example: In step S6.1 above, the temporary access token is split into three parts: header, payload, and signature by the token parser built into the smart contract; the encrypted data range identifier is extracted from the payload, and decrypted using the symmetric key that matches the encryption (such as the AES algorithm key, which is usually derived from the user's public key or the contract's private key) to restore the plaintext data range (such as the sales department's Q2 2025 customer data).

[0091] Extract the digital fingerprint binding signature (such as ECDSA signature result) from the token, and obtain the access control digital fingerprint and dynamic permission configuration set from the payload; use the public key of the smart contract to verify the signature to confirm whether the signature was generated by the corresponding private key and whether the data has been tampered with during transmission. If the verification fails, it is directly determined to be an illegal token.

[0092] Based on the decrypted data range and the verified permission configuration set (such as the operation permission list and time limit parameters), real-time permission baseline rules are generated to clearly define the allowed data access range, operation type and time limit boundaries.

[0093] In step S6.2 above, the data identifier of the current access request (such as data ID, file path) is extracted and matched with the data range identifier (plaintext) in the real-time permission benchmark. If the accessed data exceeds the benchmark range (such as requesting access to the Finance Department's 2025 budget but the permission only allows access to the Sales Department's customer data), it is marked as an out-of-range access anomaly.

[0094] Obtain the operation timestamp from the access request and compare it with the timeliness parameters (effective time and expiration time) in the permission baseline. If the operation time is earlier than the effective time or later than the expiration time, mark it as a timeliness out-of-bounds exception. Parse the operation instructions of the access request (such as modifying or exporting) and compare them with the set of operations allowed by the permission baseline (such as reading-only query). If there is an unauthorized operation (such as holding query permissions but executing export), mark it as an operation out-of-bounds exception.

[0095] The above detection results (data range, timeliness, operation) are converted into binary feature vectors (e.g., [1, 0, 1] represents data out of bounds and operation out of bounds); input into the association rule engine to match the preset combination out of bounds pattern (e.g., data out of bounds + timeliness out of bounds is considered a high-risk attack). If the match is successful, the combination out of bounds anomaly flag is triggered.

[0096] Step S6.3 above triggers the built-in revokePermission(sessionID) function of the smart contract, which immediately terminates all permissions of the session based on the current session ID (carried in the access request); generates a session termination certificate, records the termination time, session ID, out-of-bounds type and other information, and stores it in the blockchain log.

[0097] Parse the address of the account that initiated the access request, find the list of temporary tokens associated with the account from the contract status; mark the valid field of the corresponding token as false, freeze its validity, and generate an account freeze status object (including freeze time and freeze reason); if the out-of-bounds behavior is high-risk (such as combined out-of-bounds behavior), automatically expand the freeze scope: freeze the account's associated sessions in other systems, or temporarily upgrade the approval level of its subsequent access.

[0098] In step S6.4 above, extract key information from the session termination credential and account freeze status objects: out-of-bounds behavior type (out of scope, time limit, operation, combination); associated data identifier (such as data ID, sensitivity level); timestamp of permission revocation operation; account freeze status (freeze duration, unfreeze conditions).

[0099] The smart contract execution engine obtains the business process stage identifier (such as data in use during approval) when the boundary is triggered and adds it to the alarm record; the above information is formatted into a standard alarm record, the record is stored in the immutable log of the blockchain, and an external alarm system (such as SIEM) is triggered to push a notification.

[0100] like Figure 2 As shown, embodiments of the present invention also provide a dynamic permission smart contract generation system based on data sensitivity adaptation, comprising: The classification module is used to classify and label multidimensional data in business scenarios and construct a customer information classification matrix based on data types. The rank matrix module is used to classify data types based on customer information matrices. It uses a decision tree-based rule engine to perform sensitivity quantitative assessment. The engine takes data usage scenarios, legal constraint labels, and timeliness weight labels as inputs, judges according to a preset tree path, and outputs sensitivity results. After traversing all data types, it generates a structured sensitivity rank matrix. The mapping module is used to establish a mapping relationship between data sensitivity and role permissions based on the data sensitivity level matrix and the preset job role permission rules, and generate a dynamic permission policy tree. The module is used to compile the dynamic permission policy tree into executable smart contract code, deploy it to the distributed ledger network, and generate a digital fingerprint for permission control; it also builds smart contract execution entry parameters based on business process stages, timestamp thresholds, and data update events. The dynamic adjustment module is used to dynamically adjust access permissions and generate temporary access tokens when the smart contract execution entry parameters are met, by parsing the current business scenario context through the smart contract execution engine. The logging module is used to perform real-time pattern analysis of data access behavior based on temporary access tokens and through the anomaly detection unit built into the smart contract; when an out-of-bounds permission behavior is detected, the permission revocation function is triggered and a security alarm event record is generated.

[0101] It should be noted that this system is a system corresponding to the above method. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0102] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for generating dynamic permission-based smart contracts based on data sensitivity adaptation, characterized in that, The method includes: Step S1: Classify and label the multidimensional data in the business scenario, and construct a customer information classification matrix based on the data type; Step S2: Based on the data type of the customer information classification matrix, use a decision tree-based rule engine to perform sensitivity quantitative evaluation. The engine takes the data usage scenario, legal constraint label, and timeliness weight label as input, judges according to the preset tree path, outputs the sensitivity result, and generates a structured sensitivity level matrix after traversing all data types. Step S3: Based on the data sensitivity level matrix and the preset job role permission rules, establish a mapping relationship between data sensitivity and role permissions, and generate a dynamic permission policy tree; Step S4: Compile the dynamic permission policy tree into executable smart contract code, deploy it to the distributed ledger network and generate a digital fingerprint for permission control; at the same time, construct smart contract execution entry parameters based on business process stages, timestamp thresholds and data update events; Step S5: When the smart contract execution entry parameters are met, the smart contract execution engine parses the current business scenario context, dynamically adjusts access permissions, and generates a temporary access token. Step S6: Based on the temporary access token, perform real-time pattern analysis on data access behavior through the anomaly detection unit built into the smart contract; when an out-of-bounds permission behavior is detected, trigger the permission revocation function and generate a security alarm event record.

2. The method for generating dynamic permission smart contracts based on data sensitivity adaptation according to claim 1, characterized in that, Step S1: Classify and label the multidimensional data in the business scenario, and construct a customer information classification matrix based on data type, including: Extract multidimensional data from business scenarios and perform dual classification and labeling based on data type dimension and business attribute dimension; Map the marked data types to preset fields to construct a structured matrix with the data subject identifier as the primary key and the data type label as the column attribute; Data source identifiers and business scenario context labels are embedded in the matrix to form a customer information classification matrix containing complete metadata.

3. The method for generating dynamic permission smart contracts based on data sensitivity adaptation according to claim 2, characterized in that, Step S2: Based on the data type of the customer information classification matrix, a sensitivity metric assessment is performed using a decision tree-based rule engine. The engine takes data usage scenarios, legal constraint labels, and timeliness weight labels as input, judges according to a preset tree path, and outputs sensitivity results. After traversing all data types, a structured sensitivity level matrix is ​​generated, including: Extract data type tags, business scenario context tags, and data source identifiers from the customer information classification matrix to generate a basic tag set; The basic tag set is combined with the externally input regulatory constraint factor mapping tags and timeliness weight parameter rule tags to form the complete set of input tags for the rule engine; The entire set of tags is input into the decision tree rule engine, and branch matching results are generated by matching layer by layer through the preset tree rule path. The branch matching results include the scenario risk branch based on the business scenario context tag matching, the compliance constraint branch based on the regulatory constraint factor mapping tag matching, and the timeliness decay or enhancement branch based on the timeliness weight parameter ruleized tag matching. Based on the branch matching results, locate the leaf node at the end of the decision tree and generate the sensitivity determination result for the current data type; Iterate through all data types in the customer information classification matrix, process them independently, aggregate the sensitivity judgment results, and generate a structured data sensitivity level matrix. This matrix inherits the data subject identifier primary key of the original matrix, adds a sensitivity level field, and associates it with scenario, regulation, and timeliness judgment basis tags.

4. The method for generating dynamic permission smart contracts based on data sensitivity adaptation according to claim 3, characterized in that, Step S3: Based on the data sensitivity level matrix and the preset job role permission rules, establish a mapping relationship between data sensitivity and role permissions, and generate a dynamic permission policy tree, including: Load the preset job role permission rule library, which defines: the default operation permissions of each job role for critical, important, and basic sensitive data; the vertical job hierarchy in the organizational structure; and the data isolation boundary rules for cross-departmental collaboration. Based on the data sensitivity level matrix, a set of sensitivity labels is generated. The sensitivity tag set is matched with the permission rule base to output a basic permission mapping table; A dynamic permission policy tree is constructed based on the basic permission mapping table. The dynamic permission policy tree includes vertical hierarchical permission inheritance relationships and horizontal cross-departmental permission isolation rules.

5. The method for generating dynamic permission smart contracts based on data sensitivity adaptation according to claim 4, characterized in that, Step S4: Compile the dynamic permission policy tree into executable smart contract code, deploy it to the distributed ledger network, and generate a digital fingerprint for permission control; Simultaneously, smart contract execution entry parameters are constructed based on business process stages, timestamp thresholds, and data update events, including: Extract permission rule components from the dynamic permission policy tree, including: permission nodes and their associated role identifiers, vertical permission inheritance relationship chain, horizontal cross-departmental isolation rule set, and embedded sensitivity determination basis tags; The permission rule component is transformed into an executable logical unit through a structured transformation algorithm; Executable smart contract code is generated based on executable logic units, deployed to a distributed ledger network, and a unique digital fingerprint for access control is generated. Define business status triggering conditions based on business process stage identifiers, define timeliness triggering conditions based on timestamp thresholds, define data change triggering conditions based on data update event listeners, and construct a set of data access triggering conditions. Bind the digital fingerprint of access control to the set of trigger conditions to form the entry parameters for smart contract execution.

6. The method for generating dynamic permission smart contracts based on data sensitivity adaptation according to claim 5, characterized in that, Step S5: When the smart contract execution entry parameters are met, the smart contract execution engine parses the current business scenario context, dynamically adjusts access permissions, and generates a temporary access token, including: When the smart contract execution entry parameters are met, the latest data sensitivity level matrix is ​​retrieved from the blockchain and parsed to generate a real-time sensitivity field; the current business stage identifier is obtained through the business unit API; the real-time digital fingerprint of the permission request is calculated and compared with the pre-stored fingerprint to generate the permission verification result. Based on a set of key dynamic parameters consisting of real-time sensitivity fields, current business stage identifiers, and permission verification results, dynamic permission adjustment calculations are performed to generate a dynamic permission configuration set. The dynamic permission configuration set is encapsulated as a temporary access token, which includes: an encrypted data range identifier, an operation permission validity parameter, and a digital fingerprint binding signature.

7. The method for generating dynamic permission smart contracts based on data sensitivity adaptation according to claim 6, characterized in that, Step S6: Based on the temporary access token, perform real-time pattern analysis on data access behavior through the anomaly detection unit built into the smart contract; When an out-of-bounds permission violation is detected, the permission revocation function is triggered and a security alert event log is generated, including: Based on the encrypted data range identifier and digital fingerprint binding signature in the temporary access token, the permission range decryption and signature verification are performed through the token parser built into the smart contract to generate real-time permission baseline rules. Based on real-time permission baseline rules, the system compares the access data identifier with the data range of the permission baseline rules to identify out-of-scope access; verifies the operation timestamp and validity parameters to determine whether the access is within the validity period; matches the operation instruction with the set of allowed operations to check for unauthorized operations; constructs the above detection results into a behavior feature vector, and uses the association rule engine to determine whether there is a combined out-of-bounds; if any detection fails, an anomaly flag is triggered, and permission out-of-bounds behavior is generated. Based on the out-of-bounds permission behavior, the smart contract's permission revocation function is triggered to immediately terminate the access permissions of the current out-of-bounds session and generate a session termination certificate; the validity of the temporary token of the associated account is frozen and an account freeze status object is generated. Based on the session termination credential and the account freeze status object, the permission revocation execution result is parsed to generate a security alarm event record. The record includes: the type of out-of-bounds behavior and associated data identifier, the permission revocation operation timestamp and account status, and the business process stage identifier at the time of triggering.

8. A dynamic permission smart contract generation system based on data sensitivity adaptation, wherein the system implements the method as described in any one of claims 1 to 7, characterized in that, include: The classification module is used to classify and label multidimensional data in business scenarios and construct a customer information classification matrix based on data types. The rank matrix module is used to classify data types based on customer information matrices. It uses a decision tree-based rule engine to perform sensitivity quantitative assessment. The engine takes data usage scenarios, legal constraint labels, and timeliness weight labels as inputs, judges according to a preset tree path, and outputs sensitivity results. After traversing all data types, it generates a structured sensitivity rank matrix. The mapping module is used to establish a mapping relationship between data sensitivity and role permissions based on the data sensitivity level matrix and the preset job role permission rules, and generate a dynamic permission policy tree. The module is used to compile the dynamic permission policy tree into executable smart contract code, deploy it to the distributed ledger network, and generate a digital fingerprint for permission control; it also builds smart contract execution entry parameters based on business process stages, timestamp thresholds, and data update events. The dynamic adjustment module is used to dynamically adjust access permissions and generate temporary access tokens when the smart contract execution entry parameters are met, by parsing the current business scenario context through the smart contract execution engine. The recording module is used to perform real-time pattern analysis of data access behavior based on temporary access tokens and through the anomaly detection unit built into the smart contract. When an out-of-bounds permission behavior is detected, the permission revocation function is triggered and a security alert event record is generated.

9. A computing device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images