An audit evidence chain construction and tamper-proofing verification method, device and medium

Abstract

The application discloses an audit evidence chain construction and tamper-proof verification method, equipment and medium, and relates to the technical field of compliance auditing.The method comprises the following steps: intercepting a business system write operation, extracting operation context information and compliance trace information, and assembling an audit event; inputting the audit event into a preset rule engine, and obtaining an audit decision result through multi-level rule matching and scoring; when an audit record is indicated to be generated, reading a previous hash value of a last evidence unit in an independent audit database, calculating a current hash value based on the previous hash value and audit event data content, and generating an evidence unit by associating the previous hash value, the current hash value and the audit event; and writing the evidence unit into the independent audit database through a data access interface with only insertion permission in an append-only mode, wherein the database is physically isolated from a business database.The application ensures the non-repudiation and reliable traceability of audit evidence through complete information collection, hash chain locking and independent storage.

Description

Technical Field

[0001] This invention relates to the field of compliance auditing technology, and in particular to a method, device and medium for constructing and verifying a chain of audit evidence and preventing tampering. Background Technology

[0002] In the process of enterprise digital operations, compliant retention of operational behaviors related to core business data is a key link in ensuring controllable internal risks and meeting external regulatory requirements. As business systems grow increasingly large and data flows become more complex, how to provide reliable, long-term, and interference-resistant business backtracking data for massive operational actions has become a common technical challenge faced by various large-scale business systems in their operation and maintenance management.

[0003] To address the aforementioned technical issues, current common operation logging solutions primarily rely on independent audit log modules for data capture. However, such log systems typically only record superficial attributes like the operation's time, the executing entity, and the operation type. They fail to synchronously retain crucial contextual information such as the specific state of the data before the operation, data changes after the operation, and the underlying business reasons that triggered the operation. Furthermore, to ensure the non-repudiation of retained evidence, hash verification or blockchain technologies have emerged in the industry. However, these solutions mainly focus on using hash digests or consensus mechanisms to ensure the stored records are not tampered with, but cannot address the difficulty in judgment caused by incomplete information in the records themselves. Even if the verification algorithm proves the evidence has not been tampered with, auditors still cannot determine whether the operation complies with internal compliance requirements. Furthermore, in actual review processes, since audit records and business data are usually stored independently or in combination, when it is necessary to review the compliance of a data adjustment, reviewers often need to manually verify information across data files in multiple systems. Moreover, due to limitations in retrieval accuracy, it is common to rely on human experience to assist in judgment, which makes it difficult to effectively improve the audit efficiency for large-scale operational events in the long term. Summary of the Invention

[0004] This invention provides a method, device, and medium for constructing and verifying a chain of audit evidence and preventing tampering. The technical problem it aims to solve is: how to provide an effective solution that can record the entirety of an enterprise's business operations and ensure that the retained records have reliable traceability.

[0005] In a first aspect, the present invention provides a method for constructing and tamper-proofing a chain of audit evidence, comprising: In response to intercepting a write operation initiated by a business system against target data, the operation context information corresponding to the write operation is extracted, and compliance traceability information associated with the write operation is obtained. An audit event is then assembled based on the operation context information and the compliance traceability information. The audit event is input into a preset rule engine, which matches and scores the audit event based on multi-level rules to obtain an audit decision result for the audit event. When the audit decision result indicates that an audit record is generated, the preceding hash value of the existing evidence unit at the last write position is read from the independent audit database. Based on the preceding hash value and the data content corresponding to the audit event, the current hash value of the current evidence unit is calculated by a preset hash algorithm. The preceding hash value and the current hash value are associated with the audit event to generate the evidence unit to be written. The evidence unit is written to the independent audit database in an append-only manner through a data access interface with only insert permissions. The independent audit database is physically isolated from the business database of the business system.

[0006] Secondly, the present invention also provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0007] Thirdly, the present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.

[0008] This invention provides a method, device, and medium for constructing and verifying a chain of audit evidence and preventing tampering. By synchronously extracting the operation context information and compliance traceability information corresponding to write operations and assembling them into a structured audit event, the record triggered by a single business operation not only covers basic metadata related to the operation but also fully incorporates compliance background information. This solves the problem that existing audit logs only record surface-level information and cannot restore the complete context of the operation, achieving a comprehensive record of business operations. Based on this, a preset rule engine is used to perform matching and scoring based on multi-level rules to generate audit decision results, thereby achieving differentiated audit judgments for different operations. For operations requiring audit records, the preceding hash value of the preceding evidence unit is obtained from an independent audit database. Based on this preceding hash value and the data content corresponding to the current audit event, the current hash value of the current evidence unit is calculated, and the preceding hash value, the current hash value, and the audit event are associated and encapsulated into an evidence unit. This chain hashing mechanism creates a tight mathematical dependency between each evidence unit. Any modification to the historical record will cause the hash chain to break, providing verifiable anti-tampering evidence for the retained records and solving the problem that logs can be synchronously tampered with without detection in existing solutions. The evidence unit is written to an independent audit database in an append-only manner through a data access interface with only insert permissions. This independent audit database is physically isolated from the business database of the business system, eliminating the possibility of records being modified or deleted afterward from both interface permission control and physical storage perspectives. Therefore, this invention forms a closed loop from the complete collection of operational information and the tamper-proof locking of the evidence chain to independent secure storage, ensuring the non-repudiation and reliable traceability of audit evidence. It provides an effective solution for enterprises to achieve comprehensive record-keeping and reliable traceability of business operations. Attached Figure Description

[0009] Figure 1 A flowchart illustrating an audit evidence chain construction and tamper-proof verification method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the overall structure of the four-layer audit architecture provided in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the process of matching and scoring audit events based on multi-level rules, as provided in an embodiment of the present invention. Figure 4 This is a flowchart illustrating step S3 according to an embodiment of the present invention; Figure 5 This is a flowchart illustrating step S4 according to an embodiment of the present invention; Figure 6 This is a schematic diagram of an audit data integrity verification process provided in an embodiment of the present invention; Figure 7 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0010] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0011] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0012] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0013] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0014] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrases "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0015] This invention provides a method for constructing and tamper-proofing a chain of audit evidence, which can be implemented based on a four-layer audit architecture. For example... Figure 2As shown, this four-layer audit architecture includes a business access layer (L1), a logic processing layer (L2), a data access layer (L3), and a data storage layer (L4). The business access layer (L1) deploys a business operation interceptor responsible for write operation interception and audit event assembly; the logic processing layer (L2) deploys a rule engine and a hash chain engine to execute audit decisions and chained locking; the data access layer (L3) deploys an audit writer to perform data persistence in an append-only manner; and the data storage layer (L4) contains physically isolated business databases and an independent audit database. This embodiment addresses the technical problems of incomplete business audit record information and weak storage security in existing systems by constructing a fully closed-loop audit evidence processing mechanism, from write operation interception and business information capture to differentiated rule determination, hash chain-based anti-tampering locking, and finally, physical isolation and independent append-only storage.

[0016] Specifically, please refer to Figure 1 The method includes the following steps: S1, in response to intercepting a write operation initiated by the business system for the target data, extract the operation context information corresponding to the write operation, obtain the compliance traceability information associated with the write operation, and assemble an audit event based on the operation context information and the compliance traceability information.

[0017] In practical implementation, at the business access layer, the audit system pre-deploys a business operation interceptor with data interception capabilities. The business operation interceptor can be embedded in the data access layer of the business system as middleware, aspects, or proxies, thereby achieving transparent capture of write operation requests without intruding on business code; this invention does not specifically limit this. When the business system initiates a write operation on target data, the business operation interceptor captures the write operation request and parses the operation context information from it. Simultaneously, to ensure the comprehensiveness of audit evidence, the system is not limited to obtaining the aforementioned basic information but further actively obtains compliance traceability information associated with the write operation through the business logic layer interface. Subsequently, the system structurally assembles the operation context information and the compliance traceability information according to a unified data model to generate standardized audit events, which serve as the data source for subsequent rule determination and hash calculation.

[0018] In some preferred embodiments, assembling the audit event based on the operation context information and the compliance traceability information includes: extracting the operator identifier, tenant identifier, operation time, operation type, operation object, list of modified fields, value before modification, and value after modification from the operation context information; extracting the modification reason, approver identifier, approval record, and summary of evidence materials from the compliance traceability information; and assembling the extracted operator identifier, tenant identifier, operation time, operation type, operation object, list of modified fields, value before modification, value after modification, modification reason, approver identifier, approval record, and summary of evidence materials according to a preset data structure to obtain the audit event.

[0019] For ease of understanding, the two core mechanism terms involved in this solution are explained here. The "rule engine" mentioned in this invention refers to the processing module that determines whether the current operation needs to generate an evidence unit based on a preset audit rule set. It supports multi-level configurations such as blacklists, whitelists, and risk levels to achieve differentiated audit strategies. The "hash chain" mentioned in this invention refers to the mechanism that links evidence units in a chain according to the order of operations using a preset hash algorithm. The current hash value of each evidence unit is calculated based on the previous hash value and the unit content. Any modification to an intermediate evidence unit will cause the hash value verification of all subsequent evidence units to fail. Both the "rule engine" and the "hash chain" use evidence units as the processing object. The specific field composition and logical grouping of evidence units are detailed below.

[0020] In specific implementation, this embodiment defines core fields of evidence units with a unified format. The purpose is to ensure that the generated audit events contain a complete operational trajectory and compliance responsibility chain, providing a standardized data foundation for subsequent hash chain locking and cross-system evidence mutual recognition. The specific implementation method is as follows: The evidence unit is divided into three logical groups based on its functional positioning: the core traceability field group, the compliance traceability field group, and the evidence storage and locking field group. The core traceability field group and the compliance traceability field group together constitute the business content part of the evidence unit, carrying the complete business and compliance information of this write operation; the evidence storage and locking field group carries the anti-tampering verification certificate. This part is generated and filled in during the subsequent hash chain locking process, and it contains two fields, namely the previous hash value and the current hash value.

[0021] When generating an audit event, the system precisely extracts eight core traceability fields from the operation context information. These include: Operator Identifier, used to uniquely identify the entity performing the write operation; Tenant Identifier, used to delineate the tenant boundaries of data ownership in a multi-tenant architecture; Operation Time, recording the precise moment the write operation occurred; Operation Type, indicating the specific action of the write operation, such as add, modify, or delete; Operation Object, specifying the data table or data resource being operated on; Modified Field List, listing the set of data columns that changed during the operation; and Pre-Modification Value and Post-Modification Value, respectively storing the specific values ​​of each changed column before and after the operation. The pairwise retention of pre-modification and post-modification values ​​allows auditors to directly obtain the precise trajectory of data changes before and after without having to backtrack to historical mirrors of the business database. Combined with the modified field list, it enables precise location of the changed data dimensions and accurate reconstruction of the physical characteristics of the data changes.

[0022] The system retrieves compliance traceability fields (compliance traceability information) from the compliance service interface linked to the business system. These fields consist of four: Reason for Modification (recording the subjective motivation of the business personnel initiating the operation); Approver Identifier (indicating the identity of the person who approved the operation for compliance); Approval Record (containing node information of the approval process, approval opinions, and time); and Evidence Material Summary (linking supporting supporting documents for this operation, such as work order screenshots or email approval records, in the form of a text summary or association identifier). These four fields collectively provide a complete business process context and basis for responsibility attribution for this operation, enabling subsequent tracing not only to identify the physical trajectory of the data change but also to clarify the business reasons and approval chain for the change.

[0023] After extracting the twelve business fields mentioned above, the system assembles them according to a preset data structure to obtain structured audit events. The preset data structure can adopt a standard data exchange format. In some implementations, JavaScript Object Notation (JSON) is used as the serialization format, clearly expressing the correspondence between field names and field values ​​in key-value pairs, facilitating parsing across different programming languages ​​and platforms. In other implementations, to further compress data volume and improve transmission and parsing efficiency, Protocol Buffers (Protobuf) can be used for binary serialization, encoding structured data into a compact byte stream using a predefined pattern. Regardless of the specific serialization method used, the goal is to convert the data structure in memory into a standardized byte sequence that can be persistently stored or transmitted over a network, ensuring semantic consistency when data flows between different processing nodes. Regarding the configuration of the rule engine, the system also supports multiple alternatives: rules can be defined using YAML or JSON configuration files for plain text-based rule version management; rules can also be integrated with configuration centers such as Nacos or Apollo for hot loading and dynamic refreshing; additionally, rules can be directly stored in a database rule table, and the currently effective rule set can be retrieved through a query interface. All of the above configuration methods can be flexibly selected according to the actual deployment environment and operational needs. Their core objective is to enable the rule engine to accurately acquire and parse multi-level audit judgment rules, providing a reliable source of rule data for subsequent matching and scoring processes.

[0024] The assembled audit event will serve as the input source data for the subsequent rule engine to perform matching and scoring, and as the baseline data content for the hash chain engine to perform digest calculations. When the business content corresponding to the audit event is subsequently sealed as an evidence unit, it will be combined with the preceding hash value and the current hash value in the evidence locking field group to form a complete evidence unit.

[0025] This embodiment establishes a standardized audit evidence data structure through detailed definition and structured encapsulation of twelve business fields, including core traceability fields and compliance traceability fields. The coordination of the pre-modification value, post-modification value, and modified field list accurately reconstructs the physical trajectory of data evolution; the simultaneous retention of modification reasons, approver identifiers, approval records, and evidence material summaries completes the entire responsibility chain from operation execution to compliance approval. The standardized data structure design provides a data format foundation for the integration and mutual recognition of audit data across systems and platforms, and also ensures that the objects locked by the subsequent hash chain have complete and business-meaning traceability content. The clear division between the business content part of the evidence unit and the evidence storage and locking part provides a clearly structured processing boundary for subsequent hash calculation and anti-tampering verification.

[0026] To visually demonstrate the technical advantages of this solution compared to traditional audit logs, Table 1 compares them from two dimensions: operational information integrity and tamper detection. Table 1. Functional Comparison of This Solution with Traditional Audit Logs As shown in the table above, traditional audit logs can only record two basic types of information: the operator and the time of the operation. They cannot reconstruct the complete trajectory of data changes before and after the changes, and they also lack compliance background information such as the reason for the modification, the approver, and supporting evidence. Furthermore, the logs themselves have a fatal flaw: they cannot be detected by synchronous tampering. This solution fully incorporates the physical trajectory of data changes and the compliance responsibility chain through structured evidence units, and achieves the detectability of any tampering behavior through a hash chain locking mechanism. It achieves a fundamental improvement in both the comprehensiveness of information collection and the reliability of the retained records.

[0027] S2, input the audit event into the preset rule engine, and use the preset rule engine to match and score the audit event based on multi-level rules to obtain the audit decision result for the audit event.

[0028] In specific implementation, at the logic processing layer, the system inputs the audit event into a preset rule engine. The preset rule engine is a software module internally constructed with a multi-level rule-based decision logic network. The multi-level rules refer to several sets of rules organized according to different risk levels and matching priorities, such as a rapid decision rule group and a quantitative scoring rule group. Further, the system uses the preset rule engine to perform step-by-step pattern comparison and scoring of the audit event, outputting an audit decision result for this write operation to indicate what audit processing strategy should be adopted for this write operation, such as mandatory audit, sampling audit, or no audit.

[0029] like Figure 3 As shown, in some preferred embodiments, the audit event is input into a preset rule engine, which matches and scores the audit event based on multi-level rules to obtain an audit decision result for the audit event. This includes: inputting the audit event sequentially into a blacklist matching rule and a whitelist matching rule; if the blacklist matching rule matches successfully, the audit decision result is determined to be mandatory audit; if the whitelist matching rule matches successfully, the audit decision result is determined to be no audit; if neither the blacklist nor the whitelist matching rule matches successfully, the audit event is input into a risk level scoring rule for scoring to obtain a risk score; and the audit decision result is determined based on the risk score.

[0030] In practice, this embodiment introduces a three-tiered progressive matching architecture consisting of blacklist matching rules, whitelist matching rules, and risk level scoring rules to achieve flexible and controllable audit strategies. The specific implementation method is as follows: When an audit event is input into the preset rule engine, the system first executes the blacklist matching rules. These blacklist matching rules contain a set of pre-configured high-risk operation characteristic conditions. These conditions are defined through logical combinations of fields such as operation type, operation object identifier, and modified field list, describing operation patterns that, once they occur, may cause serious damage to the company's core assets, such as deleting a core configuration table or illegally modifying administrator permission fields. The system compares the values ​​of the corresponding fields in the audit event with the characteristic conditions in the blacklist matching rules. If a match is successful, meaning the audit event hits the blacklist, the system directly determines the audit decision result as mandatory audit, skipping the subsequent whitelist matching and risk scoring processes, and outputs the mandatory audit decision result.

[0031] If an audit event does not match the blacklist, the system immediately executes the whitelist matching rules. These whitelist matching rules include a set of pre-configured harmless operation characteristics, such as internal system status queries, periodic health check heartbeat operations, and routine data backup read operations. The system compares the audit event with the characteristics in the whitelist matching rules. If a match is successful, meaning the audit event matches the whitelist, the system directly determines the audit decision as "not to audit" and terminates the current audit process, without performing any subsequent audit record generation operations. The whitelist mechanism provides a fast-track for determining harmless routine operations, effectively reducing system resource overhead.

[0032] If an audit event falls outside both the blacklist and whitelist, it indicates that the current operation is in a gray-scale risk zone and requires more refined quantitative assessment. In this case, the system inputs the audit event into a risk level scoring rule for evaluation. This rule extracts multiple risk factors from the audit event based on a pre-defined weighted evaluation model. These risk factors may include the sensitivity level of the data assets involved, whether the operation occurred during a non-business period, the size of the data involved, and the frequency of recent changes to this type of operation. The system weights and sums each risk factor according to preset weights to obtain a numerical risk score. Based on this risk score, the system determines the final audit decision according to a pre-defined risk level judgment logic. For example, a risk score above a certain high threshold may be considered a mandatory audit, a score between the high and low thresholds may be considered a sampling audit, and a score below the low threshold may be considered a no-audit.

[0033] This embodiment achieves hierarchical control and flexible allocation of audit decisions through a three-tiered progressive matching logic of blacklist matching rules, whitelist matching rules, and risk level scoring rules. High-risk operations are directly captured by the blacklist and immediately included in mandatory audits, ensuring that no security threats are missed. Harmless operations are quickly identified and allowed by the whitelist, avoiding the consumption of computing and storage resources for low-value audit events. For operations with unclear risk characteristics, a multi-dimensional weighted risk model is used for quantitative scoring, allowing audit resources to be allocated differentiated according to the risk score. This enables limited system resources to be precisely focused on truly potentially threatening business operations, improving the overall operating efficiency and threat detection capability of the audit system in high-concurrency environments.

[0034] In some preferred embodiments, determining the audit decision result based on the risk score includes: comparing the risk score with a preset threshold range; if the risk score is greater than the upper limit of the preset threshold range, the audit decision result is determined to be a mandatory audit; if the risk score is within the preset threshold range, the audit decision result is determined to be a sampling audit; if the risk score is less than the lower limit of the preset threshold range, the audit decision result is determined to be no audit.

[0035] In other embodiments, step S2 can also be implemented by: inputting the audit event into a frequency detection rule to determine the trigger frequency of the write operation within a preset time window; if the trigger frequency is greater than a preset high-frequency threshold, then the audit decision result is determined to be mandatory audit; if the trigger frequency is between the preset high-frequency threshold and the preset low-frequency threshold, then the audit decision result is determined to be sampling audit; if the trigger frequency is less than the preset low-frequency threshold, then the audit decision result is determined to be no audit.

[0036] In practice, this embodiment provides two parallel optional implementation methods to specifically define how to determine the final audit decision based on risk scoring. In actual deployment, enterprises can choose to apply one of the methods according to their own business compliance requirements, or combine the two methods to achieve a more rigorous audit decision strategy.

[0037] In the first optional implementation, the system employs a threshold range comparison method. The system compares the risk score with a preset threshold range. This preset threshold range has an upper and lower limit, which can be flexibly configured according to different compliance strategies. If the risk score is greater than the upper limit of the preset threshold range, it indicates that the potential risk of the current operation has exceeded the acceptable safety threshold, and the system determines its audit decision as mandatory auditing to ensure full traceability of high-risk operations. Further, if the risk score is within the preset threshold range, i.e., the risk score is less than or equal to the upper limit and greater than or equal to the lower limit, the system determines its audit decision as sampling auditing. Sampling auditing means that the system only generates audit records for a subset of operations that meet this condition, achieving a balance between audit completeness and system performance. If the risk score is less than the lower limit of the preset threshold range, it indicates that the risk of the current operation is extremely low, and the system determines its audit decision as no auditing.

[0038] Furthermore, in the second optional implementation, the system employs a frequency detection mechanism as a supplementary dimension for risk scoring to capture abnormal behavior patterns spanning time windows. Such abnormal behavior may have a low risk score on a single occurrence, but its high frequency makes it threatening overall. Based on the operation time information in the audit event, the system calculates the trigger frequency of the operation type or operator within a preset time window. The preset time window can be a sliding time window, such as the number of times the operation was executed in the past n seconds. If the calculated trigger frequency is greater than a preset high-frequency threshold, it indicates a possible automated script attack, batch data tampering, or abnormally high-frequency operation. The system automatically determines the audit decision as mandatory audit, regardless of the single-occurrence risk score of the operation. If the trigger frequency is between the preset high-frequency threshold and the preset low-frequency threshold (i.e., less than or equal to the preset high-frequency threshold and greater than or equal to the preset low-frequency threshold), the system determines the audit decision as sampling audit. If the trigger frequency is less than the preset low-frequency threshold, it indicates that the operation frequency is at a normal level, and the system determines the audit decision as no audit.

[0039] In scenarios where the two methods are combined, the system can perform threshold comparison and frequency detection separately. As long as either decision path leads to the conclusion of mandatory audit, the final audit decision result is determined to be mandatory audit, thus forming a double-insurance audit decision mechanism.

[0040] This embodiment further enhances the situational awareness and adaptive decision-making capabilities of the rule engine by implementing refined threshold range classification and the parallel operation of a frequency anomaly detection mechanism. Threshold range comparison enables precise hierarchical control of the risk level of a single operation; the frequency detection mechanism can keenly capture abnormal high-frequency behavior patterns spanning time windows, effectively preventing threats that are difficult to identify through traditional single-operation scoring, such as malicious automated attacks and batch misoperations. These two mechanisms complement each other, freeing audit decisions from being limited to static, single-operation-level rules, and maintaining efficient utilization of system resources while ensuring the integrity of audit coverage.

[0041] S3, when the audit decision result indicates the generation of an audit record, read the preceding hash value of the existing evidence unit at the last write position from the independent audit database, calculate the current hash value of the current evidence unit based on the preceding hash value and the data content corresponding to the audit event using a preset hash algorithm, associate the preceding hash value and the current hash value with the audit event, and generate the evidence unit to be written.

[0042] In practice, when the audit decision indicates the need to generate an audit record (e.g., a mandatory audit or a sampling audit), the system triggers a hash chain locking process. The system accesses an independent audit database in the data storage layer, reads an existing evidence unit at its last written position, and extracts its preceding hash value. This preceding hash value is a fixed-length digest obtained by hashing all or part of the existing evidence unit, used to logically chain the existing evidence unit with the new evidence unit to be generated. Subsequently, the system extracts the data content corresponding to the audit event, combines this data content with the preceding hash value according to preset concatenation rules, performs digest calculation using a preset hash algorithm, obtains the current hash value of the current evidence unit, and encapsulates the audit event, the preceding hash value, and the current hash value together to generate the evidence unit to be written. In this process, the current hash value mathematically depends on the preceding hash value, thus forming a tight chain dependency between adjacent evidence units. When the audit decision result indicates that no audit record needs to be generated, for example, if the audit decision result is no audit, the system will terminate the current audit process and will not perform hash calculation and evidence unit writing operations to avoid unnecessary computational overhead and storage space occupation.

[0043] In some preferred embodiments, the step of calculating the current hash value of the current evidence unit based on the preceding hash value and the data content corresponding to the audit event using a preset hash algorithm includes: extracting the data content corresponding to the audit event; concatenating the preceding hash value with the data content to obtain a string to be hashed; and performing a hash calculation on the string to be hashed using the preset hash algorithm to obtain the current hash value.

[0044] See Figure 4 In specific implementation, the purpose of this embodiment is to achieve tamper-proof chain locking between evidence units through the mathematical dependency relationship of the hash chain, so that any tampering of historical evidence can be detected afterward. The specific implementation method is as follows: S31, The system determines that an audit record needs to be generated this time, and has read the preceding hash value H_prev of the preceding evidence unit from the independent audit database.

[0045] S32, the system extracts the data content D_current corresponding to the audit event, which is the byte sequence obtained after serializing fields such as operator identifier, tenant identifier, operation time, operation type, operation object, modified field list, value before modification, value after modification, modification reason, approver identifier, approval record, and evidence material summary of the audit event generated in the above embodiment. This ensures that the hash calculation covers all business semantics of the audit event, so that any change in business field can be reflected by the change in hash value.

[0046] S33, the system sequentially concatenates the read preceding hash value with the aforementioned data content to form a continuous string to be hashed, S = H_prev + D_current. The concatenation order is a predefined fixed order, such as placing the preceding hash value first and the data content last, or using other agreed-upon order. This concatenation operation, at the algorithm level, implements an irreversible binding between the state fingerprint of the preceding evidence unit and the content of the current audit event. Any single-bit modification to the preceding evidence unit or the content of the current audit event will change the composition of the string to be hashed, thus affecting the final hash calculation result.

[0047] S34, the system calls a preset hash algorithm to perform a cryptographic digest calculation on the string to be hashed, generating a fixed-length digest value, which is the current hash value H_current. The preset hash algorithm can be a secure hash algorithm with strong collision resistance, such as the 256-bit version of the Secure Hash Algorithm (SHA-256), where H_current = SHA256(S). Alternatively, in other implementations, collision-resistant hash algorithms such as SM3, SHA-512, SHA-3, or BLAKE2 can be used. The avalanche effect of this type of hash algorithm is that any difference of 1 bit in the input message will cause approximately half of the bits in the output hash value to flip, and the flip positions are unpredictable. The current hash value is uniquely determined by the previous hash value and the current data content, and is extremely sensitive to input changes. This mechanism ensures that if the content of a certain evidence unit or any link in the preceding chain is tampered with, the current hash value of that unit and all subsequent evidence units will fail to pass the recalculation verification, thus achieving absolute sensitivity to tampering.

[0048] This embodiment constructs a strict mathematical chain dependency between adjacent evidence units by concatenating the preceding hash value with the data content of the current audit event and then performing a hash calculation. Since the calculation of the current hash value strongly depends on the preceding hash value, any single-point tampering with a preceding evidence unit will inevitably lead to continuous variation of the hash values ​​in all subsequent stages. Furthermore, this variation is unpredictable and uncontrollable due to the avalanche effect of the hash algorithm, making it impossible for attackers to modify any single evidence unit while maintaining complete consistency throughout the hash chain. This chain structure provides extremely strong post-audit detectability for the integrity of audit data, and the verification process can be completed independently using only the hash values ​​already stored within the database, without requiring external trust infrastructure or timestamp services, thus reducing system complexity while ensuring security.

[0049] In some preferred embodiments, S35, associating the preceding hash value and the current hash value with the audit event to generate an evidence unit to be written includes: using the audit event as the business content part of the evidence unit, using the preceding hash value and the current hash value as the evidence storage locking part of the evidence unit; and combining the business content part and the evidence storage locking part according to a preset evidence unit structure to obtain the evidence unit to be written.

[0050] In practical implementation, this embodiment provides a logically indivisible evidence unit storage structure to ensure that business content and tamper-proof fingerprints coexist in one entity. The specific implementation method is as follows: Once the current hash value is calculated, the system begins constructing a structurally complete evidence unit. The system treats the entire audit event as the business content portion of the evidence unit. This portion carries the serialized data of all core traceability fields and compliance traceability fields defined in the above embodiments, constituting the substantive business semantics of the audit record. The system combines the preceding hash value and the current hash value, using both as the evidence storage and locking portion of the evidence unit. The preceding hash value logically connects the current evidence unit to the previous evidence unit, while the current hash value is used to lock the integrity of the current evidence unit's content and serves as a prerequisite for the next evidence unit. Logically, they form an unbreakable chain.

[0051] The system merges the business content portion and the evidence locking portion according to a pre-defined evidence unit data structure. This merging process can be achieved by placing the business content portion and the evidence locking portion in the same data object's sibling field group, or by using the evidence locking portion as an additional header or footer field of the business content portion, as long as they belong to the same record in physical storage. After merging, a complete evidence unit to be written is formed. This evidence unit, at the physical data level, is an indivisible whole record, containing all auditable and traceable business information, and also possessing a complete set of hash fingerprints for verifying its content integrity and chain continuity. Because the business content and the tamper-proof fingerprint are within the same data unit, any modification to the original business content will immediately cause a mismatch in the current hash value in the evidence locking portion. Consistency verification can be completed within a single record without additional external data queries, significantly improving the response speed and location accuracy of the verification operation.

[0052] This embodiment integrates and encapsulates audit events as business content and preceding and current hash values ​​as evidence locking components, ensuring the integrity of evidence units at the physical storage level and a tight binding of anti-tampering logic. The isomorphic design of business content and hash fingerprints means that any tampering with the business content will directly lead to contradictions in the hash values ​​within that unit. Tampering not only disrupts the global consistency of the chain but is also immediately exposed during single-record verification. This structure allows for independent verification of each evidence unit without cross-record join queries during integrity checks, providing a structural foundation for rapid integrity scanning of large-scale audit data.

[0053] S4, the evidence unit is written to the independent audit database in an append-only manner through a data access interface with only insert permissions. The independent audit database is physically isolated from the business database of the business system.

[0054] In practical implementation, at the data access layer, the system writes the evidence units into the independent audit database in an append-only manner through a data access interface with only data insertion operation permissions. At the physical deployment level, the independent audit database is independent of the business database of the business system, and the two are physically isolated in terms of storage media or database instances. Regarding anti-tampering constraints, the system supports several alternative implementation methods: triggers can be configured at the underlying level of the independent audit database to prohibit modification or deletion operations on existing audit records at the database level; the same effect can be achieved through database user permission control, i.e., granting INSERT permissions only to the audit system database account and not UPDATE and DELETE permissions; alternatively, only insert methods can be provided in the application-layer data access objects without exposing modification and deletion interfaces, ensuring that all database operations are append-only writes at the code level. These alternative solutions can be deployed individually or in combination, all achieving the goal of preventing audit records from being modified or deleted afterward. Thus, the system constructs an anti-tampering security defense line from three dimensions: application-layer data access interface permission control, database-layer triggers, and physical storage isolation.

[0055] This embodiment achieves a complete closed loop from intercepting business write operations to writing to the physically isolated independent audit database through a four-layer architecture of business access layer, logic processing layer, data access layer, and data storage layer. This ensures that the entire chain of audit evidence generation, processing, and storage is under controlled security. The system only triggers hash calculation and evidence unit writing when the audit decision indicates that an audit record needs to be generated, effectively avoiding the waste of computing resources and storage space expansion caused by full audit. In terms of anti-tampering design, a defense-in-depth system is built through multiple restrictions, including physical isolation between the independent audit database and the business database, opening only INSERT permissions on the application layer data access interface, and prohibiting modification and deletion by database layer triggers. The database layer triggers can be replaced with INSERT-only permission configuration of the database account, and the insertion permission of the application layer interface can also be implemented by exposing only the insertion method on the data access object. The above methods can be flexibly selected according to the actual deployment environment to ensure that once audit evidence is written, it cannot be tampered with or destroyed by any single-layer operation, achieving high reliability and non-repudiation of evidence records. The evidence units are linked by a chain of dependencies between their preceding and current hash values. This ensures that any modification to any evidence unit will result in inconsistent hash values ​​for all subsequent units, providing a solid mathematical foundation for post-event integrity verification and significantly reducing the risk of unauthorized tampering of audit data. Furthermore, this hash chain can be deployed using only a general hash algorithm and a standard database, without requiring distributed nodes or consensus mechanisms, making it particularly suitable for the lightweight deployment needs of enterprise-level SaaS scenarios.

[0056] like Figure 5As shown, in some preferred embodiments, the evidence units are written to the independent audit database in an append-only manner through a data access interface with only insert permissions, including: S41, sending the evidence units to a message queue; S42, achieving asynchronous decoupling between the write operation and the write operation of the evidence units through the message queue; S43, reading the evidence units in batches from the message queue, and writing the read evidence units in batches to the independent audit database through the data access interface.

[0057] In practice, this embodiment provides engineering specifications for the step of writing the evidence unit into an independent audit database, aiming to eliminate the performance interference of the audit data persistence process on the main business system through asynchronous decoupling and batch processing. The specific implementation method is as follows.

[0058] Once a piece of evidence to be written is generated, the system first submits it to a message queue. This message queue can be a high-performance distributed message middleware, such as the distributed publish-subscribe messaging system (Apache Kafka). Other implementations may use message middleware such as RabbitMQ, RocketMQ, or local memory queues. This message queue acts as a buffer for asynchronous decoupling and peak shaving. After the write operation thread of the business system completes the construction of the evidence unit and successfully submits it to the message queue, it can return a successful business processing result to the caller without waiting for disk write confirmation from the independent audit database. This logically isolates the business system and the audit storage system in terms of time, ensuring that audit write latency no longer directly affects the response time of business requests.

[0059] The system is configured with an independent audit data consumer. This consumer runs independently as a background service, fetching data in batches from the message queue according to a set capacity threshold. The capacity threshold can be configured based on a data volume threshold (e.g., triggering batch processing when the cumulative fetched data volume reaches 1 MB), or a record count threshold (e.g., triggering batch processing when the cumulative fetched evidence units reach 100), or both conditions can be set simultaneously, with the first condition being met. After fetching a batch of evidence units, the consumer writes these evidence units into the corresponding data table of the independent audit database all at once through the data access interface, which only has insert permissions. This batch writing method combines multiple network round trips and disk I / O operations into a single batch operation, effectively reducing connection establishment overhead and the frequency of I / O scheduling, significantly improving the persistence throughput efficiency of the independent audit database. After writing is complete, the consumer submits a consumption confirmation to the message queue, ensuring that each evidence unit is successfully written at least once. The aforementioned data access interface only allows insert operations at the application layer, and does not support update or delete operations, thus effectively preventing the audit data from being maliciously or accidentally modified at the code level. Independent auditing databases can utilize PostgreSQL, MySQL, TiDB, Oracle, DM Database, etc.

[0060] This embodiment utilizes an asynchronous decoupling mechanism with message queues to ensure that the persistence process of audit evidence does not block the main write operation chain of the business system, effectively avoiding business response timeouts caused by audit write delays in high-concurrency business scenarios. Based on threshold-triggered batch retrieval and batch write modes, multiple input / output operations are aggregated into batch processing, significantly optimizing the write throughput performance of the independent audit database and reducing the system overhead of disk input / output scheduling. Data access interfaces with only insert permissions further strengthen anti-tampering constraints at the application layer, achieving maximum overall system throughput and data security while ensuring no audit data loss. The replaceability of message queues and databases allows the system to flexibly adapt to different technology stack environments.

[0061] In some preferred embodiments, such as Figure 6This is a schematic diagram of the audit data integrity verification process. The method of the present invention further includes: responding to an integrity verification instruction for a target evidence unit in the independent audit database, traversing each evidence unit starting from the first evidence unit; for the currently traversed evidence unit to be verified, reading the hash value and data content stored in the evidence unit to be verified; calculating a verification hash value using the preset hash algorithm based on the hash value stored in the previous evidence unit and the data content of the evidence unit to be verified; determining whether the verification hash value is equal to the hash value stored in the evidence unit to be verified; if the verification hash value is equal to the hash value stored in the evidence unit to be verified, determining that the evidence unit to be verified has not been tampered with; if the verification hash value is not equal to the hash value stored in the evidence unit to be verified, determining that the evidence unit to be verified has been tampered with and triggering an alarm.

[0062] In practice, this embodiment provides a proactive verification method for audit data integrity that does not rely on external third-party evidence storage services and can be completed solely through the hash chain logic built within an independent audit database. The specific implementation is as follows: When maintenance personnel or automated monitoring programs initiate an integrity verification command for a target evidence unit or the entire database of records in the independent audit database, the system starts the verification process. The system begins with the first evidence unit in the independent audit database and traverses each evidence unit strictly in chronological order. For the currently accessed evidence unit to be verified, the system reads the hash value stored within that evidence unit, denoted as H. i Simultaneously, the data content stored in the data unit to be verified is read, denoted as D. i The data content D i This refers to the business content described in the above embodiments. Simultaneously, the system traces and reads the hash value stored in the previous evidence unit of the evidence unit to be verified, denoted as H. i-1 If the current data unit to be verified is the first record, its preceding hash value can be a preset initial vector or zero value, which is predefined during system initialization.

[0063] The system uses the exact same hash calculation rules as in the above embodiments when writing, to process H. i-1 With D i Perform sequential concatenation and re-execute the hash operation using the same preset hash algorithm to calculate the verification hash value H. calc Furthermore, the system compares H... calc With H i The value of H. If H calc With H i If they are equal, the verification passes, the system determines that the evidence unit to be verified has not been tampered with, and that all preceding chain data from the first record to this evidence unit is complete and error-free, allowing the system to continue traversing the next evidence unit. If Hcalc With H i If the hashes are not equal, the system determines that the evidence unit to be verified has been tampered with or is corrupted. At this point, the system immediately triggers an alarm and sends an alarm message containing the identifier or storage location of the evidence unit to the operations and maintenance personnel or monitoring center, clearly indicating the location where the hash comparison first occurred. Due to the cascading dependency of the hash chain, once a chain breaks, the hash values ​​of all subsequent evidence units will fail verification. Therefore, the system can accurately locate the starting point of tampering by identifying the first failed comparison record. Operations and maintenance personnel can use this location information to further verify the related data before and after the tampered record and, if necessary, recover the corrupted evidence unit from backups or other trusted sources.

[0064] This embodiment provides a completely autonomous, zero-trust integrity verification solution that does not rely on external centralized timestamps or third-party evidence storage services. It utilizes only the evidence storage locking fields within an independent audit database to complete accurate integrity verification of the entire chain and all records. Deployment and maintenance costs are low, and no distributed consensus mechanism is required, making it suitable for lightweight deployment within enterprises. Once a hash comparison inconsistency is detected, the system can accurately pinpoint the specific record location where the chain breaks, clearly pointing to the tampered audit evidence. This significantly improves the audit system's proactive defense capabilities and fault diagnosis efficiency, enabling maintenance personnel to quickly define the scope of damage and implement targeted recovery, maximizing the credibility and availability of audit evidence throughout its entire lifecycle.

[0065] The audit evidence chain construction and tamper-proof verification method provided by this invention can be widely applied to various business scenarios with high-reliability operational audit requirements. In the financial compliance field, it can be deployed in the core business systems of financial institutions such as banks, securities firms, and insurance companies to generate structured evidence units for key operations involving fund transactions and account changes, meeting regulatory requirements for comprehensive record-keeping and complete traceability of operational behavior. In the field of medical data security, it can generate evidence units for access to and modification of medical and health data, fully recording the data access trajectory and changes, ensuring the security and privacy compliance of medical data. In the field of government services, it can be applied to auditing operations involving citizens' personal information and internal government documents, providing verifiable operational traceability evidence for government service platforms. In the field of artificial intelligence platform auditing, it can generate evidence units for the behavior of agents in multi-agent collaborative systems, recording the decision-making chain, tool calls, and data access operations of the agents, providing a reliable data foundation for the interpretability and compliance review of AI system behavior. In the field of enterprise internal control, it can generate evidence units for internal operations of enterprise application systems such as enterprise resource planning systems and customer relationship management systems, effectively preventing internal data leakage and violations, and supporting enterprise internal audit and accountability mechanisms. The aforementioned application scenarios all benefit from the closed-loop mechanism of this invention, which encompasses complete collection of operational information, tamper-proof locking of the evidence chain, and independent secure storage, thereby achieving non-repudiation and reliable traceability of audit evidence. In terms of deployment, this invention can be used independently or integrated with existing business systems and compliance and risk control systems to form a complete audit closed loop of "operation interception → rule judgment → evidence construction → hash locking → independent evidence storage," flexibly adapting to the audit needs of enterprises of different sizes and security levels.

[0066] The following example, using order amount modification, illustrates the complete implementation process of this invention. The specific steps are as follows: Step 1: Zhang San logs into the business system, changes the amount of order NO.123 from 100 yuan to 50 yuan, fills in the reason for the change as "customer applied for discount", selects the approver Li Si, and submits the operation.

[0067] Step 2: The business operation interceptor of the L4 business access layer intercepts the UPDATE operation and automatically extracts the operation information: Operator = Zhang San, Tenant = T001, Operation Time = 2026-07-07 14:30:00, Operation Type = UPDATE, Operation Object = Order Table (record_id=123), Modified Field = [Amount], Value Before Modification = 100, Value After Modification = 50.

[0068] Step 3: The interceptor obtains compliance traceability information through the business interface: Reason for modification = "Customer applied for discount", approver = Li Si, approval record number = AP-2026-001; The interceptor assembles the above information into an audit event according to the evidence unit structure specification and sends it to the L3 logic processing layer.

[0069] Step 4: The rules engine assesses the risk level by step, from blacklist to whitelist to risk level. This operation modifies the amount; if it doesn't match either the blacklist or whitelist, the risk level score is 65 (exceeding the mandatory audit threshold of 60), and a complete evidence unit needs to be generated.

[0070] Step 5: The hash chain engine reads the hash value H_prev of the previous evidence unit from the independent audit database, concatenates the contents of fields 1-12 of the current evidence unit into EU_content, calculates H_current = SHA256(H_prev ||EU_content), and writes H_prev and H_current into fields 13 and 14 of the evidence unit to complete the chain locking.

[0071] Step 6: The audit writer writes the complete evidence unit to the audit_evidence_unit table in the independent audit database in an append-only manner.

[0072] Step 7: Operation approved, business system continues with subsequent processes. Reviewers will then use the evidence unit ID to query the complete record of the order modification and verify the integrity of the hash chain.

[0073] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0074] Please see Figure 7 , Figure 7 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 can be a terminal or a server, wherein the server can be a standalone server or a server cluster composed of multiple servers.

[0075] The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0076] The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. When the computer program 5032 is executed, it causes the processor 502 to perform an audit evidence chain construction and tamper-proof verification method.

[0077] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0078] The internal memory 504 provides an environment for the operation of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can perform an audit evidence chain construction and anti-tampering verification method.

[0079] The network interface 505 is used for network communication with other devices. Those skilled in the art will understand that the above structure is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. A specific computer device 500 may include more or fewer components than shown in the figures, or combine certain components, or have different component arrangements.

[0080] The processor 502 is used to run a computer program 5032 stored in a memory to implement the steps of an audit evidence chain construction and anti-tampering verification method provided in any of the above embodiments.

[0081] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), but it may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0082] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0083] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program. When executed by a processor, the computer program causes the processor to perform the steps of the audit evidence chain construction and tamper-proof verification method provided in any of the above embodiments.

[0084] The storage medium is a physical, non-transient storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk, or any other physical storage medium capable of storing program code. The computer-readable storage medium can be non-volatile or volatile.

[0085] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0086] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of the various units is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not performed.

[0087] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0088] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, 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. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, terminal, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0089] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0090] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, this invention is also intended to include these modifications and variations as long as they fall within the scope of the claims of this invention and their equivalents.

[0091] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for constructing and tamper-proofing a chain of audit evidence, characterized in that, include: In response to intercepting a write operation initiated by a business system against target data, the operation context information corresponding to the write operation is extracted, and compliance traceability information associated with the write operation is obtained. An audit event is then assembled based on the operation context information and the compliance traceability information. The audit event is input into a preset rule engine, which matches and scores the audit event based on multi-level rules to obtain an audit decision result for the audit event. When the audit decision result indicates that an audit record is generated, the preceding hash value of the existing evidence unit at the last write position is read from the independent audit database. Based on the preceding hash value and the data content corresponding to the audit event, the current hash value of the current evidence unit is calculated by a preset hash algorithm. The preceding hash value and the current hash value are associated with the audit event to generate the evidence unit to be written. The evidence unit is written to the independent audit database in an append-only manner through a data access interface with only insert permissions. The independent audit database is physically isolated from the business database of the business system.

2. The audit evidence chain construction and tamper-proof verification method according to claim 1, characterized in that, The audit event assembled based on the operation context information and the compliance traceability information includes: Extract the operator identifier, tenant identifier, operation time, operation type, operation object, list of modified fields, value before modification, and value after modification from the operation context information; Extract the reason for modification, approver identifier, approval record, and summary of evidence materials from the compliance traceability information; The extracted operator identifier, tenant identifier, operation time, operation type, operation object, list of modified fields, value before modification, value after modification, reason for modification, approver identifier, approval record, and summary of evidence materials are assembled according to a preset data structure to obtain the audit event.

3. The audit evidence chain construction and tamper-proof verification method according to claim 1, characterized in that, The step of inputting the audit event into a preset rule engine, and then using the preset rule engine to match and score the audit event based on multi-level rules to obtain an audit decision result for the audit event, includes: The audit events are sequentially entered into the blacklist matching rules and the whitelist matching rules; If the blacklist matching rule is successful, the audit decision result is determined to be a mandatory audit. If the whitelist matching rule is successful, the audit decision result is determined to be no audit. If neither the blacklist matching rule nor the whitelist matching rule is successfully matched, the audit event is input into the risk level scoring rule for scoring to obtain a risk score; the audit decision result is determined based on the risk score.

4. The method for constructing and tamper-proofing a chain of audit evidence according to claim 3, characterized in that, Determining the audit decision result based on the risk score includes: The risk score is compared with a preset threshold range. If the risk score is greater than the upper limit of the preset threshold range, the audit decision is determined to be a mandatory audit; if the risk score is within the preset threshold range, the audit decision is determined to be a sampling audit; if the risk score is less than the lower limit of the preset threshold range, the audit decision is determined to be no audit. or, The audit event is input into a frequency detection rule to determine the trigger frequency of the write operation within a preset time window. If the trigger frequency is greater than a preset high-frequency threshold, the audit decision result is determined to be mandatory audit. If the trigger frequency is between the preset high-frequency threshold and the preset low-frequency threshold, the audit decision result is determined to be sampling audit. If the trigger frequency is less than the preset low-frequency threshold, the audit decision result is determined to be no audit.

5. The method for constructing and tamper-proofing audit evidence chains according to claim 1, characterized in that, The step of calculating the current hash value of the current evidence unit based on the preceding hash value and the data content corresponding to the audit event using a preset hash algorithm includes: Extract the data content corresponding to the audit event; The preceding hash value is concatenated with the data content to obtain the string to be hashed; The current hash value is obtained by performing a hash calculation on the string to be hashed using the preset hash algorithm.

6. The method for constructing and tamper-proofing audit evidence chains according to claim 1, characterized in that, The step of associating the preceding hash value and the current hash value with the audit event to generate an evidence unit to be written includes: The audit event is used as the business content part of the evidence unit, and the preceding hash value and the current hash value are used as the evidence storage and locking part of the evidence unit. The business content portion and the evidence storage locking portion are combined according to a preset evidence unit structure to obtain the evidence unit to be written.

7. The method for constructing and tamper-proofing audit evidence chains according to claim 1, characterized in that, The step of writing the evidence unit into the independent audit database in an append-only manner through a data access interface with only insert permissions includes: The evidence unit is sent to a message queue to achieve asynchronous decoupling between the write operation and the write operation of the evidence unit through the message queue; The evidence units are read in batches from the message queue and written in batches to the independent audit database through the data access interface.

8. The method for constructing and tamper-proofing audit evidence chains according to claim 1, characterized in that, The method further includes: In response to the integrity verification instruction for the target evidence unit in the independent audit database, each evidence unit is traversed starting from the first evidence unit; For the currently traversed data unit to be verified, read the hash value and data content stored in the data unit to be verified; The verification hash value is calculated using the preset hash algorithm based on the hash value stored in the previous evidence unit of the evidence unit to be verified and the data content. Determine whether the verification hash value is equal to the hash value stored in the data unit to be verified; If the verification hash value is equal to the hash value stored in the data unit to be verified, it is determined that the data unit to be verified has not been tampered with; if the verification hash value is not equal to the hash value stored in the data unit to be verified, it is determined that the data unit to be verified has been tampered with and an alarm is triggered.

9. A computer device, characterized in that, The computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method as described in any one of claims 1-8.

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

Images