Method, system and related device for access control of vehicle repair data
By combining geofencing and device behavior analysis into a risk control system, the problem of misjudgment in vehicle maintenance data access control has been solved, enabling accurate identification and protection against malicious crawler behavior, and ensuring data security and smooth business operations.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- LAUNCH SOFTWARE DEV
- Filing Date
- 2026-03-05
- Publication Date
- 2026-06-16
AI Technical Summary
Existing vehicle maintenance data access control methods have a high false positive rate when identifying abnormal behavior, which affects normal maintenance operations, and lack accurate methods for identifying abnormal behavior.
By combining client network access location with geofencing, the system analyzes changes in device location, vehicle access frequency and time intervals, and constructs a risk control system that integrates geofencing, device behavior analysis, and human-machine collaborative review to achieve precise control over vehicle maintenance data access requests.
Effectively identify malicious web crawler behavior, reduce the risk of mistakenly harming legitimate users, protect vehicle maintenance data security, and ensure the smooth operation of normal maintenance business.
Smart Images
Figure CN122226344A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing technology, and in particular to methods, systems and related equipment for access control of vehicle maintenance data. Background Technology
[0002] In the vehicle repair service industry, repair shops or technicians need to access vehicle repair data (such as fault codes, repair history, parts information, etc.) on servers via client devices. However, this data has commercial value and is easily targeted for data theft by web crawlers or malicious programs.
[0003] Currently, common access control methods often rely on single dimensions such as access frequency or Internet Protocol (IP) address blacklists for restrictions. For example, if the number of requests made by a device exceeds a threshold within a given time period, it is considered abnormal and blocked. However, in real-world repair scenarios, technicians may need to intensively query repair data for multiple vehicles for fault diagnosis or spare parts preparation. Their access behavior may resemble that of web crawlers in frequency, leading to a high false positive rate in existing frequency-based control strategies and interfering with normal repair operations.
[0004] Therefore, existing technologies lack a method to accurately identify abnormal behavior in vehicle maintenance data access scenarios, so as to ensure data security while avoiding impact on normal maintenance operations. Summary of the Invention
[0005] This application provides a method, system, and related equipment for access control of vehicle maintenance data, relating to the field of data processing technology. The method determines anomalies by comparing the client's network access location with a preset geographic geofence, and further combines this with analysis of behavioral patterns such as device location changes, vehicle access frequency, and time intervals to implement corresponding restriction policies on vehicle maintenance data access requests. The specific technical solution is as follows: Firstly, a method for access control of vehicle maintenance data is provided, comprising: receiving an access request from a client, the access request including at least a device identifier, a vehicle identifier, and the client's network access location information; comparing the network access location information with pre-stored geofencing information; if the network access location information is located within the area defined by the geofencing information, determining the access request as an abnormal access request; based on the historical access records of the device identifier, obtaining the number of different network access location information from the same client within a first preset time period; if the number of locations exceeds a first threshold, determining the access request as an abnormal access request; determining whether the access request is an abnormal access request based on the access frequency and interval of the vehicle identifier; and executing corresponding access restriction policies on clients determined to have abnormal access requests.
[0006] In conjunction with the first aspect, the determination of whether an access request is an abnormal access request is based on the access frequency and interval of the vehicle identifier. Specifically, this includes: counting the number of times the device identifier accesses the vehicle identifier within a second preset time period; obtaining the access time interval between the vehicle identifier accessed in the current access and the different vehicle identifier accessed in the previous access based on the historical access records of the device identifier; if the number of accesses exceeds the second threshold, or the access time interval is less than the third threshold, the access request is determined to be an abnormal access request.
[0007] In conjunction with the first aspect, in some embodiments of the first aspect, the number of times a device identifier accesses a vehicle identifier within a second preset time period is counted, specifically including: deduplicating access requests from the device identifier to the same vehicle identifier repeatedly within the second preset time period.
[0008] In conjunction with the first aspect, in some embodiments of the first aspect, the method further includes: counting at least two network access location information accessed by the vehicle identifier within a third preset time period; if the at least two network access location information are different, then the access request is determined to be an abnormal access request.
[0009] In conjunction with the first aspect, in some implementations of the first aspect, a corresponding access restriction policy is executed on the client that is determined to be an abnormal access request, specifically including: blocking the current access request and prohibiting access requests initiated by the device identifier within a fourth preset time period.
[0010] In conjunction with the first aspect, in some implementations of the first aspect, the access restriction policy includes adding the device identifier to a temporary restricted list. After executing the corresponding access restriction policy on the client with the abnormal access request, the method further includes: reviewing the device identifier added to the temporary restricted list through a manual review channel; and after confirming that the client corresponding to the device identifier has performed normal maintenance operations, lifting the access restriction policy on the device identifier.
[0011] In conjunction with the first aspect, in some implementations of the first aspect, removing the access restriction policy on the device identifier specifically includes: removing the device identifier from the temporary restricted list and resetting at least one risk counter associated with the device identifier for determining abnormal access requests.
[0012] It should be noted that, in the absence of conflict, the features in the various embodiments of the first aspect can be combined with each other, and any combination of features in different embodiments is also within the protection scope of this application. That is to say, the various embodiments described above can also be arbitrarily combined according to actual needs.
[0013] Secondly, a vehicle maintenance data access control system is provided, including: The request receiving module is used to receive access requests from clients. The access request includes at least the device identifier, vehicle identifier, and the client's network access location information. The location information processing module, connected to the request receiving module, is used to compare the network access location information with the pre-stored geofence information. If the network access location information is within the area defined by the geofence information, the access request is determined to be an abnormal access request. The location information processing module is also used to obtain the number of different network access location information of the client within a first preset time period based on the historical access records of the device identifier. If the number of locations exceeds a first threshold, the access request is determined to be an abnormal access request. The behavior analysis module, connected to the request receiving module, determines whether an access request is an abnormal access request based on the frequency and interval of access to the vehicle identifier. The policy execution module, connected to the location information processing module and the behavior analysis module, is used to execute corresponding access restriction policies on clients with abnormal access requests.
[0014] Thirdly, a computer device is provided, including one or more memories and one or more processors; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the computer device to implement the method as described in the first aspect or any of the embodiments of the first aspect.
[0015] Fourthly, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the method as described in the first aspect or any of the embodiments in the first aspect.
[0016] In this embodiment, the method provided in this application constructs a comprehensive risk control system including geofencing, device behavior analysis, and human-machine collaborative review to achieve real-time identification and precise crackdown on malicious crawling of vehicle maintenance data. Its core advantage lies in combining risk control dimensions with the client's geographical location and device behavior for correlation analysis, thereby effectively distinguishing between high-intensity normal maintenance and malicious data crawling. This enhances the protection of vehicle maintenance data assets while reducing the risk of mistakenly harming legitimate users. Furthermore, the manual review mechanism introduced by the system enhances the fairness and self-recovery capabilities of risk control, ensuring the smooth operation of normal vehicle maintenance business under strict security control. Attached Figure Description
[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is a diagram of a communication system for access control of vehicle maintenance data provided in an embodiment of this application; Figure 2 This is a system framework diagram of access control for vehicle maintenance data provided in an embodiment of this application; Figure 3 This is a flowchart illustrating an access control method for vehicle maintenance data provided in an embodiment of this application; Figure 4 This is a schematic flowchart of a method for access control combined with vehicle identification provided in an embodiment of this application; Figure 5 This is a schematic diagram of a module of a vehicle maintenance data access control system provided in an embodiment of this application; Figure 6 This is a schematic diagram of the hardware structure of a computer device provided in an embodiment of this application; Figure 7 This is a schematic diagram of a computer-readable storage medium provided in an embodiment of this application. Detailed Implementation
[0019] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.
[0020] It should be understood that "multiple" as mentioned in this application refers to two or more. In the description of this application, unless otherwise stated, " / " indicates "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, to facilitate a clear description of the technical solutions of this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.
[0021] The terms "one embodiment" or "some embodiments" used in this application mean that one or more embodiments of this application include the specific features, structures, or characteristics described in that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this application do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. Furthermore, the terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.
[0022] The following describes the vehicle feature-based information query method, system, and related equipment provided in this application through three embodiments. Embodiment 1 describes the system framework of the vehicle feature-based information query method, Embodiment 2 describes the method flow for implementing the vehicle feature-based information query, and Embodiment 3 describes the module structure, computer equipment hardware structure, and computer-readable storage medium for executing the vehicle feature-based information query method.
[0023] Example 1: Figure 1 This is a diagram of a communication system for access control of vehicle maintenance data provided in an embodiment of this application. Figure 1 As shown, the communication system mainly includes a client device 100 and a server 200, which communicate through a network to achieve access control of vehicle maintenance data.
[0024] In this embodiment, the client device 100 runs a corresponding application or software module to generate an access request and send it to the server 200. The access request encapsulates information including, but not limited to, the following: a device identifier that can uniquely identify the client device 100 (e.g., the Media Access Control Address (MAC) address, serial number, or authorized account assigned by the software to the client device 100), the current network access location information of the client device 100 (e.g., the IP address and corresponding geographical coordinates transmitted by the client device 100 to the server 200 via a Wireless Fidelity connection), and the target vehicle identifier (e.g., the Vehicle Identification Number (VIN)) corresponding to the maintenance data that the request seeks to obtain.
[0025] In this embodiment of the application, the client device 100 is the terminal that initiates the data access request, and may include, but is not limited to: a dedicated diagnostic computer set up in the repair shop, a mobile diagnostic instrument held by a technician, a personal computer with specific repair software installed, and a smart mobile terminal, etc.
[0026] In this embodiment, server 200 is a data and business processing center deployed behind the data provider (such as a vehicle manufacturer, a large parts supplier, or a third-party data platform). Server 200 has a built-in control unit that executes various access control methods provided in this application, used to receive and process access requests from client device 100. This control unit can execute access control methods for vehicle maintenance data, including geofencing comparison, device behavior analysis, and business operation mode detection, based on the device identifier, network access location information, and vehicle identifier in the access request.
[0027] In this embodiment of the application, server 200 can be a standalone physical server, a cluster of multiple servers, or a virtual server resource based on a cloud computing platform.
[0028] In this embodiment, the network connecting the client device 100 and the server 200 can be the public internet, a dedicated enterprise wide area network, or a virtual private network (VPN). To ensure the security and reliability of data transmission, the communication link can use transmission protocols such as Hypertext Transfer Protocol Secure (HTTPS) or Virtual Private Network (VPN). The data flow primarily involves the client device 100 sending an access request containing the aforementioned information to the server 200. After processing the request according to the risk control policy, the server 200 returns the corresponding vehicle maintenance data or relevant control instructions (such as allow, restrict, or deny instructions) to the client device 100.
[0029] In the embodiments of this application, Figure 1 The communication system described herein uses the communication between a client device 100 and a server 200 as an example. In practical applications, the communication system can have more or fewer devices. For example, the number of client devices 100 and servers 200 can be even greater, and one server 200 can communicate with multiple client devices 100 simultaneously. This application embodiment does not limit the specific types of devices included in the communication system. In the following description, the vehicle maintenance data access control method involved in this application embodiment can be applied to... Figure 1 The communication system shown.
[0030] Figure 2This is a system framework diagram of access control for vehicle maintenance data provided in an embodiment of this application, applied to, for example... Figure 1 The communication system shown. (As shown) Figure 2 As shown, the system framework can be applied to server 200, including request receiving unit 210, location information processing unit 220, behavior analysis unit 230, policy execution unit 240 and manual review unit 250.
[0031] In this embodiment, the request receiving unit 210 is responsible for detecting, receiving, and parsing access requests from the client device 100 within the system framework. The key parameters extracted by the request receiving unit 210 include at least the device identifier, vehicle identifier, and the client's network access location information; based on the request content, it also extracts the vehicle identifier. This structured data is then distributed to subsequent units.
[0032] In this embodiment, the location information processing unit 220 and the behavior analysis unit 230 are the core components of the system framework for implementing various access control methods, specifically including: The location information processing unit 220 receives network access location information and compares it with a pre-stored geofence information database. If the network access location information indicates that the client device 100 is located within a preset sensitive or high-risk fence area, a high-risk signal can be generated to determine that the access request is an abnormal access request.
[0033] In this embodiment of the application, the location information processing unit 220 can also count the number of different network access locations used by the client device 100 in the first preset time period (e.g., the past month) (e.g., the IP addresses sent by the two client devices 100 to the server 200, indicating two network access locations). If the number of locations exceeds the first threshold (e.g., 3), an abnormal behavior signal of the client device 100 is generated, and the access request can be determined to be an abnormal access request.
[0034] The behavior analysis unit 230 determines whether an access request is abnormal based on the frequency and interval of access to the vehicle identifier. Specifically, the behavior analysis unit 230 queries the historical access record database to analyze the long-term behavior patterns of the client device 100.
[0035] In this embodiment, the behavior analysis unit 230 can be activated when the access request contains a vehicle identifier. The behavior analysis unit 230 performs analysis based on business logic: First, it counts the number of different vehicle identifiers accessed by the client device 100 within a second preset time period (e.g., the past day) (using deduplication counting); second, it calculates the access time interval between the vehicle identifier requested in this request and the previously accessed different vehicle identifiers. If the number of accesses (i.e., the number of vehicles) exceeds a preset second threshold (e.g., 5) or the time interval is less than a third threshold (e.g., 30 minutes), a business operation anomaly signal is generated for the client device 100, indicating that the access request is an abnormal access request.
[0036] In this embodiment of the application, the behavior analysis unit 230 can also count at least two network access location information accessed within a third preset time period (e.g., 30 minutes) for the same vehicle identifier. If the at least two network access location information are different, indicating that the client device 100 has different locations, an abnormal service operation signal of the client device 100 is generated, and the access request can be determined to be an abnormal access request.
[0037] In this embodiment, the policy execution unit 240 aggregates the output signals of the location information processing unit 220 and the behavior analysis unit 230, and determines the final access control decision based on pre-configured comprehensive judgment rules. Specifically, for access requests deemed abnormal, the policy execution unit 240 executes corresponding access restriction policies, such as immediately blocking the current request and adding the device identifier of the client device 100 to a temporary restricted list, prohibiting it from initiating new requests for a period of time.
[0038] In this embodiment, the manual review unit 250 is an optional unit used to provide a manual review channel interface for appealing and reviewing client devices 100 on the temporary restricted list. If a manual review confirms a misjudgment, the manual review unit 250 can instruct the policy execution unit 240 to lift the restriction. Specifically, this includes removing the device identifier of the client device 100 from the list and resetting its associated risk counter (such as the counter in the behavior analysis unit 230 used to count the number of times the client device 100 accesses different vehicle identifiers), thus managing access control.
[0039] It is understood that the functional division between units in the system framework illustrated in the embodiments of this application is merely illustrative and does not constitute a functional limitation on the system framework. In other embodiments of this application, the system framework may also employ different units or combinations of multiple units to implement the functions within the system framework.
[0040] Example 2: Figure 3This is a flowchart illustrating an access control method for vehicle maintenance data provided in an embodiment of this application, applicable to, for example... Figure 1 The communication system shown and such Figure 2 The system framework shown includes the following steps.
[0041] S101. Receive and parse the access request.
[0042] In this embodiment of the application, server 200 receives an access request from client device 100. Corresponding to Figure 2 The request receiving unit 210 in the middle performs the action, and the server 200 parses the access request and extracts key parameters including at least: device identifier, network access location information (such as IP address) and vehicle identifier.
[0043] S102. Comparison of geolocation fence information.
[0044] In the embodiments of this application, corresponding to Figure 2 In the location information processing unit 220, the server 200 compares the network access location information parsed in step S101 with one or more pre-stored geographic location fences in the system. These geographic location fences define a specific geographic area (e.g., a known high-incidence area of abnormal activity). If the network access location information is located within any of the set geographic location fences, the current access request is directly determined to be an abnormal access request.
[0045] S103. Based on device location analysis.
[0046] In this embodiment, if step S102 does not trigger an anomaly, this step can be performed by the location information processing unit 220. The server 200 queries the historical access records based on the device identifier and counts the number of different network access locations used by the client device 100 within a first preset time period (e.g., the past 24 hours). If the number of locations exceeds a first threshold, the access request is determined to be an abnormal access request. Thus, step S103 is used to identify abnormally high-frequency switching behavior exhibited by the client device 100 at network access locations, and to analyze and determine whether the client device 100 is using virtual positioning or a proxy.
[0047] S104. Business operation analysis based on vehicle identification.
[0048] In this embodiment of the application, if the aforementioned steps do not trigger an exception, these steps are executed in parallel or sequentially, corresponding to Figure 2 The behavior analysis unit 230, step S104 includes the following steps: 1. Count the number of visits to different vehicles (i.e., the access frequency of vehicle identifiers). Based on the obtained device identifier, query the historical records of client device 100 within a second preset time period (e.g., 1 month) and count the number of visits to different vehicle identifiers (wherein, duplicate visits to the same vehicle are deduplicated).
[0049] 2. Obtain the cross-vehicle access time interval (i.e., the access interval of the vehicle identifier). From the historical records of client device 100, obtain the access time interval between the vehicle identifier of the current request and the different vehicle identifier accessed in the previous request. If the number of accesses exceeds the second threshold (e.g., 5), or the access time interval is less than the third threshold (e.g., 30 minutes), it is determined to be an abnormal access request.
[0050] 3. Analyze at least two network access location information entries accessed by the same vehicle identifier within a third preset time period (e.g., 30 minutes). If the at least two network access location information entries are different, the access request is determined to be an abnormal access request.
[0051] S105. Determine whether the access request is an abnormal access request based on comprehensive analysis.
[0052] In this embodiment, step S105 is used to summarize risk signals. Server 200 can summarize the determination results from steps S102 to S104. Specifically, if an abnormal access request is detected in any step, the current access request is ultimately determined to be an abnormal access request, and the subsequent step S106 is executed. Otherwise, the subsequent step S108 is executed.
[0053] S106. Implement access restriction policies.
[0054] In this embodiment of the application, this step corresponds to Figure 2 When the access request in step S105 is determined to be an abnormal access request, the policy execution unit 240 executes the corresponding access restriction policy. The access restriction policy includes immediately blocking the current access request and adding the device identifier of the client device 100 to a temporary restricted list to prevent it from initiating new access requests within a fourth preset time period (e.g., the past day).
[0055] S107. Manual review and status management.
[0056] In this embodiment of the application, this step corresponds to Figure 2The manual review unit 250 provides a manual review channel for client devices 100 that have been added to the temporary restricted list to appeal. If the manual review confirms that the access request of the client device 100 is a misjudgment or a normal maintenance operation, the removal operation is performed, including removing the device identifier of the client device 100 from the temporary restricted list and resetting the risk counters associated with it that are used to trigger the anomaly judgment (such as resetting the access count of different vehicle identifiers used in step S104).
[0057] S108. Execute the normal access request.
[0058] In this embodiment of the application, if the access request in step S105 is determined to be normal, the server 200 processes the access request and returns the requested vehicle maintenance data to the client device 100 to complete the vehicle maintenance data service.
[0059] Based on the method shown in steps S101-S108 above, Figure 3 The flowchart illustrates the complete logical chain from request parsing, through parallel detection of geofencing, device behavior, and business operation modes, to comprehensive judgment, execution of restriction policies, and management closed loop. These steps collectively achieve the identification and handling of abnormal access behavior from clients.
[0060] It should be understood that, as mentioned above Figure 3 The steps in the flowcharts 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 performed; they can be executed in other orders. Furthermore, as mentioned above... Figure 3 The flowchart may include at least some steps or stages. These steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the steps or stages in other steps.
[0061] Figure 4 This is a flowchart illustrating a method for access control combining vehicle identification, as provided in an embodiment of this application, applicable to, for example... Figure 1 The communication system shown and such Figure 2 The system framework shown identifies abnormal access requests (such as malicious crawling requests) through refined analysis of vehicle identifiers in access requests. It is particularly suitable for preventing automated attacks aimed at extensively collecting data from various vehicles, specifically including: S201. Obtain vehicle identification.
[0062] In this embodiment, when the server 200 receives an access request, in addition to parsing the device identifier, it also extracts the vehicle identifier (e.g., Vehicle Identification Number, VIN) carried in the request. The vehicle identifier is used for further analysis of the access request.
[0063] S202. Count the number of visits to different vehicles.
[0064] In this embodiment, server 200 queries the historical access records of a device identifier within a second preset time period (e.g., the past hour). Its core operation is to count the total number of different vehicle identifiers accessed by the device identifier within this time period and to deduplicate records of repeated accesses to the same vehicle identifier.
[0065] For example, if client device 100 accesses vehicle data with the first device identifier (e.g., the first VIN code) twice and the second device identifier (e.g., the second VIN code) three times, after deduplication, the number of accesses to different vehicles (i.e., the number of accesses) is counted as 2.
[0066] S203. Calculate the cross-vehicle access time interval.
[0067] In this embodiment, server 200 further searches the historical records of the same device identifier to find the specific times of its two most recent accesses to different vehicle identifiers. It calculates the access time interval between the vehicle identifier requested this time and the previously accessed different vehicle identifier. Thus, step S203 can measure the frequency or speed at which client device 100 switches between accessing target vehicles. An access time interval less than a third threshold (e.g., 30 minutes) may indicate that the automated script is rapidly and continuously requesting data from different vehicles.
[0068] S204. Statistical analysis of the locations of devices accessing the same vehicle.
[0069] In this embodiment of the application, the server 200, based on the vehicle identifier, counts at least two network access location information accessed by the same vehicle identifier within a third preset time period (e.g., 30 minutes), and determines whether the access request is an abnormal access request by judging whether the at least two network access location information are the same.
[0070] S205. Perform anomaly detection and strategy execution.
[0071] In this embodiment, the analysis results of steps S202-S204 are compared using a preset threshold, and the following determination logic is executed: First rule: If the number of accesses counted in step S202 (i.e., the number of different vehicles accessed within the second preset time period (e.g., the past day)) exceeds the second threshold (e.g., 5), the access request will be judged as an abnormal access request.
[0072] Second rule: If the access time interval calculated in step S203 is less than the third threshold (e.g., 30 minutes), the access request will be judged as an abnormal access request.
[0073] Second rule: If at least two network access location information are different within the third preset time period in step S204, the access request is determined to be an abnormal access request. For example, server 200 may obtain one access request from client device 100 from the first network access location information and one access request from client device 100 from the second network access location information within 5 minutes. Since these two network access location information are different, it indicates that client device 100 may not be the actual vehicle diagnostic device, and the access request from client device 100 is determined to be an abnormal access request.
[0074] In this embodiment of the application, when the anomaly determination condition meets either the first rule or the second rule, the current access request is determined to be an abnormal access request. After being determined to be abnormal, the policy execution unit 240 will immediately execute the access restriction policy, such as blocking the current request and adding the device identifier to the temporary restricted list.
[0075] In some implementations, the method can be used as Figure 3 This is an analysis step in the access control method for vehicle maintenance data. When an access request is made, a comparison based on geofencing information (such as...) is performed. Figure 3 (as shown in step S102) and Figure 4 When implementing access control based on vehicle identifiers, the system can perform weighted judgments to improve the accuracy of intercepting abnormal access requests.
[0076] In some implementations, the method can also detect coordinated attack patterns. Server 200 can analyze whether multiple different device identifiers collectively accessed the same batch or the same vehicle identifier within a specific time period, and combined with other rules, can identify organized distributed crawler attacks.
[0077] Based on the method shown in steps S201-S205 above, this application performs a comprehensive analysis of the breadth (i.e., number of visits) and density (i.e., time interval between visits) of vehicle identifiers (e.g., VIN), enabling the system to effectively identify abnormal access requests (such as crawler behavior characteristics). In this way, in complex business scenarios, it can accurately distinguish between high-intensity normal maintenance and malicious data crawling, achieving a balance between data security protection and smooth business operation.
[0078] Example 3: Figure 5 This is a schematic diagram of a module of a vehicle maintenance data access control system provided in an embodiment of this application. Figure 5 As shown, the vehicle maintenance data access control system 500 can be specifically implemented as a collection of software function modules running on the aforementioned server 200. Each module works together to achieve multi-level, three-dimensional identification and control of abnormal access risks.
[0079] Specifically, the vehicle maintenance data access control system 500 includes the following modules: The request receiving module 510 is used to receive access requests from clients. The access requests include at least the device identifier, vehicle identifier, and the client's network access location information, providing structured data input for subsequent parallel risk analysis.
[0080] The location information processing module 520, connected to the request receiving module 510, is used to compare the network access location information with the pre-stored geofence information. If the network access location information is located within the area defined by the geofence information, the access request is determined to be an abnormal access request.
[0081] The location information processing module 520 is also used to obtain the number of different network access location information of the client within a first preset time period based on the historical access records of the device identifier. If the number of locations exceeds a first threshold, the access request is determined to be an abnormal access request.
[0082] The behavior analysis module 530, connected to the request receiving module 510, determines whether an access request is an abnormal access request based on the frequency and interval of access to the vehicle identifier. Specifically, the behavior analysis module 530 is used to count the number of times the device identifier accesses the vehicle identifier within a second preset time period. Based on the historical access records of the device identifier, it obtains the access time interval between the vehicle identifier accessed in the current instance and the different vehicle identifier accessed in the previous instance. If the number of accesses exceeds a second threshold, or the access time interval is less than a third threshold, the access request is determined to be an abnormal access request.
[0083] The policy execution module 540, connected to the location information processing module and the behavior analysis module, is used to execute corresponding access restriction policies on clients with abnormal access requests.
[0084] In some implementations, the vehicle maintenance data access control system 500 may also include manual review. This module is responsible for maintaining a temporary restricted list and executing list operation instructions issued by the policy enforcement module 540. More importantly, it provides a manual review channel interface, supporting administrators to appeal and review devices on the list. After manual confirmation, the module can perform a restriction removal operation, specifically removing the device identifier from the list and resetting the risk counter associated with the device that triggers anomaly detection (e.g., resetting the access count in the behavior analysis module 530), thereby achieving closed-loop management of risk control status.
[0085] In some implementations, the vehicle maintenance data access control system 500 may also include a historical access database to provide persistent data support for the location information processing module 520 and the behavior analysis module 530, storing historical access records of each device identifier, including timestamps, network access locations, and the identifiers of the accessed vehicles.
[0086] In this embodiment, the software implementation architecture of the technical solution of this application is demonstrated through the modular presentation of the vehicle maintenance data access control system 500. The logical relationships and data flow between the functional modules in the vehicle maintenance data access control system 500 illustrate the complete vehicle maintenance data access control method from access request to final processing.
[0087] It is understood that the functional division between the modules illustrated in the embodiments of this application is merely illustrative and does not constitute a functional limitation on the vehicle maintenance data access control system 500. In other embodiments of this application, the vehicle maintenance data access control system 500 may also employ different modules or combinations of multiple modules to implement the functions of the vehicle maintenance data access control system 500.
[0088] Figure 6 This is a schematic diagram of the hardware structure of a computer device provided in an embodiment of this application. The computer device 600 may include the aforementioned... Figure 1 The server 200 shown and such Figure 2 The system framework is shown below. Figure 6 As shown, the computer device 600 includes: a processor 601, a memory 602, a communication unit 604, and a computer program 603 stored in the memory 602 and executable on the processor 601. When the processor 601 executes the computer program 603, it implements the aforementioned... Figures 3-4 The execution steps are shown. For example, the computer program 603 described above can be divided into one or more units / modules, which are stored in the memory 602 and executed by the processor 601 to complete this application.
[0089] The aforementioned one or more units / modules may be a series of computer program instruction segments capable of performing a specific function. These instruction segments describe the execution process of the aforementioned computer program 603 within the aforementioned computer device 600. For example, the aforementioned computer program 603 may be used to perform actions such as... Figure 3 The access control method for vehicle maintenance data shown in steps S101-S108 has been described in the above embodiments for its specific functions or mechanisms, and will not be repeated here.
[0090] Those skilled in the art will understand that Figure 6 This is merely an example of computer device 600 and does not constitute a limitation on computer device 600. It may include more or fewer components than shown, or combine certain components, or different components. For example, the computer device 600 described above may also include input / output devices, network access devices, buses, etc.
[0091] The processor 601 mentioned above can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.
[0092] In some embodiments, the processor 601 may include one or more interfaces. These interfaces may include: an internal integrated circuit I2C interface, an integrated circuit built-in audio bus I2S interface, a pulse code modulation (PCM) interface, a universal asynchronous transceiver (URAT) interface, a mobile industry processor MIPI interface, a general purpose input / output (GPIO) interface, an on-board diagnostic (OBD) system interface, and / or a universal serial bus (USB) interface, etc. It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the computer device 600. In other embodiments of this application, the computer device 600 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.
[0093] In some embodiments, the computer device 600 can connect internal devices and modules through one or more interfaces. The aforementioned memory 602 can be an internal storage unit of the computer device 600, such as a hard disk or RAM. The aforementioned memory 602 can also include both internal storage units and external storage devices. The aforementioned memory 602 is used to store the aforementioned computer program and other programs and data required by the computer device 600. The aforementioned memory 602 can also be used to temporarily store data that has been output or will be output.
[0094] Communication unit 604 can provide solutions for wireless communication applications on computer device 600, including Wireless Local Area Network (WLAN), Bluetooth (BT), Global Navigation Satellite System (GNSS), Frequency Modulation (FM), Near Field Communication (NFC), and Infrared (IR). Communication unit 604 can be one or more communication devices integrating at least one communication processing module. It receives electromagnetic waves via an antenna, demodulates and filters the electromagnetic wave signals, and sends the processed signals to processor 601. Communication unit 604 can also receive signals to be transmitted from processor 601, frequency modulate and amplify them, and then convert them into electromagnetic waves for radiation via the antenna.
[0095] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the above equipment can be divided into different functional units or modules to complete all or part of the functions described above.
[0096] The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of software functional units.
[0097] In the embodiments of this application, the specific names of each functional unit and module are only for easy distinction and are not intended to limit the scope of protection of this application. It should be understood that each step in the above-described method embodiments provided in this application can be completed by the integrated logic circuits in the processor hardware or by instructions in software form. The method steps disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.
[0098] This application also provides a computer program product, which includes a computer program (also referred to as code or instructions) that, when run, causes a computer to execute the vehicle maintenance data access control method described in the above embodiments.
[0099] The various embodiments of this application can be combined arbitrarily to achieve different technical effects.
[0100] In the embodiments provided in this application, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, in the form of a computer program product.
[0101] The computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.
[0102] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is run, it causes the computer to perform the method executed by the computer device in any of the foregoing embodiments.
[0103] Figure 7 This is a schematic diagram of a computer-readable storage medium provided in an embodiment of this application. For example... Figure 7 As shown, the computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means.
[0104] The computer-readable storage medium can be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Universal Optical Discs, DVDs), or semiconductor media (e.g., solid-state drives, SSDs), etc.
[0105] Those skilled in the art will understand that implementing all or part of the processes in the foregoing embodiments can be accomplished by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the foregoing method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or RAM, magnetic disks, or optical disks.
[0106] In summary, the above description is merely an embodiment of the technical solution of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the disclosure of this application should be included within the scope of protection of this application.
Claims
1. A method for access control of vehicle maintenance data, characterized in that, include: Receive an access request from a client, the access request including at least a device identifier, a vehicle identifier, and the client's network access location information; The network access location information is compared with the pre-stored geofencing information; If the network access location information is located within the area defined by the geographic location fence information, then the access request is determined to be an abnormal access request; Based on the historical access records of the device identifier, the number of different network access location information from the same client within a first preset time period is obtained. If the number of locations exceeds the first threshold, the access request is determined to be an abnormal access request. The frequency and interval of access to the vehicle identifier are used to determine whether the access request is an abnormal access request. For clients whose access requests are determined to be abnormal, implement the corresponding access restriction policy.
2. The method according to claim 1, characterized in that, The step of determining whether an access request is an abnormal access request based on the frequency and interval of access to the vehicle identifier specifically includes: The number of times the device identifier accesses the vehicle identifier within a second preset time period is counted. Based on the historical access records of the device identifier, obtain the access time interval between the vehicle identifier accessed in the current access and the different vehicle identifier accessed in the previous access; If the number of accesses exceeds the second threshold, or the access time interval is less than the third threshold, then the access request is determined to be an abnormal access request.
3. The method according to claim 2, characterized in that, The method of counting the number of times the device identifier accesses the vehicle identifier within a second preset time period specifically includes: The access requests of the device identifier to the same vehicle identifier repeatedly within the second preset time period are deduplicated.
4. The method according to claim 2, characterized in that, The method further includes: The system counts at least two network access location information accessed by the vehicle identifier within a third preset time period. If the at least two network access location information are different, the access request is determined to be an abnormal access request.
5. The method according to any one of claims 1 to 4, characterized in that, The execution of corresponding access restriction policies on clients whose access requests are determined to be abnormal specifically includes: The current access request is blocked, and access requests initiated by the device identifier within a fourth preset time period are prohibited.
6. The method according to any one of claims 1 to 4, characterized in that, The access restriction policy includes adding the device identifier to a temporary restricted list. After executing the corresponding access restriction policy on the client making the abnormal access request, the method further includes: The device identifiers added to the temporary restricted list are reviewed through a manual review channel; After confirming that the client corresponding to the device identifier has performed normal maintenance operations, the access restriction policy on the device identifier is lifted.
7. The method according to claim 6, characterized in that, The policy for lifting the access restriction on the device identifier specifically includes: Remove the device identifier from the temporary restricted list and reset at least one risk counter associated with the device identifier used to determine the abnormal access request.
8. A vehicle maintenance data access control system, characterized in that, For implementing the method as described in any one of claims 1 to 7, comprising: The request receiving module is used to receive access requests from clients, wherein the access requests include at least a device identifier, a vehicle identifier, and the network access location information of the client; A location information processing module, connected to the request receiving module, is used to compare the network access location information with pre-stored geographic location fence information. If the network access location information is located within the area defined by the geographic location fence information, the access request is determined to be an abnormal access request. The location information processing module is also used to obtain the number of different network access location information of the client within a first preset time period based on the historical access records of the device identifier. If the number of locations exceeds a first threshold, the access request is determined to be an abnormal access request. The behavior analysis module is connected to the request receiving module and determines whether the access request is an abnormal access request based on the access frequency and interval of the vehicle identifier. The policy execution module, connected to the location information processing module and the behavior analysis module, is used to execute corresponding access restriction policies on the client making the abnormal access request.
9. A computer device, characterized in that, The device includes one or more memories and one or more processors; the memories are coupled to the one or more processors, the memories are used to store computer program code, the computer program code including computer instructions, and the one or more processors invoke the computer instructions to cause the computer device to perform the method as described in any one of claims 1 to 7.
10. A computer-readable storage medium storing computer instructions thereon, characterized in that, When the computer instructions are executed by the processor, they implement the method of any one of claims 1 to 7.