Unified log encryption method and device and electronic equipment

Abstract

The invention discloses a unified log encryption method and device and electronic equipment, and relates to the technical field of data encryption, and the method comprises the steps: obtaining a unified public key and an encryption rule from a management end, and installing an encryption assembly with the information and an encryption algorithm, thereby improving the encryption efficiency. Therefore, when the assembly service on the host node generates the log, the assembly is uniformly called to encrypt the sensitive information, so that the centralized management of the encryption configuration is realized instead of the independent configuration of each assembly; the technical problems that in an existing log encryption and desensitization method, due to the fact that encryption algorithms and secret keys are independently configured for all assemblies, a unified management mechanism is lacked, secret key management is dispersed, encryption strategies are inconsistent, security updating lags, and therefore the overall security and stability of a cloud platform are affected can be solved, and the purposes of unified management of encryption configuration and security updating are achieved. The technical effects of improving the consistency and timeliness of cloud platform log sensitive information protection and enhancing the overall security and stability of the cloud platform are achieved.

Description

Technical Field

[0001] This application relates to the field of data encryption technology, and in particular to methods, apparatus and electronic devices for unified encryption of logs. Background Technology

[0002] With the rapid development of cloud computing technology, cloud management platforms have become a core component of modern information technology (IT) infrastructure, widely used in enterprise data centers, public cloud services, and hybrid cloud architectures. Among these technologies, log data, as a critical source of information for system operation status and security auditing, is particularly important for security. Existing cloud platform log protection systems typically cover data collection, processing and analysis, and storage control, primarily relying on encryption and data masking techniques working together to protect sensitive information.

[0003] In this type of log encryption and desensitization method, each component is usually configured with encryption algorithms and keys independently, lacking a unified management mechanism. This may lead to problems such as scattered key management, inconsistent encryption strategies, and delayed security updates, thereby affecting the overall security and stability of the cloud platform. Summary of the Invention

[0004] This application provides a method, apparatus, and electronic device for unified encryption of logs, in order to at least solve the problems of scattered key management, inconsistent encryption strategies, and lagging security updates in related technologies.

[0005] This application provides a method for unified encryption of logs, which is applied to host nodes and includes:

[0006] Obtain the public key and encryption rules sent by the management terminal;

[0007] Install an encryption component, which contains the public key, encryption algorithm, and encryption rules, so that the component service running on the host node can call the encryption component to encrypt sensitive information when generating logs.

[0008] Optionally, the installation of the encryption component, wherein the encryption component contains the public key, encryption algorithm, and encryption rules, further includes:

[0009] When the encryption component receives an encryption request from the component service, it classifies and identifies sensitive information according to the encryption rules and calls the corresponding encryption algorithm for processing. In particular, when processing log data, the encryption component uses a memory isolation mechanism to protect the encryption process and prevent unauthorized access to sensitive information during processing.

[0010] Optionally, the method further includes:

[0011] Obtain the updated key and encryption rules sent by the management terminal;

[0012] The system updates the old configuration based on the updated encrypted configuration, and versions the old configuration and retains it for a preset duration.

[0013] This application provides a method for unified encryption of logs, which is applied to the management end and includes:

[0014] Generate a key pair and distribute the public key and encryption rules to each host node; wherein, the key pair includes a public key and a private key;

[0015] Obtain log data sent by the host node and upload the log data to the management terminal;

[0016] Decryption is performed based on the management-side encryption component and the private key.

[0017] Optionally, the method further includes:

[0018] The encryption configuration transmission channel is used to synchronize and update the keys and encryption rules to each host node in real time, so as to ensure that the encryption components of each host node always use the latest encryption configuration.

[0019] Optionally, the generation of key pairs and the distribution of the public key and encryption rules to each host node further includes:

[0020] Based on the current security level requirements of the cloud platform, the target encryption algorithm is determined and the corresponding key pair is generated. The encryption rules include setting different encryption processing methods for different sensitive information fields; different security level requirements correspond to different strengths of encryption algorithms.

[0021] The public key and encryption rules are distributed to each host node in the form of an encrypted packet through a secure transmission channel, and the encrypted packet is digitally signed and verified before distribution.

[0022] Optionally, the step of synchronizing and updating the key and encryption rules to each host node in real time via the encrypted configuration transmission channel to ensure that the encryption components of each host node always use the latest encryption configuration includes:

[0023] In response to known vulnerabilities in the encryption algorithm or the expiration of the key usage period, a new encryption configuration is automatically generated and pushed to each host node.

[0024] This application also provides a device for unified encryption of logs, the device being applied to a host node, comprising:

[0025] The acquisition unit is used to acquire the public key and encryption rules sent by the management terminal;

[0026] An encryption unit is used to install an encryption component, which contains the public key, encryption algorithm, and encryption rules, so that the component service running on the host node can call the encryption component to encrypt sensitive information when generating logs.

[0027] Optionally, the encryption unit is further used for:

[0028] When the encryption component receives an encryption request from the component service, it classifies and identifies sensitive information according to the encryption rules and calls the corresponding encryption algorithm for processing. In particular, when processing log data, the encryption component uses a memory isolation mechanism to protect the encryption process and prevent unauthorized access to sensitive information during processing.

[0029] Optionally, the device further includes:

[0030] The acquisition unit is also used to acquire updated keys and encryption rules sent by the management terminal;

[0031] The update unit is used to perform an update on the old updated configuration based on the updated encrypted configuration, and to version-mark the old configuration and retain it for a preset duration.

[0032] This application also provides a device for unified encryption of logs, the device being applied to a management terminal, comprising:

[0033] A generation unit is used to generate key pairs and distribute the public key and encryption rules to each host node; wherein, the key pair includes a public key and a private key;

[0034] The acquisition unit is used to acquire log data sent by the host node and upload the log data to the management terminal.

[0035] The decryption unit is used to perform decryption processing based on the management terminal encryption component and the private key.

[0036] Optionally, the device further includes:

[0037] The sending unit is used to synchronize the updated keys and encryption rules to each host node in real time through the encrypted configuration transmission channel, so as to ensure that the encryption components of each host node always use the latest encryption configuration.

[0038] Optionally, the generation unit is further configured to:

[0039] Based on the current security level requirements of the cloud platform, the target encryption algorithm is determined and the corresponding key pair is generated. The encryption rules include setting different encryption processing methods for different sensitive information fields; different security level requirements correspond to different strengths of encryption algorithms.

[0040] The public key and encryption rules are distributed to each host node in the form of an encrypted packet through a secure transmission channel, and the encrypted packet is digitally signed and verified before distribution.

[0041] Optionally, the sending unit is further configured to:

[0042] In response to known vulnerabilities in the encryption algorithm or the expiration of the key usage period, a new encryption configuration is automatically generated and pushed to each host node.

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

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

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

[0046] This application achieves centralized management of encryption configurations by obtaining a unified public key and encryption rules from the management end and installing an encryption component with built-in information and encryption algorithms. This allows component services on the host node to uniformly call the component to encrypt sensitive information when generating logs, thus realizing centralized management of encryption configurations instead of independent configurations by each component. Therefore, it can solve the technical problems in existing log encryption and desensitization methods, such as scattered key management, inconsistent encryption strategies, and delayed security updates caused by independent configuration of encryption algorithms and keys by each component and the lack of a unified management mechanism, which affect the overall security and stability of the cloud platform. This achieves the technical effect of unified management of encryption configurations, improving the consistency and timeliness of cloud platform log sensitive information protection, and enhancing the overall security and stability of the cloud platform. Attached Figure Description

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

[0048] Figure 1 A flowchart illustrating a method for unified encryption of logs provided in an embodiment of this disclosure;

[0049] Figure 2 A flowchart illustrating another method for unified encryption of logs provided in this embodiment of the disclosure;

[0050] Figure 3 A schematic diagram of the structure of a unified log encryption device provided in an embodiment of this disclosure;

[0051] Figure 4 A schematic diagram of the structure of another unified log encryption device provided in an embodiment of this disclosure;

[0052] Figure 5 A schematic diagram of the structure of another unified log encryption device provided in an embodiment of this disclosure;

[0053] Figure 6 A schematic diagram of another log unified encryption device provided in an embodiment of this disclosure. Detailed Implementation

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

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

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

[0057] The embodiments of this application provide a method for unified encryption of logs, and the method is described in detail in conjunction with the execution flow of the unified encryption of logs. Figure 1 This is a flowchart illustrating a method for unified encryption of logs provided in an embodiment of this disclosure, the method being applied to a host node.

[0058] like Figure 1 As shown, the method includes the following steps:

[0059] Step 101: Obtain the public key and encryption rules sent by the management terminal;

[0060] The public key originates from the RSA asymmetric key pair generated by the management end. As an important component of the asymmetric encryption system, the public key has a clear functional boundary—it is only used to perform encryption operations on data and cannot be reversed to decrypt data. This characteristic determines that it can be securely transmitted between the management end and the host node. Even if there is a risk of data exposure during transmission, it will not cause the security defense of subsequent encrypted log data to fail, thus ensuring the security of the key transmission link from the root. The encryption rules are standardized processing specifications formulated by the management end in combination with the overall security level requirements of the cloud platform, industry security compliance standards, and the hierarchical characteristics of sensitive information in the log data. The rules clearly define the processing methods for information of different levels of sensitivity. For example, for low-sensitivity information such as usernames recorded in the logs, the rules will specify the specific logic of simple desensitization (such as partial character replacement and masking). For extremely sensitive information such as passwords and tokens, the rules will specify the encryption processing requirements based on the RSA algorithm, providing clear guidance for subsequent host nodes to accurately identify and process sensitive information.

[0061] In actual operation, host nodes obtain public keys and encryption rules through a pre-established secure communication link between the management terminal and the host nodes. This link is built using a preset secure transmission protocol, effectively resisting risks such as data tampering and theft during transmission. This ensures that the integrity and security of the data remain intact throughout the entire process from the management terminal sending the public key and encryption rules to the host nodes receiving them. After the management terminal completes the RSA key pair generation and encryption rule configuration, it will proactively trigger a command to push the public key and encryption rules to all host nodes within the cloud platform through the aforementioned secure link. Upon receiving the relevant data, the host nodes will first initiate an integrity verification mechanism. By comparing data verification values, they will confirm that the public key and encryption rules have not been damaged or tampered with during transmission. After successful verification, the host nodes will store the public key and encryption rules in a dedicated secure storage area on their local machine. This area is only accessible to encryption components that will be installed on the host nodes later, preventing unauthorized components or processes from illegally reading or modifying it, thus laying a secure foundation for subsequent access to relevant resources by encryption components.

[0062] In some embodiments, the acquisition operation is not a single static execution, but also includes dynamic scenarios in which the host node reacquires the updated public key or encryption rules according to the update instructions issued by the management terminal during operation. This ensures that the host node always holds keys and rules that meet the current security requirements, and provides a guarantee for the continuity and compliance of log encryption and desensitization processing.

[0063] Step 102: Install the encryption component. The encryption component contains the public key, encryption algorithm, and encryption rules, so that the component service running on the host node can call the encryption component to encrypt sensitive information when generating logs.

[0064] The encryption component is a software module with an independent closed-loop function, capable of integrated operation of key storage, algorithm invocation, rule parsing, and encryption processing. Its installation process needs to be adapted to the host node's operating system environment (such as mainstream server operating systems). Deployment is completed through a standardized installation process (such as script-based automatic deployment, visual installation wizards, etc.). After installation, it will automatically register as a system-level service, with the ability to start automatically on boot, monitor running status, and automatically recover from failures. This ensures that the component provides continuous and stable service throughout the host node's operating cycle, avoiding the risk of sensitive log information being exposed due to encryption component interruption.

[0065] The encryption component imports the public key into a dedicated secure storage area. This area uses local encryption protection technology (such as system kernel-level encryption partitions or lightweight hardware security unit adaptation) and only grants access to the algorithm modules within the encryption component. This prevents unauthorized processes or components from reading, modifying, or tampering with the public key, ensuring its secure storage on the host node side.

[0066] For the built-in encryption algorithms, the encryption component pre-integrates an encryption algorithm library that is consistent with the management end. This algorithm library must comply with current industry security standards and cloud platform security baseline requirements. For example, it includes the RSA asymmetric encryption algorithm for highly sensitive data (such as passwords and tokens). At the same time, the algorithm library reserves extension interfaces, which can be upgraded later according to the algorithm update instructions from the management end to avoid security risks caused by outdated algorithms. For the built-in encryption rules, the encryption component will convert the acquired encryption rules into executable rule engine logic. By parsing the processing requirements for different types of sensitive information (such as usernames, passwords, tokens, etc.) in the rules, a precise mapping of "sensitive information type - processing method" is established. For example, the "simple desensitization of usernames" rule is parsed into the specific execution logic of "retaining the first N valid characters and replacing the remaining characters with mask symbols". The "password RSA encryption" rule is parsed into a standardized process of "calling the built-in RSA algorithm module, passing in the public key to perform encryption operations on the plaintext password to generate ciphertext". This ensures that the rules can be directly executed when called by the component service.

[0067] After the encryption component is installed on the host node, all component services running on that node (such as compute services, storage services, network management services, etc.) will immediately initiate an encryption request through the standardized calling interfaces (such as API interfaces, local function call interfaces, etc.) provided by the encryption component if they detect sensitive information in the data to be logged during the log generation process (through the sensitive information identification logic built into the component service, such as keyword matching, data format recognition, etc.). This request contains key parameters such as the plaintext of the sensitive information to be processed and the sensitive information type identifier.

[0068] Upon receiving a request, the encryption component first uses a rule engine to match the corresponding encryption rules based on the sensitive information type. Then, it invokes the built-in encryption algorithm module and, in conjunction with the stored public key, performs the appropriate processing. After processing, the encryption component returns the processed secure data (de-identified text or encrypted ciphertext) to the component service. The component service then integrates this data into the complete log content and finally outputs it to a local log file. The entire process is performance-optimized. Through the encryption component's multi-threaded processing mechanism and efficient algorithm execution logic, it ensures that while achieving secure processing of sensitive information, the real-time performance and efficiency of component service log generation are not affected. Furthermore, the encryption component automatically records key logs for each call (such as call time, the identifier of the initiating component service, processing result, and sensitive information type), providing traceable evidence for subsequent security audits and troubleshooting, further enhancing the security and standardization of host node log processing.

[0069] In some embodiments, the installation of the encryption component, wherein the encryption component has the public key, encryption algorithm, and encryption rules built in, further includes:

[0070] When the encryption component receives an encryption request from the component service, it classifies and identifies sensitive information according to the encryption rules and calls the corresponding encryption algorithm for processing. In particular, when processing log data, the encryption component uses a memory isolation mechanism to protect the encryption process and prevent unauthorized access to sensitive information during processing.

[0071] When the encryption component receives an encryption request from a component service running on the host node (the request contains log data fragments to be processed and related data identifiers), it first initiates a sensitive information classification and identification process based on encryption rules. This classification and identification is not a simple keyword matching process, but rather relies on the encryption component's built-in rule engine to perform deep analysis of the encryption rules, extracting the pre-set feature identifiers for different types of sensitive information (such as data format features: passwords usually contain a combination of uppercase and lowercase letters, numbers, and special characters and their length conforms to a specific range; tokens are mostly fixed-length strings; semantic features: data fields in log data associated with keywords such as "username", "password", and "token"). Then, through a multi-dimensional feature matching algorithm, the log data fragments in the request are scanned and identified field by field and content by content. Finally, the identified sensitive information is accurately classified into pre-set categories (such as username, password, token, device identifier, etc.).

[0072] After completing the classification and identification, the encryption component will call the encryption algorithm corresponding to the current category through the built-in "Sensitive Information Category - Encryption Algorithm" mapping table. This mapping table is pre-built by the encryption component according to encryption rules. For example, if the rules stipulate that usernames use simple de-identification algorithms, passwords use RSA encryption algorithms, and tokens use symmetric encryption algorithms (the key is derived from the public key), then after classification, the encryption component will automatically match and call the corresponding algorithm module, and at the same time extract the required public key from the built-in storage area (such as calling the RSA algorithm module and passing in the public key when processing password information). This ensures that each type of sensitive information can be accurately processed according to the encryption rules, which avoids the waste of resources caused by over-encryption and prevents security risks caused by insufficient encryption.

[0073] The memory isolation mechanism used by the encryption component when processing log data is a core protection measure designed to address the risk that sensitive information (especially plaintext data and intermediate processing data) during the encryption process can be stolen through memory reads, dump attacks, and other means.

[0074] This mechanism is not a simple memory partition, but a deep isolation achieved through a system-level memory management module within the encryption component: When the encryption component starts its processing flow, the memory management module allocates an independent memory region in the host node's physical memory with strict access control. This region establishes a unique data interaction channel with the encryption processing module within the encryption component, and the channel uses dynamic permission verification. That is, only when the encryption processing module initiates a data read / write request, it performs real-time verification using a preset authentication key (which is stored in the kernel-level secure storage area of ​​the encryption component and cannot be accessed externally). Only after the verification is successful can data interaction be allowed. No other process (including the component service that initiates the encryption request, other applications on the host node, system background processes, etc.) can obtain access to this memory region, and even forced memory scanning tools cannot read the data in the region.

[0075] During the encryption process, the plaintext of sensitive information to be processed and the intermediate results generated by the algorithm (such as plaintext block data and key-derived data in the RSA encryption process) are stored and circulated only within this isolated memory area. Each data write is accompanied by real-time encryption protection (using a lightweight symmetric encryption algorithm to encrypt the data in memory in real time, and only temporarily decrypting it when the algorithm module is called). When the encryption process is completed (i.e., generating desensitized text or encrypted ciphertext and returning it to the component service), the memory management module will immediately start the data clearing process, thoroughly clearing all data (including plaintext, intermediate results, temporary keys, etc.) in the isolated memory area by repeatedly overwriting random data to ensure that no sensitive data remains.

[0076] In addition, the memory isolation mechanism also has anomaly monitoring capabilities. If an unauthorized process is detected attempting to break access permissions or illegally scan the isolated memory area, a security alarm will be immediately triggered by the encryption component, and the current encryption process will be suspended. At the same time, the isolated memory area will be locked, further preventing the possibility of unauthorized access to sensitive information during processing. This provides underlying security for the entire process of log encryption and desensitization.

[0077] In some embodiments, the method further includes:

[0078] Obtain the updated key and encryption rules sent by the management terminal;

[0079] The system updates the old configuration based on the updated encrypted configuration, and versions the old configuration and retains it for a preset duration.

[0080] Obtaining updated keys and encryption rules sent by the management terminal is a prerequisite for dynamic configuration updates. The triggering scenario is directly related to the security management needs of the cloud platform. When the management terminal determines that the key used by the current host node is at risk of expiration, the encryption algorithm no longer meets the security level, or the sensitive information processing rules need to be adjusted, based on preset security policies (such as key rotation cycle, encryption algorithm security assessment results) or external security requirements (such as customer security baseline upgrades, industry compliance standard updates), it will generate updated keys (i.e., new RSA public keys, corresponding to the public key in the newly generated RSA key pair on the management terminal, while the private key is still retained on the management terminal) and updated encryption rules (such as adding processing requirements for new sensitive information types, adjusting the encryption strength of existing sensitive information, for example, updating "username retains the first 3 digits for desensitization" to "retains the first 2 digits for desensitization", or adding a rule "device serial number uses RSA encryption").

[0081] The management terminal issues update commands via a pre-established secure communication link with the host node (the same link used in step 101 to obtain the initial configuration, employing an encrypted transmission protocol). These commands contain key information such as the update configuration package (encapsulating the update key and encryption rules), the update effective time, and the configuration version identifier. The encryption component on the host node continuously monitors the management terminal's configuration update channel. Upon receiving an update command, it first performs an integrity check on the update configuration package (by calculating the hash value of the configuration package and comparing it with the checksum issued by the management terminal with the command, confirming that the configuration package has not been tampered with or damaged during transmission). Simultaneously, it verifies the legitimacy of the update command (by verifying the management terminal's digital signature, ensuring the command originates from an authorized management terminal and is not illegally forged). After successful verification, the encryption component temporarily stores the update configuration package in a local temporary secure storage area to avoid directly overwriting existing configurations and causing service interruption, thus preparing for subsequent update operations.

[0082] An updated encryption configuration refers to a complete set of configurations including the updated key, updated encryption rules, and corresponding algorithm parameters (if the rule adjustment involves a new algorithm, the management system will simultaneously issue an algorithm adaptation module). When performing an update operation, the encryption component follows an atomic process of "verify first, then replace" to ensure that the update process does not affect the normal operation of the component services.

[0083] The first step is for the encryption component to load the updated configuration from the temporary storage area into an independent verification environment, simulate the encryption request of the component service (such as constructing username and password data for testing), call the rules and algorithms in the updated configuration to perform encryption processing, and verify whether the processing result meets expectations (such as the de-identification format is correct and the encrypted ciphertext can be decrypted by the management end later). At the same time, it checks the compatibility between the updated configuration and the existing functions of the encryption component (such as whether the algorithm module supports the new key format and whether the rule engine can parse the new rule logic).

[0084] The second step, after successful verification, is for the encryption component to perform configuration replacement during a preset update window (usually a period with low component service call frequency, such as the early morning maintenance window). First, the existing old configuration (old public key, old rules, old algorithm parameters) is backed up to a dedicated historical configuration storage area. Then, the updated configuration is migrated from the temporary storage area to the core working storage area of ​​the encryption component, overwriting the original old configuration. The third step, after the configuration replacement is completed, is for the encryption component to start real-time monitoring, record the processing result of the first component service request that calls the new configuration, and confirm that the new configuration can respond to encryption requirements normally. If an anomaly occurs (such as processing failure or incorrect result), the rollback mechanism is immediately triggered to restore the backed-up old configuration, avoiding the exposure of sensitive information or service interruption due to update failure.

[0085] Throughout the update process, the encryption component will provide feedback on the update progress to the management console (such as "verification passed", "replacing configuration", "update successful"), ensuring that the management console has real-time access to the configuration status of each host node, which meets the requirements of unified management.

[0086] When backing up old configurations to historical storage, the encryption component automatically adds multi-dimensional version tags. These tags include at least: configuration version number, effective period, a summary of core configuration information (such as the fingerprint of the old public key and key adjustments to old rules for quick identification), and an update reason identifier. This tagging information is stored bound to the old configuration data and protected with encryption to prevent unauthorized tampering, providing a clear basis for subsequent security audits and troubleshooting.

[0087] The preset retention period needs to be determined based on the cloud platform's security policies, industry compliance standards, and storage resources, and is typically set to between 7 and 90 days. During the retention period, the old configuration is in a "read-only" state, and can only be accessed by the encryption component in rollback scenarios or when providing data when an audit query is initiated on the management side. After the retention period expires, the encryption component will initiate an old configuration cleanup process, which will completely delete the old configuration and associated tag information by overwriting random data multiple times, so as to avoid historical configurations occupying too many storage resources and prevent the security risks faced by old configurations due to long-term retention.

[0088] The embodiments of this application provide a method for unified encryption of logs, and the method is described in detail in conjunction with the execution flow of the unified encryption of logs. Figure 2 This is a flowchart illustrating another method for unified log encryption provided in this disclosure, the method being applied to a management terminal, including:

[0089] Step 201: Generate a key pair and distribute the public key and encryption rules to each host node; wherein the key pair includes a public key and a private key;

[0090] The core of generating key pairs is to rely on the built-in encryption component of the management terminal to complete the creation of asymmetric key pairs that meet security standards. The key pairs are generated using the RSA algorithm. This is based on the maturity and security of the RSA algorithm in the field of asymmetric encryption. Its core characteristics are that the public key can be publicly transmitted for encryption, while the private key is only used for decryption and must be kept absolutely confidential. This fully meets the requirements of the cloud platform that "the management terminal uniformly controls decryption permissions and the host node only performs encryption operations".

[0091] During the key generation process, the encryption component on the management end uses a built-in key generation module to perform key pair generation operations in accordance with industry security standards. First, the module generates a random seed that meets the requirements of the RSA algorithm using a cryptographically secure random number generator, ensuring the uniqueness and unpredictability of the key pair. Then, based on this random seed, it executes the key generation logic of the RSA algorithm to calculate a pair of mathematically related but functionally separate keys—a public key and a private key. After generation, the management end immediately performs classified storage and security protection on the key pair: the private key, as the core credential for decrypting log data, is stored in a dedicated high-security storage area on the management end. This area is only accessible to the decryption module of the encryption component on the management end, and access requires multiple identity verifications to prevent any unauthorized process or personnel from reading, modifying, or copying the private key, thus providing dual protection against leakage of the private key from both physical and logical levels. The public key is temporarily stored in the public key distribution cache on the management end, preparing for subsequent distribution to host nodes. During the temporary storage process, it is periodically verified by the integrity verification mechanism within the management end to prevent the public key from being tampered with before distribution.

[0092] Before distribution, the encryption rules must be configured. These rules are formulated by the management end based on the overall security level requirements of the cloud platform, customer security baseline standards, and the hierarchical characteristics of sensitive information in the logs (such as the sensitivity differences of usernames, passwords, and tokens). The rule content must clearly define the correspondence between "sensitive information type and processing method." For example, for usernames with low sensitivity, the rule is set to "simple desensitization (retaining the first two characters)"; for passwords and tokens with extremely high sensitivity, the rule is set to "encryption processing based on RSA public key"; for medium-sensitivity information such as device identifiers, the rule is set to "partial character masking + fixed format retention," etc. All rules must be written in a structured format to ensure that the encryption component of the host node can directly parse and convert them into executable logic, avoiding rule failures due to inconsistent formats.

[0093] The management terminal establishes a connection with all host nodes within the cloud platform through a pre-set secure communication link. Upon connection establishment, the identity of each host node is verified, allowing only legitimate host nodes already under management to access the platform. Subsequently, the management terminal encapsulates the public key and encryption rules into a unified "configuration data packet," generates a unique verification value for this packet, and attaches the management terminal's digital signature to ensure the data packet is not tampered with during transmission and its origin is traceable. Next, the management terminal pushes the "configuration data packet + digital signature" to each host node one by one through the secure communication link. The push process supports batch distribution and breakpoint resumption—for scenarios with a large number of host nodes on the cloud platform, the management terminal adopts a batch distribution strategy to avoid excessive network bandwidth consumption. For transmission failures caused by network interruptions during distribution, the management terminal records the nodes that have successfully distributed the configuration and those that have not. Once the network is restored, only the nodes that have not completed the distribution will be resumed, ensuring that all host nodes receive the complete configuration.

[0094] After receiving the data packet, each host node verifies the digital signature against the management terminal's public key (the management terminal's trusted public key pre-stored on the host node). Simultaneously, it calculates the data packet's checksum and compares it with the checksum issued by the management terminal. Upon successful verification, it sends a "successful reception" signal to the management terminal. Once the management terminal receives feedback from all nodes, it completes the public key and encryption rule distribution process. If some nodes fail to verify or fail to provide feedback, the management terminal triggers a retry mechanism. If multiple retries fail, an anomaly alarm is generated and node information is recorded. This facilitates troubleshooting by operations personnel (e.g., node offline, network failure), ensuring that the distribution operation covers all host nodes and laying the foundation for subsequent unified log encryption and desensitization across all host nodes.

[0095] Step 202: Obtain the log data sent by the host node and upload the log data to the management terminal;

[0096] The log data originates from host node logs that have undergone encryption and anonymization processing. This type of log data is not the original plaintext log, but rather secure data generated after component services on the host node call the encryption component. It includes highly sensitive information (such as passwords and tokens) encrypted with RSA, less sensitive information (such as usernames) that has undergone simple anonymization processing, and regular log content that does not require processing. The data format has been standardized by the host node encryption component to ensure that the management end can directly parse it. Log data sending is triggered in two scenarios:

[0097] First, the logs are sent proactively at set times. The host node automatically initiates log upload requests during off-peak business hours according to the log collection cycle preset by the management terminal, avoiding the impact of concentrated uploads on network bandwidth and affecting the normal operation of the cloud platform.

[0098] Second, it passively sends logs on demand. When the management end needs to obtain log data from one or a batch of host nodes in real time for security audits, troubleshooting, or other purposes, it sends a log collection command to the target host node, triggering the host node to immediately send log data for the specified time period. Regardless of the triggering method, log transmission between the host node and the management end relies on a pre-set secure communication link. This link uses an encrypted transmission protocol that conforms to industry security standards, and requires two-way identity verification when establishing a connection: the management end verifies the unique identifier of the host node (such as the device ID and authentication key pre-registered by the host) to confirm that it is a legitimate node within the cloud platform; the host node verifies the digital certificate of the management end (pre-stored in the trusted certificate store of the host node's encryption component) to prevent sending log data to a forged management end, thus eliminating the risk of log theft or hijacking from the source of the link.

[0099] During log data transmission, host nodes encapsulate log data into "log data packets" of preset size. Each data packet includes key metadata, including but not limited to: a unique host node identifier, the log generation time range, a data packet checksum, and a log data type identifier. When the management terminal receives a log data packet, it first performs a double check on the host node identifier and checksum in the metadata: the identifier confirms the legitimacy of the sending node, excluding invalid data sent by illegal nodes; the hash value of the received data packet is calculated and compared with the checksum in the metadata to confirm that the data packet has not been damaged or tampered with during transmission due to network fluctuations or malicious attacks. If the checksum fails, the management terminal immediately sends a "retransmission request" to the host node, requesting the retransmission of the data packet until complete and correct log data is received. If multiple checks fail, an anomaly alarm is generated and faulty node information is recorded, facilitating maintenance personnel to troubleshoot network or host node anomalies.

[0100] Uploading the log data to the management terminal is essentially a process where the management terminal receives the log data and then performs standardized storage and management. After receiving and verifying all log data packets, the management terminal first uses its built-in log parsing module to perform structured processing on the standardized log data, extracting key fields from the logs (such as log level, component service identifier, and processed sensitive information fields), and establishing a three-dimensional index of "host node ID - log time - log content" to support subsequent rapid querying and filtering of log data.

[0101] The management system stores the processed log data in a dedicated, high-security log storage area. This storage area employs multiple security measures: First, storage encryption: the log data is encrypted in real-time using a built-in encryption algorithm on the management system before being written to the storage medium. Even if the storage medium is physically lost, the log content cannot be directly accessed. Second, access control: the storage area is only accessible to the management system's decryption and log auditing modules, and access requires strict identity authentication and operation approval to prevent unauthorized personnel or processes from reading the log data. Third, data backup: the management system performs incremental backups of the stored log data at preset intervals. The backup data is also encrypted and stored on a backup device physically isolated from the main storage area to prevent log data loss due to main storage failure.

[0102] In addition, the management system generates detailed operation logs for each log data upload process, recording information such as the log source node, reception time, storage location, and verification results, providing traceable evidence for subsequent security audits and troubleshooting.

[0103] Step 203: Decryption is performed based on the management terminal encryption component and the private key.

[0104] The management-side encryption component is the core carrier of decryption processing. This component is not a single functional module, but rather an integrated processing unit encompassing a decryption algorithm module, a private key secure invocation module, a log data parsing module, and a security protection module. Its core responsibility is to provide a standardized and highly secure execution environment for decryption operations. The decryption algorithm module pre-constructs RSA decryption algorithm logic consistent with the host node encryption component. Because highly sensitive information (such as passwords and tokens) in the encrypted logs uploaded by the host node is generated using a public key combined with the RSA algorithm, the management end needs to use the corresponding RSA decryption algorithm, relying on the private key, to complete the ciphertext restoration. Furthermore, this algorithm module has undergone performance and security optimization, supporting both fast decryption of single log entries and parallel decryption processing of batches of encrypted logs, avoiding the impact of insufficient decryption efficiency on the timeliness of log analysis (such as troubleshooting and security auditing).

[0105] The private key secure access module is the key hub connecting the decryption algorithm module and the private key storage area. Its core function is to achieve "on-demand access and recycling" of the private key under a strict permission verification mechanism, preventing the private key from being directly exposed or illegally copied during the decryption process. The log data parsing module is responsible for structuring the log data uploaded by the host node before decryption. By identifying the preset encryption identifiers in the log, it accurately locates the ciphertext fragments that need to be decrypted, avoiding invalid decryption operations on unencrypted information that has been desensitized. At the same time, it filters redundant data in the log, ensuring that the decryption operation is only performed on the ciphertext of key and sensitive information, thereby improving processing efficiency.

[0106] Once generated, the private key is stored in a dedicated, high-security storage area on the management end (such as an encrypted storage unit built on the Hardware Security Module (HSM), or an independent storage partition on the management end protected by kernel-level encryption). This area is completely isolated from the outside world, allowing only the private key security call module of the management end's encryption component to initiate access requests through a preset encrypted channel. Each request requires multiple permission checks: First, the identity of the entity initiating the decryption operation must be verified (such as the account permissions of the management end's maintenance personnel, or the authorization credentials of the audit system). Only authorized entities with "log decryption permissions" can trigger the request; second, the compliance of the decryption operation must be verified (such as whether a corresponding...). The system records the decryption approval process and whether it falls under a reasonable scenario for security auditing or troubleshooting. By linking with the management system's access control and approval system, it prevents decryption operations without compliance basis. Finally, when the private key security call module obtains the private key, it uses a "temporary loading in memory" method, loading the private key only into an isolated memory area inside the management encryption component (this area is completely isolated from the memory of other processes, and data transmission is encrypted in real time) for the decryption algorithm module to temporarily call. After decryption, the private key traces in the isolated memory are immediately cleared by overwriting random data multiple times, ensuring that the private key is always in a "not visible and not copyable" secure state.

[0107] In the specific decryption process, the management-side encryption component executes operations in the following orderly manner: First, it receives encrypted log data from the host node that has passed integrity verification. The log data parsing module scans the log field by field, extracts all ciphertext fragments that need to be decrypted by identifying preset encryption identifiers, and records the sensitive information type corresponding to each ciphertext fragment, providing a basis for subsequent decryption algorithm matching. Second, the private key security call module initiates a private key call request to the private key storage area according to the decryption requirements. After passing multiple permission verifications, the private key is temporarily loaded into an isolated memory area, and a limited call interface is opened to the decryption algorithm module. Subsequently, the decryption algorithm module decrypts the extracted ciphertext fragments... The process involves calling the corresponding RSA decryption algorithm, passing in a temporarily loaded private key, and performing the decryption operation. Taking ciphertext as an example, the algorithm first performs format verification on the ciphertext (confirming that the ciphertext conforms to the standard format of RSA encryption to avoid decryption failure due to ciphertext corruption), and then uses the mathematical inverse operation of the RSA algorithm to restore the ciphertext to the original plaintext. The entire operation is performed in the isolated memory of the encryption component on the management side, without interacting with external processes. After decryption, the encryption component performs immediate security processing on the decrypted plaintext information: if the purpose of decryption is for security auditing or troubleshooting, the plaintext information will be temporarily displayed on the authorized security interface on the management side (such as an auditing platform visible only to authorized personnel).

[0108] In some embodiments, the method further includes:

[0109] The encryption configuration transmission channel is used to synchronize and update the keys and encryption rules to each host node in real time, so as to ensure that the encryption components of each host node always use the latest encryption configuration.

[0110] The encrypted configuration transmission channel is the fundamental carrier for ensuring the secure and efficient transmission of updated content. Its construction relies on a dedicated secure communication architecture pre-established between the management terminal and the host node, rather than relying on ordinary data transmission links. This channel adopts multiple security protection designs from the physical layer to the application layer: at the transmission protocol level, it adopts an encrypted transmission protocol that meets the highest industry security standards, and ensures the legitimacy of the identities of both parties through a two-way certificate authentication mechanism.

[0111] At the data transmission level, all updates to be synchronized are encapsulated into "encrypted configuration data packets." Before encapsulation, a data verification value is generated using the SHA-256 hash algorithm, and then the verification value is digitally signed using a signature key exclusive to the management end. During data packet transmission, the protocol's built-in encryption algorithm is used for real-time encryption to ensure that even if the data packet is intercepted in the transmission link, it cannot be cracked or tampered with. At the channel stability level, the channel has a built-in heartbeat detection and breakpoint resumption mechanism. The management end will periodically send heartbeat packets to each host node to confirm the node's online status and channel connectivity. If a node's heartbeat response times out, it will be marked as "offline" and a retry connection will be triggered. If the transmission is interrupted due to network fluctuations during synchronization, the channel will record the transmitted data packet fragments and resume the unfinished part only after the network is restored, avoiding repeated transmission and wasting bandwidth, while ensuring the complete transmission of large configuration files (such as encryption rule sets containing complex rules). In addition, this channel is only used for the synchronous transmission of encrypted configurations and does not carry other business data. This achieves functional isolation, further reducing the risk of the configuration synchronization timeliness being affected by congestion in business data transmission, and ensuring that updated content can quickly reach all host nodes.

[0112] In some embodiments, generating a key pair and distributing the public key and encryption rules to each host node further includes:

[0113] Based on the current security level requirements of the cloud platform, the target encryption algorithm is determined and the corresponding key pair is generated. The encryption rules include setting different encryption processing methods for different sensitive information fields; different security level requirements correspond to different strengths of encryption algorithms.

[0114] The public key and encryption rules are distributed to each host node in the form of an encrypted packet through a secure transmission channel, and the encrypted packet is digitally signed and verified before distribution.

[0115] The security level requirements for cloud platforms are not a single standard, but a grading standard determined by a combination of factors such as customer security baseline, industry compliance standards, and data sensitivity. They are usually divided into three security levels: low, medium, and high, and each level corresponds to specific encryption strength requirements.

[0116] The core implementation of this logic is to use different strength encryption algorithms corresponding to different security levels. For example, when the cloud platform's security level is "low" (such as processing only non-core business logs, and sensitive information only includes ordinary usernames), the target encryption algorithm can choose a basic strength RSA algorithm (such as a key length of 2048 bits), which can meet basic encryption requirements and avoid resource consumption caused by excessively strong algorithms. When the security level is "medium" (such as processing regular business logs containing user passwords), the target encryption algorithm needs to be upgraded to a medium strength RSA algorithm (such as increasing the key length to 3072 bits) to enhance the ciphertext's resistance to cracking. When the security level is "high" (such as processing critical logs containing user tokens and core device authentication information), the target encryption algorithm needs to adopt a high strength RSA algorithm (such as a key length of 4096 bits), and additional security verification logic can be added at the algorithm level (such as performing integrity hash calculations on plaintext data before encryption to ensure that the encrypted data has not been tampered with).

[0117] After the target encryption algorithm is determined, the encryption component on the management end will call the built-in key generation module to generate the corresponding key pair strictly according to the parameter requirements of the selected algorithm (such as key length and random number generation standard). During the generation process, the random number generator will use a cryptographically secure random source (such as a physical random entropy source based on the management end hardware environment) to ensure the uniqueness and unpredictability of the key pair. The generated private key will be immediately stored in the management end's dedicated high-security storage area, while the public key will be temporarily stored in the configuration distribution preparation area to prepare for subsequent encapsulation and distribution.

[0118] In some embodiments, the step of synchronizing and updating the key and encryption rules to each host node in real time via the encrypted configuration transmission channel to ensure that the encryption components of each host node always use the latest encryption configuration includes:

[0119] In response to known vulnerabilities in the encryption algorithm or the expiration of the key usage period, a new encryption configuration is automatically generated and pushed to each host node.

[0120] The management console has a built-in algorithm vulnerability monitoring module, which uses two core methods to monitor the security status of encryption algorithms in real time:

[0121] First, we establish real-time data connections with authoritative security intelligence sources in the industry to automatically capture vulnerability information related to the encryption algorithms currently in use.

[0122] Second, we regularly initiate local algorithm security assessment processes, proactively identifying potential security vulnerabilities in algorithms through methods such as simulated attack tests and encryption strength verification.

[0123] When the vulnerability monitoring module detects a known vulnerability in the currently used encryption algorithm and the vulnerability risk level reaches a preset threshold, it will automatically send an "algorithm update trigger command" to the encryption configuration generation module on the management side. The command includes vulnerability details, the current algorithm identifier, and the recommended alternative algorithm standard.

[0124] In response to the triggering logic of "key usage period expires", the management revolves around the standardized management of the key lifecycle. When generating each batch of key pairs, the management terminal will set a clear "usage period" for the key according to the cloud platform security level requirements and industry key management best practices. This period information will be bound to the key pair and stored in the key management library of the management terminal.

[0125] The management system will activate the key cycle monitoring module to calculate the remaining validity time of each batch of keys in real time and set dual warning thresholds: the first threshold is "10% of the cycle remaining time", at which point the module will send a warning notification to the operation and maintenance personnel, indicating that the key is about to expire; the second threshold is "cycle expiration time point", when the key usage time reaches the set cycle, the module will automatically send a "key update trigger instruction" to the encryption configuration generation module. The instruction contains the version identifier of the expired key and the algorithm standard that the new key in the corresponding host node range must match.

[0126] Upon receiving an "algorithm update trigger command" or a "key update trigger command," the "automatic generation of new encryption configuration" step will execute according to a standardized process: First, the encryption configuration generation module, based on the algorithm standard in the command, calls the key generation module of the management-side encryption component to generate a new key pair (the private key is stored in the high-security storage area of ​​the management side, and the public key serves as the core content of the new key). The generation process strictly adheres to cryptographic security standards (such as using a cryptographically secure random number generator to ensure key uniqueness and ensuring that the key meets the current security level requirements through algorithm compliance verification); Second, the module will synchronously update the encryption rules; if the triggering reason is an algorithm vulnerability, the execution logic related to the old algorithm in the original encryption rules needs to be checked and adjusted to logic adapted to the new algorithm.

[0127] If the triggering reason is key expiration, the main logic of the encryption rule remains unchanged, but the version identifier of the new key will be associated in the rule to facilitate the host node encryption component to identify and bind the latest key; in the third step, the module integrates the new key and the updated encryption rule into a "new encryption configuration package", and performs legality and compatibility verification through the built-in configuration verification module (verifying whether the new key format is correct, whether there is a logical conflict in the encryption rule, and whether the new configuration is compatible with the encryption component version of all host nodes). After the verification is passed, the new encryption configuration package enters the preparation state for distribution.

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

[0129] Embodiments of this application also provide a device for unified encryption of logs. Figure 3 This is a schematic diagram of a unified log encryption device provided in an embodiment of this disclosure. The device is applied to a host node, such as... Figure 3 As shown, it includes:

[0130] The acquisition unit 31 is used to acquire the public key and encryption rules sent by the management terminal;

[0131] The encryption unit 32 is used to install an encryption component, which contains the public key, encryption algorithm and encryption rules, so that the component service running on the host node can call the encryption component to encrypt sensitive information when generating logs.

[0132] Furthermore, in one possible implementation of this disclosure embodiment, the encryption unit 32 is further configured to:

[0133] When the encryption component receives an encryption request from the component service, it classifies and identifies sensitive information according to the encryption rules and calls the corresponding encryption algorithm for processing. In particular, when processing log data, the encryption component uses a memory isolation mechanism to protect the encryption process and prevent unauthorized access to sensitive information during processing.

[0134] Furthermore, in one possible implementation of the embodiments of this disclosure, such as Figure 4 As shown, the device further includes:

[0135] The acquisition unit 31 is also used to acquire the updated key and encryption rules sent by the management terminal;

[0136] The update unit 33 is used to perform an update on the old updated configuration based on the updated encrypted configuration, and to version-mark the old configuration and retain it for a preset duration.

[0137] Embodiments of this application also provide a device for unified log encryption, which is applied to a management terminal. Figure 5 This is a schematic diagram of the structure of a unified log encryption device provided in an embodiment of the present disclosure, as shown below. Figure 5 As shown, it includes:

[0138] The generation unit 41 is used to generate key pairs and distribute the public key and encryption rules to each host node; wherein, the key pair includes a public key and a private key;

[0139] Acquisition unit 42 is used to acquire log data sent by the host node and upload the log data to the management terminal;

[0140] The decryption unit 43 is used to perform decryption processing based on the management terminal encryption component and the private key.

[0141] Furthermore, in one possible implementation of the embodiments of this disclosure, such as Figure 6 As shown, the device further includes:

[0142] The sending unit 44 is used to synchronize the updated key and encryption rules to each host node in real time through the encryption configuration transmission channel, so as to ensure that the encryption components of each host node always use the latest encryption configuration.

[0143] Furthermore, in one possible implementation of this disclosure embodiment, the generation unit 41 is further configured to:

[0144] Based on the current security level requirements of the cloud platform, the target encryption algorithm is determined and the corresponding key pair is generated. The encryption rules include setting different encryption processing methods for different sensitive information fields; different security level requirements correspond to different strengths of encryption algorithms.

[0145] The public key and encryption rules are distributed to each host node in the form of an encrypted packet through a secure transmission channel, and the encrypted packet is digitally signed and verified before distribution.

[0146] Furthermore, in one possible implementation of this disclosure, the sending unit 44 is further configured to:

[0147] In response to known vulnerabilities in the encryption algorithm or the expiration of the key usage period, a new encryption configuration is automatically generated and pushed to each host node.

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

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

[0150] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described embodiments of the unified log encryption method.

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

[0152] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described methods for unified log encryption.

[0153] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described log unified encryption method embodiments.

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

[0155] The above provides a detailed description of the method, apparatus, and electronic device for unified log encryption provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for unified encryption of logs, characterized in that, The method is applied to host nodes and includes: Obtain the public key and encryption rules sent by the management terminal; Install an encryption component, which contains the public key, encryption algorithm, and encryption rules, so that the component service running on the host node can call the encryption component to encrypt sensitive information when generating logs.

2. The method according to claim 1, characterized in that, The installation of the encryption component, wherein the encryption component contains the public key, encryption algorithm, and encryption rules, further includes: When the encryption component receives an encryption request from the component service, it classifies and identifies sensitive information according to the encryption rules and calls the corresponding encryption algorithm for processing. In particular, when processing log data, the encryption component uses a memory isolation mechanism to protect the encryption process and prevent unauthorized access to sensitive information during processing.

3. The method according to claim 1, characterized in that, The method further includes: Obtain the updated key and encryption rules sent by the management terminal; The system updates the old configuration based on the updated encrypted configuration, and versions the old configuration and retains it for a preset duration.

4. A method for unified encryption of logs, characterized in that, The method is applied to the management terminal and includes: Generate a key pair and distribute the public key and encryption rules to each host node; wherein, the key pair includes a public key and a private key; Obtain log data sent by the host node and upload the log data to the management terminal; Decryption is performed based on the management-side encryption component and the private key.

5. The method according to claim 4, characterized in that, The method further includes: The encryption configuration transmission channel is used to synchronize and update the keys and encryption rules to each host node in real time, so as to ensure that the encryption components of each host node always use the latest encryption configuration.

6. The method according to claim 4, characterized in that, The generation of key pairs and the distribution of the public key and encryption rules to each host node also includes: Based on the current security level requirements of the cloud platform, the target encryption algorithm is determined and the corresponding key pair is generated. The encryption rules include setting different encryption processing methods for different sensitive information fields; different security level requirements correspond to different strengths of encryption algorithms. The public key and encryption rules are distributed to each host node in the form of an encrypted packet through a secure transmission channel, and the encrypted packet is digitally signed and verified before distribution.

7. The method according to claim 5, characterized in that, The key and encryption rules, which are synchronized and updated in real time to each host node through the encrypted configuration transmission channel, to ensure that the encryption components of each host node always use the latest encryption configuration, include: In response to known vulnerabilities in the encryption algorithm or the expiration of the key usage period, a new encryption configuration is automatically generated and pushed to each host node.

8. A device for unified encryption of logs, characterized in that, The device is applied to a host node and includes: The acquisition unit is used to acquire the public key and encryption rules sent by the management terminal; An encryption unit is used to install an encryption component, which contains the public key, encryption algorithm, and encryption rules, so that the component service running on the host node can call the encryption component to encrypt sensitive information when generating logs.

9. A device for unified encryption of logs, characterized in that, The device is used in the management terminal and includes: A generation unit is used to generate key pairs and distribute the public key and encryption rules to each host node; wherein, the key pair includes a public key and a private key; The acquisition unit is used to acquire log data sent by the host node and upload the log data to the management terminal. The decryption unit is used to perform decryption processing based on the management terminal encryption component and the private key.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the log uniform encryption method as described in any one of claims 1 to 3 or 4 to 7 when executing the computer program.

Images