Log auditing method and device based on identity key and service logic collaborative configuration, equipment and medium

Abstract

The invention discloses a log auditing method and device based on identity key and business logic collaborative configuration, equipment and a medium. The method comprises the following steps: configuring an auditing strategy associated with a specific business operation node in business logic; in response to service logic execution to the specific service operation node, extracting and structuring a key service data field set from a current service execution context according to the auditing strategy, and generating a to-be-signed data packet; obtaining an identity private key of a current operation main body to perform digital signature operation on the to-be-signed data packet to generate a digital signature value; performing association packaging on the digital signature value, the to-be-signed data packet and a corresponding public key to generate a structured log record; and outputting the structured log record to a log stream, and providing a signature verification interface based on the public key certificate for auditing. The auditing efficiency and accuracy can be effectively improved, and the defect that log auditing lacks business context is overcome.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of business log audit, in particular to a log audit method and device based on identity key and business logic collaborative configuration, equipment and medium. BACKGROUND

[0002] In today's information technology field, with the increasing demand for data security and operation audit in key industries such as finance and medical treatment, the traditional log audit system exposes many defects.

[0003] Firstly, the traditional log recording method is relatively simple, usually only records the basic information such as operation time, user identification, operation type and IP address. This recording method cannot fully reflect the key details of business operation. Secondly, although some systems will hash the log or use a unified key for encryption, the key management method is relatively extensive. Once the key is leaked, all encrypted logs will face the risk of being cracked, resulting in a significant reduction in the security of the entire system. Finally, the traditional identity authentication, key management system and business logic are independent of each other. Log recording cannot implement differentiated security policies according to the importance and compliance requirements of business operation, and it is difficult to meet the strict requirements of the financial, medical and other industries for data security.

[0004] In summary, the existing log audit system has obvious shortcomings in recording integrity, data security and business relevance, and a more secure and reliable new log audit method is needed to solve these problems. SUMMARY

[0005] The purpose of the present application is to provide a log audit method, device, equipment and medium based on identity key and business logic collaborative configuration, to at least solve the problems of recording integrity, data security and business relevance of the current log audit system.

[0006] To solve the above technical problems, the present application provides a log audit method based on identity key and business logic collaborative configuration, comprising: configuring an audit policy associated with a specific business operation node in the business logic, the audit policy defining a set of key business data fields to be collected; In response to the execution of the business logic to the specific business operation node, the set of key business data fields is extracted and structured from the current business execution context according to the audit policy, and a to-be-signed data packet is generated; Determine the current operation subject, and obtain the identity private key of the operation subject to perform digital signature operation on the to-be-signed data packet, and generate a digital signature value; Associating and encapsulating the digital signature value, the to-be-signed data packet and the corresponding public key to generate a structured log record; outputting the structured log records to a log stream, and providing a signature verification interface based on the public key certificate for auditing.

[0007] Optionally, the generating the data package to be signed comprises: serializing the extracted set of key business data fields to generate a standardized data block; calculating a message digest value of the standardized data block; assembling the message digest value with a preset log header information to generate a final data package to be signed.

[0008] Optionally, the obtaining the identity private key of the operation subject and performing a digital signature operation comprises: initiating a signature challenge request to a client to which the operation subject belongs, the request carrying the data package to be signed; receiving a digital signature value returned by the client after signing the data package to be signed using an identity private key in a local secure hardware; verifying the validity of the digital signature value to confirm that it is a legal signature.

[0009] Optionally, after the generating the digital signature value, the method further comprises: encoding the digital signature value according to a cryptographic message syntax standard; binding the encoded digital signature value with a corresponding X.509 format digital certificate; performing time stamping authority time service on the bound data to obtain a trusted time stamp.

[0010] Optionally, after the outputting the structured log records, the method further comprises: configuring a real-time alarm strategy based on business rules, the alarm strategy being associated with the key business data fields defined in the auditing strategy; continuously consuming the log stream and parsing the structured log records therein to extract key business data; when the extracted data triggers the alarm strategy, generating and pushing a security alarm notification in real time.

[0011] Optionally, the generating and pushing the security alarm notification in real time comprises: dynamically generating alarm details containing the digital signature value of the associated log record according to the triggered alarm strategy level; simultaneously pushing the alarm details to a security operation center and a terminal device of a person in charge of the operation subject through a plurality of channels pre-integrated; embedding a quick verification interface in the alarm notification, so that a receiver can trigger online verification of the integrity and authenticity of the associated log record by one key.

[0012] Optionally, after the output structured log record, further comprising: Periodically uploading the batch log record to the IPFS distributed storage network; Recording the content identifier returned by the IPFS into the blockchain smart contract; Generating a verifiable storage proof certificate based on zero-knowledge proof technology.

[0013] To solve the above technical problems, the present application also provides a log audit device based on identity key and business logic cooperative configuration, comprising: A policy definition module is configured to configure an audit policy associated with a specific business operation node in the business logic, wherein the audit policy defines a set of key business data fields to be collected; A field extraction module is configured to extract and structure the set of key business data fields from the current business execution context according to the audit policy and generate a to-be-signed data packet in response to the execution of the business logic to the specific business operation node; A digital signature module is configured to determine the current operation subject and obtain the identity private key of the operation subject to perform digital signature operation on the to-be-signed data packet to generate a digital signature value; A log generation module is configured to associate and encapsulate the digital signature value, the to-be-signed data packet and the corresponding public key to generate a structured log record; A log verification module is configured to output the structured log record to a log stream and provide a signature verification interface based on the public key certificate for auditing.

[0014] To solve the above technical problems, the present application also provides a computer device comprising a memory and a processor, wherein the memory stores computer readable instructions, and the computer readable instructions are executed by the processor to make the processor execute the steps of the log audit method based on identity key and business logic cooperative configuration.

[0015] To solve the above technical problems, the present application also provides a storage medium storing computer readable instructions, wherein the computer readable instructions are executed by one or more processors to make the one or more processors execute the steps of the log audit method based on identity key and business logic cooperative configuration.

[0016] The beneficial effects of the embodiments created by the present application are as follows: firstly, by configuring the audit strategy associated with the specific business operation node in the business logic, the key business data field set to be collected is accurately defined, ensuring the pertinence and effectiveness of the collected data, and providing detailed basis for subsequent audit. Secondly, the key business data field is extracted and structured at the key business node, a to-be-signed data packet is generated, and the identity private key of the operation subject is used for digital signature, effectively guaranteeing the integrity and non-tamperability of the log, realizing the non-repudiation of the operation, and enhancing the credibility of the log. Thirdly, the digital signature value, the to-be-signed data packet and the public key are associated and encapsulated into a structured log record, which is convenient for storage and transmission, and a signature verification interface based on the public key certificate is provided, which is convenient for auditors to verify, and improves the audit efficiency and accuracy. In addition, the method is closely combined with the business logic, can reflect the business scene and compliance requirements of the operation, overcomes the defect that the traditional log audit lacks business context, is especially suitable for financial transaction systems, medical information systems and other scenes with high audit requirements, effectively reduces the risk of data leakage and operation denial, meets the strict requirements of relevant industry regulations, helps to improve the overall security and credibility of the system, and has wide applicability. BRIEF DESCRIPTION OF DRAWINGS

[0017] The above and / or additional aspects and advantages of the present application will become apparent and more readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings, in which: Figure 1 The basic flowchart of a log audit method based on identity key and business logic cooperative configuration for one specific embodiment of the present application; Figure 2 The basic structure diagram of a log audit device based on identity key and business logic cooperative configuration for one specific embodiment of the present application; Figure 3 The basic structure block diagram of a computer device for one specific embodiment of the present application. DETAILED DESCRIPTION

[0018] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, in which the same or similar notations represent the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by reference to the accompanying drawings are exemplary, and are only used to explain the present application, and cannot be interpreted as a limitation on the present application.

[0019] It will be further understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0020] Those skilled in the art will appreciate that the terms used herein, including technical and scientific terms, have meanings commonly used in the art unless otherwise defined. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0021] As those skilled in the art will readily appreciate, the term "terminal" as used herein includes both devices that are solely wireless signal receivers, devices that are solely wireless signal receivers without transmit capability, and devices that have receive and transmit hardware enabling two-way communications over a two-way communications link. Such devices include cellular or other communications devices that have single line or multiple line displays, or no display, Personal Communications Service (PCS) devices that can combine a voice, data processing, facsimile, and / or data communications capabilities, Personal Digital Assistants (PDAs) that can include a radio frequency receiver, pagers, Internet / intranet access, web browsers, organizers, calendars, and / or a Global Positioning System (GPS) receiver, conventional laptop and / or palmtop computers or other devices that have a radio frequency receiver, and / or the like. The term "terminal" as used herein can be a portable, transportable, installed in a vehicle (aeronautical, maritime, and / or land), or situated and / or configured to operate in a local mode, and / or in a distributed mode, to operate in any other location of the Earth and / or in space. The term "terminal" as used herein can also be a communication terminal, an Internet terminal, a music / video playing terminal, such as a PDA, a Mobile Internet Device (MID), and / or a mobile phone with music / video playing function, a smart television, a set-top box, and / or the like.

[0022] The hardware referred to by the names "server", "client", "service node" and the like in the present application is essentially an electronic device with the equivalent capabilities of a personal computer, and is a hardware device with a central processing unit (including an arithmetic unit and a controller), a memory, an input device, and an output device, and the like necessary components disclosed by the von Neumann principle. A computer program is stored in the memory, the central processing unit calls the program stored in the external storage into the memory for running, executes the instructions in the program, and interacts with the input and output devices, thereby completing a specific function.

[0023] It should be noted that the concept of "server" in the present application can also be extended to the case of a server cluster. According to the network deployment principle understood by those skilled in the art, the servers should be logically divided, and in physical space, these servers can be independent of each other but can be called through an interface, or can be integrated into a physical computer or a computer cluster. Those skilled in the art should understand this variation and should not be restricted by the implementation of the network deployment of the present application.

[0024] One or more technical features of the present application, unless explicitly specified, can be deployed on a server for implementation and accessed by a client remotely calling an online service interface provided by the server, or can be directly deployed and run on a client for implementation.

[0025] The AI model referred to or possibly referred to in the present application, unless explicitly specified, can be deployed on a remote server and remotely called by a client, or can be deployed on a client with sufficient device capability for direct calling. In some embodiments, when it is run on a client, its corresponding intelligence can be obtained through transfer learning, so as to reduce the requirement for client hardware running resources and avoid excessive occupation of client hardware running resources.

[0026] The various data involved in the present application, unless explicitly specified, can be remotely stored on a server or stored on a local terminal device, as long as it is suitable for being called by the technical solutions of the present application.

[0027] Those skilled in the art should know that the various methods of the present application, although based on the same concept and described to present commonality among them, are independently executable unless otherwise specified. Similarly, for each embodiment disclosed in the present application, it is based on the same inventive concept, and therefore, for the same concept of expression, and although the concept of expression is different, it is only for the convenience of appropriately transforming the concept, and should be understood as equivalent.

[0028] Unless otherwise indicated herein, the various disclosed embodiments can be combined in any and all permutations. It is intended that the following claims be construed to encompass all such embodiments.

[0029] Please refer to Figure 1 , Figure 1 The basic flowchart of the log auditing method based on the identity key and the business logic cooperative configuration of the present embodiment is shown in the figure.

[0030] As Figure 1 shown, it includes: S1100, configuring an audit policy associated with a specific business operation node in the business logic, the audit policy defining a set of key business data fields to be collected; The present embodiment is applied to business process monitoring and log auditing scenarios in various fields such as finance, insurance, e-commerce, and medical treatment. In the present embodiment, a log auditing system with an audit policy arranged is used for monitoring and log auditing of various business processes. First, an audit policy associated with a specific business operation node is configured in the business logic, and the audit policy defines a set of key business data fields to be collected. For example, in key business fields such as financial transaction systems and medical information systems, when configuring the audit policy, the system administrator first analyzes the business process in depth and identifies key business operation nodes such as the "final approval node" in loan approval and the "patient information query operation node" in medical record access. Then, for these nodes, the visual configuration interface provided by the system or the script language is used to define a set of key business data fields to be collected. For example, in a credit approval system, when the "loan approval pass" operation is performed, the fields of "approver ID, loan ID, approval result, and timestamp" are collected; in a medical information system, the fields of "visitor ID, patient ID, access time, and access purpose" are collected at the "medical record query" operation node. These rules are stored in a configuration file or a database, and when the business logic executes to the corresponding node, the system extracts the corresponding field data according to the preset rules. This method ensures that the collected data accurately reflects the core elements of the business operation and provides detailed evidence for subsequent auditing.

[0031] It should be noted that in an embodiment, a rule engine (such as Drools) is used to implement the configuration of the audit strategy. The system administrator writes and deploys the key business operation nodes and the corresponding set of key business data fields in the form of rules into the rule engine. When the business logic is executed, the rule engine matches the corresponding rules according to the current business state. For example, in a securities trading system, when the transaction amount exceeds a certain threshold, the "large transaction audit" node is triggered, and the rule engine extracts the "transaction account number, transaction amount, transaction time, and audit personnel ID" fields according to the preset rules. The advantage of this approach is the flexibility and scalability of the rules, which can quickly adapt to changes in business rules.

[0032] It should be noted that in another embodiment of the present embodiment, in the business logic code, a custom annotation is used to mark the key business operation nodes, and the set of key business data fields to be collected is defined in the annotation. For example, in the approval service code of a credit approval system, an annotation @AuditStrategy(fields = {"approverId", "loanId", "approvalResult", "timestamp"}) is added to the "loan approval pass" method. When the business logic executes to this method, the annotation information is read through the reflection mechanism, and the corresponding field data is extracted. This approach tightly integrates the audit strategy with the business code, ensuring that the audit requirements are implemented during development, and facilitating developers to directly participate in the configuration of the audit strategy.

[0033] S1200, in response to the execution of the business logic to the specific business operation node, extracting and structuring the set of key business data fields from the current business execution context according to the audit strategy, and generating a to-be-signed data packet; After configuring the audit policy associated with a specific business operation node in the business logic, the audit policy defines the set of key business data fields to be collected, in response to the execution of the business logic to the specific business operation node, the set of key business data fields is extracted and structured from the current business execution context according to the audit policy, and a to-be-signed data packet is generated. Specifically, when the business logic executes to the specific business operation node, the system first identifies the audit policy corresponding to the node. Then, the predefined key business data fields are extracted from the current business execution context through a reflection mechanism or a script analysis method. For example, in a credit approval system developed in Java, the reflection mechanism is used to access the attributes of the current business object to obtain the field values of "approver ID, loan ID, approval result, timestamp", etc. Then, according to the preset data structuring rules (such as JSON or XML format), the field values are encapsulated to generate a structured to-be-signed data packet. Such structured data packet not only contains key business information, but also provides a clear data basis for subsequent digital signature and audit verification in a unified format.

[0034] It should be noted that in an embodiment of the present embodiment, in a system developed in an object-oriented programming language (such as Java, C#), the reflection mechanism is used to implement field extraction. When the business logic executes to the key node, the reflection mechanism dynamically accesses the attributes of the current business object according to the field names defined in the audit policy. For example, in a Java-based medical information system, when executing to the "medical record query" operation node, the reflection mechanism extracts the corresponding values from the attributes of the current business object according to the preset "visitor ID, patient ID, access time, access purpose" field names. The advantage of this method is that it can flexibly cope with changes in business object attributes. As long as the field name remains unchanged, the audit logic code does not need to be modified.

[0035] It should be noted that in an embodiment, the present embodiment can also embed script parsing logic (such as using JavaScript script parsing) in the business logic code, and the script defines how to extract key business data fields from the current business context. For example, in a Web development framework, the current HTTP request and session object are parsed using JavaScript scripts to extract fields such as "user identification, operation time, operation type". The advantage of this approach is that the script is easy to write and modify, and the developer can quickly adjust the field extraction logic according to the business requirements without recompiling the entire business system. In addition, the present embodiment can also deploy middleware between the business system and the data storage system, which intercepts business operation requests and responses to extract key business data fields. For example, in a financial transaction system based on a micro-service architecture, the middleware is deployed between each micro-service and the database. When the middleware detects that the business logic executes to the "funds transfer" operation node, it extracts fields such as "transferor ID, transfer amount, transfer time, and payee ID" from the database operation request. The advantage of this approach is that it is non-intrusive to the business logic code, and the middleware runs independently, allowing data extraction without affecting the normal operation of the business system, while also allowing unified management of data extraction logic for multiple business systems.

[0036] S1300, determine the current operation subject, and obtain the identity private key of the operation subject to perform digital signature operation on the to-be-signed data packet to generate a digital signature value; After responding to the execution of the business logic to the specific business operation node, extracting and structuring the set of key business data fields from the current business execution context according to the audit policy to generate a to-be-signed data packet, determining the current operation subject, and obtaining the identity private key of the operation subject to perform digital signature operation on the to-be-signed data packet to generate a digital signature value, in order to accurately identify the operation subject, the present embodiment is configured to implement the following multiple ways, such as in a financial transaction system, according to the unique identification of the operation account; in a medical information system, according to the work number of medical staff, etc. The identity information of the operation subject is usually stored in the system database or the permission management system. Then, the system needs to securely obtain the identity private key. The private key is generally stored in a secure medium (such as a USB Key, a smart card, or an encryption chip) and is used for digital signature operation through an encryption algorithm (such as RSA, ECDSA, etc.). For example, when using the RSA algorithm, the to-be-signed data packet is converted into a digital digest, and then the private key is used to perform encryption operation on the digest to obtain the digital signature value. In order to ensure the security of the private key, the entire obtaining and signing process is performed in a secure encryption environment (such as a TPM trusted execution environment) to prevent the private key from being leaked. This process provides technical support for the integrity verification and non-repudiation of subsequent logs.

[0037] It should be noted that the embodiment adopts a hardware encryption module (such as an HSM hardware security module) to store the identity private key of the operation subject. When signature is needed, the system sends a data packet to be signed to the HSM, the HSM performs signature operation using the private key in the internal secure environment, and returns a digital signature value. The advantage of this mode is that the private key is always stored in the hardware module and will not be exposed to the external system, effectively preventing the private key from being stolen or misused. For example, in the core transaction system of a bank, the HSM is used to sign the key operation node of each transaction, ensuring the security and non-repudiation of the transaction. The HSM usually has high security authentication and powerful encryption operation capability, and can meet the business requirements of high concurrency and high security.

[0038] It should be noted that the embodiment also combines a joint identity authentication (such as OAuth2.0 or SAML) mechanism. When the operation subject passes the joint authentication, the system obtains a token (Token) containing private key information from an identity provider (IdP). When signing, the token is parsed to extract the private key, and the data packet is signed. This mode facilitates unified identity management and signature operation across systems and platforms. For example, in a cloud-native application, different microservices interact through joint identity authentication, and the private key in the token is used to sign the key business operation node, ensuring the credibility and traceability of the operation.

[0039] S1400, associating and packaging the digital signature value, the data packet to be signed, and the corresponding public key to generate a structured log record; After determining the current operation subject and obtaining the identity private key of the operation subject to perform digital signature operation on the to-be-signed data packet to generate a digital signature value, the digital signature value, the to-be-signed data packet and the corresponding public key are associated and encapsulated to generate a structured log record. Specifically, after completing the digital signature operation, the system enters a critical encapsulation stage. First, the system associates and integrates the digital signature value, the to-be-signed data packet and the public key of the operation subject as main elements according to a predetermined data structure. This embodiment adopts encapsulation in JSON or XML format. For example, when using the JSON format, the digital signature value is mapped to "digitalSignature", the to-be-signed data packet is mapped to "toBeSignedData", the public key is mapped to "publicKey", and a "timestamp" field is added to record the log generation time according to certain key-value pair rules. These elements are integrated in a JSON object to form a complete structured log record. During the encapsulation process, the system performs necessary format conversion and verification on the data to ensure the integrity and consistency of the data. For example, the date and time format is uniformly standardized, and the format of the public key is verified. This encapsulation method not only realizes the structured storage of data, but also provides a clear data format for subsequent log storage, transmission and auditing, facilitating the processing and display of auditing tools.

[0040] It should be noted that, for high-concurrency business systems, in order to improve the response speed and stability of the system, an asynchronous encapsulation and transmission method based on a message queue (such as RabbitMQ or Kafka) is adopted. After the digital signature value is generated, the related data is sent to the message queue. A special consumer process obtains these data from the queue to perform the encapsulation operation of the structured log record. The advantage of this method is that it can decouple the encapsulation operation and the execution of business logic, avoiding the influence of the delay of the encapsulation process on the real-time performance of the business. At the same time, the message queue provides a reliable message transmission mechanism for the transmission of log data, ensuring that the log data will not be lost.

[0041] S1500, output the structured log record to a log stream, and provide a signature verification interface based on the public key certificate for auditing.

[0042] After the structured log record is generated by associating and encapsulating the digital signature value, the data packet to be signed, and the corresponding public key, the structured log record is output to a log stream, and a signature verification interface based on the public key certificate is provided for auditing. Specifically, after the structured log record is generated, the system needs to output it to the log stream for subsequent processing and provide a signature verification interface. In this embodiment, the log stream is configured as a variety of storage or transmission media, such as a log server, a file system, or a console, etc. For example, the system can send the log record to a centralized log management system (such as ELKStack), collect the log through Logstash, store the index through Elasticsearch, and use Kibana for visual display. At the same time, in order to facilitate auditing, the system develops a signature verification interface based on public key verification, which is provided in the form of RESTful API or Web service in this embodiment. Auditors or auditing tools can input the structured log record and the corresponding public key by calling the interface, and the interface internally verifies the digital signature of the log using a digital signature algorithm (such as RSA verification algorithm). The verification process includes using the public key to decrypt the digital signature to obtain a digital digest, recalculating the digital digest of the data packet to be signed, and comparing it with the decrypted digest. If they are consistent, the integrity and authenticity of the log are confirmed. This process ensures that auditors can conveniently verify the credibility of the log, providing a solid foundation for the traceability of business operations and the identification of responsibilities.

[0043] It should be noted that in one embodiment of the present embodiment, a remote signature verification interface based on Web service is constructed, and SOAP or RESTful architecture style is adopted. The system outputs the structured log record to the log database on the Web server and deploys a signature verification service on the server. Auditors access the service through a browser or a special auditing client, upload the log record file to be verified or input the unique identifier of the log record. After receiving the request, the server-side verification service retrieves the corresponding log record from the database, verifies the signature of the log using the public key stored on the server (or obtains the corresponding public key from the public key server), and returns the verification result (such as success or failure, and the specific reason for failure) to the auditing client in XML or JSON format. The advantage of this approach is that auditors do not need to install complex verification tools locally, but can perform verification as long as they have network access, which is suitable for cross-organizational and cross-platform auditing scenarios. For example, in joint audits of financial institutions, auditors from different banks can verify transaction logs through remote Web service, improving audit efficiency and collaboration.

[0044] It should be noted that in another embodiment of the present embodiment, distributed signature verification is implemented on the blockchain platform. After the structured log record is generated, its hash value and related public key information are recorded in the blockchain ledger, while the complete log record can be stored in a distributed storage system (such as IPFS). The system provides a blockchain-based verification interface for auditors, who access the blockchain ledger through a blockchain client or a dedicated blockchain browser to query the hash value of the log record. At the same time, the complete log record is obtained from the distributed storage system, and the log is verified locally using the public key, and the calculated hash value is compared with the hash value on the blockchain. If they are consistent and the signature verification is passed, the authenticity and integrity of the log are doubly confirmed. This way, the tamper-proof and distributed nature of the blockchain enhances the credibility and anti-repudiation of log verification. For example, in the supply chain finance scenario, the transaction log involving multiple participants is verified in this way to ensure that the operation records at each link are real and reliable, and any participant cannot tamper with the log record alone.

[0045] In an actual application scenario, in a financial transaction system, when a risk control manager approves a large loan, the system generates a data package to be signed according to the pre-set audit strategy, extracts the key data fields such as the approval person ID, loan ID, approval result and timestamp at the key node of the loan approval, and generates a data package to be signed. Call the identity private key of the approver to perform digital signature operation on the data package to generate a digital signature value. The signature value, the data package to be signed and the public key are packaged into a structured log record, output to the log stream, and a signature verification interface based on the public key certificate is provided. In this way, in the future audit, the signature of the log record can be verified to ensure that it has not been tampered with, realizing the non-repudiation and integrity of the operation, and effectively solving the problems of low credibility, lack of non-repudiation and lack of business context in traditional log audit in the financial field.

[0046] In the above embodiments, by configuring the audit strategy associated with the specific business operation node in the business logic, the set of key business data fields to be collected is accurately defined, ensuring the pertinence and effectiveness of the collected data, and providing detailed basis for subsequent audit. Secondly, the key business data fields are extracted and structured at the key business node, a to-be-signed data packet is generated, and the identity private key of the operation subject is used for digital signature, effectively guaranteeing the integrity and non-tamperability of the log, and realizing the non-repudiation of the operation, enhancing the credibility of the log. Furthermore, the digital signature value, the to-be-signed data packet and the public key are associated and encapsulated into a structured log record, which is convenient for storage and transmission, and a signature verification interface based on the public key certificate is provided, which is convenient for auditors to verify, improving the audit efficiency and accuracy. In addition, the method is closely combined with the business logic, which can reflect the business scenario and compliance requirements of the operation, overcoming the defects of traditional log audit lacking business context, especially suitable for financial transaction systems, medical information systems and other scenes with high audit requirements, effectively reducing the risk of data leakage and operation denial, meeting the strict requirements of relevant industry regulations, helping to improve the overall security and credibility of the system, and having wide applicability.

[0047] In some embodiments, the to-be-signed data packet is generated in S1200, including: S1211: serializing the extracted set of key business data fields to generate a standardized data block; In this embodiment, when the set of key business data fields is extracted and structured from the current business execution context according to the audit strategy to generate a to-be-signed data packet, the set of extracted key business data fields is first serialized to generate a standardized data block. Serialization is a key process of converting the set of extracted key business data fields into a standardized data block. Taking Java language as an example, the serialization mechanism of Java can be used to convert the object composed of the set of key business data fields into a byte sequence by implementing the Serializable interface. Or use the JSON serialization method to convert the data field set into a JSON format string. For example, the extracted fields such as "loan ID", "approval result" and "timestamp" in loan approval are combined into an object, and the JSON library (such as Jackson or Gson) is used to serialize it into a JSON string. In addition, it is also necessary to ensure that the data format after serialization conforms to the pre-defined standardized specification, such as uniform date format, data type definition, etc. This step provides a structured and standardized data basis for subsequent generation of message digest value and assembly of to-be-signed data packet.

[0048] It should be noted that the embodiment is configured to serialize the extracted set of key business data fields using XML format. With the help of XML serialization library (such as JAXB), the set of data fields is converted into an XML document. For example, in a medical information system, the fields such as "visitor ID", "patient ID", "visit purpose" extracted from the medical record access operation are combined into an object, and serialized into XML format by JAXB. During the serialization process, an XML Schema needs to be defined to ensure that the generated XML document conforms to the standardized specification, including element name, data type, structure level, etc. The advantage of this approach is that XML format has good readability and cross-platform compatibility, and can be converted and displayed through tools such as XSLT.

[0049] S1212: Calculate the message digest value of the standardized data block; After the extracted set of key business data fields is serialized and the standardized data block is generated, the embodiment calculates the message digest value of the standardized data block. The calculation of the message digest value is a key step to ensure data integrity and security. Specifically, the embodiment uses secure hash algorithms such as SHA-256, SHA-3, etc. to calculate the message digest value of the standardized data block. Taking Java language as an example, the MessageDigest class in the Java Security library is used to implement it. First, initialize the MessageDigest object and specify the use of SHA-256 algorithm. Then, the standardized data block generated in step 21 (such as JSON string or byte sequence of XML document) is taken as input, and the update method of MessageDigest is called to perform hash calculation. Finally, the byte array of the message digest is obtained by calling the digest method, and it can be converted into hexadecimal string format for storage and transmission. For example, for a standardized JSON data block of a loan approval operation, the calculated SHA-256 message digest is unique and fixed. As long as the standardized data block does not change, the message digest value remains consistent. This step provides a basis for subsequent data integrity verification, ensuring that any minor tampering during data transmission and storage can be detected.

[0050] It should be noted that the embodiments are configured in different technology stacks, and the calculation methods of the message digest are different. For example, in the Python language environment, the hashlib library can be used. After importing hashlib, a hash object is created using the sha256 function, the byte sequence of the standardized data block is passed in through the update method, and finally the hexdigest method is used to obtain the hexadecimal message digest string. In the C# environment, the SHA256 class under the System.Security.Cryptography namespace can be used to perform hash calculation on the byte sequence through the ComputeHash method. Although the implementation methods of these different languages are different in specific API calls, they are all based on the same hash algorithm principle, ensuring the consistency and interoperability of message digest calculation in cross-platform and cross-language environments, meeting the needs of diverse technology ecosystems.

[0051] S1213: Assemble the message digest value with the preset log header information to generate the final data packet to be signed.

[0052] In this embodiment, after calculating the message digest value of the standardized data block, the message digest value is assembled with the preset log header information to generate the final data packet to be signed. Specifically, the log header information usually contains some metadata, such as log type, log source, log generation timestamp, business operation node identifier, etc. These information can be set through configuration file or system predefined constant. Taking JSON format as an example, first create a JSON object, take the message digest value as one of the fields (such as "messageDigest"), then add each metadata item of the log header information as other fields to the JSON object. For example, add "logType" (log type), "sourceSystem" (log source system), "timestamp" (log generation timestamp) and other fields. Ensure that the values of all fields conform to the predefined data type and format specification, such as the timestamp format is unified as ISO 8601 standard. Finally, serialize this JSON object into a string or byte sequence to form the final data packet to be signed. This JSON format of the data packet to be signed not only has clear structure, but also is easy to extend and maintain, facilitating subsequent digital signature operation and log audit processing.

[0053] It should be noted that in one embodiment of the present embodiment, the data structure is customized according to the business requirements to assemble the data packet to be signed. For example, in a financial transaction system, a binary data structure is defined, the starting part is a fixed length header, which contains log header information such as log version number (2 bytes), operation type code (1 byte), timestamp (8 bytes) and the like, followed by a variable length message digest value area. According to the pre-defined byte order and coding rules, the message digest value is converted into a byte sequence and filled into the specified position. The advantage of this self-defined data structure is that it can be optimized according to the business characteristics, improve the data processing efficiency and reduce the storage space occupation. For example, in a high-frequency trading system, using compact binary format can speed up the generation and processing of logs, and adapt to high-concurrency trading scenarios.

[0054] The present embodiment ensures the integrity, consistency and verifiability of the log data by serializing the set of key business data fields, calculating the message digest value and assembling the data packet to be signed. This processing flow not only enhances the security of the log data in the transmission and storage process, but also effectively prevents data tampering. At the same time, the generation of standardized data blocks and message digests provides a solid foundation for subsequent digital signature, improving the efficiency and credibility of the entire log audit system. In addition, this processing method also facilitates the unified management and audit analysis of log data, which helps to quickly locate and solve potential security problems, and is suitable for various complex application scenarios, especially for industries with high data security requirements.

[0055] In some embodiments, the S1300 obtains the identity private key of the operation subject and performs a digital signature operation, comprising: S1311, a signature challenge request is initiated to the client to which the operation subject belongs, and the request carries the data packet to be signed; In order to ensure the security of the identity private key and the validity of the signature, the signature challenge request is first initiated to the client to which the operation subject belongs, and the to-be-signed data packet is carried in the request. Taking a financial transaction system as an example, when a risk control manager completes a loan approval operation on a client (such as a browser or a mobile APP), the system needs to perform digital signature auditing on the operation. The backend server first generates a unique signature challenge request, which contains a to-be-signed data packet (such as key information of loan approval). The request is sent to the client through the HTTPS protocol to ensure the security of the transmission process. At the same time, the to-be-signed data packet carried in the request is presented in JSON format, which contains an explicit business operation description, facilitating the operation subject to confirm. A short-lived token (Token) is also attached in the request to prevent replay attacks after the request is intercepted. After the client receives the request, the operation subject is prompted to perform identity verification (such as fingerprint recognition or password input) through the interface, ensuring that the operation subject himself participates in the signature process. This design not only ensures the security of the private key, but also enhances the credibility of the signature operation.

[0056] It should be noted that the present embodiment is configured in a modern browser environment, and the signature challenge request is implemented by using the WebAuthn (World Wide Web Authentication) standard. WebAuthn allows the client to perform identity verification through biometric identification (such as fingerprint, facial recognition) or secure key. The backend server uses the WebAuthn API to generate a signature challenge request, which contains a to-be-signed data packet and a public key credential. The client browser interacts with the local secure hardware (such as a fingerprint sensor or a TPM chip) to complete identity verification and sign the data packet using the identity private key. For example, in a bank's online transaction system, when a user uses a browser supporting WebAuthn to perform a large amount of transfer operation, the system initiates a WebAuthn signature challenge request, and the user completes the signature through fingerprint recognition, without the need to input a password, thereby improving user experience and security. The advantage of this way is that it utilizes the native security functions of the browser and the operating system, reducing the dependence on additional security hardware.

[0057] S1312, receiving a digital signature value returned by the client after signing the to-be-signed data packet using the identity private key in the local secure hardware; After the signature challenge request is initiated to the client to which the operation subject belongs, the digital signature value returned by the client after signing the to-be-signed data packet using the identity private key in the local secure hardware is received. Specifically, after receiving the signature challenge request, the client will use the identity private key in the local secure hardware to perform a signature operation on the to-be-signed data packet. Taking a mobile phone APP client with a fingerprint recognition function as an example, after the user verifies the identity through the fingerprint, the security chip (such as TEE trusted execution environment) of the mobile phone will load the identity private key stored therein and perform a signature algorithm (such as ECDSA elliptic curve digital signature algorithm) on the data packet. After the signature is completed, the client returns the generated digital signature value to the server through a secure communication channel (such as HTTPS protocol based on TLS). In the transmission process, in order to ensure the integrity of the data and prevent man-in-the-middle attacks, the digital signature value and related metadata (such as signature timestamp, client device identifier) are encapsulated in a secure message format, for example, JSON Web Signature (JWS) format. The JWS format encodes the signature value and header information using Base64 encoding and combines them into a compact string format through a dot segmentation method, facilitating transmission and verification. After receiving the response, the server side parses the JWS message, extracts the digital signature value and related metadata, and prepares for the subsequent signature verification step. The whole process ensures the secure transmission of the digital signature value and prevents the signature value from being tampered with or intercepted during transmission.

[0058] S1313, verifying the validity of the digital signature value and confirming that it is a legal signature.

[0059] The embodiment verifies the validity of the digital signature value returned after the client uses the identity private key in the local secure hardware to sign the data packet to be signed, and confirms that it is a legal signature. Verifying the validity of the digital signature value is a key link to ensure the credibility of the entire log audit process. After receiving the digital signature value returned by the client, the server first needs to ensure that the signature value has not been tampered with and is indeed generated by a legitimate operation subject. The server stores the public key of each operation subject, which corresponds to the identity private key of the operation subject and is pre-registered and managed in a secure environment. The server uses the public key corresponding to the operation subject identity private key to verify the digital signature. The specific process is as follows: extracting the public key: the server retrieves the corresponding public key from the secure storage according to the identification (such as user ID) of the operation subject; verifying the algorithm: the server calls the signature verification function in the encryption algorithm library (such as OpenSSL), and inputs the data packet to be signed, the digital signature value and the public key; result judgment: if the verification function returns successfully, it is confirmed that the digital signature is valid, indicating that the data has not been tampered with and is indeed signed by the operation subject; otherwise, the signature is invalid, and the log record will be marked as suspicious or rejected. In the implementation process, the server also needs to record the verification result and related logs for subsequent audit and problem troubleshooting. For example, if the verification fails, the server should record the reason for the failure (such as signature mismatch, invalid public key, etc.), and decide whether to trigger an alarm or take other security measures according to the security policy.

[0060] In addition, in order to prevent replay attacks, the server of the embodiment can also check the timestamp or random number in the signature to ensure the timeliness and uniqueness of the signature. This step enhances the security of the entire log audit system, ensuring that only legitimate and unaltered log records can be accepted and stored.

[0061] The present embodiment ensures the security of the private key by initiating a signature challenge request to the client and requiring the client to sign using the identity private key in the local secure hardware, preventing private key leakage and misuse. At the same time, verifying the validity of the digital signature value can confirm the legality of the signature and the integrity of the data, effectively preventing forgery and tampering. This mechanism not only guarantees the authenticity and non-repudiation of log records, but also applies to various application scenarios that require high security, such as financial transactions, medical information systems, etc., ensuring the traceability and responsibility identification of operations, and helping to improve the overall security and compliance of the system.

[0062] In some embodiments, after the S1300 generates the digital signature value, it further includes: S1321, encoding the digital signature value according to the password message syntax standard; In this embodiment, after generating the digital signature value, the digital signature value is encoded according to the Cryptographic Message Syntax Standard. Encoding the digital signature value according to the Cryptographic Message Syntax Standard (such as CMS or PKCS#7) is a key step to ensure interoperability and standardization. Specifically, using the Bouncy Castle library in Java as an example, first create a CMSProcessable object to encapsulate the data packet to be signed. Then use the CMSSignedDataGenerator class to generate a signed data object, load the certificate and private key of the operation subject in the process, and specify the signature algorithm (such as SHA256withRSA). Then call the generate method to generate the CMSSignedData object, which contains the digital signature value encoded according to the CMS standard and related certificate and attribute information. Finally, get the encoded byte array through the getEncoded method, which is the digital signature value encoded according to the Cryptographic Message Syntax Standard. This encoding method ensures that the signature value can be correctly parsed and verified by different systems and tools, and at the same time meets the industry standard, facilitating data exchange and interoperability between different platforms.

[0063] It should be noted that when the present embodiment is applied in the Python environment, the cms module in the cryptography library can be used to realize the CMS encoding of the digital signature value. First, load the private key and certificate of the operation subject, then create a SignedData object, add the data packet to be signed and the certificate information to the object. Specify the signature algorithm (such as SHA-256), and call the signer signature method to sign the data. After signing, convert the SignedData object to a byte sequence using an appropriate encoding method (such as DER). This method provides a simple way for Python developers to realize the CMS encoding of digital signatures, which is suitable for scenarios that require processing of signed data in the Python ecosystem, such as Web backend services or data processing scripts.

[0064] S1322, binding the encoded digital signature value with the corresponding X.509 format digital certificate; Further, after encoding the digital signature value according to the cryptographic message syntax standard, the embodiment binds the encoded digital signature value with the corresponding X.509 format digital certificate. The binding of the encoded digital signature value and the corresponding X.509 format digital certificate is a key link to ensure the verifiability and credibility of the digital signature. The X.509 digital certificate used in the embodiment is a public key certificate that complies with the X.509 standard, issued by a certificate authority (CA), and contains key information such as public key, issuer information, and validity period. Specifically, taking the Java Bouncy Castle library as an example, first load the X.509 digital certificate, which can be obtained from the file system, database, or network as a byte stream, and then use the X509Certificate class to parse the certificate. Next, the encoded digital signature value and the X.509 certificate are packaged into a container object, for example, using the CMSSignedDataGenerator class to add the certificate to the signature data object. In this way, the signature data object not only contains the digital signature value, but also contains the certificate chain used to verify the signature. Finally, the generated signature data object can be serialized into a byte stream for storage or transmission. This approach ensures the binding of the signature value and the certificate, making it easy for the verifier to obtain and use the certificate to verify the authenticity of the signature.

[0065] S1323, time-stamp the bound data with a time authority to obtain a trusted time stamp.

[0066] Further, after binding the encoded digital signature value with the corresponding X.509 format digital certificate, the embodiment performs time stamping on the bound data to obtain a trusted time stamp. Specifically, a hash value is generated for the bound data (including the digital signature value and the X.509 certificate) using a secure hash algorithm such as SHA-256 or SHA-3. Then, a time stamp request message is constructed, which includes the hash value and other necessary information such as the URL of the time stamp server (TSA), user credentials, etc. Next, the time stamp request message is sent to the authoritative time stamp server via HTTPS protocol. Upon receiving the request, the TSA verifies the integrity and legality of the request. After verification, the TSA digitally signs the time stamp containing the hash value and the current accurate time using its own private key, and returns the signed time stamp to the requester. After receiving the time stamp response, the validity of the time stamp needs to be verified. The verification process includes checking whether the TSA's digital signature is valid, whether the hash value in the time stamp is consistent with the hash value of the original data, and whether the certificate of the time stamp server is trustworthy. After verification, the time stamp information is bound with the original data to ensure that the data has not been tampered with at a specific point in time, thereby providing a trusted time proof for log recording. This process enhances the legal effectiveness and traceability of log auditing, ensuring the accuracy and non-repudiation of operation time.

[0067] By encoding the digital signature value according to the Cryptographic Message Syntax Standard, the embodiment ensures the standardization and interoperability of the signature, facilitating identification and verification between different systems. The binding with the X.509 format digital certificate provides identity proof and public key information of the signature subject, ensuring the authenticity and traceability of the signature. The introduction of time stamping provides accurate time proof for the signature data, preventing time tampering of the signature data and ensuring the integrity and timeliness of log recording. These measures collectively enhance the legal effectiveness and anti-repudiation of log auditing, which is of great significance for fields such as finance and medicine that have high requirements for data security and compliance.

[0068] In some embodiments, after outputting the structured log record in S1400, the method further includes: S1411, configuring a real-time alarm strategy based on business rules, the alarm strategy being associated with the key business data fields defined in the audit strategy; In this embodiment, after outputting the structured log records, a business rule-based real-time alerting strategy is also configured for the system, which is associated with the key business data fields defined in the audit strategy. Configuring a business rule-based real-time alerting strategy is an important part of implementing proactive security defense. Specifically, in a financial transaction system, system administrators can define alerting rules associated with key business data fields in a visual configuration interface according to business needs. For example, set the rule: "trigger an alert when the single loan approval amount exceeds 5 million yuan". These rules are stored in a rule engine (such as Drools) and are associated with key business data fields (such as "loan amount") defined in the audit strategy. At the same time, the threshold, frequency and notification method (such as sending an email, a short message or pushing to a monitoring system) of the alert can be set. In this embodiment, the rule engine continuously monitors the key business data fields in the log stream and triggers the alert process when the conditions are met. This configuration method is not only flexible, but also can quickly adjust the alerting strategy according to business changes.

[0069] It should be noted that in this embodiment, in a complex business scenario, intelligent alerting is achieved in combination with a machine learning model. First, historical business data and corresponding alert events are collected, and the data is preprocessed and feature extracted. Then, a suitable machine learning algorithm (such as random forest, neural network) is selected for model training. The trained model can automatically identify abnormal patterns or potential risks according to the key business data fields in the real-time log. For example, in a medical information system, the model can learn the normal behavior patterns of medical staff accessing medical records, and trigger an alert when detecting abnormally high frequency access or access to sensitive medical records. The advantage of this approach is that it can handle complex nonlinear relationships, improving the accuracy and adaptability of the alert.

[0070] S1412, continuously consume the log stream and parse the structured log records therein to extract key business data; Further, in this embodiment, after configuring the real-time alerting strategy based on business rules, the log stream is continuously consumed and the structured log records therein are parsed to extract key business data. Specifically, a message queue system (such as Apache Kafka or RabbitMQ) is used to manage the log stream. Log producers (such as application servers) send generated structured log records to the message queue. Then, a dedicated log consumer service (such as a microservice developed using Spring Boot or Node.js) is deployed to continuously consume log data by subscribing to the log topic in the message queue. During the consumption process, the structured log records are parsed into objects or data structures in the program using JSON or XML parsing libraries. According to the preset mapping rules, the key business data fields (such as loan amount, transaction type, etc.) related to the alerting strategy are extracted from the parsed objects. To improve processing efficiency, multi-threading or asynchronous processing mechanisms can be used, and the consumption progress is persistently stored to prevent data loss. The parsed key business data is stored in an in-memory buffer or a temporary database for subsequent real-time analysis and alerting judgment.

[0071] S1413, when the extracted data triggers the alerting strategy, a real-time security alert notification is generated and pushed.

[0072] Further, in this embodiment, after continuously consuming the log stream and parsing the structured log records to extract key business data, when the extracted data triggers the alerting policy, real-time generation and pushing of security alert notifications are generated. Specifically, the system needs to monitor the parsed key business data in real time and match it with the preset alerting policy. Once a match is successful, i.e., the data meets the alerting conditions, the system immediately triggers the alerting process. This embodiment is implemented through a real-time analysis and monitoring module that continuously polls or listens to changes in key business data. When an alert is triggered, the system generates an alert notification object containing detailed information such as alert time, triggered alert rule, related business data field values, and possible impact range. This information is crucial for quickly locating and resolving potential security issues. Then, the system calls the notification service to push the alert notification. The notification service can send notifications through various channels such as email, SMS, instant messaging tools (such as Slack or WeChat Enterprise), or trigger sound / visual alarms according to the preset alerting policy configuration. For example, in a financial transaction system, if an abnormal large transaction is detected, the system can immediately send an SMS notification to the security team and pop up a visual alarm on the monitoring interface. To ensure the reliability and timeliness of notifications, the notification service usually has a retry mechanism and backup notification channels. If the primary channel fails, the system will automatically switch to the backup channel to ensure that the alert information can be timely communicated to relevant personnel. In addition, the system also records all alert events and notification sending states for subsequent auditing and analysis. This real-time alerting mechanism can significantly improve the security and response capabilities of the system, reducing potential security risks.

[0073] In this embodiment, by configuring real-time alerting policies based on business rules, the system can actively identify potential security risks or abnormal operations. Continuous consumption of log streams and parsing of key business data ensures the timeliness and accuracy of monitoring. When the alerting policy is triggered, real-time generation and pushing of security alert notifications are generated, allowing relevant personnel to quickly take measures to prevent potential security incidents from expanding. This mechanism not only improves the security and reliability of the system, but also enhances the continuity and compliance of the business, especially suitable for industries with high real-time requirements such as financial transaction monitoring and medical information system security.

[0074] In some embodiments, the 1413 real-time generation and pushing of security alert notifications include: S1421: Dynamically generating alert details containing associated log record digital signature values according to the triggered alerting policy level; In this embodiment, in the process of generating and pushing security alert notifications in real time, the system dynamically generates alert details containing the associated log record digital signature value according to the triggered alert policy level. Specifically, first, the system needs to define different levels of alert policies (such as low, medium, high, and urgent), each policy level corresponds to different notification templates and processing procedures. When a log record triggers a specific alert policy, the system will retrieve the log record and its associated digital signature value from the log database according to the predefined mapping relationship. Then, use the template engine (such as Thymeleaf or FreeMarker) to dynamically generate the alert details page or message content. In the template, placeholders are reserved for inserting key information of the log record (such as operation time, operation subject, business data field, etc.) and digital signature value. In addition, the unique identifier of the log record and the signature verification link or two-dimensional code can also be included in the alert details, so that the recipient can quickly verify the integrity and authenticity of the log. Finally, the generated alert details are stored in a temporary buffer, ready to be pushed to the relevant recipients through subsequent steps.

[0075] It should be noted that in the Web-based application scenario, this embodiment uses a Web framework (such as Spring MVC or Django) to implement dynamic alert detail generation. When an alert is triggered, the backend service selects the corresponding HTML template according to the alert policy level, fills in the log record and digital signature value into the template. The generated HTML content can be pushed to the front-end page in real time through WebSocket, or generated as an independent HTML email sent to the relevant personnel. The advantage of this approach is that it can take full advantage of the rich presentation forms of Web technology, such as charts, links, and interactive elements, making the alert details more intuitive and easy to understand. At the same time, the Web service can be integrated with the existing identity authentication and authorization system to ensure that only authorized personnel can view sensitive alert details.

[0076] S1422: Push the alert details to the security operation center and the terminal device of the person in charge of the operation subject through the pre-integrated multiple channels at the same time; In this embodiment, after dynamically generating the alarm details containing the associated log record digital signature value according to the triggered alarm policy level, the alarm details are pushed to the security operation center and the terminal equipment of the person in charge of the operation subject through multiple pre-integrated channels at the same time. Specifically, the system adopts a multi-channel integration strategy to ensure efficient communication of alarm notifications. First, the alarm details are sent to the security operation center through enterprise message middleware (such as RabbitMQ or Kafka), and the monitoring system of the operation center (such as ELK Stack or Splunk) subscribes to the corresponding queue to receive and display alarm information in real time. At the same time, a mail server (such as SendGrid or Amazon SES) is used to send emails to relevant persons in charge, ensuring that key personnel can receive notifications even if they are not on instant messaging platforms. For more direct access, the system integrates a short message gateway (such as Twilio) for sending short message alarms and a push service (such as Firebase Cloud Messaging or Apple Push Notification Service) for sending push notifications to mobile devices. All channels use secure transmission protocols (such as TLS) to ensure data security and asynchronous processing mechanisms to ensure the timeliness of alarm pushing. When configuring alarm policies, the system can select appropriate combinations of push channels based on the urgency of the alarm and business rules to ensure that alarm notifications in different environments can quickly reach the target recipients.

[0077] S1423: Embed a quick verification interface in the alarm notification, and the recipient can trigger online verification of the integrity and authenticity of the associated log record with one key.

[0078] In this embodiment, after the alarm details are pushed to the security operation center and the terminal device of the responsible person of the operation subject through the pre-integrated multiple channels, a quick verification interface is embedded in the alarm notification, and the receiver can trigger online verification of the integrity and authenticity of the associated log record with one key. First, the system generates a unique verification link, which contains the unique identifier of the log record, the digital signature value and the associated public key information (or the address of the public key). This link points to a secure online verification service interface, which can be a verification service of the system itself or a third-party verification service. The verification link usually uses HTTPS protocol to ensure the security of data transmission. When generating the alarm notification, the verification link is embedded in the notification content, such as adding a "click here to verify the authenticity of the log" button or link in the email body, providing a short link address in the SMS, and attaching the verification link in the push notification. In addition, a two-dimensional code containing the verification link information can also be generated to facilitate the receiver to quickly access the verification page by scanning the code with a mobile phone. When the receiver clicks the verification link, the browser or mobile device will open the verification service page. The verification service receives the log unique identifier and digital signature value in the request, retrieves the corresponding log record and public key from the log storage system. Then, the verification service calls the signature verification algorithm to verify the log record using the public key, checks its integrity and authenticity. The verification result is immediately displayed on the page, informing the receiver whether the log record has been tampered with and whether the signature is valid.

[0079] In this embodiment, by dynamically generating alarm details containing digital signature values according to alarm levels, the accuracy and integrity of alarm information are ensured. The multi-channel push mechanism ensures that the alarm can reach the security operation center and the relevant responsible person in time, reducing the response time. The embedded quick verification interface allows the receiver to verify the authenticity of the log with one key, simplifying the verification process and enhancing trust. This mechanism not only speeds up the processing of security incidents, but also effectively prevents false alarms based on tampered logs, ensuring the security and reliability of the system, especially suitable for scenarios that require quick decision-making and high trust.

[0080] In some embodiments, after the S1400 outputs the structured log record, it further includes: S1431: periodically upload batch log records to the IPFS distributed storage network; In this implementation, after outputting structured log records, batch log records are also periodically uploaded to the IPFS distributed storage network. Specifically, the system needs to determine the upload period of log records (e.g., upload once an hour or once a day), which can be set through a configuration file or management interface. Then, the generated structured log records are collected and packaged into batches. During packaging, log records can be compressed to reduce storage space and upload bandwidth. Next, the IPFS client library (such as js-IPFS or go-IPFS) is used to interact with the IPFS node. The packaged log batch file is uploaded to the IPFS network through the add method of the IPFS client. IPFS will return a content identifier (CID), which is a hash value generated based on the content of the log file, ensuring the uniqueness and verifiability of the file. The system needs to record this CID and the corresponding log batch information (such as time range, log quantity, etc.) in order to record the CID into the blockchain smart contract later.

[0081] S1432: Record the content identifier returned by IPFS into the blockchain smart contract. In this embodiment, after periodically uploading batch log records to the IPFS distributed storage network, the content identifier returned by IPFS is recorded into the blockchain smart contract. First, select a suitable blockchain platform (such as Ethereum, Hyperledger Fabric, etc.) to deploy the smart contract. The smart contract needs to define a data structure to store the CID of the log batch and related metadata (such as upload time, batch number, etc.). After step 71 completes log upload and obtains CID, the system calls the corresponding function of the smart contract, passing CID and other metadata as parameters to the smart contract. The smart contract will verify the authority of the caller (e.g., whether it is an authorized log management system), and after verification, record these information on the blockchain. The non-tamperable nature of the blockchain ensures that once the CID is written, it cannot be modified, thereby guaranteeing the long-term integrity of the log records.

[0082] S1433: Generate verifiable storage proof credentials based on zero-knowledge proof technology.

[0083] In this embodiment, after recording the content identifier returned by IPFS into the blockchain smart contract, a verifiable storage proof certificate is generated based on zero-knowledge proof technology. Zero-knowledge proof is a technology that allows one party (prover) to prove to another party (verifier) that a certain statement is correct without revealing any other information. In this step, the system uses a zero-knowledge proof library (such as zk-snarks library) to generate a storage proof. The prover (log storage system) creates a zero-knowledge proof based on the CID and log batch information recorded in the smart contract, proving that these log records are indeed stored on IPFS and have not been tampered with. This proof process does not require disclosure of the specific content of the log records, protecting the privacy of the data. The generated storage proof certificate can include the proof itself, related public key parameters, and other information required by the verification algorithm. The verifier (such as an auditor or regulatory authority) can use these credentials to verify the storage integrity of the log records without accessing the complete log data. This way enhances the security and credibility of log storage while meeting privacy protection requirements.

[0084] In this embodiment, by periodically uploading batch log records to the IPFS distributed storage network, the decentralized and content-addressed features are used to ensure the durability and tamper resistance of log data. Then, the content identifier returned by IPFS is recorded in the blockchain smart contract, and the tamper-proof nature of the blockchain is used to further enhance the credibility and transparency of the log records. In addition, based on zero-knowledge proof technology, a verifiable storage proof certificate is generated, allowing auditors to verify the integrity of the logs without revealing sensitive information, effectively protecting data privacy. This combination of IPFS and blockchain technology not only improves the security of log storage, but also provides a reliable solution for long-term archiving and auditing, especially suitable for financial, medical and other fields with high requirements for data integrity and privacy, with important application value and wide applicability.

[0085] For details, please refer to Figure 2 , Figure 2 The basic structure of the log auditing device based on identity key and business logic collaborative configuration in this embodiment is shown in the figure.

[0086] As Figure 2As shown, a log auditing device based on identity key and business logic collaborative configuration includes: a policy definition module 1100 configured in the business logic to configure an audit policy associated with a specific business operation node, the audit policy defining a set of key business data fields to be collected; a field extraction module 1200 configured to extract and structure the set of key business data fields from the current business execution context according to the audit policy in response to the business logic execution to the specific business operation node, and generate a to-be-signed data packet; a digital signature module 1300 configured to determine the current operation subject and obtain the identity private key of the operation subject to perform a digital signature operation on the to-be-signed data packet to generate a digital signature value; a log generation module 1400 configured to associate and encapsulate the digital signature value, the to-be-signed data packet and the corresponding public key to generate a structured log record; and a log verification module 1500 configured to output the structured log record to a log stream and provide a signature verification interface based on the public key certificate for auditing.

[0087] The log auditing device based on identity key and business logic collaborative configuration described above defines a set of key business data fields to be collected accurately by configuring an audit policy associated with a specific business operation node in the business logic, ensures the pertinence and effectiveness of the collected data, and provides detailed basis for subsequent auditing. Secondly, the key business data fields are extracted and structured at the key business node to generate a to-be-signed data packet, and the identity private key of the operation subject is used for digital signature, which effectively guarantees the integrity and non-tamperability of the log, realizes the non-repudiation of the operation, and enhances the credibility of the log. Furthermore, the digital signature value, the to-be-signed data packet and the public key are associated and encapsulated into a structured log record, which is convenient for storage and transmission, and a signature verification interface based on the public key certificate is provided, which facilitates the verification of the auditors and improves the auditing efficiency and accuracy. In addition, the method is closely combined with the business logic, can reflect the business scenario and compliance requirements of the operation, overcomes the defects of the traditional log auditing lacking business context, is especially suitable for scenes such as financial transaction systems and medical information systems which have high requirements for auditing, effectively reduces the risks of data leakage and operation repudiation, meets the strict requirements of relevant industry regulations, helps to improve the overall security and credibility of the system, and has wide applicability.

[0088] To solve the above technical problems, the embodiment of the present application also provides a computer device. For details, please refer to Figure 3 , Figure 3 The basic structure block diagram of the computer device of the present embodiment is shown in the figure.

[0089] As Figure 3As shown, the internal structure diagram of the computer device is shown. The computer device includes a processor, a non-volatile storage medium, a memory and a network interface connected by a system bus. Among them, the non-volatile storage medium of the computer device stores an operating system, a database and computer readable instructions, and the control information sequence can be stored in the database. The processor of the computer device is used to provide computing and control capability to support the operation of the entire computer device. The memory of the computer device can store computer readable instructions, which when executed by the processor, can cause the processor to execute a log audit method based on identity key and business logic cooperative configuration. The network interface of the computer device is used to connect and communicate with the terminal. Those skilled in the art can understand, Figure 3 The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. The specific computer device can include more or fewer components than those shown in the figure, or combine certain components, or have a different component arrangement.

[0090] The processor in the embodiment is used to execute Figure 2 The functions of the policy definition module 1100, the field extraction module 1200, the digital signature module 1300, the log generation module 1400 and the log verification module 1500 in the embodiment are to define the key business data field set to be collected accurately by configuring the audit policy associated with the specific business operation node in the business logic, to ensure the pertinence and effectiveness of the collected data, and to provide detailed basis for subsequent audit. Secondly, the key business data field is extracted and structured at the key business node, a to-be-signed data packet is generated, and the identity private key of the operation subject is used for digital signature, which effectively guarantees the integrity and non-tamperability of the log, realizes the non-repudiation of the operation, and enhances the credibility of the log. Furthermore, the digital signature value, the to-be-signed data packet and the public key are associated and encapsulated into a structured log record, which is convenient for storage and transmission, and provides a signature verification interface based on the public key certificate, which is convenient for auditors to verify and improves the audit efficiency and accuracy. In addition, the method is closely combined with the business logic, can reflect the business scenario and compliance requirements of the operation, overcomes the defect that the traditional log audit lacks business context, is especially suitable for scenes such as financial transaction systems and medical information systems which have high requirements for audit, effectively reduces the risk of data leakage and operation repudiation, meets the strict requirements of relevant industry regulations, helps to improve the overall security and credibility of the system, and has wide applicability.

[0091] The present application also provides a storage medium storing computer readable instructions, which when executed by one or more processors, causes the one or more processors to execute the steps of the log audit method based on identity key and business logic cooperative configuration described in any of the above embodiments.

[0092] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a computer readable storage medium. When the program is executed, it can include the processes of the above-mentioned embodiment methods. The storage medium can be a non-volatile storage medium such as a magnetic disc, an optical disc, a read-only memory (ROM), or a random access memory (RAM).

[0093] Those skilled in the art can understand that the steps, measures, and schemes in the various operations, methods, and processes discussed in the present application can be alternated, changed, combined, or deleted. Further, other steps, measures, and schemes in the various operations, methods, and processes discussed in the present application can also be alternated, changed, rearranged, decomposed, combined, or deleted. Further, the steps, measures, and schemes in the prior art with the various operations, methods, and processes disclosed in the present application can also be alternated, changed, rearranged, decomposed, combined, or deleted.

[0094] The above only describes some embodiments of the present application. It should be noted that those skilled in the art can make several improvements and refinements without departing from the principles of the present application, and these improvements and refinements should also be considered within the scope of protection of the present application.

Claims

1. A log auditing method based on the collaborative configuration of identity keys and business logic, characterized in that, include: Configure an audit strategy associated with a specific business operation node in the business logic. The audit strategy defines the set of key business data fields to be collected. In response to the execution of business logic reaching the specific business operation node, the key business data field set is extracted and structured from the current business execution context according to the audit strategy to generate a data packet to be signed; The current operating entity is identified, and the private key of the operating entity is obtained to perform a digital signature operation on the data packet to be signed, generating a digital signature value; The digital signature value, the data packet to be signed, and the corresponding public key are associated and encapsulated to generate a structured log record; The structured log records are output to a log stream, and a signature verification interface based on the public key credentials is provided for auditing.

2. The log auditing method based on the collaborative configuration of identity keys and business logic according to claim 1, characterized in that, The generation of the data packet to be signed includes: The extracted set of key business data fields is serialized to generate standardized data blocks. Calculate the message digest value of the standardized data block; The message digest value is assembled with preset log header information to generate the final data packet to be signed.

3. The log auditing method based on the collaborative configuration of identity keys and business logic according to claim 1, characterized in that, The step of obtaining the private key of the operating entity and performing digital signature calculation includes: A signature challenge request is sent to the client to which the operating entity belongs, the request carrying the data packet to be signed; The receiving client signs the data packet to be signed using its identity private key stored in its local security hardware, and returns the digital signature value thereon. Verify the validity of the digital signature value and confirm that it is a legitimate signature.

4. The log auditing method based on the collaborative configuration of identity keys and business logic according to claim 1, characterized in that, After generating the digital signature value, the process also includes: The digital signature value is encoded according to the cryptographic message syntax standard; Bind the encoded digital signature value to the corresponding X.509 format digital certificate; Authoritative timestamp authentication is performed on the bound data to obtain a trusted timestamp.

5. The log auditing method based on the collaborative configuration of identity keys and business logic according to claim 1, characterized in that, Following the output of the structured log record, the following is also included: Configure a real-time alarm policy based on business rules, wherein the alarm policy is associated with key business data fields defined in the audit policy; Continuously consume the log stream and parse the structured log records to extract key business data; When the extracted data triggers the alarm policy, a security alarm notification is generated and pushed in real time.

6. The log auditing method based on the collaborative configuration of identity keys and business logic according to claim 5, characterized in that, The real-time generation and push of security alert notifications includes: Based on the triggered alarm policy level, dynamically generate alarm details including the digital signature value of the associated log record; Alarm details are simultaneously pushed to the security operations center and the terminal devices of the person in charge of the operation through multiple pre-integrated channels; By embedding a quick verification interface in the alarm notification, the recipient can trigger online verification of the integrity and authenticity of the associated log records with one click.

7. The log auditing method based on the collaborative configuration of identity keys and business logic according to claim 1, characterized in that, Following the output structured log record, the following is also included: Regularly upload batch log records to the IPFS distributed storage network; Record the content identifier returned by IPFS into the blockchain smart contract; Generate verifiable stored proof credentials based on zero-knowledge proof technology.

8. A log auditing device based on the collaborative configuration of identity keys and business logic, characterized in that, include: The strategy definition module is used to configure audit strategies associated with specific business operation nodes in the business logic. The audit strategy defines the set of key business data fields to be collected. The field extraction module is used to extract and structure the set of key business data fields from the current business execution context in response to the execution of business logic to the specific business operation node, and generate a data packet to be signed according to the audit strategy. The digital signature module is used to determine the current operating entity and obtain the identity private key of the operating entity to perform digital signature operation on the data packet to be signed, and generate a digital signature value; The log generation module is used to associate and encapsulate the digital signature value, the data packet to be signed, and the corresponding public key to generate structured log records. The log verification module is used to output the structured log records to the log stream and provide a signature verification interface based on the public key credential for auditing.

9. A computer device, characterized in that, The system includes a memory and a processor, wherein the memory stores computer-readable instructions that, when executed by the processor, cause the processor to perform the steps of the log auditing method based on identity key and business logic co-configuration as described in any one of claims 1 to 7.

10. A storage medium storing computer-readable instructions, characterized in that, When the computer-readable instructions are executed by one or more processors, the one or more processors perform the steps of the log auditing method based on the collaborative configuration of identity keys and business logic as described in any one of claims 1 to 7.

Images