Data life cycle judgment method and device, storage medium and computer equipment

Abstract

The embodiment of the invention provides a data life cycle judgment method and device, a storage medium, computer equipment and a computer program product, and belongs to the field of data life cycle safety management. The method comprises the steps that multiple pre-established life cycle stage rules are established and stored and merged into a rule base, each rule comprises at least one condition item, and each condition item at least comprises a field identifier, a comparison operator and an expected value; analyzing and normalizing the original log of the data security equipment to obtain a standardized log with a unified field structure; matching the standardized logs with life cycle stage rules in a rule base according to a preset sequence; and under the condition that the standardized log is matched with all condition items of one rule for the first time, adding a life cycle stage identifier corresponding to the rule to the standardized log, forming an enriched log, outputting the enriched log, and ending a rule matching process aiming at the standardized log. And the data life cycle division precision and accuracy are effectively improved.

Description

Technical Field

[0001] This application relates to the field of data lifecycle security management, specifically to a data lifecycle determination method, apparatus, storage medium, computer equipment, and computer program product. Background Technology

[0002] Data security is the cornerstone of information security, encompassing the confidentiality, integrity, and availability of data. As enterprises and organizations increasingly rely on data-driven decision-making and business operations, data security becomes paramount. This is especially true when data involves personal privacy, trade secrets, or national security-related data, where the impact is even more profound. Data lifecycle management is a crucial component of data security. This management model divides the entire data flow from creation to destruction into several stages, such as generation, storage, use, sharing, archiving, and destruction. By identifying the characteristics and risks of each stage, it develops and implements stage-specific security strategies, thereby systematically improving data protection levels and fully unlocking data value while controlling risks.

[0003] A typical approach is to categorize all managed security devices in the enterprise information system and associate them with one or more data lifecycle stages based on their functional attributes. However, this method has significant drawbacks. Its control granularity is coarse; it is essentially device-centric rather than data operation-centric in determining the stage. This makes it impossible to finely differentiate between different types of data operations within the same device. Summary of the Invention

[0004] The purpose of this application is to provide a data lifecycle determination method, apparatus, storage medium, computer equipment, and computer program product.

[0005] To achieve the above objectives, the first aspect of this application provides a method for determining data lifecycle, the method comprising: Create and store multiple pre-created lifecycle phase rules and incorporate them into the rule base. Each rule includes at least one condition item, and each condition item includes at least a field identifier, a comparison operator, and an expected value. Each rule is used to define the lifecycle phase that will be divided into the log data that matches it. Collect raw logs from data security devices, parse and normalize the raw logs to obtain standardized logs with a unified field structure; For each standardized log entry, the standardized log entry is matched with the lifecycle stage rules in the rule base in a predetermined order; For each standardized log entry, if the standardized log entry matches all the conditions of a rule for the first time, a lifecycle stage identifier corresponding to that rule is added to the standardized log entry, the enriched log entry is generated and output, and the rule matching process for the standardized log entry ends.

[0006] In this embodiment of the application, adding a lifecycle stage identifier corresponding to the rule to the standardized log includes: adding a lifecycle stage field to the structure of the standardized log, and using the lifecycle stage identifier corresponding to the rule matched with the standardized log as the value of the field.

[0007] In this embodiment, the predetermined order is determined based on the priority of lifecycle stage rules, with rules of higher priority being used first to match standardized logs.

[0008] In this embodiment of the application, the method further includes: performing syntactic and logical compliance checks on the rules before storing the lifecycle stage rules in the rule base, and returning an error message to the user when the check fails.

[0009] In this embodiment of the application, the method further includes: not enriching the standardized log if the standardized log fails to match all rules.

[0010] In this embodiment of the application, the method further includes: enriching the standardized logs and outputting the enriched logs, and then manually evaluating the enriched logs.

[0011] A second aspect of this application provides a data lifetime determination apparatus, comprising: a memory configured to store instructions; and a processor configured to retrieve instructions from the memory and, when executing the instructions, to implement any of the aforementioned data lifetime determination methods.

[0012] A third aspect of this application provides a machine-readable storage medium storing instructions, characterized in that, when executed by a processor, the instructions cause the processor to be configured to perform any of the aforementioned data lifetime determination methods.

[0013] A fourth aspect of this application provides a computer device, including a memory and a processor. The memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of any of the above-described data lifecycle determination methods.

[0014] The fifth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements any of the above-described data lifecycle determination methods.

[0015] This application proposes a data lifecycle determination method. By standardizing and normalizing the raw logs of data security devices, and then automatically matching and labeling the standardized logs using configurable rules that support field-level logical combinations and priority determination, the method achieves highly accurate identification and enrichment of the lifecycle stage of data operations, thereby classifying data into different lifecycle stages. This significantly improves the precision and accuracy of data lifecycle segmentation.

[0016] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0017] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings: Figure 1 The schematic diagram illustrates a flowchart of a data lifecycle determination method according to an embodiment of this application; Figure 2 This diagram schematically illustrates an interface for creating lifecycle phase rules according to an embodiment of this application. Figure 3 This illustration schematically shows a data lifecycle determination method flowchart according to another embodiment of this application; Figure 4 The diagram illustrates the internal structure of a computer device according to an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0019] Figure 1 The illustration shows a flowchart of a data lifecycle determination method according to an embodiment of this application. Figure 1 As shown in one embodiment of this application, a data lifecycle determination method is provided, including the following steps: Step 101: Create and store multiple pre-created lifecycle phase rules and incorporate them into the rule base. Each rule includes at least one condition item, and each condition item includes at least a field identifier, a comparison operator, and an expected value. Each rule is used to define the lifecycle phase that will be divided into the log data that matches it.

[0020] The system provides a graphical user interface (GUI) for security administrators to create rules. The graphical user interface includes features such as... Figure 2 As shown. Each rule includes: Rule Name, used for semantic identification of the rule; Rule Content, used to define the judgment logic, constructing fields, comparison operators, expected value input / selection, and logical relationships; Lifecycle, i.e., the stage identifier corresponding to the rule, including "Production," "Transmission," "Use," "Storage," "Destruction," "Sharing," etc.; Data Flow, used to help describe the transmission direction of the data involved in the rule, such as "Destination Asset → Client"; Update Activation, used to control whether the rule takes effect immediately; Description, a text input box, used to record the business purpose or remarks of the rule. The user interface also provides a "Reset" button to clear the current form and a "Back" button to cancel the operation. By building a rule base with structured, configurable, and centralized management features, the system achieves clear expression, flexible expansion, and efficient maintenance of lifecycle judgment logic, providing a fundamental guarantee for the accuracy, adaptability, and maintainability of the entire data lifecycle calculation system.

[0021] In one embodiment, comparison operators in the rule content support equality, not equal, exist, not exist, regular expression matching, multi-value matching, etc. If multiple fields need to be set simultaneously, the logical operators between the different fields need to be explicitly specified. Logical relationships include AND and OR.

[0022] In one embodiment, the method further includes: performing syntactic and logical compliance checks on the rules before storing the lifecycle stage rules in the rule database, and returning an error message to the user if the check fails. During the user's input process and before clicking "OK," the interface performs real-time validation. For example, ensuring that the condition items in the rule content are complete and the lifecycle stage has been selected. After clicking "OK" to submit, the system backend performs deep validation, including syntactic validity checks and logical conflict detection of condition items. If the validation fails, an error message is displayed and the user is returned to the interface. If the validation succeeds, the successfully validated rules are structured and stored in the rule database.

[0023] Step 102: Collect the raw logs from the data security device, parse and normalize the raw logs to obtain standardized logs with a unified field structure.

[0024] Data security equipment includes, but is not limited to, Data Loss Prevention (DLP) systems, Database Auditing (DAP) systems, data masking tools, and Application Firewalls (WAFs). The system supports collecting raw log streams sent in real-time or in batches from various devices via multiple standard protocols. The collected raw logs have diverse formats, and the system deconstructs each raw log entry based on a preset parsing template or model. The parsing process extracts valid information units from the logs and maps them to temporary "field-value" pairs. For example, from a raw alarm, raw fields such as "event time," "source IP," "operation type," and "target object" are parsed. Then, normalization processing is performed, including: field standardization, mapping the device-specific raw field names obtained from the parsing to a set of standard field identifiers defined internally by the system. For example, the fields src_ip, client_address, and sip representing "source IP" in different devices are uniformly mapped to the standard field source_ip; value standardization: converting field values ​​into uniform enumerated values, formats, or units of measurement. For example, various expressions for the operation result "success" (success, 1, SUCC) are uniformly mapped to SUCCESS; timestamps are uniformly converted to ISO 8601 format. After completing the above mapping, the system generates a standardized log with a unified field structure, typically in the format of a structured data object, and all subsequent processing is based on this standard format. This embodiment eliminates the differences in data format and semantics between devices. This transforms heterogeneous logs that were originally impossible to directly correlate and compare into a data stream with common standard fields and values, providing a foundation for global data lifecycle determination.

[0025] Step 103: For each standardized log entry, match the standardized log entry with the lifecycle stage rules in the rule base in a predetermined order.

[0026] In one embodiment, the predetermined order is determined based on the priority of lifecycle phase rules, with higher-priority rules being used first for matching standardized logs. Each lifecycle phase rule must be assigned a numeric priority attribute upon creation. This attribute is set through the rule configuration interface and persistently stored in the rule repository as part of the rule metadata. After initialization or a rule repository update, the log enrichment engine loads all enabled rules from the database. The engine sorts all loaded rules according to their priority values, generating an ordered list of rules, whose order is the predetermined matching order. Once a log file successfully matches a rule, the engine immediately stops attempting to match any subsequent lower-priority rules. A log file is only marked as belonging to the lifecycle phase defined by its first successfully matched, highest-priority rule. If a log file fails to match a current high-priority rule, the engine automatically proceeds to the next rule in the ordered list and repeats this process until a match is successful or all rules have been matched.

[0027] For each input standardized log entry, the engine executes the following matching loop sequentially: First, a rule is selected. From the sorted list of rules, the rule with the highest priority is retrieved for matching. Then, the rule conditions are parsed, breaking them down into a logical expression tree composed of condition items. Each condition item contains: a field identifier (Key), a comparison operator, and an expected value. Condition items are connected by logical operators. The engine starts calculating from the first condition item of the rule, extracting the field identifier from the condition item and searching for the same field in the current standardized log. If the field is found, the engine calculates whether the actual value of the field in the log satisfies the relationship with the expected value according to the comparison operator specified in the condition item. Supported operations include: equal to, not equal to, exist, not exist, regular expression matching, multi-value matching, etc. If the calculation is satisfied, the next condition item of the rule is calculated. If the calculation is not satisfied, the calculation of the current rule is terminated immediately, and the log entry is determined not to match the rule. A log entry is determined to match a rule only when all condition items connected by "AND" or the entire logical expression combined by "OR" and "NOT" are satisfied. An example is given below: The rule `log_type=499 AND proto=pSpace AND oper_type=29` fails to match if `oper_type=5` in the log, as the third condition is not met. However, if `oper_type=29` in the log, all conditions are met sequentially, resulting in a successful match.

[0028] Once a standardized log entry successfully matches a rule, the engine immediately stops attempting to match any remaining rules and designates that rule as a valid match. If the log entry fails to match any rule in the rule chain sequentially, the engine determines that there are no matching rules.

[0029] The system matching result will be passed to step 104 for log enrichment. This step ensures the efficiency and determinism of the matching process.

[0030] Step 104: For each standardized log, if the standardized log matches all the conditions of a rule for the first time, add the lifecycle stage identifier corresponding to the rule to the standardized log, form the enriched log and output it, and end the rule matching process for the standardized log.

[0031] The "first match" here refers to the first rule that is fully satisfied by the log in the preset order.

[0032] In one embodiment, adding a lifecycle stage identifier corresponding to the rule to the standardized log includes: adding a new lifecycle stage field to the structure of the standardized log, and using the lifecycle stage identifier corresponding to the rule matched by the standardized log as the value of this field. The system extracts the target lifecycle stage identifier bound to the successfully matched rule, and while maintaining the integrity of all data in the original standardized log, the system adds a specific field to the log's data structure. The name of this field is globally unified in the system, for example, lifecycle_stage. The obtained lifecycle stage identifier is assigned as the value to the newly added field. An example of its data structure is as follows: Original standardized log: "timestamp": "2023-10-27 10:00:00", "src_ip": "192.168.1.100", "oper_type": "INSERT", "target_db": "customer_info" Enriched logs (with a new lifecycle_stage field): "timestamp": "2023-10-27 10:00:00", "src_ip": "192.168.1.100", "oper_type": "INSERT", "target_db": "customer_info", "lifecycle_stage": "Production" Once the enrichment operation on a log entry is completed, the system immediately terminates any subsequent rule matching process for that log entry. Regardless of whether other potentially matching rules exist in the rule base, they are not evaluated further. This first-match-and-terminate mechanism ensures that each log entry has one and only one clear lifecycle stage identifier, avoiding semantic confusion caused by multiple markers. It also avoids unnecessary full rule set traversal for a single log entry, optimizing computational resources. The generated enriched logs are output in real-time or near real-time through predefined system data channels.

[0033] In one embodiment, the method further includes: not enriching the normalized log if it fails to match any of the rules. If, after iterating through all rules, a normalized log entry fails to match all conditions of any rule, the system will not enrich it. This log entry may be output in its original normalized log format with a special identifier, such as lifecycle_stage: "Uncategorized", or transferred to a manual review queue for administrator analysis and potential creation of new rules.

[0034] In one embodiment, the method further includes: enriching the standardized logs and outputting the enriched logs, followed by manual evaluation of the enriched logs. The system automatically imports all enriched logs into a dedicated manual evaluation workbench queue. Users, based on their professional knowledge, evaluate the system's automatic evaluation results and can perform one or more of the following operations on the workbench: Confirm, i.e., acknowledge the system's automatic evaluation. This operation will mark the evaluation status of the log as "Confirmed"; Correct, indicating that the system's evaluation is incorrect. Users can manually select a correct lifecycle stage identifier. This correction result will immediately update the lifecycle_stage field value in the enriched log; Reclassify, if the existing stage set cannot accurately describe the situation, users can select "Reclassify" and enter text comments describing what they consider a reasonable classification or special case. If the evaluation finds that the error originates from the rule itself, users can directly click "Submit Rule Optimization Suggestion" on the workbench. The system will automatically associate the current log with the triggering rule and allow users to describe the problem. The manual evaluation feedback collected by the system, especially rule optimization suggestions, will enter a management process. All rule optimization suggestions are centrally stored and managed and can be viewed by rule, frequency, submitter, etc. Rule administrators or the system itself can review these suggestions periodically. Frequently used or generally accepted effective suggestions can be directly used to edit existing rules or create new ones. The results of corrections and reclassifications can be used as labeled training data to optimize the accuracy of future rule matching or to train auxiliary classification models.

[0035] In one embodiment, users create lifecycle stage determination rules through a graphical rule configuration interface. Each rule includes: a rule name (for inputting a semantic identifier); rule content (for defining the determination logic, including fields, comparison operators, expected value input / selection, and logical relationships); lifecycle (the stage identifier corresponding to the rule, including "production," "transmission," "use," "storage," "destruction," and "sharing"); data flow direction (for describing the transmission direction of the data involved in the rule, such as "destination asset → client"); update activation (for controlling whether the rule takes effect immediately); and a description (a text input box for recording the business purpose or remarks of the rule). The user interface also provides a "reset" button to clear the current form and a "back" button to cancel the operation. Before the rule is entered into the database, the system performs syntax and logic validation. After successful validation, the rule and its configured priority are stored in the rule database. The system continuously collects raw heterogeneous logs from various managed data security devices. Through a pre-set parsing template, key information in the raw logs is extracted and normalized, that is, synonymous field names and values ​​in different devices are mapped to unified standard field identifiers and value ranges. Finally, standardized logs with a unified field structure are output, providing consistent input data for subsequent judgments. The log enrichment engine loads a rule base sorted by priority. For each standardized input log, the engine matches it against the rules in descending order of priority. During matching, the engine sequentially calculates each condition in the rule: searching for the corresponding field in the log and comparing the actual value with the expected value based on the specified operator. A match is considered successful only when all conditions of a rule are satisfied. Once a log is matched successfully for the first time, the engine immediately performs enrichment: adding a uniformly named field to the log's data structure and using the target stage identifier defined by the matching rule as its value, thus generating the enriched log. Subsequently, the engine immediately terminates all subsequent rule matching for that log and outputs the enrichment result. The system pushes all enriched logs to the human review platform. Users can review log details, matched rules, and associated context in the interface, and perform operations such as confirmation, correction, or reclassification of the system's judgment results. More importantly, users can directly submit rule optimization suggestions for judgment errors. The system collects all analysis feedback and suggestions, applying them to the continuous optimization of the rule base. Rule administrators modify existing rules or create new ones based on frequently used and effective suggestions. This allows the accuracy of the entire system's judgments to continuously improve with accumulated operational experience. This embodiment achieves refined and automated identification of the lifecycle stage of data operations through configurable field-level rules, overcoming the shortcomings of traditional device-centric coarse-grained classification. The automated process enables real-time processing and enrichment of massive logs, and combined with manual analysis, it focuses on analyzing key or complex events, significantly improving the analysis and response efficiency of the security team.Through a closed-loop optimization mechanism driven by human feedback, the system can quickly adapt to new business scenarios and threat patterns, ensuring that lifecycle judgment results remain highly accurate over the long term, and providing a reliable data foundation for accurate alerts, compliance audits, and situational awareness.

[0036] Figure 1 This is a flowchart illustrating a data lifecycle determination method in one embodiment. It should be understood that, although... Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise explicitly stated herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0037] In one embodiment, Figure 3This diagram illustrates a data lifecycle determination method flowchart according to another embodiment of this application. The upper left of the diagram shows the user manually creating or editing lifecycle determination rules in the system interface. Field selection: Selecting fields for determination (such as operation type, protocol type, etc.) from standardized log fields. Comparison operation settings: Setting comparison conditions for the selected fields, such as equal to, contain, regular expression matching, etc. Logical operation settings: If the rule contains multiple conditions, the logical relationship between the conditions needs to be set. Rule verification: The system verifies the configured rules: if verification is successful, the rule is stored in the database (DB); if verification fails, the process terminates and needs to be reconfigured. The upper right of the diagram shows the log collection and processing stage. The system collects raw logs from various security devices. These security devices can be leakage prevention devices, data auditing devices, de-identification devices, etc. The logs are uniformly collected and processed by the processing engine. Data processing operations include log parsing and normalization operations. Log parsing involves structured parsing of the logs and extraction of key fields. Log normalization unifies logs from different sources and formats into a standardized format. The middle part of the diagram shows the rule matching and annotation stage. Loading Rules: The system loads stored lifecycle rules from the database. Rule Association with Logs: The pre-processed logs are matched against the loaded rules one by one. Matching Result Processing: Successful Match: A corresponding "Lifecycle Stage" field is added to the log and assigned a value; Failed Match: The log is not labeled with a stage. Storage and Termination: The processed logs are stored in the database or output to downstream systems, and the process ends. The lower half of the diagram shows the detailed calculation logic of the lifecycle rule matching process, describing how user-configured rules are applied to log data to determine its lifecycle stage. The process is as follows: Decomposition into Atomic Conditions: Each lifecycle rule is broken down into a comparison between a single field and a certain value. Comparison operators are used to calculate each atomic condition, including: equal to (=), not equal to (<>), greater than or equal to (>=), less than or equal to (<=), belong to (IN), fuzzy matching (LIKE), and empty (IS NULL). Calculation of Each Atomic Condition: The system executes the comparison operations defined in the atomic conditions one by one for the corresponding field values ​​in the log to determine whether they are satisfied. The results are combined using logical operators: NOT: negates the condition result; AND: the result is true only if all conditions are true; OR: the result is true if any condition is true. Overall result calculation: Based on the logical operators set in the rule, the calculation results of each atomic condition are combined to obtain the overall matching result of the rule. If the overall matching result is true, the corresponding lifecycle stage of the rule is marked, that is, the lifecycle stage defined by the rule is assigned to the current log. If the matching result is false, no data is marked, and the next rule is executed.The rules iteratively determine whether the current rule is the last rule. If it is, the process ends; otherwise, it returns to execute the next rule, repeating the atomic condition calculation, logical combination, and result judgment process. This embodiment's flowchart clearly illustrates how the system achieves matching from a single log entry to its lifecycle stage through decomposition, calculation, combination, and judgment steps during rule matching. The process employs a cyclical matching mechanism, supporting the sequential execution of multiple rules until a match is successful or all rules have been traversed, demonstrating the system's structured, automated, and flexible rule execution.

[0038] In one embodiment, a data lifecycle determination device (not shown in the figure) is provided, comprising: The memory is configured to store instructions; The processor is configured to retrieve instructions from memory and to implement any of the aforementioned data lifetime determination methods when executing instructions.

[0039] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and data lifetime determination methods can be implemented by adjusting kernel parameters.

[0040] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0041] This application provides a storage medium on which a program is stored, which, when executed by a processor, implements the above-described data lifecycle determination method.

[0042] This application provides a processor for running a program, wherein the program executes the above-described data lifecycle determination method during runtime.

[0043] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4As shown. The computer device includes a processor A01, a network interface A02, memory (not shown), and a database (not shown) connected via a system bus. The processor A01 provides computing and control capabilities. The memory includes internal memory A03 and a non-volatile storage medium A04. The non-volatile storage medium A04 stores an operating system B01, a computer program B02, and a database (not shown). The internal memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 stored in the non-volatile storage medium A04. The network interface A02 is used for communication with external terminals via a network connection. The computer program B02, when executed by the processor A01, implements a data lifecycle determination method.

[0044] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0045] This application provides a computer (electronic) device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements any of the above data lifecycle determination methods.

[0046] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing the steps of an initialization data lifecycle determination method.

[0047] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0048] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0049] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0050] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0051] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0052] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0053] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0054] It should also be noted that 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 process, method, article, or apparatus.

[0055] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for determining data lifecycle, characterized in that, The method includes: Create and store multiple pre-created lifecycle phase rules and incorporate them into the rule base. Each rule includes at least one condition item, and each condition item includes at least a field identifier, a comparison operator, and an expected value. Each rule is used to define the lifecycle phase that will be divided into the log data that matches it. Collect raw logs from data security devices, parse and normalize the raw logs to obtain standardized logs with a unified field structure; For each standardized log entry, the standardized log entry is matched with the lifecycle stage rules in the rule base in a predetermined order; For each standardized log, if the standardized log matches all the conditions of a rule for the first time, a lifecycle stage identifier corresponding to that rule is added to the standardized log, the enriched log is generated and output, and the rule matching process for the standardized log ends.

2. The method according to claim 1, characterized in that, Adding a lifecycle stage identifier corresponding to the rule to the standardized log includes: In the structure of the standardized log, a new lifecycle stage field is added, and the lifecycle stage identifier corresponding to the rule matched with the standardized log is used as the value of this field.

3. The method according to claim 1, characterized in that, The predetermined order is determined based on the priority of the lifecycle stage rules, with rules of higher priority being used first to match the standardized logs.

4. The method according to claim 1, characterized in that, The method further includes: Before storing lifecycle phase rules into the rule base, the rules are checked for syntactic and logical compliance, and an error message is returned to the user if the check fails.

5. The method according to claim 1, characterized in that, The method further includes: If the standardized log fails to match any of the rules, the standardized log will not be enriched.

6. The method according to claim 1, characterized in that, The method further includes: After enriching the standardized logs and outputting the enriched logs, the enriched logs are manually evaluated.

7. A data lifecycle determination device, characterized in that, include: The memory is configured to store instructions; A processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the data lifetime determination method according to any one of claims 1 to 6.

8. A machine-readable storage medium storing instructions thereon, characterized in that, When executed by a processor, this instruction causes the processor to be configured to perform the data lifecycle determination method according to any one of claims 1 to 6.

9. A computer device comprising a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the data lifecycle determination method as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the data lifecycle determination method according to any one of claims 1 to 6.

Images