Government affair data platform interface calling monitoring method and system and electronic equipment

Abstract

The invention provides a monitoring method and system for interface calling of a government affair data platform and electronic equipment. The monitoring method comprises the steps of obtaining a calling request of calling a target interface of a public data platform by a government affair application; wherein the incoming parameters of the calling request at least comprise a user ID, an application ID and an application server IP; verifying the user ID, the application ID and the application server IP, and if the user ID, the application ID and the application server IP pass verification, returning calling data to the government affair application; identifying an interface calling behavior of calling the target interface by the government affair application based on preset business logic, and if the interface calling behavior does not accord with the business logic, determining that the interface calling behavior of the government affair application is an abnormal calling behavior; wherein the business logic comprises a user calling the target interface, calling time, a government affair application calling the target interface, a server calling the target interface and calling data. The accuracy of monitoring the abnormal calling behavior of the interface is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of interface security monitoring, and in particular to a monitoring method, system and electronic equipment for interface calls of a government data platform. Background Art

[0002] Since the establishment of data bureaus in various regions, public data platforms have been established. Public data platforms are used to store, manage, and share public data. Public data sharing methods include interface sharing and batch sharing. Interface sharing encapsulates public data access, query, retrieval, and retrieval functions into standardized APIs (Application Programming Interfaces), which can be accessed by other systems or departments through methods such as HTTP requests to obtain the required data. These interfaces define the data format, access methods, parameter requirements, and other aspects, allowing callers to easily obtain the required data according to the interface specifications.

[0003] However, a public data platform often registers and publishes hundreds or even thousands of interfaces, which are used by tens of thousands of applications across various local business departments. For example, the Zhejiang Provincial Public Data Platform has registered over 3,000 interfaces, which are used by over 1,700 applications across the province. Monitoring these interfaces to ensure they are not misused (used for unintended purposes) or accessed by unauthorized parties (causing data leaks), leading to data security incidents, is a key issue requiring significant attention.

[0004] Currently, technologies such as interface vulnerability scanning and repair, access control and identity authentication, secure transmission protocols, interface call monitoring and auditing technologies are available to prevent interface call data security risks.

[0005] 1) Interface vulnerability scanning technology (such as penetration testing) is used to discover vulnerabilities in the interface itself.

[0006] 2) Access control and identity authentication are used on the application side to prevent risks such as permission abuse and identity fraud.

[0007] 3) Secure transmission protocol uses secure transmission protocols such as HTTPS to ensure the integrity and confidentiality of data during transmission.

[0008] 4) Interface monitoring and auditing refers to the detailed logging of interface calls and data access, including access time, visitor identity, access content, etc., to monitor the access behavior of the interface in real time. Once abnormal or suspicious behavior is detected, an early warning will be issued immediately and corresponding measures will be taken (such as Figure 1 shown).

[0009] Existing interface monitoring and auditing technology is deployed on public data platforms as a monitoring and protection measure. Its purpose is to enable the platform (data bureau) to monitor user calls to interfaces and prevent their abuse. However, a key drawback of current solutions is that the platform's interface monitoring and auditing rules are static and fixed. As a result, existing interface monitoring systems are unable to accurately detect abnormal calls. Summary of the Invention

[0010] In view of this, the purpose of the present invention is to provide a method, system and electronic equipment for monitoring interface calls of a government data platform, so as to improve the accuracy of monitoring abnormal interface call behavior.

[0011] In order to achieve the above object, the technical solution adopted by the present invention is as follows:

[0012] In the first aspect, the present invention provides a monitoring method for interface calls of a government data platform, comprising: obtaining a call request for a government application to call a target interface of a public data platform; wherein the input parameters of the call request include at least: user ID, application ID, and application server IP; verifying the user ID, application ID, and application server IP, and if the user ID, application ID, and application server IP are all verified, returning the call data to the government application; identifying the interface call behavior of the government application calling the target interface based on a preset business logic, and if it does not conform to the business logic, determining that the interface call behavior of the government application is an abnormal call behavior; wherein the business logic includes: the user who calls the target interface, the call time, the government application that calls the target interface, the server that calls the target interface, and the call data.

[0013] Optionally, the user ID, application ID and application server IP are verified, including: comparing the application ID with a pre-configured application ID whitelist, if the application ID is in the application ID whitelist, the application ID verification is passed; based on a pre-built association table between the user ID and the application ID, the user ID is verified, if there is an association between the user ID and the application ID, the user ID verification is passed; if the target interface restricts access to the IP, the application server IP is compared with the pre-set access IP segment of the target interface, if the application server IP matches the access IP segment, the application server IP verification is passed.

[0014] Optionally, before obtaining the call request of the government application to call the target interface of the public data platform, it also includes: connecting the government application to the user system and application directory pre-built by the public data platform, and establishing an association relationship table between each user ID in the user system and the application ID of the government application.

[0015] Optionally, it also includes: obtaining the calling parameters of the interface associated with the government application; wherein the calling parameters include one or more of the following: calling frequency, request interval, IP geographic location, request parameters; modeling the calling parameters, and identifying abnormal calling behavior of the interface based on the modeling results.

[0016] Optionally, after obtaining the calling parameters of the interface associated with the application ID, it also includes: obtaining the real business data of the government application; comparing the real business data with the calling frequency; if the difference between the real business data and the calling frequency exceeds a preset value, it is determined that abnormal calling behavior exists.

[0017] Optionally, after determining that the interface call behavior of the government application is an abnormal call behavior, it also includes: automatically triggering an alarm and executing a preset handling strategy; wherein the handling strategy at least includes: banning the user ID and restricting the application server IP access rights.

[0018] Optionally, it also includes: recording the full log of application ID, user ID, application server IP and call data through API monitoring equipment, and auditing and tracing abnormal call behavior based on the full log; or using bypass mirror traffic collection technology to record the log of application ID, user ID, application server IP and call data, and auditing and tracing abnormal call behavior based on the log.

[0019] In the second aspect, the present invention provides a monitoring system for interface calls of a government data platform, comprising: a data acquisition module for obtaining call requests for government applications to call the target interface of a public data platform; wherein the input parameters of the call request include at least: user ID, application ID, and application server IP; an identity authentication module for verifying the user ID, application ID, and application server IP, and returning the call data to the government application if the user ID, application ID, and application server IP are all verified; an exception identification module for identifying the interface call behavior of the government application calling the target interface based on preset business logic, and determining that the interface call behavior of the government application is an abnormal call behavior if it does not conform to the business logic; wherein the business logic includes: the user who calls the target interface, the call time, the government application that calls the target interface, the server that calls the target interface, and the call data.

[0020] In a third aspect, the present invention provides an electronic device comprising a processor and a memory, wherein the memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the steps of any one of the methods provided in the first aspect above.

[0021] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the computer program executes the steps of any one of the methods provided in the first aspect.

[0022] The present invention brings the following beneficial effects:

[0023] The monitoring method, system and electronic device for the interface call of the above-mentioned government data platform provided by the present invention first obtain the call request of the government application to call the target interface of the public data platform; wherein, the input parameters of the call request include at least: user ID, application ID, application server IP; then the user ID, application ID and application server IP are verified, and if the user ID, application ID and application server IP are all verified, the call data is returned to the government application; finally, based on the preset business logic, the interface call behavior of the government application calling the target interface is identified, and if it does not conform to the business logic, the interface call behavior of the government application is determined to be an abnormal call behavior; wherein, the business logic includes: the user who calls the target interface, the call time, the government application that calls the target interface, the server that calls the target interface and the call data. In the above monitoring method, the user ID, application ID and application server IP of the government application that calls the target interface can be verified, and the call data will be fed back to the government application only after the verification is passed. This not only ensures the legitimacy of the user and government application identities, but also avoids the risks of unauthorized access and cross-regional attacks; abnormal call behavior is identified through preset business logic, so that the difference between the actual business data and the number of interface calls can be monitored, thereby improving the accuracy of monitoring abnormal interface call behavior.

[0024] Other features and advantages of the present invention will be described in the following description, and in part will become apparent from the description, or will be understood through implementation of the present invention. The purposes and other advantages of the present invention are realized and obtained by the structures particularly pointed out in the description, claims and drawings.

[0025] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the preferred embodiments are specifically listed below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0027] Figure 1A schematic diagram of the relationship between a public data platform and API interface monitoring and auditing provided by an embodiment of the present invention;

[0028] Figure 2 A flowchart of a method for monitoring government data platform interface calls provided by an embodiment of the present invention;

[0029] Figure 3 A schematic diagram of the structure of a monitoring system for government data platform interface calls provided by an embodiment of the present invention;

[0030] Figure 4 A schematic structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0031] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0032] Currently, the platform's interface monitoring and auditing rules are static and fixed. For example, if a single account calls more than 500 times, an alarm will be triggered. "500 times" is just an example, representing a "static, fixed" value. It can also be set to "100 times," "1000 times," or even based on the daily average call count over a specific period (for example, the past three months). This interface monitoring system has the following two problems:

[0033] 1) A "thief" (illegal caller) can access a small amount of data each day, which is below the interface monitoring alarm threshold. For example, 99 calls per day is below the monitoring threshold of 100. By continuously accessing data for a long period of time, such as six months or a year, they can "steal" a large amount of data without being detected by the monitoring system.

[0034] 2) Many false alarms. Practice has found that because the interface monitoring and auditing rules on the platform are static, a large number of false alarms are generated every day. Since more than 3,000 interfaces are called by more than 1,000 applications, if each application calls one interface, which is recorded as one call group, there will be tens of thousands of call groups (because one application may call multiple interfaces). Statistics show that hundreds of false alarms are generated every day. The verification and disposal of false alarms consumes a lot of energy of interface monitoring operators, resulting in "real problems being drowned by false alarms" (even if there is one real risk among 1,000 false alarms, the real risk cannot be identified and handled in a timely manner).

[0035] Based on this, the embodiment of the present invention provides a method, system and electronic device for monitoring the interface call of a government data platform, which can improve the accuracy of monitoring abnormal interface call behavior.

[0036] To facilitate understanding of this embodiment, we first provide a detailed introduction to a method for monitoring government data platform interface calls disclosed in an embodiment of the present invention. This method can be executed by electronic devices such as smartphones, computers, and tablets. This method is a dynamic interface monitoring method based on "2IDs and 1IP," implementing "one application, one monitoring" and truly achieving refined monitoring of application interface calls.

[0037] 2ID refers to application ID and user ID:

[0038] (1) Application ID is the unique identification code of the application. Taking Zhejiang Province as an example, when the application is cataloged in IRS (Zhejiang Province Integrated Digital Resource System), a unique and tamper-proof application ID is automatically generated.

[0039] (2) User ID refers to the unique identifier of the user logging into the application. In order to prevent the application calling the interface from forging or fabricating the user ID, the user ID that is uniquely identified in the system must be used, and the specific user can be located. For example, enterprises generally use mobile phone numbers as the unique user ID. However, the applications that call the public data platform belong to different developers in different business departments. In order to prevent the application developers from forging or fabricating user mobile phone numbers, a unique "user ID system" must be used, and the platform side can locate the person. Taking Zhejiang Province as an example, all applications for the public and enterprises in Zhejiang Province must be listed on "Zhejiang Liban". Individuals and legal persons log in to "Zhejiang Liban" and then jump to the corresponding government service application. Therefore, the "Zhejiang Liban" user ID is unique; all internal applications in Zhejiang Province must be listed on "Zhejiang Zhengding". Government officials scan the code through "Zhejiang Zhengding" to log in to the relevant internal government applications. Therefore, the "Zhejiang Zhengding" user ID is unique. Therefore, in Zhejiang, "Zhejiang Liban ID" and "Zhejiang Zhengding ID" can be used to locate a unique user.

[0040] Since government applications are either for businesses and the public, they must be listed on "Zhejiang Liban" or for department officials, they must be listed on "Zhejiang Government Nail". Therefore, through "Zhejiang Liban" and "Zhejiang Government Nail", all applications can be fully classified. The user system of "Zhejiang Liban" and "Zhejiang Government Nail" covers all users. "Zhejiang Liban" and "Zhejiang Government Nail" are under the management of the Zhejiang Provincial Data Bureau (the management unit of the Zhejiang Provincial Public Data Platform), which can ensure that the user IDs of "Zhejiang Liban" and "Zhejiang Government Nail" are unique, authentic, and valid, and can locate unique individuals based on "Zhejiang Liban" and "Zhejiang Government Nail".

[0041] In addition, the user's biometric features, such as fingerprints, faces, etc., can also be used as the user ID.

[0042] 2. 1IP refers to the server IP of the application that calls the interface: Taking the government cloud server IP as an example, the application server IP and application ID can be used together to determine whether the application that calls the interface is the one that applied for the interface.

[0043] In order to realize refined monitoring of the "2ID 1IP" interface, in the embodiment of the present invention, it is necessary to complete the user system transformation of the application that calls the interface in advance, that is, to connect the government application to the user system and application directory pre-built by the public data platform, and establish an association relationship table between each user ID in the user system and the application ID of the government application.

[0044] During the specific implementation, the public data platform pre-builds a set of compliant user systems and application directories, in which the user system includes each user's unique user ID, such as: "Zheliban" can be considered a user system, in which "Zheliban ID" is the user ID. Government applications are connected to the user system and application directory, that is, government applications need to complete the transformation of being listed on "Zheliban" and "Zhezhengding", otherwise the interface call permission will not be given. After the government application is connected to the user system, users in the user system can use the government application to call data from the public data platform, that is, an association relationship is established between the user and the application, and then an association relationship table can be established to store the association relationship between each user ID and the application ID of the government application.

[0045] See also Figure 2 The flowchart of a method for monitoring the call of a government data platform interface is shown, which illustrates that the method mainly includes the following steps S201 to S203:

[0046] Step S201: Obtain a call request from a government application to call a target interface of a public data platform.

[0047] In one embodiment, the user can call the target interface of the public data platform by sending an HTTP request, etc. to obtain the required data. In this embodiment, the input parameters of the call request include at least: user ID, application ID, and application server IP, otherwise no interface data is returned.

[0048] Step S202: Verify the user ID, application ID and application server IP. If the user ID, application ID and application server IP are all verified, return the call data to the government application.

[0049] In one embodiment, identity and authority verification is required during the interface call process, including:

[0050] (1) Application ID and user ID verification. Through customized identity authentication logic (such as inheriting AuthenticatingRealm), the caller's application ID and user ID are verified to verify their legitimacy. For example, a whitelist of legal application IDs can be pre-configured in the database, and the authenticity of the user ID can be verified using an encryption algorithm.

[0051] (2) IP address restriction. During the permission verification phase, the access source is restricted by the application server IP address. Traffic mirroring technology (such as port mirroring) is used to monitor IP access behavior in real time, and only specific IP segments are allowed to call sensitive interfaces.

[0052] If the user ID, application ID, and application server IP are all verified, the caller is allowed to call the target interface and the call data is returned to the government application.

[0053] Step S203: Identify the interface calling behavior of the government application calling the target interface based on the preset business logic. If it does not conform to the business logic, determine that the interface calling behavior of the government application is an abnormal calling behavior.

[0054] In one embodiment, abnormal calling behavior can be identified during and after the interface call. In this embodiment, the interface calling behavior of the government application calling the target interface can be identified based on the preset business logic, wherein the business logic includes: the user who calls the target interface, the calling time, the government application that calls the target interface, the server that calls the target interface, and the calling data. That is, the abnormal calling behavior is identified based on the business logic of "who (i.e. user ID) - at what time (when, i.e. calling time) - which application is logged in (how, i.e. application ID) - through which server (where, i.e. application server IP) - what data is called (what, i.e. calling data)". If the interface calling behavior of the target interface fully complies with the business logic, it is determined to be a normal interface calling behavior. If any of them does not comply, it is determined to be an abnormal calling behavior. In this embodiment, the behavior of the application calling the interface is finely monitored by the business logic, which can ensure that only when real business is generated, there will be data calls, avoiding machine traversal calls and public data being stored locally.

[0055] The monitoring method for the interface call of the above-mentioned government data platform provided by the present invention can verify the user ID, application ID and application server IP of the government application that calls the target interface, and only feed back the call data to the government application after the verification is passed, which not only ensures the legitimacy of the user and government application identities, but also avoids the risks of unauthorized access and cross-regional attacks; it identifies abnormal call behavior through preset business logic, so that the difference between the actual business data and the number of interface calls can be monitored, thereby improving the accuracy of monitoring abnormal interface call behavior.

[0056] In one embodiment, for the aforementioned step S202, that is, when verifying the user ID, application ID and application server IP, the following methods can be adopted, including but not limited to: first, the application ID is compared with a pre-configured application ID whitelist. If the application ID is in the application ID whitelist, the application ID verification is successful; then, based on the pre-acquired association relationship table between the user ID and the application ID, the user ID is verified. If there is an association relationship between the user ID and the application ID, the user ID verification is successful; finally, if the target interface restricts access to the IP, the application server IP is compared with the pre-set access IP segment of the target interface. If the application server IP meets the access IP segment, the application server IP verification is successful.

[0057] In one embodiment, the above method also includes: obtaining the calling parameters of the interface associated with the government application; wherein the calling parameters include one or more of the following: calling frequency, request interval, IP geographic location, request parameters; modeling the calling parameters, and identifying abnormal calling behavior of the interface based on the modeling results.

[0058] In practice, the call parameters of the interfaces associated with the application IDs of government applications are modeled. Based on the modeling results, abnormal call behavior is identified, such as frequent access or calls at unusual times (e.g., frequent requests in the early morning). Common modeling algorithms include correlation, clustering, classification (decision tree), time series, regression, and neural networks.

[0059] In an embodiment of the present invention, a machine learning algorithm can also be used to model features such as call frequency, IP geographic location, and request parameter complexity associated with the application ID to identify abnormal call behavior and dynamically assess risk levels.

[0060] In one embodiment, the above method can also perform parameter and protocol compliance checks, including: obtaining real business data of government applications; comparing the real business data with the call frequency; if the difference between the real business data and the call frequency exceeds a preset value, it is determined that abnormal calling behavior exists.

[0061] During implementation, the call frequency is verified to ensure it matches actual business data, preventing secondary packaging or traversal attacks on the interface. If the difference between the actual business data and the call frequency exceeds a preset value, abnormal call behavior is identified. For example, if only 100 cases were processed on that day and the interface was called 1,000 times, this is considered an abnormal call and will trigger an alarm.

[0062] In one embodiment, when abnormal calling behavior is detected (such as high-frequency access, IP spoofing), an alarm can be automatically triggered and a preset handling strategy can be executed; wherein the handling strategy at least includes: banning user ID and restricting application server IP access rights.

[0063] In practice, when anomalies are detected (such as frequent access or IP spoofing), the system automatically triggers an alarm and executes pre-set action strategies, such as temporarily blocking a user ID or restricting IP access. High-risk events (such as frequent calls) undergo manual secondary confirmation, and an alarm ticket is issued to the data user for review and resolution. Once the data user completes the review and resolution, the alarm ticket is closed.

[0064] In the embodiment of the present invention, the request frequency threshold of a single IP / device / user can be dynamically adjusted based on historical data (e.g., 100 times per day for normal users and 10 times per minute for abnormal IPs), or the IP reputation scoring system can be integrated with a third-party IP reputation database (e.g., abuseipdb) to automatically downgrade or block high-risk IPs. The IP reputation scoring system combines multi-dimensional data collection, dynamic scoring algorithms, and automated response mechanisms to form a closed-loop protection system, which specifically includes the following processes:

[0065] (1) Data source construction and integration.

[0066] First, collect heterogeneous data from multiple sources, including but not limited to: accessing commercial IP reputation APIs (such as ipdata scoring APIs and WhoisXML threat intelligence libraries) to obtain real-time blacklists, malicious activity history, and other data; recording IP request frequency, access paths, abnormal behaviors (such as high-frequency failed logins, access during non-working hours), etc., and extracting features through log analysis tools (such as ELKStack); integrating with platforms such as Microsoft Defender Threat Intelligence and Cisco Talos to obtain contextual information such as malicious domain names and C2 servers associated with IPs. Then, standardize the data and build a unified data model, including but not limited to the following fields: basic attributes (ASN number, geographic location, operator information), basic attributes (ASN number, geographic location, operator information), threat tags (whether it is a C&C server, botnet node, dark web forum IP), and use ETL tools to clean invalid data, and complete missing fields through IP geolocation APIs (such as MaxMind).

[0067] (2) Construct a scoring model.

[0068] First, determine the scoring algorithm, including but not limited to: ① Rule engine layer: static rules: blacklist (such as AbuseIPDB tag), whitelist (trusted partner IP segment); dynamic rules: time window-based request volume surge detection (such as the number of requests exceeding 3 times the average within 5 minutes triggers an alert); ② Machine learning model: extract 30+ dimensional features, including: time series features (access frequency, interval distribution), behavioral features (API call success rate, parameter anomaly rate), association features (number of malicious domain names associated with IP), use XGBoost integration model, and integrate decision trees (for processing structured data) with LSTM (for capturing time series patterns); ③ Adjust rules and model weights according to business scenarios.

[0069] Then, the scoring dimensions are determined, such as: for malicious activities, +10 points for each C2 communication discovered; abnormal behavior, the average daily request volume exceeds the threshold × 2 times +5 points; security configuration, the associated server has the CVE-2023-1234 vulnerability +8 points; reputation decay, -2 points if the daily abnormal behavior decreases by 20%.

[0070] (3) Real-time evaluation and dynamic response.

[0071] Specifically, a tiered response mechanism is developed, categorizing risk levels. For example, a score of 80-100 indicates a high risk level, resulting in automatic blocking and an alert; a score of 60-79 indicates a medium risk level, resulting in speed limits and secondary verification; and a score of 0-59 indicates a low risk level, resulting in monitoring and logging. During implementation, thresholds can be dynamically adjusted, such as automatically reducing speed limits by 20% during peak business periods (such as Double 11), or initiating an "observation period" for first-time access from new IP addresses (within 72 hours of treatment as medium risk).

[0072] In addition, in this embodiment, Kong or Apigee can be used to implement real-time interception, such as adopting the following strategies: conditional blocking: IF ip_score>80THEN RETURN 403; frequency control: trigger sliding window current limiting when the daily IP request volume>1000.

[0073] Furthermore, in the implementation of the present invention, the entire link of interface calls can be traced and audited. Specifically, the full log of application ID, user ID, application server IP and call data can be recorded through API monitoring equipment, and abnormal call behavior can be audited and traced based on the full log.

[0074] During specific implementation, API monitoring equipment is used to record the full log of application ID, user ID, IP and call data, support post-audit and rapid tracing of risk events, and promptly issue alerts for data calls that are inconsistent with actual business.

[0075] To reduce server pressure, embodiments of the present invention can also employ bypass mirrored traffic collection technology, replacing the log analysis system to enable full API behavior tracing. Specifically, bypass mirrored traffic collection technology is used to record logs of application IDs, user IDs, application server IP addresses, and call data, and to audit and trace abnormal call behavior based on these logs. In specific implementations, bypass mirrored traffic collection technology is used to mirror the logging, auditing, and tracing to other servers, thereby reducing server pressure.

[0076] The monitoring method for the above-mentioned government data platform interface call provided by the embodiment of the present invention has the following advantages and effects compared with traditional technologies:

[0077] 1. More refined identity and permission verification. This invention verifies both the identity of the application and the legitimacy of the specific user's identity by associating the application ID with the user ID. At the same time, it combines the application server IP to limit access sources and prevent unauthorized access and cross-regional attack risks.

[0078] 2. More accurate identification of abnormal call behavior. This invention associates the application ID, user ID, and application server IP address to identify "who (who) - when (when) - which application (how) - through which server (where) - what data (what)" for each data call. It can monitor the difference between the actual number of transactions on the application side and the number of interface calls on the platform side, thus achieving refined risk alerting for "one application, one monitoring."

[0079] 3. Full-link tracing and rapid closed-loop disposal. The present invention realizes full-process tracing of interface calls by recording the interaction logs of application ID, user DI and application server IP. After the security alarm is triggered, the specific application, specific server and specific user can be traced according to the log to build a rapid tracing capability for risk events, which can quickly locate the root cause of the event. At the same time, the system can automatically trigger the risk disposal process corresponding to the application ID, such as temporarily banning the user ID or restricting the access rights of the application server IP, forming a rapid closed-loop disposal link of "monitoring-alarm-disposal".

[0080] Regarding the monitoring method for the government data platform interface call provided in the above embodiment, the embodiment of the present invention also provides a monitoring system for the government data platform interface call, see Figure 3 The diagram below shows a structure diagram of a monitoring system for government data platform interface calls, which mainly includes the following parts:

[0081] The data collection module 301 is used to obtain a call request from a government application to call a target interface of a public data platform; wherein the input parameters of the call request include at least: user ID, application ID, and application server IP;

[0082] The identity authentication module 302 is used to verify the user ID, application ID and application server IP. If the user ID, application ID and application server IP are all verified, the call data is returned to the government application;

[0083] The exception identification module 303 is used to identify the interface calling behavior of the government application calling the target interface based on the preset business logic. If it does not conform to the business logic, the interface calling behavior of the government application is determined to be an abnormal calling behavior; wherein, the business logic includes: the user who calls the target interface, the calling time, the government application that calls the target interface, the server that calls the target interface and the calling data.

[0084] The monitoring system for the interface call of the above-mentioned government data platform provided by the present invention can verify the user ID, application ID and application server IP of the government application that calls the target interface, and only feed back the call data to the government application after the verification is passed, which not only ensures the legitimacy of the user and government application identities, but also avoids the risks of unauthorized access and cross-regional attacks; it identifies abnormal call behavior through preset business logic, so that the difference between the real business data and the number of interface calls can be monitored, thereby improving the accuracy of monitoring abnormal interface call behavior.

[0085] In one embodiment, the above-mentioned identity authentication module 302 is further used to: compare the application ID with a pre-configured application ID whitelist. If the application ID is in the application ID whitelist, the application ID verification is passed; based on the pre-acquired association relationship table between the user ID and the application ID, verify the user ID. If the user ID and the application ID have an association relationship, the user ID verification is passed; if the target interface restricts access to the IP, the application server IP is compared with the pre-set access IP segment of the target interface. If the application server IP meets the access IP segment, the application server IP verification is passed.

[0086] In one embodiment, the above system also includes an application access module, which is used to: connect government applications to the user system and application directory pre-built by the public data platform, and establish an association relationship table between each user ID in the user system and the application ID of the government application.

[0087] In one embodiment, the above-mentioned abnormality identification module 303 is also used to: obtain the calling parameters of the interface associated with the government application; wherein the calling parameters include one or more of the following: calling frequency, request interval, IP geographic location, request parameters; model the calling parameters, and identify abnormal calling behavior of the interface based on the modeling results.

[0088] In one embodiment, the above-mentioned abnormality identification module 303 is also used to: obtain real business data of government applications; compare the real business data with the call frequency; if the difference between the real business data and the call frequency exceeds a preset value, it is determined that abnormal call behavior exists.

[0089] In one embodiment, the system further includes an alarm module for automatically triggering an alarm and executing a preset handling strategy; wherein the handling strategy at least includes: banning user IDs and restricting application server IP access rights.

[0090] In one embodiment, the above-mentioned system also includes an audit module, which is used to: record the full log of application ID, user ID, application server IP and call data through API monitoring equipment, and audit and trace abnormal call behavior based on the full log; or use bypass mirror traffic collection technology to record the log of application ID, user ID, application server IP and call data, and audit and trace abnormal call behavior based on the log.

[0091] It should be noted that the implementation principle and technical effects of the system provided in the embodiment of the present invention are the same as those of the aforementioned method embodiment. For the sake of brief description, for matters not mentioned in the system embodiment, reference can be made to the corresponding content in the aforementioned method embodiment.

[0092] An embodiment of the present invention further provides an electronic device. Specifically, the electronic device includes a processor and a storage device. The storage device stores a computer program, and when the computer program is executed by the processor, it executes the method described in any one of the above embodiments.

[0093] Figure 4 This is a structural diagram of an electronic device provided in an embodiment of the present invention. The electronic device 100 includes: a processor 40, a memory 41, a bus 42 and a communication interface 43. The processor 40, the communication interface 43 and the memory 41 are connected via the bus 42; the processor 40 is used to execute an executable module stored in the memory 41, such as a computer program.

[0094] The memory 41 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage. The system network element communicates with at least one other network element via at least one communication interface 43 (which may be wired or wireless), and may utilize the Internet, a wide area network, a local area network, a metropolitan area network, or the like.

[0095] The bus 42 may be an ISA bus, a PCI bus, or an EISA bus. The bus may be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, Figure 4 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0096] Among them, the memory 41 is used to store programs, and the processor 40 executes the program after receiving the execution instruction. The method executed by the device for flow process definition disclosed in any embodiment of the above-mentioned embodiment of the present invention can be applied to the processor 40 or implemented by the processor 40.

[0097] Processor 40 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method may be completed by hardware integrated logic circuits or software instructions in processor 40. The above processor 40 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It may implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in conjunction with the embodiments of the present invention may be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or the like. The storage medium is located in the memory 41 , and the processor 40 reads the information in the memory 41 and completes the steps of the above method in combination with its hardware.

[0098] The computer program product of the readable storage medium provided in the embodiment of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the method described in the previous method embodiment. The specific implementation can be referred to the previous method embodiment and will not be repeated here.

[0099] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0100] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the above-described embodiments, those skilled in the art should understand that any person skilled in the art can modify or easily conceive of changes to the technical solutions described in the above-described embodiments within the technical scope disclosed by the present invention, or replace some of the technical features therein with equivalents. Such modifications, changes, or replacements do not deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A monitoring method for government data platform interface calls, characterized in that: include: Obtain a call request from a government application to call a target interface of a public data platform; wherein the input parameters of the call request include at least: user ID, application ID, and application server IP; Verify the user ID, the application ID, and the application server IP address. If the user ID, the application ID, and the application server IP address are all verified successfully, return the call data to the government application. The interface calling behavior of the government application calling the target interface is identified based on the preset business logic. If it does not conform to the business logic, the interface calling behavior of the government application is determined to be an abnormal calling behavior; wherein, the business logic includes: the user who calls the target interface, the calling time, the government application that calls the target interface, the server that calls the target interface and the calling data.

2. The monitoring method according to claim 1, characterized in that: Verifying the user ID, the application ID, and the application server IP address includes: Compare the application ID with a pre-configured application ID whitelist. If the application ID is in the application ID whitelist, the application ID verification passes. Verify the user ID based on a pre-built association table between user IDs and application IDs. If there is an association between the user ID and the application ID, the user ID verification is successful. If the target interface restricts access IP, the application server IP is compared with the preset access IP segment of the target interface. If the application server IP meets the access IP segment, the application server IP verification is passed.

3. The monitoring method according to claim 1, characterized in that Before obtaining the call request of the target interface of the government application to call the public data platform, it also includes: The government affairs application is connected to the user system and application directory pre-built by the public data platform, and an association relationship table is established between each user ID in the user system and the application ID of the government affairs application.

4. The monitoring method according to claim 1, characterized in that: Also includes: Obtaining call parameters of the interface associated with the government application; wherein the call parameters include one or more of the following: call frequency, request interval, IP geographic location, and request parameters; The calling parameters are modeled, and abnormal calling behavior of the interface is identified based on the modeling result.

5. The monitoring method according to claim 4, characterized in that: After obtaining the call parameters of the interface associated with the application ID, the following steps are also included: Obtaining real business data of the government application; Comparing the actual business data with the call frequency; If the difference between the actual business data and the call frequency exceeds a preset value, it is determined that abnormal call behavior exists.

6. The monitoring method according to claim 1, characterized in that: After determining that the interface call behavior of the government application is an abnormal call behavior, the method further includes: Automatically trigger an alarm and execute a preset handling strategy; wherein, the handling strategy at least includes: banning the user ID and restricting the access rights of the application server IP.

7. The monitoring method according to claim 1, characterized in that: Also includes: Record the application ID, user ID, application server IP, and full log of call data through API monitoring equipment, and audit and trace abnormal call behavior based on the full log; Alternatively, bypass mirror traffic collection technology is used to record the application ID, the user ID, the application server IP and the call data log, and abnormal call behavior is audited and traced based on the log.

8. A monitoring system for government data platform interface calls, characterized in that: include: The data collection module is used to obtain the call request of the government application to call the target interface of the public data platform; wherein the input parameters of the call request include at least: user ID, application ID, and application server IP; An identity authentication module, configured to verify the user ID, the application ID, and the application server IP address, and return call data to the government application if the user ID, the application ID, and the application server IP address are all verified successfully. An exception identification module is used to identify the interface calling behavior of the government application calling the target interface based on the preset business logic. If it does not conform to the business logic, it is determined that the interface calling behavior of the government application is an abnormal calling behavior; wherein, the business logic includes: the user who calls the target interface, the calling time, the government application that calls the target interface, the server that calls the target interface and the calling data.

9. An electronic device, characterized in that: The method comprises a processor and a memory, wherein the memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are performed.

Images