Data sharing management system and method for database

Abstract

The invention relates to the technical field of computers, in particular to a data sharing management system and method for a database, and the system comprises an identity verification module, a permission adaptation and grading approval module, a risk control module and an iteration module, and the method correspondingly executes the functions of the modules. The identity verification guarantees the legality of an access subject through format verification and multi-dimensional hierarchical authentication, and the intensity of the hierarchical authentication is dynamically adjusted along with the data sensitivity; authority management and control execute differentiation logic according to public, internal and confidential three levels, and fine authorization is achieved; the risk control module monitors abnormal operation in real time and performs grading processing; all operations are recorded in a block chain audit log, and the system realizes dynamic iteration through regular verification and historical data optimization. The data sharing security and cooperation efficiency are considered, the risk controllability and the system adaptability are improved, and the multi-scene data sharing requirements such as enterprise cross-department and external cooperation are met.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a data sharing management system and method for database. BACKGROUND

[0002] Under the background of digital transformation, enterprise data sharing scenarios continue to expand, and the demand for cross-departmental collaboration and external cooperation is increasing. The balance between data security and sharing efficiency has become a core pain point. The existing data sharing management scheme has obvious limitations: the identity authentication mode is single, relying mainly on static passwords and other basic verifications, and the authentication strength cannot be dynamically adjusted according to the sensitivity of the data, making it difficult to resist targeted security risks; the authority control lacks fine-grained classification logic, and the same authorization process is used for data of different security levels, which either affects collaboration efficiency due to excessive control or causes data leakage risks due to lax authorization; the risk control mechanism responds slowly, the abnormal operation recognition dimension is limited, and there is no clear classification disposal standard; the audit log is centrally stored and easily tampered with, and cannot realize full-process traceability; at the same time, the system rules are fixed and cannot be dynamically optimized based on historical operation data and abnormal feedback, which lacks adaptability. These problems lead to a prominent contradiction between security and efficiency in the data sharing process, and cannot meet the needs of enterprises for fine-grained control of data, risk early warning, and sustainable optimization, so there is an urgent need for a data sharing management scheme that takes into account security, flexibility, and dynamic iteration capability. SUMMARY

[0003] In view of the above, the present application proposes a data sharing management system and method for database to solve at least one of the problems in the background art.

[0004] In a first aspect, the present application provides a data sharing management system for database, comprising: an identity verification module configured to receive a sharing request submitted by a user, the sharing request containing a requester ID, a target data identifier, a use scenario, and an estimated duration, first verify the completeness of the request format, and then verify the identity of the requester through multi-dimensional identity authentication, the multi-dimensional identity authentication including basic verification and hierarchical authentication, the basic verification being matching a user registration table and a blacklist, and the hierarchical authentication being dynamically adjusting the authentication strength according to the sensitivity of the target data; an authority adaptation and hierarchical approval module configured to query the desensitization classification label of the target data, and execute differentiated authority logic according to three levels of public, internal, and confidential; wherein the public data directly generates a temporary access token for the authenticated user, the internal data executes automatic authorization or hierarchical approval based on cross-departmental collaboration relationship, and the confidential data is only open to whitelist scenarios and requires double approval; a risk control module configured to monitor the authorized sharing operation in real time, and suspend the authority and trigger an early warning when an abnormal indicator is detected; The iteration module is configured to write all operations to the blockchain audit log, periodically verify the rules, and optimize system parameters based on historical data. In some embodiments, the verification request format integrity includes: when the target data identifier cannot accurately locate a specific data table or field, automatically associating it with a data dictionary and pushing a pre-stored matching table name for the user to select; When the estimated duration exceeds the system's preset upper limit, it will be automatically corrected to the current time plus one hour and the user will be prompted for confirmation. When the application scenario involves external collaboration, the name of the collaborator and the collaboration agreement number must be included.

[0005] In some embodiments, in the hierarchical authentication of the identity verification module, when the sensitivity of the target data is public, it needs to be verified by a password plus a verification code. When the target data is sensitive to internal or confidential levels, it needs to be verified through multiple factors, including at least two of the following: password, verification of frequently used devices in the past thirty days, SMS or biometric features. When a new device accesses the target data, if the sensitivity level of the target data is public, internal, or confidential, a temporary authorization code must be provided. The authorization code is valid for a preset time. When the target data is classified as confidential, access requires biometric verification.

[0006] In some embodiments, in the permission adaptation and hierarchical approval module, the hierarchical approval process for internal data is to approve data belonging to multiple levels sequentially, and to preset an approval threshold. When the actual approval time exceeds the approval threshold, the data will automatically flow to the next stage. During the approval process, access restrictions are implemented based on the applicant's compliance score. When the compliance score is not lower than 80, full access is granted; when the compliance score is between 60 and 79, download access is restricted; and when the compliance score is lower than 60, the request is rejected.

[0007] In some embodiments, in the permission adaptation and hierarchical approval module, after the confidential data is approved, if the permission validity period is less than the preset permission validity period threshold, and only online viewing is supported, the front-end disables the download, copy, and screenshot functions. Otherwise, online viewing is not supported.

[0008] In some embodiments, the abnormal indicators of the risk control module include: Data classified as confidential was accessed by the same user more than five times within five minutes; Data with an internal sensitivity level: more than ten files are downloaded within ten minutes, and each file is larger than 100 megabytes. Three consecutive attempts to access an unauthorized field; IP address switches no less than three non-company VPN node regions within ten minutes.

[0009] In some embodiments, the risk control module detects abnormal indicators, and performs disposal according to the abnormal level: The first-level abnormality is single unauthorized access, at which time the system pop-up window warns and deducts five points of compliance points; The second-level abnormality is that the IP frequently switches to download at a preset frequency, at which time the current permission is immediately suspended, and an abnormal signal is generated; The third-level abnormality is that the confidential data is exported, at which time the user's all data permissions are frozen, the database connection is cut off, and a warning signal is generated.

[0010] In some embodiments, the blockchain audit log of the iteration module includes a timestamp, a digital signature of an operator, a device fingerprint hash, desensitized data identification, and permission range.

[0011] In some embodiments, the iteration module includes that the rule checking and optimization of the iteration module includes that the rule checking above the preset number of times threshold is automatically performed every day, and the checking items cover the matching of shared records and permission rules. The red-level risk is that the confidential data is not approved, and such risk needs to be rectified within twenty-four hours; The quarterly optimization based on historical data includes adjusting the validity period of the new device authorization code according to the abnormal trigger rate, and adjusting the approval level according to the department compliance score.

[0012] In a second aspect, the application provides a data sharing management method for a database, comprising the following steps: Receiving a user-submitted sharing request containing a requester ID, target data identification, use scenario, and estimated duration, first checking the request format integrity, and then verifying the requester's identity through multi-dimensional identity authentication, the multi-dimensional identity authentication including basic verification and hierarchical authentication, the basic verification being matching the user registration table and the blacklist library, and the hierarchical authentication being dynamically adjusting the authentication strength according to the target data sensitivity; Querying the target data desensitization hierarchical label, and executing differentiated permission logic according to three levels of public, internal, and confidential; wherein the public data directly generates a temporary access token for the authenticated user, the internal data performs automatic authorization or hierarchical approval based on cross-department cooperation relationship, and the confidential data is only open to whitelist scenarios and requires double approval; Real-time monitoring of authorized sharing operations, suspending permissions and triggering warnings when abnormal indicators are detected; Writing all operations into a blockchain audit log, regularly checking rules and optimizing system parameters based on historical data.

[0013] Compared with the prior art, the beneficial effects of the present application are that: through multi-dimensional identity authentication and dynamic hierarchical authentication mechanism, combined with data sensitivity to adapt verification strength, both the access security of high sensitive data is ensured, and the verification process redundancy of low sensitive data is avoided, the balance of safety and efficiency is realized; based on the differentiated permission logic of data desensitization grading, the public data is quickly authorized, the internal data is flexibly adapted to the collaboration scene, the confidential data is strictly controlled, the sharing needs of different levels of data are finely met, and the risk of abuse of permissions is reduced; the real-time risk control module can identify and curb risk operations in time through clear abnormal indicators and hierarchical disposal rules, and reduce the probability of data leakage; the blockchain audit log ensures that the operation is traceable and tamper-proof throughout the link, and provides a reliable basis for responsibility identification; the iterative module dynamically optimizes system parameters based on historical data, so that the rules continuously adapt to the changes in the actual scene, and the long-term applicability of the system is improved.

[0014] The above general description and the following detailed description are merely exemplary and explanatory, but not limiting the present disclosure.

[0015] Other features and aspects of the present disclosure will be more clearly understood from the following detailed description of exemplary embodiments with reference to the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0016] In order to more clearly illustrate the specific embodiments of the present application or the technical solutions in the prior art, the drawings needed in the specific embodiments or the prior art description will be briefly introduced below. Obviously, the drawings in the following description are some embodiments of the present application, and those skilled in the art can also obtain other drawings according to these drawings without creative labor.

[0017] Figure 1 The functional block diagram of the data sharing management system for the database provided by the embodiment of the present application is shown in the figure; Figure 2 The flow chart of the data sharing management method for the database provided by the embodiment of the present application is shown in the figure; DETAILED DESCRIPTION

[0018] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments described herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art. It should be noted that the embodiments in the present application and the features in the embodiments can be combined with each other without conflict. The present application will be described in detail below with reference to the drawings and in combination with the embodiments.

[0019] Reference Figures 1-2As shown in the first embodiment, the data sharing management system for a database according to the embodiment of the application comprises: The identity verification module is configured to receive a sharing request submitted by a user, the sharing request containing a requester ID, target data identifier, use scenario, and expected duration, and to verify the request format integrity first and then verify the requester identity through multi-dimensional identity authentication, the multi-dimensional identity authentication including basic verification and hierarchical authentication, the basic verification being matching a user registration table and a blacklist library, and the hierarchical authentication being dynamically adjusting the authentication strength according to the target data sensitivity; The permission adaptation and hierarchical approval module is configured to query a target data desensitization hierarchical label and execute differentiated permission logic according to three levels of public, internal, and confidential; wherein the public data directly generates a temporary access token for the authenticated user, the internal data performs automatic authorization or hierarchical approval based on cross-department cooperation relationship, and the confidential data is only open to whitelist scenarios and requires double approval; The risk control module is configured to monitor the authorized sharing operation in real time, suspend the permission when detecting abnormal indicators, and trigger an early warning; The iteration module is configured to write all operations into a blockchain audit log, regularly check the rules, and optimize the system parameters based on historical data.

[0020] It should be understood that the identity verification module serves as the starting point of the entire process, and first receives a sharing request submitted by a user, the request containing a requester ID, target data identifier, use scenario, and expected duration. Before identity verification, the module first verifies the integrity of the request format: if there is missing or unclear information, the user will be prompted to supplement or correct in a timely manner. Subsequently, multi-dimensional identity authentication is entered, the basic verification preliminarily filters out the compliant request subject by comparing the user registration table (confirming whether the user is a legal registered member) and the blacklist library (excluding users who have been marked as risks) in the system, and the hierarchical authentication dynamically adjusts the strictness according to the sensitivity of the target data, for example, data with low sensitivity may only need simple verification, while high-sensitivity data needs a more complex verification process, so as to ensure that the strength of identity verification matches the importance of data.

[0021] The permission adaptation and hierarchical approval module performs differentiated management based on the desensitization hierarchical labels (public, internal, confidential) of the target data. For public data, the system will directly generate a temporary access token to allow instant access as long as the user passes the identity verification. The processing of internal data needs to be combined with cross-department collaboration: if the requester and the data ownership department have preset collaboration permissions, the system will automatically authorize, otherwise it will start a hierarchical approval process, and the data ownership person in charge at each level will approve in turn. The sharing of confidential data is the most restricted, only for preset whitelist scenarios (such as specific core business scenarios), and must be approved by two people (such as the department head and the security officer), ensuring that every access is strictly controlled.

[0022] The risk control module assumes the responsibility of real-time monitoring during data sharing, by collecting data such as user access frequency, operation type (download, copy, etc.), IP address changes, and comparing them with preset abnormal indicators. Once abnormal behavior is detected (such as high-frequency access to sensitive fields, abnormal IP jumps, etc.), the user's access rights will be suspended immediately, and different levels of early warning (such as system pop-up windows, administrator notifications, etc.) will be triggered to prevent data from being illegally obtained or leaked during sharing.

[0023] The iteration module is responsible for the continuous optimization of the system: on the one hand, all operations (including request submission, approval records, access behavior, abnormal handling, etc.) are written in detail into the blockchain audit log, using the non-tamperable characteristics of the blockchain to ensure that every step of operation can be traced and audited; on the other hand, the system rules are checked regularly (such as checking whether the approval process is in compliance, whether the permission allocation is reasonable), and based on historical data (such as abnormal trigger frequency, approval efficiency, etc.), the system parameters (such as authentication strength threshold, approval level setting, etc.) are adjusted, so that the system continuously adapts to actual business needs, balancing security and efficiency.

[0024] In some embodiments, the verification of the request format integrity includes: when the target data identifier cannot accurately locate a specific data table or field, automatically associate the data dictionary and push the system's pre-stored matching table name for user selection; When the estimated time exceeds the system's preset upper limit, it is automatically corrected to the current time plus one hour and prompts the user for confirmation; When the use scenario is external cooperation, the name of the cooperation party and the cooperation agreement number need to be attached.

[0025] It should be understood that when the target data submitted by the user identifies (such as table name, field name) is ambiguous or cannot be accurately located, the system will automatically call a preset data dictionary that records the names, meanings and correlation of all data tables and fields in the database, and through keyword matching, the most likely matching table name or field name is pushed to the user for selection (for example, the user inputs "customer information", and the system will push "customer_base" "customer_detail" and other related table names), avoiding the user from submitting invalid requests due to unfamiliarity with data identification. If the user fills in a predicted duration that exceeds the system preset upper limit (for example, the system stipulates that the maximum access duration is 7 days, and the user fills in 10 days), the system will automatically correct the duration to a temporary value of "current time + 1 hour", and prompt the user for confirmation through a pop-up window or a short message. The user can choose to accept the temporary value or re-enter a reasonable duration that does not exceed the upper limit, so as to prevent long-term occupation or abuse of data due to excessive permission duration. When the use scenario is "external cooperation" (i.e. data needs to be shared with external agencies or personnel), the system will forcibly require the user to supplement "cooperation party name" and "cooperation agreement number": the cooperation party name needs to match the list of registered cooperation agencies in the system, and the cooperation agreement number needs to be able to query the corresponding valid agreement in the enterprise contract management system, so as to ensure that external data sharing has clear business basis and legal support, and facilitate subsequent audit to trace data flow and responsible subject.

[0026] In some embodiments, in the hierarchical authentication of the identity verification module, when the target data sensitivity is public level, password plus verification code verification is required; When the target data sensitivity is internal level or confidential level, multi-factor authentication is required, including at least two of password, near thirty days of commonly used device verification, short message or biometric characteristics; When a new device accesses, when the target data sensitivity level is public level, internal level or confidential level, a temporary authorization code needs to be provided, and the authorization code is valid within a preset time; When the target data sensitivity is confidential level, access needs to be verified by biometric characteristics.

[0027] It should be understood that for the data with a sensitivity of a public level (such as product information disclosed by an enterprise), the authentication strength is the lowest, only the correct account password input by a user is required, and verification through a short message or a graphic verification code is required, the data leakage risk is low, and the basic verification is sufficient to meet the security requirement. For internal data (such as business reports in a department) or confidential data (such as core technical parameters and customer privacy information), multi-factor authentication is required, and at least two verification conditions are required to be met: for example, “password + device check in the last 30 days” (whether the device is a device commonly used by the user is verified through hardware fingerprint comparison), “password + short message verification code” (secondary confirmation through a mobile phone short message), and “password + biological characteristics” (such as fingerprint, face, and other unique characteristics). Among them, the confidential data is extremely high in sensitivity, and is additionally required to pass through biological characteristic verification, and the non-reproducibility of biological characteristics is used to further ensure the authenticity of the identity of the visitor. For new device access (that is, a device not commonly used by the user in the last 30 days), no matter the sensitivity level of the target data, the system will require the user to provide a temporary authorization code: the authorization code is sent by the system through a mobile phone number or an email address reserved by the user, and is valid within a preset time (such as 10 minutes), and the user needs to input the authorization code within the validity period to complete the verification. This mechanism can effectively prevent the risk of illegal access to data by an attacker through a strange device after the account is stolen.

[0028] In some specific embodiments, the permission adaptation and hierarchical approval module, the hierarchical approval process of the internal data is a multi-level approval in turn of data ownership, and a preset approval threshold is set, and when the actual approval time is greater than the approval threshold, the next link is automatically transferred; The permission restriction is executed in combination with the compliance score of the requester in the approval process, full permission is granted when the compliance score is not less than 80%, the download permission is limited when the compliance score is 60% to 79%, and the request is rejected when the compliance score is less than 60%.

[0029] It should be understood that the approval of internal data needs to follow the principle of "data ownership multi-level approval in turn": for example, the business data of a certain department needs to be initially reviewed by the department head (to confirm the necessity of data use), and then submitted to the department head for review (to evaluate the rationality of cross-department sharing), and if the data involves multiple departments, it also needs to be reviewed by the company-level data administrator. At the same time, the system will preset an "approval threshold" for each approval link (such as the longest approval time for each link is 24 hours), if a certain link has not completed the approval within the threshold time, the system will automatically transfer the request to the next link, and send a reminder to the person in charge who has not approved in time, to avoid the approval process from being blocked due to human delay. During the approval process, the system will combine the "compliance score" of the requester (based on the user's historical operation records, with a full score of 100) to perform differentiated permission restrictions: users with a compliance score of 80 or higher (no historical violation records, and the use of permissions is standardized) will be granted full permissions (including viewing, downloading, and copying data); users with a score of 60-79 (with minor violation records, such as once exceeding the time limit for occupying permissions) will be restricted from downloading permissions (only online viewing is allowed, and local saving is not allowed); users with a score of less than 60 (with multiple violation records, such as unauthorized access and data leakage risks) will have their requests directly rejected, thereby filtering trusted access subjects based on their historical compliance performance and reducing the risk of internal data leakage.

[0030] In some embodiments, after the confidential data approval, when the permission validity period is less than the preset permission validity threshold, and only online viewing is supported, the front-end disables the download, copy, and screenshot functions; Otherwise, online viewing is not supported.

[0031] It should be understood that after the confidential data approval, the system will first determine the relationship between the "permission validity" (the length of time the user wishes to access the data) and the "preset permission validity threshold" (such as 24 hours): if the permission validity is less than the threshold (such as the user applies for 2 hours of access), only online viewing is supported, and at this time the front-end interface will forcibly disable the download, copy, and screenshot functions through technical means (for example, shielding the "copy" and "save as" options in the right-click menu, and intercepting system-level screenshot shortcuts such as PrintScreen to prevent users from obtaining data through screenshot tools), ensuring that the data can only be temporarily viewed in the system and cannot be saved offline. If the permission validity is not less than the preset threshold (such as the user applies for 3 days of access), online viewing is not supported, and in such scenarios, data usually needs to be transmitted offline through encrypted physical media (such as encrypted USB drives): the user needs to submit an offline access application, which is reviewed by the security department, and then a special person copies the encrypted data to a special USB drive while recording the pickup time and user information of the USB drive; after the user finishes using it, the USB drive needs to be returned in a timely manner, and the system will check whether the data has been tampered with or copied, thereby controlling the spread of confidential data through physical isolation.

[0032] In some embodiments, the abnormal indicators of the risk control module include: More than five times of access to the same field by the same user within five minutes for data with confidentiality level; More than ten times of downloading files within ten minutes for data with internal level, and a single file is larger than one hundred megabytes; Three consecutive attempts to access unauthorized fields; Switching of IP address to not less than three non-company VPN node regions within ten minutes.

[0033] It should be understood that for data with confidentiality level, if the same user accesses the same field more than five times within five minutes, the system will determine that it is abnormal, and frequent access to the same sensitive field may be that the user tries to obtain data in batches through multiple operations (such as manual recording or script crawling); for data with internal level, if more than ten files are downloaded within ten minutes, and a single file is larger than one hundred megabytes, it will be marked as abnormal, and a large amount of large capacity download may be that the user tries to transfer internal data to external storage medium; three consecutive attempts to access unauthorized fields (i.e. tables or fields that the user has no access to) will be determined as abnormal, and such behavior may be that the user is trying to explore the boundary of system permission, and there is a risk of unauthorized data stealing; if the IP address is switched to not less than three non-company VPN node regions within ten minutes, it will be marked as abnormal, and frequent IP jumping and non-company approved VPN node may be that the attacker hides the real address through proxy server to try to bypass the regional restrictions of the system for illegal access. By monitoring these indicators, the risk control module can timely warn before data leakage occurs.

[0034] In some embodiments, after the risk control module detects abnormal indicators, it executes disposal according to the abnormal level: First-level abnormality is single unauthorized access, at this time the system pop-up window warns and deducts five points of compliance points; Second-level abnormality is IP frequent switching and preset frequency downloading, at this time the current permission is immediately suspended, and an abnormal signal is generated; Third-level abnormality is confidential data export, at this time the user's all data permissions are frozen, the database connection is cut off, and a warning signal is generated.

[0035] It should be understood that the first level of exception is "single unauthorized access" (such as a user mistakenly clicking on an unauthorized field), which is relatively light, and the system will immediately pop up a window to warn the user (prompting "current operation has no permission, please use it properly") and automatically deduct 5 points of compliance points, and the reduction of compliance points will affect the user's subsequent permission application (such as low score may lead to rejection of the approval); the second level of exception is "frequent IP switching and downloading according to the preset frequency" (such as meeting the "internal level data download + IP abnormal jump" in claim 6), which is medium, the system will immediately suspend the user's current all data rights (cannot continue to access, download any data), and generate an exception signal to push to the data security administrator (including user ID, exception behavior details, timestamp, etc.), which is manually checked by the administrator whether it is a malicious operation; the third level of exception is "secret data export" (such as the system discovers through traffic monitoring that the user sends secret data to the outside through email or instant messaging tools), which is serious, the system will immediately freeze the user's all data rights (including all authorized and unauthorized data access entrances), forcibly cut off its connection with the database (terminate the current session, refuse new connection request), and generate a warning signal to trigger the emergency response process (such as notifying the security department to trace the data flow, contacting the user to verify the situation), and minimize the impact of secret data leakage.

[0036] In some embodiments, the blockchain audit log of the iteration module includes a timestamp, a digital signature of an operator, a device fingerprint hash, a desensitized data identifier, and a permission range.

[0037] It should be understood that the log includes several key elements: the timestamp is accurate to the millisecond level, recording the specific time when each operation (such as request submission, approval, data access) occurs, ensuring that the operation timing is traceable; the digital signature of the operator is a unique identifier generated by the user through private key encryption, which matches the user public key stored in the system, and can verify the real identity of the operator to prevent identity forgery; the device fingerprint hash is a string obtained by hashing the hardware information (such as CPU serial number, network card MAC address) of the access device, which can uniquely identify the operation device and facilitate tracing the operation source; the desensitized data identifier is a desensitized treatment (such as replacing "TBL-001") of the original data identifier (such as table name "customer_privacy"), which avoids leaking sensitive data information in the log itself; the permission range records in detail the operation type (view, download, etc.), data range (specific table or field), and permission validity (start and end time) granted to the user. These information are packaged into blockchain blocks and stored through distributed nodes, ensuring that they cannot be tampered with or deleted, and providing a solid support for compliance auditing of the whole process of data sharing.

[0038] In some embodiments, the iteration module includes: the rule checking and optimization of the iteration module includes: daily automatic execution of rule checking above a preset number threshold, and the checking items cover the matching of shared records and permission rules; The red level risk is the approval of confidential data, and such risk needs to be rectified within 24 hours. The quarterly optimization based on historical data includes adjusting the validity period of the new device authorization code according to the abnormal trigger rate and adjusting the approval level according to the department compliance score.

[0039] It should be understood that the system is continuously adapted to business needs and balanced between security and efficiency through continuous self-checking and parameter adjustment. In the daily rule checking link, the system automatically performs rule checking above a preset number threshold (such as 3 times a day), and the checking items cover the matching of shared records and permission rules; for example, checking whether “confidential data is subject to double approval”, “whether the internal data download permission matches the user compliance score”, “whether the access to public data is subject to identity verification”, and the like, to ensure that the system rules are strictly implemented. If the check finds “red level risk” (such as the approval of confidential data is not accessed), the system will automatically mark and notify the responsible department to complete the rectification (including tracing the data access path, completing the approval process, punishing the responsible person, and optimizing the rule vulnerability) within 24 hours. The quarterly optimization link dynamically adjusts the system parameters based on historical data (such as operation records, abnormal records, and approval efficiency data in the past 3 months): for example, if the abnormal trigger rate (such as the authorized code being maliciously used) is high when a new device is accessed, the system will shorten the validity period of the new device authorization code (such as from 10 minutes to 5 minutes); if the compliance score of a department remains above 90 points for a long time (indicating that the users of the department operate in a standard manner), the system will reduce the approval level of its internal data (such as from “department-department-company” three-level approval to “department-department” two-level), improving the approval efficiency; if the compliance score of a department is continuously below 70 points, the system will increase the approval level (such as adding the security department approval on the basis of the original), strengthening the control. Through this “daily check + quarterly optimization” mechanism, the system can continuously iterate and upgrade to better meet the security and efficiency needs of data sharing.

[0040] In a second embodiment, a data sharing management method for a database according to an embodiment of the present application includes the following steps: S100, receiving a sharing request submitted by a user, the sharing request containing a requester ID, target data identifier, use scenario, and expected duration, first checking the completeness of the request format, and then verifying the identity of the requester through multi-dimensional identity authentication, the multi-dimensional identity authentication including basic verification and hierarchical authentication, the basic verification being matching a user registration table and a blacklist, and the hierarchical authentication being dynamically adjusting the authentication strength according to the sensitivity of the target data; S200, query target data desensitization classification label, execute differentiated permission logic according to public, internal and confidential three levels; wherein the public data generates a temporary access token directly for the authenticated user, the internal data performs automatic authorization or hierarchical approval based on cross-department cooperation relationship, and the confidential data is only open to the whitelist scene and needs double-person approval; S300, real-time monitoring of authorized sharing operations, suspending the permission and triggering an early warning when detecting abnormal indicators; S400, writing all operations into a blockchain audit log, regularly checking rules and optimizing system parameters based on historical data.

[0041] Those skilled in the art will appreciate that embodiments of the application can be provided as methods, systems or computer program products. Accordingly, the application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the application can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer readable program code.

[0042] The application is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device that implements the functions specified in the flowcharts and / or block diagrams. Figure 1 one or more flows and / or blocks Figure 1 an apparatus that performs the functions specified in one or more flows and / or blocks.

[0043] These computer program instructions can also be stored in a computer-readable memory that can direct the computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a product including instruction apparatus, which implements the functions specified in the flowcharts and / or block diagrams. Figure 1 one or more flows and / or blocks Figure 1 an apparatus that performs the functions specified in one or more flows and / or blocks.

[0044] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are performed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide a product for implementing the functions specified in the flowcharts and / or block diagrams. Figure 1 one or more flows and / or blocksFigure 1 the steps of the functions specified in the one or more blocks.

[0045] It should be noted that the above-mentioned embodiments are only used to illustrate the technical solutions of the present application, but not to limit the present application. Although the present application has been described in detail with reference to the above-mentioned embodiments, those skilled in the art should understand that the specific embodiments of the present application can be modified or equivalent replacements without departing from the spirit and scope of the present application, and any modifications or equivalent replacements should be covered in the protection scope of the claims of the present application.

Claims

1. A data sharing management system for databases, characterized in that, include: The identity verification module is configured to receive a sharing request submitted by a user, which includes the requester ID, target data identifier, usage scenario and expected duration. It first verifies the integrity of the request format, and then verifies the requester's identity through multi-dimensional identity authentication. The multi-dimensional identity authentication includes basic verification and hierarchical authentication. The basic verification is to match the user's registry and blacklist database, and the hierarchical authentication is to dynamically adjust the authentication strength according to the sensitivity of the target data. The permission adaptation and hierarchical approval module is configured to query target data with desensitized hierarchical tags and execute differentiated permission logic according to three levels: public, internal, and confidential. Among them, public data directly generates temporary access tokens for authenticated users, internal data performs automatic authorization or hierarchical approval based on cross-departmental collaboration relationships, and confidential data is only open to whitelist scenarios and requires approval from two people. The risk control module is configured to monitor authorized shared operations in real time, suspend permissions and trigger an alert when abnormal indicators are detected; The iteration module is configured to write all operations to the blockchain audit log, periodically verify the rules, and optimize system parameters based on historical data.

2. The data sharing management system for a database according to claim 1, characterized in that, The verification request format integrity includes: when the target data identifier cannot accurately locate the specific data table or field, automatically associating the data dictionary and pushing the system's pre-stored matching table name for the user to select; When the estimated duration exceeds the system's preset upper limit, it will be automatically corrected to the current time plus one hour and the user will be prompted for confirmation. When the application scenario involves external collaboration, the name of the collaborator and the collaboration agreement number must be included.

3. A data sharing management system for a database according to claim 2, characterized in that, In the hierarchical authentication of the identity verification module, when the sensitivity of the target data is public, it needs to be verified by a password plus a verification code. When the target data is sensitive to internal or confidential levels, it needs to be verified through multiple factors, including at least two of the following: password, verification of frequently used devices in the past thirty days, SMS or biometric features. When a new device accesses the target data, if the sensitivity level of the target data is public, internal, or confidential, a temporary authorization code must be provided. The authorization code is valid for a preset time. When the target data is classified as confidential, access requires biometric verification.

4. A data sharing management system for a database according to claim 3, characterized in that, In the permission adaptation and hierarchical approval module, the hierarchical approval process for internal data is that the data belongs to multiple levels and is approved sequentially, and an approval threshold is preset. When the actual approval time exceeds the approval threshold, it will automatically flow to the next stage. During the approval process, access restrictions are implemented based on the applicant's compliance score. When the compliance score is not lower than 80, full access is granted; when the compliance score is between 60 and 79, download access is restricted; and when the compliance score is lower than 60, the request is rejected.

5. A data sharing management system for a database according to claim 4, characterized in that, In the permission adaptation and hierarchical approval module, after the confidential data is approved, if the permission validity period is less than the preset permission validity period threshold, and only online viewing is supported, the front-end disables the download, copy, and screenshot functions. Otherwise, online viewing is not supported.

6. A data sharing management system for a database according to claim 5, characterized in that, The abnormal indicators of the risk control module include: Data classified as confidential was accessed by the same user more than five times within five minutes; Data with an internal sensitivity level: more than ten files are downloaded within ten minutes, and each file is larger than 100 megabytes. Three consecutive attempts to access an unauthorized field; The IP address was switched to no fewer than three non-company VPN node regions within ten minutes.

7. A data sharing management system for a database according to claim 6, characterized in that, After detecting abnormal indicators, the risk control module will take action according to the level of abnormality: A Level 1 exception is a single instance of unauthorized access, in which case the system will pop up a warning and deduct five compliance points. A level 2 anomaly occurs when the IP address frequently switches to the preset download frequency. In this case, the current access is immediately suspended, and an anomaly signal is generated. A Level 3 anomaly indicates that confidential data has been leaked. In this case, all user data permissions are frozen, the database connection is cut off, and a warning signal is generated.

8. A data sharing management system for a database according to claim 7, characterized in that, The blockchain audit log of the iterative module includes timestamps, operator digital signatures, device fingerprint hashes, anonymized data identifiers, and permission scopes.

9. A data sharing management system for a database according to claim 8, characterized in that, The iteration module includes: the rule verification and optimization of the iteration module includes: automatically performing rule verification above a preset threshold number of times per day, and the verification items cover the matching of shared records and permission rules; Red-level risks indicate that confidential data was not approved, and such risks must be rectified within 24 hours. Quarterly optimizations based on historical data include adjusting the validity period of new device authorization codes according to the anomaly trigger rate and adjusting the approval level according to departmental compliance scores.

10. A data sharing management method for a database, characterized in that, A data sharing management system for a database as described in any one of claims 1 to 9, comprising the following steps: The system receives a sharing request submitted by a user, which includes the requester ID, target data identifier, usage scenario, and expected duration. First, it verifies the integrity of the request format, and then verifies the requester's identity through multi-dimensional identity authentication. The multi-dimensional identity authentication includes basic verification and hierarchical authentication. The basic verification is to match the user's registry and blacklist database, and the hierarchical authentication is to dynamically adjust the authentication strength according to the sensitivity of the target data. The system queries target data with desensitized and tiered tags, and applies differentiated access logic based on three levels: public, internal, and confidential. Public data generates temporary access tokens directly for authenticated users, internal data is automatically authorized or subject to tiered approval based on cross-departmental collaboration, and confidential data is only accessible to whitelisted users and requires approval from two people. Real-time monitoring of authorized shared operations; suspension of permissions and triggering of alerts when abnormal indicators are detected. All operations are written to the blockchain audit log, rules are regularly verified, and system parameters are optimized based on historical data.

Images