Dynamic adaptive data security processing method, system, and program product

Abstract

The application discloses a kind of dynamic self-adapting data security processing method, system and program product, the method comprises: in response to the access request of target file, it is detected whether target file exists signature information, signature information is based on the security verification mark of preconfigured in preset area in the analysis result of target file;When there is signature information, the first password algorithm is used to verify signature information;According to the verification result of signature information, the processing decision of access request is determined.The dynamic self-adapting data security processing method provided in the embodiment of the application, by configuring signature information for security verification in target file, avoids the loss of signature information occurs, while the configuration mode can adapt to different formats of target file, to realize the dynamic adaptation of data security processing, so as to improve the guarantee effect of data security.

Description

Technical Field

[0001] This application relates to the field of data security technology, specifically to a dynamic adaptive data security processing method, system, and program product. Background Technology

[0002] Currently, file transfer across systems and devices has become the norm. With the increasing demand for information security, file protection technology has become the key to preventing malicious tampering, unauthorized access, and file self-repair.

[0003] In existing technologies, file protection technologies typically rely on file system extended attributes or verification through centralized management servers, which suffer from problems such as insufficient flexibility, poor cross-platform compatibility, and easy loss of verification information. Furthermore, they lack self-repair mechanisms for some damaged sensitive files. Summary of the Invention

[0004] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide a dynamic adaptive data security processing method, system and program product. This method avoids the loss of signature information by configuring the signature information used for security verification in the target file. At the same time, this configuration method can adapt to target files of different formats to achieve dynamic adaptation of data security processing, thereby improving the protection effect of data security.

[0005] In a first aspect, the present invention provides a dynamically adaptive data security processing method, the method comprising:

[0006] In response to an access request for the target file, the system checks whether the target file contains signature information. The signature information is a security verification identifier pre-configured in a preset area based on the parsing result of the target file.

[0007] When signature information exists, the first cryptographic algorithm is used to verify the signature information;

[0008] Based on the verification result of the signature information, a decision is made on how to process the access request.

[0009] In one possible implementation, the signature information is a security verification identifier pre-configured in a preset area based on the parsing result of the target file, including:

[0010] For each target file, a preset area for configuring signature information is determined based on the parsing results of the target file;

[0011] Based on the preset signature level of the signature information, a second cryptographic algorithm is used to generate signature information within a preset area. The signature level is used to characterize the data coverage of the signature information in the target file.

[0012] In one possible implementation, the preset area of ​​the signature information includes at least the .signature section of the ELF file and preset fields in the header of the BIN file.

[0013] In one possible implementation, the processing decision for the access request is determined based on the verification result of the signature information, including:

[0014] When the verification result indicates a mismatch in the signature information, a backup copy of the target file is obtained, and the target file is repaired using the backup copy; the backup copy is stored within the configured time period of the signature information.

[0015] In one possible implementation, the method also includes:

[0016] Access to the target file is prohibited if a backup copy of the target file does not exist.

[0017] In one possible implementation, the method also includes:

[0018] When the number of repair failures of the target file reaches the preset number within a preset time period, the target file will be transferred to the isolation area.

[0019] In one possible implementation, the method also includes:

[0020] A security incident report is generated based on the entire response process of the access request; the security incident report should include at least the time of tampering and the results of the remediation.

[0021] Secondly, a dynamic adaptive data security processing system is provided, which includes a signature generation module and a security verification module.

[0022] The signature generation module is used to pre-configure signature information within a preset area based on the parsing results of the target file;

[0023] The security verification module is used to detect whether the target file has signature information in response to an access request for the target file;

[0024] The security verification module is also used to verify the signature information using a first cryptographic algorithm when signature information exists, and to determine the processing decision of the access request based on the verification result of the signature information.

[0025] In one possible implementation, the system also includes a self-healing module;

[0026] The self-repair module is used to obtain a backup copy of the target file when the verification result indicates a mismatch in the signature information, and to repair the target file using the backup copy; the backup copy is stored within the configured time period of the signature information.

[0027] Thirdly, a computer program product is provided, which includes instructions that, when executed, perform the method described in any one of the first aspects.

[0028] Fourthly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the method described in any one of the first aspects above.

[0029] Fifthly, a computer-readable storage medium is provided having a computer program stored thereon, characterized in that the program, when executed by a processor, implements the method described in any one of the first aspects above.

[0030] Compared to existing file protection methods that rely on file system extended attributes or verification through centralized management servers, the dynamic adaptive data security processing method, system, and program products provided in this application configure the signature information used for security verification within the target file. On the one hand, this avoids the possibility of signature information being easily lost due to the separation of signature information and file content. On the other hand, by automatically identifying and judging the file format of the target file, it can adapt to target files of different formats, thereby achieving dynamic adaptation of data security processing and improving the protection effect of data security. Attached Figure Description

[0031] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0032] Figure 1 This is a block diagram of the dynamically adaptive data security processing system 10 provided in the embodiments of this application;

[0033] Figure 2 This is a flowchart illustrating a dynamic adaptive data security processing method provided in an embodiment of this application;

[0034] Figure 3 This is a schematic diagram illustrating the execution of the self-healing module 13 provided in an embodiment of this application;

[0035] Figure 4 This is a schematic diagram illustrating the execution of the signature generation module 11 provided in an embodiment of this application;

[0036] Figure 5 This is a schematic diagram illustrating the execution of the security verification module 12 provided in this embodiment of the application;

[0037] Figure 6 This is another flowchart illustrating the dynamic adaptive data security processing method provided in the embodiments of this application;

[0038] Figure 7 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0039] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0040] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present application will now be described in detail with reference to the accompanying drawings and embodiments. Furthermore, the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The terms "first" and "second," etc., in the specification and claims of the embodiments of this application are used to distinguish different objects, not to describe a specific order of objects.

[0041] The following is an explanation of the terms used in this application:

[0042] (1) File system extended attributes: a mechanism that allows users to attach additional metadata to files or directories. The attached metadata is usually independent of regular permissions and content, such as security tags in the SELinux security module.

[0043] (2) Centralized management service: A computer technology that manages data through a central control node, such as a cloud file server;

[0044] (3) ELF format: a universal binary format for executable files, shared libraries and object files under Linux / Unix systems, which can support dynamic linking and multiple CPU architectures;

[0045] (4) BIN format: A raw binary file format that does not contain metadata, typically used for firmware, disk images or bare-metal programming;

[0046] (5) TrustZone: A hardware-level security extension provided by the ARM architecture, which can isolate sensitive operations by dividing the secure world and the normal world;

[0047] (6) SGX: A CPU security technology that allows applications to perform sensitive computations in a protected “enclave” to prevent external access to data (including the OS).

[0048] To protect file data, existing technologies offer the following approaches: First, storing trusted rules for reading files in file extended attributes for trusted verification; however, this method relies on the file system supporting extended attributes, making it unsuitable for embedded scenarios, and the extended attributes are prone to losing rule information during file copying. Second, using hardware to achieve secure data isolation; however, this method relies on the management baseline of the control server, consumes significant resources, and the centralized management approach can easily disrupt normal business operations if the management server malfunctions. Third, utilizing a network center to determine whether a smart device is permitted based on the results of remote trusted verification. The method offers several approaches: First, it provides access to the network. However, this requires sending proof information to the network center, resulting in poor flexibility and real-time performance. Furthermore, the separation of measurement information from the file makes it prone to loss. Second, it utilizes the real-time synchronization capabilities of distributed storage nodes to replace file transfer between platforms. However, this method is only applicable to specific files and cannot adapt to various parsing scenarios. Third, it adds a sequence number to the distributed data and performs RSA signing, using the distributed key to verify data integrity and retrieving the sequence position via the sequence number, recovering data in case of retrieval failure. However, this method is primarily applicable to distributed data, and the separation of signature information from the distributed data makes it unsuitable for adapting to different file formats.

[0049] Based on this, existing technologies still have problems such as the easy loss of verification rules in embedded or cross-system scenarios (corresponding to dependence on specific file systems), lack of self-repair capability for verification failure files (corresponding to centralized measurement management architecture), and inability to adapt to multiple file formats (corresponding to signature verification only for specific file formats).

[0050] In view of the above problems, embodiments of this application provide a dynamic adaptive data security processing method, system, and program product that overcomes or at least partially solves the above problems. The method stores the signature information used for security verification and the target file content together, avoiding the loss of signature information, and can adapt to target files of different formats.

[0051] It should be noted that although the operation of the method of the present invention is described in a specific order in the accompanying drawings, this does not require or imply that the operations must be performed in that specific order, or that all the operations shown must be performed in order to achieve the desired result.

[0052] In one possible implementation, the dynamically adaptive data security processing method provided in this application is applicable to a dynamically adaptive data security processing system. For example, Figure 1 This is a block diagram of the dynamically adaptive data security processing system 10 provided in the embodiments of this application, as shown below. Figure 1As shown, the dynamic adaptive data security processing system 10 includes a signature generation module 11, a security verification module 12, and a self-healing module 13, which are deployed on computer devices to achieve data security processing.

[0053] For example, the signature generation module 11 is used to pre-configure signature information in a preset area of ​​the target file based on the parsing result of the target file. The signature information is a security verification identifier when accessing the target file. The security verification module 12 is used to verify the signature information of the target file when receiving an access request for the target file. The self-repair module 13 is used to repair the content of the target file after the signature information verification fails.

[0054] Figure 2 This is a flowchart illustrating a dynamic adaptive data security processing method provided in an embodiment of this application, such as... Figure 2 As shown, the method specifically includes the following steps:

[0055] Step S201: In response to the access request of the target file, detect whether the target file has signature information. The signature information is a security verification identifier pre-configured in a preset area based on the parsing result of the target file.

[0056] In one possible implementation, before receiving an access request for the target file, the signature information of the target file can be set based on the parsing result of the target file.

[0057] For example, for each target file, a preset area (i.e., the signature area) for configuring signature information can be determined first based on the parsing results of the target file.

[0058] Specifically, the file format of the target file is determined based on the parsing results of the target file, and the signature area is determined based on the file format.

[0059] For example, when the file format represents the target file as an ELF file, the signature area corresponds to the .signature section of the ELF file; when the file format represents the target file as a BIN file, the signature area corresponds to the preset field in the header of the BIN file (i.e., the reserved field in the header); secondly, for other file formats, the signature area can correspond to the footer of the file.

[0060] Optionally, the same signature area can be set for target files of different formats, for example, the signature area can be fixed as the file header.

[0061] For example, after determining the signature area of ​​the target file, a second cryptographic algorithm can be used to generate signature information within the signature area according to the preset signature level of the signature information; wherein, the signature level is used to characterize the data coverage of the signature information in the target file, that is, it can be used to determine whether to perform full-text signing of the target file.

[0062] Specifically, the preset signature level of the signature information can be determined based on the operation command parameters or configuration file, including a specified data range (e.g., code segment) and the full text data; wherein, the specified data can be specified by the operation user.

[0063] For example, when the file format indicates that the target file is an ELF file, the specified data may include the code segment and data segment of the ELF file; alternatively, the specified data may also be data between the start position and the end position of the file (e.g., data between the start of the file and 64 bytes).

[0064] It should be noted that the reason for setting specified data when the default signature level is full-text data is because the file content itself contains changing data, and this changing data is likely to cause the signature verification result to fail. Therefore, the unchanging data other than the changing data can be determined as the specified data. Secondly, when the file is large and execution speed is a priority, specifying data can also improve the file execution speed.

[0065] For example, the second cryptographic algorithm can be an asymmetric encryption algorithm. Based on this, when the preset signature level is specified data, the asymmetric encryption algorithm can be used to generate signature information for the specified data of the target file and embed the signature information into the preset signature area.

[0066] For example, when the operation command parameters are cmd_sign --sign_level 1 --file test.elf, cmd_sign represents the signing command, --sign_level represents the default signing level as 1, and --file test.elf represents the signing file as test.elf.

[0067] Alternatively, the signature information can be configured using a multi-signature or dynamic signature strategy.

[0068] In one possible implementation, when the signature information of the target file is successfully set (i.e., a file containing configuration information and signature information is successfully generated), the original target file can be backed up to the storage area to form a backup copy of the target file in the storage area.

[0069] For example, during the backup process of the original target file, it is necessary to ensure that the signature information strictly corresponds to the content of the target file in order to avoid the signature information from being separated from the content of the target file during transmission or storage.

[0070] Specifically, by designing an exclusive cryptographic module, a strict correspondence between the signature information and the content of the target file can be achieved. That is, only one program can call the cryptographic algorithm at any given time, in order to avoid data interference.

[0071] Optionally, when successfully obtaining the key and signature information using the signature tool, a fixed-length data writing method can be used to ensure that the signature information corresponds to the content of the target file.

[0072] Alternatively, a distributed storage verification method can be used to implement the above backup process for the target file.

[0073] This embodiment avoids the loss of signature information by storing the signature information and the target file content together, and solves the problem in the prior art that the verification information is easily lost during cross-platform transmission or copying due to the separation of the verification information and the target file. Secondly, for target files of different formats, different methods can be used to write signature information, thereby achieving automatic compatibility with multiple file formats and having good dynamic adaptive capabilities.

[0074] Step S202: When signature information exists, the signature information is verified using the first cryptographic algorithm.

[0075] In one possible implementation, when it is determined that the target file contains signature information, the signature information can be verified using a first cryptographic algorithm based on the relevant information of the target file; wherein, the first cryptographic algorithm can be a decryption algorithm corresponding to the second cryptographic algorithm mentioned above.

[0076] For example, relevant information about the target file can be obtained based on its parsing results, specifically including file information, signature information, and public key information.

[0077] For example, when the file format indicates that the target file is an ELF file, the target file can be opened through the system interface to obtain the signature section and the location of the signature field. The signature information and key information can be obtained by reading the signature section (signature field) information.

[0078] Correspondingly, the application domain can provide the relevant information of the target file to the security domain, so that the security domain's signature interface can verify the signature information using the first cryptographic algorithm based on the file information, signature information, and public key information. Specifically, the security domain used in the verification process can be implemented using technologies such as TrustZone or SGX.

[0079] Step S203: Determine the processing decision for the access request based on the verification result of the signature information.

[0080] In one possible implementation, by verifying the signature information in step S202 above, a processing decision for the target file access request can be determined based on the verification result of the signature information.

[0081] For example, access to the target file is allowed when the verification result indicates that the signature information has been verified.

[0082] Optionally, if the verification result indicates that the signature information does not match, it can be determined that the target file may have been tampered with, and the target file can be repaired.

[0083] For example, a backup copy of the target file can be obtained to repair the target file using the backup copy, which is the backup copy of the target file formed in the storage area mentioned above.

[0084] Optionally, if the target file does not have signature information, access to the target file is denied, or an alarm log is generated.

[0085] In another embodiment of this application, a specific method for repairing the target file is also provided.

[0086] For example, Figure 3 This is a schematic diagram illustrating the execution of the self-healing module 13 provided in an embodiment of this application. (Refer to...) Figure 3 When the verification result indicates that the signature information does not match, the application domain corresponding to the self-repair module 13 can be used to determine whether the target file needs self-repair. If the target file needs self-repair, the security domain self-repair operation interface can be called to repair the target file; otherwise, if the target file does not need self-repair, access will be denied or an alarm log will be generated.

[0087] Specifically, when the target file needs to self-repair, the security domain corresponding to the self-repair module 13 can find and obtain the backup copy of the target file. If a backup copy exists, the backup copy is used to overwrite the damaged target file to complete the repair of the target file. If no backup copy exists, access to the target file is prohibited and a detailed log is recorded. Non-critical files are simply marked as untrusted files.

[0088] For example, when the number of repair failures of the target file within a preset time period reaches a preset number, the target file is transferred to the isolation area; wherein, the reasons for repair failure may include no corresponding backup copy, the backup copy is outdated (i.e., not the latest version of the file), the backup copy is incomplete (i.e., it was interrupted during the backup process or there is insufficient storage space), and the backup copy is corrupted (i.e., other programs may corrupt the backup file), etc., and this application does not impose specific restrictions on this.

[0089] For example, if the target file fails to be repaired three times in a row, a permanent disable mechanism can be triggered to move the target file to an isolated area and notify the administrator accordingly.

[0090] It should be noted that when a target file undergoes self-repair, the signature information should be reconfigured.

[0091] In this embodiment, after the signature information verification fails, the file self-repair is completed by automatically recovering sensitive file data from the secure area, thereby realizing the automatic recovery of important files and reducing manual intervention.

[0092] In addition, for example, the self-healing module 13 can also generate a security incident report based on the entire process of responding to the access request, so as to facilitate subsequent audit analysis; wherein, the security incident report includes at least metadata such as the time of tampering and the repair results.

[0093] It should be noted that the reason for recording the file tampering time in the security incident report is that the entire response process of the access request includes multiple verifications of the target file's signature information (for example, the signature information is verified when the file is accessed or executed). When the interval between two verifications is long, the file may have been tampered with.

[0094] In another embodiment of this application, a complete implementation process of the signature generation module 11 is also provided.

[0095] For example, Figure 4 This is a schematic diagram illustrating the execution of the signature generation module 11 provided in an embodiment of this application, as shown below. Figure 4 As shown, for each target file, the file format can be parsed first to determine that the pre-configured signature area of ​​the ELF file format is the .signature section, and the pre-configured signature area of ​​the BIN file format is the reserved field in the header.

[0096] Subsequently, based on the pre-configured signature level of each target file, it is determined whether the target file is a full-text signature. If so, it is determined to generate signature information in the full-text data content; otherwise, it is determined to generate signature information in the specified data field.

[0097] Finally, the signature information is embedded to generate a file containing configuration and signature information, specifically including the signature level, self-healing flag, signature, and public key.

[0098] In another embodiment of this application, a complete implementation process for the security verification module 12 is also provided.

[0099] For example, Figure 5 This is a schematic diagram illustrating the execution of the security verification module 12 provided in this application embodiment, as shown below. Figure 5As shown, the security verification module 12 is used to implement the three execution steps of triggering, verification, and decision-making.

[0100] Specifically, when a verification request for the signature information of the target file is received, the configuration information and signature key of the target file are parsed, and the verification request is executed based on the parsing result.

[0101] During the execution of the verification request, the security domain's signature interface can use cryptographic algorithms to verify the signature information based on the file information, signature information, and public key information provided by the application domain.

[0102] If the signature information is verified, access to the target file is allowed; otherwise, the security verification module 12 refuses access to the target file or generates an alarm log to implement the decision-making process.

[0103] In another embodiment of this application, a complete implementation flow of the dynamically adaptive data security processing system 10 is also provided.

[0104] For example, Figure 6 This is another flowchart illustrating the dynamic adaptive data security processing method provided in this application embodiment, as shown below. Figure 6 As shown, the method includes the following steps:

[0105] Step S601: Parse the target file;

[0106] Step S602: Generate signature information for the target file;

[0107] Step S603: Receive the access request for the target file;

[0108] Step S604: Detect whether the target file contains signature information;

[0109] For example, if yes, then proceed to step S6051; otherwise, proceed to step S6052.

[0110] Step S6051: Trigger the signature information verification mechanism;

[0111] Step S6052: Deny access or log alert;

[0112] Step S606: Determine whether the signature information has been verified.

[0113] For example, if yes, then proceed to step S6071; otherwise, proceed to step S6072.

[0114] Step S6071: Allow access operation;

[0115] Step S6072: Determine whether to perform self-repair of the target file;

[0116] For example, if so, proceed to step S608; otherwise, proceed to step S6052.

[0117] Step S608: Has the target file been successfully recovered?

[0118] For example, if so, proceed to step S6071; otherwise, proceed to step S609.

[0119] Step S609: Permanently disable the target file and generate a log alert.

[0120] The dynamic adaptive data security processing method provided in this application supports multiple file formats such as ELF and BIN without relying on file system features, and has high flexibility. Through the strong binding of signature information and target file content, the signature information is not lost across platforms, and has good robustness. Secondly, it can automatically recover important files and reduce manual intervention.

[0121] The following is for reference. Figure 7 , Figure 7 A schematic diagram of a communication device suitable for implementing embodiments of this application is shown, such as... Figure 7 As shown, the communication device 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) 702 or a program loaded from a storage section 708 into a random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the system's operating instructions. The CPU 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0122] The following components are connected to the input / output (I / O) interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the input / output (I / O) interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0123] Specifically, according to embodiments of this application, the flowchart above refers to... Figure 2 , Figure 6Any of the described processes can be implemented as a computer software program. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program contains program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit (CPU) 701, it performs the functions defined in the system of this application.

[0124] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium compatible with computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0125] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operational instructions of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two connected blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. 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, can be implemented using a dedicated hardware-based system that performs the specified functions or operational instructions, or using a combination of dedicated hardware and computer instructions.

[0126] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be housed in a processor; for example, a processor may be described as including a semantic extraction unit, a weight allocation unit, and a determination unit. The names of these units or modules do not necessarily constitute a limitation on the unit or module itself.

[0127] On the other hand, this application also provides a computer-readable storage medium, which may be included in the communication device described in the above embodiments, or may exist independently and not assembled into the communication device. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the methods described in this application. For example, it may execute... Figure 2 , Figure 6 Each step of any of the methods shown.

[0128] This application provides a computer program product including instructions that, when executed, cause the method described in this application to be performed. For example, it can execute... Figure 2 , Figure 6 Each step of any of the methods shown.

[0129] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A dynamic adaptive data security processing method, characterized in that, The method includes: In response to an access request for a target file, the system detects whether there is signature information in the target file. The signature information is a security verification identifier pre-configured in a preset area based on the parsing result of the target file. When the signature information exists, the signature information is verified using the first cryptographic algorithm; Based on the verification result of the signature information, a processing decision for the access request is determined; The signature information is a security verification identifier pre-configured in a preset area based on the parsing result of the target file, including: For each target file, a preset area for configuring the signature information is determined based on the parsing result of the target file; Based on the preset signature level of the signature information, the second cryptographic algorithm is used to generate the signature information in the preset area, wherein the signature level is used to characterize the data coverage range of the signature information in the target file; The step of determining the processing decision for the access request based on the verification result of the signature information includes: When the verification result indicates that the signature information does not match, a backup copy of the target file is obtained, and the target file is repaired using the backup copy; the backup copy is stored during the configured time period of the signature information.

2. The dynamic adaptive data security processing method according to claim 1, characterized in that, The preset area of ​​the signature information includes at least the .signature section of the ELF file and preset fields in the header of the BIN file.

3. The dynamic adaptive data security processing method according to claim 1, characterized in that, The method further includes: If a backup copy of the target file does not exist, access to the target file is prohibited.

4. The dynamic adaptive data security processing method according to claim 1 or 3, characterized in that, The method further includes: When the number of repair failures of the target file within a preset time period reaches a preset number, the target file will be transferred to an isolation area.

5. The dynamic adaptive data security processing method according to claim 1, characterized in that, The method further includes: A security incident report is generated based on the entire response process of the access request; the security incident report includes at least the time of tampering and the result of the repair.

6. A dynamic adaptive data security processing system, characterized in that, The system includes a signature generation module and a security verification module; The signature generation module is used to pre-configure signature information in a preset area based on the parsing result of the target file, wherein the signature information is a security verification identifier pre-configured in the preset area based on the parsing result of the target file. The security verification module is used to detect whether there is signature information in the target file in response to an access request for the target file; The security verification module is further configured to, when the signature information exists, verify the signature information using a first cryptographic algorithm, and determine the processing decision for the access request based on the verification result of the signature information; The signature information is a security verification identifier pre-configured in a preset area based on the parsing result of the target file, including: For each target file, a preset area for configuring the signature information is determined based on the parsing result of the target file; Based on the preset signature level of the signature information, the second cryptographic algorithm is used to generate the signature information in the preset area, wherein the signature level is used to characterize the data coverage range of the signature information in the target file; The system also includes a self-healing module; The self-repair module is used to obtain a backup copy of the target file when the verification result indicates that the signature information does not match, and to repair the target file using the backup copy; the backup copy is stored during the configured time period of the signature information.

7. A computer program product, characterized in that, The computer program product includes instructions that, when executed, cause the method as described in any one of claims 1-5 to be implemented.

Images