Multi-platform data collaborative governance authority dynamic control method and system

Abstract

The embodiment of the invention relates to the technical field of information, in particular to a dynamic control method and system for multi-platform data collaborative governance authority. The method comprises the following steps: marking static permission description for each field; when an event work order or a cooperation application sent by a user is received, obtaining a request data result set; identifying a current scene, a requester department, a requester role and a requester permission level; comparing the static permission description with the requester department, the requester role and the requester permission level to obtain a static permission data set; comparing the static permission description with the current scene to obtain a dynamic permission data set and a validity period; performing conflict verification on the static permission data set and the dynamic permission data set to obtain a permission set, and generating a permission token according to the permission set and the validity period; the platform feeds back data and records a log at the same time, and stores the log by using a block chain; and based on the trigger, withdrawing the permission token.

Description

Technical Field

[0001] Multiple embodiments of this specification relate to the field of information technology, and specifically to a method and system for dynamic control of multi-platform data collaboration governance permissions. Background Art

[0002] In grass-roots community management, data collaboration and permission management are crucial for information flow and security. Currently, the role-based access control (RBAC) mechanism is commonly used, but it has obvious deficiencies in the face of multi-platform collaboration scenarios. Traditional methods rely on static permission configurations, pre-defining "role-permission" mappings, ignoring the detailed classification of data confidentiality levels and operation scenarios, resulting in excessive data openness. For temporary collaboration requirements, permissions need to be adjusted manually, which is time-consuming and prone to generating temporary accounts that are not cancelled in a timely manner, increasing security risks. The permission systems of each department's systems are independent, and data sharing requires repeated development of interfaces, increasing maintenance costs and the complexity of new system access. These problems lead to lagging permission allocation responses, extensive permission management, a high rate of permission residues, and difficulties in compliance auditing. Therefore, there is an urgent need for a new management system that can adapt to changing scenarios, achieve fine-grained permission control, and support automatic permission recovery. Summary of the Invention

[0003] Multiple embodiments of this specification describe a method and system for dynamic control of multi-platform data collaboration governance permissions.

[0004] In a first aspect, embodiments of this specification provide a method for dynamic control of multi-platform data collaboration governance permissions, including the steps of: Each platform labels static permission descriptions for each field of the data, and the static permission descriptions include department, using role, confidentiality level, usage scenario description, validity period description, and operation description; When any platform receives an event work order or collaboration application sent by a user, it obtains a request data result set according to the retrieval formula carried in the event work order or collaboration application; Identify the current scenario, the department of the requester, the role of the requester, and the permission level of the requester according to the event work order or collaboration application; Traverse the fields included in the request data result set, compare the static permission descriptions of the fields with the department of the requester, the role of the requester, and the permission level of the requester, and obtain a static permission data set; Compare the static permission descriptions of the fields with the current scenario, and obtain a dynamic permission data set and a validity period; Perform conflict verification on the static permission data set and the dynamic permission data set to obtain a permission set, and generate a permission token according to the permission set and the validity period; The user uses the permission token and the data retrieval formula to obtain data from the platform. The platform feeds back the data while recording logs, and stores the logs on the blockchain at a preset period. The platform withdraws the permission token based on the expiration of the validity period, the triggering of the current scenario completion event, or the triggering of an abnormal query behavior by the user.

[0005] In a second aspect, an embodiment of the present specification provides a multi-platform data collaborative governance permission dynamic control system, including: A marking module, where each platform marks static permission descriptions for each field of the data. The static permission descriptions include department, usage role, confidentiality level, usage scenario description, validity period description, and operation description. A retrieval module, when any platform receives an event work order or a collaboration application sent by a user, obtains a request data result set according to the retrieval formula carried by the event work order or the collaboration application. An identification module, which identifies the current scenario, the department of the requester, the role of the requester, and the permission level of the requester according to the event work order or the collaboration application. A first comparison module traverses the fields included in the request data result set, compares the static permission descriptions of the fields with the department of the requester, the role of the requester, and the permission level of the requester, and obtains a static permission data set. A second comparison module compares the static permission descriptions of the fields with the current scenario to obtain a dynamic permission data set and a validity period. A verification module performs conflict verification on the static permission data set and the dynamic permission data set to obtain a permission set, and generates a permission token according to the permission set and the validity period. An execution module, where the user uses the permission token and the data retrieval formula to obtain data from the platform. The platform feeds back the data while recording logs, and stores the logs on the blockchain at a preset period. A monitoring module, where the platform withdraws the permission token based on the expiration of the validity period, the triggering of the current scenario completion event, or the triggering of an abnormal query behavior by the user.

[0006] In a third aspect, an embodiment of the present specification provides an electronic device, including a processor and a memory; The processor is connected to the memory; The memory is used to store executable program code; The processor runs a program corresponding to the executable program code by reading the executable program code stored in the memory, so as to execute the method described in any of the above aspects.

[0007] Fourthly, embodiments of the present specification provide a computer-readable storage medium with a computer program stored thereon. When the computer program is executed by a processor, the methods described in any of the above aspects are implemented.

[0008] Fifthly, embodiments of the present specification provide a computer program product, including a computer program. When the computer program is executed by a processor, the methods described in any of the above aspects are implemented.

[0009] The beneficial effects brought by the technical solutions provided in some embodiments of the present specification at least include: In multiple embodiments of the present specification, the provided dynamic permission control method and system perform fine-grained permission control by combining a six-tuple static permission description with factors such as specific scenarios, validity periods, and operation types, ensuring that data is correctly used in appropriate scenarios. And through the setting of the validity period and the automatic permission recovery mechanism, the risk of data leakage caused by long-term residual permissions is avoided. It overcomes the problem that it is difficult to meet the needs of modern grass-roots governance in the traditional RBAC method, especially the detailed division in aspects such as data classification levels and operation scenarios, making cross-departmental collaboration more efficient and secure, and reducing the complexity caused by the independent permission system. Through the precise matching of data fields required in different scenarios and the reasonable configuration of user roles and permission levels, the effective utilization of resources is realized, which not only ensures the safe circulation of information but also improves the accuracy of decision-making and service provision.

[0010] Other features and advantages of multiple embodiments of the present specification will be further revealed in the following specific embodiments and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] To more clearly illustrate the technical solutions in the embodiments of the present specification, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present specification. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0012] Figure 1 It is a schematic diagram of the application scenario of the dynamic permission control method provided by the embodiment of the present specification.

[0013] Figure 2 It is a schematic diagram of the permission token generation provided by the embodiment of the present specification.

[0014] Figure 3 It is a schematic diagram of the flow of the dynamic permission control method provided by the embodiment of the present specification.

[0015] Figure 4 It is a schematic diagram of the dynamic permission control system provided by the embodiment of the present specification.

[0016] Figure 5 Schematic diagram of the electronic device provided by the embodiments of this specification. Specific implementation manners

[0017] The technical solutions of the embodiments of this specification will be explained and described below with reference to the accompanying drawings of the embodiments of this specification. However, the following embodiments are only the preferred embodiments of this specification, not all of them. Based on the embodiments in the implementation manners, other embodiments obtained by those skilled in the art without creative efforts all fall within the protection scope of this specification.

[0018] Terms such as "first", "second", "third", etc. in the specification, claims and the above accompanying drawings of this specification are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed, or optionally further includes other steps or units inherent to these processes, methods, products or devices.

[0019] In the following description, terms indicating orientation or positional relationships such as "inside", "outside", "above", "below", "left", "right", etc. are only for the convenience of describing the embodiments and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus cannot be construed as a limitation of this specification.

[0020] The data involved in this application are all information and data authorized by users or fully authorized by all parties, and the collection, use and processing of relevant data all comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0021] Before introducing the technical solutions described in this specification, the application scenarios of the technical solutions and related technologies will be introduced.

[0022] In grass-roots management, the reasonable configuration and dynamic adjustment of the permissions of Data 11 are the key to ensuring the smooth flow and security of information. The traditional role-based access control (RBAC) method allocates access permissions through predefined role-permission mappings. For example, the community director is defaultly granted the read and write permissions for all Data 11 within the jurisdiction. However, this method is difficult to meet the needs of modern grass-roots governance because it ignores the detailed classification of the confidentiality levels of Data 11 (such as personal privacy and public data) and operation scenarios (such as emergency response and daily statistics), and relies on manual adjustment and recovery of temporary permissions, which is not only time-consuming but also prone to the problem of residual permissions.

[0023] For example, in a typical application scenario of grassroots community management, when responding to public health emergencies, cross-departmental collaboration needs to be quickly organized to effectively control the spread of the epidemic. At this time, different functional departments such as health, public security and community grid workers need to share and access relevant data in real time11 to ensure accurate information transmission and rapid response. With the growth of multi-departmental collaboration needs, the independent authority system of each department system makes data11 sharing complicated and costly.

[0024] To this end, this manual provides a dynamic permission hierarchical control and automatic recovery solution. Figure 1 , the data 11 permission dynamic allocation scheme recorded in this specification adopts a six-tuple static permission description 12, combines specific scenarios, validity periods, and operation types to perform fine-grained permission control, and realizes automatic generation and timely recovery of permissions, effectively improving response speed and reducing the risk of data 11 leakage. In the technical solution provided in this specification, each platform 10 with data 11 associates a static permission description 12 with each field of data 11. The static permission description 12 includes department, usage role, confidentiality level, usage scenario description, validity period description, and operation description. The static permission description 12 defines the boundaries and conditions of a permission. For example, the department specifies the management agency to which the data 11 belongs; the usage role clarifies which job function can access the data 11; the confidentiality level is divided into different levels according to the sensitivity of the data 11; the usage scenario description defines under what specific circumstances the data 11 can be accessed; the validity period description sets the time range of the permission; and the operation description specifies the specific operation types that the user 20 can perform, such as reading, writing, downloading, etc.

[0025] The platforms 10 agree on the format of the event ticket 21 and the collaboration application. Figure 2 When the platform 10 receives an event ticket 21 or a collaboration application submitted by a user 20 of another platform 10, the current scenario, the department of the requester, the role of the requester, and the permission level of the requester are extracted. The extracted current scenario, the department of the requester, the role of the requester, and the permission level of the requester are compared with the static permission description 12 to finally obtain the permission token and validity period. During the validity period, the permission token is used to operate the data 11, such as querying, forwarding, modifying, downloading, etc.

[0026] This manual first provides a method for dynamically controlling multi-platform data collaborative governance permissions. Figure 3 , including the steps of: Step S1) Each platform 10 marks each field of the data 11 with a static permission description 12, wherein the static permission description 12 includes a department, a user role, a confidentiality level, a usage scenario description, a validity period description, and an operation description.

[0027] Each grass-roots department generates various types of data 11. Using this data 11 under appropriate circumstances can efficiently support decision-making, service provision, and emergency management. Exemplarily, community health service centers store residents' health records, vaccination records, chronic disease management information, etc., which are used during annual health checks, emergency medical services, or responses to public health events (such as disease outbreaks). It is of great significance for improving the efficiency of residents' health management, quickly responding to public health crises, and optimizing the allocation of medical resources.

[0028] Civil affairs departments store records of social assistance applications, marriage registration information, service needs of the elderly and disabled, etc., which are used when reviewing social welfare eligibility, organizing community activities, and providing customized services for special groups. It improves the accuracy of social welfare distribution, enhances community cohesion, and improves the quality of life of vulnerable groups.

[0029] To enable this data 11 to be used in appropriate scenarios and ensure that the data 11 is not leaked, appropriate permission management is required. Through the permission management of the data 11, the data 11 can be shared with users 20 who need to use it, while ensuring the privacy and security of the data 11.

[0030] In this embodiment, on the platform 10 corresponding to each grass-roots department that generates data 11, a static permission description 12 is associated with each field of the data 11 to achieve field-level permission control. Exemplarily, the static permission description 12 of the community residents' health records is as follows: Department: Community Health Service Center, Using Roles: Community Doctors, Community Nurses, Grid Workers, Confidentiality Level: Privacy Level, Usage Scenario Description: Can be accessed only in the case of annual health checks, emergency medical treatment, and medical subsidy registration, Validity Period Description: Expected business duration + 2-hour buffer, Operation Description: Allows reading and updating, prohibits downloading or forwarding. This indicates that the community residents' health records belong to the privacy level, and the usage scenario restricts that the data 11 can only be used in this scenario. And the roles of the users 20 who can apply to use the data 11 are limited by the using roles. Another exemplarily, the static permission description 12 of the community neighborhood dispute mediation records is as follows: Department: Police Station, Using Roles: Grid Workers, Police Officers, Confidentiality Level: Internal Level, Usage Scenario Description: Used when handling neighborhood dispute incidents, Validity Period Description: Expected business duration + 2-hour buffer, Operation Description: Allows reading and adding, prohibits modification, downloading or forwarding. The confidentiality levels include privacy level, internal level, and public level, and the level relationship is privacy level > internal level > public level. For example, the community director has the requester permission level of the privacy level and can match more usage scenario descriptions, so he can view almost all the data 11. The community doctor also has the requester permission level of the privacy level, but the usage scenario descriptions he can match are concentrated on medical-related matters. Therefore, it can be controlled that the community doctor can only have the highest-level viewing permission for the scenarios matched in the scenarios related to health management and medical assistance.

[0031] Step S2) When any platform 10 receives an event work order 21 or a collaboration application sent by the user 20, according to the retrieval formula carried by the event work order 21 or the collaboration application, a requested data result set is obtained.

[0032] The event work order 21 or the collaboration application submitted by the user 20 needs to include clear retrieval conditions to describe the specific characteristics of the required data 11. For example, the involved community, personnel, specific usage scenarios (such as fire safety control), expected validity period, and specific operation types (such as reading). The scenario recognition engine in the platform 10 will analyze the event work order 21 or the collaboration application, extract the core elements through natural language processing technology (NLP), and convert them into executable query instructions. For example, if the event work order 21 mentions "fire safety hazard investigation for illegal rental housing in XX community", the platform 10 will identify that this is a scenario related to "fire safety control". And it will retrieve the registration information of all illegal rental houses in this community, including house location, landlord registration information, tenant registration information, historical fire safety hazard investigation records, etc.

[0033] Step S3) Identify the current scenario, the department of the requester, the role of the requester, and the permission level of the requester according to the incident work order 21 or the collaboration application.

[0034] The method for identifying the current scenario, the department of the requester, the role of the requester, and the permission level of the requester according to the incident work order 21 or the collaboration application includes:

[0035] Parse the meta-information contained in the incident work order 21 or the collaboration application to obtain the scenario label, the applicant identifier, and the organizational structure path therein;

[0036] Query the accessed user database according to the applicant identifier to obtain the department of the requester, the job level, and the job role;

[0037] Obtain the role of the requester according to the job level, and obtain the permission level of the requester according to the pre-stored mapping of job role - permission level;

[0038] Attempt to identify the business type, process stage, and task description carried in the incident work order 21 or the collaboration application, and identify the current scenario according to the preset scenario classification.

[0039] First, it is necessary to parse the meta-information contained in the incident work order 21 or the collaboration application, and extract basic information such as the scenario label, the applicant identifier, and the organizational structure path. Analyze the content of the incident work order 21 or the collaboration application through text analysis techniques (such as the TextCNN model) to extract key information, such as "the keyword 'flood control' matches the 'emergency rescue' scenario", and at the same time identify the applicant identifier and the organizational structure path.

[0040] Then, query the database of the platform 10, and query in the accessed user database according to the extracted applicant identifier to obtain the detailed information of the requester, including the department to which the requester belongs, the job level, and the job role. Use the extracted applicant identifier as the query condition to find the corresponding information in the user database.

[0041] Then determine the role and permission level. Determine the role of the requester based on the obtained job level, and determine the permission level of the requester through the pre-stored mapping table of job role permission levels. Directly obtain the role of the requester within the organization according to the job level, such as "grid operator", "community director", etc. Use the pre-set mapping relationship of job role permission levels to assign corresponding permission levels to each role. For example, the permission level of a "community director" may allow access to more sensitive information.

[0042] Finally, identify the business type and scenario. Try to identify the business type, process stage, and task description carried in the incident work order 21 or collaboration application. Based on the preset scenario classification rules, finally identify the current specific scenario. Further analyze the business type, process stage, and task description in the incident work order 21 or collaboration application, and combine the preset scenario classification rules to identify the current work scenario. If the application involves querying "vaccination records", it can be classified as a public health management scenario; if it is about "investigating potential safety hazards in group rental housing", it belongs to the public safety management scenario.

[0043] Step S4) Traverse the fields included in the request data result set, and compare the static permission description 12 of the fields with the requester's department, requester's role, and requester's permission level to obtain a static permission data set.

[0044] The method of comparing the static permission description 12 of the fields with the requester's department, requester's role, and requester's permission level to obtain a static permission data set includes:

[0045] For the department, usage role, and confidentiality level in the static permission description 12 of each field, respectively compare them with the requester's department, requester's role, and requester's permission level to obtain the matching fields;

[0046] According to the matching fields, obtain a static permission data set from the request data result set.

[0047] Traverse the entire request data result set and check the static permission description 12 of each field. For the static permission description 12 (including department, usage role, and confidentiality level) of each field, respectively compare it with the requester's department, role, and permission level. For each field, the system will respectively compare the "department", "usage role", and "confidentiality level" in its static permission description 12 with the requester's "requester's department", "requester's role", and "requester's permission level" one by one.

[0048] For example, if the static permission description 12 of a certain field is: "Department - Community Health Service Center; Usage Role - Medical Advisor; Confidentiality Level - Privacy Level", and the requester exactly belongs to a "Medical Advisor" in the "Community Health Service Center" and has the "Privacy Level" permission, then this field is regarded as a successful match.

[0049] By comparison, the fields that meet the requester's permission conditions are identified, that is, the data fields that the requester can access. According to the successfully matched fields, the corresponding data 11 is extracted from the request data result set to form a static permission data set. The static permission data set contains all the specific data fields that the requester has permission to access in the current scenario, ensuring the security and compliance of the data 11. Precise control over the access to the data 11 not only ensures the security of the data 11 but also improves the efficiency of the use of the data 11. The fine-grained permission management mechanism provided in this embodiment is particularly applicable to the data collaborative governance environment of grass-roots multi-platforms 10, which helps to improve the overall social governance level and service quality.

[0050] Step S5) Compare the static permission description 12 of the field with the current scenario to obtain a dynamic permission data set and a validity period.

[0051] The method of comparing the static permission description 12 of the field with the current scenario to obtain a dynamic permission data set and a validity period includes:

[0052] Read the pre-established scenario permission mapping table;

[0053] Compare the current scenario with the scenario permission mapping table to obtain a dynamic permission field set;

[0054] According to the dynamic permission field set, obtain a dynamic permission data set from the request data result set;

[0055] Obtain the validity period according to the current scenario and the validity period description. The system has a built-in scenario permission mapping table that records the permission relationships between different business scenarios and accessible fields. A scenario permission mapping table in this embodiment is shown in Table 1. The scenario permission mapping table is preset by the administrator according to the actual business requirements and is an important basis for dynamic permission judgment. Table 1 A scenario permission mapping table in this embodiment Scene Name List of Allowed Access Fields Operation Restrictions Emergency Rescue and Relief Resident Contact Information, Residential Address, Emergency Contacts Read Only Epidemic Prevention and Control Health Status, Vaccination Status, Travel History Read and Write Educational Resource Allocation Number of Students, Class Distribution, Teacher Allocation View Statistical Information Only Match the current scenario (such as "epidemic prevention and control") identified in step S3 with the entries in the scenario permission mapping table, and extract the set of data fields allowed to be accessed in this scenario, that is, the "dynamic permission field set". For example: If the current scenario is "epidemic prevention and control", the dynamic permission field set includes "health status, vaccination status, travel itinerary". From the obtained complete request data result set, filter out the field data 11 belonging to the above "dynamic permission field set" to form a "dynamic permission data set". Each scenario usually corresponds to a preset validity period policy. Exemplarily, the expected business duration in the emergency rescue scenario is 72 hours, the expected business duration in the epidemic prevention and control scenario is the current day, and the expected business duration in the education resource allocation scenario is valid daily during the period from June to August. Combining the rules defined in the scenario permission mapping table and the expected business duration of the field itself, determine the permission validity period for this access and generate a permission token with a time limit. For example, a certain incident work order 21 involves "Community Flood Control Emergency Response", and the platform 10 identifies the current scenario as "Emergency Rescue". By comparing the scenario permission mapping table, the system knows that the fields accessible in this scenario include "Resident contact information, Residential address, House structure grade". Extract these fields from the request data result set to form a dynamic permission data set, and set the validity period of this access permission to 72 + 2 hours according to the preset rules of the "Emergency Rescue" scenario. Through the scenario-driven dynamic permission control mechanism, not only the security of data 11 access is improved, but also the system's adaptability to complex grass-roots governance scenarios is enhanced. By combining static permissions with dynamic scenarios, it not only ensures the compliant use of data 11, but also avoids the problems of permission abuse and long-term residue, providing a solid support for building an efficient, secure, and intelligent grass-roots governance system. Step S6) Perform conflict verification on the static permission data set and the dynamic permission data set to obtain a permission set, and generate a permission token according to the permission set and the validity period. The method of performing conflict verification on the static permission data set and the dynamic permission data set to obtain a permission set and generating a permission token according to the permission set and the validity period includes: When a field existing in the dynamic permission data set does not exist in the static permission data set, set the permission of the field to read-only permission; Obtain a permission set according to the dynamic permission data set with the permissions reset; Generate a permission token according to the permission set and the validity period. Compare the fields in the static permission data set and the dynamic permission data set. If a certain field exists in the dynamic permission data set but not in the static permission data set, it means that although the field meets the current scenario requirements, it is not authorized to be accessed in the basic permission configuration. For such fields, they are default set to read-only permission, that is, viewing is allowed but modification or download is not allowed, so as to control risks while meeting business needs. Exemplarily, a certain field "Resident Health Status" is a read-write field in dynamic permissions but fails the static permission review. If the requester's role permissions are insufficient, its permissions are automatically adjusted to read-only, and an expiration period is set. Viewing is no longer allowed after the expiration period. Based on the dynamic permission dataset after resetting the permissions, a permission set is obtained. After conflict handling is completed, the system merges all fields, including the original static matching fields and the adjusted dynamic fields, to form a permission set. The permission set includes the access type (such as read, write), operation restrictions (such as prohibiting exports), applicable scenarios, and expiration period for each field. Based on the content of the above permission set and combined with the permission expiration period determined in step S5, the system generates a structured permission token (Permission Token). Exemplarily, the permission token stores the following information in an encrypted format (such as JWT): requester identity identifier, list of fields allowed to access and their operation permissions, scenario tags, valid start time and end time, and signature information for anti-tampering verification.

[0056] Exemplarily, the generated permission token may contain the following information fragments: json { "user_id": "U20250521", "allowed_fields": {"field_name": "Resident Contact Information", "operation": "read"}, {"field_name": "House Structure Grade", "operation": "read"} , "scene": "Flood Control Emergency Response", "valid_from": "2025-05-21T17:00:00Z", "valid_to": "2025-05-24T17:00:00Z", "signature": "xxx" } The conflict verification mechanism ensures the consistency of permission logic and avoids unauthorized access due to dynamic expansion. The permission token has characteristics such as standardization, structurization, and auditability, and can be transmitted and used across platforms 10. The fine-grained control based on scenarios and time makes data sharing in grass-roots governance more flexible, secure, and controllable. The combination of the permission token and technologies such as blockchain enables full-process traceability and post-event auditing to meet regulatory compliance requirements.

[0057] Step S7) User 20 uses the permission token and the data retrieval formula to obtain data from platform 10. Platform 10 feeds back the data while recording logs, and stores the logs using blockchain at a preset cycle. In accordance with a preset cycle, such as daily or weekly, the logs are batch-processed and stored in an immutable manner through blockchain technology.

[0058] Step S8) Platform 10 retrieves the permission token based on the expiration of the validity period, the triggering of the current scenario completion event, or the abnormal query behavior of user 20. To avoid security risks caused by long-term retention of permissions, a multi-dimensional permission recovery mechanism is supported to ensure that permissions expire in a timely manner at appropriate time points. The system has built-in scheduled tasks or event listeners to continuously monitor all issued permission tokens. When it is detected that the "valid until time" of a certain permission token arrives, the system automatically marks it as "expired" and removes it from the available permission pool. At the same time, the relevant log status is updated to record the reason for recovery. During collaborative processes, if an event work order 21 or a collaboration application is marked as "completed", "cancelled", or "timed out", it is considered that the scenario has ended, and the recovery operation of the associated permission token is immediately triggered. Platform 10 integrates a behavior analysis module to monitor the access behavior patterns of user 20 in real time. If it is found that user 20 has abnormal operations, such as frequent high-frequency queries, accessing unauthorized fields, attempting to export a large amount of sensitive data, etc., the system will initiate the permission recovery process. Behavior modeling and anomaly detection can be combined with an AI model to improve the recognition accuracy.

[0059] On the other hand, the method further includes dynamically and actively allocating permission tokens. The method for dynamically and actively allocating permission tokens includes: Monitoring the status of the collaboration application process among platforms 10 and the triggering of preset external events; After manual annotation, obtaining the status of the collaboration application process and the associated required data sets and potential requesters when the preset external event is triggered, to obtain sample data; Establishing and using the sample data to train a machine learning model to obtain an active allocation model; Based on the active allocation model, obtaining the required data sets and potential requesters for the subsequent monitored status of the collaboration application process among platforms 10 and the triggering of preset external events; Generating a permission token corresponding to the required data set for the potential requester and notifying the potential requester.

[0060] Continuously track the status changes of data sharing requests and collaboration applications among the platforms 10, as well as specific external events, such as emergencies and regular tasks, to trigger the dynamic and proactive allocation of permission tokens. For example, when facing sudden floods or rainstorm warnings, local governments need to quickly organize multi-departmental cooperation, including data sharing and collaboration among departments such as water conservancy, meteorology, public security, and civil affairs. Traditional permission management methods often delay the best response time due to cumbersome approval processes. Monitor the status of the collaboration application process among the platforms 10 and the triggering of preset external events, and monitor in real-time the rainstorm warning information (external event) released by the meteorological forecasting system, while tracking the status of the collaboration application process among departments. For example, when an orange rainstorm warning is issued in a certain area, the system automatically identifies this as a "flood control emergency" scenario and starts to prepare for relevant permission adjustments.

[0061] In previous flood control work, administrators would record which departments, such as the Water Conservancy Bureau and the Public Security Bureau, needed to access which specific types of data, such as river water levels and resident evacuation route maps, and the roles of the visitors to this data, such as flood control commanders and on-site rescue personnel. These constitute the sample data for training the machine learning model. Use the sample data to train a machine learning model that can predict which data sets are needed and who will be the potential data requesters based on the characteristics of the current flood control event, such as the warning level and the affected area. The model is optimized through multiple iterations to ensure its accurate prediction of requirements in different scenarios. When a new rainstorm warning is triggered, the system uses the trained proactive allocation model for analysis. Suppose the proactive allocation model predicts that technicians from the Water Conservancy Bureau may need to access the latest river water level monitoring data to formulate an emergency drainage plan; at the same time, staff from the Public Security Bureau may need to obtain community floor plans to plan the evacuation routes of residents. The platform 10 automatically generates permission tokens for technicians from the Water Conservancy Bureau and staff from the Public Security Bureau, allowing them to access the required data sets within a limited time. Notify the relevant personnel by text message or internal message, informing them that they have been granted access rights and providing guidance on how to quickly find and use this data. By pre-allocating permissions, relevant departments and technicians can obtain critical data immediately without waiting for formal approval, thus accelerating the decision-making speed.

[0062] On the other hand, this specification provides a dynamic control system for multi-platform data collaboration governance permissions. Please refer to the appendix Figure 4 , including: A labeling module 100 that labels each field of the data on each platform 10 with a static permission description 12, and the static permission description 12 includes department, usage role, confidentiality level, usage scenario description, validity period description, and operation description; A retrieval module 200 that, when any platform 10 receives an event work order 21 or a collaboration application sent by a user 20, obtains a requested data result set according to the retrieval formula carried by the event work order 21 or the collaboration application; An identification module 300, which identifies the current scenario, the requester's department, the requester's role, and the requester's permission level according to the event work order 21 or the collaboration application; A first comparison module 400, which traverses the fields included in the request data result set, compares the static permission description 12 of the fields with the requester's department, the requester's role, and the requester's permission level, and obtains a static permission data set; A second comparison module 500, which compares the static permission description 12 of the fields with the current scenario, and obtains a dynamic permission data set and a validity period; A verification module 600, which performs conflict verification on the static permission data set and the dynamic permission data set, obtains a permission set, and generates a permission token according to the permission set and the validity period; An execution module 700, where the user 20 uses the permission token and the data retrieval formula to obtain data from the platform 10. The platform 10 feeds back the data and records the log at the same time, and stores the log in the blockchain according to a preset period; A monitoring module 800, where the platform 10 takes back the permission token based on the expiration of the validity period, the triggering of the completion event of the current scenario, or the abnormal query behavior of the user 20.

[0063] Please refer to Figure 5 The structural schematic diagram of an electronic device provided by the embodiment of the present specification shown.

[0064] As Figure 5As shown, the electronic device 1100 may include: at least one processor 1101, at least one network interface 1104, a user interface 1103, a memory 1105, and at least one communication bus 1102. Among them, the communication bus 1102 can be used to realize the connection and communication of the above-mentioned various components. Among them, the user interface 1103 may include buttons, and the optional user interface may further include a standard wired interface and a wireless interface. Among them, the network interface 1104 may but is not limited to include a Bluetooth module, an NFC module, a Wi-Fi module, etc. Among them, the processor 1101 may include one or more processing cores. The processor 1101 connects various parts within the entire electronic device 1100 through various interfaces and lines, and by running or executing instructions, programs, code sets, or instruction sets stored in the memory 1105, and by calling data stored in the memory 1105, it executes various functions of the routing device and processes data. Optionally, the processor 1101 may be implemented in at least one hardware form of a DSP, an FPGA, or a PLA. The processor 1101 may integrate one or a combination of several of a CPU, a GPU, and a modem, etc. Among them, the CPU mainly processes the operating system, the user interface, and application programs, etc.; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; the modem is used to process wireless communication.

[0065] It can be understood that the above-mentioned modem may not be integrated into the processor 1101 and may be implemented separately by a single chip.

[0066] Among them, the memory 1105 may include a RAM and may also include a ROM. Optionally, the memory 1105 includes a non-transitory computer-readable medium. The memory 1105 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 1105 may include a program storage area and a data storage area. Among them, the program storage area may store instructions for implementing the operating system, instructions for at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store the data involved in the above-mentioned various method embodiments. Optionally, the memory 1105 may further be at least one storage device located far from the aforementioned processor 1101. The memory 1105, as a computer storage medium, may include an operating system, a network communication module, a user interface module, and application programs. The processor 1101 may be used to call the application programs stored in the memory 1105 and execute the methods in the above-mentioned multiple embodiments.

[0067] The embodiments of this specification also provide a computer-readable storage medium. Instructions are stored in the computer-readable storage medium. When the instructions are run on a computer or a processor, the computer or the processor is caused to execute multiple steps in the above embodiments. If each component module of the above electronic device is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in the computer-readable storage medium.

[0068] The embodiments of this specification also provide a computer program product, including a computer program. When the computer program is executed by a processor, multiple steps in the above embodiments are implemented.

[0069] Without conflict, the technical features in this embodiment and the implementation solutions can be combined arbitrarily.

[0070] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes multiple computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this specification are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center in a wired manner (such as coaxial cable, optical fiber, Digital Subscriber Line (DSL)) or a wireless manner (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or a data center that integrates multiple available media. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a Digital Versatile Disc (DVD)), or a semiconductor medium (for example, a Solid State Disk (SSD)), etc.

[0071] When implemented by hardware or firmware, the foregoing method flow is programmed into a hardware circuit to obtain a corresponding hardware circuit structure and implement the corresponding functions. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit, and its logic function is determined by a user's programming of the device. A designer can program by himself to integrate a digital system on a PLD without asking a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating an integrated circuit chip, this programming is mostly implemented using logic compiler software, which is similar to the software compiler used in program development and writing. The original code before compilation also has to be written in a specific programming language, which is called a hardware description language (HDL), and there are not only one but many kinds of HDLs. Those skilled in the art should also be clear that only by slightly logically programming the method flow with the above-mentioned several hardware description languages and programming it into an integrated circuit can a hardware circuit implementing the logic method flow be easily obtained.

[0072] The embodiments described above are only described in a preferred embodiment manner of this specification, and do not limit the scope of this specification. Without departing from the design spirit of this specification, various deformations and improvements made by those of ordinary skill in the art to the technical solutions of this specification should all fall within the protection scope determined by the claims of this specification.

Claims

1. A method for dynamically controlling multi-platform data collaborative governance permissions, characterized in that, Including the steps: Each platform labels static permission descriptions for each field of the data. The static permission descriptions include department, usage role, confidentiality level, usage scenario description, validity period description, and operation description; When any platform receives an event work order or collaboration application sent by a user, it obtains a request data result set according to the retrieval formula carried in the event work order or collaboration application; Identify the current scenario, requester's department, requester's role, and requester's permission level according to the event work order or collaboration application; Traverse the fields included in the request data result set, compare the static permission descriptions of the fields with the requester's department, requester's role, and requester's permission level, and obtain a static permission data set; Compare the static permission description of the field with the current scenario to obtain a dynamic permission data set and a validity period; Perform conflict verification on the static permission data set and the dynamic permission data set to obtain a permission set, and generate a permission token according to the permission set and the validity period; The user uses the permission token and the data retrieval formula to obtain data from the platform. The platform feeds back the data and records the log at the same time, and stores the log on the blockchain at a preset period; The platform withdraws the permission token based on the expiration of the validity period, the triggering of the conclusion of the current scenario event, or the triggering of an abnormal query behavior by the user.

2. The method for dynamically controlling multi-platform data collaborative governance permissions according to claim 1, wherein: The method for identifying the current scenario, requester's department, requester's role, and requester's permission level according to the event work order or collaboration application includes: Analyze the meta-information included in the event work order or collaboration application to obtain the scenario label, applicant identifier, and organizational structure path therein; Query the accessed user database according to the applicant identifier to obtain the requester's department, job level, and position role; Obtain the requester's role according to the job level, and obtain the requester's permission level according to the pre-stored mapping of position role permission levels; Attempt to identify the business type, process stage, and task description carried in the event work order or collaboration application, and identify the current scenario according to the preset scenario classification.

3. The method for dynamically controlling multi-platform data collaborative governance permissions according to claim 1 or 2, wherein: The method for comparing the static permission description of the field with the requester's department, requester's role, and requester's permission level to obtain a static permission data set includes: For the department, usage role, and confidentiality level in the static permission description of each field, compare them with the requester's department, requester's role, and requester's permission level respectively to obtain matching fields; According to the matching fields, obtain a static permission data set from the request data result set.

4. The method for dynamically controlling multi-platform data collaborative governance permissions according to claim 3, wherein: The method for comparing the static permission description of the field with the current scenario to obtain a dynamic permission data set and a validity period includes: Read the pre-established scenario permission mapping table; Compare the current scenario with the scenario permission mapping table to obtain a dynamic permission field set; Obtain a dynamic permission data set from the request data result set according to the dynamic permission field set; Obtain a validity period according to the current scenario and the validity period description.

5. The method for dynamically controlling multi-platform data collaborative governance permissions according to claim 1 or 2, characterized in that The method for performing conflict verification on the static permission data set and the dynamic permission data set to obtain a permission set and generating a permission token according to the permission set and the validity period includes: When a field existing in the dynamic permission data set does not exist in the static permission data set, set the permission of the field to read-only permission; Obtain a permission set according to the dynamically permission data set after resetting the permissions; Generate a permission token according to the permission set and the validity period.

6. The method for dynamically controlling multi-platform data collaborative governance permissions according to claim 1, characterized in that The method further includes dynamically and actively allocating permission tokens, and the method for dynamically and actively allocating permission tokens includes: Monitor the status of the collaboration application process between platforms and the triggering of preset external events; Obtain sample data by manually annotating the status of the collaboration application process and the required data sets and potential requesters associated when the preset external event is triggered; Establish and use the sample data to train a machine learning model to obtain an active allocation model; Obtain the required data sets and potential requesters according to the active allocation model for the status of the collaboration application process between platforms and the triggering of preset external events monitored subsequently; Generate a permission token for the required data set corresponding to the potential requester and notify the potential requester.

7. Multi-platform data collaborative governance permission dynamic control system, characterized in that, Includes: A labeling module, where each platform labels static permission descriptions for each field of the data, and the static permission descriptions include department, usage role, confidentiality level, usage scenario description, validity period description, and operation description; A retrieval module, when any platform receives an event work order or collaboration application sent by a user, obtain a request data result set according to the retrieval formula carried by the event work order or collaboration application; An identification module, identify the current scenario, requester department, requester role, and requester permission level according to the event work order or collaboration application; A first comparison module, traverse the fields included in the request data result set, compare the static permission descriptions of the fields with the requester department, requester role, and requester permission level, and obtain a static permission data set; A second comparison module, compare the static permission descriptions of the fields with the current scenario to obtain a dynamic permission data set and a validity period; A verification module, perform conflict verification on the static permission data set and the dynamic permission data set to obtain a permission set, and generate a permission token according to the permission set and the validity period; An execution module, the user uses the permission token and the data retrieval formula to obtain data from the platform, the platform feeds back the data and records the log at the same time, and stores the log in a blockchain at a preset period; A monitoring module, the platform withdraws the permission token based on the expiration of the validity period, the triggering of the current scenario completion event, or the triggering of an abnormal query behavior by the user.

8. An electronic device, characterized in that, Includes a processor and a memory; The processor is connected to the memory; The memory is configured to store executable program code; The processor runs a program corresponding to the executable program code by reading the executable program code stored in the memory, so as to execute the method according to any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, the method according to any one of claims 1-6 is implemented.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, the method according to any one of claims 1-6 is implemented.

Images