Method for safely issuing multi-level API (Application Program Interface) service interface

Abstract

The invention relates to the technical field of information security, and particularly discloses a multi-level API (Application Program Interface) service interface security publishing method, which comprises the following steps of: establishing a unique coding system, and distributing a unique AppID (Application Platform Identifier) containing administrative level information for each application system and a security networking gateway; the trusted access control system constructs a registration and management mechanism based on AppID; establishing a multi-level routing mechanism based on the allocated AppID, and performing hierarchical forwarding according to requests of different levels; a signature-based interface authentication mechanism is started in combination with AppID, an AppID key, a random number and a timestamp; and finally, performing hierarchical security access control based on the allocated AppID. By adopting the method for safely releasing the multi-level API service interface, the problems of difficulty in releasing the API interface, weak authentication, complex routing and the like under a multi-level framework are solved, the integration of unified identification, intelligent routing, safety authentication and level management and control is realized, the flexibility, the safety and the expandability of the system are improved, and the safety of the system is improved. The method is suitable for multi-level network environments such as government affairs and large organizations.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information security, and in particular to a method for safe publishing of multi-level API service interfaces. BACKGROUND

[0002] In the informatization system of a large organization, there are a large number of data interaction requirements between different departments or nodes. In order to realize communication between heterogeneous systems in different places, the existing technology usually adopts multiple ways to publish and call API interfaces: Traditional VPN / dedicated line connection scheme: cross-network system communication relies on VPN tunnel or physical dedicated line for interconnection, and on this basis, the target system IP and interface path are manually configured. This scheme is complicated in network configuration, and has high deployment and maintenance cost; it relies on fixed IP and lacks flexibility; it cannot cope with dynamically adjusted nodes or interfaces, and has poor scalability. Static API registration and calling: some systems register API documents through a platform, and the interface path and parameter format are maintained by administrators, and the calling party accesses through hard coding or configuration. This way lacks an automatic registration mechanism, has high maintenance cost; lacks a unique identification mechanism, and has serious interface conflict and duplicate naming problems; lacks version management and interface state management (such as activation / disuse) capabilities. General API gateway (such as Kong, Apigee, Zuul, etc.): in enterprise applications, some cloud-native architectures introduce API gateways for traffic control, authentication, rate limiting, etc. However, these systems are based on homogeneous and same-layer environments, and the design intention is biased towards internal calling scenarios of microservices. They are not suitable for complex network structures under multi-level and isolated network segments in government affairs, etc.; lack a location-aware coding system (such as AppID) for hierarchical addressing; lack data forwarding mechanisms and permission control mechanisms between cross-layer nodes. Simple token or account password authentication mechanism: the current interface authentication methods of many systems are still at the initial stage of token, BasicAuth, APIKey, etc. Lack of tamper-proofing and anti-replay mechanisms, there are great security risks; the interface cannot distinguish the system identity of the calling party, and lacks a trusted authentication based on the "system-system" dimension; cannot support one-time signature, two-way authentication and other higher-level security requirements. In summary, the main problems of the prior art include interface addressing confusion, dependence on domain name / IP manual maintenance, lack of unified coding identification system, inability to accurately locate target services; registration and management are not unified, lack of standard interface registration and management platform, life cycle management is missing, interface version and state are difficult to track; cross-level routing mechanism is missing, at multiple levels of nodes, interfaces cannot be automatically routed or forwarded according to levels; the security of the authentication mechanism is insufficient, and the existing authentication scheme is easy to be forged, and mechanisms such as complete signature verification, timestamp verification, and anti-replay are not implemented; the API platform is not adapted to the multi-level government architecture, and the general API gateway product does not consider regional / administrative level division, and it is difficult to land in government or isolated network environments. SUMMARY

[0003] The purpose of the present application is to provide a multi-level API service interface security publishing method, which aims to solve the problems of API service interface publishing difficulty, weak authentication, and complex routing in the prior art, and to provide a multi-level API service interface security publishing method and system with unified identification management, intelligent routing, and secure authentication mechanism, thereby improving the automation, controllability, and security of the system.

[0004] To achieve the above-mentioned purpose, the present application provides a multi-level API service interface security publishing method, comprising the following steps: S1, a unique coding system is established, and a unique AppID containing administrative level information is allocated to each application system and secure networking gateway; S2, a registration and management mechanism is constructed based on the AppID by a trusted access control system; S3, a multi-level routing mechanism is established based on the AppID allocated in S1, and hierarchical forwarding is performed according to requests of different levels; S4, a signature-based interface authentication mechanism is enabled in combination with the AppID, AppID secret key, random number, and timestamp; S5, hierarchical security access control is performed based on the AppID allocated in S1.

[0005] Preferably, in S1, the AppID is a 16-bit code, the first 10 bits represent the system administrative position representing the administrative level, and the last 6 bits represent the system number, wherein the system number of the secure networking gateway is 000000.

[0006] Preferably, S2 is specifically: When the application system and the secure networking gateway access, the interface registration is completed through the trusted access control system; after successful registration, the trusted access control system allocates a unique AppID and the corresponding AppID secret key to the application system and the secure networking gateway; The secure networking gateway obtains all AppID secret keys and constructs a global AppID secret key table for interface authentication; The trusted access control system performs full life cycle management on the registered application system and the secure networking gateway, including system information updating and state monitoring.

[0007] Preferably, S3 is specifically: Each secure networking gateway is internally provided with an AppID routing rule table, which is generated by the trusted access control system according to the administrative level topology structure and is periodically synchronized to each secure networking gateway; the AppID routing rule table includes routing path information corresponding to different administrative levels; When the secure networking gateway receives an interface request, the source AppID (X-SRP-SRCAPPID) and the target AppID (X-SRP-DSTAPPID) carried in the request header are extracted; The secure networking gateway compares the first 10 digits of the target AppID with the first 10 digits of its own AppID: If they are consistent, it is determined that the request is of the same level, and the request is directly forwarded to the corresponding application system for processing; If they are inconsistent, it is determined that the request is cross-level, and according to the administrative level information of the target AppID, the request is transferred to the upper gateway or the gateway of the target level through the preset routing path, and then forwarded to the corresponding application system by the upper gateway or the target gateway.

[0008] Preferably, S4 specifically includes the following steps: S41, before sending the request, the application system generates a signature X-SRP-SIGN using the HMAC-SM3 algorithm in combination with its own AppID (X-SRP-SRCAPPID), its own AppID secret key, the target AppID (X-SRP-DSTAPPID), a random number and a timestamp, and the format of X-SRP-SIGN is: random number + timestamp + HMAC-SM3; S42, the application system transmits the authentication information field including X-SRP-SRCAPPID, X-SRP-DSTAPPID and X-SRP-SIGN through the HTTPHeader; S43, after receiving the request, the secure networking gateway extracts the authentication information in the HTTPHeader, first judges whether the timestamp in X-SRP-SIGN is expired, if it is expired, the request is directly rejected, if it is not expired, the HMAC-SM3 signature is regenerated using the same algorithm and parameters, and compared with the received signature: If they are consistent, the verification is passed, ensuring that the request source is traceable, the content is not tampered with and the request is not repeated; if they are inconsistent, the request is rejected.

[0009] Preferably, in S5, the secure networking gateway performs access control on the interface request based on the AppID according to the security policy preset by the trusted access control system: When it is monitored that the system of a certain machine room is intruded, an emergency blocking strategy is adopted to prohibit all requests from the AppID corresponding to the system of the machine room from entering the network; For a certain application system, a hierarchical permission control strategy is adopted to allow only the request from the AppID corresponding to the central hierarchical system to be called, and the requests from other hierarchical AppIDs are all rejected.

[0010] Therefore, the application adopts the above-mentioned method for secure publishing of a multi-level API service interface, and has the following beneficial effects: (1) The application realizes unique positioning of any node interface through the combination of the position information and the system number in the AppID code; the data request between systems can be intelligently judged for routing path according to the AppID, and is automatically forwarded between the central, provincial, municipal, and county nodes, without relying on static IP or VPN configuration, thereby greatly improving the flexibility and scalability of the system, greatly simplifying the service docking process between cross-regional and cross-network systems, and realizing unified addressing and rapid docking. (2) The application adopts the request authentication mechanism of generating a signature by using a domestic encryption algorithm such as HMAC-SM3, which can effectively prevent data from being tampered with or forged; the time stamp and random number mechanism are introduced to resist replay attacks; the authentication parameter design in the form of HTTPHeader facilitates system access and extension; at the same time, there is no direct call between application systems, and all requests are made through the secure networking gateway, thereby avoiding leakage of IP and port information of the application system; thus, a strong identity authentication mechanism based on system-to-system is constructed to meet the demand for high security standards in government affairs and sensitive scenarios. (3) The secure networking gateway in the application can judge whether the request is a same-level route by comparing the first 10 bits of the AppID itself and the target AppID; the same-level request is processed by the local application system, and the cross-level request is transferred to the target gateway, and the routing logic can adapt to changes in the hierarchical topology structure and support dynamic expansion; this mechanism improves the forwarding efficiency and accuracy of interface calls, and reduces human configuration errors and network maintenance pressure. (4) All application systems in the application must complete registration and identity binding through the trusted access control system, the system uniformly manages the whole life cycle of the AppID, including creation, change, offline, and abandonment, and simultaneously realizes standardization of the whole process of interface publishing, permission allocation, and access control, thereby reducing the difficulty of operation and maintenance, and improving the visibility, standardization, and security of interface resource management. (5) The platform architecture of the application adopts modular design, covers components such as gateway, registration center, coding system, routing service, and can be flexibly combined; the coding system, authentication mechanism and gateway behavior can adapt to different organizational structures and permission models, and can be widely popularized and applied in industries such as government affairs, medical treatment, finance and electric power. From the perspective of solving multiple levels and applications with a set of platform, it has high promotion and reuse value, and can bring significant social and economic benefits. (6) All operations such as routing, authentication and response in the interface calling process of the application are uniformly recorded, which provides original basis for subsequent audit, security tracking and performance analysis, improves the transparency and compliance of the system, and facilitates fault troubleshooting and security supervision.

[0011] The technical solutions of the application will be further described in detail below with the help of drawings and examples. BRIEF DESCRIPTION OF DRAWINGS

[0012] Figure 1 is the overall architecture diagram of an embodiment of the method for safe publishing of multi-level API service interfaces of the application; Figure 2 is the overall flowchart of an embodiment of the method for safe publishing of multi-level API service interfaces of the application; Figure 3 is a cross-level request schematic diagram of an embodiment of the method for safe publishing of multi-level API service interfaces of the application; Figure 4 is a same-level request schematic diagram of an embodiment of the method for safe publishing of multi-level API service interfaces of the application. DETAILED DESCRIPTION

[0013] The technical solutions of the application will be further described in detail below with the help of drawings and examples.

[0014] Unless otherwise defined, the technical terms or scientific terms used in the application should be understood as the usual meanings understood by persons with ordinary skills in the art to which the application belongs. The terms "first", "second" and similar words used in the application do not represent any order, quantity or importance, but are only used to distinguish different components.

[0015] As shown in Figure 1 The architecture in the application includes several application systems, secure networking gateways and trusted access control systems, wherein 1-n application systems are distributed in central, provincial and municipal nodes, are business function carriers, perform government affairs handling and data query systems in government affairs scenes, undertake specific business logic, and generate and process data.

[0016] The secure networking gateway is responsible for the encryption, transmission and decryption of data messages, ensuring the security of cross-node data interaction such as tamper prevention and leakage prevention, so that different levels of application systems can communicate safely.

[0017] The trusted access control system manages the access permissions and data flow rules of the secure networking gateway of each node through control messages, ensuring that only trusted nodes and legal data can participate in collaboration, and preventing illegal access.

[0018] As shown in Figure 2 A method for secure publishing of a multi-level API service interface, comprising the following steps: S1, a unique coding system is established, and a unique AppID containing administrative level information is allocated to each application system and secure networking gateway. The AppID is a 16-bit code, the first 10 bits represent the system administrative position representing the administrative level, and the last 6 bits represent the system number. The secure networking gateway is a special application system, and its system number is special 000000. The AppID is uniformly allocated by the trusted access control system as the unique identity of the interface request and response, and is used for routing addressing, identity authentication, permission control and log auditing. Through the AppID, a unified identification and location information fusion service addressing method can be realized across domains and layers.

[0019] S2, the trusted access control system constructs a registration and management mechanism based on the AppID, specifically: When the application system and the secure networking gateway access, the interface registration is completed through the trusted access control system; after successful registration, the trusted access control system allocates a unique AppID and the corresponding AppID secret key to the application system and the secure networking gateway; the secure networking gateway also obtains all AppID secret keys and constructs a global AppID secret key table for interface authentication in S4.

[0020] Then the trusted access control system performs full life cycle management on the registered application system and secure networking gateway, including system information update and state monitoring.

[0021] S3, a multi-level routing mechanism is established based on the AppID allocated in S1, and hierarchical forwarding is performed according to different levels of requests, specifically: Each secure networking gateway has an AppID routing rule table built-in, which is generated by the trusted access control system according to the administrative level topology structure and is synchronized to each secure networking gateway periodically; the AppID routing rule table includes routing path information corresponding to different administrative levels; When the secure networking gateway receives an interface request, the source AppID X-SRP-SRCAPPID and the target AppID X-SRP-DSTAPPID carried in the request header are extracted; The security networking gateway compares the first 10 bits of the target AppID with the first 10 bits of the AppID itself: If they are consistent, it is determined that it is a same-level request, and the request is directly forwarded to the corresponding application system for processing. If they are inconsistent, it is determined that it is a cross-level request, and according to the administrative level information of the target AppID, it is transferred to the upper gateway or the gateway of the target level through the preset routing path, and then forwarded to the corresponding application system by the upper gateway or the target gateway.

[0022] Through the decoupling of the routing mechanism and the location coding, the target path can be dynamically determined without manual maintenance and configuration of the rule table. The change in the topology structure can be automatically adapted by analyzing the level identifier carried in the request, and the optimal forwarding path can be generated in real time, which can not only cope with dynamic adjustment scenarios such as node addition and migration, but also reduce configuration errors caused by manual intervention, greatly improving the flexibility and reliability of API interface routing in a multi-level network environment.

[0023] S4, in combination with AppID, AppID key, random number and timestamp, a signature-based interface authentication mechanism is enabled, specifically including the following steps: S41, before sending the request, the application system uses the HMAC-SM3 algorithm to generate a signature X-SRP-SIGN in combination with its own AppID, i.e., X-SRP-SRCAPPID, its own AppID key, the target AppID, i.e., X-SRP-DSTAPPID, a random number and a timestamp.

[0024] The format of X-SRP-SIGN is: random number + timestamp + HMAC-SM3(SRCAPPID + DSTAPPID + random number + timestamp, AppID key).

[0025] S42, the application system transmits the authentication information field through the HTTPHeader, including X-SRP-SRCAPPID, X-SRP-DSTAPPID and X-SRP-SIGN, etc., to ensure that the source of the interface request is verifiable, tamper-proof and anti-replay.

[0026] S43, after the interface receiver, including the security networking gateway or the target application system, receives the request, it extracts the authentication information in the HTTPHeader, first judges whether the timestamp in X-SRP-SIGN is expired or not, the expired time is generally 5 seconds (configurable), if it is expired, the request is directly rejected. If it is not expired, the signature is regenerated using the same algorithm and parameters, wherein the AppID key needs to be found from the AppID key table according to the source AppID, and compared with the received signature: If they are consistent, the verification is passed, ensuring that the request source is traceable, the content is not tampered with and it is not a repeated request; if they are inconsistent, the request is rejected.

[0027] S5, hierarchical security access control based on the AppID assigned in S1.

[0028] The secure networking gateway performs access control on the interface request based on the security policy preset by the trusted access control system according to the AppID: When it is monitored that the system of a certain computer room is intruded, an emergency blocking strategy is adopted to prohibit all requests from the AppID corresponding to the system of the computer room to enter the network; For a certain application system, a hierarchical permission control strategy is adopted to allow only the request from the AppID corresponding to the central hierarchical system to be called, and the requests from other hierarchical AppIDs are all rejected.

[0029] Embodiment I As shown in FIG. 1, the two-way communication between the central node application system AppID1 and the provincial node application system AppID2 is used to illustrate the cross-hierarchical request process, and the specific interaction process is as follows: Figure 3 (I) Request process from the central level to the provincial level First, the AppID1 of the central node initiates a request, the request header carries the source AppID: AppID1 and the destination AppID: AppID2, and delivers it to the secure networking gateway of the central node.

[0030] Then, after the central routing service identifies the destination AppID, i.e., AppID2, it forwards the request to the provincial node secure networking gateway through the secure networking gateway, and the provincial routing service delivers the request to the provincial destination AppID2.

[0031] After the AppID2 is processed, the response data is returned to the AppID1 along the reverse path through the provincial and central routing services, and a cross-hierarchical call is completed.

[0032] (II) Request process from the provincial level to the central level The logic of this process is opposite to the above, the AppID2 initiates a request, the request header carries the source ID: AppID2 and the destination ID: AppID1, and is forwarded through the provincial and central routing services, and the AppID1 makes a response and then returns, to achieve two-way interaction. Through the above interaction process, the two application systems across levels can transmit messages and data to each other, and realize cross-regional business cooperation.

[0033] Embodiment II As shown in FIG. 2, the data interaction between the application system 1 and the application system 2 in the same level is performed through the secure access device and the routing service, and the specific process is as follows: Figure 4 ​​Firstly, the application system 1 sends a request to the secure access device, and the request header carries a source AppID, i.e. AppID1, and a destination AppID, i.e. AppID2, and the secure access device forwards the request to the application system 2 through a routing service.

[0034] After processing, the application system 2 returns the data content to the secure access device, and the secure access device returns the data content to the application system; then, the application system 2 sends a request to the secure access device, and the request header carries a source ID, i.e. AppID2, and a destination ID, i.e. AppID1, and the request is forwarded to the application system 1 through the routing service; after processing, the application system 1 returns the data content, which is returned to the application system 2 through the secure access device.

[0035] In the same level request, the source and destination of the data are identified by carrying the source ID and the destination ID in the request header, so as to realize accurate routing and data transmission between different application systems. The secure access device plays a role in security verification and filtering, so as to guarantee the communication security; the routing service is responsible for forwarding the request and returning the data according to the request header information, so as to ensure the collaborative work and data interaction between different services or applications.

[0036] Therefore, the application adopts the above-mentioned method for safe publishing of a multi-level API service interface, realizes unified identification and accurate addressing of the multi-level system through the unique AppID, realizes the whole life cycle management relying on the trusted access control, guarantees the cross-level communication security in combination with the intelligent routing and the strong signature authentication, and strengthens the risk control by means of the hierarchical access control, so as to effectively solve the problems of publishing, authentication and routing of the API interface under the multi-level architecture, and significantly improve the system security and ease of use.

[0037] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the application but not to limit it, although the application has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the application can still be modified or replaced by equivalents, and these modifications or equivalent replacements cannot make the modified technical solutions deviate from the spirit and scope of the technical solutions of the application.

Claims

1. A method for securely publishing a multi-level API service interface, characterized in that: The following steps are involved: S1. Establish a unique coding system to assign a unique AppID containing administrative level information to each application system and secure networking gateway; S2. The trusted access control system builds a registration and management mechanism based on AppID; S3, based on the AppID assigned by S1, establishes a multi-level routing mechanism to forward requests at different levels; S4. Enable the signature-based interface authentication mechanism by combining AppID, AppID key, random number and timestamp; S5. Perform hierarchical security access control based on the AppID assigned by S1.

2. A method for securely publishing a multi-level API service interface according to claim 1, characterized in that: In S1, AppID is a 16-digit code. The first 10 digits represent the system administrative position, representing the administrative level, and the last 6 digits represent the system number. Among them, the system number of the secure network gateway is 000000.

3. A method for securely publishing a multi-level API service interface according to claim 2, characterized in that: S2 is specifically: When the application system and the secure network gateway are accessed, the interface registration is completed through the trusted access control system. After successful registration, the trusted access control system assigns a unique AppID and the corresponding AppID key to the application system and the secure network gateway. The secure networking gateway obtains all AppID keys and builds a global AppID key table for interface authentication; The trusted access control system manages the entire life cycle of registered application systems and secure networking gateways, including system information updates and status monitoring.

4. A method for securely publishing a multi-level API service interface according to claim 3, characterized in that: S3 specifically: Each secure networking gateway has a built-in AppID routing rule table. The AppID routing rule table is generated by the trusted access control system based on the administrative hierarchy topology and is regularly synchronized to each secure networking gateway. The AppID routing rule table includes routing path information corresponding to different administrative levels; When the secure networking gateway receives the interface request, it extracts the source AppID (X-SRP-SRCAPPID) and the target AppID (X-SRP-DSTAPPID) carried in the request header; The secure networking gateway compares the top 10 target AppIDs with its own AppIDs: If they match, it is determined to be a request at the same level and the request is directly forwarded to the corresponding local application system for processing; If there is any inconsistency, it is determined to be a cross-level request. According to the administrative level information of the target AppID, it is transferred to the upper-level gateway or the gateway of the target level through the preset routing path, and then forwarded to the corresponding application system by the upper-level gateway or the target gateway.

5. A method for securely publishing a multi-level API service interface according to claim 4, characterized in that: S4 specifically includes the following steps: S41. Before sending the request, the application system uses the HMAC-SM3 algorithm to combine its own AppID (i.e., X-SRP-SRCAPPID), its own AppID secret key, the target AppID (i.e., X-SRP-DSTAPPID), a random number, and a timestamp to generate a signature X-SRP-SIGN. The format of X-SRP-SIGN is: random number + timestamp + HMAC-SM3. S42. The application system transmits authentication information fields through HTTP Header, including X-SRP-SRCAPPID, X-SRP-DSTAPPID, and X-SRP-SIGN. S43. After receiving the request, the secure networking gateway extracts the authentication information in the HTTP Header and first checks whether the timestamp in the X-SRP-SIGN has expired. If so, the request is directly rejected. If not, the HMAC-SM3 signature is regenerated using the same algorithm and parameters and compared with the received signature: If they are consistent, the verification is successful, ensuring that the request source is traceable, the content has not been tampered with, and it is not a duplicate request; if they are inconsistent, the request is rejected.

6. A method for securely publishing a multi-level API service interface according to claim 5, characterized in that: In S5, the secure networking gateway performs access control on the interface request based on the AppID according to the security policy preset by the trusted access control system: When a computer room system is detected to be intruded, an emergency blocking strategy is adopted to prohibit all requests from the AppID corresponding to the computer room system from entering the network; For a certain application system, a hierarchical permission control strategy is adopted, which only allows requests from the AppID corresponding to the central level system, and rejects requests from AppIDs of other levels.

Images