A security verification method, system, device and medium for energy big data external supply

Abstract

The application discloses a kind of security check methods, systems, equipment and medium for energy big data outward supply, belong to network security and data service technical field, including: identity credentials in API call request is verified, build request context object;Based on request source address execution source address white list matching, match result is injected as source check mark request context object, marked as first request context object;For user identifier and request source address, respectively in user dimension and source address dimension execution call frequency counting and threshold comparison, comparison result is injected as frequency check mark first request context object, obtain second request context object;Read source check mark and frequency check mark, output access control decision for API call request.The application ensures that each illegal request must pass through complete check chain before reaching backend data engine, illegal request cannot penetrate to back end.

Description

Technical Field

[0001] This invention relates to the field of network security and data service technology, specifically to a security verification method, system, device, and medium for the external supply of energy big data. Background Technology

[0002] The Energy Big Data Center aggregates various energy data, including electricity and coal, and provides data product services to government departments and enterprise users. External users obtain identity credentials through application and include these credentials in their API requests to call data service interfaces. Existing API gateways typically manage external requests using a combination of identity credential verification and token bucket rate limiting. The process is as follows: after receiving a request, the gateway verifies the identity credential, then retrieves the remaining tokens in the token bucket corresponding to the current credential from the cache. If there are enough tokens, the request is forwarded to the backend data engine; otherwise, a rate limit exceeded response is returned.

[0003] However, the above scheme has some drawbacks. IP source verification and frequency counting are executed asynchronously in separate threads, which are separate from the main request processing pipeline. This means that illegal requests can continue to occupy backend resources even after a verification fails. At the same time, the token bucket replenishes tokens at a fixed rate, which cannot precisely control the distribution of requests within a unit time window. Attackers can send a large number of requests at the beginning of the window to penetrate the rate limiting mechanism, causing the backend data engine to be overloaded instantly, and the response latency of legitimate users' requests will increase significantly. Summary of the Invention

[0004] In view of the above-mentioned problems, the present invention provides a method, system, device and medium for security verification of energy big data supply to external parties.

[0005] Therefore, the technical problem solved by this invention is: how to integrate source legitimacy verification and frequency compliance verification into the same request processing pipeline during the request processing of energy big data API services, so that the verification results of each dimension can be transmitted in real time during the request processing and centrally processed by a unified decision-making step, ensuring that illegal requests are intercepted in real time before reaching the backend data engine.

[0006] To address the aforementioned technical problems, this invention provides the following technical solution: a security verification method for the external supply of energy big data, comprising, In response to the API call request for energy data services, the identity credentials in the request are verified, and a request context object carrying the user identifier and the request source address is constructed. Based on the request source address in the request context object, perform source address whitelist matching, and inject the matching result as a source verification flag into the request context object to obtain a first request context object carrying the source verification flag; Based on the user identifier and request source address in the first request context object, call frequency count and threshold comparison are performed in the user dimension and the source address dimension, respectively. The comparison result is injected into the first request context object as a frequency verification flag to obtain a second request context object that carries both a source verification flag and a frequency verification flag. Read the source verification flag and frequency verification flag from the second request context object, and output the access control decision for the API call request.

[0007] As a preferred embodiment of the security verification method for external supply of energy big data described in this invention, the identity credentials in the API call request of the energy data service are verified, and the construction of a request context object carrying the user identifier and the request source address includes: Extract identity credentials from API call requests for energy data services; Initiate a matching query to the credential database based on the identity credential identifier; In response to a successful match and a valid credential record, the user identifier and service identifier bound to the identity credential identifier are retrieved from the certified database, and a request context object is constructed.

[0008] As a preferred embodiment of the security verification method for external supply of energy big data described in this invention, the step of performing source address whitelist matching based on the request source address in the request context object, and injecting the matching result as a source verification mark into the request context object to obtain a first request context object carrying the source verification mark includes: Retrieve the whitelist of source addresses bound to the service identifier in the request context object; Perform a source matching operation between the request source address and the source address whitelist, and inject the result of the source matching operation as a source verification flag into the request context object to obtain the first request context object.

[0009] As a preferred embodiment of the security verification method for external supply of energy big data described in this invention, the step of performing call frequency counting and threshold comparison based on the user identifier and request source address in the first request context object, respectively, and injecting the comparison result as a frequency verification mark into the first request context object to obtain a second request context object carrying both a source verification mark and a frequency verification mark includes: Based on the user identifier and request source address in the first request context object, construct the user dimension count identifier and the source address dimension count identifier respectively; Perform atomic counting operations on the user dimension count identifier and the source address dimension count identifier within their respective time windows to obtain the current count value of the user dimension and the current count value of the source address dimension. The current count values ​​for the user dimension and the current count values ​​for the source address dimension are compared with the corresponding frequency thresholds, and the comparison results are injected into the first request context object as frequency verification flags to obtain the second request context object.

[0010] As a preferred embodiment of the security verification method for external supply of energy big data described in this invention, the source matching operation includes: Each entry in the source address whitelist is retrieved sequentially. When the current entry is a single address, the request source address is matched against the current entry. When the current entry is an address network segment, convert the request source address into a numerical form and then determine whether it falls within the numerical range of the address network segment; When the request source address matches any entry in the source address whitelist, the source verification flag in the first request context object is marked as valid; If the request source address does not match any of the entries in the source address whitelist, mark the source verification flag in the first request context object as illegal.

[0011] As a preferred embodiment of the security verification method for external supply of energy big data described in this invention, the atomic counting operation includes: Simultaneously, increment instructions are executed on the user dimension count flag and the source address dimension count flag to obtain the current count value of the user dimension and the current count value of the source address dimension, respectively. When the user dimension count flag is in the new status, set an expiration time for the user dimension count flag that is consistent with the duration of the user dimension time window. When the source address dimension count flag is in the new status, set an expiration time for the source address dimension count flag that is consistent with the duration of the source address dimension time window; Write the current count values ​​for the user dimension and the current count values ​​for the source address dimension into the corresponding count fields in the first request context object.

[0012] As a preferred embodiment of the security verification method for external supply of energy big data described in this invention, the output of access control decisions for API call requests includes: If the origin verification flag in the second request context object is invalid, a origin rejection response is returned to the initiator of the API call request; When the frequency check flag in the second request context object is marked as frequency exceeded, a frequency rejection response is returned to the initiator of the API call request; When the source verification flag in the second request context object is valid and the frequency verification flag is compliant, the API call request is forwarded to the backend data engine.

[0013] This invention provides a security verification system for the external supply of energy big data.

[0014] To address the aforementioned technical problems, this invention provides the following technical solution: a security verification system for the external supply of energy big data, comprising: a construction module, a source legality verification module, a frequency compliance verification module, and an output module; The construction module is used to construct a request context object carrying the user identifier and the request source address in response to the verification of identity credentials in the API call request of the energy data service; The source legitimacy verification module is used to perform source address whitelist matching based on the request source address in the request context object, and inject the matching result as a source verification mark into the request context object to obtain a first request context object carrying the source verification mark. The frequency compliance verification module is used to perform call frequency count and threshold comparison based on the user identifier and request source address in the first request context object, respectively, in the user dimension and the source address dimension, and inject the comparison result as a frequency verification mark into the first request context object to obtain a second request context object that carries both the source verification mark and the frequency verification mark. The output module is used to read the source verification flag and frequency verification flag in the second request context object and output the access control decision for the API call request.

[0015] The present invention provides a computer device, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of the security verification method for external supply of energy big data.

[0016] The present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the security verification method for external supply of energy big data.

[0017] The beneficial effects of this invention are as follows: By integrating source legitimacy verification and frequency compliance verification into the same request processing pipeline, the verification results of each step are sequentially written into the request context object and passed to the next step. A comprehensive decision-making step then reads and outputs a pass or reject decision. Compared to existing technologies where each verification step is executed asynchronously and independently, this invention ensures that every illegal request must pass through the complete verification chain before reaching the backend data engine, preventing illegal requests from penetrating to the backend.

[0018] In frequency compliance verification, by performing atomic counting operations at the user dimension and the source address dimension respectively, the problem that attackers can send requests in a concentrated manner to penetrate the rate limit at the beginning of the window due to asynchronous token replenishment in the token bucket scheme is solved, making the request count within a unit time window accurate and controllable. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating a security verification method for external supply of energy big data, provided as an embodiment of the present invention.

[0021] Figure 2 The flowchart illustrates the source matching operation of a security verification method for external supply of energy big data, as provided in one embodiment of the present invention.

[0022] Figure 3 The flowchart illustrates an atomic counting operation of a security verification method for external supply of energy big data, provided as an embodiment of the present invention. Detailed Implementation

[0023] To make the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0024] Example 1, referring to Figure 1 This is one embodiment of the present invention, which provides a security verification method for the external supply of energy big data, including: This invention uses a request context object as the state carrier, integrating source legitimacy verification and frequency compliance verification into the same request processing pipeline. The verification results of each step are sequentially written into the request context object and passed to the next step. A comprehensive decision-making step then reads and outputs a pass / reject decision, ensuring that illegal requests are intercepted in real time before reaching the backend data engine. Specifically, it includes the following steps: S1. In response to the API call request for energy data services, the identity credentials in the request are verified, and a request context object carrying the user identifier and the request source address is constructed. S2. Perform source address whitelist matching based on the request source address in the request context object, and inject the matching result as a source verification flag into the request context object to obtain the first request context object carrying the source verification flag. S3. Based on the user identifier and request source address in the first request context object, perform call frequency count and threshold comparison in the user dimension and source address dimension respectively, and inject the comparison result as a frequency verification mark into the first request context object to obtain a second request context object that carries both source verification mark and frequency verification mark. S4. Read the source verification flag and frequency verification flag from the second request context object, and output the access control decision for the API call request.

[0025] Example 2, an embodiment of the present invention, provides a security verification method for the external supply of energy big data based on the previous embodiment, including: Step S1: In response to the API call request for energy data services, the identity credentials are verified, and a request context object carrying the user identifier and the request source address is constructed, including the following steps S11~S13. S11. Extract the identity credential identifier from the API call request of the energy data service.

[0026] Specifically, the first credential identifier (AppKey) and the second credential identifier (AppSecret) are extracted from the request header of the API call request. At the same time, the request source address (source_ip), request timestamp (timestamp) and terminal identifier string (User-Agent) are extracted and temporarily stored.

[0027] S12. Initiate a matching query to the credential database based on the identity credential identifier.

[0028] Specifically, the system searches the local credential database for a matching, unexpired credential record. If no matching record is found or the credential record has expired, the system determines that the identity credential verification has failed, terminates the current request processing flow, and returns an identity authentication failure response to the initiator.

[0029] S13. In response to a successful match and a valid credential record, retrieve the user identifier and service identifier bound to the identity credential identifier from the certified database and construct a request context object.

[0030] Specifically, a globally unique request identifier (request_id) is generated, in the format power_req_yyyyMMdd_serial number, to uniquely identify this request in log recording and system monitoring; a request context object is constructed based on the request identifier, user identifier, service identifier, request source address, request timestamp, and terminal identifier string, and the source verification flag (ip_valid), frequency verification flag (rate_ok), user-dimensional count field (user_rate_count), and source address-dimensional count field (ip_rate_count) are initialized in the request context object.

[0031] It should be further noted that the source verification flag and frequency verification flag are initially in a state of being to be filled, and the user dimension count field and source address dimension count field are initially 0; the constructed request context object is passed to the source validity verification step.

[0032] Step S2: Perform source address whitelist matching based on the request source address in the request context object, and inject the matching result as a source verification flag into the request context object to obtain a first request context object carrying the source verification flag, including the following steps S21~S22: S21. Obtain the whitelist of source addresses bound to the service identifier in the request context object.

[0033] Specifically, using the service identifier in the request context object as the query condition, the whitelist of source addresses bound to the current service identifier is retrieved from the configuration database of the security management center.

[0034] The source address whitelist can take the form of two entries: a single address and an address range. That is, the whitelist entry can be a specific single IP address or an IP address range represented in CIDR format.

[0035] The source address whitelist can also take the form of dynamically generated address entries based on domain name resolution results. That is, by resolving the preset domain name in real time to obtain the corresponding set of IP addresses, the set is used as a whitelist entry for matching.

[0036] S22. Perform a source matching operation between the request source address and the source address whitelist, and inject the result of the source matching operation as a source verification flag into the request context object to obtain the first request context object.

[0037] Specifically, refer to Figure 2 As shown, the request source address is retrieved from the request context object and matched against each entry in the source address whitelist in turn.

[0038] When the source address whitelist entry is a single address, the request source address will be matched exactly with that entry; When the source address whitelist entry is an address range, the request source address is converted into a numerical form and then it is determined whether it falls within the numerical range of that address range. When the request source address matches any entry in the source address whitelist, the source verification flag is injected into the first request context object and marked as valid; When the request source address does not match any of the entries in the source address whitelist, inject the source verification flag into the first request context object and mark it as illegal; pass the updated first request context object to the frequency compliance verification step.

[0039] Step S3: Based on the user identifier and request source address in the first request context object, perform call frequency count and threshold comparison on the user dimension and source address dimension respectively, and inject the comparison result as a frequency verification flag into the first request context object to obtain a second request context object carrying both source verification flag and frequency verification flag, including the following steps S31~S33: S31. Based on the user identifier and request source address in the first request context object, construct the user dimension count identifier and the source address dimension count identifier respectively.

[0040] Specifically, a user-dimensional count identifier (user_rate_key) is constructed by combining the user identifier and the service identifier, in the format rate:user:{user_id}:{service_id}, which is used to uniquely identify the user's request count under the current service in the cache.

[0041] A source address dimension count identifier (ip_rate_key) is constructed by combining the request source address and service identifier, with the format rate:ip:{source_ip}:{service_id}. This identifier is used to uniquely identify the request count of the source address under the current service in the cache.

[0042] S32. Perform atomic counting operations on the user dimension count identifier and the source address dimension count identifier within their respective time windows to obtain the current count value of the user dimension and the current count value of the source address dimension.

[0043] Specifically, refer to Figure 3 As shown, on the cache server, an auto-increment instruction is executed simultaneously on the user dimension count flag and the source address dimension count flag in an atomic manner to obtain the current count value of the user dimension (user_current) and the current count value of the source address dimension (ip_current), respectively.

[0044] When the user dimension count flag is in the new state, set an expiration time for the user dimension count flag that is consistent with the user dimension time window duration (window_user).

[0045] When the source address dimension count flag is in a new state, set an expiration time for the source address dimension count flag that is consistent with the source address dimension time window duration (window_ip).

[0046] Furthermore, atomic counting operations can be implemented using cache increment instructions, that is, the count identifier is atomically incremented on the cache server and the corresponding expiration time is set when the count identifier is in a newly created state.

[0047] Furthermore, atomic counting operations can also be implemented through database transactions, that is, by performing an increment operation on the count field and committing within a database transaction to ensure the atomicity of the counting.

[0048] S33. Compare the current count value of the user dimension and the current count value of the source address dimension with the corresponding frequency thresholds respectively, and inject the comparison result as a frequency verification flag into the first request context object to obtain the second request context object.

[0049] Specifically, the current count value of the user dimension is compared with the frequency threshold (user_limit) of the user dimension, and the current count value of the source address dimension is compared with the frequency threshold (ip_limit) of the source address dimension.

[0050] Furthermore, the frequency thresholds for user dimension and source address dimension can be configured independently according to the contractual agreement corresponding to the service identifier. The thresholds corresponding to different service identifiers are independent of each other and do not affect each other.

[0051] Furthermore, when the current count value of the user dimension exceeds the frequency threshold of the user dimension or the current count value of the source address dimension exceeds the frequency threshold of the source address dimension, the frequency verification flag is marked as frequency exceeding the limit, and the current count value of the user dimension and the current count value of the source address dimension are written into the user dimension count field and the source address dimension count field in the first request context object, respectively.

[0052] If the current count value of the user dimension does not exceed the frequency threshold of the user dimension and the current count value of the source address dimension does not exceed the frequency threshold of the source address dimension, the frequency verification flag is marked as compliant, and the current count value of the user dimension and the current count value of the source address dimension are written into the user dimension count field and the source address dimension count field of the first request context object, respectively; the second request context object is passed to the comprehensive decision-making step.

[0053] Step S4: Read the source verification flag and frequency verification flag from the second request context object, and output the access control decision for the API call request, including the following steps S41~S43: S41. When the source verification flag is invalid, return a source rejection response to the initiator of the API call request.

[0054] The source verification flag is read from the second request context object. If the source verification flag is marked as invalid, the request is determined to be invalid. An HTTP 403 Forbidden response is returned to the initiator, and the request processing flow is terminated.

[0055] S42. When the frequency check flag indicates that the frequency has exceeded the limit, return a frequency rejection response to the initiator of the API call request.

[0056] Specifically, the frequency verification flag is read from the second request context object. If the frequency verification flag is marked as exceeding the frequency limit, it is determined that the current request exceeds the call frequency limit. A frequency rejection response (HTTP 429 TooMany Requests) is returned to the initiator, and the current request processing flow is terminated.

[0057] S43. When the source verification mark is valid and the frequency verification mark is compliant, forward the API call request to the backend data engine.

[0058] Specifically, when the source verification flag in the second request context object is marked as valid and the frequency verification flag is marked as compliant, the request is determined to be a valid request. The original API call request is then forwarded to the backend data engine, which processes it and returns a pass response (HTTP 200 OK) and the requested data to the initiator.

[0059] Example 3 is an embodiment of the present invention, which provides a method for improving the efficiency of short-term high-frequency energy storage. In order to verify the beneficial effects of the present invention, scientific demonstration is carried out through experiments.

[0060] Scenario 1: Attackers use stolen credentials to initiate high-frequency calls from illegitimate sources.

[0061] A government department subscribed to a monthly industrial electricity consumption statistics product. The product's source address whitelist was the department's office network segment (202.101.1.0 / 24), with a user-level frequency threshold of 100 times per minute and a source address-level frequency threshold of 10 times per second. An attacker obtained the service's first and second credential identifiers through phishing and initiated calls from the source address 8.8.8.8 at a frequency of 20 times per second, attempting to obtain sensitive electricity data.

[0062] The gateway receives API call requests, extracts the first credential identifier and the second credential identifier from the request header, initiates a matching query to the credential database, and responds to a successful match and a valid credential record. It retrieves the user identifier (NDRC_YN) and service identifier (industrial_power) from the credential database, generates a request identifier, constructs a request context object, records the request source address as 8.8.8.8, records the request timestamp as 03:15:00, and sets the initial values ​​of the source verification flag and frequency verification flag to be filled.

[0063] Based on the service identifier, the source address whitelist (202.101.1.0 / 24) is obtained from the security control center. After converting the request source address 8.8.8.8 into a numerical form, it is determined whether it falls within the numerical range of 202.101.1.0 / 24. If the match fails, the source verification flag is marked as illegal and written into the request context object. The updated request context object is then passed to the frequency compliance verification step.

[0064] A user-dimensional count identifier is constructed based on the user identifier and the service identifier, and a source address-dimensional count identifier is constructed based on the request source address and the service identifier. An auto-increment instruction is executed atomically on the cache server to obtain the current count value of the user dimension (45 times, not exceeding the 100-times threshold) and the current count value of the source address dimension (18 times, exceeding the 10-times threshold). In response to the current count value of the source address dimension exceeding the source address dimension frequency threshold, the frequency verification flag is marked as frequency exceeding the limit and written to the request context object. The second request context object is then passed to the comprehensive decision-making step.

[0065] The source verification flag is read from the request context object. If the source verification flag is marked as invalid, an HTTP 403 Forbidden response is returned to the initiator, terminating the current request processing flow. In subsequent calls, as the source address dimension count continues to accumulate, each request is marked as exceeding the frequency limit in stage S3 and rejected in stage S4. The backend data engine does not receive any invalid requests.

[0066] Scenario 2: A legitimate user initiates a normal call within the authorized scope.

[0067] The request source address (203.205.2.100) of a large power generation company has been added to the source address whitelist. The contract stipulates that the frequency threshold for users is 200 times per minute, and the frequency threshold for source addresses is 10 times per second. During the company's normal peak business hours, it makes 3 calls per second, and has made a total of 179 calls in the current minute.

[0068] The gateway receives API call requests, extracts the first credential identifier and the second credential identifier from the request header, initiates a matching query to the credential database, and responds to a successful match and the credential record being in a valid state. It then retrieves the user identifier and service identifier from the credential database, generates a request identifier, constructs a request context object, and records the request source address as 203.205.2.100. The source verification flag and frequency verification flag are initially in a state of pending filling.

[0069] The source address whitelist is obtained from the security control center based on the service identifier. The request source address 203.205.2.100 is matched with the source address whitelist. If the match is successful, the source verification flag is marked as valid and written into the request context object. The updated request context object is then passed to the frequency compliance verification step.

[0070] A user-dimensional count identifier is constructed based on the user identifier and service identifier, and a source address-dimensional count identifier is constructed based on the request source address and service identifier. An auto-increment instruction is executed atomically on the cache server to obtain the current count value of the user dimension (179 times, not exceeding the 200-times threshold) and the current count value of the source address dimension (3 times, not exceeding the 10-times threshold). In response to the fact that the current count value of the user dimension does not exceed the user dimension frequency threshold and the current count value of the source address dimension does not exceed the source address dimension frequency threshold, the frequency verification flag is marked as compliant and written to the request context object, and the second request context object is passed to the comprehensive decision-making step.

[0071] Read the source verification flag and frequency verification flag from the request context object. If the source verification flag is marked as valid and the frequency verification flag is marked as compliant, the request is determined to be a valid request. The original API call request is forwarded to the backend data engine, which processes it and returns a pass response (HTTP 200 OK) and the requested data to the initiator.

[0072] Example 4 is an embodiment of the present invention. This embodiment provides a security verification system for the external supply of energy big data, including a construction module, a source legality verification module, a frequency compliance verification module, and an output module. The construction module is used to construct a request context object carrying the user identifier and the request source address in response to the verification of identity credentials in the API call request of the energy data service; The source legitimacy verification module is used to perform source address whitelist matching based on the request source address in the request context object, and inject the matching result as a source verification mark into the request context object to obtain a first request context object carrying the source verification mark. The frequency compliance verification module is used to perform call frequency count and threshold comparison based on the user identifier and request source address in the first request context object, respectively, in the user dimension and the source address dimension, and inject the comparison result as a frequency verification mark into the first request context object to obtain a second request context object that carries both the source verification mark and the frequency verification mark. The output module is used to read the source verification flag and frequency verification flag in the second request context object and output the access control decision for the API call request.

[0073] This embodiment also provides an electronic device applicable to a security verification method for external supply of energy big data, comprising: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the security verification method for external supply of energy big data as proposed in the above embodiment.

[0074] This embodiment also provides a storage medium storing a computer program, which, when executed by a processor, implements a security verification method for external supply of energy big data as proposed in the above embodiment.

[0075] The storage medium proposed in this embodiment and the security verification method for external supply of energy big data proposed in the above embodiments belong to the same inventive concept. Technical details not described in detail in this embodiment can be found in the above embodiments, and this embodiment has the same beneficial effects as the above embodiments.

[0076] Based on the above description of the implementation methods, those skilled in the art can clearly understand that the present invention can be implemented using software and necessary general-purpose hardware, and of course, it can also be implemented using hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk, or optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0077] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A security verification method for the external supply of energy big data, characterized in that, include: In response to the API call request for energy data services, the identity credentials in the request are verified, and a request context object carrying the user identifier and the request source address is constructed. Based on the request source address in the request context object, perform source address whitelist matching, and inject the matching result as a source verification flag into the request context object to obtain a first request context object carrying the source verification flag; Based on the user identifier and request source address in the first request context object, call frequency count and threshold comparison are performed in the user dimension and the source address dimension, respectively. The comparison result is injected into the first request context object as a frequency verification flag to obtain a second request context object that carries both a source verification flag and a frequency verification flag. Read the source verification flag and frequency verification flag from the second request context object, and output the access control decision for the API call request.

2. The security verification method for external supply of energy big data as described in claim 1, characterized in that, The identity credentials in the API call request in response to the energy data service are verified, and a request context object carrying the user identifier and the request source address is constructed, including: Extract identity credentials from API call requests for energy data services; Initiate a matching query to the credential database based on the identity credential identifier; In response to a successful match and a valid credential record, the user identifier and service identifier bound to the identity credential identifier are retrieved from the certified database, and a request context object is constructed.

3. The security verification method for external supply of energy big data as described in claim 2, characterized in that, The step of performing source address whitelist matching based on the request source address in the request context object, and injecting the matching result as a source verification flag into the request context object to obtain a first request context object carrying the source verification flag includes: Retrieve the whitelist of source addresses bound to the service identifier in the request context object; Perform a source matching operation between the request source address and the source address whitelist, and inject the result of the source matching operation as a source verification flag into the request context object to obtain the first request context object.

4. The security verification method for external supply of energy big data as described in claim 3, characterized in that, The step of performing call frequency counting and threshold comparison based on the user identifier and request source address in the first request context object, respectively, in the user dimension and the source address dimension, and injecting the comparison result as a frequency verification flag into the first request context object to obtain a second request context object carrying both a source verification flag and a frequency verification flag includes: Based on the user identifier and request source address in the first request context object, construct the user dimension count identifier and the source address dimension count identifier respectively; Perform atomic counting operations on the user dimension count identifier and the source address dimension count identifier within their respective time windows to obtain the current count value of the user dimension and the current count value of the source address dimension. The current count values ​​for the user dimension and the current count values ​​for the source address dimension are compared with the corresponding frequency thresholds, and the comparison results are injected into the first request context object as frequency verification flags to obtain the second request context object.

5. A security verification method for external supply of energy big data as described in claim 3, characterized in that, The source matching operation includes: Each entry in the source address whitelist is retrieved sequentially. When the current entry is a single address, the request source address is matched against the current entry. When the current entry is an address network segment, convert the request source address into a numerical form and then determine whether it falls within the numerical range of the address network segment; When the request source address matches any entry in the source address whitelist, the source verification flag in the first request context object is marked as valid; If the request source address does not match any of the entries in the source address whitelist, mark the source verification flag in the first request context object as illegal.

6. A security verification method for external supply of energy big data as described in claim 4, characterized in that, The atom counting operation includes: Simultaneously, increment instructions are executed on the user dimension count flag and the source address dimension count flag to obtain the current count value of the user dimension and the current count value of the source address dimension, respectively. When the user dimension count flag is in the new status, set an expiration time for the user dimension count flag that is consistent with the duration of the user dimension time window. When the source address dimension count flag is in the new status, set an expiration time for the source address dimension count flag that is consistent with the duration of the source address dimension time window; Write the current count values ​​for the user dimension and the current count values ​​for the source address dimension into the corresponding count fields in the first request context object.

7. A security verification method for external supply of energy big data as described in claim 4, characterized in that, The output includes access control decisions for API call requests, including: If the origin verification flag in the second request context object is invalid, a origin rejection response is returned to the initiator of the API call request; When the frequency check flag in the second request context object is marked as frequency exceeded, a frequency rejection response is returned to the initiator of the API call request; When the source verification flag in the second request context object is valid and the frequency verification flag is compliant, the API call request is forwarded to the backend data engine.

8. A security verification system for external supply of energy big data, employing the security verification method for external supply of energy big data as described in any one of claims 1 to 7, characterized in that, include: The module includes a construction module, a source legality verification module, a frequency compliance verification module, and an output module. The construction module is used to construct a request context object carrying the user identifier and the request source address in response to the verification of identity credentials in the API call request of the energy data service; The source legitimacy verification module is used to perform source address whitelist matching based on the request source address in the request context object, and inject the matching result as a source verification mark into the request context object to obtain a first request context object carrying the source verification mark. The frequency compliance verification module is used to perform call frequency count and threshold comparison based on the user identifier and request source address in the first request context object, respectively, in the user dimension and the source address dimension, and inject the comparison result as a frequency verification mark into the first request context object to obtain a second request context object that carries both the source verification mark and the frequency verification mark. The output module is used to read the source verification flag and frequency verification flag in the second request context object and output the access control decision for the API call request.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the security verification method for external supply of energy big data as described in 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 the processor, it implements the steps of the security verification method for external supply of energy big data as described in any one of claims 1 to 7.

Images