Method, device and electronic equipment for security management of API request, and storage medium

Abstract

The application provides an API request security management method and device, electronic equipment and storage medium, and belongs to the technical field of information security, in which, the decentralized authentication is realized by introducing the smart contract, the complexity of the centralized key management and the single-point failure risk are fundamentally avoided, the end-to-end data checking mechanism based on the hash comparison is used, the integrity and authenticity of the response data in the transmission process are ensured, finally, the log hash value is anchored to the block chain, and the unforgeable characteristics are used to build a credible audit trace chain. The scheme finally forms an automatic and highly credible API security protection system throughout the whole process of the prior authentication, the middle checking and the subsequent audit, and the reliability, the transparency and the safety level of the system are significantly improved.

Description

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] Although existing technical solutions provide a certain degree of security for API interfaces, the following issues still exist: Key management is complex and prone to leakage: the process of generating, distributing, revoking and updating API keys is cumbersome, and once leaked, it may lead to unauthorized access to the service, thereby causing security risks; Data integrity is difficult to guarantee: Traditional methods are not effective in preventing data from being tampered with during transmission. Once the data is tampered with, it 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, if the API gateway is attacked or malfunctions, the entire service will become unavailable, severely impacting the stability and availability of the system.

[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 method for secure management of API requests, comprising: 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 the verification is successful, 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 realize the immutable evidence 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 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 deploys the bytecode to the blockchain network.

[0010] Further, sending the log hash value to the blockchain network for storage includes: The log hash value is encapsulated into transaction data sent to a specific smart contract address; The transaction data is signed using the private key of the control account of the API gateway, and the signed transaction is broadcast to the blockchain network. Nodes in the blockchain network add new blocks containing the signed transactions to the blockchain through a consensus mechanism, forming 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: Verify the validity of the signed transaction; Once the verification is successful, the corresponding signed transaction is packaged together with other transactions to generate a new candidate block; Based on a predefined consensus mechanism, a consensus is reached with other nodes in the blockchain network on the validity of the candidate block, and the consensus-reached candidate block is added to the blockchain; The newly added block information is broadcast 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, a specific log hash value is queried from the blockchain network, and the complete request log stored locally is obtained; The hash value of the obtained request log is calculated and compared with the log hash value queried from the blockchain network. If they match, the obtained request log is confirmed to be 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: 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; and forward the response data to the API consumer after the verification is successful. 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.

[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 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 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 can be seen from the above description, the secure management method 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; 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. 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 A flowchart illustrating the API request security management method provided in this embodiment of the invention; Figure 2 This is a schematic diagram illustrating the process of secure management of API requests provided in an embodiment of the present invention. Figure 3 A schematic diagram of an API request security management device provided in an embodiment of the present invention; Figure 4 This 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 This is a flowchart of a security management method for API requests according to an embodiment of the present invention, such as... Figure 1 As shown, 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 section will first introduce some concepts involved in this invention: API (Application Programming Interface): An application programming interface is a predefined protocol for interaction between different components in a software system, allowing one software application to access the functionality 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, a log hash value of the request log is generated and sent to the blockchain network for storage, so as to realize the immutable 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 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 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 can be seen from the above description, the secure management method 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; 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.

[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) API service providers generate smart contract code based on API access control rules; (2) The API service provider compiles the smart contract code into bytecode; (3) API service providers deploy bytecode to the blockchain network.

[0039] In an optional embodiment of the present invention, sending the log hash value to a blockchain network for storage specifically includes the following steps: (1) Encapsulate the log hash value into transaction data sent to a specific smart contract address; (2) Use the private key of the API gateway's control account to sign the transaction data and broadcast the signed transaction to the blockchain network; (3) Nodes in the blockchain network add new blocks containing signed transactions to the blockchain through a consensus mechanism, forming a request log chain.

[0040] Specifically, nodes in a blockchain network add new blocks containing transactions to the blockchain through a consensus mechanism, which includes the following steps: (31) Verify the validity of the signed transaction; (32) After verification, the corresponding signed transaction is packaged together with other transactions to generate a new candidate block; (33) Based on a predefined consensus mechanism, reach a consensus with other nodes in the blockchain network on the validity of candidate blocks, and add the consensus-reaching candidate blocks to the blockchain; (34) Broadcast the newly added block information to the blockchain network so that all nodes of 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 the 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 section further describes the API request security management method of this invention, such as... Figure 2 As shown: S1: API service providers first need 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 for access, frequency limits, etc. Then, they write the smart contract code 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 a testnet and tested to ensure its functionality is 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 in S8 and S9.

[0043] S2: The API consumer initiates an access request to the API gateway (i.e., ... Figure 2 The request contains information such as the requester's identity, the request time, and the requested 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 passes, the API gateway forwards the access request to the API server (i.e., ...). Figure 2 (API service provider in the system); if 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 length and format of the response data 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 containing request details (such as the requester, request time, request content, response result, etc.). Figure 2 The system retrieves the log information from the request log, performs integrity verification on the log (such as calculating the hash value of the request log), obtains the log hash value, and then sends the log hash value to the blockchain network.

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

[0051] Constructing transaction data: Encapsulating the log hash value into a data portion of a transaction (i.e., transaction data). Transaction data typically includes the following fields: from: The address of the account that initiated 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 invention also provides an API request security management device, which is mainly used to execute the API request security management method provided in Embodiment 1 of this invention. The following is a detailed description of the API request security management device provided in this invention.

[0065] Figure 3 This is a schematic diagram of an API request security management device according to an embodiment of the present invention, such as... Figure 3 As shown, the device mainly includes: a generation and verification unit 10, a forwarding and verification unit 20, and a generation and storage unit 30, wherein: The generation and verification unit 10 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 20 is used to forward the access request to the API server if the permission verification is successful; receive the 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; and forward the response data to the API consumer after the verification is successful. The generation and storage unit 30 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.

[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] like Figure 4 As shown in the embodiment of this application, an electronic device 600 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, and 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. The processor 601 reads the information in 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. The request hash value is generated based on the identity of the requester, the request time, and the request API path. 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 realize the immutable evidence and traceability of the request log; 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 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.

2. The method according to claim 1, 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 deploys the bytecode to the blockchain network.

3. The method according to claim 1, characterized in that, Sending the log hash value to the blockchain network for storage includes: The log hash value is encapsulated into transaction data sent to a specific smart contract address; The transaction data is signed using the private key of the control account of the API gateway, and the signed transaction is broadcast to the blockchain network. Nodes in the blockchain network add new blocks containing the signed transactions to the blockchain through a consensus mechanism, forming a request log chain.

4. The method according to claim 3, characterized in that, Nodes in the blockchain network add a new block containing the transaction to the blockchain through a consensus mechanism, including: Verify the validity of the signed transaction; Once the verification is successful, the corresponding signed transaction is packaged together with other transactions to generate a new candidate block; Based on a predefined consensus mechanism, a consensus is reached with other nodes in the blockchain network on the validity of the candidate block, and the consensus-reached candidate block is added to the blockchain; The newly added block information is broadcast to the blockchain network so that all nodes in the blockchain network can synchronously update the blockchain state.

5. The method according to claim 1, characterized in that, The method further includes: When auditing is required, a specific log hash value is queried from the blockchain network, and the complete request log stored locally is obtained; The hash value of the obtained request log is calculated and compared with the log hash value queried from the blockchain network. If they match, the obtained request log is confirmed to be complete and reliable.

6. The method according to claim 1, characterized in that, The log hash value is generated based on the requester, request time, request content, and response data of the request log.

7. 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 request hash value is generated based on the requester's identity, request time, and request API path of the access request. 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; 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 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.

8. 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 6.

9. 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 6.

Images