API request security management method and device, electronic equipment and storage medium

Abstract

The invention provides a security management method and device for an API request, electronic equipment and a storage medium, and belongs to the technical field of information security, in the method, decentralized authentication is realized by introducing an intelligent contract, and complexity and single-point failure risk of centralized key management are fundamentally avoided; through an end-to-end data verification mechanism based on Hash comparison, the integrity and authenticity of response data in the transmission process are ensured; and finally, the log hash value is anchored to the block chain, and a credible audit tracing chain is constructed by using the non-tampering characteristic of the block chain. According to the scheme, a set of automatic and high-credibility API security protection system penetrating through the whole process of prior authentication, in-process verification and after-process auditing is finally formed, and the reliability, transparency and safe water level of the system are remarkably improved.

Description

Security management methods, devices, electronic devices, and storage media for API requests Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a method, apparatus, electronic device, and storage medium for secure management of API requests. Background Technology

[0002] Currently, existing API security primarily relies on traditional security mechanisms, such as OAuth 2.0-based authorization and authentication, API key management, and IP whitelisting. These technologies attempt to ensure API security by setting access permissions, managing keys, and restricting access sources.

[0003] Specifically, the OAuth 2.0 authorization and authentication mechanism allows API consumers to obtain access tokens through a third-party authentication server, thereby accessing protected API interfaces. API key management authenticates API consumers by assigning them unique keys and including these keys in the request. IP whitelisting further enhances security by restricting access to API interfaces to API consumers only from specific IP addresses.

[0004] While existing technical solutions offer some level of security for API interfaces, the following issues remain: Key management is complex and prone to leakage: The generation, distribution, revocation, and updating of API keys are cumbersome, and leakage can lead to unauthorized access to the service, posing security risks; Data integrity is difficult to guarantee: Traditional methods struggle to effectively prevent data tampering during transmission. Substitution of data will affect the normal operation of the API interface and the accuracy of the data; Single point of failure risk: As the entry point for all requests, an attack or malfunction of the API gateway will render the entire service unavailable, severely impacting system stability and availability.

[0005] In summary, traditional API interface security solutions suffer from technical problems such as complex key management, high risk of single point of failure, difficulty in ensuring data integrity, and susceptibility to log tampering. Summary of the Invention

[0006] In view of this, the purpose of the present invention is to provide a method, apparatus, electronic device and storage medium for secure management of API requests, so as to alleviate the technical problems of traditional API interface security solutions, such as complex key management, high risk of single point of failure, difficulty in ensuring data integrity and easy tampering of logs.

[0007] In a first aspect, the present invention provides a secure management method for API requests, comprising: an API gateway receiving an access request from an API consumer, generating a request hash value for the access request, and invoking a smart contract deployed on a blockchain network to perform permission verification on the request hash value; if the permission verification is successful, forwarding the access request to an API server; receiving response data and a corresponding response hash value from the API server; performing a hash calculation on the received response data and comparing the calculation result with the received response hash value; after successful verification, forwarding the response data to the API consumer; and after the access request is processed, generating a log hash value for the request log and sending the log hash value to the blockchain network for storage, thereby achieving tamper-proof evidence storage and traceability of the request log.

[0008] Furthermore, the smart contract is pre-configured with API access control rules defined by the API service provider. These API access control rules include at least one of the following: allowed API consumer identifiers, access time ranges, and access frequency restrictions. The smart contract returns an authentication result by verifying whether the access request corresponding to the request hash value satisfies the API access control rules.

[0009] Furthermore, before the API gateway receives the access request from the API consumer, the smart contract is deployed on the blockchain network through the following steps: the API service provider generates smart contract code based on the API access control rules; the API service provider compiles the smart contract code into bytecode; and the API service provider deploys the bytecode to the blockchain network.

[0010] Furthermore, sending the log hash value to the blockchain network for storage includes: encapsulating the log hash value into transaction data destined for a specific smart contract address; signing the transaction data using the private key of the API gateway's control account, and broadcasting the signed transaction to the blockchain network; and nodes in the blockchain network adding a new block containing the signed transaction to the blockchain through a consensus mechanism to form a request log chain.

[0011] Furthermore, nodes in the blockchain network add a new block containing the transaction to the blockchain through a consensus mechanism, including: verifying the validity of the signed transaction; after successful verification, packaging the corresponding signed transaction with other transactions to generate a new candidate block; reaching a consensus with other nodes in the blockchain network on the validity of the candidate block based on a predefined consensus mechanism, and adding the consensus-reaching candidate block to the blockchain; and broadcasting the newly added block information to the blockchain network so that all nodes in the blockchain network can synchronously update the blockchain state.

[0012] Furthermore, the method also includes: when auditing is required, querying a specific log hash value from the blockchain network and obtaining the complete request log stored locally; calculating the hash value of the obtained request log and comparing it with the log hash value queried from the blockchain network; if they match, then confirming that the obtained request log is complete and reliable.

[0013] Furthermore, the request hash value is generated based on the requester's identity, request time, and request API path of the access request; the log hash value is generated based on the requester, request time, request content, and response data of the request log.

[0014] Secondly, the present invention also provides a security management device for API requests, comprising: a generation and verification unit, configured to receive access requests from API consumers via an API gateway, generate a request hash value for the access request, and invoke a smart contract deployed on a blockchain network to perform permission verification on the request hash value; a forwarding and verification unit, configured to forward the access request to an API server if the permission verification passes; receive response data and the corresponding response hash value from the API server; perform hash calculation on the received response data and compare the calculation result with the received response hash value; and forward the response data to the API consumer after the verification passes; and a generation and storage unit, configured to generate a log hash value for the request log after the access request is processed, and send the log hash value to the blockchain network for storage, so as to achieve tamper-proof evidence storage and traceability of the request log.

[0015] Thirdly, the present invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the method described in the first aspect.

[0016] Fourthly, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the method described in the first aspect.

[0017] This invention provides a secure API request management method, comprising: an API gateway receiving an access request from an API consumer, generating a request hash value for the access request, and invoking a smart contract deployed on a blockchain network to verify the access rights of the request hash value; if the access rights verification is successful, forwarding the access request to the API server; receiving response data and the corresponding response hash value from the API server; performing hash calculation on the received response data and comparing the calculation result with the received response hash value; after successful verification, forwarding the response data to the API consumer; after the access request is processed, generating a log hash value for the request log and sending the log hash value to the blockchain network for storage, thereby achieving tamper-proof evidence storage and traceability of the request log. As described above, this invention's secure API request management method, by introducing smart contracts to achieve decentralized authentication, fundamentally avoids the complexity and single-point-of-failure risk of centralized key management; through an end-to-end data verification mechanism based on hash comparison, ensures the integrity and authenticity of the response data during transmission; and finally, by anchoring the log hash value to the blockchain, utilizing its immutability, constructing a trusted audit and traceability chain. The solution ultimately forms an automated and highly reliable API security protection system that runs through the entire process of pre-authentication, in-process verification, and post-audit. It significantly improves the system's reliability, transparency, and security level, and alleviates the technical problems of traditional API interface security solutions, such as complex key management, high risk of single point of failure, difficulty in ensuring data integrity, and easy tampering of logs. Attached Figure Description

[0018] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 is a flowchart of the API request security management method provided in an embodiment of the present invention; Figure 2 is a schematic diagram of the API request security management process provided in an embodiment of the present invention; Figure 3 is a schematic diagram of the API request security management device provided in an embodiment of the present invention; Figure 4 is a schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0020] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Traditional API security solutions suffer from complex key management, high risk of single point of failure, difficulty in ensuring data integrity, and easy log tampering.

[0022] Based on this, the API request security management method of the present invention utilizes blockchain technology to achieve decentralized permission authentication of API interfaces, avoiding single points of failure; it reduces management complexity by automating permission verification and log recording through smart contracts; it introduces a hash value comparison mechanism for end-to-end data integrity verification; it significantly improves the security of API interfaces, effectively preventing key leakage and unauthorized access; it simplifies the security management process and improves management efficiency; it ensures that data is not tampered with during transmission, and constructs a trusted audit traceability chain through the immutability of blockchain, significantly improving the reliability, transparency, and security level of the system.

[0023] To facilitate understanding of this embodiment, a detailed description of an API request security management method disclosed in this embodiment of the invention will be provided first.

[0024] Example 1: According to an embodiment of the present invention, an embodiment of a security management method for API requests is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0025] Figure 1 is a flowchart of a security management method for API requests according to an embodiment of the present invention. As shown in Figure 1, the method includes the following steps: Step S102, the API gateway receives the access request from the API consumer, generates the request hash value of the access request, and calls the smart contract deployed on the blockchain network to verify the permission of the request hash value; The following is an introduction to some concepts involved in the present invention: API (Application Programming Interface): An application programming interface refers to a predefined protocol for interaction between different components in a software system, which allows a software application to access the functions of another software application through a specific request format.

[0026] Blockchain is a distributed database that consists of a series of data blocks linked together in chronological order to form a specific data structure, and is a distributed ledger that is cryptographically guaranteed to be immutable and unforgeable.

[0027] Smart contracts are automated contracts deployed on a blockchain that can automatically execute contract terms when preset conditions are met, without the need for third-party intervention.

[0028] An API Gateway is an intermediary layer located between the client (API consumer) and the server (API server), responsible for handling all API requests, including authentication, traffic control, and protocol conversion.

[0029] Hash value: A hash function converts an input of arbitrary length (such as data, text, etc.) into a fixed-length output value, often used for data integrity verification.

[0030] This invention is applicable to any internet service that uses API interfaces, such as e-commerce platforms, financial services, and IoT platforms. The system consists of four parts: an API server, an API consumer, a blockchain network, and smart contracts. The API server provides services through an API gateway, and the API consumer accesses these services through requests. The blockchain network acts as a trust intermediary, storing access permission information and request logs for the API interfaces, while the smart contracts are used to automate permission verification and logging.

[0031] The above request hash value is generated based on the requester's identity, request time, and request API path.

[0032] The process will be described in detail below, and will not be repeated here.

[0033] Step S104: If the permission verification is successful, the access request is forwarded to the API server; the response data and corresponding response hash value from the API server are received; the received response data is hashed, and the calculation result is compared with the received response hash value; after the verification is successful, the response data is forwarded to the API consumer; Step S106: After the access request is processed, the log hash value of the request log is generated, and the log hash value is sent to the blockchain network for storage to achieve tamper-proof evidence storage and traceability of the request log.

[0034] Specifically, the above log hash value is generated based on the requester, request time, request content, and response data of the request log.

[0035] This invention provides a secure API request management method, comprising: an API gateway receiving an access request from an API consumer, generating a request hash value for the access request, and invoking a smart contract deployed on a blockchain network to verify the access rights of the request hash value; if the access rights verification is successful, forwarding the access request to the API server; receiving response data and the corresponding response hash value from the API server; performing hash calculation on the received response data and comparing the calculation result with the received response hash value; after successful verification, forwarding the response data to the API consumer; after the access request is processed, generating a log hash value for the request log and sending the log hash value to the blockchain network for storage, thereby achieving tamper-proof evidence storage and traceability of the request log. As described above, this invention's secure API request management method, by introducing smart contracts to achieve decentralized authentication, fundamentally avoids the complexity and single-point-of-failure risk of centralized key management; through an end-to-end data verification mechanism based on hash comparison, ensures the integrity and authenticity of the response data during transmission; and finally, by anchoring the log hash value to the blockchain, utilizing its immutability, constructing a trusted audit and traceability chain. The solution ultimately forms an automated and highly reliable API security protection system that runs through the entire process of pre-authentication, in-process verification, and post-audit. It significantly improves the system's reliability, transparency, and security level, and alleviates the technical problems of traditional API interface security solutions, such as complex key management, high risk of single point of failure, difficulty in ensuring data integrity, and easy tampering of logs.

[0036] The above provides a brief overview of the API request security management method of the present invention. The specific details involved are described in detail below.

[0037] In an optional embodiment of the present invention, the smart contract is pre-configured with API access control rules defined by the API service provider. The API access control rules include at least one of the following: allowed API consumer identifiers, access time ranges, and access frequency restrictions. The smart contract returns an authentication result by verifying whether the access request corresponding to the request hash value meets the API access control rules.

[0038] In an optional embodiment of the present invention, before the API gateway receives the access request from the API consumer, the smart contract is deployed on the blockchain network through the following steps: (1) the API service provider generates smart contract code based on the API access control rules; (2) the API service provider compiles the smart contract code into bytecode; and (3) the API service provider deploys the bytecode to the blockchain network.

[0039] In an optional embodiment of the present invention, the log hash value is sent to the blockchain network for storage, specifically including the following steps: (1) encapsulating the log hash value into transaction data sent to a specific smart contract address; (2) signing the transaction data using the private key of the control account of the API gateway, and broadcasting the signed transaction to the blockchain network; (3) the nodes in the blockchain network add a new block containing the signed transaction to the blockchain through a consensus mechanism to form a request log chain.

[0040] Specifically, nodes in the blockchain network add new blocks containing transactions to the blockchain through a consensus mechanism, which includes the following steps: (31) verifying the validity of the signed transactions; (32) after verification, packaging the corresponding signed transactions together with other transactions to generate new candidate blocks; (33) based on a predefined consensus mechanism, reaching a consensus with other nodes in the blockchain network on the validity of the candidate blocks, and adding the consensus-reaching candidate blocks to the blockchain; (34) broadcasting the information of the newly added blocks to the blockchain network so that all nodes in the blockchain network can update the blockchain state synchronously.

[0041] In an optional embodiment of the present invention, the method further includes the following steps: (1) when auditing is required, query a specific log hash value from the blockchain network and obtain the complete request log stored locally; (2) calculate the hash value of the obtained request log and compare it with the log hash value queried from the blockchain network. If they match, the obtained request log is confirmed to be complete and trustworthy.

[0042] The following describes the API request security management method of the present invention, as shown in Figure 2: S1: The API service provider first needs to define the rules of the smart contract (i.e., API access control rules), clarifying which API consumers have the right to access the interface, the time range of access, frequency restrictions, etc. Then, the smart contract code is written using Solidity or other supported programming languages, including business logic such as whether the requester is on the allowed list and whether the request time is within the valid range. After writing, the smart contract is compiled into bytecode using a compiler. Next, the smart contract (i.e., bytecode) is deployed on the test network and tested to ensure that its functions are correct and there are no security vulnerabilities. Once the smart contract passes the test (i.e., bytecode), it can be deployed to the actual blockchain network to create and run custom program logic on the blockchain. The deployment steps are the same as S8 and S9.

[0043] S2: The API consumer initiates an access request to the API gateway (i.e., the request in Figure 2). The access request includes information such as the requester's identity, request time, and request API path.

[0044] S3: After receiving an access request, the API gateway generates a request hash value containing information such as the requester's identity, request time, and requested API path, and sends the generated request hash value to the blockchain network. The steps for sending to the blockchain network are the same as in S8 and S9.

[0045] S4: Smart contracts on the blockchain network verify the permissions of the request hash value according to predefined rules (such as whether the requester is on the allowed list, whether the request time is within the valid range, i.e. API access control rules).

[0046] S5: The smart contract returns the verification result to the API gateway. If the verification is successful, the API gateway forwards the access request to the API server (i.e., the API service provider in Figure 2). If the verification fails, the access request is rejected and an error message is returned.

[0047] S6: After processing the access request, the API server performs a hash calculation on the response data to obtain the response hash value, and returns the response data together with the response hash value to the API gateway.

[0048] S7: When the API gateway receives response data from the API server, it uses a predefined hash algorithm (such as SHA-256, MD5, etc.) to hash the response data, obtaining a new response hash value, and then compares it with the received response hash value. Simultaneously, it can perform other integrity checks on the response data, such as checking whether the response data length and format meet expectations. If all checks are consistent, the API gateway can trust the response data and forward it to the API consumer; otherwise, the API gateway will take measures, such as logging, issuing alerts, or rejecting the response, to ensure security.

[0049] S8: After an API access request is completed, the API gateway will generate a request log (i.e., the log information in Figure 2) containing request details (such as the requester, request time, request content, response result, etc.), perform integrity verification on the request log (such as calculating the hash value of the request log), obtain the log hash value, and send the log hash value to the blockchain network.

[0050] Send to blockchain network: Connect to blockchain node: The API gateway establishes a connection with the blockchain network through a pre-configured blockchain network node address.

[0051] Constructing transaction data: Encapsulate the log hash value into the data portion of a transaction (i.e., transaction data). Transaction data typically includes the following field: from: the address of the account initiating the transaction (the control account of the API gateway).

[0052] to: The account address receiving the transaction (a smart contract address used to receive and process log hash values).

[0053] value: Transaction amount (usually 0, because it is just sending data).

[0054] data: The actual data to be sent (i.e., the log hash value).

[0055] Transaction signing: Transaction data is signed using the API gateway's control account private key to ensure its legitimacy and authenticity. The signing process involves converting the transaction data into a hash value and then encrypting that hash value using the private key.

[0056] Broadcast transactions: The API gateway broadcasts the signed transaction to multiple nodes in the blockchain network. These nodes receive and verify the validity of the transaction.

[0057] S9: The blockchain network adds the log hash value to a new block, forming an immutable log chain.

[0058] Transaction Reception and Verification: When nodes in the blockchain network receive a signed transaction broadcast by the API gateway, they first verify the validity of the signed transaction. This includes verifying the signature of the signed transaction, checking the legality of the transaction data (such as whether the hash value meets the format requirements), and ensuring that the sender's account has sufficient balance (although in the scenario of sending log hash values, the transaction amount is usually 0).

[0059] Block Construction: Once a signed transaction is verified as valid, the node attempts to include it in a new block (i.e., a new candidate block). This block contains multiple transactions (including log hash transactions) and the hash of the previous block (used to maintain blockchain continuity). The node also generates a unique hash value for the new block (i.e., the block hash), which serves as the unique identifier for the new block.

[0060] Consensus Mechanism: In order to add a new block to the blockchain, nodes need to reach a consensus. This is typically achieved through a consensus mechanism such as Proof-of-Work (PoW), Proof-of-Stake (PoS), or Delegated Proof-of-Stake (DPoS). Under these mechanisms, nodes need to compete or vote to decide which new block should be added to the blockchain.

[0061] Adding a new block: Once a new block is agreed upon by the nodes in the network and added to the blockchain, it becomes part of the blockchain. This means that the log hash value has been securely stored on the blockchain and is closely linked to previous blocks through hash values, forming an immutable log chain.

[0062] Broadcasting and Synchronization: Finally, the node broadcasts the new block information to other nodes in the network to ensure that the entire network can update and synchronize the latest blockchain state in a timely manner. This way, any node can access and verify the log hash value information at any time.

[0063] S10: When it is necessary to trace a specific access request, the API gateway or auditing agency can query the blockchain network for the log hash value of that access request (i.e., a specific log hash value). Based on the retrieved log hash value, the original log information (i.e., the request log) is retrieved from local storage. The retrieved original log information is then subjected to integrity verification (such as recalculating the hash value of the log information and comparing it with the retrieved hash value) to ensure the authenticity and integrity of the log information.

[0064] Example 2: This embodiment of the invention also provides an API request security management device, which is mainly used to execute the API request security management method provided in Example 1 of the invention. The following is a detailed description of the API request security management device provided in this embodiment of the invention.

[0065] Figure 3 is a schematic diagram of an API request security management device according to an embodiment of the present invention. As shown in Figure 3, the device mainly includes: a generation and verification unit 10, a forwarding and verification unit 20, and a generation and storage unit 30. The generation and verification unit 10 is used for the API gateway to receive access requests from API consumers, generate a request hash value for the access request, and call a smart contract deployed on the blockchain network to verify the permission of the request hash value. The forwarding and verification unit 20 is used for forwarding the access request to the API server if the permission verification is successful; receiving response data and the corresponding response hash value from the API server; performing hash calculation on the received response data and comparing the calculation result with the received response hash value; and forwarding the response data to the API consumer after successful verification. The generation and storage unit 30 is used for generating a log hash value for the request log after the access request processing is completed, and sending the log hash value to the blockchain network for storage, so as to achieve tamper-proof evidence storage and traceability of the request log.

[0066] This invention provides a secure management device for API requests, comprising: an API gateway receiving access requests from API consumers, generating a request hash value for the access request, and invoking a smart contract deployed on a blockchain network to verify the access rights of the request hash value; if the access rights verification is successful, forwarding the access request to the API server; receiving response data and the corresponding response hash value from the API server; performing hash calculation on the received response data and comparing the calculation result with the received response hash value; after successful verification, forwarding the response data to the API consumer; and generating a log hash value for the request log after the access request is processed, and sending the log hash value to the blockchain network for storage, thereby achieving tamper-proof evidence storage and traceability of the request log. As described above, the secure management device for API requests of this invention, by introducing smart contracts to achieve decentralized authentication, fundamentally avoids the complexity and single-point-of-failure risk of centralized key management; through an end-to-end data verification mechanism based on hash comparison, it ensures the integrity and authenticity of the response data during transmission; and finally, by anchoring the log hash value to the blockchain, it utilizes its immutability to construct a trusted audit and traceability chain. The solution ultimately forms an automated and highly reliable API security protection system that runs through the entire process of pre-authentication, in-process verification, and post-audit. It significantly improves the system's reliability, transparency, and security level, and alleviates the technical problems of traditional API interface security solutions, such as complex key management, high risk of single point of failure, difficulty in ensuring data integrity, and easy tampering of logs.

[0067] Optionally, the smart contract has pre-defined API access control rules, which include at least one of the following: allowed API consumer identifiers, access time ranges, and access frequency restrictions. The smart contract returns the authentication result by verifying whether the access request corresponding to the request hash value meets the API access control rules.

[0068] Optionally, the device is also used for: API service providers generating smart contract code based on API access control rules; API service providers compiling the smart contract code into bytecode; and API service providers deploying the bytecode to the blockchain network.

[0069] Optionally, the generation and storage unit 30 is also used to: encapsulate the log hash value into transaction data sent to a specific smart contract address; sign the transaction data using the private key of the API gateway's control account, and broadcast the signed transaction to the blockchain network; and have nodes in the blockchain network add a new block containing the signed transaction to the blockchain through a consensus mechanism to form a request log chain.

[0070] Optionally, the generation and storage unit 30 is also used to: verify the validity of the signed transaction; after verification, package the corresponding signed transaction with other transactions to generate a new candidate block; based on a predefined consensus mechanism, reach a consensus with other nodes in the blockchain network on the validity of the candidate block, and add the consensus-reaching candidate block to the blockchain; and broadcast the newly added block information to the blockchain network so that all nodes in the blockchain network can synchronously update the blockchain state.

[0071] Optionally, the device is also used to: when auditing is required, query a specific log hash value from the blockchain network and obtain the complete request log stored locally; calculate the hash value of the obtained request log and compare it with the log hash value queried from the blockchain network; if they match, confirm that the obtained request log is complete and trustworthy.

[0072] Optionally, the request hash value is generated based on the requester's identity, request time, and request API path of the access request; the log hash value is generated based on the requester, request time, request content, and response data of the request log.

[0073] The device provided in this embodiment of the invention has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0074] As shown in Figure 4, an electronic device 600 provided in this application embodiment includes: a processor 601, a memory 602, and a bus. The memory 602 stores machine-readable instructions executable by the processor 601. When the electronic device is running, the processor 601 communicates with the memory 602 via the bus. The processor 601 executes the machine-readable instructions to perform the steps of the security management method as described above in the API request.

[0075] Specifically, the memory 602 and processor 601 mentioned above can be general-purpose memory and processor, without any specific limitations. When the processor 601 runs the computer program stored in the memory 602, it can execute the security management method for the API request mentioned above.

[0076] The processor 601 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 601 or by instructions in software form. The processor 601 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 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 602, and processor 601 reads the information from memory 602 and, in conjunction with its hardware, completes the steps of the above method.

[0077] Corresponding to the above-described security management method for API requests, this application embodiment also provides a computer-readable storage medium storing machine-executable instructions. When the machine-executable instructions are invoked and executed by a processor, the machine-executable instructions cause the processor to perform the steps of the above-described security management method for API requests.

[0078] The API request security management device provided in this application embodiment can be specific hardware on the device or software or firmware installed on the device. The device provided in this application embodiment has the same implementation principle and technical effects as the foregoing method embodiments. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the foregoing method embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0079] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0080] For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0081] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0082] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0083] If the aforementioned functions are implemented as 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 this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the API request security management method described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0084] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0085] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A method for secure management of API requests, characterized in that, include: The API gateway receives access requests from API consumers, generates a request hash value for the access request, and calls a smart contract deployed on the blockchain network to verify the permissions of the request hash value. If the permission verification is successful, the access request is forwarded to the API server; the response data and corresponding response hash value from the API server are received; the received response data is hashed, and the calculation result is compared with the received response hash value; After successful verification, the response data is forwarded to the API consumer. After the access request is processed, a log hash value for the request log is generated and sent to the blockchain network for storage, so as to achieve tamper-proof evidence storage and traceability of the request log.

2. The method according to claim 1, characterized in that, The smart contract is pre-configured with API access control rules defined by the API service provider. These rules include at least one of the following: allowed API consumer identifiers, access time ranges, and access frequency limits. The smart contract returns an authentication result by verifying whether the access request corresponding to the request hash value meets the API access control rules.

3. The method according to claim 2, characterized in that, Before the API gateway receives access requests from API consumers, the smart contract is deployed on the blockchain network through the following steps: the API service provider generates smart contract code based on the API access control rules; The API service provider compiles the smart contract code into bytecode; the API service provider then deploys the bytecode to the blockchain network.

4. The method according to claim 1, characterized in that, Sending the log hash value to the blockchain network for storage includes: encapsulating the log hash value into transaction data destined for a specific smart contract address; signing the transaction data using the private key of the API gateway's control account, and broadcasting the signed transaction to the blockchain network; and nodes in the blockchain network adding a new block containing the signed transaction to the blockchain through a consensus mechanism to form a request log chain.

5. The method according to claim 4, characterized in that, Nodes in the blockchain network add a new block containing the transaction to the blockchain through a consensus mechanism, including: verifying the validity of the signed transaction; after successful verification, packaging the corresponding signed transaction with other transactions to generate a new candidate block; reaching a consensus with other nodes in the blockchain network on the validity of the candidate block based on a predefined consensus mechanism, and adding the consensus-reaching candidate block to the blockchain; and broadcasting the newly added block information to the blockchain network so that all nodes in the blockchain network can synchronously update the blockchain state.

6. The method according to claim 1, characterized in that, The method further includes: when auditing is required, querying a specific log hash value from the blockchain network and obtaining the complete request log stored locally; calculating the hash value of the obtained request log and comparing it with the log hash value queried from the blockchain network; if they match, confirming that the obtained request log is complete and reliable.

7. The method according to claim 1, characterized in that, The request hash value is generated based on the requester's identity, request time, and request API path of the access request; the log hash value is generated based on the requester, request time, request content, and response data of the request log.

8. A security management device for API requests, characterized in that, include: The generation and verification unit is used by the API gateway to receive access requests from API consumers, generate a request hash value for the access request, and call a smart contract deployed on the blockchain network to verify the permission of the request hash value. The forwarding and verification unit is used to forward the access request to the API server if the permission verification is successful; receive response data and corresponding response hash value from the API server; perform hash calculation on the received response data and compare the calculation result with the received response hash value. After successful verification, the response data is forwarded to the API consumer. The generation and storage unit is used to generate a log hash value of the request log after the access request is processed, and send the log hash value to the blockchain network for storage, so as to realize the immutable evidence and traceability of the request log.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program thereon, characterized in that, The computer program is executed by the processor to perform the method of any one of claims 1 to 7.

Images