Log management method and device, electronic equipment and computer program product

Abstract

The application discloses a log management method and device, electronic equipment and computer program product, and relates to the technical field of audit log management, and even if an attacker attempts to modify the generated log, the hash chain mechanism in the TEE can guarantee the security of the original log and the accuracy of the historical record, a digital certificate is generated by using a VC mechanism to obtain a VC, the VC can maliciously prove that the source of the log is credible, and the log content can be ensured to be not tampered with in the transmission and storage process.

Description

Technical Field

[0001] This application relates to the field of audit log management technology, and in particular to a log management method, apparatus, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] In the wave of digital transformation, the IT infrastructure of enterprises and organizations is becoming increasingly complex, exhibiting a typical pattern of private cloud, hybrid cloud, and multi-cloud coexistence. In this distributed environment, auditing and tracing the behavior of resources such as computing power, network, and storage are core aspects of ensuring system security, meeting compliance requirements, troubleshooting, and determining responsibility.

[0003] However, if an attacker compromises the system and tampers with the locally cached logs, the logs will be less reliable, and subsequent audits based on the logs will also be less trustworthy. Summary of the Invention

[0004] This application provides a log management method, apparatus, electronic device, computer-readable storage medium, and computer program product to at least solve the problem in the related art that if an attacker attacks the system and tamperes with the locally cached logs, the logs will have poor reliability, and the subsequent auditing based on the logs will also have poor reliability.

[0005] This application provides a log management method, comprising: acquiring events during business processing; generating logs based on the events in a trusted execution environment; when there are multiple logs, linking the multiple logs using the hash value of the logs to obtain a hash chain of the multiple logs; generating a verifiable credential of the hash chain using a verifiable credential mechanism to obtain a digital credential, wherein the digital credential is used to verify the authenticity and integrity of the logs, and the digital credential is also used to enable the traceability of the logs.

[0006] This application also provides a log management device, comprising: a first acquisition unit for acquiring events during business processing; a first generation unit for generating logs based on the events in a trusted execution environment; a linking unit for linking multiple logs using the hash value of the logs to obtain a hash chain of the multiple logs when there are multiple logs; and a second generation unit for generating a verifiable credential of the hash chain using a verifiable credential mechanism to obtain a digital credential, wherein the digital credential is used to verify the authenticity and integrity of the logs, and the digital credential is also used to enable the traceability of the logs.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described log management methods when executing the computer program.

[0008] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described log management methods.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described log management methods.

[0010] This application provides a hardware-level isolated and protected area for the TEE (Trusted Execution Environment), ensuring that the code and data running within it cannot be illegally accessed or tampered with by external software (including operating systems and virtual machine monitors). By generating logs within the TEE, the originality and integrity of the logs at the source can be ensured. Even if other parts of the system are compromised, attackers cannot tamper with the logs within the TEE. Each newly generated log has its hash value calculated within the TEE, and the hash value of the previous log is used as the field value of the current log, forming a chain-like log hash chain. This chain structure is immutable; any modification to the log content will cause its hash value to change, thereby breaking the continuity of the chain, making tampering easily detectable in subsequent verification. Therefore, even if an attacker attempts to modify the generated logs, the hash chain mechanism within the TEE can guarantee the security of the original logs and the accuracy of historical records. A digital certificate is generated using the VC mechanism, resulting in the VC. The VC can maliciously prove that the source of the log is trustworthy and can also ensure that the log content has not been tampered with during transmission and storage. Attached Figure Description

[0011] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a hardware structure block diagram of an execution log management method according to an embodiment of this application;

[0013] Figure 2 This is a flowchart illustrating a log management method according to this application;

[0014] Figure 3 This is a schematic diagram of the framework of this application;

[0015] Figure 4 This is a schematic diagram of the structure of a log management device according to this application. Detailed Implementation

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

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

[0018] Existing auditing and tracing technologies face a series of profound challenges when dealing with complex scenarios that are cross-domain, highly dynamic, and highly adversarial.

[0019] Existing technologies mainly include the following categories:

[0020] 1. Centralized Log Management Systems: Represented by the ELK (Elasticsearch, Logstash, Kibana) technology stack, Splunk, or various Security Information and Event Management (SIEM) platforms. These systems collect logs by deploying agents on various nodes and then aggregate them onto a centralized storage and analysis platform. Their advantages lie in powerful data aggregation, indexing, querying, and visualization capabilities. However, their core weakness lies in the fragility of the "trust chain." Log collection agents typically run in privileged mode on the host operating system (OS) or virtual machine (VM). Once the OS or hypervisor is compromised by an attacker, the attacker can easily stop the agent, tamper with or delete locally cached logs, or even forge fake logs to send to the central platform. Even if the central platform itself is secure, it cannot guarantee that the received logs are original, complete, and untampered, posing a fundamental risk of "garbage in, garbage out."

[0021] 2. Log systems based on simple signatures: To address the tampering problem, some systems have introduced log signing mechanisms. This means that logs are digitally signed by an entity when they are generated. However, this also faces the problem of the root of trust: where is the private key used for signing stored? If the private key is stored in a non-isolated software environment along with the log broker, an attacker who compromises the system can also steal the private key and use it to sign forged logs, rendering the signing mechanism ineffective.

[0022] 3. Blockchain-based Auditing Solutions: In recent years, some technical solutions have attempted to leverage the immutability of blockchain to store audit logs. Writing the original logs or their hashes directly to the blockchain can indeed effectively prevent data tampering after it's uploaded. However, these solutions face several major bottlenecks: First, they also fail to address the "garbage in, garbage out" trust problem at the source. If the uploaded logs themselves have been tampered with, then the blockchain is only protecting a false "fact." Second, blockchain's transaction throughput (TPS) is limited and transaction costs are high, making it unable to handle the massive amounts of log data generated by modern IT systems. Directly uploading large amounts of original logs to the blockchain is not feasible in terms of performance and cost. Finally, there is an inherent contradiction between the blockchain's transparent nature and the sensitive information commonly found in audit logs; direct uploading could lead to serious data privacy breaches.

[0023] The closest existing technology to this application can be seen as a simple combination of "log signing" and "blockchain notarization". Specifically, it involves software signing the log at the log generation end, and then uploading the hash of the signed log to a consortium blockchain or public blockchain for notarization.

[0024] The differences and shortcomings between this technical solution and the present application are as follows:

[0025] 1. Lack of Root of Trust: In existing technologies, signature keys are typically stored in a regular file system or memory, lacking hardware-level security protection. This application addresses the issue of log source trust by running a log broker in a Trusted Execution Environment (TEE) and utilizing a remote authentication mechanism to anchor the root of trust in CPU hardware that cannot be compromised by software.

[0026] 2. Insufficient Standardization and Privacy Protection of Cross-Domain Evidence: Existing technologies typically process log hashes directly, lacking a standardized evidence carrier suitable for cross-domain transfer. This application introduces the W3C standard Verifiable Credential (VC), abstracting the complex log chain into a lightweight, independently verifiable, and interoperable "digital evidence unit." More importantly, this application incorporates selective disclosure technology, allowing the proof of certain facts without exposing all details, perfectly balancing the needs of cross-domain auditing and privacy protection—a deficiency in existing technologies.

[0027] 3. Systematicity and Feasibility: Existing technologies often provide solutions for single points, while this application offers a systematic, end-to-end solution covering the entire process from trust collection, cross-domain storage, joint auditing to lifecycle management. It not only defines the technical framework but also delves into numerous implementable and operational details such as trusted timestamps, cross-domain sequence reconstruction, audit query languages, evidence packaging, and compliance pattern libraries, forming a system far more complete and robust than a simple combination of technologies.

[0028] In summary, existing technologies may not be able to guarantee the authenticity of log sources, or they may compromise between cross-domain sharing, privacy protection, system performance, and cost. This application addresses this technological gap by constructing a truly end-to-end trusted cross-domain auditing and traceability system that balances privacy and efficiency through systematic innovation.

[0029] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0030] The specific application environment architecture or specific hardware architecture on which the log management method depends is described here.

[0031] The methods and embodiments provided in this application can be executed on a server device or a similar computing device. Taking running on a server device as an example, Figure 1 This is a hardware structure block diagram of log management according to an embodiment of this application. For example... Figure 1 As shown, the server device may include one or more ( Figure 1 Only one is shown in the image. A processor 102 (which may include, but is not limited to, a central processing unit (CPU), microprocessor (MCU), or programmable logic device (FPGA), etc.) and a memory 104 for storing data are also shown. The server device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the server device. For example, the server device may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0032] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the log management method in this embodiment. The processor 102 executes various functional applications and data processing, i.e., the implemented method, by running the computer program stored in the memory 104. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to server devices via a network. Examples of networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0033] Transmission device 106 is used to receive or send data via a network. Specific examples of the network may include a wireless network provided by a communication provider for the server device. In one example, transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0034] The embodiments of this application provide a log management method, and the method is described in detail in conjunction with the execution flow of the log management method.

[0035] The following explains the technical terms used in this application:

[0036] TEE (Trusted Execution Environment): A secure region isolated within the main processor, providing confidentiality and integrity protection for the code running and the data processed within it.

[0037] VC (Verifiable Credential): A standardized, tamper-proof, cryptographically verifiable digital credential used to carry claim information and is the core evidentiary unit for cross-domain transfer in this application.

[0038] SGX (Software Guard Extensions): A Trusted Execution Environment (TEE) technology, specifically a type of TEE.

[0039] JSON-LD (JavaScript Object Notation for Linked Data): A JavaScript object notation for linked data. It's a JSON-based data format that adds semantic context to data, making it easier for machines to understand and interoperate. It's the foundation of the W3C-recommended VC data model.

[0040] BFT (Byzantine Fault Tolerance): A consensus algorithm feature of distributed systems that allows the system to reach correct consensus even when some nodes (Byzantine nodes) experience arbitrary failures (including malicious behavior).

[0041] TSA (Trusted Timestamping Authority): A trusted timestamping service. An authoritative third-party organization, based on standards such as RFC3161, provides data with a verifiable and precise timestamp bearing an authoritative signature, proving that the data existed at a certain point in time.

[0042] API (Application Programming Interface): A standardized set of functions, protocols, and tools provided by a system or component for interaction and invocation by external applications.

[0043] KMS (Key Management Service): A system for centrally managing the lifecycle of cryptographic keys, including key creation, storage, distribution, rotation, and destruction.

[0044] RBAC (Role-Based Access Control): A permission management model that controls user access to resources by assigning different roles to users and granting corresponding permissions to those roles.

[0045] WORM (Write Once, Read Many): A data storage feature that ensures data cannot be modified or deleted once it is written. It is often used in archiving and compliance scenarios.

[0046] This embodiment provides a log management method. Figure 2 This is a flowchart of a log management method according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0047] Step S202: Obtain events during the business processing;

[0048] First, it's essential to capture and collect various security-related events generated during business processes. These events cover all aspects of system operation, including but not limited to virtual machine operations, container activity, user logins, permission changes, and API calls. By comprehensively capturing business events, the log management method ensures coverage of all business operations, providing a comprehensive evidentiary basis for subsequent auditing and tracing. The reason for this technical success is that the comprehensive capture of business events reflects the true activity state of the system, providing accurate source data for subsequent chained log generation and VC mechanisms.

[0049] Step S204: Generate logs based on events in a trusted execution environment;

[0050] The log broker runs within a Trusted Execution Environment (TEE) on the computing node. This TEE (e.g., Intel SGX or AMD SEV) provides hardware-level isolation and protection, ensuring that the log broker and the generated logs are not affected by unauthorized software or malicious attacks. Generating logs using a TEE environment guarantees the security of the log source, preventing tampering or forgery during the generation stage. This is because the code and data within the TEE are protected at the hardware level; even if the operating system or virtualization software is compromised, the data within the TEE cannot be accessed, thus guaranteeing the authenticity and integrity of the logs.

[0051] Step S206: When there are multiple logs, the hash values ​​of the logs are used to link the multiple logs to obtain a hash chain of multiple logs;

[0052] When a system has multiple consecutively generated logs, by calculating the hash value of each log entry and using the hash value of the previous log entry as the previous_log_hash field value of the current log entry, an irreversible chain structure or hash chain is formed, ensuring the continuity and integrity of the log sequence. The construction of the hash chain provides a powerful detection capability for log tampering because any modification to historical logs will cause a change in the hash value, disrupting the continuity of the entire chain and making tampering extremely easy to detect. This is because the hash chain utilizes the property of cryptographic hash functions: a small change in the input data will lead to a large difference in the output hash value, thus effectively detecting and preventing any attempt to tamper with the logs.

[0053] Step S208: A verifiable credential for a hash chain is generated using a verifiable credential mechanism to obtain a digital credential. The digital credential is used to verify the authenticity and integrity of the log and is also used to enable log traceability.

[0054] By encapsulating the constructed hash chain or its digest information into a Verifiable Certificate (VC), and digitally signing it using a TEE-protected key within a TEE, the generated digital certificate not only verifies the source and credibility of the log, but also allows for cross-domain sharing and auditing of logs in a standardized form. The introduction of the VC mechanism significantly enhances the verifiability and traceability of logs, ensuring interoperability and privacy protection in cross-domain auditing. This is because the VC contains a log digest signed with a TEE-protected key, allowing any verifier to independently verify the integrity and authenticity of the digest. Furthermore, the VC allows auditors to trace the source and context of the original log through the information within the VC without exposing sensitive personal information or trade secrets.

[0055] Through the above steps, the TEE (Trusted Execution Environment) provides a hardware-level isolated and protected area, ensuring that the code and data running within it cannot be illegally accessed or tampered with by external software (including operating systems and virtual machine monitors). By generating logs in the TEE, the originality and integrity of the logs at the source can be ensured. Even if other parts of the system are compromised, attackers cannot tamper with the logs within the TEE. Each newly generated log has its hash value calculated within the TEE, and the hash value of the previous log is used as the field value of the current log, forming a chain-like log hash chain. This chain structure is immutable; any modification to the log content will cause its hash value to change, thereby breaking the continuity of the chain, making tampering easily detectable in subsequent verification. Therefore, even if an attacker attempts to modify the generated logs, the hash chain mechanism within the TEE can guarantee the security of the original logs and the accuracy of historical records. A digital certificate is generated using the VC mechanism, resulting in the VC. The VC can maliciously prove that the source of the log is trustworthy and can also ensure that the log content has not been tampered with during transmission and storage.

[0056] The purpose of this application is to overcome the shortcomings of existing technologies and provide a cross-domain verifiable auditing and traceability system and method based on trusted credentials. This solution aims to address core pain points in private and multi-cloud environments, such as the lack of a root of trust, susceptibility to tampering, difficulties in cross-domain traceability, inconsistent time bases, and privacy leakage risks during the collection, storage, transfer, and auditing of audit logs. By establishing a hardware root of trust in the trusted execution environment of computing nodes, combined with a chained log structure, verifiable credentials, trusted timestamps, selective disclosure, a cross-domain shared federated ledger, and replayable attribution analysis, this application constructs an end-to-end, fully trusted auditing and traceability system that emphasizes privacy protection and feasibility.

[0057] To achieve its purpose, this application adopts the following technical solution: Figure 3As shown, a cross-domain verifiable audit and traceability system based on trusted credentials is applied in a private cloud or multi-cloud environment consisting of multiple independent management domains. The system includes: a trust collection layer, a cross-domain distributed storage layer, a joint audit and traceability layer, and a lifecycle management and evolution strategy.

[0058] As an optional implementation, generating logs based on events in a trusted execution environment includes: starting a log agent in the trusted execution environment and generating a reference report for the log agent, wherein the log agent is a software component used to generate logs, and the reference report includes code, configuration information, and platform identity; signing the reference report using the hardware key of the trusted execution environment to obtain a signed reference report; sending the signed reference report to a remote verification service, wherein the remote verification service is a service for verifying whether the log agent is trustworthy; receiving the report verification result sent by the remote verification service, wherein the report verification result indicates whether the log agent is trustworthy; if the report verification result indicates that the verification is successful, issuing a verification token to the log agent, explaining that the verification token indicates that the identity and operating environment of the log agent have been proven to be trustworthy; and using the log agent to convert events into a standardized data structure to obtain logs.

[0059] In this scheme, the TEE environment provides hardware-level security for the log broker, ensuring it is protected from any software attacks and tampering, thus establishing a hardware root of trust for log generation. Hardware key signing provides non-repudiation of cited reports, ensuring they are not forged during transmission. A remote authentication service verifies the authenticity, integrity, and tamper-proof nature of the log broker's operating environment, enhancing the trustworthiness of the auditing system. Report verification results ensure the log broker operates in a trusted state, guaranteeing the trustworthiness of the log source. Authentication tokens provide the log broker with credentials to prove its trusted identity among other components of the system. Standardized data structures facilitate unified log management and cross-domain sharing, while also improving log readability and analyzability.

[0060] A "log agent" software component is deployed within each computing node. This component runs in a Trusted Execution Environment (TEE), which can be based on technologies such as Intel SGX or AMD SEV. Upon startup, the log agent performs a "remote attestation" process, generating a "quote" containing its code metrics, configuration information, and platform identity. Due to the isolation characteristics of the TEE, even if the operating system or virtualization layer is compromised, the data and code within the TEE cannot be accessed or modified.

[0061] The log broker uses hardware keys deployed within the TEE (e.g., a private key built into the CPU) to digitally sign citation reports, generating signed citation reports. Because the hardware keys are generated and stored internally within the TEE and inaccessible from the outside, the signatures cannot be forged, ensuring the authenticity of the reports.

[0062] The Remote Verification Service is an independent third-party organization responsible for verifying the signature of reference reports and the trusted state of the platform on which the log broker runs. Based on the hardware manufacturer's records, the Remote Verification Service verifies the validity of signatures and the trusted state of the platform, ensuring the integrity of the TEE environment.

[0063] After receiving verification feedback from the remote certification service regarding the citation report, the log agent checks whether the verification passes. Only log agents that pass the remote certification service's verification are considered trustworthy. This step excludes log agents running in untrusted environments, preventing trust vulnerabilities at the source.

[0064] If the remote attestation service verifies the transaction, it will issue an expired attestation token to the log broker. The attestation token is a sign of the remote attestation service's confirmation of the TEE's running status. Any component within the system can verify the log broker's trusted status by verifying the token, thereby ensuring that all logs originate from a trusted source.

[0065] In a TEE (Tracking Equipment) environment, the log broker converts captured events into standardized JSON data objects, forming structured log entries. This standardized format allows logs to be consistently parsed by various systems and auditing tools, while the TEE environment ensures the integrity and originality of the log content, enabling efficient and secure data transfer even in complex cross-domain scenarios.

[0066] 1. Trust Collection Layer:

[0067] The trust collection layer is the cornerstone of trust in this system. Its core responsibility is to ensure the originality, integrity, timeliness, and privacy compliance of data at the source of log generation.

[0068] 1.1 Trusted Execution Environment (TEE) Log Broker:

[0069] This application deploys a "log agent" program within each computing node. The core innovation of this agent lies in its operation within a Trusted Execution Environment (TEE). A TEE, such as Intel's SGX (Software Guard Extensions) or AMD's SEV (Secure Encrypted Virtualization), is a secure zone within the main processor that provides confidentiality and integrity protection for the code and data loaded into it, shielding them from interference from the host operating system, hypervisor, and even physical attacks.

[0070] Remote authentication and root of trust establishment:

[0071] When the log broker starts, it executes a crucial "Remote Attestation" process. The specific steps are as follows:

[0072] 1. The agent generates a report called a "Quote" within the TEE, which includes its own code metrics, configuration information, and platform identity.

[0073] 2. The reference is signed by the platform hardware (such as the private key built into the CPU) to ensure its authenticity and integrity.

[0074] 3. The agent sends this signed reference to a separate "remote verification service." This service is typically provided by the hardware manufacturer or the root of trust management authority in the cloud environment.

[0075] 4. The remote attestation service verifies the referenced signature and the platform's trusted state based on the hardware manufacturer's records. If the verification is successful, it issues a time-limited "attestation token" to the log broker.

[0076] This process establishes a hardware-based "root of trust" for the log broker, proving to other components in the system that its operating environment is authentic, complete, and tamper-proof. Only the log broker that has been remotely authenticated can obtain the key used for subsequent log signing, thus ensuring that all logs originate from a trusted source.

[0077] Log capture and standardization:

[0078] The log broker is responsible for capturing various critical security event logs generated on this node, including but not limited to:

[0079] Virtualization layer: Lifecycle operations such as creation, destruction, migration, and snapshots of virtual machines (VMs).

[0080] Container layer: container startup, shutdown, image pulling, privileged container alerts, etc.

[0081] Management plane: User login, permission changes, API calls, security policy modifications, etc.

[0082] All captured logs are formatted into a standard, structured data object, typically in JSON format. A typical log entry contains the following fields:

[0083] `event_id`: A globally unique event identifier.

[0084] `timestamp`: A high-precision timestamp generated by a secure clock within the TEE to prevent tampering.

[0085] `domain_id`: The identifier of the management domain to which the log was generated.

[0086] `source_node_id`: A unique identifier for the computing node that generates the logs.

[0087] `actor_principal`: The identity identifier of the entity performing the operation (such as user ID, service account).

[0088] `action`: The type of operation to be performed (such as `vm.create`, `user.login`).

[0089] `target_resource`: Identifier of the target resource affected by the operation.

[0090] `status`: The result of the operation (such as `success`, `failure`).

[0091] `signature`: A digital signature generated within the TEE, used to verify the authenticity of the log.

[0092] `previous_log_hash`: The hash value of the previous log entry, used to build the log chain.

[0093] As an optional implementation, multiple logs are linked using their hash values ​​to obtain a hash chain of multiple logs, including: if the first log has been generated, generating the hash value of the first log to obtain the first hash value; if the Nth log has been generated, generating the hash values ​​of the Nth log and the (N-1)th hash value to obtain the Nth hash value, thus obtaining a hash chain of logs, where N≥2.

[0094] This scheme generates a unique identifier, or hash value, for each log entry. This helps build a continuous chain of evidence, ensuring the integrity of the logs. The scheme guarantees the continuity and immutability of the log sequence because any modification to historical logs will break the continuity of the hash chain, making tampering easily detectable in subsequent verification.

[0095] When the first log entry L1 is generated, its previous_log_hash field is empty or a preset genesis value. The proxy calculates the hash value H1 of everything in L1 except the signature. This step establishes the basis of the hash chain. When the second log entry L2 is generated, its previous_log_hash field is set to H1. Then, the proxy calculates the hash value H2 of L2 (containing H1). And so on, the previous_log_hash field value of the nth log entry Ln is the hash value H(n-1) of the (n-1)th log entry.

[0096] By establishing a hash chain, we create a cryptographically secure structure where the integrity of each new log entry depends on the hash value of the previous log entry. This means that if any intermediate log entry is tampered with, its hash value will change, causing the `previous_log_hash` field of all subsequent log entries to no longer match, breaking the continuity of the entire chain. Because the chain is built chronologically, with each new log entry based on the hash value of the previous log entry, this mechanism makes tampering with earlier log entries extremely costly, as it would require simultaneously tampering with all subsequent log entries to maintain the continuity of the hash chain. The hash chain leverages the property of cryptographic hash functions—that even small changes in data can lead to completely different hash values—providing a powerful tool for detecting log tampering.

[0097] 1.2 Generation of local domain log chains:

[0098] To ensure the continuity and immutability of the log sequence on a single node, this application uses a hash chain structure to organize the logs.

[0099] Chained integrity building:

[0100] On a computing node, each log entry generated by the log broker is linked to the previous log entry via a hash value. The specific implementation is as follows:

[0101] 1. When the first log entry `L1` is generated, its `previous_log_hash` field is empty or a preset genesis value. The proxy calculates the hash value `H1` of all content in `L1` except for the signature.

[0102] 2. When the second log entry `L2` is generated, its `previous_log_hash` field is set to `H1`. Then, the agent calculates the hash value `H2` of `L2` (which includes `H1`).

[0103] 3. And so on, the value of the `previous_log_hash` field of the `n`th log `Ln` is the hash value `H(n-1)` of the `n-1`th log.

[0104] In this way, any modification to the historical log content will change its hash value, thus disrupting the continuity of the entire hash chain and making it easily detectable during subsequent verification. This structure is similar to a lightweight, single-node blockchain, providing powerful tamper detection capabilities.

[0105] TEE signature:

[0106] After each log entry is generated and its hash value is calculated, the log broker uses a security key obtained through remote authentication to digitally sign the entire log entry (or its hash value) within the TEE. Because the signing key itself is protected by the TEE's hardware and cannot be accessed by untrusted external software, the signature has extremely high credibility and can be used to prove that the log was indeed generated by a trusted broker on a specific node at a specific time, thus achieving non-repudiation of the log.

[0107] As an optional implementation, a verifiable credential mechanism is used to generate a verifiable credential for a hash chain to obtain a digital credential. This includes: extracting key metadata, which includes the hash value of the last log, the time range of the hash chain, the management domain ID, and the node ID, where the management domain ID represents different management domains in the system, and the node ID represents a node in the management domain; and signing the key metadata using the private key of the issuing authority to obtain a digital credential, where the issuing authority is the entity that issues the verifiable credential.

[0108] In this scheme, the VC refines and encapsulates key information from the original log chain, enabling it to be shared and verified across domains in a unified standard format, without having to directly transmit the entire log chain data. This improves transmission efficiency and data security. The signed VC not only ensures the authenticity of its content but also provides the holder with the ability to selectively disclose information, allowing certain facts to be proven without revealing all details—a crucial aspect of cross-domain auditing.

[0109] After the log chain is generated, the audit credential issuing authority extracts key metadata from the chain, including: the root digest of the log chain (e.g., the hash value H(final) of the last log entry), the time range (start and end timestamps), the management domain ID, and the node ID that generated the log. This information constitutes the core components of VC, used to prove the integrity of the log chain and its generation within a specific time and management domain. Through VC, an efficient and secure representation of the log chain is achieved, while the extraction of key metadata ensures that the core elements of the information are preserved, facilitating subsequent auditing and verification.

[0110] The issuing authority uses its own publicly disclosed private key to securely sign critical metadata, generating an immutable and independently verifiable audit credential (VC). This VC conforms to W3C standards, ensuring cross-domain interoperability. The issuing authority's private key signing ensures the VC's immutability, while the adoption of W3C standards guarantees its universality and compatibility across cross-domain systems. Through the use of the VC, the system can balance the necessity of auditing with the protection of data privacy, meeting various regulatory and compliance requirements.

[0111] 1.3 Verifiable credential generation:

[0112] While the aforementioned log chain ensures the integrity of logs on a single node, the original log chain data is massive, varies in format, and is deeply embedded within its respective management domain. It is not suitable for direct sharing and transfer between multiple independent management domains, otherwise it will cause multiple problems such as efficiency, privacy, and standardization.

[0113] To address this issue, this application introduces a Verifiable Credential (VC) mechanism. The core function of a VC is to transform the summary information of one or more log chains into a standardized, lightweight, and independently verifiable digital "credential," serving as a "digital evidence unit" suitable for cross-domain transfer and verification. It acts as a "trust passport": abstracting the complex raw logs at the underlying level into structured evidence that can be efficiently, securely, and reliably transferred at higher levels, and adhering to relevant W3C standards to ensure cross-domain interoperability. Once a log chain (e.g., segmented by time window or log quantity) is generated, a corresponding VC can be issued for it.

[0114] Audit voucher issuing authority:

[0115] Each administrative domain establishes one or more "Audit Credential Issuers." This is a logical role whose responsibility is to issue verifiable credentials for the log chain generated within its domain. The issuer's own identity and public key are also registered and publicized in the cross-domain consortium to establish cross-domain trust.

[0116] Voucher generation process:

[0117] 1. The log broker submits a complete log chain (or its summary structure, such as a Merkle root) to the domain’s audit credentialing authority.

[0118] 2. The issuing authority verifies the origin (through the identity of the log broker) and internal integrity of the log chain.

[0119] 3. After successful verification, the issuing authority extracts key metadata, including:

[0120] The root digest of the log chain (e.g., the hash of the last log entry, or the Merkle tree root hash of the entire chain).

[0121] The time range of the log chain (start and end timestamps).

[0122] The management domain ID and node ID to which it belongs.

[0123] The issuing authority's own logo.

[0124] 4. The issuing authority encapsulates this metadata and holder information (usually the administrative domain itself) into a VC object. This object is represented in JSON-LD (JavaScript Object Notation for Linked Data) format, a JSON-based data format that makes the data more semantically understandable and interoperable for machines.

[0125] 5. Finally, the issuing authority uses its own private key to sign the entire VC object, generating an immutable and independently verifiable audit credential.

[0126] As an optional implementation, after generating verifiable credentials from a hash chain using a verifiable credential mechanism and obtaining digital credentials, the method further includes: obtaining the status of all digital credentials, wherein the status includes one of online, offline, and location; constructing a bitmap based on the status of all digital credentials; and displaying the bitmap in a display interface.

[0127] In this solution, real-time status monitoring ensures the validity of VCs, promptly detects and addresses potential revocations, and prevents the misuse of invalid or dangerous documents. The bitmap provides a compact and efficient status overview, allowing auditors to quickly understand the health status of VCs throughout the system, thus improving audit efficiency. Visualizing the VC status overview enables auditors to immediately identify potentially problematic VCs in the system, such as revoked or documents with unknown status, and to take appropriate action.

[0128] After a credential is issued, the system continuously monitors the status of the VC, including whether the VC is online (i.e., accessible and verifiable), offline (the VC can no longer verify its status via the network), and location (whether the VC's storage location has changed, such as moving from on-chain to off-chain storage). Status acquisition is performed through a dedicated VC status service, which communicates with a list of online VC statuses (such as W3C StatusList2021) to update the VC's online status in real time.

[0129] The status of all VCs is aggregated to construct a bitstring, where each bit corresponds to a specific VC's status (online, offline, location changed). Bitstrings, as a data structure, are very space-efficient and can quickly display the status of a large number of VCs without requiring detailed viewing of each VC's information, which is particularly crucial for auditing large-scale systems.

[0130] On the audit dashboard or console, bitmaps are displayed visually, with the status of each Control Controller (VC) represented by a color-coded dot or symbol. For example, green represents online and active, red represents revoked, and orange represents unknown status. The bitmaps on the display enhance the intuitiveness of information through color and icons, simplifying the cognitive load for auditors, enabling them to process large amounts of information quickly, and improving the speed and accuracy of audit decisions.

[0131] 1.4 VC Status and Revocation Service:

[0132] To ensure the manageability of the credential lifecycle, this application introduces a dynamic and efficient credential status management mechanism to replace the traditional static "credential revocation list" (CRL).

[0133] Online state endpoints and federated cache:

[0134] Status List: This application employs advanced online status query mechanisms such as W3C's `StatusList2021`. Each issuing authority maintains one or more publicly accessible "status endpoints" via the network. Each endpoint provides a bit-string, where each bit corresponds to the valid status (valid, revoked, etc.) of an issued credential. The VC itself only contains the URL pointing to this status list and its index position within the list. This approach significantly reduces the cost of transmitting and verifying revocation information.

[0135] Federation caching strategy: To improve performance and availability, authentication nodes in each management domain can cache the state lists of other domains. The system defines a cache refresh mechanism based on the credential `Cache-Control` header or federation policy to ensure that the latest state is obtained within a set time window.

[0136] Downgrade verification strategy under network disconnection and network partition:

[0137] When a network failure prevents access to the state endpoint of a VC, the system initiates a downgrade verification policy. The verification node marks the VC as "unknown state" and processes it according to the preset federation governance policy. For example, the policy may stipulate that "credentials with unknown states can only be accepted within their issuing domain for local auditing," or "in cross-domain auditing, the operations related to the credential are assigned a temporary risk weight until the state is reconfirmed after the network is restored."

[0138] As an optional implementation, after generating a verifiable credential for a hash chain using a verifiable credential mechanism and obtaining a digital credential, the method further includes: obtaining a request to extract data; determining the range of log data that the object of the extraction request can view based on its permissions; and displaying a portion of the log data that falls within the range of log data that the object can view on the display interface.

[0139] This solution ensures a controlled access log process through standardized request interfaces, laying the foundation for subsequent permission checks and log extraction. Role-based access control (RBAC) ensures log access follows the principle of least privilege, preventing improper information disclosure. While maintaining security, it achieves efficient log retrieval and display, improving auditing efficiency.

[0140] When a user or auditor requests access to a specific range of logs via the interface, the system first receives the request. The standardized and structured nature of the request allows the system to accurately understand the user's needs and perform authorization verification and log retrieval accordingly.

[0141] Upon receiving a request, the system determines the scope of logs the requester is allowed to view based on their identity and permissions. The RBAC mechanism automatically restricts user access to sensitive information based on a predefined role-based access control (RBAC) model, thus protecting system security and data privacy while meeting auditing requirements.

[0142] Once authorization is granted, the system retrieves logs matching the authorized scope from storage and displays them in the user interface. This may include summary information, event time, and operation type. A high-performance indexed database is used, enabling rapid location and extraction of logs within a specified range. Meanwhile, the optimized interface design ensures that auditors can intuitively and quickly understand the log content.

[0143] 1.5 Selective Disclosure and Privacy Protection:

[0144] To address data privacy issues in cross-domain sharing, this application introduces a selective disclosure mechanism in the VC generation and usage stages.

[0145] Technical Implementation:

[0146] This application preferably employs cryptographic suites that support selective disclosure, such as BBS+signatures or SD-JWT (selective disclosure JWT). When issuing a VC, the issuing authority processes multiple claims in the credential separately, allowing the credential holder (i.e., the managing domain) to present only a portion of the claims when sharing the credential, while simultaneously generating a cryptographic proof that these claims indeed originate from the original, complete credential.

[0147] Application Scenarios and Evidence Acquisition Upgrades:

[0148] Scope proof: During initial investigations, auditing firms may only need to prove that "a high-privilege operation did indeed occur in domain A within a certain time window," without needing to know the specific operator or target resource. In this case, domain A can provide a "scope proof" that only includes a declaration of the time range and event type, hiding other sensitive details.

[0149] Evidence escalation process: When an anomaly is detected during the initial audit and further investigation is required, the system defines an evidence escalation process. The auditor must initiate a "details request" (equivalent to an electronic audit warrant) with a digital signature, according to the governance protocol. After the request is verified and recorded through the consortium blockchain's governance contract, the credential holder can unseal and disclose more relevant credential fields.

[0150] As an optional implementation, after generating verifiable credentials for a hash chain using a verifiable credential mechanism and obtaining digital credentials, the method further includes: storing logs using a consortium blockchain; and upon receiving an extraction request, querying the logs from the consortium blockchain and sending the logs to the requesting end of the extraction request.

[0151] In this scheme, the federated ledger not only provides permanent storage for core evidence but also utilizes a consensus mechanism to ensure consistent understanding of the evidence records among all participants. This is particularly important in cross-domain environments, enhancing the overall credibility of the system and the transparency of auditing. This mechanism of on-demand querying and selective disclosure satisfies auditing needs while protecting data privacy and security.

[0152] In this application, instead of directly storing the original logs, verifiable credentials (VCs) generated from the original logs are stored. These VCs are recorded on a consortium blockchain jointly maintained by multiple mutually trusted management domains, forming a distributed, tamper-proof audit evidence storage system. The immutability and consensus mechanism of the consortium blockchain ensure that VCs cannot be altered once recorded, and that all domains can reach a consensus on the recording of VCs, regardless of network state.

[0153] When a legitimately authorized user or auditor needs to view the logs, the system processes the retrieval request and retrieves the original log chain from the consortium blockchain and off-chain storage system based on the location information recorded in the VCs. Then, according to the RBAC permission model and selective disclosure technology, the system determines the scope of visibility for the requester and sends this portion of the logs to the requesting party through a secure channel. This design, which allows for rapid location of the original log chain's storage location through VCs and then provides it to the requester with restricted access, avoids the unnecessary propagation of sensitive logs while ensuring the efficiency and security of the auditing process.

[0154] 2. Cross-domain distributed storage layer:

[0155] This layer is responsible for the secure and efficient storage and management of audit credentials and related metadata, and provides powerful cross-domain indexing and retrieval capabilities.

[0156] 2.1 Joint Ledger and Consensus Mechanism:

[0157] This application employs a consortium blockchain, jointly maintained by all participating domains, as the federated ledger. It is a logically unified, physically distributed storage system. All participating consortium management domains together form a network, with each domain running one or more nodes, which collectively maintain a copy of the same ledger.

[0158] Architecture and Consensus:

[0159] 1. Network Composition: An audit consortium is formed by multiple mutually trusted management domains. Each consortium member deploys and operates a ledger node that conforms to a unified protocol.

[0160] 2. Consensus Mechanism: In order to reach a consensus on the contents of the ledger in a distributed environment, the system adopts a consensus algorithm suitable for enterprise consortium scenarios, such as the Byzantine Fault Tolerance (BFT) algorithm or its variants.

[0161] 3. On-chain content: The data written to the federated ledger mainly consists of verifiable credentials (VCs) generated by each domain. Complete raw log chain data is not directly uploaded to the chain.

[0162] 4. Immutability: Once a “block” containing VC is added to the ledger chain through the consensus mechanism, it is linked to the previous block by cryptographic techniques (hash pointers), ensuring the permanence and immutability of audit credential records.

[0163] Finality, bifurcation, and evidence selection:

[0164] To ensure absolute consistency of the federated ledger in a distributed environment, this application specifies the following provisions:

[0165] Confirmation Threshold and Finality: A transaction containing VC needs to be confirmed by at least `2f+1` consensus nodes (where `f` is the tolerable number of Byzantine nodes) and grow for `N` blocks (e.g., `N=6`) before it is considered "Finalized". Time to Finality is a key performance indicator of the system, representing the delay in evidence solidification.

[0166] Fork handling strategy: The consensus protocol uses strategies such as the "longest chain principle" to automatically resolve temporary forks.

[0167] Evidence selection principle: In the extremely rare case of a network split leading to a prolonged fork, the consortium governance strategy stipulates that evidence on the main chain (the chain with the most consensus nodes) shall be considered legal evidence. Meanwhile, evidence on the forked chain will not be discarded, but will be marked as "pending evidence" and archived for manual review during subsequent dispute resolution.

[0168] As an optional implementation, a consortium blockchain is used to store logs, including: storing a portion of the log data in the shared chain of the consortium blockchain; and storing all the log data in the corresponding node of the consortium blockchain.

[0169] This solution, by storing VC metadata on the shared blockchain, not only achieves tamper-proof storage of key log information but also significantly reduces storage costs and data transmission time, improving the efficiency of cross-domain auditing. This hybrid storage architecture of "on-chain metadata and off-chain raw data" ensures the immutability of audit evidence while fully leveraging the high-speed access advantages of local storage, improving the response speed of audit queries and reducing the storage pressure and costs of the consortium blockchain.

[0170] The consortium blockchain is jointly maintained by all participating domains. As a federated ledger, it stores core metadata from the VC (Consortium Virtual Chain), including but not limited to the root digest of the log chain, time range, management domain ID, and node ID. This metadata is carefully selected within the VC to ensure independent verification of log authenticity while consuming minimal storage space. The VC mechanism effectively extracts and encapsulates key information from the original logs, transforming it into standardized audit evidence suitable for storage on the consortium blockchain. This leverages the consensus and immutability of the consortium blockchain to ensure the reliability of the audit evidence.

[0171] In addition to storing VC metadata on the consortium blockchain, the complete raw log chain is stored locally in high-performance, high-reliability storage systems, such as object storage or databases, within each management domain. The high performance and large capacity of off-chain storage systems are well-suited for storing and managing large amounts of raw log data, while the consortium blockchain ensures the integrity and verifiability of VCs storing off-chain data. This collaborative design is key to ensuring the overall performance and cost-effectiveness of the system.

[0172] 2.2 Cross-domain indexing and retrieval:

[0173] To support efficient audit queries, this application designs a cross-domain indexing and retrieval mechanism.

[0174] Hierarchical index structure:

[0175] The system builds a high-performance distributed index database on or in parallel with the federated ledger. This index associates the voucher metadata recorded in the ledger with specific query dimensions, forming key-value pairs that support multi-dimensional combined queries.

[0176] On-demand storage strategy:

[0177] This application employs a flexible "on-demand storage" or "hybrid storage" strategy to balance storage costs, query performance, and data security:

[0178] On-Chain data: The federated ledger stores only the most essential metadata that requires consensus guarantees, which can then be used to verify the credentials themselves.

[0179] Off-Chain data: Complete, raw log chain data is stored in high-performance, high-reliability storage systems local to each domain.

[0180] When an auditor needs to verify a specific log entry, the query process is as follows:

[0181] 1. Use the cross-domain indexing service to find the corresponding verifiable credential ID based on the query conditions.

[0182] 2. Read the VC corresponding to the ID from the federated ledger to obtain the root digest and storage location information of the log chain.

[0183] 3. Based on the storage location information, retrieve the complete log chain data from the corresponding off-chain storage system.

[0184] 4. Perform integrity verification on the retrieved log chain locally and compare it with the root digest in VC.

[0185] As an optional implementation, querying logs from the consortium blockchain and sending the logs to the requesting end of the extraction request includes: obtaining the storage location of the logs from the consortium blockchain according to the extraction request; obtaining the logs from the nodes in the consortium blockchain according to the storage location, and sending them to the requesting end of the extraction request.

[0186] This solution directly accesses the log chain's storage location via a consortium blockchain, avoiding redundant queries and data transfers and improving log retrieval efficiency. It achieves efficient data retrieval from on-chain to off-chain, while ensuring data security and compliance through permission mechanisms such as RBAC.

[0187] When an auditor or authorized user sends a request to retrieve the log chain, the system first looks up VCs on the consortium blockchain. VCs contain information pointing to the original log chain's storage location, typically a URL or storage object identifier in an off-chain storage system. VCs are designed to include necessary metadata, which is used not only to verify the authenticity of the logs but also to indicate the exact location of the log chain in local storage, making it possible to retrieve logs on demand.

[0188] Once the storage location of the original log chains is obtained, the system directly reads and extracts these log chains from the off-chain storage system. Then, within the framework of access control and privacy protection, it sends some or all of the log chain data to the requesting client. The hybrid storage architecture design, which stores the metadata of VCs on the consortium blockchain while storing the complete log chains on a local, high-performance off-chain system, enables the system to quickly respond to audit queries by leveraging the high-speed access characteristics of local storage while ensuring data security.

[0189] 2.3 Audit Query Language and Index Key Design:

[0190] To make "cross-domain retrieval" concrete and feasible, this application defines a simplified Audit Query Language (AQL) and corresponding index design.

[0191] Example of query language syntax:

[0192] AQL uses SQL-like syntax and focuses on auditing scenarios:

[0193] SQL

[0194] --Query all failed virtual machine creation operations for user-abc in domain A within a specific time period.

[0195] GET logs

[0196] WHERE domain.id = 'domain-A'

[0197] AND actor.id = 'user-abc'

[0198] AND action.name = 'vm.create'

[0199] AND status = 'failure'

[0200] AND event.time BETWEEN '2025-10-06T08:00:00Z' AND '2025-10-06T12:00:00Z';

[0201] -- Find high-risk events related to a specific resource across all domains

[0202] GET events

[0203] WHERE resource.id = 'res-xyz'

[0204] AND risk.level > 'high';

[0205] ```

[0206] Index key design:

[0207] To support queries, the backend distributed index database (such as Elasticsearch or ClickHouse) uses composite index keys and time-sharing strategies:

[0208] Primary index key: Uses a combination of frequently queried fields such as `domain_id:actor_id:action_name`, whose values ​​point to a list of related VC IDs.

[0209] Time series index: Create a separate time series index on the `event.time` field to efficiently handle time range queries.

[0210] Inverted index: An inverted index is created for keywords, resource IDs, etc. in the logs, supporting full-text search and fast association.

[0211] 2.4 Cross-Domain Credential Sharing Protocol:

[0212] To standardize and automate cross-domain trust interactions, a standard credential sharing and verification protocol is built into the consortium blockchain. This protocol defines the following core interaction processes:

[0213] Identity Registration: When a new management domain joins the federation, its identity and public key as an "audit credential issuer" must be registered and made public on the federated ledger to become a "trusted issuer" recognized by the federation.

[0214] Credential Exchange: When a domain needs to provide audit evidence to another domain or central audit platform, it can send the corresponding VC through a secure channel.

[0215] Credential Verification: Upon receiving the VC, the recipient can independently perform verification steps, including checking the signature, issuer identity, validity period, and online status (see Section 1.4).

[0216] As an optional implementation, after generating verifiable credentials for a hash chain using a verifiable credential mechanism and obtaining digital credentials, the method further includes: obtaining a timestamp token when logs are obtained, wherein the timestamp token is a token generated based on a trusted timestamp service when the logs are generated; performing time verification on the logs based on the timestamp token to obtain a time verification result, wherein if the timestamp represented by the timestamp token is the same as the pre-recorded timestamp of log generation, the time verification result is a pass; if the timestamp represented by the timestamp token is different from the pre-recorded timestamp of log generation, the time verification result is a fail; and outputting the complete logs if the time verification result indicates that the verification has passed.

[0217] In this scheme, timestamp tokens ensure the accuracy and non-repudiation of log generation time, improving the credibility of the time base for audit evidence. The time verification mechanism ensures the authenticity of the log's chronological order and time points, and is a crucial means of preventing post-event log forgery. By adding a reliable verification step to the logs through time verification, the accuracy of audit evidence received by auditors in the time dimension is ensured, avoiding misjudgments based on erroneous time information.

[0218] After obtaining the raw log chain data from the consortium blockchain or off-chain storage system, the auditing system further searches for timestamp tokens generated by the Trusted Timestamp Service (TSA) associated with these logs. These timestamp tokens are requested and recorded when the log chain is generated, providing independent and authoritative third-party proof of the generation time of each log entry. TSA, through standards such as RFC3161, provides a precise timestamp with an authoritative digital signature for the data, proving the existence and state of the data at a specific point in time, thus overcoming potential tampering or errors in the log source clock.

[0219] The accuracy of the log generation time is verified by comparing the timestamp marked on the timestamp token with the timestamp recorded in the log entry. If they match, it means the log's time information has not been tampered with, and the verification result is passed. The combination of the timestamp token and the time information in the log entry provides a dual verification mechanism. Even if the log broker's internal clock is compromised, the timestamp token can still provide an independent proof of time, ensuring the authenticity and credibility of the log time.

[0220] The auditing system will only allow the complete log data to be output to auditors or authorized users after the time verification result shows that the log time information has not been tampered with. If the verification fails, the system will mark these logs as suspicious and further investigate the cause. The accuracy of time information is crucial during the auditing process. By introducing an authoritative third-party timestamp service, a reliable reference point independent of the system's internal clock can be provided for the log time, enhancing the legal validity and judicial acceptance of audit evidence.

[0221] 3. Joint Audit and Retrospective Layer:

[0222] This layer utilizes the trusted data and infrastructure provided by the first two layers to perform specific audit tasks.

[0223] 3.1 Log Validation and Integrity Check:

[0224] When it is necessary to verify a certain log segment, this application provides an end-to-end verification mechanism that covers time, sequence, and content.

[0225] Reliable Timelines and Clock Correction:

[0226] To address the core challenge of "time synchronization issues" in cross-domain auditing, this application constructs a "verifiable timeline":

[0227] 1. Trusted Timestamping Authority (TSA): After generating a log or log chain digest, each log broker sends a request to a Trusted Timestamping Authority (TSA) that conforms to the RFC3161 standard or a decentralized time beacon network.

[0228] 2. The TSA returns a "timestamp token" containing the digest and the exact time, signed by the TSA's authoritative private key.

[0229] 3. This timestamp token is stored together with the log or its VC, providing strong evidence of when the event occurred that is independent of the node's own clock and can be verified by a third party.

[0230] 4. Cross-Domain Timeline Calibration: Nodes within the consortium periodically synchronize their clocks using methods such as Network Time Protocol (NTP). The system records the maximum permissible offset and actual drift data of each domain relative to the consortium's standard time. This calibration data can be attached to the VC as "time calibration proof" to accurately reconstruct a globally unified timeline during cross-domain event sequence analysis.

[0231] As an optional implementation, after generating verifiable credentials for a hash chain using a verifiable credential mechanism and obtaining digital credentials, the method further includes: generating a special log when a single log is changed, wherein the special log records the sequence number of the log before rollback; and generating a concatenated log when business operations occur between different nodes in the consortium blockchain, wherein the concatenated log records the logical relationship and time sequence between business events, wherein the special log and the concatenated log are used to trace events.

[0232] In this scheme, the generation of special logs not only records the sequence number of the logs before the change but also provides a clear marker of the change. This enables the system to detect any attempts to tamper with audit traces, enhancing the reliability of audit evidence and the integrity of the audit process. These concatenated logs record the logical relationships and chronological order between business events, providing a solid foundation for tracing cross-domain business operations and ensuring the continuity and verifiability of the operational chain in a distributed environment.

[0233] When any modification to historical log content is detected, including when the log sequence is interrupted due to system state rollback (such as snapshot restoration or data recovery), the log broker generates a special "state rollback" log. The introduction of state rollback logs provides an additional monitoring perspective for auditing systems, enabling them to capture unusual activity in the log chain, including intentional or unintentional sequence number jumps, thereby helping auditors identify potential violations.

[0234] When a business process spans multiple management domains and involves interactions between different nodes in the consortium blockchain, the system generates a "joint point proof" at each key business handover point and encapsulates it into a join log. By establishing clear event correlations between different nodes, the join log enables auditors or the system to reconstruct the complete cross-domain operation sequence based on these proofs. Even in complex multi-cloud scenarios, it can accurately track and verify the legality and compliance of each operation.

[0235] Cross-domain monotonic sequences and rollback detection:

[0236] To accurately detect log loss, truncation, and rollback, this application refines the sequence verification mechanism:

[0237] Strictly Monotonic Sequence within the Domain: Within each TEE log broker, a strictly monotonically increasing sequence number is maintained. Any operation, including virtual machine snapshot restoration and other operations that may lead to state rollback, must generate a special "state rollback" log, explicitly indicating the discontinuity of the sequence number and recording the last sequence number before the rollback.

[0238] Inter-Domain Sequence: When a business process spans multiple domains (e.g., a user in domain A requests the creation of a resource in domain B), the system generates a "sequence point certificate." This certificate is recorded on the federated ledger and includes the VC ID and sequence number of the source event (domain A) and the VC ID and sequence number of the target event (domain B). Using these sequence points, the auditing system can securely reconstruct fragments of log chains scattered across different domains into a complete and verifiable cross-domain operation sequence and detect any attempts to truncate logs at the inter-domain junctions.

[0239] End-to-end verification process:

[0240] The verification process now includes: 1) credential and online status verification; 2) timestamp token verification; 3) log chain retrieval; 4) chain and sequence integrity verification combined with rollback markers; 5) root digest comparison; and 6) log signature verification.

[0241] As an optional implementation, before outputting the complete log, the method further includes: acquiring relevant data, including location information, time information, and sequence information, wherein the location information indicates whether the operator's login geographical location is consistent with previous login records, the time information indicates whether the time interval between operations exceeds the normal range, and the sequence information indicates whether the operation sequence constitutes a known privilege escalation attack path; acquiring an evaluation model, wherein the evaluation model is one of a multilayer perceptron model, a convolutional neural network model, or a recurrent neural network model; forming a training set with historical relevant data and corresponding risk labels, and training the evaluation model using the training set to obtain a risk evaluation model, wherein the risk labels are the historical risk scores of the historical relevant data in the training set; inputting the relevant data into the risk evaluation model to obtain the risk score corresponding to the relevant data; and outputting the log through an API interface if the risk score is lower than a preset score threshold.

[0242] In this solution, by collecting and analyzing relevant data, the system can identify abnormal behavioral patterns, providing a basis for subsequent risk assessment and log output decisions. The machine learning model can automatically learn and adjust risk assessment strategies based on historical data, improving the intelligence and adaptability of the audit system. By training the evaluation model using a training set, the system can continuously improve and optimize its risk assessment algorithm, enhancing its accuracy in identifying abnormal behavior. Risk scores provide auditors with intuitive evaluation indicators, helping them quickly determine whether operations in the logs require further attention or investigation. By setting risk score thresholds, the system can effectively filter out a large number of low-risk operations, reducing the workload of auditors and improving audit efficiency.

[0243] Before outputting detailed logs, the auditing system collects a series of relevant data, including the operator's login geographic location, the time interval between operations, and whether the operation sequence constitutes a known privilege escalation attack path. This data originates from raw logs captured by the TEE log broker and has been hashed and digested during the previous VC generation process. Geographic location, time interval, and operation sequence are all important factors in assessing operational risks. Comparing this information with historical data can help identify potential security threats in a timely manner.

[0244] A machine learning evaluation model is used for risk assessment. This model can be a multilayer perceptron (MLP), convolutional neural network (CNN), or recurrent neural network (RNN), among others. By training the model, the system can automatically identify data features associated with abnormal behavior, enabling faster and more accurate risk assessments in future audits.

[0245] A training set was constructed, containing historical data related to past operations and corresponding risk labels. The training process enabled the model to learn the distinguishing features between normal and abnormal behaviors, allowing it to more accurately predict risk scores when faced with new data.

[0246] In specific audit scenarios, the system inputs collected data into the risk assessment model in real time or on demand to calculate a risk score. The machine learning model can comprehensively consider multiple risk factors and output a quantified risk assessment result, which is more objective and faster than manual judgment.

[0247] The preset score threshold is a risk assessment standard set in the system. When the calculated risk score is lower than this threshold, it means that the current operation has a relatively low risk, and the system can safely output the corresponding log data to the requester through the API interface. As a configurable parameter, the preset score threshold helps the system find a balance between security and efficiency, avoiding unnecessary waste of resources and manpower.

[0248] 3.2 Cross-Domain Anomaly Attribution and Event Correlation:

[0249] One of the most significant innovations of this application is the realization of effective cross-domain anomaly attribution.

[0250] Unified event model and event correlation analysis:

[0251] To understand and correlate logs from different systems, this application first constructs a Unified Event Model. This is a standardized, implementation-independent framework for event classification and description. For example, the "Create Cloud Host" operation in one domain and the "ProvisionVirtual Machine" API call in another domain can both be mapped to the `compute.instance.create` event in the Unified Event Model. The system employs various techniques, including time correlation, subject correlation, and causal analysis, to connect cross-domain events and construct a complete operation trajectory.

[0252] Explainability features and audit replay:

[0253] To address the "black box" problem of attribution analysis, this application emphasizes the interpretability of the model and the replayability of the conclusions:

[0254] Verifiable Feature List: The input features relied upon by the risk scoring model are all extracted directly from verifiable audit logs. For example:

[0255] `feature_login_location_consistency`: Consistency of the operator's login location.

[0256] `feature_time_delta_anomalous`: Whether the time interval between critical operations is abnormal.

[0257] `feature_privilege_escalation_path`: Whether it constitutes a known privilege escalation attack path.

[0258] The original value of each feature can be found directly from the evidence, making the scoring criteria transparent.

[0259] Audit Replay Interface: The system provides a "Replay" API. This interface accepts an "evidence package" (see Section 3.4) and a specified attribution model version number as input, enabling deterministic recalculation of risk scores and attribution conclusions that are completely consistent with the original report in an isolated environment. This makes any audit conclusion a "white box" that can be independently reproduced and verified by a third party.

[0260] 3.3 Audit Service Interface and Compliance Output:

[0261] To facilitate integration and meet compliance requirements, this application provides a range of standardized services and outputs.

[0262] Standardized API interface:

[0263] The system exposes a set of RESTful or gRPC-based application programming interfaces (APIs) for external systems (such as existing enterprise SIEM systems, Security Operations Center (SOC) platforms, or regulatory audit tools). Through these APIs, authorized users can retrieve logs and credentials, submit verification tasks, and subscribe to alerts as needed.

[0264] Chain audit reports:

[0265] The system can generate a "chain audit report" with one click. This report not only includes a summary of events during the audit period, but also links to and verification results of all relevant evidence (VC), forming a complete and self-proving chain of evidence.

[0266] As an optional implementation, before outputting the complete log, the method further includes: receiving an evidence request, wherein the evidence request is sent by a server of a regulatory agency; extracting evidence information according to the evidence request, wherein the evidence information includes the status of a digital credential, a timestamp token, a portion of the stored logs, a password, and a hash fingerprint; and sending the evidence information to the server corresponding to the evidence request.

[0267] This solution establishes a dedicated interface for receiving and processing evidence requests, enabling the audit system to respond promptly to regulatory needs and provide accurate audit evidence, thereby enhancing the system's compliance and judicial credibility. This evidence extraction process not only ensures the comprehensiveness of audit evidence but also, through selective disclosure techniques, provides regulatory agencies with sufficient evidence to support compliance reviews while protecting privacy and trade secrets. Through a standardized evidence package delivery process, the audit system ensures that regulatory agencies can independently verify and analyze audit evidence in an isolated and controlled environment, significantly enhancing the verifiability and transparency of audit evidence.

[0268] When regulatory agencies need to conduct in-depth reviews of a specific operation or a series of related operations, they send an evidence request to the audit system of this application through their servers. The design of the evidence request interface ensures that regulatory agencies can initiate the extraction and verification of specific audit evidence in a secure and traceable manner in accordance with pre-defined governance protocols, which provides a foundation for subsequent in-depth audits and judicial proceedings.

[0269] Upon receiving an evidence request from a regulatory agency, the audit system extracts relevant evidence from trusted credentials, timestamp tokens, stored logs, passwords, and hash fingerprints based on the specific conditions in the request (such as time range, operation type, and management domain ID). The extraction process follows a standardized set of evidence package construction rules that match the request conditions, enabling the audit system to respond to evidence requests efficiently and accurately, while protecting data privacy through encrypted sensitive information within the evidence package.

[0270] The audit system packages the extracted evidence into an evidence package, including VC status, timestamp tokens, parts of the original logs, cryptographic proofs, and hash fingerprints. This evidence package is then sent to the regulatory agency's server via a secure communication channel. The evidence package contains cryptographic proofs used to verify the integrity and authenticity of all critical information (VC, timestamps, log chains, etc.), allowing the regulatory agency to be confident in the credibility of the audit evidence without relying on the audit system's operators.

[0271] 3.4 Evidence Bundle Export Format:

[0272] To meet the "one-click evidence collection" needs of legal, compliance, and third-party auditing departments, this application defines a standardized "Evidence Bundle" format. This is a self-contained, portable archive (such as a signed ZIP or TAR file) with the following structure:

[0273] 1. Core evidence: A set of relevant verifiable credentials (VCs).

[0274] 2. Status and Time Proofs: Each VC has an online status proof (from the Status List) and a trusted timestamp token (from the TSA).

[0275] 3. Off-chain log fragments: The original log chain fragments extracted from off-chain storage corresponding to VCs.

[0276] 4. Cryptographic proof: Merkle containment proof or consistency proof connecting the off-chain logs and the on-chain VC.

[0277] 5. Verification Script Fingerprint: A version hash fingerprint of the client verification script or software used to verify this evidence package, ensuring the consistency of the verification environment.

[0278] 6. Metadata manifest: A manifest file describing all files in the package and their hash values; the manifest itself is also signed.

[0279] This evidence package can be distributed and verified independently of the original system, greatly facilitating judicial acceptance.

[0280] As an optional implementation, after generating verifiable credentials for a hash chain using a verifiable credential mechanism and obtaining digital credentials, the method further includes: obtaining a key, wherein the key includes at least a key for signing the log and a key for issuing the credential; and managing the key using a key management service.

[0281] In this scheme, by acquiring and managing these keys, the system can ensure the authenticity of the source of all audit logs and the authority of VCs, thereby constructing a non-repudiable audit evidence chain based on digital signatures. Through centralized management of the key lifecycle via KMS, the system can ensure the credibility of audit evidence while avoiding the complexity and security risks of key management.

[0282] In the technical solution of this application, keys are the core elements for ensuring log integrity and VC authenticity, including keys used for log signing and keys used for credential issuance. The key acquisition and management process ensures the security and confidentiality of the keys, preventing unauthorized parties from forging or tampering with logs and VCs, thereby enhancing the trustworthiness of the audit system.

[0283] Key Management Service (KMS) is a system that centrally manages cryptographic keys, responsible for key generation, distribution, rotation, and destruction. The introduction of KMS provides a secure and auditable key distribution and storage mechanism for the entire auditing system, ensuring the correctness and security of key usage. This is crucial for building a highly trustworthy auditing system.

[0284] 4. Lifecycle Management and Evolution Strategy:

[0285] 4.1 Key and Credential Management:

[0286] The system relies on a centralized or federated Key Management Service (KMS) to manage various keys across the entire system, including log signing keys and credential issuance keys. The KMS is responsible for the secure generation, distribution, periodic rotation, and emergency revocation of these keys. The key rotation policy is matched with the log archiving policy to ensure that even if keys expire, the signatures of historical logs can still be verified.

[0287] As an optional implementation, after managing the key using a key management service, the method further includes: obtaining a request to configure log viewing permissions according to the user's role or according to the user's personal custom configuration, thus obtaining a configuration request; receiving voting information on the configuration request; and configuring the log disclosure permissions according to the configuration request if the voting information indicates that the vote has passed.

[0288] This solution utilizes a flexible permission configuration request mechanism to support diverse access control policies, ensuring that only authorized users can view and manipulate audit logs. By introducing a voting mechanism, the system ensures democratic and consensus-based decision-making regarding permission modifications, preventing abuse of power or decision-making errors by a single administrator. The standardization and democratization of the permission modification process enable the system to dynamically respond to changing audit requirements and user role shifts, while ensuring that all changes undergo appropriate approval and documentation.

[0289] The auditing system receives permission configuration requests from users. These requests may be based on the user's role (such as administrator, auditor, developer, etc.) or on the user's custom settings. Such permission configurations not only meet the personalized needs of different user groups but also automatically adjust the permissions for log disclosure based on the user's role, improving system security and management efficiency.

[0290] Before modifying log viewing permissions, the system receives voting information from other participants to confirm the rationale for the permission change. This collective decision-making model ensures that any permission change is approved by multiple parties, increasing the transparency and fairness of the permission management process.

[0291] When voting information indicates that a majority of participants agree to the permission modification, the system will adjust the log disclosure permissions according to the configuration request. By linking permission configuration to voting information on the consortium blockchain, the system can provide an auditable, consensus-based history of permission changes, enhancing the fairness and traceability of permission management.

[0292] 4.2 Governance and Access Control:

[0293] Fine-grained permission model and compliance pattern library:

[0294] Access Control Model: The system defines a rich set of role and access control models (such as RBAC, Role-Based Access Control) to provide fine-grained authorization for all operations. In addition, the system also supports attribute-based access control (ABAC) to implement more dynamic and flexible authorization strategies.

[0295] Compliance Packs (New): The system comes pre-loaded with a series of "Compliance Packs". This is a collection of pluggable policy templates, such as:

[0296] GDPR Mode: Automatically enables selective disclosure of personally identifiable information (PII) fields, sets a regulatory-compliant data minimization retention period, and prohibits disclosure of specific information to non-EU domains by default.

[0297] Cybersecurity Classified Protection 2.0 Mode: Automatically configures log field sets, audit scope, and report templates that meet the requirements of cybersecurity classified protection.

[0298] Administrators can enable a specific mode with a single click, quickly making the system configuration meet specific audit requirements.

[0299] Cross-domain governance implementation interface:

[0300] To make the "strategy negotiation" executable and auditable, this application specifies it as an on-chain governance process:

[0301] Policy Object: Any governance policy (such as field-level visibility, cross-domain disclosure rules) is defined as a structured "Policy Object".

[0302] Change process: Any modification to the strategy must go through an on-chain proposal process.

[0303] 1. One or more alliance members initiate a proposal transaction that includes a new strategy object.

[0304] 2. Other members vote on the proposal during the pre-set voting period.

[0305] 3. When the vote meets the preset majority (such as more than 2 / 3), the governance smart contract automatically executes the proposal, records the new strategy object at a specific block height, and declares it effective.

[0306] Dispute resolution: Defines dispute arbitration mechanisms, such as establishing one or more "arbitration domains", or adopting a default, stricter strategy when no consensus is reached within a time limit.

[0307] As an optional implementation, after using a consortium blockchain to store logs, the method further includes: using a single write-multiple read approach to store logs in the consortium blockchain, wherein, in the case of storing logs for the Mth time, the logs stored for the (M-1)th time are pre-stored, where M≥2; constructing a copy of the stored logs to obtain log copies, wherein the log copies are stored in a disaster recovery device.

[0308] In this solution, by enabling the WORM feature, the system ensures the immutability of log data, protecting the original state of the logs even in the event of future network attacks or internal errors. The construction of log replicas and disaster recovery storage significantly enhance the system's disaster recovery capabilities and data persistence. Even if the primary storage system suffers unpredictable failures, the disaster recovery system can provide complete and consistent audit logs, ensuring the continuity of auditing operations remains unaffected.

[0309] When storing logs in the consortium blockchain, the Write-Once (WORM) feature is employed to ensure that once data is written, it cannot be modified or deleted, but can only be read multiple times. The WORM feature provides silent corruption protection and compliance retention for data in the storage system, which is crucial for ensuring data integrity and long-term archiving for audit logs.

[0310] In addition to storing logs on the consortium blockchain, the system also creates log copies and stores them in geographically separated disaster recovery devices. The disaster recovery storage strategy relies on off-site data synchronization and versioning management, which enables the original logs to be recovered from the copies even in extreme cases, avoiding audit vulnerabilities caused by data loss.

[0311] 4.3 Deployment and Expansion Path:

[0312] This application supports flexible, incremental deployment.

[0313] Phase 1: Single-Domain Deployment. Enterprises can initially deploy this solution within a single private cloud management domain to establish trusted audit capabilities within that domain. At this stage, the federated ledger can be simplified to a highly trusted database within the domain.

[0314] Phase Two: Multi-Domain Interconnection. As business expands, multiple deployed single-domain systems will be connected by introducing consortium blockchains and cross-domain identity authentication to form a multi-domain mutual trust and shared audit system.

[0315] Pluggable Components: The core components of the system are designed to be pluggable. For example, the hash chain implementation can be replaced with a more efficient Merkle tree; the consensus algorithm can be changed according to the size of the consortium and trust assumptions; and the TEE platform can also support products from different vendors. This modular design ensures the system's long-term technological competitiveness and evolutionary capabilities.

[0316] 4.4 Measurement and Acceptance Criteria:

[0317] To quantify the system's performance and security, this application defines a series of key metrics:

[0318] Performance metrics:

[0319] Log generation overhead: The performance impact (CPU, memory usage) of signature and hash calculation within the TEE on business applications.

[0320] Cross-domain synchronization latency: The average time it takes for a VC to become visible on all ledger nodes across the network from its generation.

[0321] Query and verification throughput: The number of audit queries and log chain verification requests that the system can process per second.

[0322] Safety indicators:

[0323] Tampering detection rate: The percentage of logs that the system successfully detects being tampered with, deleted, or forged during a simulated attack, with a target of 100%.

[0324] False alarm rate: The proportion of normal operations that the system mistakenly identifies as abnormal events.

[0325] Anomaly attribution accuracy: For known attack scenarios, can the system accurately trace abnormal behavior to the correct source and responsible party?

[0326] 4.5 Operation and Maintenance and Reliability Assurance:

[0327] To ensure the stable and reliable operation of the system in a production environment, this application includes the following design:

[0328] Off-chain storage enhancement:

[0329] Immutable storage strategy: The archiving storage of off-chain logs must enable the WORM (Write Once, Read Many) feature, for example, through the object lock function of object storage.

[0330] Versioning and Retention Period: The storage policy forces versioning and sets a minimum retention period that prevents deletion, thus preventing logs from being lost within the compliance period due to accidental operation or malicious attack.

[0331] Cross-region replication and verification: The system periodically replicates off-chain log data to geographically separated disaster recovery regions. At the same time, a background "integrity verification" service continuously and randomly samples off-chain logs and compares them with on-chain credentials to ensure that the data has not been silently corrupted and can be rebuilt from replicas in the event of corruption.

[0332] Back pressure and quota mechanism:

[0333] To prevent massive writes or queries from crippling the system, this application designs a multi-level resource control mechanism:

[0334] Log inbound rate limit: Limit the rate at which a single node or an entire domain submits VCs to the federated ledger using algorithms such as the token bucket.

[0335] Audit query quota: Set query quotas for each audit user or service account (such as the number of queries per minute or the amount of data pulled per day). Requests exceeding the quota will be rate-limited or rejected.

[0336] Disaster recovery and read-only audit mode: When the system undergoes major maintenance or encounters a catastrophic failure, it can switch to "read-only audit mode". In this mode, the system stops receiving new logs, but ensures that the query and verification functions of all historical data are available, ensuring the continuity of audit operations.

[0337] In summary, this application, through the addition and enhancement of technical details, not only constructs an end-to-end trusted audit traceability framework, but also provides a complete and robust solution that far surpasses existing technologies from multiple dimensions such as implementability, operability, privacy compliance, and judicial acceptance.

[0338] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be described in detail below with reference to specific embodiments.

[0339] The cross-domain verifiable auditing and traceability system based on trusted credentials proposed in this application can be broken down into a complete, step-by-step business process. Assume that in a multi-cloud environment consisting of "Management Domain A" and "Management Domain B," it is necessary to audit a cross-domain operation.

[0340] Phase 1: System Initialization and Deployment

[0341] 1. Alliance Establishment and Node Deployment: Management Domain A and Management Domain B jointly form an audit alliance. Both parties negotiate and sign an alliance governance strategy, which is then formalized into a smart contract within the federated ledger (consortium blockchain). Each domain deploys at least one consensus node for the consortium blockchain, along with other server-side components of this application, such as audit credential issuing authorities and cross-domain indexing services.

[0342] 2. Log Agent Deployment: Deploy a log agent program running in a Trusted Execution Environment (TEE) on all computing nodes (such as physical servers and virtual machine hosts) in Domain A and Domain B.

[0343] 3. Trust Root Establishment: Upon startup, each log broker executes a remote authentication process. It submits a "reference" signed by the hardware of its platform to a remote authentication service trusted by the consortium (which may be provided by the hardware manufacturer or a consortium-designated organization). Upon successful verification, the broker receives a time-limited authentication token and a signing key protected by the TEE hardware. This process proves the broker's trusted identity to the entire consortium.

[0344] Phase Two: Trusted Log Generation and Credential Issuance

[0345] Suppose user `user-X` initiates an operation on the portal of management domain A, which requires calling a service in management domain B to create a resource.

[0346] 1. Log generation for domain A:

[0347] The operation request for `user-X` is processed by a service on a computing node `node-A1` in domain A.

[0348] The TEE log broker on `node-A1` captured this API call event.

[0349] Within the TEE, the agent formats the event into a structured log `Log-A1`, which includes event details, a timestamp generated by the TEE security clock, and information such as the operation subject `user-X`.

[0350] The agent calculates the hash value H(A0) of the previous log entry `Log-A0` and fills it into the `previous_log_hash` field of `Log-A1`.

[0351] The agent uses the TEE signing key it obtained in the first phase to digitally sign the entire `Log-A1`.

[0352] `Log-A1` is safely appended to the local log chain of `node-A1`.

[0353] 2. Issuance and on-chaining of credentials for Domain A:

[0354] After a preset time window (e.g., 1 minute), the log broker of `node-A1` will submit the log chain containing `Log-A1` (or its Merkle root) to the "Audit Credentials Issuing Authority" of domain A.

[0355] The issuing authority verifies the integrity of the log chain (hash chain continuity) and the signature of `Log-A1` (confirming that it comes from a trusted TEE agent).

[0356] After successful verification, the issuing authority creates a verifiable credential `VC-A`. `VC-A` contains metadata such as the root hash of the log chain, start and end times, domain (domain A), and node (`node-A1`). This credential is signed using the BBS+ scheme, which supports selective disclosure.

[0357] The issuing authority submits `VC-A` to the consortium blockchain nodes in domain A. After consortium consensus (such as BFT), `VC-A` is packaged into a new block, permanently recorded on the consortium ledger, and synchronized with all consortium members, including those in domain B.

[0358] At the same time, the complete raw log chain is archived to a local object storage in domain A with WORM enabled.

[0359] Phase Three: Cross-Domain Event Correlation and Tracing

[0360] 1. Log generation and association in domain B:

[0361] A service in domain A invokes a service interface in domain B, requesting the creation of a resource on `node-B1`. This request may optionally include the identifier of `VC-A` or partial disclosure as "upstream evidence" of the legitimacy of its operation.

[0362] The TEE log broker on `node-B1` captured this inbound API call and the subsequent resource creation event, generating logs `Log-B1` and `Log-B2`.

[0363] When generating `Log-B1`, in addition to regular information, the agent also records the associated upstream event information, namely the identifier of `VC-A`.

[0364] The subsequent process is similar to that in domain A. The issuing authority of domain B will eventually issue a verifiable credential `VC-B` for this log chain, which contains the key association information that "this operation was triggered by the event represented by `VC-A`". `VC-B` is also recorded on the federated ledger.

[0365] Phase Four: Joint Audit and Verification

[0366] Now, an authorized auditor needs to investigate the complete activity log of `user-X`.

[0367] 1. Cross-domain query: The auditor uses the audit client to initiate a query using the Audit Query Language (AQL) defined in this application: `GET logs WHERE actor.id = 'user-X' AND event.time BETWEEN ...`.

[0368] 2. Indexing and Retrieval: When the system's cross-domain indexing service receives a query, it quickly locates the two credentials related to `user-X`: `VC-A` and `VC-B` from its distributed index.

[0369] 3. Document Verification: The audit client retrieves the complete contents of `VC-A` and `VC-B` from the combined ledger.

[0370] The client first verifies whether the digital signatures of the two credentials are valid, and whether the issuing authority is a member recognized by the consortium.

[0371] The client can check online whether `VC-A` and `VC-B` have been revoked by using the "status list" URL pointed to in VC.

[0372] 4. Trajectory Reconstruction: The client parsed the content of `VC-B` and discovered its association field with `VC-A`. Through this link, the system successfully connected the user operation that occurred in domain A and the resource creation operation that occurred in domain B, constructing a complete business operation trajectory spanning two management domains.

[0373] 5. In-depth forensics (optional): If the auditor needs to verify the original details of `Log-A1`, the procedure is as follows:

[0374] The audit client extracts the storage location information of the raw log chain (a URL pointing to the object storage inside domain A) and the root hash `H_root(A)` from `VC-A`.

[0375] The client sends a request to the storage system of domain A to retrieve the corresponding encrypted log chain data.

[0376] Locally, the client first performs an integrity check on the retrieved log chain, that is, checks whether the hash pointers are consecutive and recalculates its root hash `H'_root(A)`.

[0377] The client compares `H'_root(A)` with the `H_root(A)` recorded in `VC-A` to see if they are completely consistent.

[0378] Finally, the client uses the public key of the TEE log broker in domain A (which has been made public in the consortium) to verify the digital signature of `Log-A1` itself.

[0379] Once all verification steps are passed, the auditor can be 100% certain that `Log-A1` was generated by a trusted agent on a specified node at a specified time, and that the content is authentic and has not been tampered with.

[0380] Through the above implementation methods, this application constructs a closed-loop, end-to-end trusted audit process. It not only ensures the trustworthiness of each log source, but also connects the isolated "trust islands" in various domains into a unified "trust continent" through VC and federated ledger, realizing truly cross-domain verifiable auditing and traceability.

[0381] In summary, the main solutions of this application include:

[0382] A cross-domain verifiable auditing and traceability system based on trusted credentials, the system comprising:

[0383] A trust collection layer, configured on one or more computing nodes, is used to capture raw event logs in the trusted execution environment of the computing nodes, perform chain-structured processing and digital signature on the logs, and issue verifiable credentials containing their cryptographic digests based on the logs.

[0384] A cross-domain distributed storage layer consists of multiple nodes belonging to different management domains, including a distributed federated ledger for recording and sharing verifiable credentials through a consensus mechanism, and one or more off-chain storage systems for archiving raw event logs;

[0385] A joint audit and traceability layer is used to respond to audit requests, retrieve relevant verifiable credentials from the joint ledger, and, based on the information contained in the credentials, obtain the corresponding raw logs from the off-chain storage system for verification, analysis, and event trajectory reconstruction.

[0386] The trusted execution environment in the trust acquisition layer interacts with an independent remote authentication service through a remote authentication process at startup to verify the integrity and authenticity of its own runtime environment and obtain the key used to digitally sign the logs.

[0387] The chained structured processing of logs includes adding the hash value of the previous log entry to each newly generated log entry, thereby forming a log chain linked by hash pointers.

[0388] Verifiable credentials are signed using a cryptographic scheme that supports selective disclosure, allowing the credential holder to disclose only a portion of the claims in the credential when presenting it to the verifier, while simultaneously generating a cryptographic proof to verify the validity of those claims.

[0389] The federated ledger is a consortium blockchain that uses a consensus algorithm based on Byzantine Fault Tolerance (BFT) or a variant thereof to ensure the consistency and immutability of verifiable credential records.

[0390] The joint audit and traceability layer also includes a module that interacts with a trusted timestamp service to request a separate, authoritative third-party signed timestamp token for logs or verifiable credentials to provide verifiable proof of time.

[0391] A cross-domain verifiable auditing and traceability method based on trusted credentials includes the following steps: In a trusted execution environment within a computing node, the original event is captured and log entries are generated; within the trusted execution environment, the log entries are digitally signed using a protected key, and multiple log entries are linked together to form a log chain; a credential issuing authority issues a verifiable credential containing its root hash digest for the log chain or a portion thereof; the verifiable credential is submitted to a distributed federated ledger maintained by multiple management domains, and permanently recorded through a consensus mechanism; in response to an audit query, one or more relevant verifiable credentials are retrieved from the federated ledger, and the original log chain is retrieved from off-chain storage based on the digest and location information recorded in the credential, for integrity and authenticity verification.

[0392] Prior to the step “Capture the original event and generate log entries”, there is also a remote certification step, in which the trusted execution environment certifies its own integrity to a remote certification service to establish a trusted root for its operation.

[0393] The issuance of verifiable credentials employs a signature algorithm that supports selective disclosure; and, in response to audit inquiries, it also includes a step of generating and providing a derived credential containing only partial claims to meet audit verification requirements without disclosing all information.

[0394] When a business process spans at least two administrative domains, the methodology also includes:

[0395] Generate a first verifiable credential for a pre-occurring event in the first management domain;

[0396] For a subsequent event that occurs in the second management domain and is triggered by a prior event, a second verifiable credential is generated, and the unique identifier of the first verifiable credential is recorded in the second verifiable credential;

[0397] By finding such reference relationships between documents on the federated ledger, cross-domain event causal chains can be reconstructed.

[0398] The verification steps specifically include:

[0399] Verify the digital signature of the credential itself, the identity of the issuer, and the online status;

[0400] The root hash digest of the original log chain retrieved from off-chain storage is recalculated.

[0401] Compare whether the recalculated root hash digest matches the root hash digest recorded in the verifiable credential.

[0402] A log processing apparatus operating in a trusted execution environment is configured to perform the following operations: prove the integrity of its operating environment to an external entity through remote proof; securely receive a private key for signing; capture event logs generated by its computing power node; add timestamps and the hash value of the previous log to the captured logs; and digitally sign the processed logs using the private key.

[0403] In summary, the core innovation of this application lies in constructing a completely new, end-to-end trusted auditing and traceability paradigm. Its key technologies and protection points are mainly reflected in the following aspects:

[0404] Key technical points:

[0405] 1. Hardware Trust Root and Log Security Anchoring Based on TEE: The key technology lies in leveraging the isolation and protection features of a Trusted Execution Environment (TEE) and combining it with a remote verification process to establish a hardware-based, unshakeable trust origin for the log generation process. All log capture, formatting, hashing, and signing are completed within this secure "enclave," ensuring the inherent security of the logs.

[0406] 2. Abstraction and Encapsulation from Logs to Credentials: The key technology lies in the introduction and modification of Verifiable Credentials (VC) technology, which serves as a bridge connecting the complex underlying logs with the upper-level cross-domain auditing. This application defines a VC structure specifically for auditing scenarios. It not only encapsulates the cryptographic digest of the log chain but also integrates multiple mechanisms such as selective disclosure, online status query, and trusted timestamps, making it a highly functional "digital evidence unit".

[0407] 3. Hybrid Trust Architecture with On-Chain and Off-Chain Collaboration: The key technology lies in the design of an innovative distributed storage model. It utilizes a consortium blockchain to store lightweight but strong consensus-required VC metadata, forming a globally unified and tamper-proof "evidence index"; simultaneously, massive amounts of raw logs are stored in high-performance off-chain storage in each domain. This collaborative architecture of "strong on-chain consensus and big off-chain data" is the core of balancing security, performance, and cost.

[0408] 4. Cross-domain event tracing based on credential association: The key technology lies in establishing reference relationships between VCs at the federated ledger level to achieve accurate tracing of cross-domain business flows. When an operation flows from one domain to another, the VC of the downstream event records the identifier of the VC of the upstream event, thus forming an auditable and complete causal chain on the immutable ledger.

[0409] 5. Cryptographic Fusion of Privacy Protection and Auditability: The key technology lies in the deep integration of cryptographic schemes supporting selective disclosure (such as BBS+signatures or SD-JWT) with the lifecycle of auditable credentials. This allows credential holders to prove to the verifier that they comply with specific audit rules without disclosing sensitive information, and is a core technical means to resolve the contradiction between data sharing and privacy protection.

[0410] The points that this application seeks to protect are:

[0411] 1. Overall inventive concept (system and method): This application seeks protection for a complete system consisting of a trust acquisition layer, a cross-domain distributed storage layer, and a joint audit and traceability layer, as well as a complete set of methods for generating trusted logs and performing cross-domain verification and traceability. This is the highest level of protection in this application.

[0412] 2. Core Component: TEE Log Broker: Requests protection for a log broker device or module running in a trusted execution environment. It establishes identity through remote authentication; and performs hash chaining and digital signatures on captured logs within the TEE.

[0413] 3. Core Data Structure: Auditable Verifiable Credentials: This request protects a data structure used for auditing (i.e., the audit VC). It includes a cryptographic digest of the log chain, issuer information, and time range, and is constructed using a signature mechanism that supports selective disclosure.

[0414] 4. Core Mechanism: Cross-Domain Tracing Method: This request seeks protection for a method to achieve cross-domain event tracing. Verifiable cross-domain event associations are established by including a reference to a first document representing an upstream event in a second document recorded on the federated ledger that represents a downstream event.

[0415] 5. Core Mechanism: Privacy Audit Methodology: Request for Protection is a method for conducting privacy audits. Upon responding to an audit request, the credential holder generates and provides a "derived credential" (or "presentation") containing only partial claims. Verifiers can use this derived credential to verify the veracity of the partial claims without accessing the complete original credential.

[0416] 6. System Architecture: Hybrid Storage and Query Method: Request for Protection proposes a method for storing and querying audit data. Verifiable credentials are stored on a distributed federated ledger, while the original log chain is stored off-chain. Linkage queries and verifications from on-chain to off-chain are achieved through the link information in the credentials.

[0417] By outlining the above key points and protection measures, the aim is to establish a comprehensive and robust intellectual property barrier for the core ideas, key components, innovative mechanisms, and overall architecture of this application.

[0418] The cross-domain verifiable auditing and traceability system and method based on trusted credentials provided in this application have the following significant advantages compared with the prior art:

[0419] 1. Achieves native trust and tamper-proof capabilities at the source level: The biggest breakthrough of this application lies in deploying a log agent in the Trusted Execution Environment (TEE) of the computing power node and combining it with a remote proof mechanism to sink the root of trust for auditing to the hardware level. This ensures that the log is authentic and complete at the moment of its generation, and that its signing key cannot be stolen by any privileged software, including the operating system. Compared with traditional schemes that rely on software signatures or no signature protection, this application fundamentally eliminates the possibility of tampering, forging, or deleting logs at the source, providing an unbreakable foundation of trust for the entire auditing system.

[0420] 2. A standardized and interoperable cross-domain trust system has been constructed: By introducing W3C standard verifiable credentials (VCs) as a "trust passport" for cross-domain transfers, this application abstracts underlying logs from different sources and in different formats into unified, lightweight, and independently verifiable digital evidence. Combined with a joint ledger (consortium blockchain) maintained by all participants, the system establishes an equal trust network without a central authority across multiple independent management domains. This effectively solves the problems of trust gaps, inconsistent audit standards, and severe data silos between systems in multi-cloud and hybrid cloud environments, making end-to-end business traceability possible.

[0421] 3. Robust privacy protection while ensuring auditability: This application creatively applies a selective disclosure mechanism (such as BBS + signature) to audit credentials. When the management domain needs to provide audit evidence to external parties, it can only present some necessary information from the credentials (e.g., "a high-risk operation occurred within a certain time period"), while concealing sensitive details such as the operation subject and target resources, and still provide cryptographic proof. This "disclosure on demand, minimal sharing" model perfectly solves the risk of trade secret and user privacy leakage caused by sharing raw logs in traditional auditing methods, and especially meets the requirements of stringent data protection regulations such as GDPR.

[0422] 4. Balancing high performance, low cost, and high scalability: This application employs a hybrid storage architecture of "on-chain metadata and off-chain raw data." Only lightweight verifiable credentials (VCs) are recorded on the consortium blockchain to leverage its immutability and consensus characteristics; while the massive raw log chain is stored in high-performance local storage in each domain. This design ensures the absolute security and consistency of core evidence while avoiding performance bottlenecks and high costs caused by uploading massive amounts of data to the blockchain, making this solution highly feasible and economical in real-world large-scale production environments.

[0423] 5. Provides independently verifiable and judicially admissible strong evidence: This application defines a standardized "evidence package" export format, which can package all relevant evidence required for an audit (VC, timestamps, log fragments, verification scripts, etc.) into a self-contained, portable file. Any third party (such as regulatory agencies or judicial departments) can independently and offline perform deterministic verification of this evidence package and reproduce the audit conclusions. This greatly enhances the credibility of the audit results, making them strong evidence that meets compliance requirements and judicial admissibility standards.

[0424] 6. Enhanced Automation, Intelligence, and Operability of Auditing: By defining an Audit Query Language (AQL), ​​a unified event model, and interpretable attribution analysis, this application transforms cumbersome manual auditing processes into efficient automated analysis. A pre-built "compliance pattern library" and on-chain governance-based policy management enable the system to flexibly adapt to different regulatory environments and ensure that all governance changes are themselves auditable. These designs significantly reduce the complexity and labor costs of auditing work, improving the efficiency and responsiveness of security operations.

[0425] From the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the embodiments can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0426] Embodiments of this application also provide a log management device. Figure 4 This is a structural block diagram of a log management device according to an embodiment of this application, such as... Figure 4 As shown, the device includes:

[0427] The first acquisition unit 402 is used to acquire events during the business processing.

[0428] The first generation unit 404 is used to generate logs based on events in a trusted execution environment;

[0429] Linking unit 406 is used to link multiple logs using their hash values ​​when there are multiple logs, to obtain a hash chain of multiple logs;

[0430] The second generation unit 408 is used to generate verifiable credentials for a hash chain using a verifiable credential mechanism to obtain digital credentials. The digital credentials are used to verify the authenticity and integrity of the logs and are also used to enable log traceability.

[0431] Through the above devices, the TEE (Trusted Execution Environment) provides a hardware-level isolated and protected area, ensuring that the code and data running within it cannot be illegally accessed or tampered with by external software (including operating systems and virtual machine monitors). By generating logs in the TEE, the originality and integrity of the logs at the source can be ensured. Even if other parts of the system are compromised, attackers cannot tamper with the logs within the TEE. Each newly generated log has its hash value calculated within the TEE, and the hash value of the previous log is used as the field value of the current log, forming a chain-like log hash chain. This chain structure is immutable; any modification to the log content will cause its hash value to change, thereby breaking the continuity of the chain, making tampering easily detectable in subsequent verification. Therefore, even if an attacker attempts to modify the generated logs, the hash chain mechanism within the TEE can guarantee the security of the original logs and the accuracy of historical records. A digital certificate is generated using the VC mechanism, resulting in the VC. The VC can maliciously prove that the source of the log is trustworthy and can also ensure that the log content has not been tampered with during transmission and storage.

[0432] For a description of the features in the embodiment corresponding to the log management device, please refer to the relevant description in the embodiment corresponding to the log management method, which will not be repeated here.

[0433] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform steps in any of the log management method embodiments.

[0434] Embodiments of this application also provide a computer-readable storage medium storing a computer program configured to execute steps in any of the log management method embodiments at runtime.

[0435] In one exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0436] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the log management method embodiments.

[0437] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of any log management method embodiment.

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

[0439] The foregoing has provided a detailed description of a log management method, apparatus, electronic device, computer-readable storage medium, and computer program product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to aid in understanding the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A log management method, characterized in that, include: Acquire events during the business processing; Logs are generated based on the events in a trusted execution environment; When there are multiple logs, the hash values ​​of the logs are used to link the multiple logs to obtain a hash chain of the multiple logs; A verifiable credential mechanism is used to generate a verifiable credential for the hash chain, resulting in a digital credential. The digital credential is used to verify the authenticity and integrity of the log, and it is also used to enable the traceability of the log. Generating logs based on the events in a trusted execution environment includes: starting a log agent in the trusted execution environment and generating a reference report for the log agent, wherein the log agent is a software component for generating the logs, and the reference report includes code, configuration information, and platform identity; signing the reference report using the hardware key of the trusted execution environment to obtain a signed reference report; sending the signed reference report to a remote verification service, wherein the remote verification service is a service for verifying whether the log agent is trustworthy; receiving a report verification result sent by the remote verification service, wherein the report verification result indicates whether the log agent is trustworthy; if the report verification result indicates that the verification is successful, issuing a verification token to the log agent, explaining that the verification token indicates that the identity and operating environment of the log agent have been proven to be trustworthy; and using the log agent to convert the events into a standardized data structure to obtain the logs.

2. The method according to claim 1, characterized in that, Linking multiple logs using their hash values ​​yields a hash chain of logs, including: If the first log has been generated, generate the hash value of the first log to obtain the first hash value; If the Nth log has been generated, generate the hash value of the Nth log and the (N-1)th hash value to obtain the Nth hash value, and obtain the hash chain of the log, where N≥2.

3. The method according to claim 1, characterized in that, A verifiable credential mechanism is used to generate verifiable credentials for the hash chain, resulting in digital credentials, including: Extract key metadata, which includes the hash value of the last log, the time range of the hash chain, the management domain ID, and the node ID, wherein the management domain ID represents different management domains in the system, and the node ID represents a node in a management domain; The key metadata is signed using the private key of the issuing authority to obtain the digital certificate, wherein the issuing authority is an entity that issues verifiable certificates.

4. The method according to claim 1, characterized in that, After generating verifiable credentials for the hash chain using a verifiable credential mechanism to obtain digital credentials, the method further includes: Obtain the status of all the digital credentials, wherein the status includes one of online, offline, and location; Construct a bitmap based on the status of all the digital credentials; The bitmap is displayed on the display interface.

5. The method according to claim 1, characterized in that, After generating verifiable credentials for the hash chain using a verifiable credential mechanism to obtain digital credentials, the method further includes: Get the data extraction request; Based on the permissions of the object making the extraction request, determine the range of log data that the object making the extraction request can view; Based on the data range of the logs that the object can view, a portion of the logs that fall within the data range of the logs that the object can view are displayed in the display interface.

6. The method according to claim 5, characterized in that, After generating verifiable credentials for the hash chain using a verifiable credential mechanism to obtain digital credentials, the method further includes: The logs are stored using a consortium blockchain; Upon receiving the extraction request, the log is queried from the consortium blockchain and the log is sent to the requesting end of the extraction request.

7. The method according to claim 6, characterized in that, The logs are stored using a consortium blockchain, including: A portion of the log data is stored in the shared chain of the consortium blockchain; All log data is stored in the corresponding node of the consortium blockchain.

8. The method according to claim 6, characterized in that, Querying the logs from the consortium blockchain and sending the logs to the requesting end of the extraction request includes: The storage location of the log is obtained from the consortium blockchain according to the extraction request; Based on the storage location, the log is retrieved from a node in the consortium blockchain and sent to the requesting end of the extraction request.

9. The method according to claim 6, characterized in that, After generating verifiable credentials for the hash chain using a verifiable credential mechanism to obtain digital credentials, the method further includes: If the log is obtained, a timestamp token is obtained, wherein the timestamp token is a token generated by a trusted timestamp service when the log is generated; The log is time-verified based on the timestamp token to obtain a time verification result. If the timestamp represented by the timestamp token is the same as the timestamp generated by the pre-recorded log, the time verification result is a pass; if the timestamp represented by the timestamp token is different from the timestamp generated by the pre-recorded log, the time verification result is a fail. If the time verification result indicates that the verification is successful, the complete log is output.

10. The method according to claim 9, characterized in that, After generating verifiable credentials for the hash chain using a verifiable credential mechanism to obtain digital credentials, the method further includes: In the event of a change to a single log, a special log is generated, wherein the special log records the sequence number of the log before the rollback; When business operations occur between different nodes in the consortium blockchain, a spliced ​​log is generated. The spliced ​​log records the logical relationship and time sequence between business events. The special log and the spliced ​​log are used to trace events.

11. The method according to claim 9, characterized in that, Before outputting the complete log, the method further includes: Acquire relevant data, including location information, time information, and sequence information. The location information indicates whether the operator's login geographical location is consistent with previous login records. The time information indicates whether the time interval between operations exceeds the normal range. The sequence information indicates whether the operation sequence constitutes a known privilege escalation attack path. Obtain an evaluation model, wherein the evaluation model is one of a multilayer perceptron model, a convolutional neural network model, or a recurrent neural network model; The historical data and corresponding risk labels are combined to form a training set. The evaluation model is trained using the training set to obtain the risk evaluation model. The risk label is the historical risk score of the historical data in the training set. The relevant data is input into the risk assessment model to obtain the risk score corresponding to the relevant data; If the risk score is lower than a preset score threshold, the log will be output via the API interface.

12. The method according to claim 9, characterized in that, Before outputting the complete log, the method further includes: A request for evidence collection is received, wherein the request for evidence collection is sent by the server of the regulatory agency; Based on the evidence request, evidence information is extracted, wherein the evidence information includes the status of the digital credential, timestamp token, a portion of the stored logs, password, and hash fingerprint; The evidence information is sent to the server corresponding to the evidence collection request.

13. The method according to claim 6, characterized in that, After generating verifiable credentials for the hash chain using a verifiable credential mechanism to obtain digital credentials, the method further includes: Obtain a key, wherein the key includes at least a key for signing the log and a key for issuing credentials; The key is managed using a key management service.

14. The method according to claim 13, characterized in that, After managing the key using a key management service, the method further includes: Obtain a request to configure the log viewing permissions according to the user's role or according to the user's custom configuration, and get the configuration request; Receive voting information for the configuration request; If the voting information indicates that the vote has passed, the disclosure permissions of the log are configured according to the configuration request.

15. The method according to claim 6, characterized in that, After storing the logs using a consortium blockchain, the method further includes: The log is stored in the consortium blockchain using a single-write, multiple-read approach, wherein, in the case of storing the log for the Mth time, the log stored for the M-1th time is pre-stored, where M≥2; A copy of the stored log is constructed to obtain a log copy, wherein the log copy is stored in a disaster recovery device.

16. A log management device, characterized in that, include: The first acquisition unit is used to acquire events during the business processing. The first generation unit is used to generate logs based on the events in a trusted execution environment; A linking unit is used to link multiple logs using their hash values ​​to obtain a hash chain of the logs when there are multiple logs. The second generation unit is used to generate verifiable credentials for the hash chain using a verifiable credential mechanism to obtain digital credentials. The digital credentials are used to verify the authenticity and integrity of the logs and are also used to enable the traceability of the logs. The first generation unit is further configured to: initiate a log agent in the trusted execution environment and generate a reference report for the log agent, wherein the log agent is a software component for generating the log, and the reference report includes code, configuration information, and platform identity; sign the reference report using the hardware key of the trusted execution environment to obtain a signed reference report; send the signed reference report to a remote verification service, wherein the remote verification service is a service for verifying whether the log agent is trustworthy; receive a report verification result sent by the remote verification service, wherein the report verification result indicates whether the log agent is trustworthy; if the report verification result indicates that the verification is successful, issue a verification token to the log agent, explaining that the verification token indicates that the identity and operating environment of the log agent have been proven to be trustworthy; and use the log agent to convert the event into a standardized data structure to obtain the log.

17. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the log management method as described in any one of claims 1 to 15.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the log management method as described in any one of claims 1 to 15.

19. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the log management method as described in any one of claims 1 to 15.

Images