Log management method and device, storage medium, program product and electronic equipment
By detecting the source and integrity of log data and using smart contracts and blockchain technology for encrypted storage, the risks of log tampering and deletion in traditional log management systems are solved, and the reliability and security of log data are achieved.
Patent Information
- Application Number
- CN202411353879.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-26
- Publication Date
- 2025-01-14
- Estimated Expiration
- Not applicable · inactive patent
AI Technical Summary
Traditional log management systems have the risk of logging or deletion, and cannot guarantee the correctness and integrity of the log, affecting incident response and system security.
By receiving log data, check whether its source is a preset source and integrity, encrypting log data using smart contracts, and linking encrypted log data to a distributed ledger for storage through blockchain technology, ensuring that the data is tampered with and reliability sex.
It effectively avoids the possibility of illegal tampering with logs by administrators or high-authorized users, enhances the integrity of log data and the credibility of audits, and ensures the flexibility and sustainability of the system.
Smart Images

Figure CN119312362A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of information security technology, and in particular to a log management method, device, storage medium, program product and electronic device. Background Art
[0002] In the field of information security, log auditing is a key component in identifying and responding to network security incidents. Log auditing allows users to track the activities of critical systems, ensure the security compliance of system operations, and conduct investigations when security incidents such as system intrusions occur.
[0003] However, traditional log management systems are at risk of logs being tampered with or deleted, and cannot guarantee that the logs users obtain from the log management system are correct and complete. This may result in the inability to trace events through logs when attacked or threatened by an internal threat, which in turn affects incident response and even system security. Summary of the invention
[0004] The embodiments of this specification provide a log management method, device, storage medium and electronic device, which can solve the above problems. The technical solution is as follows:
[0005] In a first aspect, an embodiment of the present specification provides a log management method, the method comprising:
[0006] Receiving log data, and detecting whether a source of the log data is a preset source and whether the log data is complete;
[0007] When it is determined that the source of the log data is the preset source and the log data is complete, encrypting the log data through a smart contract to obtain encrypted log data;
[0008] The encrypted log data is linked to a distributed ledger for storage through blockchain technology.
[0009] In a second aspect, an embodiment of the present specification provides a log management device, the device comprising:
[0010] A first management module, used for receiving log data, detecting whether the source of the log data is a preset source and whether the log data is complete;
[0011] A second management module, configured to encrypt the log data by using a smart contract to obtain encrypted log data when it is determined that the source of the log data is the preset source and the log data is complete;
[0012] The third management module is used to link the encrypted log data to a distributed ledger for storage through blockchain technology.
[0013] In a third aspect, an embodiment of the present specification provides a computer storage medium, wherein the computer storage medium stores a plurality of instructions, wherein the instructions are suitable for being loaded by a processor and executing the above-mentioned method steps.
[0014] In a fourth aspect, an embodiment of the present specification provides a computer program product, wherein the computer program product stores a plurality of instructions, wherein the instructions are suitable for being loaded by a processor and executing the above-mentioned method steps.
[0015] In a fifth aspect, an embodiment of the present specification provides an electronic device, which may include: a processor and a memory; wherein the memory stores a computer program, and the computer program is suitable for being loaded by the processor and executing the above-mentioned method steps.
[0016] The beneficial effects brought by the technical solutions provided by some embodiments of this specification include at least:
[0017] When receiving log data, the embodiments of the present specification first detect whether the source of the log data is a preset source, for example, whether the log data comes from a trusted system or user, and detect whether the log data is complete, for example, determining, based on the type of the log data, that the log data includes multiple indicators corresponding to the type and data corresponding to each indicator; further, after determining that the source of the log data is compliant and complete, encrypt the log data through a smart contract to obtain encrypted log data, and link the encrypted log data to a distributed ledger for storage through blockchain technology.
[0018] In other words, in the embodiments of this specification, only after determining that the source of the log data is compliant and complete, the log data is chained to the blockchain for management, first ensuring that the log data stored in the blockchain is reliable, and further, because the blockchain is a distributed ledger, the problem of single point failure is eliminated by distributing and storing log data on multiple nodes, that is, even if a node is attacked or crashes, other nodes still retain complete log records, ensuring the resilience and sustainability of the system. At the same time, the blockchain has the characteristic of being tamper-proof. Once the log data is written into the blockchain through a smart contract, it cannot be modified or deleted. This effectively avoids the possibility of administrators or high-authority users illegally tampering with the logs, thereby enhancing the integrity of the log data and the credibility of the audit. BRIEF DESCRIPTION OF THE DRAWINGS
[0019] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0020] Figure 1 It is a schematic diagram of the architecture of a log management method provided in an embodiment of this specification;
[0021] Figure 2 It is a flow chart of a log management method provided by an embodiment of this specification;
[0022] Figure 3 It is a schematic diagram of the structure of block data provided by an embodiment of this specification;
[0023] Figure 4 It is a schematic diagram of the structure of a distributed ledger provided in an embodiment of this specification;
[0024] Figure 5 It is a flow chart of a log management method provided by an embodiment of this specification;
[0025] Figure 6 It is a flow chart of a log management method provided by an embodiment of this specification;
[0026] Figure 7 It is a structural diagram of a log management device provided in an embodiment of this specification;
[0027] Figure 8 It is a structural schematic diagram of an electronic device provided in an embodiment of this specification. DETAILED DESCRIPTION
[0028] The following will be combined with the drawings in the embodiments of this specification to clearly and completely describe the technical solutions in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this specification.
[0029] In the description of this specification, it should be understood that the terms "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or implying relative importance. In the description of this specification, it should be noted that, unless otherwise clearly specified and limited, "including" and "having" and any of their variations are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally also includes steps or units that are not listed, or optionally also includes other steps or units inherent to these processes, methods, products or devices. For those of ordinary skill in the art, the specific meanings of the above terms in this specification can be understood in specific circumstances. In addition, in the description of this specification, unless otherwise specified, "multiple" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B, which can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the associated objects before and after are an "or" relationship.
[0030] The present specification is described in detail below with reference to specific embodiments.
[0031] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions. For example, the features, information and data involved in this specification are all obtained with full authorization.
[0032] In the field of information security, log auditing is a key component in identifying and responding to network security incidents. Log auditing allows users to track the activities of critical systems, ensure the security compliance of system operations, and conduct investigations when security incidents such as system intrusions occur.
[0033] Common log management systems include centralized log management systems and log redundancy storage systems. Centralized log management systems are usually composed of specialized servers or software components that are responsible for collecting, storing, and analyzing logs from multiple log sources within the system. Log redundancy storage systems replicate logs to multiple storage devices, which may be distributed in different physical locations. This ensures that even if a storage device fails, copies in other locations can still provide the required information. However, centralized log management systems have single point failure problems and tampering risks. Specifically, when log storage is concentrated in one place, if the system is attacked or crashes, all logs may be destroyed, and administrators or users with advanced permissions may modify or delete log records, which may result in loss or incompleteness of audit evidence. Log redundancy storage systems have synchronization problems and cost issues. Specifically, log copies stored in multiple locations may cause data synchronization delays, affect the timeliness of logs, and require more storage space and management work, increasing the operating costs of the system.
[0034] Traditional log management systems have the risk of logs being tampered with or deleted, and there is no guarantee that the logs users obtain from the log management system are correct and complete. This may result in the inability to trace events through logs when attacked or threatened by an internal threat, which in turn affects incident response and even system security.
[0035] Therefore, the embodiment of this specification provides a log management method to solve the problem. Figure 1 As shown, Figure 1 It is a schematic diagram of the architecture of a log management method provided in an embodiment of this specification. Figure 1 It includes multiple electronic devices, which at least include multiple servers storing distributed ledgers and multiple electronic devices for uploading log data. The multiple servers at least include server 1011, server 1012, server 1013 and server 1014, and the multiple electronic devices at least include electronic device 1021, electronic device 1022 and electronic device 1023. It can be understood that Figure 1 The number of servers and electronic devices shown in the figure is for illustration only, and this specification does not impose any limitation on this.
[0036] The above-mentioned electronic devices include but are not limited to physical or virtual processors, mobile stations (MS), mobile terminals, mobile phones, handsets and portable equipment, Bluetooth headsets, smart watches and other types. The electronic devices can communicate with one or more core networks via a radio access network (RAN).
[0037] For example, the server is a plurality of physical servers, and the plurality of physical servers are independent in hardware. Or, the server is a plurality of virtual servers, and the plurality of virtual servers are deployed in the same hardware resource pool, and the deployment methods of the virtual servers include but are not limited to: VMware, Virtual Box and Virtual PC.
[0038] It is understandable that servers 1011, 1012, 1013, and 1014 also have other service capabilities and functions to complete the tasks in the following embodiments. For example, server 1011 also provides portal services, resource management services, and CI / CD services.
[0039] In the embodiments of the present specification, electronic devices such as electronic device 1021, electronic device 1022 and electronic device 1023 may also be equipped with display devices, and the display devices may be various devices capable of realizing display functions, for example, the display devices may be cathode ray tube display (Cathode ray tube display, referred to as CR), light-emitting diode display (Light-emitting diode display, referred to as LED), electronic ink screen, liquid crystal display (Liquid crystal display, referred to as LCD), plasma display panel (Plasma display panel, referred to as PDP), etc. For example, a user may use the display device on electronic device 1021 to send log data or log audit request to server 1011, or view log data sent by server 1011.
[0040] Multiple electronic devices and multiple servers can communicate through communication links established by communication protocols, such as the gRPC protocol. gRPC is a high-performance, general-purpose open source remote procedure call (RPC) framework, which is mainly designed for mobile application development and based on the HTTP / 2 protocol standard, based on the protocol buffer (PB) serialization protocol development, and supports many development languages. In addition, the communication link can also be a wireless communication link or a wired communication link, for example, a wired communication link includes an optical fiber, a twisted pair or a coaxial cable, and a wireless communication link includes a Bluetooth communication link, a wireless fidelity (WIreless-FIdelity, Wi-Fi) communication link or a microwave communication link.
[0041] In one embodiment, Figure 2As shown, it is a schematic diagram of a log management method provided by an embodiment of this specification, which can be implemented by a computer program and can be run on a log management device based on the von Neumann system. The computer program can be integrated into an application or run as an independent tool application.
[0042] Specifically, the log management method includes:
[0043] S102: receiving log data, and detecting whether the source of the log data is a preset source and whether the log data is complete.
[0044] Log data (Log Data) is the record information that system, application program or equipment produces in the execution process, and is mainly used to record its running state, user behavior, error event, performance data etc. In the embodiment of this specification, multiple log data from network equipment, security equipment, mainframe, middleware, database, memory, application and service etc. can be received for collection. For example, the embodiment of this specification can also include the log data of the operation process of log management personnel themselves, and this log data can be used for recording the operation process and operation result of log management personnel, so the embodiment of this specification can analyze the historical operation behavior of log management personnel and the result produced after the operation through log data.
[0045] Whether the source of the log data is a preset source is detected according to the source information of the log data. The source information of the log data may include but is not limited to at least one of the application type, account type, account name, and device number. For example, the log data is operation data generated when a certain device runs a certain application. The source of the log data includes the device number of the device and the application type of the application. For example, the device number of the device is the device number of the electronic device 1021.
[0046] The preset source can be understood as a source that indicates that the source of the log data is set in advance. The source of the log data is a preset source, which indicates that the source of the log data is compliant. The preset source can be preset by the log manager, and can also be set by receiving information such as application type, account type, account name, device number, etc. sent by the electronic device. For example, the preset source is a device number abc123def. When the log data is received, it is detected whether the source of the log data is the device number abc123def. If so, it is determined that the source of the log data is compliant.
[0047] Checking whether the log data is complete can be understood as checking whether the content of the log data is complete and whether the format is correct. For example, check the log configuration file of the log data to ensure that the log level (such as DEBUG, INFO, WARN, ERROR, etc.) and output format (such as JSON, plain text, etc.) meet the correct conditions. Further, compare the number of multiple log entries in the log data with the expected log entries. If the number decreases abnormally, it may indicate that data is lost. And check the timestamps in the log data to ensure that the timestamps of the data of multiple entries in the log data are continuous and there are no large time jumps. If time jumps occur, it may indicate that the log data of certain time periods has not been recorded, and the log data is incomplete.
[0048] S104: When it is determined that the source of the log data is a preset source and the log data is complete, encrypt the log data through a smart contract to obtain encrypted log data.
[0049] A smart contract is a computer protocol signed and stored on a blockchain network that can automatically execute contract terms and related operations when preset conditions are met. Encrypted log data is obtained by encrypting log data through smart contracts, and the encrypted log data is used as block data for subsequent linking to the blockchain.
[0050] The ledger maintained by any node in the blockchain stores data in a connected data block structure. Each data block includes a block header and a block body. The block body stores multiple log data obtained by packaging log data and a binary Merkle tree composed of hash values obtained by encrypting each log data. The block header generally includes a version number and the hash value (hash pointer) of the previous data block connected to the data block. Figure 3 It is a structural diagram of block data provided in an embodiment of this specification, which at least includes a hash value, data, a timestamp of generating data, a timestamp of generating a block (block version) and a hash pointer (the address of the previous block).
[0051] It is understandable that, according to different application requirements, the data items of the block header / body and the blockchain structure (such as single-chain and double-chain structures) may also be different, and this embodiment does not impose any restrictions on this. Figure 3 The structure of the block data shown is for illustration only.
[0052] Each node in the blockchain pre-stores a pair of public keys and secret keys. The secret key is used to encrypt the node identifier from plain text to cipher text, while the public key is used to decrypt the cipher text to plain text, thereby obtaining log data.
[0053] S106. Link the encrypted log data to a distributed ledger for storage through blockchain technology.
[0054] The management of distributed ledgers is achieved through blockchain. Multiple nodes are set up on the blockchain. The blockchain is a decentralized distributed database that reflects the characteristics of being collectively maintained by multiple nodes that join the blockchain. Among them, each node stores data blocks arranged in chronological order, and each block stores several log data. Cryptography methods are used to ensure that the log data in the block is tamper-proof, unforgeable, and verifiable. The consensus algorithm enables all nodes on the entire blockchain (theoretically all nodes) to complete the recognition of the block, and different nodes exchange data through a peer-to-peer network (Peer to Peer, P2P). The ledger maintained by any node in the blockchain stores data in a connected data block structure.
[0055] like Figure 4 As shown, Figure 4 2 is a schematic diagram of a distributed ledger structure provided in an embodiment of this specification, including multiple decentralized nodes, and the multiple nodes at least include node 201, node 202, node 203, node 204, node 205, node 206, node 207 and node 208. It can be understood that the number of nodes and the adjacent relationship shown in this embodiment are only for illustration, and this specification does not make any limitation on this, and also includes any other number of nodes and the adjacent relationship between multiple nodes.
[0056] Specifically, through blockchain technology, the encrypted log data is added as a new block to the target node included in the distributed ledger, and the new block is broadcast to multiple nodes included in the distributed ledger.
[0057] Taking the node 201 receiving the log data as an example, the node 201 encrypts the log data using the stored encryption parameters corresponding to the transaction data type of the log data, signs the encrypted log data using the node identifier of the reporting node 201, and writes the block data. The node 101 broadcasts the encrypted and reported node-signed block data to the target node 202 in the blockchain, and further synchronizes the encrypted log data to other nodes in the blockchain through nodes 202, 204, 205, and 207, thereby completing the linking of the encrypted log data to the distributed ledger for storage.
[0058] When receiving log data, the embodiments of the present specification first detect whether the source of the log data is a preset source, for example, whether the log data comes from a trusted system or user, and detect whether the log data is complete, for example, determining, based on the type of the log data, that the log data includes multiple indicators corresponding to the type and data corresponding to each indicator; further, after determining that the source of the log data is compliant and complete, encrypt the log data through a smart contract to obtain encrypted log data, and link the encrypted log data to a distributed ledger for storage through blockchain technology.
[0059] In other words, in the embodiments of this specification, only after determining that the source of the log data is compliant and complete, the log data is chained to the blockchain for management, first ensuring that the log data stored in the blockchain is reliable, and further, because the blockchain is a distributed ledger, the problem of single point failure is eliminated by distributing and storing log data on multiple nodes, that is, even if a node is attacked or crashes, other nodes still retain complete log records, ensuring the resilience and sustainability of the system. At the same time, the blockchain has the characteristic of being tamper-proof. Once the log data is written into the blockchain through a smart contract, it cannot be modified or deleted. This effectively avoids the possibility of administrators or high-authority users illegally tampering with the logs, thereby enhancing the integrity of the log data and the credibility of the audit.
[0060] In one embodiment, Figure 5 As shown, it is a schematic diagram of a log management method provided by an embodiment of this specification, which can be implemented by a computer program and can be run on a log management device based on the von Neumann system. The computer program can be integrated into an application or run as an independent tool application.
[0061] Specifically, the log management method includes:
[0062] S202: Receive log data, and detect whether the source of the log data is a preset source and whether the log data is complete.
[0063] See the above S102, which will not be described again here.
[0064] S204. Encrypt the log data through the smart contract to obtain encrypted log data.
[0065] See the above S104, which will not be described again here.
[0066] S206. Link the encrypted log data to a distributed ledger for storage through blockchain technology.
[0067] See the above S106, which will not be described again here.
[0068] S208: Receive a log audit request for log data.
[0069] Then, a pre-stored audit table is determined, and the log data in a unified format is stored in the audit table according to the data attributes of the log data. The data attributes here at least include the operation content, operation method, operator and operation time.
[0070] S210. Do the identity information and audit parameters corresponding to the detection log audit request meet the preset conditions?
[0071] The identity information corresponding to the log audit request represents the identity of the user or device requesting to retrieve log data and perform log audit. The audit parameters corresponding to the log audit request represent information such as the specific content of the retrieved log data and the sending time of the log audit request.
[0072] By detecting whether the identity information and audit parameters corresponding to the log audit request meet the preset conditions, only after it is determined that the identity information and audit parameters corresponding to the log audit request meet the preset conditions, that is, after it is determined that the identity information and audit parameters corresponding to the log audit request are compliant, the log data is sent to the receiving address specified in the log audit request, thereby protecting the log data from being leaked and improving data security.
[0073] In one embodiment, it is detected whether the identity information corresponding to the log audit request is the preset identity information; when it is determined that the identity information corresponding to the log audit request is the preset identity information, it is detected whether the audit parameters corresponding to the log audit request comply with the permission rules corresponding to the preset identity information; when it is determined that the identity information corresponding to the log audit request is the preset identity information, and the audit parameters corresponding to the log audit request comply with the permission rules corresponding to the preset identity information, encrypted log data is retrieved in the distributed ledger according to the permission rules.
[0074] When retrieving log data through blockchain response to log review request, the server first receives the log audit request of the calling device, determines the identity information of the calling device based on the log audit request, and determines the log data to be retrieved based on the audit parameters corresponding to the log audit request.
[0075] Determine whether the identity information of the calling device is the preset identity information, that is, whether the identity information is the identity information that is allowed to call the log data. Then determine the security permissions of the log data that the identity information is allowed to call, compare the calling permissions required by the audit parameters with the security permissions, and if the calling permissions match the security permissions, retrieve the encrypted log data stored in the block data in the distributed ledger.
[0076] If the calling permission does not match the security permission, or the identity information is not the preset identity information, the log audit request will be rejected.
[0077] S212: When it is determined that the identity information and audit parameters corresponding to the log audit request meet the preset conditions, the encrypted log data is retrieved from the distributed ledger according to the permission rules.
[0078] The permission rules are related to the identity information and audit parameters corresponding to the log audit request. Specifically, when the identity information corresponding to the log audit request is the preset identity information, the permission rules include the security permissions for the log data that are allowed to be called by the preset identity information. For example, a preset identity information is set with the log data that is allowed to be called only for a certain device, and the log data of other devices is not allowed to be called by the calling device from the preset identity information.
[0079] Detect whether the identity information corresponding to the log audit request is the preset identity information; when it is determined that the identity information corresponding to the log audit request is the preset identity information, detect whether the audit parameters corresponding to the log audit request comply with the permission rules corresponding to the preset identity information; when it is determined that the identity information corresponding to the log audit request is the preset identity information and the audit parameters corresponding to the log audit request comply with the permission rules corresponding to the preset identity information, retrieve the encrypted log data in the distributed ledger according to the permission rules, and the content of the encrypted log data complies with the permission rules corresponding to the preset identity information. In other words, the content of the encrypted log data is within the content range of the encrypted log data that the preset identity information is allowed to call.
[0080] When retrieving encrypted log data in a distributed ledger according to permission rules, the block data corresponding to the hash value associated with the audit parameter can be matched in multiple block data according to the encryption algorithm for encrypting the log data through the audit parameter. The encrypted log data stored in the block data is the encrypted log data required for the log audit request.
[0081] S214. Send the encrypted log data to the receiving address specified by the log audit request.
[0082] The receiving address specified in the log audit request can be any address for receiving encrypted log data, such as a MAC address, an email address, or a mobile phone number. The receiving device corresponding to the receiving address of the encrypted log data and the sending device corresponding to the log review request can be the same or different.
[0083] The encrypted log data is sent to the receiving address specified by the log audit request, and the receiving device corresponding to the receiving address decrypts the encrypted log data according to the agreed decryption method or key to obtain the log data. This embodiment ensures the privacy and security of the log data during transmission by sending encrypted log data.
[0084] S216: When it is determined that the identity information or audit parameters corresponding to the log audit request do not meet the preset conditions, refuse to respond to the log audit request.
[0085] When it is determined that the identity information or audit parameters corresponding to the log audit request do not meet the preset conditions, it indicates that the log audit request attempts to call log data that does not meet the permission rules. At this time, a warning message can be sent to the corresponding calling device according to the identity information corresponding to the log audit request, and the log audit request of the calling device is prohibited, that is, the log audit request sent by the calling device is no longer received.
[0086] The blockchain node may also send a marginalization protocol to the blockchain node corresponding to the log data to be retrieved, so as to prohibit the blockchain node from sending the encrypted log data to the receiving address corresponding to the log review request according to the marginalization protocol. Due to the existence of illegal review requests, the server corresponding to the encrypted log data may be attacked at this time. At this time, the log data or encrypted log data may be prohibited from entering the server to prevent the encrypted log data from interfering with other log data stored on the server node related to the log data.
[0087] S218. When it is determined that the source of the log data is not the preset source, or the log data is incomplete, refuse to store the log data in the distributed ledger.
[0088] When it is determined that the source of the log data is not the preset source, or the log data is incomplete, there is no need to perform steps such as encrypting the log data and uploading the encrypted log data to the blockchain. Further, the log data can be deleted, or warning measures such as notifying the sending device of the log data to complete the log data can be taken.
[0089] When receiving log data, the embodiments of the present specification first detect whether the source of the log data is a preset source, for example, whether the log data comes from a trusted system or user, and detect whether the log data is complete, for example, determining, based on the type of the log data, that the log data includes multiple indicators corresponding to the type and data corresponding to each indicator; further, after determining that the source of the log data is compliant and complete, encrypt the log data through a smart contract to obtain encrypted log data, and link the encrypted log data to a distributed ledger for storage through blockchain technology.
[0090] In other words, in the embodiments of this specification, only after determining that the source of the log data is compliant and complete, the log data is chained to the blockchain for management, first ensuring that the log data stored in the blockchain is reliable, and further, because the blockchain is a distributed ledger, the problem of single point failure is eliminated by distributing and storing log data on multiple nodes, that is, even if a node is attacked or crashes, other nodes still retain complete log records, ensuring the resilience and sustainability of the system. At the same time, the blockchain has the characteristic of being tamper-proof. Once the log data is written into the blockchain through a smart contract, it cannot be modified or deleted. This effectively avoids the possibility of administrators or high-authority users illegally tampering with the logs, thereby enhancing the integrity of the log data and the credibility of the audit.
[0091] In one embodiment, Figure 6 As shown, it is a schematic diagram of a log management method provided by an embodiment of this specification, which can be implemented by a computer program and can be run on a log management device based on the von Neumann system. The computer program can be integrated into an application or run as an independent tool application.
[0092] Specifically, the log management method includes:
[0093] S302: Receive log data and check whether the source of the log data is a preset source.
[0094] The preset source can be understood as a source that indicates that the source of the log data is set in advance. The source of the log data is a preset source, which indicates that the source of the log data is compliant. The preset source can be preset by the log manager, and can also be set by receiving information such as application type, account type, account name, device number, etc. sent by the electronic device. For example, the preset source is a device number abc123def. When the log data is received, it is detected whether the source of the log data is the device number abc123def. If so, it is determined that the source of the log data is compliant.
[0095] S304: When it is determined that the source of the log data is a preset source, based on multiple indicators corresponding to the target type to which the log data belongs, detect whether the log data includes data corresponding to the multiple indicators respectively.
[0096] In the server, multiple indicators corresponding to the target type of log data are preset, and each indicator should include corresponding data. For example, the log data should have a time indicator, and the time indicator includes at least two timestamps, namely the start timestamp of the log data and the end timestamp of the log data.
[0097] In one embodiment, the target type to which the log data belongs is the log type generated when a security event is triggered. The security event indicates that the target system has been attacked. The multiple indicators corresponding to the target type include at least one of the following indicators: the time when the attack occurred, the system information of the target system, and the attack method.
[0098] Security incidents can be detected and triggered during network security operation and maintenance by the intrusion detection system of the target system. Network security operation and maintenance refers to the production organization and management activities taken to ensure the safe, stable and efficient operation of the enterprise's electronic affairs. The network security operation and maintenance specifically refers to various IT maintenance methods. Intrusion Detection System (IDS) refers to: a network security device that monitors network transmission in real time and issues an alarm or takes active response measures when suspicious transmission is found.
[0099] When a security incident occurs in the target system, the Intrusion Prevention System (IPS) will be activated. It is a special switch with the function of processing attacks. It is a sub-item of network switches. It is usually arranged between the firewall and the equipment of the external network, relying on the detection of data packets for defense. The specific functions are: check the data packets entering the network, determine the real purpose of the data packets, and then decide whether to allow them to enter the system intranet.
[0100] When a security incident is detected in the target system, log data will be generated based on the security incident. The target type to which the log data belongs is the log type generated when the security incident is triggered. The multiple indicators corresponding to the preset target type include at least one of the following indicators: the time when the attack occurred, the system information of the target system, and the attack method. Among them, the time when the attack occurred represents the time when the intrusion or attack occurred, the system information of the target system represents information such as the version number and system type of the system, and the attack method represents the type of the intrusion or attack, such as social engineering attack, phishing, Trojan attack, system vulnerability attack, or network monitoring and interception.
[0101] According to the multiple indicators corresponding to the target type to which the log data belongs, it is detected whether the log data includes the data corresponding to the multiple indicators. For example, when the target type includes the time when the attack occurred, the system information of the target system, and the attack method, a total of three indicators, it is detected whether the log data includes the data corresponding to the above three indicators. Only when the log data includes the data corresponding to the above three indicators, it is determined that the log data is complete.
[0102] In other embodiments, this specification may also include other types of log data. For example, the type of log data is log data generated when securities transactions occur in fund institutions, or log data generated when credit behavior occurs in fund institutions. For different types of log data, log managers may set different numbers and different types of indicators, and this specification embodiment does not impose any restrictions on this.
[0103] S306: When it is determined that the log data includes data corresponding to a plurality of indicators, the log data is formatted to obtain log data in a preset format.
[0104] Before encrypting the log data, the server needs to determine the data format of the acquired log data, such as character type, text type, etc., and pre-process the log data according to the initialization rules to unify the format of the log data and obtain log data in a preset format.
[0105] Specifically, common log formats include plain text, JSON, XML, etc. In order to process uniformly, daily data needs to be formatted into the same format, such as JSON. A standard JSON structure is preset, including fields such as timestamp, log level, log source, and log content. First, the log data is field mapped. If the fields of the original log data do not completely match the standard JSON structure, field mapping is required. That is, the original fields are mapped to the corresponding fields of the standard JSON structure. Further, the log data is parsed. For complex data structures (such as JSON arrays or objects) nested in the log data, parsing is required to extract the required fields. The JSON parsing library in the programming language (such as Python's json library) can be used to complete this task. Further, the timestamps included in the log data are processed to ensure that the log data contains the correct timestamps and convert them to a unified time zone or format. The timestamp is an important field in the log data, which is particularly important for time synchronization and sequential verification on the blockchain.
[0106] When log data is received, data cleaning processing can also be performed on the log data, including removing invalid or duplicate data, correcting erroneous data formats or content, filtering out unnecessary fields or information, etc.
[0107] S308. Encrypt the log data in a preset format through a smart contract to obtain encrypted log data.
[0108] See the above S104, which will not be described again here.
[0109] S310, linking the encrypted log data to a distributed ledger for storage through blockchain technology.
[0110] See the above S106, which will not be described again here.
[0111] S312: When it is determined that the source of the log data is not the preset source, or the log data is incomplete, refuse to store the log data in the distributed ledger.
[0112] See above S218, which will not be repeated here.
[0113] When receiving log data, the embodiments of the present specification first detect whether the source of the log data is a preset source, for example, whether the log data comes from a trusted system or user, and detect whether the log data is complete, for example, determining, based on the type of the log data, that the log data includes multiple indicators corresponding to the type and data corresponding to each indicator; further, after determining that the source of the log data is compliant and complete, encrypt the log data through a smart contract to obtain encrypted log data, and link the encrypted log data to a distributed ledger for storage through blockchain technology.
[0114] In other words, in the embodiments of this specification, only after determining that the source of the log data is compliant and complete, the log data is chained to the blockchain for management, first ensuring that the log data stored in the blockchain is reliable, and further, because the blockchain is a distributed ledger, the problem of single point failure is eliminated by distributing and storing log data on multiple nodes, that is, even if a node is attacked or crashes, other nodes still retain complete log records, ensuring the resilience and sustainability of the system. At the same time, the blockchain has the characteristic of being tamper-proof. Once the log data is written into the blockchain through a smart contract, it cannot be modified or deleted. This effectively avoids the possibility of administrators or high-authority users illegally tampering with the logs, thereby enhancing the integrity of the log data and the credibility of the audit.
[0115] The following are device embodiments of this specification, which can be used to implement the method embodiments of this specification. For details not disclosed in the device embodiments of this specification, please refer to the method embodiments of this specification.
[0116] See also Figure 7 , which shows a schematic diagram of the structure of a log management device provided by an exemplary embodiment of this specification. The log management device can be implemented as all or part of the device through software, hardware or a combination of both. The device includes a first management module 401, a second management module 402 and a third management module 403.
[0117] The first management module 401 is used to receive log data, detect whether the source of the log data is a preset source and whether the log data is complete;
[0118] A second management module 402 is used to encrypt the log data through a smart contract to obtain encrypted log data when it is determined that the source of the log data is the preset source and the log data is complete;
[0119] The third management module 403 is used to link the encrypted log data to a distributed ledger for storage through blockchain technology.
[0120] In one embodiment, the log management device further includes:
[0121] A first audit module, configured to receive a log audit request for the log data;
[0122] The second audit module is used to detect whether the identity information and audit parameters corresponding to the log audit request meet the preset conditions;
[0123] A third audit module, configured to retrieve the encrypted log data in the distributed ledger according to the permission rules when the identity information and the audit parameters corresponding to the log audit request meet the preset conditions;
[0124] The fourth audit module is used to send the encrypted log data to the receiving address specified by the log audit request.
[0125] In one embodiment, the second audit module includes:
[0126] A first audit unit, used to detect whether the identity information corresponding to the log audit request is preset identity information;
[0127] A second audit unit is used to detect whether the audit parameter corresponding to the log audit request complies with the authority rule corresponding to the preset identity information when it is determined that the identity information corresponding to the log audit request is the preset identity information;
[0128] The third audit module includes:
[0129] The third audit unit is used to retrieve the encrypted log data in the distributed ledger according to the permission rule when it is determined that the identity information corresponding to the log audit request is the preset identity information and the audit parameter corresponding to the log audit request meets the permission rule corresponding to the preset identity information.
[0130] In one embodiment, the log management device further includes:
[0131] The fifth audit module is used to refuse to respond to the log audit request when it is determined that the identity information or audit parameter corresponding to the log audit request does not meet the preset conditions.
[0132] In one embodiment, the second management module 402 includes:
[0133] A first management unit is used to format the log data to obtain log data in a preset format when it is determined that the source of the log data is the preset source and the log data is complete;
[0134] The second management unit is used to encrypt the log data in the preset format through a smart contract to obtain encrypted log data.
[0135] In one embodiment, the third management module 403 includes:
[0136] The third management unit is used to add the encrypted log data as a new block to the target node included in the distributed ledger through the blockchain technology, and broadcast the new block to the multiple nodes included in the distributed ledger.
[0137] In one embodiment, the first management module 401 includes:
[0138] A fourth management unit, configured to receive the log data and detect whether a source of the log data is a preset source;
[0139] The fifth management unit is used to detect whether the log data includes data corresponding to the multiple indicators respectively according to the multiple indicators corresponding to the target type to which the log data belongs when the source of the log data is the preset source, so as to detect whether the log data is complete.
[0140] In one embodiment, the target type to which the log data belongs is a log type generated when a security event is triggered. The security event indicates that the target system is attacked. The multiple indicators corresponding to the target type include at least one of the following indicators: the time when the attack occurred, the system information of the target system, and the attack method.
[0141] In one embodiment, the log management device further includes:
[0142] The fourth management module is used to refuse to store the log data in the distributed ledger when it is determined that the source of the log data is not the preset source or the log data is incomplete.
[0143] When receiving log data, the embodiments of the present specification first detect whether the source of the log data is a preset source, for example, whether the log data comes from a trusted system or user, and detect whether the log data is complete, for example, determining, based on the type of the log data, that the log data includes multiple indicators corresponding to the type and data corresponding to each indicator; further, after determining that the source of the log data is compliant and complete, encrypt the log data through a smart contract to obtain encrypted log data, and link the encrypted log data to a distributed ledger for storage through blockchain technology.
[0144] In other words, in the embodiments of this specification, only after determining that the source of the log data is compliant and complete, the log data is chained to the blockchain for management, first ensuring that the log data stored in the blockchain is reliable, and further, because the blockchain is a distributed ledger, the problem of single point failure is eliminated by distributing and storing log data on multiple nodes, that is, even if a node is attacked or crashes, other nodes still retain complete log records, ensuring the resilience and sustainability of the system. At the same time, the blockchain has the characteristic of being tamper-proof. Once the log data is written into the blockchain through a smart contract, it cannot be modified or deleted. This effectively avoids the possibility of administrators or high-authority users illegally tampering with the logs, thereby enhancing the integrity of the log data and the credibility of the audit.
[0145] It should be noted that the log management device provided in the above embodiment only uses the division of the above functional modules as an example when executing the log management method. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the log management device provided in the above embodiment and the log management method embodiment belong to the same concept, and the implementation process thereof is detailed in the method embodiment, which will not be repeated here.
[0146] The serial numbers of the embodiments of this specification are for description only and do not represent the advantages or disadvantages of the embodiments.
[0147] The present specification also provides a computer storage medium, which can store multiple instructions, and the instructions are suitable for being loaded and executed by a processor as described above. Figure 1 - Figure 6 The log management method of the embodiment shown in the figure can be found in the specific execution process. Figure 1 - Figure 6 The specific description of the illustrated embodiment will not be repeated here.
[0148] The present specification also provides a computer program product, which stores at least one instruction, and the at least one instruction is loaded and executed by the processor as described above. Figure 1 - Figure 6 The log management method of the embodiment shown in the figure can be found in the specific execution process. Figure 1 - Figure 6 The specific description of the illustrated embodiment will not be repeated here.
[0149] See also Figure 8 , is a schematic diagram of the structure of an electronic device provided in the embodiment of this specification. Figure 8 As shown, the electronic device 500 may include: at least one processor 501 , at least one network interface 504 , a user interface 503 , a memory 505 , and at least one communication bus 502 .
[0150] The communication bus 502 is used to realize the connection and communication between these components.
[0151] The user interface 503 may include a display screen (Display) and a camera (Camera), and the optional user interface 503 may also include a standard wired interface and a wireless interface.
[0152] The network interface 504 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface).
[0153] Among them, the processor 501 may include one or more processing cores. The processor 501 uses various interfaces and lines to connect various parts within the entire server 500, and executes various functions and processes data of the server 500 by running or executing instructions, programs, code sets or instruction sets stored in the memory 505, and calling data stored in the memory 505. Optionally, the processor 501 can be implemented in at least one hardware form of digital signal processing (Digital Signal Processing, DSP), field programmable gate array (Field-Programmable Gate Array, FPGA), and programmable logic array (Programmable Logic Array, PLA). The processor 501 can integrate one or more combinations of a processor (Central Processing Unit, CPU), an image processor (Graphics Processing Unit, GPU) and a modem. Among them, the CPU mainly processes the operating system, user interface and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; and the modem is used to process wireless communications. It can be understood that the above-mentioned modem may not be integrated into the processor 501, and it can be implemented separately through a chip.
[0154] Among them, the memory 505 may include a random access memory (Random Access Memory, RAM) and may also include a read-only memory (Read-Only Memory). Optionally, the memory 505 includes a non-transitory computer-readable storage medium. The memory 505 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 505 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store data involved in the above-mentioned various method embodiments, etc. The memory 505 may also be optionally at least one storage device located away from the aforementioned processor 501. As Figure 7 As shown, the memory 505 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a log management application.
[0155] exist Figure 7In the electronic device 500 shown, the user interface 503 is mainly used to provide an input interface for the user and obtain the data input by the user; and the processor 501 can be used to call the log management application stored in the memory 505, and specifically perform the following operations:
[0156] Receiving log data, and detecting whether a source of the log data is a preset source and whether the log data is complete;
[0157] When it is determined that the source of the log data is the preset source and the log data is complete, encrypting the log data through a smart contract to obtain encrypted log data;
[0158] The encrypted log data is linked to a distributed ledger for storage through blockchain technology.
[0159] In one embodiment, the processor 501 executes the log management method and further executes:
[0160] Receiving a log audit request for the log data;
[0161] Detect whether the identity information and audit parameters corresponding to the log audit request meet the preset conditions;
[0162] When the identity information and audit parameters corresponding to the log audit request meet the preset conditions, retrieving the encrypted log data in the distributed ledger according to the permission rules;
[0163] The encrypted log data is sent to the receiving address specified by the log audit request.
[0164] In one embodiment, the processor 501 performs the detection of whether the identity information and audit parameters corresponding to the log audit request meet the preset conditions, specifically performing:
[0165] Detecting whether the identity information corresponding to the log audit request is the preset identity information;
[0166] When it is determined that the identity information corresponding to the log audit request is the preset identity information, detecting whether the audit parameter corresponding to the log audit request complies with the authority rule corresponding to the preset identity information;
[0167] The processor 501 executes the step of retrieving the encrypted log data in the distributed ledger according to the permission rule when the identity information and the audit parameter corresponding to the log audit request meet the preset condition, specifically performing:
[0168] When it is determined that the identity information corresponding to the log audit request is the preset identity information, and the audit parameter corresponding to the log audit request complies with the permission rule corresponding to the preset identity information, the encrypted log data is retrieved in the distributed ledger according to the permission rule.
[0169] In one embodiment, after the processor 501 executes the detection of whether the identity information and the audit parameters corresponding to the log audit request meet the preset conditions, it further executes:
[0170] When it is determined that the identity information or audit parameter corresponding to the log audit request does not meet the preset condition, the log audit request is refused to be responded to.
[0171] In one embodiment, the processor 501 executes the step of encrypting the log data by a smart contract to obtain encrypted log data when it is determined that the source of the log data is the preset source and the log data is complete, specifically performing:
[0172] When it is determined that the source of the log data is the preset source and the log data is complete, formatting the log data to obtain log data in a preset format;
[0173] The log data in the preset format is encrypted by a smart contract to obtain encrypted log data.
[0174] In one embodiment, the processor 501 executes the linking of the encrypted log data to the distributed ledger for storage by using the blockchain technology, specifically performing:
[0175] By using blockchain technology, the encrypted log data is added as a new block to the target node included in the distributed ledger, and the new block is broadcast to multiple nodes included in the distributed ledger.
[0176] In one embodiment, the processor 501 executes the receiving of log data, and detects whether the source of the log data is a preset source and whether the log data is complete, specifically performing:
[0177] receiving the log data, and detecting whether a source of the log data is a preset source;
[0178] When the source of the log data is the preset source, based on multiple indicators corresponding to the target type to which the log data belongs, it is detected whether the log data includes data corresponding to the multiple indicators respectively, so as to detect whether the log data is complete.
[0179] In one embodiment, the target type to which the log data belongs is a log type generated when a security event is triggered. The security event indicates that the target system is attacked. The multiple indicators corresponding to the target type include at least one of the following indicators: the time when the attack occurred, the system information of the target system, and the attack method.
[0180] In one embodiment, after the processor 501 receives the log data and detects whether the source of the log data is a preset source and whether the log data is complete, it further executes:
[0181] When it is determined that the source of the log data is not the preset source, or the log data is incomplete, refusing to store the log data in the distributed ledger.
[0182] When receiving log data, the embodiments of the present specification first detect whether the source of the log data is a preset source, for example, whether the log data comes from a trusted system or user, and detect whether the log data is complete, for example, determining, based on the type of the log data, that the log data includes multiple indicators corresponding to the type and data corresponding to each indicator; further, after determining that the source of the log data is compliant and complete, encrypt the log data through a smart contract to obtain encrypted log data, and link the encrypted log data to a distributed ledger for storage through blockchain technology.
[0183] In other words, in the embodiments of this specification, only after determining that the source of the log data is compliant and complete, the log data is chained to the blockchain for management, first ensuring that the log data stored in the blockchain is reliable, and further, because the blockchain is a distributed ledger, the problem of single point failure is eliminated by distributing and storing log data on multiple nodes, that is, even if a node is attacked or crashes, other nodes still retain complete log records, ensuring the resilience and sustainability of the system. At the same time, the blockchain has the characteristic of being tamper-proof. Once the log data is written into the blockchain through a smart contract, it cannot be modified or deleted. This effectively avoids the possibility of administrators or high-authority users illegally tampering with the logs, thereby enhancing the integrity of the log data and the credibility of the audit.
[0184] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing related hardware through a computer program, and the program can be stored in a computer-readable storage medium, and when the program is executed, it can include the processes of the embodiments of the above-mentioned methods. The storage medium can be a disk, an optical disk, a read-only storage memory, or a random access memory, etc.
[0185] The technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0186] The above disclosure is only the preferred embodiment of this specification, which certainly cannot be used to limit the scope of rights of this specification. Therefore, equivalent changes made according to the claims of this specification are still within the scope covered by this specification.
Claims
1. A log management method, the method comprising: Receiving log data, and detecting whether a source of the log data is a preset source and whether the log data is complete; When it is determined that the source of the log data is the preset source and the log data is complete, encrypting the log data through a smart contract to obtain encrypted log data; The encrypted log data is linked to a distributed ledger for storage through blockchain technology.
2. The log management method according to claim 1, further comprising: Receiving a log audit request for the log data; Detect whether the identity information and audit parameters corresponding to the log audit request meet the preset conditions; When the identity information and audit parameters corresponding to the log audit request meet the preset conditions, retrieving the encrypted log data in the distributed ledger according to the permission rules; The encrypted log data is sent to the receiving address specified by the log audit request.
3. According to the log management method of claim 2, the step of detecting whether the identity information and audit parameters corresponding to the log audit request meet preset conditions comprises: Detecting whether the identity information corresponding to the log audit request is the preset identity information; When it is determined that the identity information corresponding to the log audit request is the preset identity information, detecting whether the audit parameter corresponding to the log audit request complies with the authority rule corresponding to the preset identity information; When the identity information and the audit parameter corresponding to the log audit request meet the preset condition, retrieving the encrypted log data in the distributed ledger according to the permission rule includes: When it is determined that the identity information corresponding to the log audit request is the preset identity information, and the audit parameter corresponding to the log audit request complies with the permission rule corresponding to the preset identity information, the encrypted log data is retrieved in the distributed ledger according to the permission rule.
4. The log management method according to claim 2, after detecting whether the identity information and audit parameters corresponding to the log audit request meet the preset conditions, further comprising: When it is determined that the identity information or audit parameter corresponding to the log audit request does not meet the preset condition, the log audit request is refused to be responded to.
5. The log management method according to claim 1, wherein when it is determined that the source of the log data is the preset source and the log data is complete, encrypting the log data by a smart contract to obtain encrypted log data comprises: When it is determined that the source of the log data is the preset source and the log data is complete, formatting the log data to obtain log data in a preset format; The log data in the preset format is encrypted by a smart contract to obtain encrypted log data.
6. The log management method according to claim 1, wherein the encrypted log data is linked to a distributed ledger for storage by using blockchain technology, comprising: By using blockchain technology, the encrypted log data is added as a new block to the target node included in the distributed ledger, and the new block is broadcast to multiple nodes included in the distributed ledger.
7. The log management method according to claim 1, wherein the receiving log data and detecting whether the source of the log data is a preset source and whether the log data is complete comprises: receiving the log data, and detecting whether a source of the log data is a preset source; When the source of the log data is the preset source, based on multiple indicators corresponding to the target type to which the log data belongs, it is detected whether the log data includes data corresponding to the multiple indicators respectively, so as to detect whether the log data is complete.
8. According to the log management method of claim 7, the target type to which the log data belongs is the log type generated when a security event is triggered, the security event represents that the target system is attacked, and the multiple indicators corresponding to the target type include at least one of the following indicators: the time when the attack occurred, the system information of the target system, and the attack method.
9. The log management method according to claim 1, after receiving the log data and detecting whether the source of the log data is a preset source and whether the log data is complete, further comprising: When it is determined that the source of the log data is not the preset source, or the log data is incomplete, refusing to store the log data in the distributed ledger.
10. A log management device, comprising: A first management module, used for receiving log data, detecting whether the source of the log data is a preset source and whether the log data is complete; A second management module, configured to encrypt the log data by using a smart contract to obtain encrypted log data when it is determined that the source of the log data is the preset source and the log data is complete; The third management module is used to link the encrypted log data to a distributed ledger for storage through blockchain technology.
11. A computer storage medium storing a plurality of instructions, wherein the instructions are suitable for being loaded by a processor and executing the method steps according to any one of claims 1 to 9.
12. A computer program product, wherein the computer program product stores a plurality of instructions, wherein the instructions are suitable for being loaded by a processor and executing the method steps according to any one of claims 1 to 9.
13. An electronic device, comprising: A processor and a memory; wherein the memory stores a computer program, and the computer program is suitable for being loaded by the processor and executing the method steps as claimed in any one of claims 1 to 9.
Citation Information
Patent Citations
Log processing method and device of log server
CN103795577A
Log storage and reading method and device based on block chain, equipment and medium
CN110839015A
Log processing method and device based on block chain, computer equipment and storage medium
CN111092745A
Log data sorting and evidence storing method and system based on block chain, equipment and medium
CN112214800A
Log auditing method based on block chain and device thereof
CN112448946A