An application access method and apparatus

Abstract

This application provides an application access method and apparatus, relating to the field of communication technology. The method is applied to a gateway device in a zero-trust network. It receives a first service message sent by a terminal device through a zero-trust client for accessing a web application; obtains a virtual IP address corresponding to the user token in the first service message, wherein the virtual IP address is allocated and issued to the gateway device by the controller in the zero-trust network after the terminal device successfully goes online; replaces the source IP address in the first service message with the virtual IP address to obtain a second service message; and forwards the second service message to the resource server of the web application.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to an application access method and apparatus. Background Technology

[0002] With the rise of internet technologies such as cloud computing, the Internet of Things, and mobile office, enterprise resources are no longer confined to the internal network. The need for employees to access the enterprise intranet anytime, anywhere is becoming increasingly common, blurring the traditional network protection boundaries and rendering traditional network boundary-based security measures increasingly inadequate. To address these issues, a Software Defined Perimeter (SDP) zero-trust function is provided. In this function, network devices act as SDP gateways, working in conjunction with SDP controllers to authenticate and authorize users accessing specified applications or APIs within the zero-trust network. This enables centralized control over user identity and access permissions, preventing unauthorized access.

[0003] When accessing resources within a zero-trust network, terminal devices can access non-web applications within the zero-trust network via an SSL VPN tunnel using a built-in zero-trust client, or they can access web applications within the zero-trust network using the zero-trust client. When accessing web applications using a zero-trust client, the user opens a web browser, which displays an application navigation page for accessible web applications. The user selects the desired web application from this navigation page, triggering a web access request. This request message is then sent to the SDP gateway within the zero-trust network. The SDP gateway verifies the user's identity. Upon successful verification, the SDP gateway, acting as a web proxy, sends the request message to the web application's resource server based on its own address. In other words, when many users access web applications in zero-trust client mode, the source IP address of each service packet forwarded by the SDP gateway is the SDP gateway itself. This leads to the following problem: when auditing and log analysis functions are configured in the zero-trust network, and a security risk is detected by risk identification based on the logs generated during web application access, it is impossible to know which user accessed the application on the resource server, resulting in the inability to trace the source. Summary of the Invention

[0004] In view of this, this application provides an application access method and apparatus to solve the problem of being unable to trace the source of risks when accessing web applications based on zero-trust clients, due to messages forwarded to the resource server of the web application having the same source IP address.

[0005] Specifically, this application is implemented through the following technical solution:

[0006] According to a first aspect of this application, an application access method is provided, applied to a gateway device in a zero-trust network, the method comprising:

[0007] The receiving terminal device sends the first business message for accessing the web application through a zero-trust client;

[0008] Based on the user token in the first service message, obtain the virtual IP address corresponding to the user token. The virtual IP address is assigned and distributed to the gateway device by the controller in the zero-trust network after the terminal device successfully goes online.

[0009] The source IP address in the first service message is replaced with the virtual IP address, and the destination IP address in the first service message is replaced with the IP address of the resource server of the web application to obtain the second service message;

[0010] The second service message is forwarded to the resource server of the web application.

[0011] According to a second aspect of this application, an application access device is provided, applied in a gateway device in a zero-trust network, the device comprising:

[0012] The receiving unit is used to receive the first business message sent by the terminal device through the zero-trust client for accessing the web application;

[0013] The acquisition unit is used to acquire the virtual IP address corresponding to the user token in the first service message. The virtual IP address is assigned and distributed to the gateway device by the controller in the zero-trust network after the terminal device successfully goes online.

[0014] The replacement unit is used to replace the source IP address in the first service message with the virtual IP address, and replace the destination IP address in the first service message with the IP address of the resource server of the web application to obtain the second service message;

[0015] The sending unit is used to forward the second service message to the resource server of the web application.

[0016] According to a third aspect of this application, an electronic device is provided, including a processor and a machine-readable storage medium storing a computer program executable by the processor, the processor being prompted by the computer program to perform the method provided in the first aspect of the embodiments of this application.

[0017] According to a fourth aspect of this application, a machine-readable storage medium is provided, which stores a computer program that, when invoked and executed by a processor, causes the processor to perform the method provided in the first aspect of the embodiments of this application.

[0018] The beneficial effects of the embodiments of this application are as follows:

[0019] In the application access method and apparatus provided in this application embodiment, the gateway device in the zero-trust network receives a first service message for accessing a web application sent by a terminal device through a zero-trust client; based on the user token in the first service message, it obtains the virtual IP address corresponding to the user token, replaces the destination IP address of the first service message with the IP address of the web application's resource server, where the virtual IP address is allocated and distributed to the gateway device by the controller in the zero-trust network after the terminal device successfully goes online; it replaces the source IP address in the first service message with the virtual IP address to obtain a second service message; and it forwards the second service message to the web application's resource server. Therefore, based on accessing web applications using a zero-trust client, since the source IP address of the service message arriving at the resource server is the virtual IP address corresponding to the unique user token of the user to which the terminal device belongs, and different user tokens correspond to different virtual IP addresses, the problem of being unable to trace the source of risks caused by the source IP address of the message arriving at the resource server being the IP address of the gateway device is solved. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating an application access method provided in an embodiment of this application;

[0021] Figure 2 This is a flowchart illustrating another application access method provided in an embodiment of this application;

[0022] Figure 3 This is a schematic diagram illustrating an application scenario of an application access method provided in an embodiment of this application;

[0023] Figure 4 This is a schematic diagram of the structure of an application access device provided in an embodiment of this application;

[0024] Figure 5 This is a schematic diagram of the hardware structure of an electronic device implementing an application access method, provided in an embodiment of this application. Detailed Implementation

[0025] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0026] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used herein are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the corresponding listed items.

[0027] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0028] The application access methods provided in this application are described in detail below.

[0029] See Figure 1 , Figure 1 This is a flowchart illustrating an application access method provided in this application. This application access method is also applied to gateway devices in zero-trust networks, such as SDP gateways. When implementing this method, the gateway device may include the following steps:

[0030] Step 101: Receive the first business message sent by the terminal device through the zero-trust client for accessing the web application.

[0031] In this step, the user's terminal device is equipped with a zero-trust client, which supports accessing web applications. When the user wishes to access a web application (also known as a browser application) in the zero-trust network through the zero-trust client, the zero-trust client is triggered to send the aforementioned first service message to the gateway device in the zero-trust network. The source IP address of this first service message is the IP address of the terminal device, and the destination IP address is the IP address of the gateway device.

[0032] To facilitate the gateway device's understanding of which application the terminal device is requesting access to, the first service message also carries the application identifier of the requested web application. It should be noted that this application identifier is the application identifier of the applications authorized for user access by the controller after the terminal device successfully completes controller authentication in the zero-trust network, and the controller sends the application list constructed from these authorized application identifiers to the terminal device. Furthermore, after successfully authenticating the terminal device, the controller assigns a user token to the user to which the terminal device belongs and sends it to the terminal device; additionally, while sending the above information, the controller also sends the device information of the gateway device corresponding to the applications that the user can access.

[0033] Optionally, the application list mentioned above can include both web applications and non-web applications. Based on this, when a user accesses a web application, the terminal device can obtain the corresponding gateway device based on the mapping between applications and gateway devices, and then send the aforementioned first service message to that gateway device. Furthermore, the aforementioned first service message can also carry a user token, so that the gateway device can verify the trustworthiness of the terminal device based on the user token.

[0034] Step 102: Obtain the virtual IP address corresponding to the user token based on the user token in the first service message.

[0035] The aforementioned virtual IP address is assigned by the controller in the zero-trust network to the terminal device and then sent to the gateway device after the terminal device successfully goes online.

[0036] In this step, after the gateway device receives the first service message, it can obtain the user token from the message and authenticate the user's identity based on the token. Specifically, after successfully authenticating the terminal device, the controller sends the user's token and the aforementioned application list to the gateway device corresponding to the application accessible to the user of the terminal device. The gateway device can then verify whether the user token matches the one issued by the controller. If they match, the user's authentication is successful. Next, it obtains the application identifier of the web application from the first service message and checks if it is in the application list. If it is, it confirms that the user has access rights to the web application.

[0037] Furthermore, in order to address the issue of being unable to trace the source of risks caused by packets forwarded to the resource server having the same source IP address, provided that the terminal device can successfully access the aforementioned web application, this embodiment proposes obtaining the virtual IP address corresponding to the user token.

[0038] Specifically, when the controller sends the user token and application list to the gateway device, it also sends a virtual IP address. This virtual IP address is uniquely assigned by the controller to each user belonging to the terminal device; that is, different users have different user tokens and different virtual IP addresses. Therefore, the gateway device, upon receiving the above information from the controller, can locally record the correspondence between the user token, application list, and virtual IP address. Thus, after successful authentication based on the user token and confirmation of access rights to the aforementioned web applications, it can retrieve the virtual IP address corresponding to the user token in the first service message based on the aforementioned correspondence.

[0039] Step 103: Replace the source IP address in the first service message with the virtual IP address, and replace the destination IP address in the first service message with the IP address of the resource server of the web application to obtain the second service message.

[0040] Step 104: Forward the second service message to the resource server of the web application.

[0041] In steps 103 and 104, after obtaining the virtual IP address corresponding to the user token, the source IP address can be replaced with this virtual IP address. Simultaneously, to successfully access the web application, the destination IP address of the first business message also needs to be replaced with the IP address of the web application's resource server. Then, the obtained second business message is sent to the resource server corresponding to the web application, thus enabling access to the web application. Since the source IP address of the second business message sent to the resource server is the virtual IP address corresponding to the user token, instead of the gateway device's IP address, different user tokens correspond to different virtual IP addresses. Therefore, based on this virtual IP address, the actual terminal device can be traced. Furthermore, when the resource server is configured with auditing and log analysis functions, if a security risk is identified during security risk assessment based on log data, the corresponding terminal device can be traced based on the virtual IP address in the log data. This solves the problem of being unable to trace the source of messages arriving at the resource server when the source IP address is the gateway device's IP address.

[0042] In implementing the above application access method, the gateway device in the zero-trust network receives a first service message for accessing a web application sent by a terminal device through a zero-trust client; based on the user token in the first service message, it obtains the virtual IP address corresponding to the user token, which is allocated and issued to the gateway device by the controller in the zero-trust network after the terminal device successfully goes online; it replaces the source IP address in the first service message with the virtual IP address and replaces the destination IP address of the first service message with the IP address of the web application's resource server to obtain a second service message; and it forwards the second service message to the web application's resource server. Therefore, based on accessing web applications using a zero-trust client, since the source IP address of the service message arriving at the resource server is the virtual IP address corresponding to the unique user token of the user to which the terminal device belongs, and different user tokens correspond to different virtual IP addresses, the problem of being unable to trace the source of risks caused by the source IP address of the message arriving at the resource server being the IP address of the gateway device is solved.

[0043] Optionally, the application access method provided in this embodiment may further include Figure 2 The application access process shown may include the following steps:

[0044] Step 201: Receive the first response message of the first service message from the resource server.

[0045] Specifically, when the second service message arrives at the resource server, the resource server will perform security checks based on the second service message and generate log data. The log data can record the five-tuple information in the second service message so as to facilitate tracing based on the log data.

[0046] Furthermore, after performing a security check, if the security check passes, the resource server can respond to the second service message and receive the first response message; then, it sends the first response message to the gateway device. The source IP address of the first response message is the resource server's IP address, and the destination IP address is the source IP address in the second service message, i.e., the virtual IP address.

[0047] Step 202: Replace the destination IP address in the first response message with the source IP address in the first service message, and replace the source IP address in the first response message with the IP address of the gateway device to obtain the second response message.

[0048] Step 203: Forward the second response message to the terminal device.

[0049] In steps 202 and 203, after receiving the first response message, the gateway device can replace the destination IP address in the first response message to ensure accurate delivery to the terminal device. Specifically, it replaces the destination IP address in the first response message with the source IP address in the first service message, i.e., the IP address of the terminal device, and simultaneously replaces the source IP address of the first response message with the IP address of the gateway device, thus obtaining the second response message. In this way, when the gateway device forwards the second response message to the terminal device, it can ensure that the second response message successfully reaches the terminal device, thereby obtaining the response from the resource server to the terminal device.

[0050] Optionally, this embodiment proposes that after executing step 104, the following process can also be performed: binding the correspondence between the first session to which the first service message belongs and the second session to which the second service message belongs.

[0051] Specifically, since this application involves IP address replacement during application access, this embodiment proposes to record sessions to accurately locate the replaced IP address. Specifically, the session to which the first service message belongs is recorded as Session 1, which is the session between the terminal device and the gateway device for accessing the web application. Simultaneously, the session between the gateway device and the resource server accessing the web application as a proxy is recorded as Session 2. Then, Session 1 and Session 2 are bound together. For example, different session identifiers, denoted as sessionIDs, can be set for different sessions. Based on this, a correspondence can be established between sessionID1 of the first session and sessionID2 of the second session to achieve the binding of Session 1 and Session 2.

[0052] Further, the step of replacing the destination IP address in the first response message with the source IP address in the first service message in step 202 can be performed according to the following process: based on the second session to which the first response message belongs, the corresponding relationship is retrieved to obtain the source IP address in the first service message based on the found first session; the destination IP address in the first response message is replaced with the source IP address in the first service message.

[0053] Specifically, in one embodiment, when the gateway device sends a second service message to the resource server, the second service message may carry the session identifier (sessionID2) of session 2. Thus, when the resource server generates a first response message in response to the second service message, it can carry the session identifier (sessionID2) of session 2, which is parsed from the second service message, in the first response message. After receiving the first response message, the gateway device can obtain the session identifier (sessionID2) from it and determine the session to which the first response message belongs, i.e., session 2, based on this session identifier (sessionID2). Then, based on session 2, it can look up the corresponding relationship to determine the target session corresponding to session 1, i.e., session 1, which is the session between the terminal device and the gateway device. After finding session 1, it can obtain the source IP address in the first service message, i.e., the IP address of the terminal device, based on session 1. Therefore, it can replace the destination IP address in the first response message with the IP address of the terminal device to obtain the second response message. This achieves successful IP address replacement, enabling the second response message to successfully reach the terminal device corresponding to the destination IP address, thus completing the access to the web application resource.

[0054] Optionally, in this embodiment, the first session corresponds to a first session table entry, which includes the correspondence between the IP address of the terminal device and the IP address of the gateway device; the second session corresponds to a second session table entry, which includes the virtual IP address and the IP address of the resource server. Based on this, the second session to which the first response message belongs can be determined according to the following process: obtain the source IP address and destination IP address from the first response message; when the source IP address and the destination IP address match a second session table entry, the second session to which the first response message belongs is determined.

[0055] In this step, to better perform IP address lookups, a corresponding session table entry is maintained for each session. Specifically, upon receiving the first service packet, a first session table entry is created based on the first session corresponding to that first service packet. Similarly, after sending the second service packet to the resource server, a second session table entry is constructed based on the second session to which the second service packet belongs. In this way, after the first and second sessions are bound together, the first session table entries and the second session table entries are also associated.

[0056] Furthermore, taking Session 1 and Session 2 as examples, in another embodiment, when the first response message does not carry a session identifier, the session to which the first response message belongs can be determined by the IP address. Specifically, the source IP address and destination IP address in the first response message can be matched with the second session table entry. When a match is successful, the session 2 corresponding to the successfully matched session table entry is the session to which the first response message belongs, thus confirming the session to which the first response message belongs.

[0057] Based on this, the step of obtaining the source IP address in the first service message based on the found first session can be performed according to the following process: obtain the IP address of the terminal device according to the first session table entry of the first session.

[0058] Specifically, after determining that the first response message belongs to session 2, the session 1 found above can be obtained based on the binding relationship between session 1 and the session, and then the first session table entry of session 1 can be obtained. Then, the IP address of the terminal device, that is, the source IP address in the first service message, can be obtained from the first session table entry.

[0059] Therefore, in this embodiment, step 202 can be performed according to the following process: replacing the destination IP address in the first response message with the IP address of the terminal device.

[0060] In this step, after obtaining the IP address of the terminal device from the first session table entry, the IP address of the terminal device can be used to replace the destination IP address (virtual IP address) in the first response message. Combined with the step of replacing the source IP address of the first response message with the IP address of the gateway device, the second response message is obtained, thereby enabling the second response message to successfully reach the terminal device corresponding to the destination IP address, so as to complete the access to the web application resources.

[0061] To better understand this embodiment, Figure 3 The application scenario diagram shown below illustrates the application access method. Figure 3 The zero-trust network shown includes a controller, a gateway device, and a resource server for the web application. User 1 accesses the web application in the zero-trust network through a terminal device, denoted as application a. For example, the terminal device has a zero-trust client installed, and the controller is configured... Figure 3 The address of application 'a' is 192.168.1.10, which is... Figure 3The IP address of the resource server is 192.168.1.10, and the controller authorizes terminal devices to access application 'a'. The IP address of this terminal device is the IP address of its physical network card, denoted as 10.1.1.10. Based on this, the access process for user 1 to access application 'a' through the zero-trust client on the terminal device is roughly as follows:

[0062] User 1 authenticates with the controller in the zero-trust network through the terminal device. After the controller authenticates User 1, it assigns a virtual IP address of 172.1.1.10 to User 1. At the same time, the controller distributes the virtual IP address to the gateway device corresponding to the application that User 1 can access.

[0063] Regarding the request direction for application resources, when user 1 accesses application a, it can send service message 1 (accessing application a) to the gateway device. The source IP address of service message 1 is 10.1.1.10, and the destination IP address is the gateway device's IP address: 10.1.1.3. Furthermore, the destination port of service message 1 is 10443, which is the SSL / TLS service port.

[0064] After receiving service packet 1, the gateway device executes TCP and SSL / TLS web proxy functions. Specifically, it obtains the virtual IP address corresponding to the user token in service packet 1 (172.1.1.10), and then replaces the source IP address in service packet 1 with this virtual IP address. This results in service packet 2 having a source IP address of 172.1.1.10 and a destination IP address of application A (192.168.1.10). The gateway device can then send service packet 2 to application A's resource server. Since the source IP address of the service packet arriving at the resource server is the unique virtual IP address corresponding to the user of the terminal device, the problem of being unable to trace the source of service packets arriving at the resource server due to the source IP address being the gateway device's IP address is solved. In other words, during tracing, the corresponding terminal device can be found based on the virtual IP address in the service packet, thus achieving the purpose of tracing the source during security risk assessment.

[0065] Regarding the response direction of the request for application resources, when the resource server responds to the request direction business message 2, it will generate response message 1 and then send response message 1 to the gateway device.

[0066] After receiving response message 1, the gateway device can find the source IP address in service message 1, which is the IP address of the terminal device: 10.1.1.10. In this way, the gateway device can change the destination IP address in the response message to the IP address of the terminal device (10.1.1.10), and at the same time, change the source IP address in the response message from the IP address of the resource server (192.168.1.10) to the IP address of the gateway device (10.1.1.3), thereby obtaining response message 2. Then, it can forward response message 2 to the terminal device according to the destination IP address in response message 2.

[0067] Therefore, in a zero-trust network scenario where web applications are accessed by zero-trust clients, the gateway device, acting as a web proxy, modifies the source IP address of the packets to be sent to the accessed web application to the virtual IP address corresponding to the terminal device. This allows the packets modified to the virtual IP address to be traced and audited when they reach the web application's resource server, thus solving the problem of being unable to trace the source of business packets arriving at the resource server due to the source IP address being the gateway device's IP address.

[0068] Based on the same inventive concept, this application also provides an application access device corresponding to the above-described application access method. Specific implementation details of this application access device can be found in the above description of the application access method, and will not be elaborated upon here.

[0069] See Figure 4 , Figure 4 This application provides an exemplary embodiment of an application access device, applied in a gateway device in a zero-trust network. The device includes:

[0070] The receiving unit 401 is used to receive the first service message sent by the terminal device through the zero-trust client for accessing the web application;

[0071] The acquisition unit 402 is used to obtain the virtual IP address corresponding to the user token in the first service message. The virtual IP address is assigned and sent to the gateway device by the controller in the zero trust network after the terminal device is successfully online.

[0072] Replacement unit 403 is used to replace the source IP address in the first service message with the virtual IP address, and replace the destination IP address in the first service message with the IP address of the resource server of the web application to obtain the second service message;

[0073] The sending unit 404 is used to forward the second service message to the resource server of the web application.

[0074] In implementing the above application access device, based on accessing web applications using a zero-trust client, since the source IP address of the business message arriving at the resource server is the virtual IP address corresponding to the unique user token of the user to which the terminal device belongs, and different user tokens correspond to different virtual IP addresses, the problem of being unable to trace the source of risks caused by the source IP address of the message arriving at the resource server being the IP address of the gateway device is solved.

[0075] Optionally, in this embodiment, the receiving unit 401 is further configured to receive the first response message of the first service message fed back by the resource server;

[0076] The replacement unit 403 described above is further configured to replace the destination IP address in the first response message with the source IP address in the first service message, and replace the source IP address in the first response message with the IP address of the gateway device to obtain the second response message;

[0077] The aforementioned sending unit 404 is further configured to forward the second response message to the terminal device.

[0078] Optionally, the application access device provided in this embodiment may further include:

[0079] The binding unit (not shown in the figure) is used to bind the correspondence between the first session to which the first service message belongs and the second session to which the second service message belongs after the sending unit forwards the second service message to the resource server of the web application.

[0080] Furthermore, the replacement unit 403 is specifically used to retrieve the corresponding relationship based on the second session to which the first response message belongs, so as to obtain the source IP address in the first service message based on the found first session; and replace the destination IP address in the first response message with the source IP address in the first service message.

[0081] Optionally, in this embodiment, the first session corresponds to a first session entry, which includes the correspondence between the IP address of the terminal device and the IP address of the gateway device; the second session corresponds to a second session entry, which includes the virtual IP address and the IP address of the resource server.

[0082] Based on this, the replacement unit 403 is specifically used to determine the second session to which the first response message belongs according to the following method: obtain the source IP address and destination IP address from the first response message; when the source IP address and the destination IP address match the second session table entry, the second session to which the first response message belongs is determined.

[0083] The replacement unit 403 described above is further configured to obtain the IP address of the terminal device based on the first session table entry of the first session;

[0084] The replacement unit 403 is further configured to replace the destination IP address in the first response message with the IP address of the terminal device.

[0085] Based on the same inventive concept, embodiments of this application provide an electronic device, which can be the aforementioned gateway device, etc. For example... Figure 5 As shown, the electronic device may include a processor 501 and a machine-readable storage medium 502. The machine-readable storage medium 502 stores a computer program executable by the processor 501. The processor 501 is prompted by the computer program to execute the application access method provided in any embodiment of this application. Furthermore, the electronic device also includes a communication interface 503 and a communication bus 504, wherein the processor 501, the communication interface 503, and the machine-readable storage medium 502 communicate with each other via the communication bus 504.

[0086] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0087] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0088] The machine-readable storage medium 502 described above can be a memory, which may include random access memory (RAM), DDR SRAM (Double Data Rate Synchronous Dynamic Random Access Memory), or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0089] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0090] Furthermore, this embodiment also provides a machine-readable storage medium storing a computer program that, when invoked and executed by a processor, causes the processor to perform the method provided in any embodiment of this application.

[0091] For embodiments of electronic devices and machine-readable storage media, since the methods involved are basically similar to those described in the foregoing method embodiments, the description is relatively simple, and relevant details can be found in the descriptions of the method embodiments.

[0092] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0093] The specific implementation process of the functions and roles of each unit / module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0094] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units / modules described as separate components may or may not be physically separate. The components shown as units / modules may or may not be physical units / modules, that is, they may be located in one place or distributed across multiple network units / modules. Some or all of the units / modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0095] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An application access method, characterized in that, The method, applied to gateway devices in zero-trust networks, includes: The receiving terminal device sends the first business message for accessing the web application through a zero-trust client; Based on the user token in the first service message, obtain the virtual IP address corresponding to the user token. The virtual IP address is assigned and distributed to the gateway device by the controller in the zero-trust network after the terminal device successfully goes online. The source IP address in the first service message is replaced with the virtual IP address, and the destination IP address in the first service message is replaced with the IP address of the resource server of the web application to obtain the second service message; The second service message is forwarded to the resource server of the web application.

2. The method according to claim 1, characterized in that, Also includes: Receive the first response message of the first service message fed back by the resource server; Replace the destination IP address in the first response message with the source IP address in the first service message, and replace the source IP address in the first response message with the IP address of the gateway device to obtain the second response message; The second response message is forwarded to the terminal device.

3. The method according to claim 2, characterized in that, After forwarding the second service message to the resource server of the web application, the method further includes: Bind the correspondence between the first session to which the first service message belongs and the second session to which the second service message belongs.

4. The method according to claim 3, characterized in that, Replacing the destination IP address in the first response message with the source IP address in the first service message includes: Based on the second session to which the first response message belongs, the corresponding relationship is retrieved to obtain the source IP address in the first service message based on the found first session; Replace the destination IP address in the first response message with the source IP address in the first service message.

5. The method according to claim 4, characterized in that, The first session corresponds to a first session table entry, which includes the correspondence between the IP address of the terminal device and the IP address of the gateway device; the second session corresponds to a second session table entry, which includes the virtual IP address and the IP address of the resource server. The second session to which the first response message belongs is determined using the following method: The source IP address and destination IP address are obtained from the first response message. When the source IP address and the destination IP address match the second session table entry, the second session to which the first response message belongs is determined. Based on the found first session, the source IP address in the first service packet is obtained, including: The IP address of the terminal device is obtained based on the first session table entry of the first session; Replacing the destination IP address in the first response message with the source IP address in the first service message includes: Replace the destination IP address in the first response message with the IP address of the terminal device.

6. An application access device, characterized in that, The device, used in gateway devices in zero-trust networks, includes: The receiving unit is used to receive the first business message sent by the terminal device through the zero-trust client for accessing the web application; The acquisition unit is used to acquire the virtual IP address corresponding to the user token in the first service message. The virtual IP address is assigned and distributed to the gateway device by the controller in the zero-trust network after the terminal device successfully goes online. The replacement unit is used to replace the source IP address in the first service message with the virtual IP address, and replace the destination IP address in the first service message with the IP address of the resource server of the web application to obtain the second service message; The sending unit is used to forward the second service message to the resource server of the web application.

7. The apparatus according to claim 6, characterized in that, The receiving unit is further configured to receive a first response message of the first service message fed back by the resource server; The replacement unit is further configured to replace the destination IP address in the first response message with the source IP address in the first service message, and replace the source IP address in the first response message with the IP address of the gateway device to obtain a second response message; The sending unit is further configured to forward the second response message to the terminal device.

8. The apparatus according to claim 7, characterized in that, Also includes: The binding unit is used to bind the correspondence between the first session to which the first service message belongs and the second session to which the second service message belongs after the sending unit forwards the second service message to the resource server of the web application.

9. The apparatus according to claim 8, characterized in that, The replacement unit is specifically used to retrieve the corresponding relationship based on the second session to which the first response message belongs, so as to obtain the source IP address in the first service message based on the found first session; Replace the destination IP address in the first response message with the source IP address in the first service message.

10. The apparatus according to claim 9, characterized in that, The first session corresponds to a first session table entry, which includes the correspondence between the IP address of the terminal device and the IP address of the gateway device; the second session corresponds to a second session table entry, which includes the virtual IP address and the IP address of the resource server. The replacement unit is specifically used to determine the second session to which the first response message belongs according to the following method: obtaining the source IP address and destination IP address from the first response message; when the source IP address and the destination IP address match the second session table entry, the second session to which the first response message belongs is determined. The replacement unit is further configured to obtain the IP address of the terminal device based on the first session table entry of the first session; The replacement unit is further configured to replace the destination IP address in the first response message with the IP address of the terminal device.

Images