Database audit method, device, storage medium and electronic device

Abstract

The present application relates to a method, device, storage medium and electronic device for the financial audit of a database. The method includes: obtaining a financial audit rule base through a management node, and loading the financial audit rule base to all data nodes in real time; receiving a first SQL statement sent from a client through a computing node of the database, and sending the first SQL statement to a target data node of the database; determining whether the first SQL statement is a high-risk operation according to the financial audit rule base through the target data node, and reviewing the first SQL statement if it is determined that the first SQL statement is a high-risk operation and the corresponding processing method is a review process; terminating the first SQL statement if the review result of the first SQL statement is that execution is not allowed, and returning the processing result of the first SQL statement to the client. The present application solves the technical problems of insufficient security of financial audit implemented by database proxy services and insufficient flexibility of built-in interception based on databases.

Description

Technical Field

[0001] The present application relates to the field of database security, and in particular to a database financial audit method, device, storage medium and electronic device. Background Art

[0002] Distributed databases are widely used to solve the problems of massive data storage and high-concurrency processing due to their high availability, easy scalability and low cost. However, with the increase in the number of data nodes and the complexity of cluster structures, the use and maintenance of distributed databases face more challenges, especially security issues, for developers and operators who are accustomed to centralized databases. In order to ensure the security of the database, especially the compliance and auditability of privileged operations, distributed databases require effective high-risk operation auditing and interception mechanisms. The existing security implementation methods are mainly divided into two types: the first method is to implement operation interception based on a proxy server, which is externally connected to the database system and acts as an intermediary to audit and intercept operations. The advantage is that operation review and security interception can be performed outside the database, with a good interception effect. However, its disadvantage is that there are bypassable security vulnerabilities, such as the exposure of the real address of the database, which may lead to direct bypassing of the proxy server to connect to the database for operation, thereby affecting security. The second method is to implement high-risk operation interception within the database system, such as prohibiting operations such as deleting databases or deleting tables. This method can effectively prevent some common high-risk operations and ensure the security of the database. However, the disadvantage of this method is that the overly simple prohibition strategy cannot adapt to flexible and changing business scenarios. Prohibiting certain operations may cause obstacles under specific business needs, and the lack of a review mechanism makes it impossible to finely manage which operations are reasonable in actual business, which can easily lead to rigid security management and lack of flexibility. In short, the existing technology lacks flexibility, simple prohibition strategies cannot adapt to dynamic business needs, and there is a problem of bypassing security vulnerabilities. The internal interception mechanism is too rigid, unable to finely manage high-risk operations, lacks review capabilities, and easily leads to problems in balancing security and flexibility. Summary of the invention

[0003] The present application provides a database financial audit method, device, storage medium and electronic device to solve the technical problems of insufficient security of financial audit implemented by database proxy service and insufficient flexibility based on database built-in interception.

[0004] In a first aspect, the present application provides a database financial review method, comprising: obtaining a financial review rule base through a management node of the database, and loading the financial review rule base into all data nodes of the database in real time; receiving a first SQL statement sent from a client through a computing node of the database, and sending the first SQL statement to a target data node of the database, wherein the target data node is at least one data node of the database; determining through the target data node whether the first SQL statement is a high-risk operation according to the financial review rule base, and reviewing the first SQL statement if it is determined that the first SQL statement is a high-risk operation and the corresponding processing method is review processing; terminating the first SQL statement if the review result of the first SQL statement is that execution is not allowed, and returning the processing result of the first SQL statement to the client.

[0005] In the second aspect, the present application provides a golden review device for a database, including: a first acquisition module, used to obtain a golden review rule base through a management node of the database, and load the above-mentioned golden review rule base to all data nodes of the above-mentioned database in real time; a sending module, used to receive a first SQL statement sent from a client through a computing node of the above-mentioned database, and send the above-mentioned first SQL statement to a target data node of the above-mentioned database, wherein the above-mentioned target data node is at least one data node of the above-mentioned database; a review module, used to determine whether the above-mentioned first SQL statement is a high-risk operation according to the above-mentioned golden review rule base through the above-mentioned target data node, and if it is determined that the above-mentioned first SQL statement is a high-risk operation and the corresponding processing method is review processing, the above-mentioned first SQL statement is reviewed; a processing module, used to terminate the above-mentioned first SQL statement when the review result of the above-mentioned first SQL statement is that execution is not allowed, and return the processing result of the above-mentioned first SQL statement to the above-mentioned client.

[0006] As an optional example, the above-mentioned golden audit rule library includes rules and processing methods for at least one operation attribute of the SQL statement, and the above-mentioned review module includes: a parsing unit, which is used to parse the above-mentioned first SQL statement to obtain each operation attribute of the above-mentioned first SQL statement; a first determination unit, which is used to determine whether each of the above-mentioned operation attributes is a high-risk operation according to the above-mentioned golden audit rule library; a second determination unit, which is used to determine that the above-mentioned first SQL statement is a high-risk operation when it is determined that there is a high-risk operation in all the above-mentioned operation attributes; a third determination unit, which is used to determine that the above-mentioned first SQL statement is not a high-risk operation when it is determined that there is no high-risk operation in all the above-mentioned operation attributes; a fourth determination unit, which is used to determine the processing method of the above-mentioned first SQL statement according to the above-mentioned golden audit rule library when it is determined that the above-mentioned first SQL statement is a high-risk operation, wherein the above-mentioned processing method includes review processing and prohibition processing.

[0007] As an optional example, the review module also includes: a first processing unit, which is used to determine whether the first SQL statement is a high-risk operation through the target data node according to the financial review rule base, and if it is determined that the first SQL statement is not a high-risk operation, send the first SQL statement to the database engine so that the database engine executes the first SQL statement; a second processing unit, which is used to terminate the first SQL statement and return the processing result of the first SQL statement to the client if it is determined that the first SQL statement is a high-risk operation and the corresponding processing method is to prohibit processing.

[0008] As an optional example, the review module includes: a cache unit for caching the first SQL statement; a generation unit for generating review data for the first SQL statement; a sending unit for sending the review data to the management node, so that the reviewer can upload the review result of the first SQL statement to the management node through the management platform of the management node based on the review data, wherein the review result includes allowing execution and not allowing execution.

[0009] As an optional example, the above-mentioned device also includes: a second acquisition module, which is used to obtain a second SQL statement through the above-mentioned management node after reviewing the above-mentioned first SQL statement, when the review result of the above-mentioned first SQL statement is to allow execution, wherein the above-mentioned second SQL statement is an SQL statement uploaded to the management node by the above-mentioned reviewer through the above-mentioned management platform; a matching module, which is used to match the above-mentioned second SQL statement with the above-mentioned first SQL statement, and when the above-mentioned second SQL statement and the above-mentioned first SQL statement match each other, send the above-mentioned first SQL statement to the database engine, so that the above-mentioned database engine executes the above-mentioned first SQL statement.

[0010] As an optional example, the above-mentioned device also includes: a prompt module, which is used to generate a prompt message and display it on the above-mentioned management platform after matching the above-mentioned second SQL statement and the above-mentioned first SQL statement, if the above-mentioned second SQL statement and the above-mentioned first SQL statement do not match each other, so that the above-mentioned reviewer can upload the SQL statement to the above-mentioned management node again through the above-mentioned management platform, wherein the above-mentioned prompt message is to prompt the above-mentioned reviewer that the above-mentioned second SQL statement and the above-mentioned first SQL statement do not match each other.

[0011] As an optional example, the above-mentioned device also includes: a modification module, which is used to obtain the financial review rule base through the management node of the database, and when it is detected that the administrator has modified the above-mentioned financial review rule base through the management platform of the above-mentioned management node, obtain the modified financial review rule base through the above-mentioned management node, and load the above-mentioned modified financial review rule base to all data nodes of the above-mentioned database in real time.

[0012] In a third aspect, the present application provides a storage medium storing a computer program, wherein the computer program executes the above-mentioned database audit method when executed by a processor.

[0013] In a fourth aspect, the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-mentioned database audit method through the computer program.

[0014] The above technical solution provided by the embodiment of the present application has the following advantages compared with the prior art:

[0015] This application adopts a method of obtaining a golden audit rule base through a database management node, and loading the golden audit rule base into all data nodes of the database in real time; receiving a first SQL statement sent from a client through a computing node of the database, and sending the first SQL statement to a target data node of the database, wherein the target data node is at least one data node of the database; determining whether the first SQL statement is a high-risk operation through the target data node according to the golden audit rule base, and reviewing the first SQL statement when it is determined that the first SQL statement is a high-risk operation and the corresponding processing method is a review process; terminating the first SQL statement when the review result of the first SQL statement is that execution is not allowed, and returning the processing result of the first SQL statement to the client, because in the above method, the golden audit rules are configured through the management node, and the rules are synchronized to all data nodes in real time. The SQL statement is routed to the target data node through the computing node, and the latter determines whether the SQL statement is a high-risk operation according to the golden audit rule base. If it is a high-risk operation and the processing method is review, the SQL statement will be cached and a record to be reviewed will be generated, and the operation and maintenance personnel will review it. If the review result is that execution is not allowed, the SQL execution is terminated and the processing result is returned to the client, thereby achieving real-time update of the rule base and interception of high-risk operations to ensure database security and prevent misoperation or malicious behavior. The review mechanism ensures a balance between security and business needs to avoid business operations being affected by overly strict rules. At the same time, it improves the transparency and compliance of database management, thereby solving the technical problems of insufficient security of the database proxy service to implement financial audit and insufficient flexibility based on the built-in interception of the database. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0017] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0018] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0019] Figure 1is a flow chart of an optional database gold audit method according to an embodiment of the present application;

[0020] Figure 2 is a functional architecture diagram of an optional database gold audit method according to an embodiment of the present application;

[0021] Figure 3 It is a flow chart of configuring a gold review rule base of an optional database gold review method according to an embodiment of the present application;

[0022] Figure 4 is a database gold audit flow chart of an optional database gold audit method according to an embodiment of the present application;

[0023] Figure 5 is a review flow chart of an optional database gold audit method according to an embodiment of the present application;

[0024] Figure 6 is a schematic structural diagram of an optional database gold review device according to an embodiment of the present application;

[0025] Figure 7 is a schematic diagram of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0026] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0027] The disclosure below provides many different embodiments or examples to realize the different structures of the present application. In order to simplify the disclosure of the present application, the parts and settings of specific examples are described below. Of course, they are only examples, and the purpose is not to limit the present application. In addition, the present application can repeat reference numbers and / or letters in different examples. This repetition is for the purpose of simplification and clarity, and does not itself indicate the relationship between the various embodiments and / or settings discussed.

[0028] According to a first aspect of an embodiment of the present application, a database audit method is provided. Optionally, as follows: Figure 1 As shown, the above method includes:

[0029] S102, obtaining a financial review rule base through a management node of the database, and loading the financial review rule base into all data nodes of the database in real time;

[0030] S104, receiving a first SQL statement sent from a client through a computing node of the database, and sending the first SQL statement to a target data node of the database, wherein the target data node is at least one data node of the database;

[0031] S106, determining whether the first SQL statement is a high-risk operation according to the financial review rule base through the target data node, and reviewing the first SQL statement if it is determined that the first SQL statement is a high-risk operation and the corresponding processing method is review processing;

[0032] S108: If the review result of the first SQL statement is that execution is not allowed, terminate the first SQL statement and return the processing result of the first SQL statement to the client.

[0033] Optionally, in this embodiment, if Figure 2 As shown in the functional architecture diagram, the client includes but is not limited to applications, open source clients (such as dbeaver), mysqlclient, etc., which are programs that can connect to and operate the database through the protocol provided by the database. The computing nodes of the distributed database are responsible for executing queries and data processing tasks, the storage nodes store data, and the management nodes are responsible for coordinating and scheduling computing and storage resources. The management nodes of the distributed database are responsible for coordinating and scheduling computing and storage resources, and usually include resource managers, task schedulers, monitoring and logging systems. The data nodes of the distributed database are responsible for actually storing the data of the database, and usually adopt a distributed storage architecture to improve the availability and access speed of the data. The GTM (Global Transaction Manager) of the distributed database is responsible for managing global transactions in the distributed system, coordinating transactions on multiple nodes, and ensuring the consistency and isolation of transactions.

[0034] Optionally, in this embodiment, the flowchart of configuring the financial audit rule base is as follows: Figure 3 As shown, first, the operation and maintenance manager logs in to the golden review rule management interface of the management node of the distributed database system, and sets or modifies the golden review rule base through the golden review rule management interface. These rules include elements such as client access method, IP, database user, operation type, operation object, data content and processing method. After the configuration is completed, the management node loads or updates these golden review rules to all data nodes in real time. Once the rule configuration is completed and submitted, the management node will synchronize these golden review rules to all data nodes of the database through the communication mechanism in the distributed system. This ensures that the data nodes can judge and intercept according to the latest rules when executing SQL operations, ensuring consistency and security.

[0035] Optionally, in this embodiment, the database audit process is as follows: Figure 4 As shown in the figure, when the client initiates an SQL request, the computing node first receives the SQL statement. The computing node sends the SQL request to the target data node according to the routing rules of the distributed database. The target data node may be one or more, which is determined by the data location and rules involved in the SQL query. The role of the computing node is not only to route the SQL request, but also to pass it to the appropriate data node for execution. After receiving the SQL statement, the target data node will parse the SQL statement and extract the attributes of the relevant operation, such as client access method, IP, database user, operation type, operation object, data content, etc. This information is the basis for judging whether the SQL statement meets the high-risk operation standard. Based on these parsed operation attributes, the data node queries and matches the golden audit rule library to judge whether the SQL statement meets the high-risk operation standard. If the operation type, database object, or data content of the SQL statement is consistent with the preset high-risk operation rules, then the operation will be marked as a high-risk operation. Once the SQL statement is determined to be a high-risk operation and the processing method of the corresponding golden audit rule is the "review" class, the SQL statement will be cached in the data node and a record to be reviewed will be generated. At this point, the review process will be initiated. Figure 5 As shown in the figure, the relevant review notification will be sent to the management node, and the operation and maintenance personnel or administrator or reviewer will receive the SQL statement to be reviewed. The reviewer logs in to the review interface of the management node to view the intercepted SQL statement and decide whether to allow it to execute. If the reviewer determines that the operation does not meet the requirements and the review result is "not allowed to execute", the review result will be fed back to the data node, and the SQL statement in the cache will be required to be deleted, and the relevant review records will be recorded. If the reviewer decides not to allow the high-risk operation to be executed, the execution of the SQL statement will be terminated, the SQL engine will not continue to process the statement, and will not issue actual database operation requests to the database execution engine. At the same time, the data node will return the corresponding processing results to the client, informing the user that the SQL statement is prohibited from execution because it has not passed the security audit, usually with the reason for the failure.

[0036] Optionally, in this embodiment, through the golden audit rule base set by the management node and the interception mechanism of the data node, high-risk operations, such as misoperation or malicious attacks, can be effectively prevented to protect the integrity and security of the database. A review-type processing method is adopted to ensure that when certain high-risk operations are performed, secondary confirmation can be performed by the operation and maintenance personnel. This review mechanism not only ensures security, but also avoids the impact of overly strict prohibition rules on business needs. By loading the golden audit rule base to all data nodes in real time, the distributed database system can update the rules in real time while ensuring flexible security management to prevent safety hazards caused by untimely rule modifications when business needs change. The audit and review process of all high-risk operations can be recorded and traced, providing an auditable basis for the security management and compliance of the database, helping to prevent potential operational risks.

[0037] As an optional example, the golden audit rule base includes a rule and a processing method for at least one operation attribute of an SQL statement, and determining whether the first SQL statement is a high-risk operation according to the golden audit rule base through the target data node includes:

[0038] Parsing the first SQL statement to obtain each operation attribute of the first SQL statement;

[0039] Determine whether each operation attribute is a high-risk operation based on the financial audit rule base;

[0040] In the case where it is determined that there is a high-risk operation in all operation attributes, determining that the first SQL statement is a high-risk operation;

[0041] When it is determined that there is no high-risk operation in all operation attributes, determining that the first SQL statement is not a high-risk operation;

[0042] When it is determined that the first SQL statement is a high-risk operation, a processing method for the first SQL statement is determined according to the financial audit rule base, wherein the processing methods include review processing and prohibition processing.

[0043] Optionally, in this embodiment, after the target data node of the database receives the SQL statement, the SQL statement is first parsed. The parsing process includes extracting various operation attributes in the SQL statement, such as: client access mode (for example, the client is accessed through VPN, direct connection, etc.), client access IP (client IP address that initiates the SQL request), database user (database user name that initiates the request), database operation type (for example: INSERT, DELETE, UPDATE, SELECT, etc.), database operation object (which table, column, record, etc. is operated), operation data content (such as the specific data value or data range involved), etc. These operation attributes can describe the behavior of the SQL statement in detail and help determine whether it is a high-risk operation. After parsing out the various operation attributes of the SQL statement, the target data node is matched according to the loaded golden audit rule base. The golden audit rule base includes high-risk operation determination rules for different operation attributes. For example, some operations may stipulate that "deleting a table operation" is a high-risk operation, or "modifying user permissions" is considered a high-risk operation. The rule base may determine whether the operation is high-risk based on the client access IP (such as an IP from the outside may be high-risk) or the database user (such as the root user's operation may be considered high-risk). By comparing the various operation attributes of the SQL statement with the rules in the golden audit rule base, it is determined whether each attribute is a high-risk operation. If one or more operation attributes of the SQL statement are determined as high-risk operations by the golden audit rules (for example: deleting a database table, accessing sensitive data, etc.), the entire SQL statement is considered a high-risk operation. In this case, the entire SQL statement will be marked as a high-risk operation, triggering subsequent security review or processing procedures. If none of the operation attributes of the SQL statement are determined to be high-risk operations, the SQL statement is not considered a high-risk operation. Figure 4 As shown in the golden audit flowchart of the database, at this time, the SQL statement will continue to be passed to the database engine for normal execution. If the SQL statement is judged as a high-risk operation, the system will then decide how to respond based on the processing method in the golden audit rule base. Review processing: If the processing method in the rule base is the review type, the SQL statement will not be executed immediately. Instead, it will be temporarily cached, a record to be reviewed will be generated, and a review notification will be issued to the operation and maintenance personnel or administrator or reviewer. The reviewer logs in to the review interface through the management node to decide whether to allow the operation to be executed. Prohibition processing: If the processing method in the rule base is the prohibition type, the SQL statement will be immediately blocked from execution, and the data node will return an error message to the client, indicating that the operation is prohibited from execution due to violation of security rules.

[0044] Optionally, in this embodiment, by performing a detailed analysis of the operational attributes of each SQL statement and comparing it with the golden audit rule base, high-risk operations can be effectively identified. These high-risk operations, such as deleting data, modifying permissions, etc., may bring risks. Through interception and review, potential misoperations or malicious behaviors can be prevented. When an SQL statement is judged to be a high-risk operation, the review mechanism provides a flexible management method. Operation and maintenance personnel can decide whether to allow execution based on actual business needs, rather than simply prohibiting it, avoiding excessive restrictions that affect business operations. For non-high-risk operations, the system can directly process them through normal processes without the need for additional intervention, thereby ensuring the efficiency and performance of the system when performing normal business operations.

[0045] As an optional example, after determining whether the first SQL statement is a high-risk operation according to the financial audit rule library through the target data node, the method further includes:

[0046] When it is determined that the first SQL statement is not a high-risk operation, sending the first SQL statement to the database engine so that the database engine executes the first SQL statement;

[0047] When it is determined that the first SQL statement is a high-risk operation and the corresponding processing method is to prohibit processing, the first SQL statement is terminated and the processing result of the first SQL statement is returned to the client.

[0048] Optionally, in this embodiment, if Figure 4 In the database gold audit flow chart shown in the figure, if the SQL statement is judged not to be a high-risk operation, no blocking measures are required. At this time, the data node will forward the SQL statement to the database engine, which is responsible for executing the SQL statement. The database engine calls the corresponding computing node and data node to complete the operation according to the query type, data structure and execution plan. The database engine will perform relevant data operations such as query, update, insert or delete according to the requirements of the SQL statement, and finally return the operation results to the client. If the SQL statement is judged to be a high-risk operation through the gold audit rule library, and the processing method of the gold audit rule is "prohibited", the data node will immediately terminate the execution of the SQL statement. At this time, the SQL statement will not be sent to the database engine, nor will it enter the execution process of the database engine. When the SQL statement is identified as a high-risk operation and is prohibited, the system will generate a processing result to notify the client that the operation has been prohibited. The reason for the rejection (such as "the operation risk is too high" or "the deletion operation is prohibited") will be returned to the client together to provide transparent operation feedback.

[0049] Optionally, in this embodiment, by intercepting and prohibiting high-risk operations in real time, the system can effectively prevent database damage caused by misoperation or malicious operations, thereby enhancing the overall security of the database. By accurately judging high-risk operations, it is ensured that high-risk operations will not be performed while not interfering with normal business operations, thus maintaining the efficiency of the system. When prohibiting an operation, the reason for the prohibition is clearly explained to the client through a feedback mechanism, thereby enhancing the transparency of the operation and facilitating subsequent audit and review work.

[0050] As an optional example, reviewing the first SQL statement includes:

[0051] Cache the first SQL statement;

[0052] Generate review data for the first SQL statement;

[0053] The review data is sent to the management node, so that the reviewer uploads the review result of the first SQL statement to the management node through the management platform of the management node according to the review data, wherein the review result includes whether the execution is allowed or not.

[0054] Optionally, in this embodiment, in the distributed database system, the purpose of reviewing SQL statements of high-risk operations is to ensure that under strict security rules, certain special cases can be manually intervened to determine whether to allow execution. Figure 5 As shown in the review flow chart, once the target data node identifies the SQL statement as a high-risk operation and the processing mode of the operation is "review", the system needs to cache the SQL statement to ensure that the SQL statement will not be executed incorrectly or omitted before the review process is completed. The data node will store this high-risk SQL statement in a temporary cache and save the relevant information of its execution, including the operation type, operation object, client information, etc. The data node organizes and formats the key information of the SQL statement to generate review data. This data set usually includes the specific operation of the SQL statement, the database table involved, the target data row, the client information, and other contextual information of the SQL execution environment. The data node packages the review data and sends it to the management node. The management node displays the data through a special review platform and provides an interface for the reviewer to review the operation. After analyzing the nature, background and risk of the SQL operation based on the review data, the reviewer selects the corresponding review result. If the reviewer believes that the operation meets the business requirements and has no security risks, the reviewer can allow execution; if the reviewer believes that the operation has potential risks or does not comply with regulations, the reviewer can choose not to allow execution.

[0055] Optionally, in this embodiment, through the review process, high-risk SQL operations can be manually reviewed and intervened to avoid the system automatically executing risky operations and enhance data security. The review mechanism can allow certain high-risk operations to be executed in specific circumstances while ensuring safety to meet special business needs. The management node and review platform provide an efficient review process, allowing reviewers to quickly view and judge high-risk SQL operations, reducing the delay and complexity of manual review.

[0056] As an optional example, after reviewing the first SQL statement, the method further includes:

[0057] When the review result of the first SQL statement is that execution is allowed, a second SQL statement is obtained through the management node, wherein the second SQL statement is an SQL statement uploaded to the management node by the reviewer through the management platform;

[0058] The second SQL statement is matched with the first SQL statement, and when the second SQL statement matches the first SQL statement, the first SQL statement is sent to the database engine, so that the database engine executes the first SQL statement.

[0059] Optionally, in this embodiment, if Figure 5 As shown in the review flow chart, when the reviewer believes that the SQL statement has security risks or violates the rules, the system will generate a record for traceability, and notify the data node through the management node to delete the cache of the SQL statement to prevent subsequent execution. If the reviewer determines that the SQL statement operation is safe and allows execution, the reviewer needs to enter the complete SQL statement again, and after confirming that the SQL statement is consistent with the intercepted SQL statement, send a notification to the data node to instruct the SQL statement that has passed the review to be restored from the cache and handed over to the database engine for execution. A record is generated for each review, approval, or rejection of the operation, and the relevant nodes are notified in a timely manner to ensure the transparency and traceability of the operation, which is helpful for future audits and problem tracking.

[0060] Optionally, in this embodiment, a manual review mechanism is used to strictly check potential high-risk SQL statement operations to ensure that SQL statements that do not comply with security regulations are not executed. The intercepted SQL is temporarily stored through a cache mechanism, and after the review is completed, it is decided whether to restore and execute, thereby avoiding the execution risk of non-compliant operations.

[0061] As an optional example, after matching the second SQL statement with the first SQL statement, the method further includes:

[0062] When the second SQL statement and the first SQL statement do not match each other, a prompt message is generated and displayed on the management platform, so that the reviewer can upload the SQL statement to the management node again through the management platform, wherein the prompt message reminds the reviewer that the second SQL statement and the first SQL statement do not match each other.

[0063] Optionally, in this embodiment, if Figure 5 As shown in the review flow chart, after the reviewer enters the second SQL statement, the system will match the second SQL statement with the first SQL statement that was initially intercepted. If the second SQL statement is inconsistent with the first SQL statement, the system will generate a prompt message and display the message on the management platform. The reviewer can upload the correct SQL statement again on the management platform. The uploaded new SQL statement will be re-matched until the match is consistent, ensuring that the reviewer makes adjustments according to the prompts and uploads accurate SQL statements to ensure that only legal and correct SQL statement operations are executed. Finally, the system will send the SQL statement to the data node for execution after verification. By matching the second SQL statement with the first SQL statement, omissions or errors in the operation are avoided, ensuring that the executed SQL statement meets the initial review standards. By generating clear prompt messages and displaying them on the management platform, it is ensured that the reviewer can promptly discover and correct inconsistent SQL statements, thereby improving the transparency of the entire operation. It prevents the reviewer from mistakenly entering or tampering with SQL during the review process, ensuring that the SQL executed by the database meets the specifications and security requirements.

[0064] As an optional example, after obtaining the golden audit rule base through the management node of the database, the above method further includes:

[0065] When it is detected that the administrator has modified the financial review rule base through the management platform of the management node, the modified financial review rule base is obtained through the management node and loaded into all data nodes of the database in real time.

[0066] Optionally, in this embodiment, when the administrator modifies the golden audit rule base through the management platform of the management node, the system needs to detect this change in real time, and the management node will monitor and capture any changes to the golden audit rule base, whether it is the addition, deletion or modification of rules. Once it is detected that the administrator has modified the golden audit rule base, the management node will promptly obtain the updated rule base to ensure that it is consistent with the security policy of the current database operation. The management node loads the modified golden audit rule base to all data nodes of the database in real time, and through the distributed database architecture, ensures that all data nodes can immediately obtain the updated rules and perform operation interception and auditing according to these rules. By synchronizing the golden audit rules in real time, it is ensured that the entire distributed database system can maintain consistency, and all data nodes can determine whether the operation is a high-risk operation according to the latest security rules when processing SQL, and further control according to the configured processing method.

[0067] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0068] According to another aspect of the embodiment of the present application, a database audit device is also provided. Figure 6 As shown, including:

[0069] The first acquisition module 602 is used to acquire the financial review rule base through the management node of the database, and load the financial review rule base to all data nodes of the database in real time;

[0070] A sending module 604 is configured to receive a first SQL statement sent from a client through a computing node of the database, and send the first SQL statement to a target data node of the database, wherein the target data node is at least one data node of the database;

[0071] A review module 606 is used to determine whether the first SQL statement is a high-risk operation according to the financial review rule base through the target data node, and if it is determined that the first SQL statement is a high-risk operation and the corresponding processing method is review processing, review the first SQL statement;

[0072] The processing module 608 is used to terminate the first SQL statement if the review result of the first SQL statement is that the execution is not allowed, and return the processing result of the first SQL statement to the client.

[0073] It should be noted that the first acquisition module 602 in this embodiment can be used to execute step S102 in the embodiment of the present application, the sending module 604 in this embodiment can be used to execute step S104 in the embodiment of the present application, the review module 606 in this embodiment can be used to execute step S106 in the embodiment of the present application, and the processing module 608 in this embodiment can be used to execute step S108 in the embodiment of the present application.

[0074] As an optional example, the golden audit rule base includes a rule and a processing method for at least one operation attribute of an SQL statement, and the review module includes:

[0075] A parsing unit, used to parse the first SQL statement to obtain each operation attribute of the first SQL statement;

[0076] A first determination unit, used to determine whether each operation attribute is a high-risk operation according to a financial audit rule base;

[0077] A second determining unit is used to determine that the first SQL statement is a high-risk operation when it is determined that there is a high-risk operation in all operation attributes;

[0078] A third determining unit is used to determine that the first SQL statement is not a high-risk operation when it is determined that there is no high-risk operation in all operation attributes;

[0079] The fourth determination unit is used to determine a processing method for the first SQL statement according to the financial audit rule base when determining that the first SQL statement is a high-risk operation, wherein the processing method includes review processing and prohibition processing.

[0080] As an optional example, the review module also includes:

[0081] A first processing unit is configured to, after determining whether the first SQL statement is a high-risk operation according to a financial audit rule base through a target data node, send the first SQL statement to a database engine if it is determined that the first SQL statement is not a high-risk operation, so that the database engine executes the first SQL statement;

[0082] The second processing unit is used to terminate the first SQL statement and return the processing result of the first SQL statement to the client when it is determined that the first SQL statement is a high-risk operation and the corresponding processing method is to prohibit processing.

[0083] As an optional example, the review module includes:

[0084] A cache unit, used for caching the first SQL statement;

[0085] A generating unit, used for generating review data of the first SQL statement;

[0086] The sending unit is used to send the review data to the management node, so that the reviewer can upload the review result of the first SQL statement to the management node through the management platform of the management node according to the review data, wherein the review result includes allowing execution or not allowing execution.

[0087] As an optional example, the above device further includes:

[0088] A second acquisition module is used to, after reviewing the first SQL statement, if the review result of the first SQL statement is that execution is allowed, obtain a second SQL statement through the management node, wherein the second SQL statement is an SQL statement uploaded to the management node by the reviewer through the management platform;

[0089] The matching module is used to match the second SQL statement with the first SQL statement, and when the second SQL statement matches the first SQL statement, send the first SQL statement to the database engine so that the database engine executes the first SQL statement.

[0090] As an optional example, the above device further includes:

[0091] The prompt module is used to generate a prompt message and display it on the management platform after matching the second SQL statement with the first SQL statement, if the second SQL statement and the first SQL statement do not match each other, so that the reviewer can upload the SQL statement to the management node again through the management platform, wherein the prompt message is to remind the reviewer that the second SQL statement and the first SQL statement do not match each other.

[0092] As an optional example, the above device further includes:

[0093] The modification module is used to obtain the golden review rule base through the management node of the database. When it is detected that the administrator has modified the golden review rule base through the management platform of the management node, the modified golden review rule base is obtained through the management node, and the modified golden review rule base is loaded into all data nodes of the database in real time.

[0094] For other examples of this embodiment, please refer to the above examples and will not be repeated here.

[0095] Figure 7 is a schematic diagram of an optional electronic device according to an embodiment of the present application, such as Figure 7 As shown, it includes a processor 702, a communication interface 704, a memory 706 and a communication bus 708, wherein the processor 702, the communication interface 704 and the memory 706 communicate with each other through the communication bus 708, wherein,

[0096] Memory 706, used to store computer programs;

[0097] The processor 702 is used to implement the following steps when executing the computer program stored in the memory 706:

[0098] Obtain the Golden Review rule base through the management node of the database, and load the Golden Review rule base to all data nodes of the database in real time;

[0099] Receiving, by a computing node of the database, a first SQL statement sent from a client, and sending the first SQL statement to a target data node of the database, wherein the target data node is at least one data node of the database;

[0100] Determine whether the first SQL statement is a high-risk operation according to the financial review rule base through the target data node, and if it is determined that the first SQL statement is a high-risk operation and the corresponding processing method is review processing, review the first SQL statement;

[0101] If the review result of the first SQL statement is that execution is not allowed, the first SQL statement is terminated, and the processing result of the first SQL statement is returned to the client.

[0102] Optionally, in this embodiment, the communication bus may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The communication bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 The communication interface is used for communication between the above electronic device and other devices.

[0103] The memory may include RAM, or may include non-volatile memory, such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0104] As an example, the memory 706 may include, but is not limited to, the first acquisition module 602, the sending module 604, the review module 606, and the processing module 608 in the database audit device. In addition, other module units in the database audit device may also be included but are not limited to, which will not be repeated in this example.

[0105] The above-mentioned processor can be a general-purpose processor, which can include but not be limited to: CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be DSP (Digital Signal Processing), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0106] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, and this embodiment will not be described in detail here.

[0107] It can be understood by those skilled in the art that Figure 7 The structure shown is for illustration only. The device for implementing the above-mentioned database audit method may be a terminal device, which may be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile Internet device (Mobile Internet Devices, MID), a PAD, and other terminal devices. Figure 7 The structure of the electronic device is not limited. For example, the electronic device may also include Figure 7 More or fewer components (such as network interfaces, display devices, etc.) shown in, or having Figure 7 Different configurations shown.

[0108] A person of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, which can include: a flash drive, ROM, RAM, a magnetic disk or an optical disk, etc.

[0109] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program executes the steps in the above-mentioned database audit method when executed by a processor.

[0110] Optionally, in this embodiment, a person of ordinary skill in the art may understand that all or part of the steps in the various methods of the above embodiments may be completed by instructing hardware related to the terminal device through a program, and the program may be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc.

[0111] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0112] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.

[0113] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0114] In the several embodiments provided in the present application, it should be understood that the disclosed client can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0115] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0116] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0117] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A database audit method, characterized in that: include: Obtaining a financial review rule base through a management node of a database, and loading the financial review rule base into all data nodes of the database in real time; Receiving, by a computing node of the database, a first SQL statement sent from a client, and sending the first SQL statement to a target data node of the database, wherein the target data node is at least one data node of the database; Determine, by the target data node, whether the first SQL statement is a high-risk operation according to the financial review rule base, and if it is determined that the first SQL statement is a high-risk operation and the corresponding processing method is review processing, review the first SQL statement; When the review result of the first SQL statement is that execution is not allowed, the first SQL statement is terminated, and the processing result of the first SQL statement is returned to the client.

2. The method according to claim 1, characterized in that The golden audit rule base includes a rule and a processing method for at least one operation attribute of an SQL statement, and determining whether the first SQL statement is a high-risk operation according to the golden audit rule base through the target data node includes: Parsing the first SQL statement to obtain each operation attribute of the first SQL statement; Determine whether each of the operation attributes is a high-risk operation according to the financial audit rule base; In the case where it is determined that there is a high-risk operation in all the operation attributes, determining that the first SQL statement is a high-risk operation; In the case where it is determined that there is no high-risk operation in all the operation attributes, determining that the first SQL statement is not a high-risk operation; When it is determined that the first SQL statement is a high-risk operation, a processing method for the first SQL statement is determined according to the financial audit rule base, wherein the processing method includes review processing and prohibition processing.

3. The method according to claim 1, characterized in that After determining, through the target data node, whether the first SQL statement is a high-risk operation according to the financial audit rule library, the method further includes: If it is determined that the first SQL statement is not a high-risk operation, sending the first SQL statement to a database engine so that the database engine executes the first SQL statement; When it is determined that the first SQL statement is a high-risk operation and the corresponding processing method is to prohibit processing, the first SQL statement is terminated and the processing result of the first SQL statement is returned to the client.

4. The method according to claim 1, characterized in that: The reviewing of the first SQL statement includes: Cache the first SQL statement; Generating review data of the first SQL statement; The review data is sent to the management node, so that the reviewer uploads the review result of the first SQL statement to the management node through the management platform of the management node according to the review data, wherein the review result includes allowing execution or not allowing execution.

5. The method according to claim 4, characterized in that After reviewing the first SQL statement, the method further includes: When the review result of the first SQL statement is that execution is allowed, obtaining a second SQL statement through the management node, wherein the second SQL statement is an SQL statement uploaded to the management node by the reviewer through the management platform; The second SQL statement is matched with the first SQL statement, and when the second SQL statement matches the first SQL statement, the first SQL statement is sent to a database engine, so that the database engine executes the first SQL statement.

6. The method according to claim 5, characterized in that After matching the second SQL statement with the first SQL statement, the method further includes: In the event that the second SQL statement does not match the first SQL statement, a prompt message is generated and displayed on the management platform, so that the reviewer can upload the SQL statement to the management node again through the management platform, wherein the prompt message prompts the reviewer that the second SQL statement does not match the first SQL statement.

7. The method according to claim 1, characterized in that After obtaining the financial audit rule base through the management node of the database, the method further includes: When it is detected that the administrator modifies the financial review rule base through the management platform of the management node, the modified financial review rule base is obtained through the management node, and the modified financial review rule base is loaded into all data nodes of the database in real time.

8. A database audit device, characterized in that: include: A first acquisition module is used to acquire a financial review rule base through a management node of a database, and load the financial review rule base into all data nodes of the database in real time; A sending module, configured to receive a first SQL statement sent from a client through a computing node of the database, and send the first SQL statement to a target data node of the database, wherein the target data node is at least one data node of the database; A review module, configured to determine whether the first SQL statement is a high-risk operation according to the financial review rule base through the target data node, and review the first SQL statement if it is determined that the first SQL statement is a high-risk operation and the corresponding processing method is review processing; The processing module is used to terminate the first SQL statement when the review result of the first SQL statement is that the execution is not allowed, and return the processing result of the first SQL statement to the client.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is executed.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 7 through the computer program.

Images