Log auditing method, system and device, electronic equipment and medium

Abstract

The invention discloses a log auditing method, system and device, electronic equipment and a medium, and relates to the technical field of information security, and the log auditing method comprises the following steps: performing fragmentation processing on an original log according to a preset fragmentation condition to obtain at least two target log fragments; based on the target log fragment, determining a target hash value corresponding to the target log fragment, the target hash value being a node value of a root node in a binary tree determined by the target log fragment; the target hash value is written into a block chain, the target hash value in the block chain is used for determining a log auditing result, and the technical problem that in a related log auditing scheme, logs on a centralized storage system are easily modified and deleted by internal personnel, and then the log auditing result is incredible is solved; the technical effect of improving the credibility of the audit result is achieved.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to log auditing methods, systems, devices, electronic equipment, and media. Background Art

[0002] In relevant log audit solutions, centralized storage systems are usually used to store logs. However, logs on centralized storage systems can be easily modified and deleted by internal personnel, which makes the log audit results unreliable. Summary of the Invention

[0003] This application provides a log audit method, system, device, electronic device, and medium to at least solve the problem in related technologies that logs on centralized storage systems can be easily modified and deleted by internal personnel, thereby causing log audit results to be unreliable.

[0004] This application provides a log audit method, including:

[0005] Split the original log into pieces according to the preset sharding conditions to obtain at least two target log shards;

[0006] Based on the target log shard, determine a target hash value corresponding to the target log shard, where the target hash value is a node value of a root node in a binary tree determined by the target log shard;

[0007] The target hash value is written into the blockchain, and the target hash value in the blockchain is used to determine the log audit result.

[0008] This application provides a log audit system, including a log collection layer, a processing layer, a blockchain layer, and an audit layer;

[0009] The log collection layer is used to obtain target logs;

[0010] The processing layer includes a sharding module, an encryption module, and a hash generation module. The sharding module is used to shard the target log to obtain at least two target log shards. The encryption module is used to encrypt the target log shards to obtain target keys corresponding to the target log shards. The hash generation module is used to construct a binary tree based on the target log shards and determine a target hash value.

[0011] The blockchain layer includes a smart contract module and a key management module, wherein the smart contract module is used to store the target hash value, and the key management module is used to determine the sharding of the target key and the recovery of the target key;

[0012] The audit layer includes a zero-knowledge proof module and a visualization module. The zero-knowledge proof module is used to respond to a log audit request, obtain the target hash value and the target log shard, and determine the log audit result based on the target hash value and the target log shard. The visualization module is used to generate an audit report based on the log audit result.

[0013] This application also provides a log auditing device, including:

[0014] A sharding unit, configured to shard the original log according to a preset sharding condition to obtain at least two target log shards;

[0015] A first determining unit is configured to determine, based on the target log shard, a target hash value corresponding to the target log shard, where the target hash value is a node value of a root node in a binary tree determined by the target log shard;

[0016] The second determining unit is used to write the target hash value into the blockchain, and the target hash value in the blockchain is used to determine the log audit result.

[0017] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned log audit methods when executing the computer program.

[0018] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned log audit methods are implemented.

[0019] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned log audit methods when executed by a processor.

[0020] Through this application, the original log is sharded according to preset sharding conditions to obtain at least two target log shards; based on the target log shards, a target hash value corresponding to the target log shard is determined, and the target hash value is the node value of the root node in the binary tree determined by the target log shard; the target hash value is written to the blockchain, and the target hash value in the blockchain is used to determine the log audit result. This solves the technical problem in related log audit solutions that logs on centralized storage systems are easily modified or deleted by internal personnel, thereby causing the log audit results to be unreliable, and achieves the technical effect of improving the credibility of the audit results. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0022] Figure 1 A flow chart of a log audit method provided in an embodiment of the present application;

[0023] Figure 2 A flowchart of a sharding storage and hashing chain method provided in an embodiment of the present application;

[0024] Figure 3 A schematic diagram of a key sharding method according to an embodiment of the present invention;

[0025] Figure 4 A flowchart of a key recovery method provided in an embodiment of the present application;

[0026] Figure 5 A flowchart of a zero-knowledge proof method provided in an embodiment of the present application;

[0027] Figure 6 A schematic diagram of the structure of a log audit system provided in an embodiment of the present application;

[0028] Figure 7 A schematic diagram of the structure of a log auditing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0029] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0030] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0031] In order to facilitate those skilled in the art to better understand the technical solutions described in the embodiments of the present disclosure, the technical terms in the embodiments of the present disclosure are explained as follows before introducing the embodiments of the present disclosure.

[0032] Merkle Tree: A binary tree structure whose leaf nodes store the hash values ​​of data blocks, and non-leaf nodes store the combined hash values ​​of their child nodes. The root node represents the summary of the entire data set, which can achieve efficient data integrity verification.

[0033] InterPlanetary File System (IPFS): IPFS is a peer-to-peer distributed file system protocol designed to make the web faster, more secure, and more open. It stores and retrieves data using content addressing rather than URLs. Its advantages include decentralized data storage, which improves availability and attack resistance. It also ensures data uniqueness: identical content is stored only once, saving space. It can be combined with blockchain technology to achieve trusted storage of large-scale logs or files.

[0034] Practical Byzantine Fault Tolerance (PBFT): PBFT is a classic consensus algorithm that can reach consistent decisions in the presence of malicious nodes (Byzantine faults) and is highly fault-tolerant and deterministic.

[0035] Zero-Knowledge Proof (ZKP): A ZKP is a cryptographic method that allows one party (the prover) to prove to another party (the verifier) ​​that they know a secret or satisfy a condition without revealing any actual information. Common types include succinct non-interactive zero-knowledge proofs and scalable transparent zero-knowledge proofs.

[0036] Secure Hash Algorithm 256 (SHA-256): SHA-256 is a widely used cryptographic hash function that can map data input of arbitrary length to a unique output hash value of fixed length (256 bits).

[0037] With the widespread development of cloud computing technology, more and more industries and government agencies are adopting distributed storage systems to build their business foundations. Many of these industries involve national security, citizen privacy, financial risks, and commercial secrets, requiring the recording of audit logs in accordance with relevant national laws and regulations, audit systems, or internal company confidential data audit requirements. Consequently, an increasing number of government agencies and financial institutions have higher requirements for audit log security management. As core evidence of storage system security compliance, audit logs currently face the following challenges:

[0038] Tampering risk: Traditional centralized storage (database systems, ElasticSearch, etc.) is susceptible to malicious tampering by administrators or internal personnel. Audit logs objectively lack reliable traceability and verification methods, posing security risks.

[0039] Cross-node consistency: Log files in a distributed cluster are stored in separate storage nodes, making it difficult to integrate overall log data and posing the risk of data inconsistency.

[0040] Compliance requirements and privacy protection conflict: Audit logs may contain private information such as user operation records, access records, and sensitive configurations. This information is protected by relevant national laws and regulations on privacy rights. However, according to audit requirements, this information is also important data for audit compliance, so there is a conflict between the two.

[0041] Storage cost: Audit logs usually need to record various sensitive operation information in detail, which will generate massive log files, resulting in a sharp increase in system storage pressure and low retrieval efficiency.

[0042] Judging from the current state of industry applications, traditional audit log storage systems use a centralized log storage solution. Its technical characteristics are the use of a centralized database to store logs, and the use of periodic backups and permission control to prevent tampering. However, this solution has the following drawbacks:

[0043] Node failure: A central node failure may cause the audit log system to become unavailable.

[0044] Tampering risk: Internal super administrators may bypass permission control and directly tamper with log content for illegal purposes.

[0045] Inefficient cross-node data integration: Multi-node log integration relies on scripts and cannot be traced in real time.

[0046] There are currently some preliminary attempts to use blockchain technology to improve audit log systems, but there are limitations in key management, cross-node consistency, privacy protection and compliance measures, and dynamic key updates. For example, when using static public-private key pairs, there is a risk of privacy leakage in the decrypted log file; for example, the privacy protection of the original audit log file uses static rules of smart contracts, and the key is not dynamically updated. Both of these solutions have certain limitations.

[0047] Through this application, the original log is sharded according to preset sharding conditions to obtain at least two target log shards; based on the target log shards, a target hash value corresponding to the target log shard is determined, and the target hash value is the node value of the root node in the binary tree determined by the target log shard; the target hash value is written to the blockchain, and the target hash value in the blockchain is used to determine the log audit result. This solves the technical problem in related log audit solutions that logs on centralized storage systems are easily modified or deleted by internal personnel, thereby causing the log audit results to be unreliable, and achieves the technical effect of improving the credibility of the audit results.

[0048] The log audit method provided by the embodiments of the present disclosure can be applied to related fields such as financial industry audit, Internet of Things device audit, and medical data log.

[0049] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0050] Figure 1 A flow chart of a log audit method provided by an embodiment of the present disclosure.

[0051] like Figure 1 As shown, the method comprises the following steps:

[0052] Step 101: Segment the original log according to a preset segmentation condition to obtain at least two target log segments.

[0053] In some embodiments, the unprocessed log information generated during the operation of the original log system may be in text, binary, etc., and may be a server log, transaction log, operation log, etc.

[0054] In some embodiments, sharding the original log according to preset sharding conditions may include sharding the original log according to size, time window, log type, module source, etc. Specifically, sharding by size may be splitting into a shard every time a certain number of bytes is reached, such as every 1MB or every 10MB; sharding by time window may be splitting according to a fixed time period, such as generating a log shard every day; sharding by log type may include sharding according to error logs, access logs, and audit logs; sharding by business module may be split according to different services or functional modules, such as user module logs and payment module logs; sharding may also be performed according to two or more mixed strategies among the aforementioned sharding strategies to improve flexibility and management efficiency.

[0055] In some embodiments, the target log shard refers to each independent data block after sharding.

[0056] In some embodiments, the original log is sharded according to a preset sharding condition to obtain at least two target log shards, and then the target log shards are stored in IPFS.

[0057] Step 102: Based on the target log shard, determine a target hash value corresponding to the target log shard, where the target hash value is the node value of the root node in the binary tree determined by the target log shard;

[0058] In some embodiments, a binary tree is a tree structure used to efficiently verify data integrity, where a leaf node is a hash value of a data block, and a non-leaf node is a combined hash of the hash values ​​of its child nodes.

[0059] In some embodiments, the target hash value represents the final hash value of the integrity of the entire log set, typically the root node hash value of the Merkle tree.

[0060] In some embodiments, the root node hash value is very sensitive to slight tampering of any shard. As long as the content of any shard is modified, the root node hash value will change, thereby detecting tampering. Based on this feature, auditors can quickly verify whether all shard data has been tampered with through the root node hash value, ensuring the immutability of the audit log.

[0061] Step 103: Write the target hash value into the blockchain. The target hash value in the blockchain is used to determine the log audit result.

[0062] In some embodiments, blockchain is a distributed ledger technology with characteristics such as decentralization, immutability, and traceability. It is suitable for storing key data summaries, which are specifically written into smart contracts. Smart contracts refer to automatically executed programs running on the blockchain that can be used to receive and verify target hash values.

[0063] In some embodiments, the log audit result refers to the auditor's determination of whether the log has been tampered with by comparing the target hash value recorded on the blockchain with the current log status, and outputting a conclusion of "success" or "failure".

[0064] In some embodiments, this application does not limit the blockchain platform, and a consortium chain is usually used.

[0065] Through this application, the original log is sharded according to preset sharding conditions to obtain at least two target log shards; based on the target log shards, a target hash value corresponding to the target log shard is determined, and the target hash value is the node value of the root node in the binary tree determined by the target log shard; the target hash value is written to the blockchain, and the target hash value in the blockchain is used to determine the log audit result. This solves the technical problem in related log audit solutions that logs on centralized storage systems are easily modified or deleted by internal personnel, thereby causing the log audit results to be unreliable, and achieves the technical effect of improving the credibility of the audit results.

[0066] In some embodiments, based on the target log shard, determining a target hash value corresponding to the target log shard includes:

[0067] Based on the target log shard, determine a hash value corresponding to the target log shard using a first preset algorithm;

[0068] Generate a binary tree based on the hash value corresponding to the target log shard;

[0069] Based on the node value of the root node in the binary tree, a target hash value corresponding to the target log shard is determined.

[0070] In some embodiments, the first preset algorithm refers to a cryptographic hash function used to calculate the hash value of the log shard, typically a standard algorithm such as SHA-256, Keccak (SHA3), BLAKE, etc. In this application, the first preset algorithm uses the SHA-256 algorithm.

[0071] In some embodiments, a hash value is a fixed-length string output after performing a hash operation on a piece of data and is unique.

[0072] In some embodiments, the binary tree in this scenario specifically refers to a Merkle tree, which is a tree structure composed of hash values, where the leaf nodes are the hash values ​​of the data blocks, and the non-leaf nodes are the combined hashes of the hash values ​​of their child nodes.

[0073] In some embodiments, the node value of the root node refers to the hash value of the top-level node of the Merkle tree, represents the summary information of the entire log set, and is unforgeable.

[0074] In some embodiments, the Merkle tree structure can be used to quickly determine whether a log segment has been tampered with, and the auditor can verify the integrity of a certain part of the content without downloading the entire log.

[0075] In some embodiments, before determining a target hash value corresponding to the target log shard based on the target log shard, the log audit method further includes:

[0076] Encrypting the target log shard using a second preset algorithm to obtain a target key and writing the encrypted target log shard into a distributed storage system;

[0077] In some embodiments, the second preset algorithm refers to an algorithm used to encrypt log shards, such as a symmetric encryption algorithm such as AES (Advanced Encryption Standard) and ChaCha20.

[0078] In some embodiments, the target key refers to the key used in the encryption process, typically a symmetric encryption key, which is used for subsequent decryption operations.

[0079] In some embodiments, the encrypted log data cannot be read directly and requires the use of a corresponding key to decrypt it.

[0080] In some embodiments, as Figure 2 As shown, Figure 2 A flow chart of a sharding storage and hash chain method provided in an embodiment of the present application. Logs (original logs) are collected and sharded according to rules. On the one hand, the shards are used to build a Merkle tree, calculate the root hash of the Merkle tree (target hash value), and generate metadata. The metadata includes timestamp, node identifier, operation type, etc., which are written to the blockchain through a smart contract and the storage status is returned. On the other hand, the shards are AES encrypted and stored in IPFS.

[0081] Splitting the target key using a third preset algorithm to obtain key fragments;

[0082] In some embodiments, the third preset algorithm is an algorithm for splitting a key into multiple segments, such as Shamir's Secret Sharing (SSS) algorithm.

[0083] In some embodiments, a full key is split into multiple subkeys, and only a sufficient number of subkeys can be combined to recover the original key.

[0084] The key shards are written into different blocks of the blockchain.

[0085] In some embodiments, key shards are written into different blockchain transactions or events and distributed across multiple blocks to improve security.

[0086] In some embodiments, the target log shard is encrypted using a second preset algorithm to obtain a target key and the encrypted target log shard is written into a distributed storage system, so that the log shard is encrypted before uploading. Even if an attacker obtains the encrypted content, the attacker cannot read the sensitive information, thereby preventing the log content from being leaked in the distributed storage system.

[0087] In some embodiments, the keys are stored in a decentralized manner by using algorithms such as Shamir secret sharing to avoid single points of failure or a single institution controlling all permissions, support multi-signature mechanisms, and improve the security and trust of the system.

[0088] In some embodiments, as Figure 3 As shown, Figure 3 A flow chart of a key sharding method provided in an embodiment of the present application includes generating a master key (target key), splitting it into three parts using the Shamir algorithm to obtain key shard 1, key shard 2, and key shard 3, storing all key shards in a smart contract, and highly binding them to the blockchain block (e.g., updating the key every 100 blocks) to achieve dynamic keys.

[0089] In some embodiments, after writing the target hash value into the blockchain, the log audit method further includes:

[0090] In response to receiving the log audit request, obtaining the key shard;

[0091] In some embodiments, a log audit request refers to a request initiated by an auditor to perform integrity verification or content review on logs of a certain period of time or a certain module.

[0092] In response to the number of the key shards being not less than a preset key recovery value, determining a target key based on the key shards;

[0093] In some embodiments, the key recovery preset value refers to the minimum number of key shards required to recover the original key. For example, if it is set to 3, at least 3 shards are required to recover the key.

[0094] In some embodiments, the target key is used to decrypt the corresponding log shard.

[0095] The target log segment is decrypted using the target key, and the target log segment is obtained from the distributed storage system.

[0096] In some embodiments, the target log shard refers to the log shard before encryption, which is written to the distributed storage system after encryption and needs to be decrypted using the target key.

[0097] In some embodiments, based on a log audit request, an encrypted log shard CID (such as a content identifier in IPFS) is obtained from a distributed storage system.

[0098] In some embodiments, as Figure 4 As shown, Figure 4 A flowchart of a key recovery method provided in an embodiment of the present application includes receiving an audit request, triggering key recovery, obtaining shards provided by at least two nodes, reorganizing the master key, and decrypting the log shards.

[0099] In some embodiments, after decrypting the target log shard using the target key, the log audit method further includes:

[0100] Obtain the target hash value from the blockchain;

[0101] In some embodiments, the target hash value can be obtained from the blockchain based on the blockchain address or the smart contract interface.

[0102] In some embodiments, obtaining the target hash value from the blockchain can effectively prevent the key from being forged or tampered with.

[0103] Determine a log audit result based on the target hash value and the target log shard;

[0104] If the log audit result is successful, an audit report is generated and written into the blockchain;

[0105] If the log audit result is failure, an alarm is generated to remind the target user that the target log segment has been modified.

[0106] In some embodiments, the target log shard refers to the original log segment that needs to be verified during the audit process.

[0107] In some embodiments, the audit report is a structured document used to record the audit process, time, results, etc.

[0108] In some embodiments, an alarm refers to a notification message sent to an administrator or relevant user when inconsistency in log integrity is found, indicating that tampering may have occurred. This application does not limit the form of the alarm, which can be a voice prompt, email or SMS notification.

[0109] In some embodiments, the system can automatically execute the audit process periodically or in response to a request without human intervention, supporting rapid comparison and anomaly detection of large-scale logs to improve audit efficiency.

[0110] In some embodiments, by writing the audit report into the blockchain, it can be ensured that the audit results are tamper-proof and suitable as legal evidence or compliance proof.

[0111] In some embodiments, determining a log audit result based on the target hash value and the target log shard includes:

[0112] Based on the target log shard, determining a hash path corresponding to the target log shard;

[0113] Based on the hash path and the target hash value, the log audit result is determined using a fourth preset algorithm.

[0114] In some embodiments, the hash path is used to verify whether the target log shard obtained from the blockchain belongs to a certain Merkle tree structure.

[0115] In some embodiments, the fourth preset algorithm is typically a zero-knowledge proof algorithm, which is used to verify the consistency of the hash path and the blockchain record without obtaining the content of the target log shard, thereby proving that the target log has not been modified. The zero-knowledge proof algorithm can be the Groth16 protocol.

[0116] In some embodiments, as Figure 5 As shown, Figure 5 A flow chart of a zero-knowledge proof method provided for an embodiment of the present application includes the auditor initiating a verification request (specifying a log shard), the system querying the blockchain layer to obtain a hash value and metadata, obtaining an encrypted shard from IPFS, recovering the key and decrypting the shard through the key management module, generating proof data, and judging whether the verification is successful. If successful, the verification result is returned as successful, an audit report is generated, and the audit report is recorded in the blockchain; if failed, the verification result is returned as failure, an alarm is generated, and the process is terminated.

[0117] Through this application, the original log is sharded according to preset sharding conditions to obtain at least two target log shards; based on the target log shards, a target hash value corresponding to the target log shard is determined, and the target hash value is the node value of the root node in the binary tree determined by the target log shard; the target hash value is written to the blockchain, and the target hash value in the blockchain is used to determine the log audit result. This solves the technical problem in related log audit solutions that logs on centralized storage systems are easily modified or deleted by internal personnel, thereby causing the log audit results to be unreliable, and achieves the technical effect of improving the credibility of the audit results.

[0118] Through this application, the Merkle tree verification time is greatly improved compared to traditional full data verification, achieving efficient data verification.

[0119] Through this application, zero-knowledge proof is applied to achieve a win-win situation of "privacy and compliance". Sensitive operations and highly confidential data can be directly verified through ZKP. The data content itself has no risk of exposure, thus achieving privacy protection and compliance.

[0120] Through this application, the blockchain records all metadata throughout the process, ensuring the credibility of audit data, avoiding errors in manual data integration, and ensuring consistency across nodes in the cluster.

[0121] The embodiment of the present application also provides a log audit system, which includes a log collection layer, a processing layer, a blockchain layer and an audit layer;

[0122] The log collection layer is used to obtain target logs;

[0123] The processing layer includes a sharding module, an encryption module, and a hash generation module. The sharding module is used to shard the target log to obtain at least two target log shards. The encryption module is used to encrypt the target log shards to obtain target keys corresponding to the target log shards. The hash generation module is used to construct a binary tree based on the target log shards and determine a target hash value.

[0124] The blockchain layer includes a smart contract module and a key management module, wherein the smart contract module is used to store the target hash value, and the key management module is used to determine the sharding of the target key and the recovery of the target key;

[0125] The audit layer includes a zero-knowledge proof module and a visualization module. The zero-knowledge proof module is used to respond to a log audit request, obtain the target hash value and the target log shard, and determine the log audit result based on the target hash value and the target log shard. The visualization module is used to generate an audit report based on the log audit result.

[0126] In some embodiments, as Figure 6 As shown, Figure 6A structural diagram of a log audit system provided in an embodiment of the present application, data collection layer: used to collect audit logs on demand from each node in the cluster. The log collection content can be freely customized according to different application scenarios, such as user identity, operation time, operation path, request parameters, etc. Processing layer: The sharding module is used to split the log according to the distributed cluster storage rules and assign a unique identifier to each shard. The encryption module is used to encrypt the sharded data and generate a shard key. The hash generation module is used to build a Merkle tree for each shard and calculate the overall data root hash value. Blockchain layer: The smart contract module is the core component of the blockchain, used to store hash values ​​and metadata, where the metadata includes metadata of the key shards, including the number of key shards, recovery threshold, the actual storage location of the shards in the cluster, encryption algorithm and other parameters. The metadata information about the key shards is then passed to the key management module, which receives the relevant parameters and performs actual key sharding, storage, encryption, recovery and other operations. Security is enhanced through this design, and the data is distributed and stored in different nodes to enhance risk resistance and avoid single point failures. Audit layer: After the auditor initiates an audit request, the hash path is queried through the blockchain. The zero-knowledge proof module analyzes the data and provides trusted authentication. The audit report is generated through the visualization module to complete the authenticity verification of the audit log data to ensure that the data has not been illegally tampered with.

[0127] In some embodiments, taking the audit log system of a financial cloud platform in the financial industry as an example, it includes log shard encryption: it is used to collect logs from the financial service cluster according to audit requirements and shard them. Each shard is encrypted using the AES-256 algorithm. The key is split into three parts using the Shamir algorithm, and at least two parts are required to recover the key. The key shards are stored in the blockchain smart contract and are highly bound to the block to achieve dynamic keys. Hashing on the chain: A Merkle tree is constructed from the sharded data to obtain the audit log root hash value. The root hash value, timestamp, node identifier, and other necessary data are written to the blockchain. Audit and traceability: The auditor initiates a request to verify a data shard, obtains the hash value and metadata from the blockchain, downloads the encrypted shard through IPFS, uses the blockchain key shard to recover the key, decrypts and verifies the Merkle tree, and finally generates an audit report. The entire operation process is recorded on the blockchain to ensure that the audit behavior is traceable.

[0128] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0129] The embodiment of the present application further provides a log auditing device 700, Figure 7 A structural diagram of a log auditing device provided by an embodiment of the present disclosure is shown as follows: Figure 7As shown, including:

[0130] The sharding unit 701 is configured to shard the original log according to a preset sharding condition to obtain at least two target log shards;

[0131] A first determining unit 702 is configured to determine, based on the target log shard, a target hash value corresponding to the target log shard, where the target hash value is a node value of a root node in a binary tree determined by the target log shard;

[0132] The second determining unit 703 is configured to write the target hash value into a blockchain, where the target hash value in the blockchain is used to determine a log audit result.

[0133] Furthermore, in a possible implementation of the embodiment of the present disclosure, the first determining unit 702 is configured to:

[0134] Based on the target log shard, determine a hash value corresponding to the target log shard using a first preset algorithm;

[0135] Generate a binary tree based on the hash value corresponding to the target log shard;

[0136] Based on the node value of the root node in the binary tree, a target hash value corresponding to the target log shard is determined.

[0137] Furthermore, in a possible implementation of the embodiment of the present disclosure, the log auditing device 700 further includes a writing unit, which is configured to:

[0138] Encrypting the target log shard using a second preset algorithm to obtain a target key and writing the encrypted target log shard into a distributed storage system;

[0139] Splitting the target key using a third preset algorithm to obtain key fragments;

[0140] The key shards are written into different blocks of the blockchain.

[0141] Furthermore, in a possible implementation of the embodiment of the present disclosure, the log auditing apparatus 700 further includes an acquisition unit, which is configured to:

[0142] In response to receiving the log audit request, obtaining the key shard;

[0143] In response to the number of the key shards being not less than a preset key recovery value, determining a target key based on the key shards;

[0144] The target log segment is decrypted using the target key, and the target log segment is obtained from the distributed storage system.

[0145] Furthermore, in a possible implementation of the embodiment of the present disclosure, the log auditing apparatus 700 further includes a generating unit, which is configured to:

[0146] Obtain the target hash value from the blockchain;

[0147] Determining a log audit result based on the target hash value and the target log shard;

[0148] If the log audit result is successful, an audit report is generated and written into the blockchain;

[0149] If the log audit result is failure, an alarm is generated to remind the target user that the target log segment has been modified.

[0150] Furthermore, in a possible implementation of the embodiment of the present disclosure, the generating unit is further configured to:

[0151] Based on the target log shard, determining a hash path corresponding to the target log shard;

[0152] Based on the hash path and the target hash value, the log audit result is determined using a fourth preset algorithm.

[0153] Through this application, the original log is sharded according to preset sharding conditions to obtain at least two target log shards; based on the target log shards, a target hash value corresponding to the target log shard is determined, and the target hash value is the node value of the root node in the binary tree determined by the target log shard; the target hash value is written to the blockchain, and the target hash value in the blockchain is used to determine the log audit result. This solves the technical problem in related log audit solutions that logs on centralized storage systems are easily modified or deleted by internal personnel, thereby causing the log audit results to be unreliable, and achieves the technical effect of improving the credibility of the audit results.

[0154] For the description of the features in the embodiment corresponding to the log audit device, please refer to the relevant description of the embodiment corresponding to the log audit method, and will not be repeated here.

[0155] An embodiment of 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 run the computer program to execute the steps in any of the above-mentioned log audit method embodiments.

[0156] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned log audit method embodiments when running.

[0157] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0158] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned log audit method embodiments are implemented.

[0159] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned log audit method embodiments are implemented.

[0160] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0161] The above is a detailed introduction to a log audit method, system, device, electronic device and medium provided by the present application. This article uses specific examples to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A log audit method, characterized in that: include: Split the original log into pieces according to the preset sharding conditions to obtain at least two target log shards; Based on the target log shard, determine a target hash value corresponding to the target log shard, where the target hash value is a node value of a root node in a binary tree determined by the target log shard; The target hash value is written into the blockchain, and the target hash value in the blockchain is used to determine the log audit result.

2. The log audit method according to claim 1, characterized in that: The determining, based on the target log shard, a target hash value corresponding to the target log shard comprises: Based on the target log shard, determine a hash value corresponding to the target log shard using a first preset algorithm; Generate a binary tree based on the hash value corresponding to the target log shard; Based on the node value of the root node in the binary tree, a target hash value corresponding to the target log shard is determined.

3. The log audit method according to claim 1, characterized in that: Before determining the target hash value corresponding to the target log shard based on the target log shard, the method further includes: Encrypting the target log shard using a second preset algorithm to obtain a target key and writing the encrypted target log shard into a distributed storage system; Splitting the target key using a third preset algorithm to obtain key fragments; The key shards are written into different blocks of the blockchain.

4. The log audit method according to claim 3, characterized in that: After writing the target hash value into the blockchain, the method further includes: In response to receiving the log audit request, obtaining the key shard; In response to the number of the key shards being not less than a preset key recovery value, determining a target key based on the key shards; The target log segment is decrypted using the target key, and the target log segment is obtained from the distributed storage system.

5. The log audit method according to claim 4, characterized in that: After decrypting the target log shard using the target key, the method further includes: Obtain the target hash value from the blockchain; Determine a log audit result based on the target hash value and the target log shard; If the log audit result is successful, an audit report is generated and written into the blockchain; If the log audit result is failure, an alarm is generated to remind the target user that the target log segment has been modified.

6. The log audit method according to claim 5, characterized in that: Determining the log audit result based on the target hash value and the target log shard includes: Based on the target log shard, determining a hash path corresponding to the target log shard; Based on the hash path and the target hash value, the log audit result is determined using a fourth preset algorithm.

7. A log audit system, characterized in that: The system includes a log collection layer, a processing layer, a blockchain layer, and an audit layer; The log collection layer is used to obtain target logs; The processing layer includes a sharding module, an encryption module, and a hash generation module. The sharding module is used to shard the target log to obtain at least two target log shards. The encryption module is used to encrypt the target log shards to obtain target keys corresponding to the target log shards. The hash generation module is used to construct a binary tree based on the target log shards and determine a target hash value. The blockchain layer includes a smart contract module and a key management module, wherein the smart contract module is used to store the target hash value, and the key management module is used to determine the sharding of the target key and the recovery of the target key; The audit layer includes a zero-knowledge proof module and a visualization module. The zero-knowledge proof module is used to respond to a log audit request, obtain the target hash value and the target log shard, and determine the log audit result based on the target hash value and the target log shard. The visualization module is used to generate an audit report based on the log audit result.

8. A log auditing device, characterized in that: include: A sharding unit, configured to shard the original log according to a preset sharding condition to obtain at least two target log shards; A first determining unit is configured to determine, based on the target log shard, a target hash value corresponding to the target log shard, where the target hash value is a node value of a root node in a binary tree determined by the target log shard; The second determining unit is used to write the target hash value into the blockchain, and the target hash value in the blockchain is used to determine the log audit result.

9. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the log audit method according to any one of claims 1 to 6 when executing the computer program.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the log audit method according to any one of claims 1 to 6.

Images