Safety control method and system for cloud inventory management platform

Abstract

The invention relates to the technical field of information security, and discloses a security control method and system for a cloud inventory management platform. The method comprises the following steps: acquiring a cloud interaction data set; performing abnormal operation identification by adopting the behavior reference template to obtain an abnormal operation set; the behavior characteristics in the set are matched with historical risk modes, and threat possibility scores are generated; related inventory data records are extracted from the data of which the threat possibility scores exceed a preset score threshold, and a to-be-checked data set is formed; performing field content and time sequence comparison on the data set, and analyzing a tampering sign to obtain a tampering possibility level; and inputting the level into a risk processing rule base, and generating and executing a safety control strategy. According to the method, a whole-process security mechanism from user behavior monitoring to data authenticity verification to risk closed-loop disposal is constructed, so that potential data tampering risks can be effectively identified and coped with, and the security and data reliability of a cloud inventory management platform are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of information security technology, and in particular to a security control method and system for a cloud inventory management platform. BACKGROUND

[0002] Inventory management is an integral part of modern enterprise operations, directly related to supply chain efficiency and rationality of resource allocation. With digital transformation, inventory management is gradually migrating to cloud platforms, providing more efficient data processing and sharing capabilities. However, security issues in this field have become a key bottleneck restricting its development.

[0003] Currently, traditional cloud inventory management platforms typically use security control methods based on static rules. For example, they generally rely on fixed permission settings and data encryption methods to protect inventory data. Some existing technologies introduce risk detection, but their evaluation dimensions are single and the data is lagging, making it difficult to reflect the real risk level of user operations in real time and comprehensively. The security strategies in these existing technologies are relatively fixed, lacking dynamic perception and adaptability to changes in user behavior and environment.

[0004] In the cloud environment where data interacts frequently, existing technologies are difficult to fully capture abnormal patterns in user behavior and cannot timely identify potential data tampering or leakage risks. Therefore, existing technologies result in an inability to accurately verify the authenticity of inventory data and identify potential security risks. SUMMARY

[0005] The present application provides a security control method and system for a cloud inventory management platform to solve the problem of low platform security and data reliability due to fixed security strategies that are difficult to dynamically identify and respond to data tampering risks in existing technologies.

[0006] In a first aspect, to solve the above technical problems, the present application provides a security control method for a cloud inventory management platform, comprising: obtaining a cloud interaction data set; performing abnormal operation behavior identification on the cloud interaction data set using a pre-set behavior benchmark template to obtain an abnormal operation set; matching and calculating real-time behavior characteristics in the abnormal operation set with pre-set historical risk patterns to determine potential threats and generate a threat likelihood score; extracting relevant inventory data records for data whose threat likelihood score exceeds a pre-set score threshold to form a data group to be checked; comparing the field content and time sequence of the data group to be checked piece by piece to analyze data tampering signs and obtain a tampering likelihood level; The tamper possibility level is input into a preset risk processing rule base to generate and execute a security control strategy.

[0007] Preferably, the cloud interaction dataset is acquired, including: Real-time multi-source log information is acquired to generate an initial interaction dataset; the initial interaction dataset includes user operation trajectory data and background response record data; According to the initial interaction dataset, the user operation trajectory data and the background response record data are matched and time-sequentially associated to obtain the cloud interaction dataset.

[0008] Preferably, the cloud interaction dataset is subjected to abnormal operation behavior identification using a preset behavior benchmark template to obtain an abnormal operation set, including: According to the cloud interaction dataset, the user operation trajectory data is subjected to item-by-item comparison using a preset behavior benchmark template to identify behavior segments deviating from the norm to obtain a preliminarily screened abnormal operation set; The operation frequency of the behavior segments in the preliminarily screened abnormal operation set is time-sequentially compared with a preset operation frequency threshold value, and behavior segments exceeding the operation frequency threshold value are marked as high-risk behavior segments; The high-risk behavior segments are subjected to hierarchical processing to obtain segments related to risk mining and are summarized to obtain the abnormal operation set.

[0009] Preferably, real-time behavior features in the abnormal operation set are matched with and calculated based on a preset historical risk pattern to determine potential threats and generate a threat possibility score, including: Real-time behavior features of current user operations are extracted from the abnormal operation set; the real-time behavior features include operation time, operation frequency, and access path; From a pre-constructed historical risk pattern library, a historical risk pattern matching the real-time behavior features is searched to determine potential threats; According to the real-time behavior features, a weighted calculation is performed based on a preset weight value to obtain the threat possibility score.

[0010] Preferably, if the threat possibility score exceeds a preset score threshold value, relevant inventory data records are extracted to form a data group to be checked, including: If the threat possibility score exceeds a preset threat score threshold value, relevant inventory data records are acquired from a cloud storage library to form a preliminarily extracted data record group; The inventory data records and historical records are subjected to content consistency comparison, and data items with inconsistent content are marked to obtain abnormal marked data; The abnormal marking data is formatted to form a standardized to-be-checked data set.

[0011] Preferably, the field content of the to-be-checked data set is compared with the time sequence piece by piece to analyze data tampering signs and obtain a tampering possibility level, including: The field content record in the to-be-checked data set is checked piece by piece to identify a content deviation of the field; The time stamp of the inventory data record is continuously detected to identify an abnormality of the time sequence; The content deviation and the abnormality of the time sequence are associated and matched to obtain a comprehensive abnormal data set; The comprehensive abnormal data set is evaluated according to a preset tampering risk evaluation rule to determine the tampering possibility level.

[0012] Preferably, the tampering possibility level is input into a preset risk processing rule library to generate and execute a security control strategy, including: According to the tampering possibility level, a corresponding risk processing rule is matched from the risk processing rule library to generate a security control strategy; According to the security control strategy, the access permission associated with the inventory data record is adjusted to generate an execution confirmation identifier; The record with the adjusted permission is integrity-verified to determine a verification result; The verification result and the execution confirmation identifier are stored in a cloud log library to complete platform security control.

[0013] In a second aspect, the present application provides a security control system of a cloud inventory management platform, including: A data acquisition module is configured to acquire a cloud interaction data set; An abnormality identification module is configured to identify abnormal operations of the cloud interaction data set by using a preset behavior benchmark template to obtain an abnormal operation set; A threat evaluation module is configured to match and calculate real-time behavior characteristics in the abnormal operation set with a preset historical risk pattern to determine potential threats and generate a threat possibility score; A data extraction module is configured to extract relevant inventory data records of data whose threat possibility score exceeds a preset score threshold to form a to-be-checked data set; A tampering analysis module is configured to compare the field content of the to-be-checked data set with the time sequence piece by piece to analyze data tampering signs and obtain a tampering possibility level; A risk response and closed-loop processing module is configured to input the tampering possibility level into a preset risk processing rule library to generate and execute a security control strategy.

[0014] In a third aspect, the present application also provides an electronic device comprising a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor implements the security control method of the cloud inventory management platform according to any one of the above embodiments when executing the computer program.

[0015] In a fourth aspect, the present application also provides a computer readable storage medium comprising a stored computer program, wherein the computer readable storage medium controls the device where the computer readable storage medium is located to execute the security control method of the cloud inventory management platform according to any one of the above embodiments when the computer program runs.

[0016] Compared with the prior art, the present application has the following beneficial effects: (1) The present application realizes accurate and rapid identification of abnormal operations by real-time acquisition and integration of multi-source log information and screening of user behavior by using a behavior benchmark template, and solves the problem of weak risk discovery ability caused by single data source and insufficient analysis dimension in the prior art, thereby providing reliable data input for subsequent security analysis.

[0017] (2) The present application constructs a multi-level and progressive analysis mechanism from behavior to data by combining real-time behavior characteristics with historical risk patterns for threat assessment, and further conducting dual verification of field content and timestamp on data records triggered by high-risk operations, thereby significantly improving the accuracy and depth of data tampering indication identification.

[0018] (3) The present application establishes a closed-loop processing flow from risk level assessment to automatic generation and execution of security strategies, can dynamically adjust access permissions according to tampering possibility levels and record disposal results, realizes rapid response and effective control of security risks, and enhances the intelligent defense capability and long-term operation reliability of the cloud inventory management platform. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 is a security control method flow diagram of a cloud inventory management platform provided by the first embodiment of the present application; Figure 2 is a security control system structure diagram of a cloud inventory management platform provided by the second embodiment of the present application. DETAILED DESCRIPTION

[0020] With reference to the drawings of the embodiments of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described, obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative work are within the protection scope of the present application.

[0021] With reference to Figure 1 The first embodiment of the present application provides a security control method of a cloud inventory management platform, comprising the following steps: S11, acquiring a cloud interaction data set; S12, performing abnormal operation behavior identification on the cloud interaction data set by using a preset behavior benchmark template to obtain an abnormal operation set; S13, matching and calculating real-time behavior features in the abnormal operation set with a preset historical risk mode to determine potential threats and generate a threat possibility score; S14, extracting relevant inventory data records for data whose threat possibility score exceeds a preset score threshold to form a to-be-checked data group; S15, comparing field contents and time sequences of the to-be-checked data group piece by piece to analyze data tampering signs and obtain a tampering possibility level; S16, inputting the tampering possibility level into a preset risk processing rule library to generate and execute a security control strategy.

[0022] In step S11, the cloud interaction data set is acquired, comprising: Real-time acquisition of multi-source log information to generate an initial interaction data set; the initial interaction data set comprises user operation trajectory data and background response record data; According to the initial interaction data set, the user operation trajectory data and the background response record data are matched and time-sequentially associated item by item to obtain the cloud interaction data set.

[0023] It should be noted that the multi-source log information mainly covers two types of core data: one is user operation trajectory data, which refers to all operation records of a user on a platform front end, such as user browsing, clicking, searching, ordering, and other behavior trajectories; the other is background response record data, which refers to response logs generated by a platform back-end server in response to user operations, such as server returned status codes, request processing time, error information, and the like. These two types of data together reflect the overall picture of a complete user interaction.

[0024] Exemplarily, in an actual application of a cloud inventory management platform, the following information is collected at the same time: user A logs in the system at 10:05:30 (user operation trajectory), the system returns a login success status code 200 at 10:05:31 (background response record); subsequently, user A queries the inventory of "material B" at 10:06:15 (user operation trajectory), and the system returns the query result at 10:06:17 (background response record). These logs of different sources are collected together to form an initial interaction data set.

[0025] It is worth noting that after obtaining the initial interaction data set, an explicit association between the user front-end behavior and the system back-end response is established. In an implementation, the process includes two key links of item-by-item matching and time sequence association. The system performs item-by-item matching between the user operation trajectory data and the background response record data in the same time window in the initial interaction data set. The purpose of matching is to verify whether each operation of the front end has obtained a reasonable response of the back end.

[0026] Exemplarily, when performing item-by-item matching, if the system finds that a user initiates 20 inventory modification requests (user operation trajectory data) within 1 minute, but the background response record shows that only 5 requests are successfully executed, and the remaining 15 times are timeout or error status codes. Such inconsistency between the operation and the response will be identified and marked as a clue of abnormal behavior by the system. In addition, the system also performs time sequence association analysis to compare the behavior characteristics of the user such as operation period and IP address change with the response log of the background in the time dimension. For example, if it is found that the above high-frequency modification operation is concentrated in the non-working period in the early morning, and is accompanied by frequent switching of IP addresses, through time sequence association analysis, it can be inferred that this may be an automated malicious attack behavior. Through the above matching and association, a cloud interaction data set that is structurally processed and contains clear behavior clues is finally obtained.

[0027] In step S12, for the cloud interaction data set, a preset behavior benchmark template is used to identify abnormal operation behaviors to obtain an abnormal operation set, including: According to the cloud interaction data set, the user operation trajectory data is compared item by item with a preset behavior benchmark template to identify behavior segments deviating from the norm to obtain a preliminarily screened abnormal operation set; The operation frequency of the behavior segments in the preliminarily screened abnormal operation set is time sequence compared with a preset operation frequency threshold, and the behavior segments exceeding the operation frequency threshold are marked as high-risk behavior segments; The high-risk behavior segments are processed in layers to obtain segments related to risk mining, and are summarized to obtain the abnormal operation set.

[0028] It should be noted that the behavior benchmark template is a multi-dimensional normal user behavior model based on platform historical big data analysis and summary. The behavior benchmark template defines the typical operation path, operation frequency and logic of a normal user when performing a specific task. When a real-time user operation trajectory deviates significantly from the normal pattern defined in the template, the behavior segment is identified by the system.

[0029] For example, assume that the standard operation path for inventory modification defined in the behavior benchmark template is: login -> find target material through search or list -> enter material detail page -> click'modify inventory' button -> submit modification -> exit. In actual monitoring, the system detects that the operation trajectory of a certain user is: "login -> directly access the inventory modification page of a specific material through URL -> submit modification. The user's behavior skips the necessary search and browsing steps, which is an irregular and suspicious operation path. This deviation in the path will be identified by the system and the behavior segment will be classified into the preliminary screening abnormal operation set for further analysis.

[0030] In an implementation mode, after obtaining the preliminary screening abnormal operation set, the system will further determine the risk level of the set, and the analysis dimension at this time focuses on the operation frequency. Specifically, the system compares the operation frequency of each behavior segment in the set with a preset operation frequency threshold. If the operation frequency of a behavior segment exceeds the threshold, it will be marked as a high-risk behavior segment.

[0031] For example, assume that the system's preset operation frequency threshold is 10 operations per minute. When analyzing the preliminary screening abnormal set, it is found that one of the behavior segments shows that a user has clicked the refresh inventory list function 20 times in 1 minute. Since 20 times exceeds the threshold of 10 times, the behavior segment is therefore officially marked as a high-risk behavior segment by the system and is included in the scope of potential threats for subsequent processing.

[0032] In an implementation mode, the system will classify high-risk behavior segments according to the nature of the anomaly, such as high-frequency repeated operations, invalid clicks, or irregular time period operations. Through this layering, the system can extract key segments directly related to specific risk scenarios (such as malicious brushing, crash attack, etc.) and aggregate them to ultimately form a precise abnormal operation set for the next threat assessment.

[0033] In step S13, the real-time behavior characteristics in the abnormal operation set are matched with the preset historical risk patterns and calculated to determine potential threats and generate threat possibility scores, including: extract real-time behavior features of the current user operation from the set of abnormal operations; the real-time behavior features include operation time, operation frequency, and access path; retrieve a historical risk pattern matching the real-time behavior features from a pre-constructed historical risk pattern library, and determine a potential threat; perform weighted calculation on the real-time behavior features combined with preset weight values to obtain the threat possibility score.

[0034] In an implementation manner, the embodiment first extracts structured real-time behavior features from each behavior segment in the set of abnormal operations obtained in S12. It should be noted that the real-time behavior features are multi-dimensional data, which are key indicators for quantifying user behavior, including: operation time, which refers to a specific time point or period when the behavior occurs, for example, whether it is during normal working hours or in the early morning.

[0035] operation frequency, which refers to the number of times an operation is performed within a unit of time, reflecting the intensity of the behavior.

[0036] access path, which refers to the sequence of pages or function nodes that a user passes through when performing a series of operations on the platform, reflecting the operation logic of the behavior.

[0037] In an implementation manner, after the real-time behavior features are extracted, the system calls a pre-constructed historical risk pattern library and matches the extracted features with the library. The historical risk pattern library is a knowledge base that stores a large number of behavior feature patterns of historical cases that have been confirmed as data tampering, malicious attacks, or other security incidents. By comparing the current behavior features with the historical risk patterns in the library, the system can determine whether the current operation has a potential threat.

[0038] For example, assume that the real-time behavior features of a user are “operation time: 3 a.m.; operation frequency: 20 times per minute; access path: skip search and directly access inventory modification page”. The system searches the historical risk pattern library and finds that the feature combination highly matches a known historical risk pattern of “account theft followed by bulk inventory tampering”. Therefore, the system preliminarily determines that the current operation of the user is a potential threat event and marks it as a suspected risk segment.

[0039] It should be noted that in order to more accurately quantify and evaluate the potential threat, the system does not stop at qualitative pattern matching, but generates a specific score. In an implementation manner, the system performs weighted calculation according to the severity of deviation of each real-time behavior feature from the regular, combined with the preset weight values for different features, and finally obtains a comprehensive threat possibility score.

[0040] For example, assume that the system has the following scoring criteria for each behavior feature (100 points in total): the operation time is at 3 a.m., scoring 90 points; the operation frequency is 20 times per minute, scoring 80 points; the access path is abnormal, scoring 85 points. At the same time, the system sets different weights for these features, for example: the operation time weight is 0.4, the operation frequency weight is 0.3, and the access path weight is 0.3. Then, the final threat possibility score is: (90 x 0.4) + (80 x 0.3) + (85 x 0.3) = 85.5. This 85.5 points is the final threat possibility score of this abnormal operation, which will be used to trigger the subsequent data authenticity verification process.

[0041] In step S14, the relevant inventory data records are extracted for the data whose threat possibility score exceeds the preset score threshold, to form a to-be-verified data set, including: If the threat possibility score exceeds the preset threat score threshold, the relevant inventory data records are obtained from the cloud storage library to form a preliminary extracted data record set; The content consistency of the inventory data records and the historical records is compared, and the data items with inconsistent content are marked to obtain abnormal marked data; The abnormal marked data is formatted to form a standardized to-be-verified data set.

[0042] In an implementation manner, this step is an escalation link of risk response, and is triggered only when the threat evaluated in S13 reaches a certain level. A triggering mechanism is pre-established in the system, which continuously compares the threat possibility score generated in S13 with a preset threat score threshold. If the score exceeds the threshold, it indicates that the risk of this user behavior is high, and the system automatically starts the data authenticity verification process.

[0043] For example, assume that the system presets a threat score threshold of 70 points. If the threat possibility score calculated in S13 for a certain operation is 85 points, since 85 points exceeds the threshold of 70 points, the system will immediately filter and extract the inventory data records directly related to this abnormal operation from the cloud storage library. For example, the system can extract all the warehousing, warehousing and inventory records of the goods involved in the operation in the past month to form a preliminary extracted data record set.

[0044] After obtaining the preliminary extracted data record set, the system starts the content consistency comparison. In an implementation manner, the system checks the content of each inventory record in the data set with the historical records in the system or the backup records from other trusted data sources. The purpose of this step is to find the deviations or contradictions in the data content, and mark these inconsistent data items.

[0045] Exemplarily, it is assumed that one piece of inventory record to be checked shows that the quantity of goods A received on a certain day is 100. Upon checking, it is found from the historical archive log or the record of the financial system that the quantity of the same batch received should be 90. The system will then mark the quantity field in this record as inconsistent in content, thereby generating exception marking data.

[0046] It is worth noting that, in order to ensure the accuracy of subsequent tampering analysis, the data needs to be standardized before the final analysis. In one implementation, the system will format and standardize the exception data marked in the previous step.

[0047] The standardization process includes format unification to ensure that the format of all data items is consistent. For example, the date format in the data record may exist in different forms such as "2023-10-01" and "01 / 10 / 2023", which will be unified into a standard format such as "2023-10-01"; and integrity check to check whether the required fields in the record are missing. For example, an inventory record must contain the product number and operation time field. If the system finds that a record is missing the operation time, the record will be determined to be incomplete and needs to be supplemented or temporarily excluded to ensure that the entire data set meets the prerequisite conditions for integrity detection.

[0048] Through the above comparison and processing flow, a standardized data set to be checked is finally obtained, which is preliminarily checked, uniformly formatted, and structurally complete.

[0049] In step S15, the field content of the data set to be checked is compared with the time sequence piece by piece, and data tampering signs are analyzed to obtain a tampering possibility level, including: The field content record in the data set to be checked is checked piece by piece to identify the content deviation of the field; The time stamp of the inventory data record is continuously detected to identify the anomaly of the time sequence; The content deviation and the anomaly of the time sequence are associated and matched to obtain a comprehensive exception data set; According to the preset tampering risk evaluation rule, the comprehensive exception data set is evaluated to determine the tampering possibility level.

[0050] In one implementation, the embodiment performs a deep integrity and consistency detection on the data set to be checked obtained in S14, and the core is to find possible tampering evidence from the data record itself. This detection mainly expands from two dimensions of content and time. First, the system checks the field content of each record in the data set piece by piece.

[0051] For example, when checking the content of the field, assume that a record to be checked shows that the inventory quantity of a certain product is 200 pieces. The system will compare it with the reference data stored in the historical archive or another associated database. If the reference data shows that the inventory quantity of the product should be 180 pieces, the system will identify and mark the difference of 20 pieces as a content deviation.

[0052] It should be noted that the continuity of the timestamp of the inventory data record is detected, and a time sequence anomaly is identified. In an implementation manner, the system checks whether the timestamps of all records in the data group to be checked are arranged in the expected logical order in sequence.

[0053] For example, assume that the timestamps of a group of inventory records should be in sequence in seconds or minutes. If it is found that the timestamp of the record jumps directly from 2023-10-01 10:00:00 to 2023-10-01 10:05:00, and 4 minutes and 59 seconds of records are missing in between, the system will mark this time discontinuity as a time sequence anomaly, which may mean that data is deleted or hidden.

[0054] It should be noted that an isolated content deviation or a time anomaly may be caused by an ordinary operation error, but when both are associated on the same data object, it is likely to be a sign of malicious tampering. Therefore, after identifying the above two types of anomalies, the system will associate and match the identified content deviation and time sequence anomaly. For example, if the system finds that there are content deviations in the inventory quantity of 3 records in the time discontinuity period mentioned above, the system will associate these records to form a comprehensive abnormal data set containing both time and content anomalies.

[0055] It should be noted that the ultimate goal of the embodiment is to output a qualitative tampering possibility level. In an implementation manner, the system inputs the comprehensive abnormal data set into a preset tampering risk assessment rule library for evaluation. The tampering risk assessment rule library contains a series of judgment logic.

[0056] For example, the evaluation rule can be defined as follows: If the comprehensive abnormal data set only contains an isolated content deviation, the tampering possibility level is low.

[0057] If the set contains a time sequence anomaly, or multiple records have content deviations, the tampering possibility level is medium.

[0058] If the records in the set have both content deviations and time sequence anomalies, the tampering possibility level is high.

[0059] By inputting the rule library for evaluation, the system finally determines the tampering possibility level faced by the current data.

[0060] In step S16, the tampering possibility level is input into a preset risk processing rule library, a security control strategy is generated and executed, including: According to the tampering possibility level, a corresponding risk processing rule is matched from the risk processing rule library to generate a security control strategy; According to the security control strategy, the access permission associated with the inventory data record is adjusted, and an execution confirmation identifier is generated; The record with the adjusted permission is subjected to integrity verification, and a verification result is determined; The verification result and the execution confirmation identifier are stored in a cloud log library, and platform security control is completed.

[0061] In an implementation manner, the system first inputs the tampering possibility level (for example, high, medium, and low) as input, and matches in a preset risk processing rule library. It should be noted that the risk processing rule library is a pre-configured knowledge base, which stores standardized security control strategies for different risk levels.

[0062] Exemplarily, the rules in the rule library can be defined as follows: If the tampering possibility level is high, a security control strategy of "immediately freezing the write permission of the batch data, and generating a high-priority alarm notification to the security administrator" is matched and generated.

[0063] If the tampering possibility level is medium, a security control strategy of "marking the related record as a to-be-verified state, and improving the access permission level, and limiting the modification permission of ordinary users" is matched and generated.

[0064] If the tampering possibility level is low, a security control strategy of "only recording the event in the log for subsequent manual audit" is matched and generated.

[0065] In an implementation manner, after obtaining the security control strategy, the system automatically calls the permission management interface of the platform to execute the strategy. This usually involves dynamically adjusting the access permission associated with the identified high-risk inventory data record. After execution is completed, the system generates a unique execution confirmation identifier for this operation, such as a string containing a timestamp and an event ID, to prove that the control measure has been executed.

[0066] Exemplarily, if the matched strategy is "marking the related record as a to-be-verified state, and improving the access permission level, and limiting the modification permission of ordinary users", the system will improve the permission level of the target record set from the preset 3 levels or below to 4 levels, and strictly limit the access of unauthorized users.

[0067] It is to be noted that, in order to ensure the accuracy and integrity of the execution of the security control measures, the system will also perform a final integrity check on the records being operated after adjusting the permissions. In an implementation, the system will check the records whose permissions are being adjusted, for example, confirm whether their key fields are still complete, whether the data format is correct, and generate a final check result, for example, "verification passed" or "verification failed: field missing".

[0068] It is worth noting that the last step of the embodiment is to archive the entire event handling process, complete the risk closed-loop processing and provide traceable audit basis. In an implementation, the system will transmit and store the check results generated in the foregoing steps together with the execution confirmation identifier into a secure, usually read-only cloud log library. This archiving operation ensures that every link from risk identification to final disposal is traceable, completing the complete closed loop of platform security control.

[0069] In order to facilitate the understanding of the present application, some preferred embodiments of the present application will be further described below.

[0070] In an implementation, the method of the present application can be applied to a complete, closed-loop cloud inventory platform security event response scenario. Taking the inventory management module in the cloud ERP system of an enterprise as an example, its workflow is as follows: Step one: event triggering, at 2 a.m., the system normally collects a series of operation logs of user "User_A".

[0071] Step two: abnormality identification, the system finds in the analysis that the operation track of "User_A" is "logging in and directly accessing the inventory modification interface of key material 'M-007' through URL", which does not conform to the standard operation path of "entering through search or list page" in the behavior benchmark template, and is therefore identified as abnormal operation.

[0072] Step three: threat assessment, the system extracts the features of the behavior (operation time: late at night; access path: abnormal), and matches them with the historical risk pattern library, and finds that they are highly similar to the pattern of "internal personnel malicious tampering". After weighted calculation by the system, the threat possibility score is 88.

[0073] Step four: data verification, since 88 exceeds the preset threshold of 70, the system extracts all inventory change records of material "M-007" in the past 24 hours from the cloud storage library to form a data set to be verified.

[0074] Step five: tampering analysis, the system found that one of the records shows that the inventory was modified from 500 to 50, but the system's cross-validation log shows that the reasonable change of this operation should be 450, and it is determined that there is a content deviation; at the same time, it is found that there are 2 minutes of log blank before and after the record, and it is determined that there is a time sequence anomaly. After comprehensive analysis, the system determines that the tampering possibility level of this event is high.

[0075] Step six: closed-loop treatment, according to the high tampering possibility level, the system matches the "immediately freeze the write permission of the batch data, and generate a high priority alarm notification to the security administrator" strategy from the risk treatment rule library. The system automatically executes the strategy, temporarily prohibits any modification operation on the inventory record of material "M-007", and sends an alarm email to the security administrator. The execution identifier and verification result of all operations are stored in the cloud log library, and the closed-loop treatment is completed.

[0076] In another implementation, the communication and data transmission between the various modules in the system, such as the data acquisition module, the anomaly identification module, the risk response module, etc., can be realized through different network architectures. In one embodiment, the modules are deployed in the same virtual private cloud (VPC) and communicate through an internal high-speed wired network. This approach has low latency and high bandwidth, ensuring the highest processing efficiency and stability. In another embodiment, the system can use a microservice-based distributed architecture, with each module deployed as an independent service and communicating asynchronously through an API gateway or a message queue such as RabbitMQ or Kafka. This approach provides greater flexibility and scalability, making it easier to maintain and upgrade the system, especially in complex, multi-tenant cloud platform environments.

[0077] In summary, the present application discloses a security control method for a cloud-based inventory management platform, which includes obtaining a set of cloud interaction data; identifying abnormal operation behaviors in the set of cloud interaction data using a pre-set behavior benchmark template to obtain a set of abnormal operations; matching and calculating real-time behavior characteristics in the set of abnormal operations with pre-set historical risk patterns to determine potential threats and generate a threat possibility score; extracting relevant inventory data records for data whose threat possibility score exceeds a pre-set score threshold to form a set of data to be checked; comparing the field content and time sequence of the set of data to be checked piece by piece to analyze data tampering signs and obtain a tampering possibility level; and inputting the tampering possibility level into a pre-set risk treatment rule library to generate and execute a security control strategy. The present application builds a full-process security mechanism from user behavior monitoring, data authenticity verification to automated risk closed-loop treatment, solves the problem of fixed security strategies in the prior art that make it difficult to dynamically identify and respond to data tampering risks, and improves the security and data reliability of the cloud-based inventory management platform.

[0078] Referring to Figure 2 The second embodiment of the present application provides a security control system of a cloud inventory management platform, comprising: A data acquisition module configured to acquire a cloud interaction dataset; An anomaly identification module configured to identify abnormal operation behaviors of the cloud interaction dataset using a preset behavior benchmark template to obtain an abnormal operation set; A threat assessment module configured to match and calculate real-time behavior features in the abnormal operation set with a preset historical risk pattern to determine potential threats and generate a threat possibility score; A data extraction module configured to extract relevant inventory data records of data whose threat possibility score exceeds a preset score threshold to form a to-be-checked data group; A tampering analysis module configured to compare field contents and time sequences of the to-be-checked data group one by one to analyze data tampering signs and obtain a tampering possibility level; A risk response and closed-loop processing module configured to input the tampering possibility level into a preset risk processing rule library to generate and execute a security control strategy.

[0079] It should be noted that the security control system of the cloud inventory management platform provided by the embodiments of the present application is used to execute all process steps of the security control method of the cloud inventory management platform of the above-mentioned embodiments, and the working principles and beneficial effects of the two are one-to-one correspondence, thus not being repeated.

[0080] The embodiments of the present application also provide an electronic device. The electronic device comprises a processor, a memory, and a computer program stored in the memory and executable on the processor, such as a security control program of a cloud inventory management platform. The processor executes the computer program to implement the steps in each of the above-mentioned cloud inventory management platform security control method embodiments, such as Figure 1 the step S11 shown. Alternatively, the processor executes the computer program to implement the functions of each module / unit in each of the above-mentioned device embodiments, such as a data acquisition module.

[0081] For example, the computer program can be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete the present application. The one or more modules / units can be a series of computer program instruction segments capable of completing a specific function, which are used to describe the execution process of the computer program in the electronic device.

[0082] The electronic device can be a computing device such as a desktop computer, a notebook computer, a palm computer, a smart tablet, etc. The electronic device can include, but is not limited to, a processor, a memory. Those skilled in the art can understand that the above components are only examples of the electronic device and do not constitute a limitation on the electronic device, and the electronic device can include more or fewer components than the above, or combine certain components, or different components, for example, the electronic device can also include an input / output device, a network access device, a bus, etc.

[0083] The processor can be a central processing unit (CPU), and can also be other general-purpose processors, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The processor is the control center of the electronic device, and connects various parts of the electronic device through various interfaces and lines.

[0084] The memory can be used to store the computer program and / or modules, and the processor realizes various functions of the electronic device by running or executing the computer program and / or modules stored in the memory, and calling data stored in the memory. The memory can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, at least one application required by a function (such as a sound playing function, an image playing function, etc.), etc.; the data storage area can store data created according to the use of the mobile phone (such as audio data, a phone book, etc.), etc. In addition, the memory can include a high-speed random access memory, and can also include a non-volatile memory, for example, a hard disk, a memory, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, at least one disk storage device, a flash memory device, or other volatile solid-state memory device.

[0085] If the module / unit integrated into the electronic device is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present invention can implement all or part of the process steps in the above-mentioned method embodiments by using a computer program to instruct the relevant hardware. The computer program can be stored in a computer-readable storage medium. When executed by a processor, the computer program can implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal, and software distribution medium. It should be noted that the content of the computer-readable medium can be appropriately increased or decreased based on the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, based on legislation and patent practice, computer-readable media does not include electric carrier signals and telecommunication signals.

[0086] It should be noted that the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed across multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment. In addition, in the drawings of the device embodiments provided by the present invention, the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines. A person of ordinary skill in the art can understand and implement the present invention without inventive effort.

[0087] The specific embodiments described above further illustrate the objectives, technical solutions, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A security control method for a cloud inventory management platform, characterized in that: include: Obtain cloud interaction dataset; For the cloud interaction dataset, using a preset behavior benchmark template to identify abnormal operation behaviors to obtain an abnormal operation set; Matching and calculating the real-time behavioral features in the abnormal operation set with preset historical risk patterns to determine potential threats and generate a threat likelihood score; Extracting relevant inventory data records for data whose threat likelihood scores exceed a preset score threshold to form a data group to be verified; Comparing the field contents of the data group to be verified with the time series one by one, analyzing the signs of data tampering, and obtaining a tampering possibility level; The tampering possibility level is input into a preset risk processing rule library to generate and execute a security control strategy.

2. The security control method of the cloud inventory management platform according to claim 1 is characterized in that: The obtaining of the cloud interaction dataset includes: Acquire multi-source log information in real time to generate an initial interaction dataset; the initial interaction dataset includes user operation trajectory data and background response record data; According to the initial interaction dataset, the user operation trajectory data and the background response record data are matched item by item and time-series associated to obtain the cloud interaction dataset.

3. The security control method of the cloud inventory management platform according to claim 2 is characterized in that: The cloud interaction dataset is subjected to abnormal operation behavior identification using a preset behavior benchmark template to obtain an abnormal operation set, including: Based on the cloud interaction dataset, the user operation trajectory data is compared item by item using a preset behavior benchmark template to identify behavioral segments that deviate from the norm and obtain a preliminarily screened abnormal operation set; Performing a time series comparison of the operation frequencies of the behavior segments in the initially screened abnormal operation set with a preset operation frequency threshold, and marking the behavior segments exceeding the operation frequency threshold as high-risk behavior segments; The high-risk behavior segments are layered to obtain segments related to risk mining, and are summarized to obtain the abnormal operation set.

4. The security control method of the cloud inventory management platform according to claim 1, characterized in that: The matching and calculation of the real-time behavior features in the abnormal operation set with the preset historical risk patterns to determine potential threats and generate a threat likelihood score includes: Extracting real-time behavior features of the current user operation from the abnormal operation set; the real-time behavior features include operation time, operation frequency and access path; Retrieving historical risk patterns that match the real-time behavior characteristics from a pre-built historical risk pattern library to determine potential threats; A weighted calculation is performed based on the real-time behavior characteristics in combination with a preset weight value to obtain the threat possibility score.

5. The security control method of the cloud inventory management platform according to claim 1 is characterized in that: The extracting of relevant inventory data records for the data whose threat likelihood score exceeds a preset score threshold to form a data group to be verified includes: If the threat likelihood score exceeds a preset threat score threshold, obtaining relevant inventory data records from a cloud repository to form a preliminary extracted data record group; Comparing the inventory data records with historical records for content consistency, marking data items with inconsistent content, and obtaining abnormal marking data; The abnormality mark data is formatted to form a standardized data group to be verified.

6. The security control method of the cloud inventory management platform according to claim 1, characterized in that: The process of comparing the field contents of the data group to be verified with the time series one by one, analyzing the signs of data tampering, and obtaining the tampering possibility level includes: Checking each field content record in the data group to be checked one by one to identify any deviations in the field content; Performing continuity checks on the timestamps of the inventory data records to identify anomalies in the time series; Correlating and matching the content deviation with the anomaly of the time series to obtain a comprehensive anomaly data set; The comprehensive abnormal data set is evaluated according to preset tampering risk assessment rules to determine the tampering possibility level.

7. The security control method of the cloud inventory management platform according to claim 1, characterized in that: The step of inputting the tampering possibility level into a preset risk processing rule library to generate and execute a security control strategy includes: According to the tampering possibility level, matching corresponding risk processing rules from the risk processing rule library to generate a security control policy; adjusting access rights associated with the inventory data record according to the security control policy and generating an execution confirmation identifier; Performing an integrity check on the record of the adjusted permissions and determining a check result; The verification result and the execution confirmation mark are stored in the cloud log library to complete the platform security control.

8. A security control system for a cloud inventory management platform, characterized in that: include: Data acquisition module, used to obtain cloud interaction data sets; An anomaly identification module is used to identify abnormal operation behaviors on the cloud interaction dataset using a preset behavior benchmark template to obtain an abnormal operation set; A threat assessment module is used to match and calculate the real-time behavioral characteristics in the abnormal operation set with preset historical risk patterns, determine potential threats, and generate a threat likelihood score; A data extraction module is used to extract relevant inventory data records for the data whose threat likelihood score exceeds a preset score threshold to form a data group to be verified; a tampering analysis module, configured to compare the field contents of the data group to be verified with the time series one by one, analyze the signs of data tampering, and obtain a tampering possibility level; The risk response and closed-loop processing module is used to input the tampering possibility level into a preset risk processing rule library to generate and execute a security control strategy.

9. An electronic device, characterized in that: The method comprises a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein when the processor executes the computer program, the security control method for the cloud inventory management platform according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute the security control method for the cloud inventory management platform according to any one of claims 1 to 7.

Images