Auditing method, electronic device, and storage medium

Abstract

Embodiments of the present disclosure provide an auditing method, an electronic device and a storage medium, which are applied to a service end of a distributed storage system. The service end comprises a distributed object storage engine and a plurality of metadata service processes. The method comprises: obtaining target data to be audited based on an audit probe deployed at a target interface in the metadata service process; generating an audit record entry corresponding to the target data according to a data operation request and a data operation response in the case that the data operation request in the target data meets a preset audit matching condition; writing the audit record entry into a first audit record set of the distributed object storage engine; and sorting the audit record entries in the first audit record set according to metadata service process identifiers and vector clock information in the distributed object storage engine to obtain a second audit record set after sorting, so as to audit data operations of a client based on the second audit record set, and safe and reliable audit records are achieved.

Description

Technical Field

[0001] This disclosure relates to the field of distributed storage technology, and more specifically, to an auditing method, electronic device, and storage medium. Background Technology

[0002] With the rapid development of cloud computing and big data technologies, distributed storage systems (such as the Ceph file system) are widely used to provide highly available and scalable shared storage services. By separating metadata management from data storage and supporting multiple metadata service processes to handle client requests simultaneously, distributed storage systems can significantly improve the system's concurrency and scalability. In a multi-active metadata service process deployment architecture, different client requests can be distributed to different metadata service processes for processing, thereby increasing the throughput of metadata operations. As the application scope of distributed storage systems expands and the requirements of scenarios such as security auditing and compliance supervision increase, how to achieve secure and reliable audit logs in distributed storage systems has become an urgent problem to be solved. Summary of the Invention

[0003] One objective of this disclosure is to provide a new technical solution regarding auditing methods for distributed storage systems.

[0004] According to a first aspect of the present disclosure, an auditing method is provided, applied to a server of a distributed storage system, the server including a distributed object storage engine and multiple metadata service processes, the metadata service processes being used to process data operation requests from clients; the method includes: The audit probe deployed at the target interface within the metadata service process is used to obtain the target data to be audited; wherein, the target interface includes a first interface for receiving and scheduling data operation requests from the client and a second interface for sending data operation responses to the client, and the target data includes the data operation requests and the data operation responses; If a data operation request in the target data meets a preset audit matching condition, an audit record entry corresponding to the target data is generated based on the data operation request and the data operation response; wherein, the audit record entry includes audit information, a metadata service process identifier that generated the audit record entry, and vector clock information; The audit record entries are written to the first audit record set of the distributed object storage engine; wherein, the first audit record set includes audit record entries written from multiple metadata service processes; In the distributed object storage engine, the audit record entries in the first audit record set are sorted according to the metadata service process identifier and the vector clock information to obtain a sorted second audit record set, so as to audit the data operations of the client based on the second audit record set.

[0005] Optionally, the vector clock information in the audit record entry includes logical clock count information corresponding to each metadata service process, which is written by the metadata service process that generates the audit record entry when generating the audit record entry. The step of sorting the audit record entries in the first audit record set according to the metadata service process identifier and the vector clock information to obtain a sorted second audit record set includes: Based on the logical clock count information corresponding to each metadata service process in the vector clock information, determine whether there is a causal order between any two audit record entries; In the case where there is a causal order between two audit record entries, a target order between the two audit record entries is determined based on the causal order. In the absence of a causal order between two audit record entries, the target order between the two audit record entries is determined based on the physical timestamp of the audit record entries and / or the metadata service process identifier; The second audit record set is generated by sorting the audit record entries according to the target order.

[0006] Optionally, determining the target order between two audit record entries based on the physical timestamp of the audit record entry and / or the metadata service process identifier includes: If the physical timestamps of two audit record entries are different, the target order between the two audit record entries is determined based on the physical timestamps; or, If two audit record entries have the same physical timestamp, the target order between the two audit record entries is determined based on the size order of the metadata service process identifier.

[0007] Optionally, writing the audit record entry into the first audit record set of the distributed object storage engine includes: The generated audit record entries are written to the buffer queue of the metadata service process; wherein the buffer queue is a lock-free circular buffer queue and is configured in a single producer single consumer mode. The asynchronous write module performs a batch write step to write audit record entries in the buffer queue to the first audit record set of the distributed object storage engine; the batch write step includes: reading audit record entries in batches from the buffer queue based on a set batch entry number, and writing the batch-read audit record entries into the first audit record set.

[0008] Optionally, during the batch write process, the asynchronous write module also performs an asynchronous write performance tuning step; the asynchronous write performance tuning step includes: If the number of audit record entries stored in the buffer queue is greater than or equal to a first preset threshold, the value of the batch entry number is increased to reduce the number of batch reads and writes. If the storage quantity is greater than or equal to the second preset quantity threshold, modify the preset audit matching conditions of the metadata service process to reduce the number of audit record entries written by the metadata service process to the buffer queue. If the number of stored items is greater than or equal to a preset maximum capacity threshold, the audit record entry written to the buffer queue first is discarded; wherein, the first preset number threshold is less than the second preset number threshold, and the second preset number threshold is less than the preset maximum capacity threshold.

[0009] Optionally, the asynchronous write performance tuning step further includes: If the number of consecutive failures when writing audit record entries read in batches into the first audit record set is greater than or equal to a preset failure count threshold, then the batch writing step is stopped, and the audit record entries are stored in the local storage of the metadata service process. After stopping the batch write step, a preset number of audit record entries are periodically written to the first audit record set. If the preset number of audit record entries are successfully written, the batch write step is restarted.

[0010] Optionally, generating audit record entries corresponding to the target data based on the data operation request and the data operation response includes: Generate initial audit record information corresponding to the target data based on the data operation request and the data operation response; If the initial audit record information is the first audit record of the metadata service process, a checksum is generated based on the initial audit record information, and the audit record entry is generated based on the checksum and the initial audit record information; or, If the initial audit record information is not the first audit record, a verification value is generated based on the historical verification values ​​in the audit record entries generated before the initial audit record information and the initial audit record information. The audit record entry is then generated based on the verification value and the initial audit record information.

[0011] Optionally, the server further includes a monitoring engine; after writing the audit record entries into the first audit record set of the distributed object storage engine, the method further includes: If the audit record entries recorded in the first audit record set meet the preset verification value storage conditions, the verification values ​​in the audit record entries are sorted according to the generation order of the audit record entries to generate an anchor record set. The anchor point record set is submitted to the monitoring engine, and the monitoring engine stores the anchor point record set. When performing integrity verification on the first audit record set and / or the second audit record set, the audit record is determined to have been tampered with by recalculating the check value of the audit record entry and comparing it with the check value in the anchor record set.

[0012] Optionally, the audit record entries in the second audit record set include a user identifier that initiated the operation request based on the client; the auditing of the client's data operations based on the second audit record set includes: Obtain the current operation characteristics of each user within the current sliding time window; wherein, the current operation characteristics include one or more current operation types and the current number of operations corresponding to each current operation type; If the current operation feature meets the preset anomaly detection conditions, an anomaly detection alarm is output; wherein, the anomaly detection alarm includes an abnormal operation mode, and the abnormal operation mode includes at least one of batch deletion operation mode, abnormal time period operation mode, unauthorized operation attempt mode or abnormal path operation mode. The anomaly detection conditions include at least one of the following: The similarity between the current operation feature and the user's historical operation feature baseline is less than a preset similarity threshold; wherein, the historical operation feature baseline is a feature baseline obtained by weighted averaging of historical operation features based on multiple historical sliding time windows; The current operation type in the current operation feature includes a preset operation type, and the current operation count of the preset operation type is greater than a preset count threshold.

[0013] Optionally, the data operation request includes at least one of the following: operation type, user identifier, target path of the data to be operated, or operation request parameters.

[0014] Optionally, the data operation response includes at least one of the following: operation result, error code, or operation duration.

[0015] Optionally, the preset audit matching conditions include at least one of operation type matching conditions, user identifier matching conditions, target path matching conditions, and audit level matching conditions.

[0016] Optionally, the audit information in the audit record entry includes at least one of the following: operation type, user identifier, target path of the data to be operated, operation request parameters, operation timestamp, or operation result; the audit record entry is encapsulated based on a pre-defined data format.

[0017] According to a second aspect of the present disclosure, an electronic device is provided, including a memory and a processor, the memory being configured to store a computer program, and the processor being configured to invoke the computer program from the memory to perform the method described in the first aspect.

[0018] According to a third aspect of the present disclosure, a computer-readable storage medium is provided having a computer program stored thereon, the computer program implementing the method described in the first aspect when executed by a processor.

[0019] Based on the auditing method provided in this disclosure, an audit probe is deployed within the metadata service process of a distributed storage system. Target data is filtered using preset audit matching conditions, and the generated audit record entries carry metadata service process identifiers and vector clock information. Audit record entries from multiple metadata service processes are then uniformly written into the distributed object storage layer and globally sorted based on the aforementioned identifiers and vector clock information. This achieves end-to-end audit record collection for user file operations and globally ordered aggregation of audit record entries across multiple processes within a distributed deployment architecture where multiple active metadata service processes concurrently process client requests. The sorted audit record set provides a timeline-consistent and causally ordered global view of user operations, thus realizing secure and reliable audit records in the distributed storage system to meet the auditing needs of scenarios such as security auditing and compliance supervision.

[0020] Other features and advantages of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the disclosure.

[0022] Figure 1This is a schematic diagram of the architecture of a distributed storage system that can apply the technical solutions provided in the embodiments of this disclosure.

[0023] Figure 2 This is a flowchart illustrating an auditing method provided in an embodiment of this disclosure.

[0024] Figure 3 This is a schematic diagram of an asynchronous writing process for audit record entries provided in an embodiment of this disclosure.

[0025] Figure 4 This is a flowchart illustrating another auditing method provided in this embodiment.

[0026] Figure 5 This is a schematic diagram of the architecture of a distributed storage system provided in an embodiment of this disclosure.

[0027] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0028] Various exemplary embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0029] The following description of at least one exemplary embodiment is merely illustrative and is not intended to limit this disclosure or its application or use. Techniques, methods, and apparatus known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and apparatus may be considered part of the specification.

[0030] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it need not be discussed further in subsequent figures.

[0031] It should be noted that the actions involved in the collection, storage, use, processing, transmission, provision, disclosure, and deletion of data in this disclosure embodiment are all carried out in compliance with the relevant data protection laws and regulations of the country or region where the data is located, and with the full authorization of the relevant data owner.

[0032] This disclosure relates to a technical solution for an auditing method, such as an auditing scheme for user operations in a distributed storage system. Figure 1 This is a schematic diagram of the structure of a distributed storage system that can apply the technical solutions provided in the embodiments of this disclosure. For example... Figure 1As shown, the distributed storage system may include a server 100 and a client 200, which can communicate with each other via a network connection. The server 100 may include at least one of a metadata service process 101, a distributed object storage engine 102, and a monitoring engine 103. The metadata service process 101 can handle data operation requests sent by the client 200. The distributed object storage engine 102 can be used to store audit-related data, such as storing an audit record set (also known as an audit log), which may include multiple audit record entries. The monitoring engine 103 can be used to maintain the cluster state mapping of the distributed storage system and manage authentication and authorization.

[0033] For example, the distributed storage system can be a Ceph distributed storage system, which can also be called a Ceph file system (CephFS), such as a POSIX-compliant distributed file system, which can define a standard interface for file system operations.

[0034] The metadata server (MDS), also known as a metadata service process, is a service process in a distributed storage system used to handle file system metadata operations (such as directory traversal, permission checks, attribute modification, data reading, and data modification). For example, it can handle client data operation requests and / or send data operation responses to clients. Metadata server processes in a distributed storage system can support multi-active deployment (Multi-Active MDS), allowing multiple metadata server processes (or instances) to simultaneously handle requests from different subdirectory trees or data operation requests from different clients, thereby improving data processing performance in the distributed storage system.

[0035] A distributed object storage engine can be the underlying storage engine of a distributed storage system. For example, it can implement a reliable autonomous distributed object store (RADOS). This distributed object storage engine can store actual data, such as actual file data and metadata objects, based on the object storage daemon (OSD).

[0036] A monitoring engine (Monitor) can be a monitoring daemon of a distributed storage system, used to maintain the cluster state mapping of the distributed storage system, manage authentication and authorization, and provide consensus services. For example, it can achieve the consistency of the cluster state of the distributed storage system based on a distributed consensus algorithm (such as Paxos).

[0037] Clients can include kernel clients (such as kclient) and / or user-space clients (such as FUSE or libcephfs) that mount file systems and send data operation requests to the server. For example, they can send metadata requests to the server's metadata service process or send data read and write requests to the distributed object storage engine.

[0038] It should be noted that, Figure 1 The structure of the distributed storage system shown is illustrative. The distributed storage system in this embodiment is not limited to the above structure and may include more or fewer devices and / or modules as needed, and the devices and / or modules may be combined or split. For example, the distributed storage system may only include the above-mentioned server; for another example, the above-mentioned server may only include a metadata service process and a distributed object storage engine; for yet another example, the above-mentioned server may also include other modules such as a management module (Manager, MGR), which may be the management daemon of the distributed storage system, providing monitoring, dashboard, and extension module functions.

[0039] based on Figure 1 The distributed storage system shown allows clients to send data operation requests (e.g., metadata requests) to the metadata service process when accessing the system. In related technologies, after the metadata service process processes the client request, the relevant operation context information (e.g., user identity, operation type, file path, etc.) is discarded and not persisted as audit logs. This results in a lack of systematic auditing capabilities in the distributed storage system.

[0040] Furthermore, the distributed storage system in the related technologies also has the following problems: In the multi-active metadata service process deployment architecture, different client requests are distributed to different metadata service processes for processing, and the audit log information lacks a globally ordered view across multiple processes, making it difficult to build a complete view of user operations; the audit log information is usually stored in an append-only manner, lacking an effective anti-tampering protection mechanism, and attackers with administrator privileges may modify or delete audit logs to cover up operation traces, lacking anti-tampering capabilities; and it cannot automatically identify abnormal operation patterns (such as abnormal data deletion).

[0041] This disclosure provides a novel auditing method for distributed storage systems. By embedding audit probes in the request processing pipeline of the metadata service process and implementing global ordered aggregation of distributed audit logs based on a vector clock mechanism, the above-mentioned problems can be solved in whole or in part.

[0042] The following combination Figure 1 The illustrated distributed storage system illustrates the specific implementation of the embodiments of this disclosure.

[0043] Figure 2 This is a flowchart illustrating an auditing method provided in an embodiment of this disclosure. The auditing method can be performed by... Figure 1 The server-side execution shown can be performed by any electronic device. For example, it can be applied to the server of a distributed storage system, which may include a distributed object storage engine and multiple metadata service processes that can handle client data manipulation requests. Figure 2 As shown, the auditing method in this embodiment may include the following steps S210 to S240.

[0044] Step S210: Obtain the target data to be audited based on the audit probe deployed at the target interface within the metadata service process.

[0045] In some examples, the target interface may include a first interface for receiving and scheduling data operation requests from clients, and a second interface for sending data operation responses to clients. The target data may include both the data operation requests and the data operation responses.

[0046] The first interface can be an interface for receiving and scheduling data operation requests from clients. For example, it could include the `dispatch_client_request` method in the metadata service process, which serves as the unified logical entry point for all data operation requests (e.g., metadata requests) sent by clients to the metadata service process. The audit probe can intercept these data operation requests at this first interface to obtain information related to the operation intent. For instance, the data operation request might include at least one of the following: operation type, user identifier, target path of the data to be operated on, or operation request parameters.

[0047] The second interface can be an interface used to send data operation responses to the client. For example, the second interface may include a `respond_to_request` method or an `early_reply` method in the metadata service process. At this second interface, the audit probe can intercept the data operation responses sent by the metadata service process to the client and obtain information related to the operation results. For example, the data operation response may include at least one of the following: operation result (success / failure), error code, or operation duration.

[0048] In this way, audit probes can be deployed at the target interface within the metadata service process to intercept and obtain the target data to be audited, enabling comprehensive capture of client data operation requests and responses.

[0049] In some examples, this audit probe may also be called an audit module or an audit interceptor. This audit probe can be embedded into the target interface using either a function hook or Aspect-Oriented Programming (AOP). Function hooks can insert custom logic before and after the execution of the target function to capture the function's input parameters and return values. AOP allows the audit logic to be implemented independently as a cross-cutting concern, implanted into the target interface at compile time or runtime. This allows for the embedding of audit functionality without modifying the core business logic of the metadata service process, reducing code coupling and improving system maintainability.

[0050] In other examples, audit probes can be configured for asynchronous interception. For instance, after intercepting target data, the data can be copied to a separate buffer, and then control can be returned to the main processing flow of the metadata service process, avoiding blocking client request processing. The audit probe can then use a separate background thread to read the target data from the buffer and perform subsequent processing. This decouples audit logic from business logic, preventing audit operations from impacting the performance of the metadata service process.

[0051] In some examples, the aforementioned data operation request may include at least one of the following: operation type, user identifier, target path of the data to be operated on, or operation request parameters; the aforementioned data operation response may include at least one of the following: operation result, error code, or operation duration. The operation type can characterize the specific metadata operation requested by the client, such as file open, file create, file delete, directory delete, file rename, attribute modification, file write, and file read. In distributed storage systems (such as CephFS), the operation type can be identified by the CEPH_MDS_OP_* enumeration value; for example, CEPH_MDS_OP_OPEN represents an open file operation, and CEPH_MDS_OP_UNLINK represents a delete file operation. The user identifier may include the user identifier (User ID, UID), group identifier (Group ID, GID), or authentication entity name (auth_name) of the operation initiator. UID and GID can be used to identify the operating system user identity of the client process, and auth_name can be used to identify the client's authentication entity in the distributed storage system authentication protocol (such as Cephx). User identification identifies the user performing the operation, providing crucial information for audit analysis. The target path of the data to be operated on identifies the complete path of the file or directory requested by the client. For example, for a file deletion operation, the target path could be ` / data / project / report.pdf`; for a rename operation, the target path could include both the source and destination paths. Operation request parameters can include additional parameters related to the operation, such as open flags for file open operations (O_RDONLY, O_WRONLY, O_RDWR, O_CREAT, etc.), permission mode, and file layout. The operation result identifies the execution outcome of the metadata operation, such as success or failure. Error codes identify the specific reasons for operation failure, such as permission denied (EACCES), file not found (ENOENT), and operation not allowed (EPERM). The operation duration identifies the processing time from receiving the request to sending the response for the metadata operation; the unit of operation duration can be microseconds or milliseconds. By analyzing the operation result, error codes, and operation duration, the execution status and performance characteristics of the operation can be determined.

[0052] Step S220: If the data operation request in the target data meets the preset audit matching conditions, generate an audit record entry corresponding to the target data based on the data operation request and the data operation response.

[0053] The audit record entry may include audit information, the metadata service process identifier that generated the audit record entry, and vector clock information.

[0054] For example, the audit information may include information extracted from data operation requests and data operation responses. For instance, the audit information may include at least one of the following: operation type, user identifier, target path of the data to be operated, operation request parameters, operation timestamp, or operation result.

[0055] The Metadata Service Process ID (MDS ID) can be used to uniquely identify a metadata service process (e.g., an instance) in a distributed storage system, with different metadata service processes corresponding to different IDs.

[0056] The vector clock information can include logical clock counts written by the metadata service process that generates the audit log entry when generating the audit log entry, corresponding to the respective metadata service processes. For example, a vector clock (VC) can be a logical clock algorithm used in a distributed system to determine the causal order of events. In a multi-active metadata service process scenario, each metadata service process can maintain a local monotonically increasing logical clock. A vector clock can be represented as a multi-dimensional vector, with each dimension corresponding to the logical clock count value of a metadata service process. For instance, if a distributed storage system includes three metadata service processes with process identifiers mds.0, mds.1, and mds.2, then the vector clock can be represented as VC = {mds.0:c_0, mds.1:c_1, mds.2:c_2}, where c_0, c_1, and c_2 represent the logical clock count values ​​of mds.0, mds.1, and mds.2, respectively. When the metadata service process mds.0 generates an audit record entry, mds.0 increments its own maintained logical clock count value c_0 by 1 and writes the complete vector clock VC={mds.0:c_0+1, mds.1:c_1, mds.2:c_2} into the audit record entry. In this way, the vector clock information carried by the audit record entry can characterize the logical clock state of each metadata service process at the time the record is generated. It should be noted that metadata service processes can interact through distributed operations (such as cross-subtree renaming), during which vector clocks can be exchanged and merged. For example, when the metadata service process mds.0 needs to collaborate with mds.1 to complete an operation, mds.0 can send its own vector clock VC_0 to mds.1. After receiving VC_0, mds.1 can merge VC_0 with its own vector clock VC_1, with the merging rule being: for each component of the vector, take the maximum value of that component from the two vectors. For example, given VC_0 = {mds.0:10, mds.1:5, mds.2:3} and VC_1 = {mds.0:8, mds.1:12, mds.2:6}, the merged vector clock would be VC_merged = {mds.0:10, mds.1:12, mds.2:6}. By exchanging and merging vector clocks, causal information can be propagated in a distributed environment.

[0057] In some examples, the above-mentioned preset audit matching conditions may include at least one of operation type matching conditions, user ID matching conditions, target path matching conditions, and audit level matching conditions.

[0058] This operation type matching condition can be used to determine the list of operation types that need to be audited. For example, it can be configured to audit only write operations (including create, modify, delete, rename, etc.), or only high-risk operations (such as delete, rename). The operation type matching condition can be configured through the parameter audit_ops, for example, audit_ops=[unlink, rename, setattr, open, write].

[0059] User ID matching criteria can be used to determine the user IDs that need to be audited. For example, whitelist mode or blacklist mode can be supported. Whitelist mode can specify that only the operations of specific users should be audited, while blacklist mode can specify that only the operations of specific users should be excluded. User ID matching criteria can be configured through the parameters audit_uid_whitelist or audit_uid_blacklist. For example, if audit_uid_whitelist is configured as =[1000,1001], it means that only the operations of users with UIDs of 1000 and 1001 should be audited.

[0060] The target path matching criteria can specify that only operations under a specific path prefix should be audited. For example, it can be configured to audit only operations under the paths / sensitive / and / finance / . The target path matching criteria can be configured through the parameter audit_path_prefixes, for example, audit_path_prefixes=[ / sensitive / 、 / finance / ].

[0061] Audit level matching criteria can specify the granularity of auditing, such as off (meaning auditing is disabled), basic (meaning only write operations are audited), standard (meaning read and write operations are audited), and full (meaning all operations are audited). Audit level matching criteria can be configured through the parameter audit_level.

[0062] In some examples, preset audit matching conditions can support multi-dimensional combined filtering. For instance, it can be configured to audit deletion and renaming operations of the user with UID 1000 under the / sensitive / path, with corresponding matching conditions including: audit_uid_whitelist=

[1000] , audit_path_prefixes = [ / sensitive / ], audit_ops=[unlink, rename]. Through multi-dimensional combined filtering, fine-grained audit strategy configuration can be achieved, flexibly balancing audit coverage and performance overhead.

[0063] In other examples, preset audit matching criteria can be dynamically adjusted. When the distributed storage system detects excessive write pressure on audit log entries, it can automatically reduce the audit granularity, for example, from the full level to the standard level, or narrow the target path matching range. When the audit log write pressure returns to normal, the original audit matching criteria can be automatically restored. In this way, as much audit information as possible can be recorded while improving the stability of the audit system.

[0064] In some examples, the audit log entries described above can be encapsulated based on a predefined data format, which may include JavaScript Object Notation (JSON) or other preset formats. For instance, the audit log entries can be serialized using JSON Lines format, where each audit log entry occupies one line, and each line is a separate JSON object. JSON Lines format facilitates streaming processing and batch writing, improving the efficiency of audit log writing.

[0065] In other examples, audit log entries can be compressed to reduce storage space usage and network transmission overhead. The compression can employ any compression algorithm (such as gzip).

[0066] Step S230: Write the audit record entries into the first audit record set of the distributed object storage engine.

[0067] The first audit record set may include audit record entries written by multiple metadata service processes. This first audit record set may be stored in, for example... Figure 1 The distributed object storage engine shown.

[0068] For example, this distributed object storage engine (such as RADOS) can provide highly reliable and highly available distributed object storage services, supporting replication and erasure coding mechanisms to achieve data persistence. The first audit record set can be stored in a separate object pool (e.g., cephfs.audit) within the distributed object storage engine, which can be configured with an independent number of replicas and storage strategies.

[0069] For example, audit log entries can be stored in shards according to the metadata service process identifier and time period. For instance, the first audit log set may include multiple audit log objects, and the naming convention for these objects can be audit.{mds_id}.{date}.{hour}, where mds_id represents the metadata service process identifier, date represents the date, and hour represents the hour. For example, audit.0.20250315.10 represents an audit log entry generated by the metadata service process mds.0 during the time period from 10:00 to 11:00 on March 15, 2025. Sharding storage enables parallel writing and querying of audit logs, improving system performance.

[0070] In this step, there are several ways to write audit record entries to the first audit record set of the distributed object storage engine.

[0071] For example, audit record entries can be written in real time, that is, written directly after the audit record entry is generated, in order to improve the timeliness of writing.

[0072] For example, audit log entries can be written in batches. The metadata service process can first cache the generated audit log entries in a local memory buffer. When the number of records in the buffer reaches a preset batch entry limit (e.g., 100 records) or the time interval since the last write reaches a preset time threshold (e.g., 1 second), a batch write operation is triggered, writing all the audit log entries in the buffer to the distributed object storage engine at once. Batch writing can reduce the number of interactions with the distributed object storage engine, reduce network overhead, and improve write efficiency.

[0073] For example, audit log entries can be written asynchronously. The metadata service process can add generated audit log entries to an asynchronous write queue, and a separate background write thread can read the audit log entries from the queue and perform the write operation. Asynchronous writing avoids the audit log write operation blocking the main processing flow of the metadata service process, so that the response time of metadata operations is not affected by the audit system.

[0074] In step S240, in the distributed object storage engine, the audit record entries in the first audit record set are sorted according to the metadata service process identifier and vector clock information to obtain a sorted second audit record set, so as to audit the client's data operations based on the second audit record set.

[0075] For example, in a distributed storage system, multiple metadata service processes run in parallel, each independently generating audit record entries and writing them into a first audit record set. This first audit record set includes audit record entries independently written by multiple metadata service processes, and the writing order of these entries does not necessarily correspond to the actual order of data operations. In this step, each audit record entry corresponds to vector clock information. By comparing the vector clocks of any two audit record entries, it can be determined whether a causal relationship exists between them (i.e., which occurred first). If a causal relationship exists, they are arranged in causal order; otherwise, if no causal relationship exists (concurrent events), they can be sorted based on physical timestamps and / or metadata service process identifiers as auxiliary sorting criteria. Thus, audit record entries can be sorted based on metadata service process identifiers and vector clock information. The resulting second audit record set can be a globally ordered sequence of audit records that conforms to causal relationships. Based on this second audit record set, auditing of client data operations (e.g., anomaly detection, compliance review, event tracing, etc.) can be performed, improving the reliability and completeness of audit backtracking and analysis.

[0076] In some examples, audits can be conducted jointly based on the first audit record set and the second audit record set. For example, the accuracy of the contents of the second audit record set can be verified based on the first audit record set to further improve the reliability of the audit.

[0077] Using the method described in steps S210 to S240 above, an audit probe is deployed within the metadata service process of the distributed storage system. Target data is filtered using preset audit matching conditions, and the generated audit record entries carry the metadata service process identifier and vector clock information. Audit record entries from multiple metadata service processes are then uniformly written into the distributed object storage layer and globally sorted based on the identifier and vector clock information. This achieves end-to-end audit record collection for user file operations and globally ordered aggregation of audit record entries across multiple processes within a distributed deployment architecture where multiple active metadata service processes concurrently handle client requests. Based on the sorted audit record set, a timeline-consistent and causally ordered global view of user operations is provided. This enables secure and reliable audit records in the distributed storage system, meeting the audit requirements of security auditing and compliance supervision scenarios.

[0078] In some examples of the present disclosure, the manner of sorting the audit record entries in the first audit record set in step S240 described above may include: determining whether a causal order exists between any two audit record entries based on the logical clock count information corresponding to each metadata service process in the vector clock information; in response to a causal order existing between two audit record entries, determining a target order between the two audit record entries based on the causal order; sorting the audit record entries according to the target order to generate a second audit record set.

[0079] For any two audit record entries A and B, it can be determined whether there is a causal order between them by comparing the partial order of their vector clocks VC_A and VC_B. The specific partial order comparison rule may include: if all components of VC_A are not greater than the corresponding components of VC_B, and at least one component is smaller than the corresponding component of VC_B, it is determined that VC_A is less than VC_B, denoted as VC_A<VC_B, that is, audit record entry A causally precedes audit record entry B. Conversely, if all components of VC_B are not greater than the corresponding components of VC_A, and at least one component is smaller than the corresponding component of VC_A, it is determined that VC_B is less than VC_A, denoted as VC_B<VC_A, that is, audit record entry B causally precedes audit record entry A. If neither VC_A<VC_B nor VC_B<VC_A is satisfied between VC_A and VC_B, it is determined that VC_A and VC_B are incomparable, at which point audit record entries A and B are concurrent events with no causal order therebetween.

[0080] For example, if VC_A={mds.0:10, mds.1:5, mds.2:3} and VC_B={mds.0:12, mds.1:5, mds.2:4}, since all components of VC_A are not greater than the corresponding components of VC_B (10≤12, 5≤5, 3≤4) and there are components that are strictly smaller (10<12, 3<4), VC_A<VC_B is satisfied, audit record entry A causally precedes audit record entry B, and in the sorted second audit record set, A should be placed before B.

[0081] For another example, if VC_A={mds.0:10, mds.1:8, mds.2:3} and VC_B={mds.0:9, mds.1:5, mds.2:6}, since some components of VC_A are greater than the corresponding components of VC_B (10>9, 8>5) while some components are smaller than the corresponding components of VC_B (3<6), VC_A and VC_B are incomparable, and audit record entries A and B are concurrent events with no causal order therebetween.

[0082] In some examples, the partial order comparison of vector clocks can be implemented by component-wise comparison. For a distributed storage system including n metadata service processes, the vector clock includes n components, and the time complexity of the partial order comparison is O(n). To improve comparison efficiency, the vector clock can be represented in an optimized manner, for example, using a sparse vector representation (recording only non-zero components), or using a hash table representation (taking the metadata service process identifier as the key and the logical clock count value as the value), which is not limited in this example.

[0083] In some examples, when there is no causal order between two audit record entries, the target order between the two audit record entries is set randomly.

[0084] In other examples, when there is no causal order between two audit record entries, the target order between the two audit record entries may be determined according to the physical timestamp of the audit record entries and / or the metadata service process identifier. The physical timestamp may be the physical time recorded when the metadata service process generates the audit record entry, such as GPS time or local time.

[0085] In this example, sorting may be performed first based on the physical timestamp, and then based on the metadata service process identifier when the physical timestamps are the same. Exemplarily, if the physical timestamps of the two audit record entries are different, the target order between the two audit record entries may be determined based on the physical timestamps. The audit record entry with an earlier physical timestamp is ranked before, and the audit record entry with a later physical timestamp is ranked after. Alternatively, if the physical timestamps of the two audit record entries are the same, the target order between the two audit record entries may be determined based on the magnitude order of the metadata service process identifiers. The audit record entry with a smaller metadata service process identifier is ranked before, and the audit record entry with a larger metadata service process identifier is ranked after.

[0086] For example, if the physical timestamp of audit record entry C is 2025-03-15T10:23:45.678912Z, and the metadata service process identifier is mds.0; the physical timestamp of audit record entry D is 2025-03-15T10:23:45.678912Z, and the metadata service process identifier is mds.1. Since the physical timestamps of the two audit record entries are the same, sorting can be performed according to the magnitude order of the metadata service process identifiers, where mds.0 < mds.1, so audit record entry C is ranked before D.

[0087] In this example, sorting can be performed first based on the metadata service process identifier, and then, if the metadata service process identifiers are the same, sorting can be performed based on the physical timestamp. For instance, if two audit record entries have different metadata service process identifiers, the target order between the two audit record entries can be determined based on the size of the metadata service process identifiers. The audit record entry with the smaller metadata service process identifier is listed first, and the audit record entry with the larger metadata service process identifier is listed later. Further, if two audit record entries have the same metadata service process identifier, the target order between the two audit record entries can be determined based on the physical timestamp. The audit record entry with the earlier physical timestamp is listed first, and the audit record entry with the later physical timestamp is listed later.

[0088] In this way, by combining the causal order of vector clocks with auxiliary sorting based on physical timestamps and / or metadata service process identifiers, all audit record entries in the first audit record set can be sorted by total order to generate a sorted second audit record set. The audit record entries in the second audit record set are arranged in causal and chronological order, providing security administrators with a consistent, time-ordered global operational view, facilitating event forensics and causal analysis.

[0089] In some examples, the sorting operation can be performed within the audit analysis module of the distributed object storage engine. The audit analysis module can periodically read new audit record entries from a first audit record set, perform the sorting operation, and write the sorting result to a second audit record set. The sorting operation can employ a merge sort algorithm, leveraging the fact that audit record entries generated by each metadata service process are already ordered on their respective timelines, to merge multiple ordered sequences into a globally ordered sequence.

[0090] In other examples, the sorting operation can use incremental sorting. The audit analysis module can maintain a global sorting state, recording the maximum vector clock and maximum physical timestamp of the currently sorted audit record entries. When a new audit record entry arrives, the audit analysis module can determine its insertion position in the global sorting based on the new record's vector clock and physical timestamp, and perform an incremental insertion operation. Incremental sorting avoids reordering all audit record entries, improving sorting efficiency.

[0091] In some examples of this disclosure, the method of auditing the client's data operations based on the second audit record set in step S240 above may include: obtaining the current operation characteristics of each user within the current sliding time window based on the second audit record set; if the current operation characteristics meet the preset anomaly detection conditions, then outputting an anomaly detection alarm.

[0092] For example, the audit record entries in the second audit record set may include user identifiers based on the data operation requests initiated by the client, with each user identifier corresponding to one user. For each user, the audit record entry for that user can be extracted from the second audit record set based on their user identifier, and the current operation characteristics of that user within the current sliding time window can be statistically analyzed.

[0093] In some examples, the aforementioned current operation feature may include one or more current operation types and the number of current operations corresponding to each current operation type. For instance, the current operation feature may be represented as an operation frequency vector, including one or more of the following: read operation count (read_count), create operation count (create_count), modify operation count (modify_count), delete operation count (delete_count), rename operation count (rename_count), etc. Furthermore, the current operation feature may also include an operation time distribution (e.g., a 24-hour distribution of the number of operations) and a path access heatmap (e.g., the number of accesses to each target path).

[0094] In some examples, the sliding time window described above can be a fixed-length time interval, such as 30 minutes or 60 minutes. The sliding time window can be continuously slid forward over time, statistically analyzing the user's operational characteristics within the window. By using the sliding time window for statistical analysis, the changing trends of user behavior over time can be captured.

[0095] In some examples, the above anomaly detection conditions may include the following first anomaly detection conditions and / or second anomaly detection conditions, wherein: the first anomaly detection condition may characterize that the similarity between the current operation feature and the user's historical operation feature baseline is less than a preset similarity threshold; the second anomaly detection condition may characterize that the current operation type in the current operation feature includes a preset operation type, and the current operation count of the preset operation type is greater than a preset count threshold.

[0096] The historical operation feature baseline can be obtained by weighted averaging of historical operation features across multiple historical sliding time windows. For example, the Exponential Weighted Moving Average (EWMA) algorithm can be used to smooth the historical operation features. The EWMA algorithm assigns higher weights to more recent historical data and lower weights to earlier historical data, thereby establishing a baseline model that reflects the user's long-term operating habits. This historical operation feature baseline may include one or more of the following features: baseline operation rate (e.g., 10 times / minute), baseline deletion operation percentage, baseline active periods, etc. This historical operation feature baseline can also be referred to as a user behavior profile.

[0097] The aforementioned similarity can be calculated using metrics such as cosine similarity, Euclidean distance, and Manhattan distance. For example, the cosine similarity between the current operation feature vector and the historical operation feature baseline vector can be calculated. If the cosine similarity is less than a preset similarity threshold (e.g., 0.6 or 0.7), it can be determined that the current operation feature deviates significantly from the historical baseline, triggering an anomaly detection alarm.

[0098] The aforementioned preset operation types can be high-risk operation types, such as deletion operations. The preset count threshold can be dynamically set based on the user's historical operation characteristics baseline. For example, it can be set to 3 times the historical baseline number of deletion operations. If the number of deletion operations performed by the user within the current sliding time window exceeds the preset count threshold, it can be determined that the user may be performing a batch deletion operation, triggering an anomaly detection alarm.

[0099] In some examples, the anomaly detection alert can be output through multiple channels, such as cluster logs (clog), audit log tags, the management module (MGR) alert interface, and external integration interfaces (e.g., webhooks). Cluster logs can be output in real-time to the distributed storage system's cluster monitoring interface, allowing security administrators to observe alert information in real-time using command-line tools (e.g., ceph -w). Audit log tags can attach anomaly markers to corresponding audit record entries, facilitating rapid identification of abnormal operations during subsequent audit analysis. The management module alert interface can push alert information to external monitoring systems via a REST API. External integration interfaces can push alert information to external alert platforms (e.g., Prometheus Alertmanager) via webhooks, enabling integration with the enterprise security operations center.

[0100] In other examples, the anomaly detection alert can support alert level classification, which can include high risk (HIGH), medium risk (MEDIUM), or low risk (LOW). Different alert levels can be handled with different strategies. For example, high-risk alerts can immediately notify the security administrator and trigger automatic response measures (such as temporarily freezing user accounts), medium-risk alerts can be logged to the audit log and periodically summarized in reports, and low-risk alerts can be logged only to the audit log for post-event analysis.

[0101] In some examples, the above-mentioned anomaly detection alarm may include an abnormal operation mode, which may include at least one of the following: batch deletion operation mode, abnormal time period operation mode, unauthorized operation attempt mode, or abnormal path operation mode.

[0102] This batch deletion operation mode can be determined based on the following detection rules: the number of deletion operations performed by the user within the sliding time window exceeds a preset threshold, and the percentage of deletion operations (number of deletion operations divided by the total number of operations) is greater than N times (e.g., 3 times) of the historical baseline. This batch deletion operation mode can be used in scenarios such as ransomware attacks or malicious deletion by internal personnel. Optionally, the corresponding anomaly alert level for this batch deletion operation mode can be high risk.

[0103] The abnormal operation pattern during this period can be determined based on the following detection rules: the current operation period is not within the user's baseline active period set, and the operation involves write or delete operations. The baseline active period set can be established by statistically analyzing the user's historical operation time distribution, for example, by counting the number of user operations within each hourly segment, and marking periods with more than a threshold as active periods. The abnormal operation pattern during this period could be a scenario such as account theft or unauthorized access. Optionally, the abnormal alarm level corresponding to this abnormal operation pattern can be medium risk.

[0104] This unauthorized operation attempt mode can be determined based on the following detection rule: the number of permission denial errors (e.g., EACCES, EPERM) committed by the user within the sliding time window exceeds a preset threshold. The unauthorized operation attempt mode can be a scenario such as permission escalation attempt or path probing. Optionally, the corresponding abnormal alarm level for this unauthorized operation attempt mode can be high risk.

[0105] The abnormal path operation pattern can be determined based on the following detection rule: the path accessed by the user is significantly different from its historical path heatmap. The historical path heatmap can be established by statistically analyzing the paths involved in the user's historical operations (e.g., by first-level directory) and their access frequency. Jaccard similarity (e.g., intersection-union ratio) can be used to measure the similarity between the current access path set and the historical path set. If the similarity is less than a preset threshold (e.g., 0.5), it can be determined that the user has accessed an abnormal path, triggering an anomaly detection alarm. The abnormal path operation pattern can be a scenario such as lateral movement or data reconnaissance. Optionally, the anomaly alarm level corresponding to this abnormal path operation pattern can be low risk.

[0106] The above methods enable comprehensive auditing of client operations in distributed storage systems, global ordered aggregation of distributed audit logs through vector clock mechanisms, and automatic identification of potential security threats through user behavior profiling and anomaly detection mechanisms, thereby improving security operation efficiency.

[0107] It should be noted that in step S240 above, the client's data operations can also be audited based on the first audit record set. For example, it can be based on the audit record entries in each metadata service process: obtain the current operation characteristics of each user in the current sliding time window; if the current operation characteristics meet the preset anomaly detection conditions, then output an anomaly detection alarm.

[0108] In some examples of this disclosure, when writing audit record entries to the first audit record set of the distributed object storage engine in step S230 above, an asynchronous write mechanism may be used. Figure 3 This is a schematic diagram of an asynchronous write process for audit record entries provided in an embodiment of this disclosure. Figure 3 As shown, the generated audit record entries can be written to the buffer queue of the metadata service process; the batch write step is performed by the asynchronous write module to write the audit record entries in the buffer queue to the first audit record set (e.g., the audit object pool) of the distributed object storage engine.

[0109] In some examples, the buffer queue can be a lock-free circular buffer queue, configured in a Single Producer Single Consumer (SPSC) mode. The lock-free circular buffer queue is an efficient concurrent data structure, implemented using a circular array, and can maintain read and write pointers through atomic operations, avoiding the use of mutex locks and thus eliminating the performance overhead caused by lock contention. The single producer single consumer mode can include: the buffer queue has only one producer (e.g., an audit log generator) and one consumer (an asynchronous write module). The producer writes audit log entries to the queue, and the consumer reads audit log entries from the queue and performs the write operation. The producer can run in the main processing flow of the metadata service process. When an audit log entry is generated, it can be appended to the tail of the buffer queue. Due to the use of a lock-free circular buffer queue, the time complexity of the append operation is O(1), and it will not block the main processing flow.

[0110] For example, the capacity of this buffer queue is configurable (default 10,000 entries), and can be implemented, for instance, by pre-allocating memory. When the metadata service process starts, a fixed-size circular array (e.g., space for 10,000 entries) can be pre-allocated to avoid dynamic memory allocation at runtime and improve memory access efficiency.

[0111] Furthermore, this buffer queue can support overflow protection mechanisms. When the buffer queue is full, a strategy of discarding the oldest record can be adopted, discarding the audit record entry at the head of the queue to make room for new audit record entries. The discarding operation can output alarm information through the cluster log (clog) to notify the security administrator that the audit system is experiencing excessive write pressure.

[0112] In some examples, the asynchronous write module described above can be a separate background thread in the metadata service process, used to read audit record entries from the head of the buffer queue and perform batch write steps.

[0113] For example, the batch write step may include: reading audit record entries in batches from a buffer queue based on a set batch entry number, and writing the batch-read audit record entries into the first audit record set of the distributed object storage engine. This batch entry number can be set to 100 entries. The asynchronous write module can read 100 audit record entries from the buffer queue each time (or read all entries in the queue if there are fewer than 100), and write multiple audit record entries into the first audit record set of the distributed object storage engine at once. In this way, batch writing reduces the number of interactions with the distributed object storage engine, lowers network overhead, and improves write efficiency.

[0114] In some examples, this batch write step can also be time-triggered. For instance, a batch write operation can be set to trigger every second, even if the number of audit log entries in the buffer queue has not reached the batch entry limit. Time-triggered execution improves the timeliness of audit log entries and prevents them from accumulating in the buffer queue for extended periods.

[0115] In this way, the asynchronous write module can achieve batch aggregation (e.g., triggering a write every 100 records or every 1 second), serialize multiple audit record entries into JSON Lines format, calculate chained hashes, and then write them all at once into the first audit record set of the distributed object storage engine.

[0116] The first audit record set of the distributed object storage engine can be called the audit object pool. This first audit record set can be an independent storage pool (e.g., cephfs.audit) within the distributed object storage engine, and can be configured with an independent number of replicas and storage policies. For example, audit record entries can be sharded and stored according to the metadata service process identifier and time period. For instance, the first audit record set can include multiple audit log objects, and the naming convention for audit log objects can be audit.{mds_id}.{date}.{hour}, where mds_id represents the metadata service process identifier, date represents the date, and hour represents the hour. For example, audit.0.20250315.10 represents the audit record entry generated by the metadata service process mds.0 during the time period from 10:00 to 11:00 on March 15, 2025. Furthermore, it is possible to aggregate by day to obtain a daily aggregated index, recording the number of records and hash anchors for each time period, represented as audit.index.{date}. This hash anchor object can record the latest hash chain anchor point for each MDS, for example, it can be represented as audit.anchor.{mds_id}.

[0117] In some examples disclosed herein, the asynchronous write module described above can also perform asynchronous write performance tuning steps during the batch write process to cope with excessive audit log write pressure.

[0118] The asynchronous write performance tuning steps may include one or more of the following first to third steps.

[0119] The first step is to increase the number of batch entries if the number of audit record entries stored in the buffer queue is greater than or equal to a first preset threshold, in order to reduce the number of batch reads and writes.

[0120] For example, the first preset threshold can be set to 50% of the buffer queue capacity. For instance, if the buffer queue capacity is 10,000 entries, the first preset threshold is 5,000 entries. When the number of audit record entries in the buffer queue reaches 5,000, the asynchronous write module can increase the batch entry count from the default value of 100 to 200 or higher. By increasing the batch entry count, the number of batch write operations can be reduced, decreasing the frequency of interaction with the distributed object storage engine and improving overall write throughput.

[0121] The second step involves modifying the preset audit matching conditions of the metadata service process when the storage quantity is greater than or equal to the second preset quantity threshold, in order to reduce the number of audit record entries written to the buffer queue by the metadata service process.

[0122] For example, the second preset threshold can be set to 70% of the buffer queue capacity. For instance, if the buffer queue capacity is 10,000 entries, the second preset threshold would be 7,000 entries. When the number of audit record entries in the buffer queue reaches 7,000, the asynchronous write module can dynamically reduce the audit granularity, for example, by reducing the audit level from standard (auditing read / write operations) to basic (auditing only write operations), or by narrowing the target path matching range. By reducing the number of operations that need to be audited, the generation speed of audit record entries can be reduced, alleviating the write pressure on the buffer queue.

[0123] The third step is to discard the audit record entry that was first written to the buffer queue if the number of stored items is greater than or equal to the preset maximum capacity threshold.

[0124] For example, the preset maximum capacity threshold can be set to 90% of the buffer queue capacity. For instance, if the buffer queue capacity is 10,000 entries, the preset maximum capacity threshold is 9,000 entries. When the number of audit record entries in the buffer queue reaches 9,000, the asynchronous write module can forcibly discard the audit record entry at the head of the queue to make room for new audit record entries. The discarding operation can be reported as an alarm in the cluster logs, recording the number of discarded audit record entries and the time range.

[0125] In some examples, the first preset quantity threshold may be less than the second preset quantity threshold, and the second preset quantity threshold may be less than the preset maximum capacity threshold. That is, the three preset quantity thresholds satisfy the following relationship: first preset quantity threshold < second preset quantity threshold < preset maximum capacity threshold.

[0126] The first to third steps described above can be referred to as the first to third levels of backpressure control, thus forming a three-level backpressure control mechanism. Through this three-level backpressure control mechanism, as the pressure on audit log writing gradually increases, escalating measures can be taken at each level to ensure the stable operation of the audit system while retaining as many audit record entries as possible.

[0127] In some examples, the backpressure control mechanism can support automatic recovery. When the number of audit record entries in the buffer queue drops to a safe level (e.g., below a first preset threshold), the asynchronous write module can automatically restore the original batch entry count and audit matching conditions, exiting the backpressure control state.

[0128] In other examples, the backpressure control mechanism can support configurable adjustment parameters. Security administrators can adjust parameters such as preset quantity thresholds at various levels (e.g., first preset quantity threshold, second preset quantity threshold, preset maximum capacity threshold), the increase in the number of batch entries, and the strategy for reducing audit granularity, according to actual audit needs and system performance, to achieve fine-grained control over the performance of the audit system.

[0129] In some examples, the asynchronous write performance tuning steps described above may also include fault degradation and automatic backfilling mechanisms to address situations where the distributed object storage engine is unavailable. For example, the asynchronous write performance tuning steps may also include the following fourth step.

[0130] In the fourth step, if the number of consecutive failures when writing the batch-read audit record entries into the first audit record set is greater than or equal to the preset failure count threshold, the batch writing step is stopped, and the audit record entries are stored in the local storage of the metadata service process.

[0131] The preset failure threshold can be set by the user based on engineering experience; for example, it can be set to 5 failures. When the asynchronous write module fails to write audit log entries to the distributed object storage engine five consecutive times (e.g., due to network failure, unavailability of the distributed object storage engine service), it can be determined that the distributed object storage engine is currently unavailable and enters fault degradation mode. In fault degradation mode, the asynchronous write module can stop executing the batch write steps and write the audit log entries to the local storage of the metadata service process. The local storage can be the local disk or local file system of the server node where the metadata service process resides. Audit log entries can be stored in the local storage as files, and the file name can include a timestamp and the metadata service process identifier for easy location in subsequent backfill operations.

[0132] In this way, the fault degradation mechanism can ensure that audit record entries are not lost even when the distributed object storage engine is unavailable, thus avoiding the loss of audit data.

[0133] Furthermore, the fourth step may also include: after stopping the batch write step, periodically writing a preset number of audit record entries to the first audit record set; if the preset number of audit record entries are successfully written, then restarting the batch write step.

[0134] For example, the preset number can be set to 1 or 2. The asynchronous write module can attempt to write a preset number of audit record entries to the distributed object storage engine every 10 seconds (it can read the oldest unfilled record from local storage). If the write is successful, it means that the distributed object storage engine has recovered and is available, and the asynchronous write module can exit the fault degradation mode and restart the batch write process.

[0135] After restarting the batch write step, the asynchronous write module can initiate an automatic backfill process, gradually backfilling the audit record entries stored in local storage into the first audit record set of the distributed object storage engine. The backfill operation can be performed in the background with a low priority to avoid affecting the writing of real-time audit record entries.

[0136] In some examples, the fault degradation mechanism can support local storage capacity limits. A maximum capacity threshold (e.g., 10GB) can be set for local storage. When the total size of the audit log entry files stored in local storage exceeds the maximum capacity threshold, the oldest files can be discarded to make room for new audit log entries, and an alarm message can be output through the cluster log.

[0137] In other examples, the automatic backfill process can support resuming interrupted uploads. Backfill progress (e.g., a list of backfilled files and their offsets within those files) can be recorded in local storage. If the backfill process is interrupted (e.g., the metadata service process restarts), it can resume from the last backfill progress, avoiding duplicate backfilling.

[0138] Through the aforementioned asynchronous writing mechanism, backpressure control mechanism, and fault degradation mechanism, as much audit information as possible can be recorded while ensuring the stable operation of the audit system, thereby improving the reliability of audit records.

[0139] In some examples, when generating audit record entries based on data operation requests and data operation responses in step S220, chain hashing or other verification mechanisms can be used to generate verification values ​​for the audit record entries. In this way, the generated audit record entries can contain verification values ​​to achieve anti-tampering capabilities through the verification mechanism and improve audit reliability.

[0140] For example, initial audit log information corresponding to the target data can be generated based on the data operation request and data operation response; if the initial audit log information is the first audit log of the metadata service process, a checksum is generated based on the initial audit log information, and an audit log entry is generated based on the checksum and the initial audit log information; or, if the initial audit log information is not the first audit log, a checksum is generated based on the historical checksums in the audit log entries generated before the initial audit log information and the initial audit log information, and an audit log entry is generated based on the checksum and the initial audit log information.

[0141] The aforementioned initial audit log information may include the original content of the audit information, such as operation type, user ID, target path, operation timestamp, operation result, etc.

[0142] For example, the above checksum can be generated using a hash algorithm. For instance, for the first audit record, a hash function (e.g., SHA-256, Secure Hash Algorithm 256-bit) can be used to hash the initial audit record information to obtain the checksum hash_0. Then, the checksum hash_0 and the initial audit record information are encapsulated together into an audit record entry Record_0. The checksum in the audit record entry Record_0 can include a previous checksum (e.g., the prev_hash field, with a value of empty or a preset initial value) and the current checksum (the hash field, with a value of hash_0). For example, for audit records that are not the first, a checksum can be generated based on historical checksums from audit record entries previously generated from the initial audit record information, along with the initial audit record information. An audit record entry is then generated based on this checksum and the initial audit record information. If the current entry to be generated is the nth audit record entry, Record_n, and the checksum of the previous audit record entry, Record_{n-1}, is hash_{n-1}, then hash_{n-1} can be used as the historical checksum. This hash_{n-1} can be concatenated with the current initial audit record information and then subjected to SHA-256 hash calculation to obtain the current checksum hash_n = SHA256(hash_{n-1} + initial audit record information). Then, the checksum hash_n and the initial audit record information are encapsulated together into an audit record entry, Record_n. The audit record entry, Record_n, can include the previous checksum (prev_hash field, value hash_{n-1}) and the current checksum (hash field, value hash_n). Through the chained hashing mechanism described above, each audit record entry contains the checksum of the previous record, forming a hash chain. The hash chain has the following property: if the content of an audit record entry is tampered with, the checksum of that record will change, causing the checksums of all subsequent records to fail to match, thus detecting the tampering.

[0143] In some examples, each metadata service process can independently maintain a hash chain for calculating checksums. In a multi-active metadata service process environment, multiple hash chains can run in parallel without interfering with each other. This avoids the synchronization overhead between different metadata service processes and improves the scalability of the auditing system.

[0144] In some examples, the hash chain can be built incrementally. The metadata service process can maintain the checksum of the most recent audit record entry (called the chain head hash) in memory. Each time a new audit record entry is generated, the chain head hash is directly used as the historical checksum for hash calculation, without needing to read the previous record from storage. This reduces storage access overhead and improves the efficiency of audit record entry generation.

[0145] In other examples, hash chains can support branching and merging. In certain special scenarios (such as needing to re-enter lost audit log entries after a metadata service process failure), branches can be inserted into the hash chain. Branches can be recorded as special audit log entries, containing the checksum of the branch point and a description of the reason for the branch. During integrity verification, the hash chain integrity of each branch can be verified separately according to the branch path.

[0146] Figure 4 This is a flowchart illustrating another auditing method provided in an embodiment of this disclosure. Figure 4 As shown, the auditing method of this embodiment may include the following steps S410 to S470.

[0147] Step S410: Obtain the target data to be audited based on the audit probe deployed at the target interface within the metadata service process.

[0148] Step S420: If the data operation request in the target data meets the preset audit matching conditions, generate an audit record entry corresponding to the target data based on the data operation request and the data operation response.

[0149] Step S430: Write the audit record entries to the first audit record set of the distributed object storage engine.

[0150] It should be noted that the implementation of steps S410 to S430 can be referred to the description of steps S210 to S230 in the foregoing embodiments of this disclosure, and will not be repeated here.

[0151] Step S440: Sort the audit record entries in the first audit record set according to the metadata service process identifier and vector clock information to obtain the sorted second audit record set.

[0152] The implementation of step S440 can be referred to the description of step S240 in the foregoing embodiments of this disclosure, and will not be repeated here.

[0153] Step S450: Generate an anchor point record set and submit it to the monitoring engine.

[0154] Step S460: Perform integrity verification on the first audit record set and / or the second audit record set based on the anchor record set.

[0155] Step S470: Audit the client's data operations based on the first audit record set and / or the second audit record set.

[0156] The anchor record set in step S450 above may include the verification value (e.g., hash value) in each audit record entry.

[0157] In some examples, step S450 can be performed after step S430, in which the audit record entries are written into the first audit record set of the distributed object storage engine. For example, if the audit record entries recorded in the first audit record set meet the preset verification value storage conditions, the verification values ​​(e.g., hash values) in the audit record entries are sorted according to the generation order of the audit record entries to generate an anchor record set; the anchor record set is submitted to the monitoring engine of the distributed storage system, and the monitoring engine stores the anchor record set; when performing integrity verification on the first audit record set and / or the second audit record set in step S460, the verification values ​​of the audit record entries can be recalculated and compared with the verification values ​​in the anchor record set to determine whether the audit record has been tampered with.

[0158] In some examples, the above-mentioned preset verification value storage conditions may include quantity conditions and / or time conditions for audit record entries, which are triggered by the number of records and by the time period, respectively.

[0159] The quantity condition can be triggered by the number of records, such as the number of anchor record sets being committed. For example, a checksum storage operation is triggered every N accumulated audit record entries. N can be a pre-configured parameter, such as a default value of 1000. When the number of audit record entries generated by the metadata service process reaches an integer multiple of N, the current chain head hash value can be extracted and used as the anchor record.

[0160] The time condition can be to trigger the commit of the anchor record set at time intervals. For example, a checksum storage operation can be triggered every T time interval. T can be a pre-configured parameter, such as a default value of 5 minutes. The metadata service process can start a timer to check every T time interval for the generation of new audit record entries. If a new audit record entry is generated, the current chain head hash value is extracted and used as the anchor record.

[0161] It should be noted that the above two conditions (two triggering methods) can be used individually or in combination. When used in combination, the checksum storage operation is triggered when either condition is met. For example, it can be configured to trigger once every N (e.g., 1000) records or every T minutes (e.g., 5 minutes). This allows for timely storage of anchor points when audit record entries are generated quickly, and periodic storage of anchor points when audit record entries are generated slowly.

[0162] In some examples, the anchor record set can be sorted according to the order in which the audit record entries were generated. Each anchor record can contain the following fields: metadata service process identifier (mds_id), audit record entry identifier (record_id), checksum (hash_current), and timestamp. The anchor record set can be stored using an ordered array or ordered linked list data structure for easy querying and verification in chronological order.

[0163] In some examples, the anchor record set can be submitted to the monitoring engine of the distributed storage system. This monitoring engine can be used within the distributed storage system to maintain cluster state mapping and provide consensus services. The monitoring engine can employ the Paxos consensus algorithm to ensure consistent data storage. For example, the metadata service process can submit anchor records to the monitoring engine through the MonCommand interface. MonCommand can be a command interface provided by the monitoring engine, supporting various cluster management and configuration operations. The metadata service process can construct a command message containing the anchor records and send it to the master node of the monitoring engine. After receiving the command message, the master node of the monitoring engine can negotiate with other monitoring nodes using the Paxos consensus algorithm, and after reaching an agreement, persist the anchor records.

[0164] This monitoring engine employs a majority consensus mechanism, requiring a majority of monitoring nodes to confirm the anchor record set before it can be successfully stored. This prevents even a single administrator with access to a particular monitoring node from unilaterally tampering with the anchor record; modification requires control of a majority of monitoring nodes, significantly enhancing the security of tamper protection.

[0165] In some examples, when performing integrity verification on the first audit record set and / or the second audit record set, step S460 above can determine whether the audit record has been tampered with by recalculating the check value of the audit record entry and comparing it with the check value in the anchor record set.

[0166] For example, the integrity verification process may include the following steps: Step S11: Receive a verification request. The verification request can specify the time range to be verified, such as [T1, T2].

[0167] Step S12: Read all audit log entries within the time range [T1, T2] from the distributed object storage engine (e.g., RADOS). The corresponding object can be located according to the naming rules of the audit log object (e.g., audit.{mds_id}.{date}.{hour}), and its content can be read and parsed into audit log entries.

[0168] Step S13: Retrieve hash anchors within the specified time range from the anchor record set of the monitoring engine (e.g., Monitor). For example, all anchor records with timestamps in the range [T1, T2] can be retrieved by querying the anchor record set of the monitoring engine.

[0169] Step S14: Starting from the earliest anchor point, verify the hash chain one by one. For each audit record entry Record_i, the following verification steps can be performed: Calculate the checksum: Based on the previous checksum of Record_i (prev_hash field) and the initial audit record information, recalculate the checksum calculated_hash = SHA256(prev_hash + initial audit record information).

[0170] Verification comparison: The calculated_hash is compared with the previous verification value (prev_hash field) of the next audit record entry Record_{i+1}. If they are equal, it means that Record_i has not been tampered with; if they are not equal, it means that Record_i or Record_{i+1} has been tampered with.

[0171] Anchor comparison: When verifying an anchor point, the current chain head hash value (verification value) is compared with the anchor hash value (verification value) in the anchor records stored by the monitoring engine. If they are equal, it means that all audit record entries from the previous anchor point to the current anchor point have not been tampered with; if they are not equal, it means that the hash chain segment has been tampered with.

[0172] Step S15: Output the verification results. If all verification steps pass, report that the audit log is complete and no tampering was detected. If a verification step fails, report the location of the tampering and the range of affected records, for example, if tampering is detected: the hash chains between audit record entries Record_i and Record_j do not match.

[0173] In some examples, the integrity verification described above can be performed in parallel. The time range [T1, T2] can be divided into multiple sub-intervals, and an independent verification task can be started for each sub-interval, performing hash chain verification in parallel. Parallel verification can improve verification efficiency and shorten verification time.

[0174] In other examples, integrity verification can support incremental verification. The time point and result of the last verification can be recorded, and when performing new verification, only audit record entries added after the last verification time point are verified. Incremental verification avoids duplicate verification of all audit record entries, improving verification efficiency.

[0175] It should be noted that the specific implementation of step S470 can be referred to the description of step S240 in the first embodiment, and will not be repeated here.

[0176] Figure 5 This is a schematic diagram of the architecture of a distributed storage system provided in an embodiment of this disclosure. Figure 5 As shown, the distributed storage system may include a server 100 and a client 200, which can communicate with the server 100 via a network connection. The server 100 may include a metadata service process 101 and a distributed object storage engine 102.

[0177] The metadata service process 101 may include one or more of the following: target interface, audit probe (AuditInterceptor), record generator (AuditRecord Generator), asynchronous write module (AsyncAuditWriter), or anomaly detection module (AnomalyDetector), which will be described in detail below.

[0178] The target interface may include a first interface and / or a second interface. The first interface may be used to receive and schedule data operation requests from client 200, distributing the requests to the internal processing logic of the metadata service process. For example, the first interface may include a `dispatch_client_request` method. The second interface may be used to send data operation responses to client 200, returning the processing results to the client. For example, the second interface may include a `respond_to_request` method or an `early_reply` method.

[0179] This audit probe can be deployed at the target interface of the scheduling response module to intercept data operation requests and responses, and obtain the target data to be audited. The audit probe can perform policy matching, determining whether the target data needs to generate an audit record entry based on preset audit matching conditions. These preset audit matching conditions may include operation type matching conditions, target path matching conditions, user identifier matching conditions (e.g., user whitelist / blacklist), audit level matching conditions, etc., as described in detail in the first embodiment. For example, this audit probe can be called an audit interceptor module (AuditInterceptor), and can be embedded in the dispatch_client_request() method of the MDS Server component. This method serves as the unified entry point for all client metadata requests to enter the MDS processing logic. Interception can be divided into two stages: request stage interception (Pre-execution) and response stage interception (Post-execution). For example, before the operation is executed, request stage interception can be performed at the entry point of the dispatch_client_request method to record the operation intent. For example, the recorded content may include: operation type, user identity, target path, request parameters, etc. After the operation is completed, response stage interception can be performed at the call point of the respond_to_request() method or the early_reply() method to record the operation result (success / failure), error code, operation time, etc.

[0180] This record generator can generate audit record entries based on data operation requests and responses, provided that the target data meets preset audit matching conditions. The record generator can perform JSON structuring to process the audit record entries; it can also record vector clock information within the audit record entries; and it can perform chained hashing to generate checksums for the audit record entries, forming a hash chain. For example, the audit record entry may include fields such as audit information, metadata service process identifier, vector clock information, and checksum.

[0181] This asynchronous write module can write audit record entries to the first audit record set of the distributed object storage engine. The asynchronous write module can include a buffer queue and a background write thread. The buffer queue can be a lock-free circular buffer queue configured in a single producer-single consumer mode to transfer audit record entries between the audit record generator and the background write thread. The background write thread can perform batch write steps, reading audit record entries in batches from the buffer queue based on a set batch entry count, and writing the batch-read audit record entries to the distributed object storage engine. This asynchronous write module can also perform backpressure control. The backpressure control function can include a three-level backpressure control mechanism: the first level increases the batch entry count when the buffer queue storage reaches a first preset threshold; the second level modifies the preset audit matching conditions to reduce audit granularity when the buffer queue storage reaches a second preset threshold; and the third level discards the oldest audit record entry when the buffer queue storage reaches a preset maximum capacity threshold. This asynchronous write module can also perform fault degradation. When the number of consecutive write failures reaches a preset failure count threshold, the asynchronous write module can stop executing the batch write steps and store the audit record entries in local storage. The asynchronous write module can periodically attempt to write a preset number of audit record entries to the distributed object storage engine. If the write is successful, it will restart the batch write step and start the automatic backfill process to backfill the audit record entries in the local storage to the distributed object storage engine.

[0182] This anomaly detection module can audit client data operations based on a first audit record set and / or a second audit record set. The module can obtain the current operation characteristics of each user within the current sliding time window using a sliding window statistical method, compare these characteristics with a baseline of historical operation characteristics, perform anomaly pattern matching, and generate anomaly alerts (such as real-time alerts). For example, if the current operation characteristics meet pre-defined anomaly detection conditions, an anomaly detection alert is output. Anomaly detection alerts can include abnormal operation patterns, such as batch deletion operation patterns, abnormal time period operation patterns, unauthorized operation attempt patterns, and abnormal path operation patterns. It should be noted that this anomaly detection module can be deployed in the metadata service process, in the distributed object storage engine, or in any process or module on the server or client side; this embodiment does not limit this.

[0183] The distributed object storage engine 102 may include an audit log object pool, hash anchors, and behavior profiles.

[0184] The audit log object pool can be used to store a first audit log set and / or a second audit log set. The first audit log set may include audit log entries written by multiple metadata service processes, and is stored in shards according to the metadata service process identifier and time period. The second audit log set may be a globally ordered audit log set obtained by sorting the first audit log set, with the sorting rule based on the metadata service process identifier and vector clock information.

[0185] Hash anchor objects can be used to store anchor record sets. These sets can include chain-head hash values ​​periodically submitted by various metadata service processes for tamper protection and integrity verification. The anchor record sets can be submitted to the monitoring engine, where consistent storage is ensured through the engine's consensus mechanism.

[0186] The behavior baseline object can be used to store the user's historical operation feature baseline. The historical operation feature baseline can be obtained by weighting the historical operation features of multiple historical sliding time windows (e.g., exponentially weighted moving average, EWMA), and is used by the anomaly detection module to compare user behavior and identify anomalies.

[0187] In some examples, the system may also include an audit analysis module deployed within the management module (MGR) of the distributed storage system. The audit analysis module can periodically read new audit record entries from a first audit record set, perform sorting operations, and generate a second audit record set. The audit analysis module can also perform integrity verification operations, determining whether an audit record has been tampered with by recalculating the checksum of the audit record entry and comparing it with the checksum in the anchor record set.

[0188] In other examples, the system may also include an audit query interface, providing audit log query functionality based on conditions such as time range, user ID, operation type, and target path. Security administrators can use the audit query interface to retrieve audit logs under specific conditions for security incident analysis and compliance review.

[0189] The above-described distributed storage system architecture enables comprehensive auditing of client operations within the distributed storage system. It also enables globally ordered aggregation of distributed audit logs through a vector clock mechanism, provides tamper protection through chained hashing and anchor point mechanisms, and automatically identifies potential security threats through anomaly detection mechanisms, thus meeting the requirements of scenarios such as security auditing, compliance supervision, and event tracing.

[0190] This disclosure also provides an electronic device, such as... Figure 6As shown, the electronic device 600 may include a processor 610 and a memory 620. The memory can be used to store computer programs, and the processor can be used to retrieve the computer programs from the memory to execute all or part of the steps of any of the methods in the foregoing embodiments of this disclosure. The processor may be one or more, and these processors may execute instructions individually or jointly. Similarly, the memory may be one or more, and these memories may store the aforementioned computer programs individually or jointly. In some examples, the processor may be a graphics processing unit (GPU), a general-purpose graphics processing unit (GPGPU), a neural network processing unit (NPU), a tensor processing unit (TPU), or a central processing unit (CPU). It may also be a chip in the form of an application-specific integrated circuit (ASIC), a system-on-a-chip (SOC), a field-programmable gate array (FPGA), or a programmable logic array (PLA). In some examples, the electronic device can be any type of terminal device, workstation, or server, etc., and this embodiment does not limit this. Optionally, the electronic device can be... Figure 1 The server shown.

[0191] This disclosure also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements all or part of the steps of any of the methods in the foregoing embodiments of this disclosure. Optionally, the computer-readable storage medium may be a non-transitory storage medium, but is not limited thereto, and may also be a temporary storage medium.

[0192] This disclosure also provides a computer program product that may include a computer program that, when executed by a processor, can implement all or part of the steps of any of the methods in the foregoing embodiments of this disclosure.

[0193] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0194] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and apparatuses according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, unit, or part of a circuit. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel or in reverse order, depending on the functions involved. It should be noted that embodiments of the present disclosure may include some or all of the functions marked in the multiple blocks in the drawings, and may also include other functions not shown in the blocks in the drawings. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using hardware that performs the specified function or action, or using a combination of dedicated hardware and computer programs. Unless otherwise specified, implementation in hardware, implementation in software, and implementation in a combination of software and hardware may be equivalent.

[0195] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein. The scope of this disclosure is defined by the appended claims.

Claims

1. An auditing method, characterized in that, A server-side application for a distributed storage system, the server-side including a distributed object storage engine and multiple metadata service processes, the metadata service processes being used to handle data operation requests from clients; the method includes: The audit probe deployed at the target interface within the metadata service process is used to obtain the target data to be audited; wherein, the target interface includes a first interface for receiving and scheduling data operation requests from the client and a second interface for sending data operation responses to the client, and the target data includes the data operation requests and the data operation responses; If a data operation request in the target data meets a preset audit matching condition, an audit record entry corresponding to the target data is generated based on the data operation request and the data operation response; wherein, the audit record entry includes audit information, a metadata service process identifier that generated the audit record entry, and vector clock information; The audit record entries are written to the first audit record set of the distributed object storage engine; wherein, the first audit record set includes audit record entries written from multiple metadata service processes; In the distributed object storage engine, the audit record entries in the first audit record set are sorted according to the metadata service process identifier and the vector clock information to obtain a sorted second audit record set, so as to audit the data operations of the client based on the second audit record set.

2. The method according to claim 1, characterized in that, The vector clock information in the audit record entry includes logical clock count information corresponding to each metadata service process, which is written by the metadata service process that generates the audit record entry when generating the audit record entry. The step of sorting the audit record entries in the first audit record set according to the metadata service process identifier and the vector clock information to obtain a sorted second audit record set includes: Based on the logical clock count information corresponding to each metadata service process in the vector clock information, determine whether there is a causal order between any two audit record entries; In the case where there is a causal order between two audit record entries, a target order between the two audit record entries is determined based on the causal order. In the absence of a causal order between two audit record entries, the target order between the two audit record entries is determined based on the physical timestamp of the audit record entries and / or the metadata service process identifier; The second audit record set is generated by sorting the audit record entries according to the target order.

3. The method according to claim 2, characterized in that, Determining the target order between two audit record entries based on the physical timestamp of the audit record entry and / or the metadata service process identifier includes: If the physical timestamps of two audit record entries are different, the target order between the two audit record entries is determined based on the physical timestamps; or, If two audit record entries have the same physical timestamp, the target order between the two audit record entries is determined based on the size order of the metadata service process identifier.

4. The method according to claim 1, characterized in that, The step of writing the audit record entries into the first audit record set of the distributed object storage engine includes: The generated audit record entries are written to the buffer queue of the metadata service process; wherein the buffer queue is a lock-free circular buffer queue and is configured in a single producer single consumer mode. The asynchronous write module performs a batch write step to write audit record entries in the buffer queue to the first audit record set of the distributed object storage engine; the batch write step includes: reading audit record entries in batches from the buffer queue based on a set batch entry number, and writing the batch-read audit record entries into the first audit record set.

5. The method according to claim 4, characterized in that, During the batch write process, the asynchronous write module also performs an asynchronous write performance tuning step; the asynchronous write performance tuning step includes: If the number of audit record entries stored in the buffer queue is greater than or equal to a first preset threshold, the value of the batch entry number is increased to reduce the number of batch reads and writes. If the storage quantity is greater than or equal to the second preset quantity threshold, modify the preset audit matching conditions of the metadata service process to reduce the number of audit record entries written by the metadata service process to the buffer queue. If the number of stored items is greater than or equal to a preset maximum capacity threshold, the audit record entry written to the buffer queue first is discarded; wherein, the first preset number threshold is less than the second preset number threshold, and the second preset number threshold is less than the preset maximum capacity threshold.

6. The method according to claim 5, characterized in that, The asynchronous write performance tuning steps also include: If the number of consecutive failures when writing audit record entries read in batches into the first audit record set is greater than or equal to a preset failure count threshold, then the batch writing step is stopped, and the audit record entries are stored in the local storage of the metadata service process. After stopping the batch write step, a preset number of audit record entries are periodically written to the first audit record set. If the preset number of audit record entries are successfully written, the batch write step is restarted.

7. The method according to claim 1, characterized in that, The step of generating audit record entries corresponding to the target data based on the data operation request and the data operation response includes: Generate initial audit record information corresponding to the target data based on the data operation request and the data operation response; If the initial audit record information is the first audit record of the metadata service process, a checksum is generated based on the initial audit record information, and the audit record entry is generated based on the checksum and the initial audit record information; or, If the initial audit record information is not the first audit record, a verification value is generated based on the historical verification values ​​in the audit record entries generated before the initial audit record information and the initial audit record information. The audit record entry is then generated based on the verification value and the initial audit record information.

8. The method according to claim 7, characterized in that, The server also includes a monitoring engine; after writing the audit record entries into the first audit record set of the distributed object storage engine, the method further includes: If the audit record entries recorded in the first audit record set meet the preset verification value storage conditions, the verification values ​​in the audit record entries are sorted according to the generation order of the audit record entries to generate an anchor record set. The anchor point record set is submitted to the monitoring engine, and the monitoring engine stores the anchor point record set. When performing integrity verification on the first audit record set and / or the second audit record set, the audit record is determined to have been tampered with by recalculating the check value of the audit record entry and comparing it with the check value in the anchor record set.

9. The method according to any one of claims 1 to 8, characterized in that, The audit record entries in the second audit record set include the user identifier that initiated the data operation request based on the client; The auditing of the client's data operations based on the second audit record set includes: Obtain the current operation characteristics of each user within the current sliding time window; wherein, the current operation characteristics include one or more current operation types and the current number of operations corresponding to each current operation type; If the current operation feature meets the preset anomaly detection conditions, an anomaly detection alarm is output; wherein, the anomaly detection alarm includes an abnormal operation mode, and the abnormal operation mode includes at least one of batch deletion operation mode, abnormal time period operation mode, unauthorized operation attempt mode or abnormal path operation mode. The anomaly detection conditions include at least one of the following: The similarity between the current operation feature and the user's historical operation feature baseline is less than a preset similarity threshold; wherein, the historical operation feature baseline is a feature baseline obtained by weighted averaging of historical operation features based on multiple historical sliding time windows; The current operation type in the current operation feature includes a preset operation type, and the current operation count of the preset operation type is greater than a preset count threshold.

10. The method according to any one of claims 1 to 8, characterized in that, The data operation request includes at least one of the following: operation type, user identifier, target path of the data to be operated, or operation request parameters. The data operation response includes at least one of the following: operation result, error code, or operation duration; The preset audit matching conditions include at least one of the following: operation type matching conditions, user identifier matching conditions, target path matching conditions, and audit level matching conditions; The audit information in the audit record entry includes at least one of the following: operation type, user identifier, target path of the data to be operated, operation request parameters, operation timestamp, or operation result; the audit record entry is encapsulated based on a pre-defined data format.

11. An electronic device, characterized in that, The device includes a memory and a processor, the memory being used to store a computer program, and the processor being used to invoke the computer program from the memory to perform the method of any one of claims 1 to 10.

12. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 10.

Images