A dynamic permission smart contract generation method and system based on data sensitivity adaptation

Abstract

The application provides a kind of based on data sensitivity adaptive dynamic permission smart contract generation method and system, it is related to data security technical field, the method includes: the multi-dimensional data in business scenario is classified and marked, constructs customer information classification matrix according to data type;Based on the data type of customer information classification matrix, sensitivity quantification evaluation is carried out using rule engine based on decision tree, engine uses data use scene, regulation constraint label, timeliness weight label as input, judges according to preset tree path, outputs sensitivity result, generates structured sensitivity level matrix after traversing all data types;According to data sensitivity level matrix, in combination with the post role permission rule of preestablished, the mapping relationship of data sensitivity and role permission is established, and dynamic permission strategy tree is generated.The application balances data security and improves protection capability through data classification and sensitivity evaluation.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data security, in particular to a dynamic permission smart contract generation method and system based on data sensitivity adaptation. BACKGROUND

[0002] With the development of digital business, data security and permission management face many challenges; some traditional data classification relies on static rules, which may have many problems in actual application.

[0003] Taking the financial industry as an example, customers' transaction data will change over time and market environment, and new transaction types and risk patterns will emerge; but static classification rules cannot timely include these newly emerging high-risk transaction data into the scope of key supervision, which may lead to ineffective protection of sensitive data. Current permission management is sometimes static, and manual authorization may lead to inefficiency, and in large enterprises, such as financial department expense approval, multi-level permission configuration from grassroots employees to senior management in vertical business processes, there is a lot of repetitive work due to manual operation, which not only wastes manpower and time, but also is prone to errors. SUMMARY

[0004] The technical problem to be solved by the present application is to provide a dynamic permission smart contract generation method and system based on data sensitivity adaptation, which balances data security and improves protection capability through data classification and sensitivity evaluation.

[0005] To solve the above technical problems, the technical solution of the present application is as follows:

[0006] In a first aspect, a dynamic permission smart contract generation method based on data sensitivity adaptation, the method comprising:

[0007] Step S1: classifying and marking multi-dimensional data in a business scenario, and constructing a customer information classification matrix according to data types;

[0008] Step S2: based on the data types of the customer information classification matrix, using a rule engine based on a decision tree to perform sensitivity quantitative evaluation, the engine taking data usage scenarios, regulatory constraint labels, and time effectiveness weight labels as inputs, judging according to a preset tree path, outputting sensitivity results, and generating a structured sensitivity level matrix after traversing all data types;

[0009] Step S3: according to the data sensitivity level matrix, combining preset post role permission rules, establishing a mapping relationship between data sensitivity and role permissions, and generating a dynamic permission strategy tree;

[0010] Step S4: compiling the dynamic permission policy tree into executable smart contract code, deploying it to the distributed ledger network and generating a permission control digital fingerprint; at the same time, constructing smart contract execution entry parameters based on business process stages, timestamp thresholds and data update events;

[0011] Step S5: when the smart contract execution entry parameters are met, the current business scenario context is analyzed by the smart contract execution engine, the access permission is dynamically adjusted, and a temporary access token is generated;

[0012] Step S6: based on the temporary access token, the data access behavior is analyzed in real time by the exception detection unit built in the smart contract; when the permission boundary behavior is detected, the permission revocation function is triggered and a security alarm event record is generated.

[0013] The second aspect is a dynamic permission smart contract generation system based on data sensitivity adaptation, comprising:

[0014] The classification module is used for classifying and marking multi-dimensional data in the business scenario, and constructing a customer information classification matrix according to the data type;

[0015] The level matrix module is used for sensitivity quantification evaluation based on the data type of the customer information classification matrix, using a decision tree-based rule engine. The engine takes data usage scenarios, regulatory constraint labels, and time effectiveness 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.

[0016] The mapping module is used to establish a mapping relationship between data sensitivity and role permission according to the data sensitivity level matrix and combining preset post role permission rules, and generate a dynamic permission policy tree;

[0017] The construction module is used for compiling the dynamic permission policy tree into executable smart contract code, deploying it to the distributed ledger network and generating a permission control digital fingerprint; at the same time, constructing smart contract execution entry parameters based on business process stages, timestamp thresholds and data update events;

[0018] The dynamic adjustment module is used for dynamically adjusting access permissions and generating temporary access tokens when the smart contract execution entry parameters are met, by analyzing the current business scenario context through the smart contract execution engine.

[0019] The recording module is used for real-time pattern analysis of data access behavior based on the temporary access token through the exception detection unit built in the smart contract; when the permission boundary behavior is detected, the permission revocation function is triggered and a security alarm event record is generated.

[0020] The third aspect is a computing device, comprising:

[0021] one or more processors;

[0022] a memory device storing one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method.

[0023] In a fourth aspect, a computer-readable storage medium stores a program, which when executed by a processor, implements the method.

[0024] The above scheme of the present application at least has the following beneficial effects:

[0025] By constructing a customer information classification matrix, multi-dimensional data is structured and managed, the problem of data fragmentation is solved, a unified framework is laid for subsequent operations, and a dynamic sensitivity quantification system is formed by using a decision tree engine to integrate data use scenarios, regulatory constraints, timeliness and other factors, so that the evaluation result meets the compliance requirements; a fine-grained mapping mechanism of data sensitivity and role permissions is established through a dynamic permission policy tree, automatic execution of the least privilege principle is realized, and the smart contract and temporary token mechanism are matched, so that the permissions can be dynamically adjusted according to the business process stage, the timestamp threshold and the data update event, and the safety and cooperation efficiency are balanced; the permission policy is compiled into a smart contract and deployed to a distributed ledger, the consistency of the permission rule execution is ensured by using the tamper-proof feature of the blockchain, the management cost and human error are reduced by combining the automatic real-time execution capability of the smart contract; the real-time boundary crossing behavior blocking is realized through the built-in exception detection unit of the smart contract, and the unalterable audit traceability system is formed by combining the boundary crossing record and the permission control digital fingerprint stored on the chain, so as to meet the compliance requirements. BRIEF DESCRIPTION OF DRAWINGS

[0026] Figure 1 is a flowchart of a dynamic permission smart contract generation method based on data sensitivity self-adaptation provided by an embodiment of the present application.

[0027] Figure 2 is a schematic diagram of a dynamic permission smart contract generation system based on data sensitivity self-adaptation provided by an embodiment of the present application. DETAILED DESCRIPTION

[0028] Exemplary embodiments of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings; however, they are not limited to the embodiments set forth herein but can be implemented in various forms. The present disclosure should not be construed as being limited to the embodiments set forth herein and thus should be defined by the scope of the claims and their equivalents. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the present disclosure to those skilled in the art.

[0029] As Figure 1As 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:

[0030] Step S1: Classify and label the multidimensional data in the business scenario, and construct a customer information classification matrix based on the data type;

[0031] 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.

[0032] 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;

[0033] 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;

[0034] 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.

[0035] 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.

[0036] 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.

[0037] In a preferred embodiment of the present application, the step S1 of classifying and marking the multi-dimensional data in the business scenario, constructing a customer information classification matrix according to the data type, can include:

[0038] Step S1.1, extracting multi-dimensional data from the business scenario, and classifying and marking based on data type dimensions and business attribute dimensions;

[0039] Step S1.2, mapping the marked data type to a preset field, and constructing a structured matrix with the data subject identifier as the primary key and the data type label as the column attribute;

[0040] Step S1.3, embedding data source identifiers and business scenario context labels in the matrix to form a customer information classification matrix containing complete metadata.

[0041] In the embodiment of the present application, the dual-dimension classification can improve the classification accuracy, avoid data ownership ambiguity caused by a single standard, and the business attribute dimension can directly associate the data needs of different departments, improving the cross-department data collaboration efficiency; when constructing the structured matrix, the preset field mapping realizes standardized management foundation, ensuring data format uniformity, and using the data subject identifier as the primary key can optimize data retrieval efficiency, and inputting the customer ID can retrieve all classified data; after embedding the data source identifiers and business scenario context labels in the matrix, the data traceability capability can be enhanced, the data collection path can be traced through the source identifier, and the compliance audit requirements can be met.

[0042] In the embodiment of the present application, when specifically applied, the following technical solutions can be used to achieve it, for example:

[0043] The above step S1.1 collects original data from a business system (such as CRM, ERP), including multi-dimensional data such as customer basic information (name, ID number), transaction records (order amount, time), behavior logs (browsing track, operation frequency), etc.; dividing types according to data attributes, for example: personal privacy data (biological characteristics, bank account), business data (purchase contract, pricing strategy), operation data (login log, permission change record); annotating according to the data belonging to the business scenario, for example: sales business (customer contact information, order data), financial business (income and expenditure records, invoice information), compliance business (identity verification materials, regulatory reporting documents).

[0044] The preset process of the preset field in the above step S1.2 is constructed based on a hierarchical field system of business scenarios and data types. The top-level classification takes enterprise core business blocks (such as sales, finance, and compliance) and data sensitivity levels (public, internal, and confidential) as top-level dimensions to form a basic framework of field classification, for example: top-level field classification: personal information, transaction data, business log, and compliance file; the middle-level field subdivision further splits the data attributes or business process links under the top-level classification, for example: personal information subdivision: basic information (name, ID number), contact information (mobile phone number, email), and biological characteristics (fingerprint, face data); transaction data subdivision: financial information (order amount, payment method), and logistics information (delivery address, delivery status); the bottom-level field definition is the standard naming and format of specific data items to ensure uniqueness, for example: bottom-level fields: personal information_basic information_name, and transaction data_financial information_amount.

[0045] For the sensitive data types (such as personal biological characteristics and financial account information) specified in the A Information Protection Law and the B Security Law, the corresponding classification is defined in the preset field, the data classification specifications (such as ISO27001 and HIPAA) of the financial and medical industries are referred to, and the field hierarchy is adjusted, for example: the medical industry preset field needs to include health data_diagnosis record_disease name, which meets the patient privacy protection standard.

[0046] Other class or custom classification nodes are set in the top-level or middle-level fields to allow the addition of new fields when the business changes, for example: when the enterprise adds blockchain transaction hash value data, the blockchain hash value field can be added under transaction data_other transaction information; the version number is recorded for changes to the preset field (such as field renaming and hierarchy adjustment).

[0047] The specific execution process of the preset field mapping is as follows:

[0048] The forward mapping matches the data classification label (such as customer name belongs to personal information_basic information) to the corresponding node of the preset field; the reverse verification checks the compliance of the data to be mapped through the semantic definition of the preset field (such as personal information_basic information_name requires field value to be Chinese characters or letter combinations); for data that may belong to multiple fields (such as customer email belongs to both contact information and marketing data), the business attribute label is used for priority matching, for example: if the customer email is used for user registration scenarios, it is mapped to personal information_contact information_email; if it is used for marketing push, it is mapped to marketing data_customer reach_email.

[0049] The mapping engine core logic reads the classified marked data (such as the order amount marked as transaction data_financial information); searches for a matching field path (transaction data_financial information_amount) in a preset field library; verifies the data format (such as the order amount which needs to be a numerical type, meeting the decimal(10,2) format requirement of the preset field); completes the mapping and records the mapping relationship (such as the binding record of the data item order amount and the field transaction data_financial information_amount); and provides a manual review interface for a complex mapping scenario (such as the field matching after unstructured data text analysis), allowing a data administrator to adjust the mapping path.

[0050] The mapped data is converted according to the format requirement of the preset field (such as the identity card number is unified to 18 digits, and the mobile phone number is prefixed with the country code); and it is checked whether the mapped data is filled in all the required items of the preset field (such as the personal information_basic information_name is required, and an exception alarm is triggered when the data is not mapped).

[0051] The above step S1.3, the data source identifier embedding is to add a data source mark in the matrix, for example: marking that the customer's identity card number is from the public security system verification interface, and the transaction record is from the payment system log; recording the specific business link of data generation, for example: the context label of the customer's identity card number is account registration-identity verification, and the label of the order amount is transaction payment-settlement link; associating the source identifier, the context label with the data subject and the type label to form a matrix record containing complete metadata.

[0052] In a preferred embodiment of the present application, the above step S2: based on the data type of the customer information classification matrix, the sensitivity quantification evaluation is performed by using a decision tree-based rule engine, the engine takes the data use scenario, the regulation constraint label, and the 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, which can include:

[0053] Step S2.1, extracting the data type label, the business scenario context label, and the data source identifier from the customer information classification matrix to generate a basic label set;

[0054] Step S2.2, combining the basic label set with the regulation constraint factor mapping label and the timeliness weight parameter regularization label input from outside to form a rule engine input label full set;

[0055] Step S2.3, inputting the label full set into the decision tree rule engine, generating branch matching results through preset tree rule paths layer by layer, and the branch matching results include a scenario risk branch matched based on the business scenario context label, a regulation constraint branch matched based on the regulation constraint factor mapping label, and a timeliness attenuation or enhancement branch matched based on the timeliness weight parameter regularization label.

[0056] Step S2.4, according to the branch matching result, locate to the end leaf node of the decision tree, and generate the sensitivity judgment result of the current data type;

[0057] Step S2.5, traverse all data types of the customer information classification matrix, independently process and aggregate the sensitivity judgment results, and generate a structured data sensitivity level matrix, which inherits the data subject identifier primary key of the original matrix, adds a sensitivity level field, and is associated with scene, regulation and time effectiveness judgment basis labels.

[0058] In the embodiment of the present application, the multi-dimensional label extraction can guarantee the integrity of the label, provide comprehensive basic information for sensitivity evaluation, and expand the evaluation dimension by business scene and source identification to associate different risk scenes. The automatic matching of regulation constraint labels can realize the automatic embedding of compliance, prevent manual omission of special protection labels of biometric data and other compliance requirements, reduce legal risks, and introduce a dynamic time dimension through the time effectiveness weight to make the evaluation result change with data updates. Through the multi-dimensional risk hierarchical evaluation of the decision tree branch, the regulations, scenes and time factors are hierarchically judged to avoid single-dimensional evaluation deviation caused by only considering regulations and ignoring scene risks. The tree path makes the evaluation logic visualized and traceable to each step of judgment basis. At the same time, the associated judgment basis labels enhance the result interpretability, and finally realize the global sensitivity visualization in the form of a matrix to intuitively present the proportion of enterprise high-sensitive data, risk concentration points of each business line and the sensitivity distribution of all data.

[0059] In the embodiment of the present application, when specifically applied, the following technical solutions can be used to realize it, for example:

[0060] The above step S2.1 reads the data type label column (such as personal privacy data, transaction data) from the customer information classification matrix, groups and aggregates them according to the data subject identifier (primary key) to form the type identifier of each data item, for example: the type label of the ID number data of the customer ID C001 is personal information_ identity verification_ ID number; the business scene context label field (such as opening registration-identity verification, transaction payment-settlement link) is extracted from the matrix, the scene link (such as opening registration) and the operation type (such as identity verification) are split; the data source identifier (such as the public security system verification interface, the payment system log) is read to record the system or interface name of the data collection path; the three types of labels are combined according to the data subject-data type-scene-source dimension to generate a JSON format basic label set.

[0061] The above step S2.2, the basic regulation layer is to collect national general regulations, such as “B safety law” “A information protection law”, and the constraint range is divided according to the data type, for example: the A information protection law clearly stipulates that sensitive personal information includes biological characteristics, financial accounts, etc. The corresponding regulation constraint label is required to be anonymized and stored for less than 3 years; the industry regulation layer is subdivided according to the industry (finance, medical care, education, etc.), and specific requirements are superimposed, for example: the financial industry “Banking financial institution data security management method” requires that customer transaction data needs to be encrypted and transmitted across borders, and cross-border transmission needs to be security evaluated; the medical industry “Health medical data management method” stipulates that medical record data needs to be stored on the blockchain and accessed by double-factor authentication.

[0062] Data type-regulation clause mapping: a many-to-many mapping relationship is established, for example:

[0063]

[0064] Convert the regulation clauses into executable labels, for example: personal sensitive information needs to be security evaluated for export → label cross-border transmission needs to be security evaluated; financial data needs to be implemented with hierarchical protection → label needs to be managed with sensitivity grading.

[0065] Dynamic matching process of data type and regulation:

[0066] Extract the data type (such as ID number, bank account) from the basic label set, match the data type column of the regulation mapping table, for example: the data type is ID number, locate to the Nth clause of “A information protection law”, and get the basic constraint label “need to be anonymized and stored for less than 3 years”; check whether the matched regulation clause covers all the required constraints (such as whether it contains the requirements of storage, transmission and use), if not, trigger a warning (such as if a regulation does not define deletion rules, prompt manual supplement of labels).

[0067] According to the business scenario context label or enterprise attribute (such as financial enterprise identification), judge whether it is necessary to superimpose industry regulations, for example: if the data belongs to financial transaction records and the enterprise is a bank, trigger the “Banking data security method” matching; if the data is patient medical records and the enterprise is a hospital, trigger the “Health medical data management method” matching; add industry-specific requirements to the basic regulation label, for example: the basic label of bank account information is anonymized, superimposed with the industry label transmission encryption transaction trace, and the final constraint label set is {anonymized, stored for less than 3 years, transmission encrypted, transaction trace}.

[0068] Combine the basic regulation label, industry label, and regional label according to the link + action + requirement format, for example: the final label of the data type bank account information is: storage period ≤3 years, storage encryption; cross-border transmission needs to be security evaluated and transmission encrypted; access needs double-factor authentication; check whether the label meets the regulation original text expression,

[0069] The mapping relationship of the data type-regulatory clause-constraint label is recorded to the blockchain.

[0070] The time decay rule configuration is to set the weight according to the data update frequency (such as transaction data with a weight of 1.0 for nearly 7 days, a weight of 0.5 for 8-30 days, and a weight of 0.2 for more than 30 days); the business cycle association is to set the weight to 1.0 within 1 month after the release of seasonal data (such as quarterly financial reports), and then decay to 0.3.

[0071] The basic label is combined with the regulatory constraint label and the timeliness weight label to form a three-dimensional label set containing data attributes-compliance requirements-time factors.

[0072] The above step S2.3 is the core rule system construction of the decision tree engine:

[0073] After the root node receives the full set of labels, it is forced to prioritize the regulatory constraint label to ensure that the compliance requirement is the primary condition for sensitivity evaluation, for example: if the data type matches the sensitive personal information in Article N of the A Information Protection Law, regardless of the scene or timeliness, it directly enters the high-sensitive data evaluation path; the condition of each branch node needs to cover all possible label states to avoid blind areas where labels cannot be matched.

[0074] The branch condition supports and, or logical combination, for example: the trigger condition of the high-risk scene of the second branch is that the scene label contains online transaction and the scene label contains cross-border transmission; in the timeliness branch, set the weight threshold as the branch condition, and if it exceeds the threshold, the sensitivity enhancement (such as +1 level) is triggered.

[0075] High-risk scenarios (such as online transactions) or high timeliness weights (nearly 7 days) trigger sensitivity level increase, with an increment of 1 level each time (such as from level 3 to level 4); historical data (more than 180 days) or low-risk scenarios (offline archiving) trigger sensitivity level decrease, with a decay of 1-2 levels each time.

[0076] The hierarchical design of the preset tree rule path:

[0077] Receive the full set of labels containing regulatory constraint labels, scene labels, and timeliness labels, and extract the sensitive level key field (such as high sensitivity general) in the regulatory constraint label.

[0078] First-level branch division:

[0079] Branch A is the high-sensitive data branch, and the regulatory constraint label contains keywords such as high-sensitive personal information confidential data that need to be anonymized, such as ID number and bank account information, which enter this branch due to the regulatory label trigger;

[0080] Branch B is a general data branch, the regulatory label does not mark the sensitivity level, or belongs to public data non-sensitive business data, such as: customer browsing records, public product introduction data into this branch.

[0081] Secondary branch (scene risk dimension):

[0082] Sub-branch under branch A (high sensitive data):

[0083] Branch A1 is a high-risk scene branch, the scene label contains keywords such as online transmission cross-border transaction third-party sharing, the sensitivity level +1 level, for example: ID number for online account opening-cross-border authentication scene, triggering this branch;

[0084] Branch A2 is a medium-risk scene branch, the scene label contains keywords such as internal system storage inter-department sharing, the sensitivity level remains unchanged, for example: ID number stored in enterprise internal CRM system, triggering this branch;

[0085] Branch A3 is a low-risk scene branch, the scene label contains keywords such as offline archiving personal use, the sensitivity level -1 level, for example: historical ID number has been offline archived, triggering this branch.

[0086] Sub-branch under branch B (general data):

[0087] Branch B1 is a business critical scene branch, the scene label contains keywords such as core business process financial settlement, the sensitivity level +1 level (such as from level 1 to 2);

[0088] Branch B2 is a normal scene branch, the scene label is auxiliary record non-core business, and the level remains unchanged.

[0089] Three-level branch (time effectiveness dimension):

[0090] Sub-branch under branch A1 (high sensitive-high risk scene):

[0091] Branch A 1-1 is a real-time data branch, the time effectiveness weight label ≥0.8 (such as updated within 7 days), the level +1 level (such as from level 4 to level 5), for example: ID number data of online transaction in the past 3 days;

[0092] Branch A 1-2 is a recent data branch, 0.5≤time effectiveness weight<0.8 (such as updated within 8-30 days), the level remains unchanged (maintain level 4);

[0093] Branch A 1-3 is a historical data branch, the time effectiveness weight <0.5 (such as not updated for more than 30 days), the level -1 level (from level 4 to level 3).

[0094] Parameterized configuration of preset path:

[0095] Branch condition parameters are configurable, such as trigger keywords of high-risk scenarios can be added through the management background (such as adding cloud storage scenario labels), without modifying the code; time limit weight threshold (such as 0.8), and grade adjustment amplitude (plus 1 level) can be dynamically configured according to business needs (such as setting to plus 2 level in the financial industry).

[0096] When multiple branch conditions are met at the same time, the priority is executed according to the regulation, followed by the scenario, and then the time limit, for example: data triggers high sensitivity and low risk scenarios at the same time, and the high sensitivity branch is processed first, and the scenario risk is only adjusted slightly; each time the preset path is modified, a new version is generated, and the historical data evaluation record retains the old version path to ensure traceability consistency.

[0097] Tree path matching example of typical data types, for example: online account opening-identity card number data in the past 3 days, high sensitive personal information label under regulations→enter branch A (high sensitive data), online account opening scenario label contains online transmission keywords→enter branch A1 (high risk scenario), sensitivity level is temporarily set to level 5 (plus 1 level) from the basic level 4; time limit label in the past 3 days weight 1.0≥0.8→enter branch A 1-1 (real-time data), sensitivity level plus 1 level→final level 6 (assuming the highest is 6); root node→A→A1→A 1-1 Corresponding judgment basis: high sensitivity required by regulations + online high-risk scenario + real-time data.

[0098] The above step S2.4, the preset leaf node corresponds to the sensitivity level (such as high sensitivity-high risk-real-time corresponding to level 4, general data-low risk-history corresponding to level 1); branch matching result and leaf node mapping: according to the final branch path (such as compliance→high sensitivity→scenario risk→online transaction→time limit→in the past 3 days), locate to the corresponding leaf node, and get the sensitivity level (such as level 4); record the key labels that trigger this level (such as regulations: article N of A information protection law, scenario: online account opening transmission risk, time limit: nearly 3 days).

[0099] The above step S2.5, according to the primary key of the customer information classification matrix (such as customer ID), the steps S2.1 to S2.4 are executed independently for each data type (such as identity card number order amount) to generate the corresponding sensitivity level; add a sensitivity level field (such as numerical value 1-5) in the original matrix, and add a judgment basis label set field (store regulations, scenario, and time limit labels); aggregate the sensitivity levels of all data types, check whether there are any uncovered data items (such as missing some business data), and generate a complete structured matrix.

[0100] In a preferred embodiment of the present application, the step S3 of establishing a mapping relationship between data sensitivity and role permission according to the data sensitivity level matrix and combining the preset post role permission rule to generate a dynamic permission policy tree can include:

[0101] Step S3.1, load the preset post role permission rule library, which defines: the default operation permission of each post role to the key level, important level and basic level sensitive data; the vertical position level relationship in the organizational structure; the data isolation boundary rule for cross-department collaboration;

[0102] Step S3.2, according to the data sensitivity level matrix, analyze and generate a sensitivity label set;

[0103] Step S3.3, match the sensitivity label set with the permission rule library, and output a basic permission mapping table;

[0104] Step S3.4, based on the basic permission mapping table, construct a dynamic permission policy tree, which includes vertical level permission inheritance relationship and horizontal cross-department permission isolation rule.

[0105] In the embodiment of the present application, the preset post role permission rule library can realize the standardization of permission management, avoid the randomness of permission allocation, ensure the consistency of the same post permission, and automatically process the permission inheritance of the position level relationship, reduce the amount of manual configuration, and the clear cross-department isolation rule can prevent sensitive data from leaking across departments; the structured sensitivity label set can improve the permission matching efficiency, support quick positioning of corresponding permissions through key level labels, reduce matching time, and the judgment basis such as the provisions of laws and regulations attached to the label can make the permission allocation result interpretable; based on the two-way matching of sensitivity and role, the permission can be accurately allocated, ensuring that the principle of least privilege is implemented, and the preset conflict resolution rule can also standardize the conflict processing; the dynamic permission policy tree has dynamic adaptability of permission, which improves business efficiency while ensuring safety, and its tree structure can visualize the permission audit, which is convenient for auditors to quickly locate the permission abnormal conditions such as employees accessing cross-department data without permission, and the built-in cross-department isolation and level inheritance logic can automatically check compliance, ensuring that the permission allocation meets the organizational structure and GDPR minimum permission principle and other regulatory requirements.

[0106] In the embodiment of the present application, when specifically applied, the following technical solutions can be used to realize, for example:

[0107] The above step S3.1, the preset post role permission rule library is mainly systematized by the following dimensions, which deeply binds the post role, data sensitivity, operation permission and organizational structure relationship to form a structured permission control system, as follows:

[0108] Post permission preset based on data sensitivity, the rule base divides data into different sensitivity levels such as basic level, important level, and key level, each level corresponds to different access control strength; for each post role (such as sales manager, financial director, etc.), it is clear that its operation permission for different level data, for example: sales manager: basic level data can be executed query, export; important level data can only be queried; key level data has no any permission; financial director: important level data related to finance can be modified and exported, key level budget data can be read and approved; compliance officer: all department key level compliance files can be read and audited, but no modification permission; rule base covers multiple operation permission types, including read, write, modify, delete, export, share, approve, audit, etc., each permission corresponds to a specific data operation scenario.

[0109] Permission inheritance rules based on organizational structure, the rule base loads the vertical hierarchy in the organizational structure (such as ordinary employee → department supervisor → director → senior manager), establishes clear superior-inferior permission inheritance logic; automatic inheritance is that high-level positions automatically inherit all permissions of low-level positions, for example, department supervisors inherit the query and export permissions of ordinary employees; permission expansion is that high-level positions additionally obtain specific permissions, such as department supervisors can add approval permissions, directors can add cross-department data coordination permissions; the rule base allows setting permission exceptions for special positions, for example, although senior managers inherit all subordinate permissions, some core data (such as board resolutions) need to be authorized separately.

[0110] Cross-department data access isolation rules, the rule base clearly defines data access restrictions between different departments to avoid cross-department overreach, for example: the sales department is prohibited from accessing key level budget data in the finance department regardless of its position level; the market department's important level customer research data is only allowed to be read by the R&D department, and export or modification is prohibited; for necessary cross-department collaboration scenarios, the rule base sets up a temporary authorization mechanism, for example: when the R&D department needs to access the sales department's important level customer data for a project, it needs to obtain temporary read permission through a compliance approval process, and the permission will be automatically revoked when the validity period ends.

[0111] The rule base takes post role-data sensitivity-operation permission-organizational level-department boundary as the core dimension, forms a multi-dimensional associated data table, which is convenient for quick query and permission matching; when the organizational structure is adjusted (such as adding new positions, department restructuring) or the data sensitivity is changed, the rule base can be manually updated by the administrator or automatically synchronized by the system, ensuring that the permission rules are consistent with the actual business needs; the rule base has preset built-in verification logic to avoid permission conflicts and comply with B security regulations.

[0112] Step S3.2: Read the sensitivity level field (e.g., numerical 1-5 levels) from the data sensitivity level matrix, convert it to a label according to the preset mapping, for example: level 4-5 → critical level, level 2-3 → important level, level 1 → basic level; generate a set containing sensitivity labels + judgment basis for each data type, for example: the label set of data ID number: [critical level, regulatory requirements + high-risk scenarios + real-time data]; check if the label covers all data types (e.g., no omissions) and verify the accuracy of the level conversion (e.g., whether level 5 is correctly mapped to the critical level).

[0113] Step S3.3: The matching process of the sensitivity label set and the permission rule library is implemented through a vertical and horizontal two-way verification mechanism, and finally a structured mapping table is generated to intuitively present the correspondence between the post role and the data permission.

[0114] The core logic of label-rule two-way matching: vertical matching is the permission mapping of post role multiplied by sensitivity label. Taking post role and sensitivity label as coordinates, the default permission is directly read from the rule library; for example, financial director, sales manager, etc., corresponding to the position identity in the organizational structure, such as critical level, important level, and basic level, indicating the security level of data; when the user is a financial director, accessing financial data with a critical level label, the vertical matching rule library concludes: permission to read, modify, and approve; if a sales manager accesses important level customer data, the vertical matching result is: only query permission.

[0115] Horizontal matching is cross-department permission isolation verification, based on department affiliation and cross-department rules, verifying whether the current post has permission to access target data across departments, determining the main department to which the post belongs (e.g., financial director belongs to the finance department), and the preset department-to-department data access prohibition clause in the rule library (e.g., sales department cannot access critical level data in the finance department); if the financial director tries to access critical level data in the sales department, the horizontal matching will trigger the cross-department rule: first confirm that the financial director's department is the finance department, and the target data belongs to the sales department; according to the rule library, the finance department needs additional approval to access critical level data in the sales department, so the default permission does not take effect.

[0116] Conflict resolution mechanism: When multiple permission rules are met at the same time and there is a conflict between the rules (such as a position that manages two departments), trigger the conflict resolution logic, for example: a director who belongs to both the sales department and the finance department may have conflicting rules when accessing key-level data in the sales department; if the position belongs to the department where the target data is located, the department's permission rules will be applied first, rather than the cross-department rules, for example: a director who manages both sales and finance accessing key-level data in the sales department, as a member of the sales department, the sales department's internal permission rules will be applied (such as no permission), rather than the cross-department rules which require approval; if the conflict involves position levels (such as senior managers and ordinary employees), senior-level permissions can override lower-level restrictions, but the principle of least privilege must be followed.

[0117] Structure design of mapping table: row dimension is position role (such as sales manager, finance director); column dimension is data sensitivity label (key level, important level, basic level); cell content is the allowed operation permission of the corresponding position for the level data (such as read, modify no permission).

[0118] Example table:

[0119]

[0120] Extract position role-sensitivity label-operation permission triple data from rule library, fill in row and column dimensions; cross-department rules and permission conflict resolution results will affect the final cell content (such as cross-department access requires approval); when the permission rules, position roles or sensitivity labels in the rule library change, the mapping table is automatically updated to ensure that the permission configuration takes effect in real time.

[0121] Directly display the permission boundaries of each position, making it easy for administrators to quickly query and audit; the system can directly read mapping table data to implement real-time permission verification for user operations (such as prohibiting sales managers from exporting key-level data).

[0122] Overall process of matching and mapping: input position role, data sensitivity label and department affiliation information, match the rule library vertically to get default permissions, check cross-department rules horizontally, adjust permissions, handle permission conflicts, and determine the final permissions; generate a position-sensitivity-permission mapping table for permission control and management.

[0123] The above step S3.4, dynamic permission strategy tree is constructed by integrating vertical level, horizontal isolation and dynamic factors, forming a three-dimensional structure with permission inheritance, department blocking and scene adaptation capabilities, its construction process takes position role as node, organization structure as skeleton, combines with business scene to dynamically inject permission variables, forms a real-time adjustable permission control network, as follows:

[0124] Take the post role in the organizational structure as the tree node, and construct the vertical level according to the level of the position. The root node: senior management (such as CEO, CFO), the second node: department director (such as sales director, financial director), the third node: department supervisor (such as sales department supervisor, financial supervisor), and the leaf node: ordinary employee.

[0125] The child node inherits all the permissions of the parent node by default, for example: the sales supervisor inherits the data query permission of the sales officer; the high-level node can add exclusive permissions, for example: the sales supervisor adds the permission to approve the data export application of the subordinate, and the financial director adds the permission to modify the department budget data.

[0126] Add an isolation layer between the node branches of different departments to block cross-department data access by default, for example: there is a cross-department blocking node between the sales department node and the financial department node, which prevents the sales manager from directly accessing the key-level data of the financial department; a read-only blocking node is set between the R&D department and the marketing department nodes, allowing R&D personnel to read important-level data in the marketing department, but prohibiting modification.

[0127] When a user accesses cross-department data, the strategy tree checks whether there is a blocking node in the path: if there is and no additional authorization, directly refuse access (such as the sales manager accessing the financial budget data triggering the blocking); if there is but passes the approval process, temporarily bypass the blocking node (such as the R&D director accessing the market customer data after applying).

[0128] Business scenario factors trigger permission adjustments for scenarios such as temporary projects and cross-department collaboration, for example: when the sales manager participates in the temporary reconciliation project of the financial department, the system injects a temporary financial collaboration factor, opening the read-only permission of the important-level data in the financial department; the time factor sets the validity period of the permission, for example: the temporary permission takes effect after the approval is passed, and automatically expires after 72 hours; the operation context factor dynamically adjusts according to the user's operation behavior, for example: when the user tries to export a large amount of data, the approval level is automatically upgraded.

[0129] Receive external input factor parameters through the dynamic nodes of 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 post node in the strategy tree (such as sales manager → financial temporary read-only); when the factor expires, the temporary node is automatically removed from the strategy tree, and the permission returns to the default.

[0130] When the organizational structure is adjusted (such as adding a new department) or the permission rules are modified, the strategy tree automatically reconfigures the node relationship, for example: after adding the compliance department, the strategy tree adds a compliance director node under the senior management layer and establishes cross-department blocking rules with other department nodes; when a dynamic factor is injected, the strategy tree automatically checks whether it conflicts with the existing rules: if the temporary permission conflicts with the default permission (such as temporarily allowing modification of prohibited data), it is overridden according to the dynamic factor priority principle, but conflict logs are recorded for auditing.

[0131] In a preferred embodiment of the present application, the step S4 of compiling the dynamic permission policy tree into executable smart contract code, deploying to the distributed ledger network and generating the permission control digital fingerprint; while constructing the smart contract execution entry parameter based on the business process phase, timestamp threshold and data update event, can include:

[0132] Step S4.1, extract the permission rule components from the dynamic permission policy tree, including: permission nodes and their associated role identifiers, vertical permission inheritance relationship chains, horizontal cross-department isolation rule sets and embedded sensitivity judgment basis labels;

[0133] Step S4.2, convert the permission rule components into executable logic units through a structured conversion algorithm;

[0134] Step S4.3, generate executable smart contract code based on the executable logic units, deploy to the distributed ledger network, and generate a unique permission control digital fingerprint;

[0135] Step S4.4, define business state trigger conditions based on business process phase identifiers, define time-sensitive trigger conditions based on timestamp thresholds, and define data change trigger conditions based on data update event listeners, and construct a set of data access trigger conditions;

[0136] Step S4.5, bind the permission control digital fingerprint with the trigger condition set to form the smart contract execution entry parameter.

[0137] In the embodiment of the present application, by deploying the smart contract to the distributed ledger, the permission rules are solidified in the blockchain in the form of code, avoiding human tampering or single point of failure, and the trigger conditions automatically drive the permission verification without human intervention; After extracting the hierarchical inheritance, cross-department isolation and sensitivity labels of the dynamic permission policy tree and converting them into smart contract logic, fine-grained matching of post-data-operation can be realized; The horizontal isolation rule is embedded in the contract to strictly block unauthorized cross-department access and reduce the risk of data leakage. The permission control digital fingerprint is bound with the blockchain transaction record, and any permission change or access behavior is recorded by the distributed ledger, which is convenient for auditing and compliance tracing; The trigger conditions are designed based on the business process phase, so that the permission control is synchronized with the actual business flow; The timestamp threshold and data update event drive the dynamic adjustment of permissions, supporting temporary collaboration scenarios.

[0138] In the embodiment of the present application, when specifically applied, it can be realized through the following technical solutions, for example:

[0139] The above step S4.1 takes the root node of the tree structure (such as the executive layer) as the starting point, traverses all permission nodes by level, extracts node attributes (such as post role name, department affiliation) and associated role identifiers (such as unique ID), traces from leaf nodes (ordinary employees) to the root node, records the permission inheritance path of each level (such as sales representative → sales manager → sales director → executive layer), forms a chain relationship data, scans the blocking nodes between department nodes, extracts the prohibition rules of cross-department access (such as sales department → finance department: prohibit access to key-level data), and records the rule triggering conditions; bind the corresponding data sensitivity label (such as key-level important level) to each permission node, and form a post-sensitivity mapping relationship table.

[0140] The above step S4.2 converts the permission node into a condition-action logic unit, for example: condition: post role = sales manager and data sensitivity = basic level; action: allow query, export operation; convert the vertical inheritance chain into permission superposition logic, such as child node permission = parent node permission + self extended permission, automatically merge the permission set through level judgment; convert the cross-department blocking rule into access control condition, for example: if the current department ≠ target department and data sensitivity ≥ important level, trigger the blocking logic; convert the label into a comparable numerical or enumeration value (such as key level = 3, important level = 2, basic level = 1), which is used for level matching in permission verification.

[0141] The above step S4.3 converts the logic unit into functions and state variables in the contract code based on the smart contract standard template (such as Solidity), for example: define the permission query function checkPermission(role, dataSensitivity), embed the condition logic of step S4.2; use the smart contract compiler to compile the code into bytecode, optimize Gas consumption, and generate interface ABI (application binary interface); send a deployment transaction to the distributed network through the blockchain client (such as Web3.js), wait for the node consensus confirmation, generate the contract address and unique hash value (digital fingerprint); hash the contract code and deployment parameters (such as SHA-256) to generate an irreversible permission control digital fingerprint, which is used to identify the permission rule version of the contract.

[0142] The step S4.4 divides the business process (such as data application -> approval -> use -> archiving) into different stages, sets a state identifier (such as stage=1 indicating the application stage) for each stage, defines the stage transition condition triggering the authority verification (such as triggering the authority check when the stage is switched), sets the time-related trigger condition, for example: temporary authority validity period: automatically invalid when currentTime>startTime+validHours; financial data authority reset triggered at 0 o'clock on the first day of each month; and deploys an event listener (such as DataUpdated(eventdataID, sensitivity)) in the smart contract, which automatically triggers the authority re-verification logic when the external system calls the contract to update the data.

[0143] The step S4.5 constructs a JSON-formatted parameter set, which includes: authority control digital fingerprint (used to locate the corresponding contract); trigger condition data (such as current business stage, timestamp, data update event parameter); and binds the digital fingerprint and trigger condition set through key-value pair, adds verification logic at the smart contract entry to ensure that the digital fingerprint matches the contract and the trigger condition meets the preset rules (such as the timestamp is not expired and the business stage is legal).

[0144] In a preferred embodiment of the present application, the step S5: when the smart contract execution entry parameters are met, the current business scenario context is parsed through the smart contract execution engine to dynamically adjust the access authority and generate a temporary access token, which can include:

[0145] 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 real-time sensitivity fields; obtain the current business stage identifier through the business unit API; calculate the real-time digital fingerprint of the authority request, and generate the authority verification result by comparing the pre-stored fingerprint;

[0146] Step S5.2, based on the key dynamic parameter set composed of real-time sensitivity fields, current business stage identifier and authority verification result, perform authority dynamic adjustment calculation to generate a dynamic authority configuration set;

[0147] Step S5.3, encapsulate the dynamic authority configuration set into a temporary access token, wherein the temporary access token includes: an encrypted data range identifier, an operation authority time limit parameter and a digital fingerprint binding signature.

[0148] In the embodiments of the present application, the latest data sensitivity level matrix is retrieved through the blockchain to realize real-time data sensitivity synchronization, avoid permission lag, and at the same time, the business unit API is used to obtain the business stage identifier, so that the permission control is deeply bound with the business process, and then the real-time digital fingerprint is compared with the pre-stored fingerprint to verify the legality of the permission request; the dynamic adjustment of the permission is performed based on the dynamic parameter set, the adaptive optimization of the permission is realized, and the fine-grained control is realized through accurate matching, the risk is dynamically prevented and controlled according to the change of the data sensitivity, the dynamic permission is encapsulated as a temporary access token, the encrypted data range identifier, the time limit parameter and the digital fingerprint binding signature are used to realize the secure encapsulation, the tamper-proof verification and the efficient management of the temporary permission.

[0149] In the embodiments of the present application, when specifically applied, the following technical solutions can be used to realize, for example:

[0150] In the above step S5.1, a query request is sent to the distributed ledger network, the latest stored data sensitivity level matrix is retrieved according to the data type (such as financial data, customer data) and the current timestamp, the matrix contains the mapping relationship between the data entity and the sensitivity label; the matrix data is analyzed, the real-time sensitivity field of the target data is extracted, and if the data update trigger event (such as version change) occurs, the timeliness is ensured by re-retrieving.

[0151] Through the preset business unit API (such as enterprise resource planning system API), the business process ID (such as sales order approval-001) associated with the current operation is transmitted, the stage state (such as in the approval and has been archived) of the process is obtained; the stage description (such as PaymentApproval) returned by the business system is mapped into an enumeration value (such as stage=2) recognizable by the smart contract.

[0152] The context parameters (user role, data ID, operation type) of the current permission request are collected, combined with the data sensitivity field and the business stage identifier, and a real-time digital fingerprint is generated through a hash algorithm (such as SHA-256); the real-time fingerprint is compared with the pre-stored permission control digital fingerprint (generated in step S4.3) of the smart contract: if they match, the permission verification process continues; if they do not match, an exception handling (such as inconsistent permission rule version, access denied) is triggered.

[0153] In the above step S5.2, the real-time sensitivity field (such as key level), the current business stage identifier (such as stage=3 indicating that the data is in use), and the permission verification result (pass / reject, and the parent node inheritance permission set) are integrated; the dynamic permission policy library is queried based on the parameter set, for example: if the business stage is in the approval and the data sensitivity is important, the approval permission is added based on the default permission; if the data sensitivity is upgraded from the basic level to the important level, the export permission is automatically revoked, and only the query is retained.

[0154] According to the adjustment rule, the default permission is added, deleted or modified: temporary permission is added, such as adding temporary financial data read-only permission for the sales manager during the cross-department project; the original permission is limited, such as reducing the permission to read-only after data archiving; and the final permission configuration set is generated.

[0155] In the step S5.3, the target data range corresponding to the permission is determined, the data range identifier is encrypted by using a symmetric encryption algorithm (such as AES), the key is bound with the user public key, and only the authorized party can decrypt; the operation permission time limit parameter is set, and the time limit parameter includes: effective time (startTime) such as current timestamp+5 minutes (waiting for the approval to be completed), expiration time (expireTime) such as temporary permission lasting for 72 hours, automatic invalidation at the expiration, and renewal rule such as the business stage not being completed, and the time limit can be applied for extension (the permission verification needs to be triggered again).

[0156] The dynamic permission configuration set, the data range identifier ciphertext and the time limit parameter are combined into a JSON structure, and the JSON structure is signed by using a smart contract private key (such as an ECDSA algorithm); the signature result is bound with the permission control digital fingerprint to form a signature-fingerprint pair, which is used for verifying the legality of the token; all fields are packaged into a standard JWT (JSON Web Token) format, including: header (Header): algorithm identifier, token type; payload (Payload): encrypted data range, permission list, time limit parameter, digital fingerprint; and signature (Signature): used for tamper-proofing verification.

[0157] In a preferred embodiment of the application, the step S6: based on the temporary access token, the data access behavior is analyzed in real time by using an exception detection unit built in the smart contract; when the permission boundary behavior is detected, the permission revocation function is triggered and a security alarm event record is generated, which can include:

[0158] In the step S6.1, based on the encrypted data range identifier and the digital fingerprint bound signature in the temporary access token, the permission range decryption and signature verification are performed by using a token parser built in the smart contract to generate a real-time permission benchmark rule;

[0159] In the step S6.2, based on the real-time permission benchmark rule, the access data identifier is compared with the data range of the permission benchmark rule to identify the out-of-range access; the operation timestamp is checked with the time limit parameter to determine whether the access is within the valid period; the operation instruction is matched with the allowed operation set to check whether there is unauthorized operation; the above detection results are constructed into a behavior feature vector, and whether there is a combined boundary is determined by using an association rule engine; if any detection does not pass, an exception flag is triggered, and a permission boundary behavior is generated.

[0160] Step S6.3, based on the permission boundary crossing behavior, triggering the permission revocation function of the smart contract to execute the access permission of the current boundary crossing session, generating a session termination credential; freezing the validity of the temporary token associated with the account, generating an account frozen state object;

[0161] Step S6.4, based on the session termination credential and the account frozen state object, analyzing the permission revocation execution result, generating a security alarm event record, which contains: the type of boundary crossing behavior and the associated data identifier, the permission revocation operation timestamp and the account state, the business process stage identifier at the time of triggering.

[0162] In the embodiments of the present application, the token parser built-in the smart contract decrypts the encrypted data range identifier in the temporary access token and verifies the digital fingerprint binding signature, ensuring the legality of the token while generating real-time permission benchmark rules, providing accurate basis for boundary crossing detection; based on the real-time permission benchmark rules, single boundary crossing behavior is identified from three dimensions of data range, operation time limit and operation instruction, and combined boundary crossing risk is analyzed through the associated rule engine, realizing real-time response of dynamic risk; once boundary crossing behavior is detected, the permission revocation function is triggered to terminate the boundary crossing session and freeze the temporary token of the associated account, accurately isolating the risk; the type of boundary crossing behavior, data identifier, revocation time, account state and business stage are chained to generate a security alarm event record, which meets the compliance audit demand by using the tamper-proof nature of the blockchain, and provides data support for business scenario risk analysis.

[0163] In the embodiments of the present application, when applied specifically, the following technical solutions can be used to achieve the purpose, for example:

[0164] In the above step S6.1, the token parser built-in the smart contract splits the temporary access token into three parts: header, payload and signature; the encrypted data range identifier is extracted from the payload and decrypted using the symmetric key (such as AES algorithm key, usually derived from the user public key or contract private key) matched at the time of encryption, and restored to plaintext data range (such as sales department 2025 Q2 customer data).

[0165] The digital fingerprint binding signature (such as ECDSA signature result) in the token is extracted, and the permission control digital fingerprint and dynamic permission configuration set are obtained from the payload; the signature is verified using the public key of the smart contract, to verify whether the signature is generated by the corresponding private key and the data has not been tampered with during transmission, and if the verification fails, it is directly determined as an illegal token.

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

[0167] The above step S6.2 extracts the data identifier (such as data ID, file path) of the current access request and matches it with the data range identifier (in plain text) in the real-time permission benchmark; if the accessed data exceeds the benchmark range (such as requesting to access the 2025 budget of the finance department while the permission only allows customer data of the sales department), it is marked as an out-of-range access exception.

[0168] The operation timestamp is obtained from the access request and compared with the time limit parameter (effective time, expiration time) in the permission benchmark; if the operation time is earlier than the effective time or later than the expiration time, it is marked as a time limit out-of-bound exception; the operation instruction (such as modification export) of the access request is analyzed and compared with the set of allowed operations (such as read-only query) in the permission benchmark; if there is an unauthorized operation (such as holding a query permission but performing an export), it is marked as an operation out-of-bound exception.

[0169] The above detection results (data range, time limit, operation) are converted into a binary feature vector (such as [1, 0, 1] representing data out-of-bound and operation out-of-bound); input into the association rule engine, match the preset combined out-of-bound mode (such as data out-of-bound + time limit out-of-bound as high-risk attack), if match, trigger combined out-of-bound exception mark.

[0170] The above step S6.3 triggers the revokePermission(sessionID) function built-in the smart contract, according to the current session ID (carried in the access request), immediately terminates all permissions of the session; generates a session termination credential, records the termination time, session ID, out-of-bound type, etc. information, stores it in the blockchain log.

[0171] The initiating account address of the access request is parsed, and the temporary token list associated with the account is found in the contract state; the valid field of the corresponding token is marked as false, freezing its validity, and an account freezing state object (including freezing time, freezing reason) is generated; if the out-of-bound behavior belongs to high risk (such as combined out-of-bound), automatically expand the freezing range: freeze the associated sessions of the account in other systems, or temporarily raise the approval level of its subsequent access.

[0172] The above step S6.4 extracts key information from the session termination credential and the account freezing state object: the out-of-bound behavior type (out-of-range, time limit, operation, combination); associated data identifier (such as data ID, sensitivity level); timestamp of permission revocation operation; account freezing state (freezing duration, unfreezing condition).

[0173] The business process phase identifier (such as in approval, data in use) at the time of triggering the out-of-bound is obtained through the smart contract execution engine, and is supplemented 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 the external alarm system (such as SIEM) is triggered to push the notification.

[0174] As Figure 2 shown, the embodiment of the application also provides a dynamic permission smart contract generation system based on data sensitivity adaptation, comprising:

[0175] A classification module is configured to classify and mark multi-dimensional data in a business scenario, and construct a customer information classification matrix according to data types.

[0176] A level matrix module is configured to perform sensitivity quantitative evaluation by using a rule engine based on a decision tree based on data types of the customer information classification matrix, the engine taking data usage scenarios, regulation constraint labels and time effectiveness weight labels as inputs, judging according to a preset tree path, and outputting a sensitivity result, and generating a structured sensitivity level matrix after traversing all data types.

[0177] A mapping module is configured to establish a mapping relationship between data sensitivity and role permissions according to the data sensitivity level matrix and combining preset post role permission rules, and generate a dynamic permission strategy tree.

[0178] A construction module is configured to compile the dynamic permission strategy tree into executable smart contract code, deploy the executable smart contract code to a distributed ledger network and generate a permission control digital fingerprint, and simultaneously construct smart contract execution entry parameters based on business process stages, timestamp thresholds and data update events.

[0179] A dynamic adjustment module is configured to, when the smart contract execution entry parameters are satisfied, parse a current business scenario context by a smart contract execution engine, dynamically adjust access permissions and generate a temporary access token.

[0180] A recording module is configured to perform real-time mode analysis on data access behavior by an exception detection unit built in the smart contract based on the temporary access token, and when a permission boundary crossing behavior is detected, trigger a permission revocation function and generate a security alarm event record.

[0181] It should be noted that the system is a system corresponding to the above method, and all implementation manners in the above method embodiment are applicable to this embodiment and can achieve the same technical effects.

[0182] The above is the preferred embodiment of the application. It should be noted that for those skilled in the art, without departing from the principles of the application, a number of improvements and refinements can be made, which should also be considered within the scope of protection of the application.

Claims

1. A method for generating a dynamic permission smart contract based on data sensitivity self-adaptation, characterized in that, The method comprises: Step S1: classifying and marking multi-dimensional data in a business scenario, and constructing a customer information classification matrix according to data types; Step S2: based on the data types of the customer information classification matrix, using a rule engine based on a decision tree to perform sensitivity quantification evaluation, the engine taking data usage scenarios, regulatory constraint labels, and time effectiveness weight labels as inputs, judging according to a preset tree path, outputting a sensitivity result, and generating a structured sensitivity level matrix after traversing all data types, including: extracting data type labels, business scenario context labels, and data source identifiers from the customer information classification matrix to generate a basic label set; combining the basic label set with externally input regulatory constraint factor mapping labels and time effectiveness weight parameter regularization labels to form a complete set of rule engine input labels; inputting the complete set of labels into the decision tree rule engine, generating branch matching results through preset tree rule paths layer by layer, and the branch matching results including a scenario risk branch matched based on the business scenario context labels, a regulatory constraint branch matched based on the regulatory constraint factor mapping labels, and a time effectiveness attenuation or enhancement branch matched based on the time effectiveness weight parameter regularization labels; locating to the end leaf node of the decision tree according to the branch matching results to generate a sensitivity judgment result of the current data type; traversing all data types of the customer information classification matrix, independently processing, and aggregating the sensitivity judgment results to generate a structured data sensitivity level matrix, which inherits the data subject identifier primary key of the original matrix, adds a sensitivity level field, and is associated with scenario, regulatory, and time effectiveness judgment basis labels; Step S3: according to the data sensitivity level matrix, combining preset post role permission rules, establishing a mapping relationship between data sensitivity and role permissions, and generating a dynamic permission policy tree; Step S4: compiling the dynamic permission policy tree into executable smart contract code, deploying it to a distributed ledger network, and generating a permission control digital fingerprint; at the same time, constructing 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 current business scenario context is analyzed through the smart contract execution engine, the access permission is dynamically adjusted, and a temporary access token is generated; Step S6: based on the temporary access token, the data access behavior is analyzed in real time through the exception detection unit built in the smart contract; when a permission boundary behavior is detected, a permission revocation function is triggered and a security alarm event record is generated.

2. The method of claim 1, wherein, Step S1: classifying and marking multi-dimensional data in a business scenario, and constructing a customer information classification matrix according to data types, including: extracting multi-dimensional data from a business scenario, and performing double classification marking based on data type dimensions and business attribute dimensions; mapping the marked data types to preset fields to construct a structured matrix with data subject identifiers as primary keys and data type labels as column attributes; embedding data source identifiers and business scenario context labels in the matrix to form a customer information classification matrix containing complete metadata.

3. The method of claim 2, wherein, Step S3: According to the data sensitivity level matrix, combined with the preset post role permission rules, the mapping relationship between data sensitivity and role permission is established, and a dynamic permission policy tree is generated, including: Load the preset post role permission rule library, which defines: the default operation permission of each post role to key level, important level and basic level sensitive data; the vertical position level relationship in the organizational structure; the data isolation boundary rule of cross-department cooperation; According to the data sensitivity level matrix, the sensitivity label set is generated; Match the sensitivity label set with the permission rule library, and output the basic permission mapping table; Based on the basic permission mapping table, a dynamic permission policy tree is constructed, which contains vertical level permission inheritance relationship and horizontal cross-department permission isolation rule.

4. The method of claim 3, wherein, Step S4: Compile the dynamic permission policy tree into executable smart contract code, deploy it to the distributed ledger network and generate the permission control digital fingerprint; At the same time, build the smart contract execution entry parameter based on the business process stage, timestamp threshold and data update event, including: Extract the permission rule components from the dynamic permission policy tree, including: permission nodes and associated role identifiers, vertical permission inheritance relationship chain, horizontal cross-department isolation rule set and embedded sensitivity judgment basis label; Convert the permission rule components into executable logic units through a structured conversion algorithm; Based on the executable logic unit, generate the executable smart contract code, deploy it to the distributed ledger network, and generate a unique permission control digital fingerprint; Based on the business process stage identifier, define the business state trigger condition, based on the timestamp threshold, define the timeliness trigger condition, and based on the data update event listener, define the data change trigger condition, to build a data access trigger condition set; Bind the permission control digital fingerprint with the trigger condition set to form the smart contract execution entry parameter.

5. The method of claim 4, wherein, Step S5: When the smart contract execution entry parameter is met, the current business scenario context is parsed through the smart contract execution engine, and the access permission is dynamically adjusted and a temporary access token is generated, including: When the smart contract execution entry parameter is met, retrieve the latest data sensitivity level matrix from the blockchain, and parse the real-time sensitivity field; Get the current business stage identifier through the business unit API; Calculate the real-time digital fingerprint of the permission request, and generate the permission verification result by comparing the pre-stored fingerprint; Based on the key dynamic parameter set composed of real-time sensitivity field, current business stage identifier and permission verification result, execute permission dynamic adjustment calculation to generate dynamic permission configuration set; Encapsulate the dynamic permission configuration set as a temporary access token, which contains: encrypted data range identifier, operation permission time limit parameter and digital fingerprint binding signature.

6. The method of claim 5, wherein, Step S6: Based on the temporary access token, the data access behavior is analyzed in real time through the exception detection unit built in the smart contract; When detecting a permission boundary crossing behavior, trigger the permission revocation function and generate a security alarm event record, including: Based on the encryption data range identifier and the digital fingerprint binding signature in the temporary access token, the authority range decryption and signature verification are performed through the token parser built in the smart contract, and a real-time authority benchmark rule is generated; Based on the real-time authority benchmark rule, the access data identifier and the data range of the authority benchmark rule are compared to identify out-of-range access; the operation timestamp and the time limit parameter are checked to determine whether the access is within the valid period; the operation instruction and the allowed operation set are matched to check whether there is an unauthorized operation; the detection results are constructed into a behavior feature vector, and whether there is a combined out-of-range is determined through an association rule engine; if any detection fails, an abnormality marker is triggered, and an authority out-of-range behavior is generated; Based on the authority out-of-range behavior, the authority revocation function of the smart contract is triggered to execute the access authority of the current out-of-range session in real time, and a session termination credential is generated; the validity of the associated account temporary token is frozen, and an account frozen state object is generated; Based on the session termination credential and the account frozen state object, the authority revocation execution result is parsed, a security alarm event record is generated, and the record includes: the out-of-range behavior type and the associated data identifier, the authority revocation operation timestamp and the account state, and the business process stage identifier at the time of triggering.

7. A dynamic permission smart contract generation system based on data sensitivity self-adaptation, the system implements the method of any one of claims 1 to 6, characterized in that, It includes: A classification module for classifying and labeling multi-dimensional data in a business scenario, and constructing a customer information classification matrix according to the data type; A level matrix module for performing sensitivity quantification evaluation based on the data type of the customer information classification matrix using a decision tree-based rule engine, the engine taking the data usage scenario, the regulatory constraint label, and the time limit weight label as input, judging according to the preset tree path, and outputting the sensitivity result, and generating a structured sensitivity level matrix after traversing all data types; A mapping module for establishing a mapping relationship between data sensitivity and role authority based on the data sensitivity level matrix and combining the preset role authority rules, and generating a dynamic authority policy tree; A construction module for compiling the dynamic authority policy tree into executable smart contract code, deploying it to a distributed ledger network, and generating a permission control digital fingerprint; and constructing a smart contract execution entry parameter based on the business process stage, the timestamp threshold, and the data update event; A dynamic adjustment module for dynamically adjusting access authority and generating a temporary access token by parsing the current business scenario context through a smart contract execution engine when the smart contract execution entry parameter is met; A recording module for real-time pattern analysis of data access behavior based on the temporary access token through the exception detection unit built in the smart contract. When a permission out-of-range behavior is detected, a security alarm event record is generated.

8. A computing device, comprising: One or more processors; A storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, so that the one or more processors implement the method of any one of claims 1-6. The computer readable storage medium stores a program which is executed by the processor to implement the method of any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, ​

Images