CN115603932A - An access control method, access control system and related equipment - Google Patents

Abstract

The application provides an access control method, an access control system and related equipment, which relate to the technical field of network security and are used to improve the security of protected application resources. The method includes: the SDP controller receives the first message sent by the first SDP client device, and the TCP option field of the first message carries the device identifier of the first SDP client device; The device identification of the end device carries out single-packet authentication to the first SDP client device; if the single-packet authentication to the first SDP client device fails, the SDP controller closes the first SDP client device and the first SDP client device to which the first message belongs. TCP connection between SDP controllers.

Description

An access control method, access control system and related equipment

This application claims the priority of the Chinese patent application with the application number 202110770853.3 and the application name "A method for access control, access control system and related equipment" submitted to the State Intellectual Property Office on July 08, 2021. The entire content of the application is passed References are incorporated in this application.

technical field

The present application relates to the technical field of network security, in particular to an access control method, an access control system and related equipment.

Background technique

Software defined perimeter (SDP) is a technology for resource access control based on identity proposed by Cloud Security Alliance. SDP first authenticates the user and the device used by the user before granting the terminal device access to resources. If the authentication passes, the user can use the device to access resources; if the authentication fails, the user is prohibited from using the device to access resources. Therefore, SDP technology can guarantee resource isolation and security.

The access control system based on SDP technology usually includes: SDP controller, SDP client and SDP gateway. The SDP client and the SDP gateway respectively establish bidirectional connections with the SDP controller. When the SDP client needs to access protected application resources, the SDP client will first initiate authentication to the SDP controller. After the authentication is passed, the SDP controller will send information such as the source IP address and destination port that need to be released to the SDP gateway. The SDP client sends an access request to the SDP gateway, and the SDP gateway judges whether the source IP address of the SDP client is legal, and allows corresponding access when it is judged that the source IP address of the SDP client is legal.

At present, there are usually situations where multiple SDP clients use the same source IP address to access after conversion by a source network address translation (SNAT) device. At this time, the source IP address of the data packets received by the SDP gateway from multiple SDP clients is the same, and the SDP gateway cannot distinguish the IP address before the SNAT device conversion. In this case, as long as one of the multiple SDP clients passes the authentication, other SDP clients that fail the authentication can use the source IP address to access the protected application resources, thus causing certain security risks .

Contents of the invention

The present application provides an access control method, an access control system and related equipment, which are used to improve the security of protected application resources.

In order to achieve the above object, the application adopts the following technical solutions:

In a first aspect, an access control method is provided, the method comprising: the SDP controller receives the first message sent by the first SDP client device, and the first SDP client is carried in the Transmission Control Protocol TCP option field of the first message The device ID of the device; the SDP controller performs single-packet authentication on the first SDP client device according to the device ID of the first SDP client device; if the single-packet authentication of the first SDP client device fails, the SDP controller shuts down A TCP connection between the first SDP client device to which the first packet belongs and the SDP controller.

In the above technical solution, the first SDP client sends a first message to the SDP controller, and the TCP option field of the first message carries the device identifier of the first SDP client device. When the SDP controller receives the first message, it performs single-packet authentication on the first SDP client device based on the device identifier of the first SDP client device. If the single-packet authentication of the first SDP client device fails, the SDP controller closes the TCP connection between the first SDP client device to which the first packet belongs and the SDP controller. In this way, when multiple SDP client devices use the same source IP address after being translated by the same SNAT device, the SDP controller can identify different SDP client devices based on the device identification of the SDP client device, thereby ensuring the protected application resources security. Furthermore, the first SDP client carries the device identifier of the first SDP client device through the TCP option field of the first message, instead of carrying the device identifier through other protocol layers above the TCP transport layer, so that there is no need to create a socket There is no need to read and parse the application layer data of the message, thereby reducing the system overhead of the SDP controller.

Optionally, in a possible design of the first aspect, the method further includes: the SDP controller receives the first message sent by the second SDP client device, and the first message sent by the second SDP client device The device identification of the second SDP client device is carried in the TCP option field of the device; the SDP controller performs single-packet authentication on the second SDP client device according to the device identification of the second SDP client device; if the second SDP client device If the single-packet authentication is successful, the SDP controller receives the second packet sent by the second SDP client device. The TLS option field of the second packet or the application layer header of the second packet carries authentication information. The rights information includes the user information of the second SDP client device; the SDP controller performs user authentication on the second SDP client device according to the device identification of the second SDP client device and the user information; if the second SDP client device If the user authentication is successful, the SDP controller sends a resource list to the second SDP client device, where the resource list includes an identifier of at least one application server that is allowed to be accessed by the second SDP client device. In the above possible design, the SDP controller only sends the resource list to the second SDP client device if the SDP controller succeeds in the single-packet authentication and user authentication of the second SDP client device. In this way, when multiple SDP client devices use the same source IP address after being converted by the same SNAT device, the SDP client devices that have not been successfully authenticated in the multiple SDP client devices cannot access the security of the protected application resources, thereby Ability to improve the security of protected application resources.

Optionally, in a possible design of the first aspect, the first message and the second message sent by the second SDP client device are messages in the same TCP connection; or, the second SDP client device The first packet and the second packet sent by the device are packets in different TCP connections. In the above possible design, the second SDP client device can perform single-packet authentication and user authentication respectively through two messages in the same TCP connection, and can also perform single-packet authentication and user authentication respectively through two messages in different TCP connections. certification, thereby improving the flexibility of certification.

Optionally, in a possible design of the first aspect, if the first message and the second message sent by the second SDP client device are messages in different TCP connections, the SDP controller receives the second SDP Before the second message sent by the client device, the method also includes: the SDP controller sends the salt value to the second SDP client device according to the first message sent by the second SDP client device; the second message also carries The salt value, after the SDP controller receives the second message sent by the second SDP client device, the method further includes: the SDP controller determines the second SDP client device according to the salt value carried in the second message Single-package authentication for was successful. In the above possible design, if the first message and the second message sent by the second SDP client device are messages in different TCP connections, by carrying the second message in the SDP controller according to the first message The salt value sent in the message can enable the SDP controller to determine that the single-packet authentication of the second SDP client device has succeeded according to the salt value carried in the second message.

Optionally, in a possible design of the first aspect, the first message sent by the first SDP client device is a synchronous SYN message; the first message sent by the second SDP client device is a SYN message .

Optionally, in a possible design of the first aspect, the device identifier carried in the first message sent by the first SDP client device is a device identifier in ciphertext form, and the method further includes: the SDP controller Use the serial number of the SYN message as the first message to decrypt the device identification in ciphertext form to obtain a character string of a specified length, which is used by the SDP controller to perform the first SDP client device Single pack authentication. Similarly, the device identification carried in the first message sent by the second SDP client device is a device identification in ciphertext form, and the method further includes: the SDP controller uses the SYN message as the first message The serial number decrypts the device identification in ciphertext form to obtain a character string of a specified length, which is used by the SDP controller to perform single-packet authentication on the second SDP client device. In the above possible design, by encrypting the device identifier carried in the first message, the security of the device identifier transmitted through the network can be guaranteed, and the legitimate SDP can be obtained from the first message after being intercepted by an illegal SDP client device. The device identification of the client device, thereby posing as a legitimate SDP client device for malicious activities.

Optionally, in a possible design of the first aspect, the SDP controller performs single-packet authentication on the first SDP client device according to the device identifier of the first SDP client device, including: the SDP controller uses the The above character string is compared with the character string corresponding to each registered SDP client device, wherein the character string corresponding to the registered SDP client device is the device according to the plain text form of the registered SDP client device The identification is generated; if the character string is the same as the character string corresponding to a registered SDP client device, it is determined that the single-packet authentication is successful.

Optionally, in a possible design of the first aspect, if the user authentication of the second SDP client device succeeds, the method further includes: the SDP controller sends token information to the second SDP client device, the The token information is used by the SDP gateway to verify the resource access initiated by the second SDP client device. In the above possible design, the SDP controller sends the token information to the second SDP client device, so that the subsequent second SDP client device carries the token information when initiating resource access to the SDP gateway, and the SDP gateway based on the resource access request The token information in is used to verify the legality of the resource access initiated by the second SDP client device.

Optionally, in a possible design of the first aspect, if the user authentication of the second SDP client device succeeds, the method further includes: the SDP controller sends client information to the SDP gateway, and the client information is used To indicate that the second SDP client device passes the authentication, the client information includes the device identifier of the second SDP client device. In the above possible design, if the user authentication of the second SDP client device is successful, the SDP controller sends the client information to the SDP gateway, so that the SDP gateway can determine the resource access information sent by the SDP client device based on the client information. Legality to ensure the security of protected application resources.

In a second aspect, an access control method is provided, the method comprising: an SDP client device sends a first message to an SDP controller, and the Transmission Control Protocol TCP option field of the first message carries the device identifier of the SDP client device . In this way, when the SDP controller receives the first message, the SDP controller can identify different SDP client devices through the device identification of the SDP client device, thereby preventing multiple SDP client devices from passing through the same SNAT device When the same source IP address is used after conversion, different SDP client devices cannot be identified, thereby ensuring the security of protected application resources. In addition, the SDP client carries the device identifier of the SDP client device in the TCP option field of the first message instead of carrying the device identifier through other protocol layers above the TCP transport layer, so that there is no need to create a socket, There is also no need to read and parse application layer data, thereby reducing the system overhead of the SDP controller.

Optionally, in a possible design of the second aspect, the method further includes: the SDP client device receives a single-packet authentication response sent by the SDP controller; if the single-packet authentication response is used to indicate that the SDP controller is The single-packet authentication of the SDP client device is successful, the SDP client device sends a second message to the SDP controller, and the security transport layer protocol TLS option field of the second message or the application layer message header carry authentication information, The authentication information includes user information of the SDP client device; the SDP client device receives a resource list returned by the SDP controller, and the resource list includes an identifier of at least one application server that the SDP client device is allowed to access. In the above possible design, the SDP client device can receive the resource list only if the SDP controller succeeds in the single-packet authentication and user authentication of the SDP client device. In this way, when multiple SDP client devices use the same source IP address after being converted by the same SNAT device, the SDP client devices that have not been successfully authenticated in the multiple SDP client devices cannot access the security of the protected application resources, thereby Ability to improve the security of protected application resources.

Optionally, in a possible design of the second aspect, the first message and the second message are messages in the same TCP connection; or, the first message and the second message are different TCP connections messages in . In the above possible design, the second SDP client device can perform single-packet authentication and user authentication respectively through two messages in the same TCP connection, and can also perform single-packet authentication and user authentication respectively through two messages in different TCP connections. certification, thereby improving the flexibility of certification.

Optionally, in a possible design of the second aspect, when the first message and the second message are messages in different TCP connections, before the SDP client device sends the second message to the SDP controller , the method further includes: the SDP client device receiving the salt value returned by the SDP controller according to the first message; the second message also carries the salt value, and the salt value carried in the second message is used for the SDP The controller determines that the single-packet authentication of the second SDP client device has succeeded. In the above possible design, if the first message and the second message sent by the SDP client device are messages in different TCP connections, by carrying the SDP controller in the second message according to the first message The sent salt value can enable the SDP controller to determine that the single-packet authentication of the second SDP client device has succeeded according to the salt value carried in the second message.

Optionally, in a possible design of the second aspect, the first packet is a synchronous SYN packet.

Optionally, in a possible design of the second aspect, the device identifier carried in the TCP option field of the first message is a device identifier in ciphertext form, and the method further includes: Obtain a string of a specified length for the device ID in plain text; use the serial number of the SYN message to encrypt the string to obtain the device ID in cipher text. Optionally, the character string of the specified length is obtained by performing a hash operation on the plaintext device identifier. In the above possible design, by encrypting the device identifier carried in the first message, the security of the device identifier transmitted through the network can be guaranteed, and the legitimate SDP can be obtained from the first message after being intercepted by an illegal SDP client device. The device identification of the client device, thereby posing as a legitimate SDP client device for malicious activities.

Optionally, in a possible design of the second aspect, after the SDP client device receives the resource list returned by the SDP controller, the method further includes: the SDP client device sends a third message to the SDP gateway, the first The device identifier of the SDP client device is carried in the TCP option field of the third message; the SDP client device receives the service data returned by the application server, and the service data is carried by the SDP gateway according to the TCP option field of the third message After the device identifier determines that the SDP client device is legal and forwards the third message to the application server, the application server sends it. In the above possible design, by carrying the device identifier of the SDP client device in the TCP option field of the third message, the SDP gateway can use the same source IP address after multiple SDP client devices pass through the same SNAT device Next, different SDP client devices are identified, thereby ensuring the security of protected application resources. In addition, the device identification of the SDP client device is carried in the TCP option field of the third message instead of carrying the device identification through other protocol layers above the TCP transport layer, so that there is no need to create a socket or read And analyze the application layer data, thereby reducing the system overhead of the SDP controller.

Optionally, in a possible design of the second aspect, the third message is a synchronous SYN message.

Optionally, in a possible design of the second aspect, the device identifier carried in the TCP option field of the third message is a device identifier in ciphertext form, and the method further includes: Obtain a character string of a specified length for the device identifier in plain text; use the serial number of the SYN message as the third message to encrypt the character string to obtain the device identifier in cipher text. Optionally, the character string of the specified length is obtained by performing a hash operation on the plaintext device identifier. In the above possible design, by encrypting the device identification carried in the third message, the security of the device identification transmitted through the network can be guaranteed, and the legal SDP can be obtained from the first message after being intercepted by an illegal SDP client device. The device identification of the client device, thereby posing as a legitimate SDP client device for malicious activities.

Optionally, in a possible design of the second aspect, the method further includes: the SDP client device receives the token information sent by the SDP controller, and carries the token information in a subsequently sent resource access request . In order for the SDP gateway to verify the resource access request initiated by the SDP client device based on the token information carried in the resource access request.

In a third aspect, an access control method is provided, the method includes: the SDP gateway receives client information sent by the SDP controller, the client information is used to indicate that the SDP client device has passed the authentication, and the client information includes the SDP client The device identifier of the device; the SDP gateway receives the third message sent by the SDP client device, and the TCP option field of the third message carries the device identifier of the SDP client device; the SDP gateway according to the client information includes The device identifier and the device identifier included in the third message determine whether the SDP client device is legal; if it is determined that the SDP client device is legal, the SDP gateway sends the third message to the application server, and sends the application server The returned service data is forwarded to the SDP client device.

In the above technical solution, the SDP client device can enable the SDP gateway to use the same source after multiple SDP client devices pass through the same SNAT device by carrying the device identifier of the SDP client device in the TCP option field of the third message. In the case of resource access by IP address, different SDP client devices are identified, thereby ensuring the security of protected application resources. In addition, the device identification of the SDP client device is carried in the TCP option field of the third message instead of carrying the device identification through other layers above the TCP transport layer, so that there is no need to create a socket, and there is no need to read and Parse the application layer data, thereby reducing the system overhead of the SDP controller or SDP gateway.

Optionally, in a possible design of the third aspect, the third message is a synchronous SYN message.

Optionally, in a possible design of the third aspect, the device identifier carried in the TCP option field is a device identifier in ciphertext form, and the method further includes: the SDP gateway uses the serial number of the SYN message Decrypt the device identification in ciphertext form to obtain a first character string of a specified length, and the first character string is used by the SDP gateway to determine whether the SDP client device is legitimate. In the above possible design, by encrypting the device identification carried in the third message, the security of the device identification transmitted through the network can be guaranteed, and the third message can be prevented from being intercepted by an illegal SDP client device to obtain a legal SDP The device identification of the client device, thereby posing as a legitimate SDP client device for malicious activities.

Optionally, in a possible design of the third aspect, the SDP gateway determines whether the SDP client device is legitimate according to the device identifier included in the client information and the device identifier included in the third message, including : The SDP gateway obtains the second character string of the specified length according to the device identification included in the client information; the SDP gateway compares the first character string with the second character string; if the first character string is consistent with the second character string, It is determined that the SDP client device is legitimate.

Optionally, in a possible design of the third aspect, the third message also carries token information, and the token information is used by the SDP gateway to verify the resource access initiated by the SDP client device.

According to a fourth aspect, an access control device is provided. The device is used as an SDP controller or a built-in chip of the SDP controller, and includes: a memory and at least one processor. The memory is used to store instructions. After the instructions are read by at least one processor, the device executes the access control method provided by the first aspect or any possible design of the first aspect. For details, refer to the above detailed description. I won't repeat them here.

In the fifth aspect, an access control device is provided, which is used as an SDP controller or a built-in chip of the SDP controller, and the device has the access control method provided by the above-mentioned first aspect or any possible design of the first aspect function in . The functions described above can be realized by hardware, and can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the above functions.

According to a sixth aspect, an access control device is provided. The device is used as an SDP client device or a built-in chip of the SDP client device, and includes: a memory and at least one processor. The memory is used to store instructions. After the instructions are read by at least one processor, the device executes the access control method provided by the second aspect or any possible design of the second aspect. For details, refer to the above detailed description, I won't repeat them here.

In the seventh aspect, an access control device is provided, which is used as an SDP client device or a built-in chip of the SDP client device, and the device has the access provided by any possible design for realizing the above-mentioned second aspect or the second aspect function in the control method. The functions described above can be realized by hardware, and can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the above functions.

In an eighth aspect, an access control device is provided. The device is used as an SDP gateway or a built-in chip of the SDP gateway, and includes: a memory and at least one processor. The memory is used to store instructions. After the instructions are read by at least one processor, the device executes the access control method provided by the above third aspect or any possible design of the third aspect. For details, refer to the above detailed description, I won't repeat them here.

In the ninth aspect, an access control device is provided. The device is used as an SDP gateway or a built-in chip of the SDP gateway. The device has the access control method provided by any possible design of the third aspect or the third aspect. Features. The functions described above can be realized by hardware, and can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the above functions.

In another aspect of the present application, an access control system is provided, the system includes: an SDP controller, an SDP client device, and an SDP gateway; wherein, the SDP controller includes the access control provided in the fourth aspect or the fifth aspect device, the SDP client device includes the access control device provided in the sixth aspect or the seventh aspect, and the SDP gateway includes the access control device in the eighth aspect or the ninth aspect.

In yet another aspect of the present application, a computer-readable storage medium is provided, the computer-readable storage medium includes computer instructions, and when the computer instructions are executed, any possible design as in the first aspect or the first aspect is executed The provided access control method.

In yet another aspect of the present application, a computer-readable storage medium is provided, the computer-readable storage medium includes computer instructions, and when the computer instructions are executed, any possible design as in the second aspect or the second aspect is executed The provided access control method.

In yet another aspect of the present application, a computer-readable storage medium is provided, the computer-readable storage medium includes computer instructions, and when the computer instructions are executed, any possible design of the third aspect or the third aspect is executed The provided access control method.

In yet another aspect of the present application, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to execute the access control method provided by the first aspect or any possible design of the first aspect.

In yet another aspect of the present application, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to execute the access control method provided by the second aspect or any possible design of the second aspect.

In yet another aspect of the present application, a computer program product containing instructions is provided, and when it is run on a computer, it causes the computer to execute the access control method provided in the third aspect or any possible design of the third aspect .

It should be understood that, the beneficial effects of any access control device, communication system, computer-readable storage medium, and computer program product provided above can refer to the beneficial effects of the method embodiments provided in the corresponding aspects above, and are not described here. Let me repeat.

Description of drawings

FIG. 1 is a system architecture diagram of a traditional network security provided by an embodiment of the present application;

FIG. 2 is a schematic structural diagram of an SDP system provided by an embodiment of the present application;

FIG. 3 is a schematic structural diagram of another SDP system provided by the embodiment of the present application;

FIG. 4 is a schematic flowchart of an access control method provided in an embodiment of the present application;

FIG. 5 is a schematic diagram of a TCP option provided by an embodiment of the present application;

FIG. 6 is a schematic flow diagram of another access control method provided by the embodiment of the present application;

FIG. 7 is a schematic diagram of reporting a second message provided by an embodiment of the present application;

FIG. 8 is a schematic flowchart of another access control method provided by the embodiment of the present application;

FIG. 9 is a schematic diagram of access control of an SDP controller provided by an embodiment of the present application;

FIG. 10 is a schematic structural diagram of an SDP controller provided in an embodiment of the present application;

FIG. 11 is a schematic structural diagram of another SDP controller provided in the embodiment of the present application;

FIG. 12 is a schematic structural diagram of an SDP client device provided in an embodiment of the present application;

FIG. 13 is a schematic structural diagram of another SDP client device provided in the embodiment of the present application;

FIG. 14 is a schematic structural diagram of an SDP gateway provided by an embodiment of the present application;

FIG. 15 is a schematic structural diagram of another SDP gateway provided by the embodiment of the present application.

detailed description

In this application, "at least one" means one or more, and "multiple" means two or more. "And/or" describes the association relationship of associated objects, indicating that there are three kinds of relationships, for example, A and/or B means: A exists alone, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural. The character "/" generally indicates that the contextual objects are an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (unit) of a, b or c means: a, b, c, a-b, a-c, b-c, or a-b-c, wherein a, b, c can be single or multiple. In addition, in the embodiments of the present application, words such as "first" and "second" do not limit the quantity and execution order.

Below, before introducing the embodiments of the present application, the background technology involved in the present application will first be described.

The traditional concept of network security is mainly based on the definition of network boundaries for security protection. Exemplarily, as shown in FIG. 1 , an internal network is isolated from an external network by border devices such as a firewall (fire wall, FW)/network intelligent protection (network intelligent protection, NIP). Among them, the external network may have security risks, the internal network is relatively safe, and the resources of the internal network (such as financial systems, human resources systems, applications and other systems used within a certain enterprise) are not exposed to the external network. That is, terminal devices in the external network cannot access the resources of the internal network. Traditional network security can provide enterprises with certain security protection, but with the development of the network, a series of problems such as blurred network boundaries, complicated access and internal attacks have emerged.

To deal with the above problems, some studies have proposed the concept of software defined perimeter (SDP) based on the concept of zero trust. SDP is a technology for resource access control based on identity. SDP first authenticates the user and the device used by the user before granting the terminal device access to resources. If the authentication passes, the user can use the device to access resources; if the authentication fails, the user is prohibited from using the device to access resources. That is to say, the SDP technology strictly authenticates the access request of each terminal device to ensure that resources are always safely accessed, thereby ensuring resource isolation and security.

FIG. 2 is a schematic structural diagram of an SDP system provided by an embodiment of the present application. The SDP system includes: an SDP controller, an SDP client, an SDP gateway, and protected application resources. Both the SDP client and the SDP gateway can be called the SDP host, and the SDP host is divided into the SDP client and the SDP gateway according to the connection initiator and receiver. The SDP gateway is set between the SDP client and the protected application resources, and the SDP client's access to the protected application resources needs to go through the SDP gateway.

Optionally, the SDP client is installed on the terminal device, and the terminal device on which the SDP client is installed is called an SDP client device. Optionally, a local agent (agent) corresponding to the SDP client is also installed on the SDP client device. The local proxy is used to perform certain processing on the packets sent or received by the SDP client. For example, in the embodiment of the present application, the home agent is used to add the device identifier of the SDP client device in the TCP option fields of the first packet and the third packet in the following method embodiments.

In the SDP system, the SDP controller is used for identity authentication of the SDP client device, authentication of the SDP client device's access to protected application resources, and the like. Optionally, the SDP controller is further configured to deliver the control policy of the legal SDP client device to the SDP gateway, so that the SDP gateway controls the SDP client device's access to the protected application resource according to the control policy. Optionally, the protected application resources include world wide web (world wide web, web) applications, secure shell protocol (secure shell protocol, SSH) services, services based on client/server (client/server, C/S) systems, Services based on a browser/server (browser/server, B/S) system, etc., are not specifically limited in this embodiment of the present application.

The SDP client and the SDP gateway respectively establish bidirectional connections with the SDP controller. When the SDP client needs to access protected application resources, the SDP client will first initiate authentication to the SDP controller. After the authentication is passed, the SDP controller will send information such as the source IP address and destination port that need to be released to the SDP gateway. The SDP client then sends an access request to the SDP gateway, and the SDP gateway judges whether the source IP address of the access request is legal, and forwards the access request to the protected application resource when it is legal, thereby allowing the SDP client sending the access request to access the protected application resources.

At present, in the SDP system, as shown in Figure 3, when multiple SDP clients (shown as the first SDP client to the nth SDP client in Figure 3) use the same source IP address to access For protected application resources, the source IP address of the access request received by the SDP gateway from multiple SDP clients is the same, and the SDP gateway cannot distinguish the IP address before the SNAT device translation. In this case, as long as one of the multiple SDP clients passes the authentication, other SDP clients that fail the authentication can use the source IP address to access the protected application resources, thus causing certain security risks . Based on this, an embodiment of the present application provides an access control method, which can identify different SDP clients when multiple SDP clients use one SNAT device, thereby improving the security of protected application resources.

FIG. 4 is a schematic flowchart of an access control method provided by an embodiment of the present application, and the method is applied to a system including an SDP controller, an SDP client device, and an SDP gateway. Referring to Fig. 4, the method includes the following steps. Fig. 4 shows the situation that the SDP controller fails to authenticate the single packet of the first SDP client device.

S201: The first SDP client device sends a first packet to the SDP controller, and a transmission control protocol (transmission control protocol, TCP) option (option) field of the first packet carries a device identifier of the first SDP client device.

Wherein, the SDP client device is a terminal device installed with an SDP client. In this embodiment, "the first packet" is used to represent the packet sent by the SDP client device for single packet authorization (single packet authorization, SPA) authentication. Optionally, the first packet is a synchronous (synchronous, SYN) packet when the first SDP client device initiates a TCP connection to the SDP controller.

In addition, the first message is a message carried on the TCP transport layer, and the TCP option field of the first message carries the device identifier of the first SDP client device. Exemplarily, as shown in FIG. 5 , the TCP option field includes three parts: kind (kind, K), length (length, L) and value (value, V). The type K is used to indicate the type of information carried by the TCP option field, and different values of K correspond to different types. For example, in Figure 5, the value of K is 252 to indicate that the information carried by the TCP option field is the SDP client Device ID of the end device. The length L is used to indicate the length occupied by the TCP option field. In FIG. 5 , the TCP option field occupies 18 bytes as an example for illustration. The value V is used to represent the device identifier of the SDP client device. In FIG. 5 , the length occupied by the value V is 16 bytes as an example for illustration.

Furthermore, the device identifier of the first SDP client device can be used to uniquely identify the first SDP client device, and the device identifier is generated based on relevant information of the first SDP client device. For example, the first SDP client device sends the serial number of the main hard disk of the first SDP client device, the media access control (media access control) information of the network card, and/or the central processing unit (central processing unit, CPU) serial number, etc. information as the primary key information, combined with the current timestamp and a hash value generated by a random number to generate the device identifier.

Specifically, when the first SDP client device establishes a TCP connection with the SDP controller, the first SDP client device sends the first message to the SDP controller, and the TCP option field of the first message carries the first The device identifier of the SDP client device, so as to initiate SPA authentication to the SDP controller through the first message.

Optionally, the device identifier of the SDP client device carried in the TCP option field of the first packet is a device identifier in ciphertext. Exemplarily, the structure of the TCP option field is shown in FIG. 5 , and the device identifier carried in the third part (namely V) in the TCP option field is the device identifier in ciphertext form of the SDP client device.

In a possible implementation, the device identification in cipher text is obtained in the following manner: the first SDP client device obtains a character string of a specified length according to the device identification in plain text of the first SDP client device, and uses the SYN The serial number of the message performs advanced encryption standard (AES) symmetric encryption on the character string to obtain the device identifier in the ciphertext form. Optionally, when obtaining a character string of a specified length, the first SDP client device uses a hash algorithm to perform a hash operation on the device identification in plain text, or intercepts the device identification in plain text to obtain the specified length string.

It should be noted that, in addition to the serial number of the SYN message, the key used by the first SDP client device to encrypt the string can also be other unique information. In this application, only the key is referred to as the SYN key. The sequence number of the message is described as an example, which does not constitute a limitation to the embodiment of the present application.

Further, when the TCP option field of the first message also includes other types of TCP options, if the length of the TCP option field exceeds the preset length (for example, 40 bytes), the first SDP client device also includes the TCP The option field is screened and reassembled to ensure that the length of the TCP option field does not exceed the preset length. After the first SDP client device reassembles the original TCP options in the TCP option field, it adds the TCP option for carrying the device identifier of the first SDP client device behind the last TCP option. If the device identifier of the first SDP client device is not filled with the corresponding TCP options, the corresponding TCP options can be filled with invalid characters (for example, NOP).

For example, when the TCP option field further includes a TCP option for improving the forwarding performance of the first packet, the first SDP client device reserves the TCP option for improving the forwarding performance of the first packet. For example, the TCP option used to improve the forwarding performance of the first message includes one or more of the following three TCP options: allow selection of acknowledgment (SACK_PERM) option, window expansion factor (WINDOW) option, maximum segment Size (maximum segment size, MSS) option.

In another possible embodiment, the above S201 can be replaced by: the first SDP client device sends a first message to the SDP controller, and the transport layer security (transport layer security, TLS) protocol of the first message The option carries the device ID of the SDP client device.

The difference between carrying the device identifier of the first SDP client device in the TLS option field of the first message and carrying the device identifier of the first SDP client device in the TCP option field of the first message is that the TLS connection is carried on In the application layer, that is, the TLS connection is located on top of the TCP connection, so when adding and obtaining the device identifier in the TLS option, it needs to be implemented with the help of a socket (socket), and the creation, reading and parsing of the socket application Layer data can bring a lot of system overhead.

It should be noted that, in the method of carrying the device identifier of the first SDP client device through the TLS option field of the first message, when the SDP controller receives the first message, it can also be realized through the steps described below Single-packet authentication for the first SDP client device, so that when multiple SDP client devices use the same source IP address after conversion by the same SNAT device, different SDP client devices can be identified to ensure the security of protected application resources sex.

In the following, the TCP option of the first packet carries the device identifier of the first SDP client device as an example for illustration.

S202: When the SDP controller receives the first packet, the SDP controller performs single-packet authentication on the first SDP client device according to the device identifier of the first SDP client device.

When the SDP controller receives the first packet, the SDP controller parses the TCP option field of the first packet. If the TCP option field of the first packet does not carry the device identifier of the first SDP client device, the SDP controller determines that the single-packet authentication of the first SDP client device fails. If the TCP option field of the first packet carries the device identifier of the first SDP client device, the SDP controller based on the device identifier of the first SDP client device and the first SDP client device carried in the first packet The source IP address of the first SDP client device performs single-packet authentication on the SDP client device. If the device ID and the source IP address are both authenticated successfully, the single-packet authentication of the first SDP client device succeeds. If the device ID and the source IP address If at least one of the addresses fails to be authenticated, the single-packet authentication to the first SDP client device fails.

Wherein, the process of the SDP controller authenticating the source IP address of the first SDP client is consistent with the authentication process in the prior art, and will not be repeated in this embodiment of the present application. The process in which the SDP controller authenticates the device identifier of the first SDP client device will be described in detail below.

Exemplarily, when the SDP controller obtains the device identifier of the first SDP client device, the SDP controller queries a locally stored trusted device identifier list, wherein the trusted device identifier list includes multiple SDP client devices in plain text logo. Optionally, the device identifiers of the multiple SDP client devices in the trusted device identifier list are sent to the SDP controller when the multiple SDP client devices register with the SDP controller. In the case where the device identification of the SDP client device carried in the TCP option field of the first message is a device identification in clear text form, if the device identification of the SDP client device carried in the TCP option field of the first message is in the In the list of trusted device identifiers, the SDP controller determines that the authentication of the device identifier of the first client device succeeds. If the device identifier of the SDP client device carried in the TCP option field of the first packet is not in the trusted device identifier list, the SDP controller determines that authentication of the device identifier of the first client device fails.

In a possible embodiment, when the device identifier carried in the TCP option field of the first message is a device identifier in ciphertext form, the SDP controller parses the TCP option field of the first message to obtain the Device ID in ciphertext. The SDP controller uses the serial number of the first message (that is, the SYN message) to decrypt the device identification in ciphertext to obtain a character string of a specified length. Afterwards, the SDP controller authenticates the device identification of the first SDP client device based on the character string.

Exemplarily, when the SDP controller obtains the device identifier of the SDP client device in the first message, the SDP controller queries the string list corresponding to the trusted device identifier list stored locally. Optionally, the character string list includes character strings of a specified length respectively obtained by the SDP controller according to device identifications in clear text of multiple SDP client devices in the trusted device identification list. The way to obtain the character string in the character string list is similar to the description in step S201, please refer to the description in step S201, for example, the SDP controller performs a hash operation on the plaintext device identification of an SDP client device in the trusted device identification list The corresponding character string of the specified length is obtained. If the character string of the specified length obtained by the SDP controller from the TCP option field of the first message is in the list of character strings, the SDP controller determines that the device identification authentication of the first SDP client device is successful; The character string of the specified length obtained in the TCP option field is not in the character string list, and the SDP controller determines that the device identification authentication of the first client device fails.

Further, for the first SDP client device, the SDP controller obtaining the device identifier of the first SDP client device during the registration process includes: the first SDP client device sends registration information to the SDP controller, and the registration information includes user information and the device ID of the first SDP client device; the SDP controller receives the registration information, and after the device ID of the first SDP client device is approved, adds the device ID of the first SDP client device to the trusted device In the identification list; after the user information is approved, the user information is added to the trusted user information list.

Optionally, the registration information also includes information such as user level and access rights. For example, the registration information also includes the user's work domain, and the SDP controller also assigns at least one application that the user is allowed to access in the protected resources according to the work domain. A server is associated with the user to form a resource list for the user.

S203a: If the single-packet authentication of the first SDP client device fails, the SDP controller closes the TCP connection between the first SDP client device to which the first packet belongs and the SDP controller.

Wherein, the SDP controller closes the TCP connection between the first SDP client device to which the first message belongs and the SDP controller, or the SDP controller blocks the first SDP client device to which the first message belongs A TCP connection between the device and the SDP controller.

Optionally, if the SDP controller fails the single-packet authentication of the first SDP client device, the SDP controller also sends a single-packet authentication response to the first SDP client device, where the single-packet authentication response is used to indicate that the first Single-packet authentication of the SDP client device failed.

In this embodiment of the application, when the first SDP client device initiates single-packet authentication to the SDP controller, the first SDP client sends the first message to the SDP controller, and the TCP option field of the first message Carry the device identifier of the first SDP client device. When the SDP controller receives the first message, the SDP controller performs single-packet authentication on the first SDP client device based on the device identifier of the SDP client device carried in the TCP option field of the first message. If the single-packet authentication of the first SDP client device fails, the SDP controller closes the TCP connection between the SDP client device to which the first packet belongs and the SDP controller. In this way, when multiple SDP client devices use the same source IP address after being converted by the same SNAT device, the SDP controller can identify different SDP client devices, thereby ensuring the security of the protected application resources.

The above FIG. 4 shows the situation that the SDP controller fails to authenticate the single packet of the first SDP client device. FIG. 6 below shows the situation that the SDP controller succeeds in single-packet authentication of the second SDP client device. Wherein, the second SDP client device can initiate single-packet authentication to the SDP controller in the same manner as above-mentioned S201, and the SDP controller can also perform single-packet authentication on the second SDP client device in the same manner as above-mentioned S202. The embodiment will not be repeated here.

Further, as shown in FIG. 6, if the SDP controller succeeds in single-packet authentication of the second SDP client device, the method further includes S203b-S206.

S203b: The second SDP client device sends a second message to the SDP controller, the TLS option field of the second message or the application layer message header carries authentication information, and the authentication information includes the second SDP client device user information.

Wherein, the user information of the second SDP client device includes information of a user who logs in to the second SDP client device. Optionally, the user information includes a user name and a password, and the user name is set when the user registers with the SDP controller, or assigned by the SDP controller for the user when the user registers with the SDP controller.

In addition, in this embodiment, a "second message" is used to indicate a message for user authentication sent by the SDP client device to the SDP controller. The second message is a message carried on the TLS application layer, and the TLS option field of the second message or the header of the application layer carries the authentication information of the second SDP client device. The structure of the TLS option field is similar to the structure of the TCP option field in the first packet. For specific description, refer to the relevant description of the above TCP option field, which is not specifically limited in this embodiment of the present application. The authentication information carried in the TLS option field of the second packet is taken as an example for description below.

Specifically, if the SDP controller successfully authenticates the single packet of the second SDP client device, the second SDP client device sends a second message to the SDP controller, and the TLS option field of the second message or the application layer report The header carries authentication information of the second SDP client device, so as to initiate user authentication to the SDP controller through the second message.

Optionally, after the SDP controller performs single-packet authentication on the second SDP client device, if the single-packet authentication to the second SDP client device succeeds, the SDP controller sends a single-packet authentication to the second SDP client device An authentication response, where the single-packet authentication response is used to indicate that the single-packet authentication of the second SDP client device succeeds. When the second SDP client device receives the single-packet authentication response, the second SDP client device sends the second packet to the SDP controller.

In an example, as shown in FIG. 7, the second SDP client device generates the second message in the following manner: the local agent in the second SDP client device is through a hook added in a subsystem such as NetFilter ( The hook) function obtains the current application message from the upper layer protocol stack, and adds the authentication information of the second SDP client device to the application message. Figure 6 also shows the relevant NetFilter hook function mount points and routes, such as input local (LOCAL_IN), local output (LOCAL_OUT), pre-routing processing (PRE ROUTING), direct forwarding (FORWARD) and post-routing processing ( POST ROUTING), etc. For example, the second SDP client device adds the authentication information to the TLS option field of the application packet, and the second packet has been generated. Alternatively, the authentication information carried in the second packet is carried in a hypertext transfer protocol secure (hyper text transfer protocol secure, HTTPS) layer, for example, carried in an HTTPS tunnel (tunnel) encapsulation packet header. For example, when the protected resource is a service of the B/S system, the authentication information is carried in the HTTPS layer; when the protected resource is a service of the C/S system, the authentication information is carried in the in the TLS options field.

S204: When the SDP controller receives the second message, the SDP controller performs user authentication on the second SDP client device according to the device identifier of the second SDP client device and the user information.

When the SDP controller receives the second packet, the SDP controller parses the TLS option field of the second packet to obtain the user information. Afterwards, the SDP controller performs user authentication on the second SDP client device according to the user information and the device identifier of the second SDP client device. Optionally, the device identifier used for user authentication may be the device identifier carried in the TCP option field of the first packet, or the second packet also carries the device identifier. Exemplarily, the SDP controller compares the device identification and the user information of the second SDP client device with the device identification and the user information when the second SDP client device is registered; if the first packet carries The device identification and the user information carried in the second message are consistent with the device identification and the user information at the time of registration, and the SDP controller determines that the user authentication of the second SDP client device is successful; if the first message carries the The device identifier and the user information carried in the second message are inconsistent with the device identifier and the user information during registration, and the SDP controller determines that the user authentication of the second SDP client device fails.

It should be noted that the process for the SDP controller to authenticate the device ID carried in the first message and the device ID at the time of registration is consistent with the above-mentioned single-packet authentication process. For details, refer to the relevant description above. The embodiment of this application is in This will not be repeated here. In addition, for the process of the SDP controller authenticating the user information carried in the second message and the user information at the time of registration, refer to the description in the related art, which is not described in this embodiment of the present application.

In a possible embodiment, the first packet and the second packet sent by the second SDP client device are packets in the same TCP connection. Exemplarily, it is assumed that the first packet and the second packet are packets in the first TCP connection, the first packet is a SYN packet, and the second packet is an application packet. Specifically, in the process of establishing the first TCP connection, the second SDP client device sends the SYN message to the SDP controller, and the TCP option field of the SYN message carries the device identifier of the SDP client device; The SDP controller returns a synchronous confirmation (SYN+ACK) message to the second SDP client device; the second SDP client device sends the ACK message to the SDP controller, and the first TCP connection is successfully established; the second SDP client The end device sends the application message to the SDP controller through the first TCP connection, and the TLS option field of the application message carries the authentication information.

In another possible embodiment, the first packet sent by the second SDP client device and the second packet are packets in different TCP connections. Exemplarily, it is assumed that the first packet is a SYN packet in the first TCP connection, and the second packet is an application packet in the second TCP connection. Specifically, in the process of establishing the first TCP connection, the second SDP client device sends a SYN message to the SDP controller, and the TCP option field of the SYN message carries the device identifier of the second SDP client device; the SDP The controller returns a synchronization confirmation (SYN+ACK) message to the second SDP client device; the second SDP client device sends the ACK message to the SDP controller. After the establishment of the second TCP is completed, the second SDP client device sends an application message to the SDP controller, and the TLS option field of the application message carries the authentication information.

Optionally, if the first message sent by the second SDP client device and the second message are messages in different TCP connections, the second message sent by the second SDP client device to the SDP controller is also carry a salt value (salt), the salt value can be used to associate the TCP connection to which the first message belongs and the TCP connection to which the second message belongs, and the salt value is that the SDP controller sends a message to the second SDP client device After successful authentication, the single packet is sent to the second SDP client device. Exemplarily, before the second SDP client device sends the second message to the SDP controller, the method further includes: the SDP controller sends the second SDP client the second message according to the first message sent by the second SDP client device The end device sends the salt value. In this way, when the second SDP client device receives the salt value, the second SDP client device carries the salt value in the second message and sends it to the SDP controller. At this time, when the SDP controller receives the second message, the SDP controller can determine that the single-packet authentication of the second SDP client device has succeeded according to the salt value carried in the second message. Afterwards, the SDP controller performs user authentication on the second SDP client device according to the above S204.

Further, if the SDP controller fails to authenticate the user of the second SDP client device, then: if the first message and the second message are messages in the same TCP connection, the SDP controller closes the The TCP connection between the second SDP client device and the SDP controller; if the first message and the second message are messages in different TCP connections, the SDP controller closes the first message and the second message A TCP connection between the second SDP client device to which the file belongs and the SDP controller. If the SDP controller successfully authenticates the user of the second SDP client device, the SDP controller executes the following S205 and S206. Fig. 6 also shows the situation that the SDP controller successfully authenticates the user of the second SDP client device.

S205: The SDP controller sends a resource list to the second SDP client device, where the resource list includes an identifier of at least one application server that is allowed to be accessed by the second SDP client device.

Wherein, at least one application server that is allowed to be accessed by the second SDP client device belongs to a protected resource, and the protected resource also includes other resources except the at least one application server. The identifier of each application server in the at least one application server may be used to uniquely identify the application server. Optionally, the identifier of each application server in the at least one application server includes a port and an IP address of the application server.

In addition, the at least one application server that is allowed to be accessed by the second SDP client device is allocated by the SDP controller for the second SDP client device according to the user information of the second SDP client device. For example, the user information may be used to indicate information such as user level and access rights, and the SDP controller assigns the second SDP client device an application server that is allowed to be accessed by the second SDP client device according to the information such as the user level and the access rights.

Specifically, if the SDP controller successfully authenticates the user of the second SDP client device, the SDP controller obtains the identifier of the at least one application server according to the user information, that is, obtains the resource list, and sends the resource list to the second SDP client device. Two SDP client devices. In this way, the second SDP client device can receive the resource list, and initiate resource access to the SDP gateway based on the resource list.

Optionally, the SDP controller also sends token (token) information to the second SDP client device. For example, the SDP controller can send the token information to the second SDP client device by means of a set cookie, and the subsequent When the second SDP client device accesses the at least one application server, it carries the token information, and the token information can be used for access verification. Wherein, the token information includes one or more tokens. Optionally, the one or more tokens include a user token (user_token), a device token (device_token), an application token (app_token) and the like.

S206: The SDP controller sends client information to the SDP gateway, where the client information is used to indicate that the second SDP client device has passed the authentication, and the client information includes a device identifier of the second SDP client device.

If the SDP controller successfully authenticates the user of the second SDP client device, the SDP controller sends the client information of the second SDP client device to the SDP gateway. In this way, the SDP gateway can receive the client information, and subsequently, when the second SDP client device initiates resource access to the SDP gateway, the SDP gateway can send information to the second SDP client based on the device identifier in the client information. The access of the device is checked for legitimacy.

In a possible embodiment, the SDP controller sends a northbound message to the SDP gateway, where the northbound message carries client information. The northbound packet refers to a control packet sent through a northbound protocol such as Restful or Netconf. Optionally, the SDP controller can also send the source IP address and destination port that need to be released to the SDP gateway, that is, send the source IP address of the second SDP client device to the SDP gateway and allow the second SDP client device to access The port of at least one application server. The source IP address and destination port can be carried in the northbound message.

In the above process, when the SDP controller receives the first message sent by the second SDP client device, the SDP controller can authenticate the second SDP client device according to the flow shown in FIG. 8 below. Exemplarily, when the SDP controller receives the first message, the authentication process includes: the SDP controller judges whether the first message is a SYN message; if the first message is not a SYN message, The SDP controller ignores the first message; if the first message is a SYN message, the SDP controller judges whether the TCP option field of the first message carries the device identification of the second SDP client device; if The device identifier is not carried in the TCP option field of the first message, and the SDP controller closes the connection between the second SDP client device to which the first message belongs and the SDP controller; if the first message The device identification is carried in the TCP option field of the device, and it is judged whether the device identification is legal; if the device identification is not legal, then close the connection between the second SDP client device to which the first message belongs and the SDP controller; If the device identifier is legal, judge whether the user information in the second message sent by the second SDP client device is legal; if the user information in the second message is illegal, the SDP controller closes the The connection between the second SDP client device and the SDP controller; if the user information in the second message is legal, the SDP controller sends a resource list to the second SDP client device, and sends a resource list to the SDP gateway client information.

The above-mentioned Figures 6-8 show that after the SDP controller successfully authenticates the single packet of the second SDP client device, the second SDP client device sends a second message for user authentication to the SDP controller, and After the SDP controller successfully authenticates the user of the second SDP client device, it sends the resource list to the second SDP client device and sends the client information to the SDP gateway.

After the second SDP client device receives the resource list and the SDP gateway receives the client information through FIG. 9, the second SDP client device initiates resource access to the SDP gateway, and the SDP gateway initiates resource access to the second SDP client device. The case where the business data is returned after the access is verified and the verification is successful. As shown in FIG. 9 , the method further includes: S207-S210, and S201-S206 are not shown in FIG. 9 .

S207: The second SDP client device sends a third packet to the SDP gateway, where the TCP option field of the third packet carries the device identifier of the second SDP client device.

Wherein, in the embodiment of the present application, a "third message" is used to represent a message for resource access sent by the second SDP client device to the SDP gateway. Optionally, the third message is a synchronization (synchronous, SYN) message when the second SDP client device initiates a TCP connection to the SDP gateway.

In addition, the manner in which the device identifier of the second SDP client device is carried in the TCP option field of the third packet is similar to the manner in which the device identifier of the SDP client device is carried in the TCP option field of the first packet described in S201 above, For details, refer to related descriptions in S201 , which will not be repeated in this embodiment of the present application.

Optionally, the device identifier of the SDP client device carried in the TCP option field of the third message is a device identifier in ciphertext. The device identification in the cipher text form is obtained in the following manner: the second SDP client device obtains a character string of a specified length according to the device identification in the plain text form of the second SDP client device, and uses the second SDP client device to send a message to the SDP gateway The serial number of the SYN message when initiating a TCP connection performs AES symmetric encryption on the character string to obtain the device identification in the ciphertext form.

Specifically, when the second SDP client device receives the resource list sent by the SDP controller, the second SDP client device sends a third message to the SDP gateway according to the resource list, and the third message can be used to request access For the application server in the at least one application server, the TCP option field of the third packet carries the device identifier of the second SDP client device.

Optionally, the third message also carries token information, which is used by the SDP gateway to verify the resource access initiated by the second SDP client device. For example, the token information includes a user token, a device token and an application token, the user token can be used by the SDP gateway to verify the user information of the second SDP client device, and the device token can be used in the SDP The gateway verifies the second SDP client device, and the application token can be used by the SDP gateway to verify the application server accessed by the second SDP client device.

In another possible embodiment, the above S207 can be replaced by: the second SDP client device sends a third message to the SDP gateway, and the TLS option field of the third message carries the second SDP client device device ID. Regarding the second SDP client device carrying the device identifier of the second SDP client device in the TLS option field of the third message and the device identifier of the second SDP client device carried in the TCP option field of the third message The difference is consistent with the relevant description of the first packet in S201 above, and will not be described again in this embodiment of the present application.

S208: When the SDP gateway receives the third packet, the SDP gateway determines whether the second SDP client device is legitimate according to the device identifier included in the client information and the device identifier included in the third packet.

When the SDP gateway receives the client information sent by the SDP controller, the SDP gateway parses the client information to obtain the device identifier included in the client information. When the SDP gateway receives the third packet, the SDP gateway parses the TCP option field of the third packet to obtain the device identifier included in the third packet. Afterwards, the SDP gateway determines whether the second SDP client device is legitimate according to the device identifier included in the client information and the device identifier included in the third message. If the device identification included in the client information is consistent with the device identification included in the third message, it is determined that the second SDP client device is legal; if the device identification included in the client information is consistent with the device identification included in the third message If they are inconsistent, it is determined that the second SDP client device is illegal.

Optionally, if the device identification of the SDP client device carried in the TCP option field of the third message is a device identification in ciphertext form, the SDP gateway also performs the following steps: use the serial number of the third message to the cipher text Decrypt the device identification in text form to obtain a first character string of a specified length, and the first character string is used by the SDP gateway to determine whether the second SDP client device is legitimate.

In an example, the SDP gateway determines whether the second SDP client device is legitimate according to the device identifier included in the client information and the device identifier included in the third message, including: the SDP gateway according to the device identifier included in the client information Obtain a second character string of a specified length, for example, the SDP gateway obtains a second character string of a specified length by performing the hash operation on the device identifier included in the client information; the SDP gateway compares the first character string with the second character string Two character strings; if the first character string is consistent with the second character string, it is determined that the second SDP client device is legal; if the first character string is inconsistent with the second character string, it is determined that the second SDP client device is not legal.

Optionally, the third message also carries the source IP address of the second SDP client device, and the client information also includes the source IP address of the second SDP client device, and the SDP gateway can also include the source IP address in the client information. When the source IP address is consistent with the source IP address in the third packet, it is determined that the source IP address of the second SDP client device is legal.

In a possible embodiment, the third message further carries token information, and the token information is used by the SDP gateway to verify the resource access initiated by the second SDP client device. Correspondingly, when the SDP gateway receives the third message, the SDP gateway can also send the token information to the SDP controller to request the SDP controller to verify the token information; when the SDP When the gateway receives the information that the token verification is successful sent by the SDP controller, the SDP gateway determines that the resource access initiated by the second SDP client device is legal.

S209: If it is determined that the second SDP client device is legal, the SDP gateway sends the third packet to the application server.

Wherein, the application server is an application server that the second SDP client device requests to access, and the application server belongs to at least one application server that is allowed to be accessed by the second SDP client device.

In an example, the port of the application server is also carried in the third message, and when the SDP gateway determines that the second SDP client device is legal, the SDP gateway sends the third message to the The application server.

S210: The SDP gateway receives the service data returned by the application server, and forwards the service data to the second SDP client device.

When the SDP gateway sends the third message to the application server, and the application server receives the third message, the application server can return corresponding service data to the SDP gateway according to the third message. When the SDP gateway receives the service data returned by the application server, the SDP gateway forwards the service data to the second SDP client device. In this way, the second SDP client device can receive the service data, so that the second SDP client device can access the application server.

In the embodiment of the present application, the second SDP client device sends a third message to the SDP gateway, and the TCP option field of the third message carries the device identifier of the second SDP client device. When the SDP gateway receives the third message, the SDP gateway can identify the second SDP client device based on the device identifier carried in the third message and the device identifier in the client information issued by the SDP controller. Validate legality. If it is determined that the second SDP client device is legal, the SDP gateway forwards the third message to the application server, and forwards the service data returned by the application server to the second SDP client device. In this way, when multiple SDP client devices use the same source IP address after being converted by the same SNAT device, the SDP gateway can identify different SDP client devices, thereby ensuring the security of protected application resources.

The foregoing mainly introduces the solutions provided by the embodiments of the present application from the perspective of interaction between various devices. It can be understood that, in order to realize the above-mentioned functions, the above-mentioned SDP controller, SDP client device, and SDP gateway include corresponding hardware structures and/or software modules for performing various functions. Those skilled in the art should easily realize that the present application can be implemented in the form of hardware or a combination of hardware and computer software in combination with the units and algorithm steps of each example described in the embodiments disclosed herein. Whether a certain function is executed by hardware or computer software drives hardware depends on the specific application and design constraints of the technical solution. Skilled artisans may use different methods to implement the described functions for each specific application, but such implementation should not be regarded as exceeding the scope of the present application.

The embodiment of the present application can divide the functional modules of the SDP controller, the SDP client device and the SDP gateway according to the above method example, for example, each functional module can be divided corresponding to each function, or two or more functions can be integrated in a processing module. The above-mentioned integrated modules can be implemented in the form of hardware or in the form of software function modules. It should be noted that the division of modules in the embodiment of the present application is schematic, and is only a logical function division, and there may be other division methods in actual implementation.

In the case of using an integrated unit, FIG. 10 shows a possible structural diagram of the access control device involved in the embodiment of the present application. The device can be used as an SDP controller or a built-in chip of the SDP controller. The device It includes: a receiving unit 301 , a processing unit 302 and a sending unit 303 . The SDP controller with the structure shown in FIG. 10 can realize the function of the SDP controller in the solutions described in the above method embodiments.

In a possible embodiment, the receiving unit 301 is configured to receive the first message sent by the first SDP client device, and the transmission control protocol TCP option field of the first message carries the device identifier of the first SDP client device . The processing unit 302 is configured to perform single-packet authentication on the first SDP client device according to the device identifier of the first SDP client device, and if the single-packet authentication to the first SDP client device fails, close the first A TCP connection between the SDP client device and the SDP controller.

In another possible embodiment, the receiving unit 301 is further configured to receive the first message sent by the second SDP client device, and the TCP option field of the first message sent by the second SDP client device carries the second Device ID of the SDP client device. The processing unit 302 is also configured to perform single-packet authentication on the second SDP client device according to the device identifier of the second SDP client device; the receiving unit 301 is also configured to receive the second SDP client device if the single-packet authentication to the second SDP client device succeeds. In the second message sent by the SDP client device, the TLS option field of the second message or the application layer carries authentication information, and the authentication information includes user information of the second SDP client device. The processing unit 302 is further configured to perform user authentication on the second SDP client device according to the device identifier of the second SDP client device and the user information. The sending unit 303 is configured to send a resource list to the second SDP client device if the user authentication of the second SDP client device is successful, the resource list includes an identifier of at least one application server that the second SDP client device is allowed to access.

Optionally, the first packet and the second packet sent by the second SDP client device are packets in the same TCP connection; or, the first packet and the second packet sent by the second SDP client device are packets in different TCP connections.

Further, if the first packet and the second packet sent by the second SDP client device are packets in different TCP connections: the sending unit 303 is also configured to send the first packet according to the second SDP client device. The second SDP client device sends the salt value. Correspondingly, the second message also carries the salt value, and the processing unit 302 is further configured to determine that the single-packet authentication of the second SDP client device has succeeded according to the salt value carried in the second message.

Optionally, the first packet sent by the first SDP client device is a SYN packet. Further, the device identification carried in the first message sent by the first SDP client device is a device identification in ciphertext form, and the processing unit 302 is further configured to: use the serial number of the SYN message to the ciphertext form of the device identification The device identifier is decrypted to obtain a character string of a specified length, which is used by the SDP controller to perform single-packet authentication on the first SDP client device. Similarly, the first packet sent by the second SDP client device also satisfies the above description.

Further, if the user authentication of the second SDP client device is successful, the sending unit 303 is further configured to: send client information to the SDP gateway, where the client information is used to indicate that the second SDP client device has passed the authentication, and the client The information includes a device identification of the second SDP client device.

It should be noted that all relevant content of the steps involved in the above method embodiments can be referred to the function description of the corresponding function module, and will not be repeated here.

On the basis of hardware implementation, the processing unit 302 in the embodiment of the present application may be the processor of the device, the sending unit 303 may be the transmitter of the device, and the receiving unit 301 may be the receiver of the device. It can be integrated with the receiver as a transceiver, and the specific transceiver can also be called a communication interface or an interface circuit.

As shown in Figure 11, it is a schematic diagram of another possible structure of the access control device involved in the above embodiment provided by the embodiment of the present application. The device can be used as an SDP controller or a built-in chip of the SDP controller. The device It includes: a processor 311 , and may further include a memory 312 , a communication interface 313 and a bus 314 , and the processor 311 , the memory 312 and the communication interface 313 are connected through the bus 314 .

Wherein, the processor 311 is used for controlling and managing the actions of the device. In a possible embodiment, the processor 311 may be configured to support the device to execute one or more steps in S202, S203a, S204, S208 in the above method embodiments, and/or other technical processes described herein. The communication interface 313 is used to support the device to communicate, for example, to support the device to communicate with the SDP client device and the SDP gateway.

In the embodiment of the present application, the processor 311 may be a central processing unit, a general processor, a digital signal processor, an application specific integrated circuit, a field programmable gate array or other programmable logic devices, transistor logic devices, hardware components or other random combination. It can implement or execute the various illustrative logical blocks, modules and circuits described in connection with the present disclosure. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, and the like. The above-mentioned bus 314 in FIG. 11 may be a peripheral component interconnect standard (peripheral component interconnect, PCI) bus or an extended industry standard architecture (extended industry standard architecture, EISA) bus or the like. The bus can be divided into address bus, data bus, control bus and so on. For ease of representation, only one thick line is used in the above-mentioned FIG. 11 , but it does not mean that there is only one bus or one type of bus.

In the case of using an integrated unit, FIG. 12 shows a possible structural diagram of the access control device involved in the embodiment of the present application. The device can be used as an SDP client device or a built-in chip of the SDP client device. The device includes: a sending unit 401 , a receiving unit 402 and a processing unit 403 . The SDP client device with the structure shown in FIG. 12 can implement the functions of the SDP client device in the solutions described in the above method embodiments.

In a possible embodiment, the sending unit 401 is configured to send a first packet to the SDP controller, where the Transmission Control Protocol TCP option field of the first packet carries the device identifier of the SDP client device. If the single-packet authentication of the SDP client device by the SDP controller fails, the SDP controller closes the TCP connection corresponding to the first packet.

In another possible embodiment, if the single-packet authentication of the SDP client device by the SDP controller succeeds, the sending unit 401 is further configured to send a second message to the SDP controller, and the secure transmission of the second message The layer protocol TLS option field or the application layer carries authentication information, and the authentication information includes user information of the SDP client device. The receiving unit 402 is further configured to receive a resource list returned by the SDP controller, where the resource list includes an identifier of at least one application server that is allowed to be accessed by the SDP client device.

Optionally, the first packet and the second packet are packets in the same TCP connection; or, the first packet and the second packet are packets in different TCP connections. Further, when the first message and the second message are messages in different TCP connections, the receiving unit 402 is also used to: receive the salt value returned by the SDP controller according to the first message; correspondingly, the second The salt value is also carried in the message, and the salt value carried in the second message is used by the SDP controller to determine that the single-packet authentication of the second SDP client device has succeeded.

Optionally, the first packet is a synchronous SYN packet. Further, the device identification carried in the TCP option field is a device identification in ciphertext form, and the processing unit 403 is configured to obtain a character string of a specified length based on the device identification in plain text form of the SDP client device, and use the SYN report Encrypt the string with the serial number of the text to obtain the device identification in the form of cipher text. In an embodiment, the character string of the specified length is obtained by performing a hash operation on the plaintext device identifier.

Further, the sending unit 401 is further configured to send a third message to the SDP gateway, and the TCP option field of the third message carries the device identifier of the SDP client device. The receiving unit 402 is configured to receive the service data returned by the application server, the service data is that the SDP gateway forwards the third message after determining that the SDP client device is legal according to the device identifier carried in the TCP option field of the third message After sending to the application server, the application server sends it.

Optionally, the third packet is a SYN packet. The device identifier carried in the TCP option field of the third packet is a device identifier in cipher text.

It should be noted that all relevant content of the steps involved in the above method embodiments can be referred to the function description of the corresponding function module, and will not be repeated here.

On the basis of hardware implementation, the processing unit 403 in the embodiment of the present application can be the processor of the device, the sending unit 401 can be the transmitter of the device, and the receiving unit 402 can be the receiver of the device, and the transmitter usually It can be integrated with the receiver as a transceiver, and the specific transceiver can also be called a communication interface or an interface circuit.

As shown in FIG. 13 , it is a schematic diagram of another possible structure of the access control device involved in the above-mentioned embodiment provided by the embodiment of the present application. The device can be used as an SDP client device or a built-in chip of the SDP client device. The device includes: a processor 411 , and may further include a memory 412 , a communication interface 413 and a bus 414 , and the processor 411 , the memory 412 and the communication interface 413 are connected through the bus 414 .

Wherein, the processor 411 is used for controlling and managing the actions of the device. In a possible embodiment, the processor 411 may be configured to support the device in performing the steps of encrypting the device identification of the SDP client device, generating the first to third messages, and parsing the SDP control One or more of the steps such as the information sent by the router and the SDP gateway. The communication interface 413 is used to support the device to communicate, for example, to support the device to communicate with the SDP controller and the SDP gateway.

In the embodiment of the present application, the processor 411 may be a central processing unit, a general processor, a digital signal processor, an application specific integrated circuit, a field programmable gate array or other programmable logic devices, transistor logic devices, hardware components or other random combination. It can implement or execute the various illustrative logical blocks, modules and circuits described in connection with the present disclosure. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, and the like. The above-mentioned bus 414 in FIG. 13 may be a PCI bus or an EISA bus or the like. The bus can be divided into address bus, data bus, control bus and so on. For ease of representation, only one thick line is used in the above-mentioned FIG. 13 , but it does not mean that there is only one bus or one type of bus.

In the case of using an integrated unit, Fig. 14 shows a possible structural diagram of the access control device involved in the embodiment of the present application. The device can be used as an SDP gateway or a built-in chip of the SDP gateway. The device includes: A receiving unit 501 , a processing unit 502 and a sending unit 503 . The SDP gateway with the structure shown in FIG. 14 can realize the function of the SDP gateway in the solutions described in the above method embodiments.

Wherein, the receiving unit 501 is configured to receive client information sent by the SDP controller, the client information is used to indicate that the SDP client device passes the authentication, and the client information includes the device identifier of the SDP client device. The receiving unit 501 is further configured to receive a third message sent by the SDP client device, where the TCP option field of the third message carries the device identifier of the SDP client device. The processing unit 502 is configured to determine whether the SDP client device is legitimate according to the device identifier included in the client information and the device identifier included in the third packet. The sending unit 503 is configured to send the third message to the application server if it is determined that the SDP client device is legal, and forward the service data returned by the application server to the SDP client device.

In one embodiment, the third message is a SYN message. Optionally, the device identifier carried in the TCP option field is a device identifier in ciphertext, and the processing unit 502 is further configured to: use the serial number of the SYN message to decrypt the device identifier in ciphertext to obtain the specified length of the first character string, the first character string is used by the SDP gateway to determine whether the SDP client device is legitimate. Further, the processing unit 502 is also configured to: obtain the second character string of the specified length according to the device identification included in the client information; compare the first character string with the second character string; if the first character string and the second character string If the strings are consistent, it is determined that the SDP client device is legal.

It should be noted that all relevant content of the steps involved in the above method embodiments can be referred to the function description of the corresponding function module, and will not be repeated here.

On the basis of hardware implementation, the processing unit 502 in the embodiment of the present application can be the processor of the device, the receiving unit 501 can be the receiver of the device, and the sending unit 503 can be the transmitter of the device, and the transmitter usually It can be integrated with the receiver as a transceiver, and the specific transceiver can also be called a communication interface or an interface circuit.

As shown in Figure 15, another possible structural diagram of the access control device involved in the above-mentioned embodiment provided by the embodiment of the present application, the device can be used as an SDP gateway or a built-in chip of the SDP gateway, and the device includes: The processor 511 may further include a memory 512 , a communication interface 513 and a bus 514 , and the processor 511 , the memory 512 and the communication interface 513 are connected through the bus 514 .

Wherein, the processor 511 is used to control and manage the actions of the device. In a possible embodiment, the processor 511 may be configured to support the device to receive S208 in the foregoing method embodiment, and/or other technical processes described herein. The communication interface 513 is used to support the apparatus to communicate, for example, to support the apparatus to communicate with the SDP controller and the SDP client device.

In the embodiment of the present application, the processor 511 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic devices, transistor logic devices, hardware components, or other random combination. It can implement or execute the various illustrative logical blocks, modules and circuits described in connection with the present disclosure. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, and the like. The above-mentioned bus 514 in FIG. 15 may be a PCI bus or an EISA bus or the like. The bus can be divided into address bus, data bus, control bus and so on. For ease of representation, only one thick line is used in the above-mentioned FIG. 15 , but it does not mean that there is only one bus or one type of bus.

The embodiment of the present application also provides an access control system, which may include an SDP controller, an SDP client device, and an SDP gateway. The SDP controller, the SDP client device and the SDP gateway can be used to implement any one of the access control methods provided in the foregoing method embodiments.

It should be noted that all relevant content of the steps involved in the above method embodiments can be referred to the function description of the corresponding function module, and will not be repeated here. Each device (SDP controller, SDP client device, and SDP gateway) provided in the embodiment of the present application is used to perform the function of the corresponding device in the above embodiment, so the same effect as the above method embodiment can be achieved.

The functions or actions or operations or steps in the above-mentioned embodiments may be fully or partially implemented by software, hardware, firmware or any combination thereof. When implemented using a software program, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, the processes or functions according to the embodiments of the present application will be generated in whole or in part. The computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website, computer, server, or data center Transmission to another website site, computer, server or data center by wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that can be accessed by a computer, or may include one or more data storage devices such as servers and data centers that can be integrated with the medium. The available medium may be a magnetic medium (such as a floppy disk, a hard disk, or a magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk (solid state disk, SSD)), etc.

Based on this, an embodiment of the present application also provides a computer-readable storage medium, the computer-readable storage medium includes computer instructions, and when the computer instructions are run on a computer device, the steps of the SDP controller in the above-mentioned method embodiments are executed .

In yet another aspect of the present application, a computer-readable storage medium is provided, the computer-readable storage medium includes computer instructions, and when the computer instructions are run on a computer device, the SDP client device in the above-mentioned method embodiment is executed. step.

In yet another aspect of the present application, a computer-readable storage medium is provided, the computer-readable storage medium includes computer instructions, and when the computer instructions are executed, the steps of the SDP gateway in the above method embodiments are executed.

In yet another aspect of the present application, a computer program product containing instructions is provided, and when the computer program product is run on a computer device, the computer device is made to execute the steps of the SDP controller in the above method embodiments.

In yet another aspect of the present application, a computer program product containing instructions is provided, and when the computer program product is run on the computer device, the computer device is made to execute the steps of the SDP client device in the above method embodiments.

In yet another aspect of the present application, a computer program product containing instructions is provided, and when the computer program product is run on a computer device, the computer device is made to execute the steps of the SDP gateway in the above method embodiments.

Finally, it should be noted that: the above is only a specific implementation of the application, but the scope of protection of the application is not limited thereto, and any changes or replacements within the technical scope disclosed in the application shall be covered by this application. within the scope of the application. Therefore, the protection scope of the present application should be determined by the protection scope of the claims.

Claims (47)

1. An access control method, characterized in that the method comprises: The software-defined boundary SDP controller receives the first message sent by the first SDP client device, and the transmission control protocol TCP option field of the first message carries the device identifier of the first SDP client device; The SDP controller performs single-packet authentication on the first SDP client device according to the device identifier of the first SDP client device; If the single-packet authentication of the first SDP client device fails, the SDP controller closes the TCP connection between the first SDP client device to which the first packet belongs and the SDP controller. 2. The method according to claim 1, characterized in that the method further comprises: The SDP controller receives the first message sent by the second SDP client device, and the TCP option field of the first message sent by the second SDP client device carries the Equipment Identity; The SDP controller performs single-packet authentication on the second SDP client device according to the device identifier of the second SDP client device; If the single-packet authentication to the second SDP client device is successful, the SDP controller receives the second message sent by the second SDP client device, and the secure transport layer protocol TLS option of the second message Carry authentication information in the field or the application layer message header, and the authentication information includes the user information of the second SDP client device; The SDP controller performs user authentication on the second SDP client device according to the device identifier of the second SDP client device and the user information; If the user authentication of the second SDP client device is successful, the SDP controller sends a resource list to the second SDP client device, and the resource list includes at least The identity of an application server. 3. The method according to claim 2, wherein the first message and the second message sent by the second SDP client device are messages in the same TCP connection; or, The first packet and the second packet sent by the second SDP client device are packets in different TCP connections. 4. The method according to claim 3, wherein if the first message and the second message sent by the second SDP client device are messages in different TCP connections, the Before the SDP controller receives the second message sent by the second SDP client device, the method further includes: The SDP controller sends a salt value to the second SDP client device according to the first message sent by the second SDP client device; The second message also carries the salt value, and after the SDP controller receives the second message sent by the second SDP client device, the method further includes: The SDP controller determines, according to the salt value carried in the second message, that the single-packet authentication of the second SDP client device has succeeded. 5. The method according to any one of claims 1-4, wherein the first message sent by the first SDP client device is a synchronous SYN message. 6. The method according to claim 5, wherein the device identifier carried in the first message sent by the first SDP client device is a device identifier in ciphertext form, and the method further includes: include: The SDP controller uses the serial number of the SYN message to decrypt the device identification in the ciphertext form to obtain a character string of a specified length, and the character string is used by the SDP controller to perform an operation on the first SDP The client device performs single-packet authentication. 7. The method according to claim 6, wherein the SDP controller performs single-package authentication on the first SDP client device according to the device identifier of the first SDP client device, comprising: The SDP controller compares the character strings corresponding to the saved registered SDP client devices using the character strings, wherein the character strings corresponding to the registered SDP client devices are based on the registered SDP client Generated by the device identification in clear text form of the end device; If the character string is the same as a character string corresponding to a registered SDP client device, it is determined that the single-packet authentication is successful. 8. The method according to any one of claims 2-7, wherein if the user authentication to the second SDP client device is successful, the method further comprises: The SDP controller sends client information to the SDP gateway, where the client information is used to indicate that the second SDP client device passes the authentication, and the client information includes the device identifier of the second SDP client device. 9. An access control method, characterized in that the method comprises: The software-defined boundary SDP client device sends a first message to the SDP controller, and the Transmission Control Protocol TCP option field of the first message carries the device identifier of the SDP client device. 10. The method according to claim 9, further comprising: The SDP client device receives the single-packet authentication response sent by the SDP controller, and if the single-packet authentication response is used to indicate that the single-packet authentication of the SDP client device by the SDP controller is successful, the SDP The client device sends a second message to the SDP controller, where the TLS option field of the second message or the application layer header carries authentication information, and the authentication information includes the SDP user information of the client device; The SDP client device receives the resource list returned by the SDP controller, where the resource list includes an identifier of at least one application server that the SDP client device is allowed to access. 11. The method according to claim 10, wherein the first message and the second message are messages in the same TCP connection; or, the first message and the second message are The second packets are packets in different TCP connections. 12. The method according to claim 11, wherein when the first message and the second message are messages in different TCP connections, the SDP client device sends the SDP control Before the device sends the second message, the method also includes: The SDP client device receives the salt value returned by the SDP controller according to the first message; The second message also carries the salt value, and the salt value carried in the second message is used by the SDP controller to determine that the single-packet authentication of the second SDP client device has succeeded. 13. The method according to any one of claims 9-12, wherein the first message is a synchronous SYN message. 14. The method according to claim 13, wherein the device identification carried in the TCP option field is a device identification in ciphertext form, the method further comprising: Acquiring a character string of a specified length based on the device identification in clear text of the SDP client device; The character string is encrypted by using the serial number of the SYN message to obtain the device identifier in ciphertext form. 15. The method according to claim 14, wherein the character string of the specified length is obtained by hashing the plaintext device identification. 16. The method according to any one of claims 9-15, wherein after the SDP client device receives the resource list returned by the SDP controller, the method further comprises: The SDP client device sends a third message to the SDP gateway, and the TCP option field of the third message carries the device identifier of the SDP client device; The SDP client device receives the service data returned by the application server, and the service data is determined by the SDP gateway according to the device identifier carried in the TCP option field of the third message. After the third packet is legally forwarded to the application server, the application server sends it. 17. The method according to claim 16, wherein the third message is a synchronous SYN message. 18. An access control method, characterized in that the method comprises: The software-defined boundary SDP gateway receives the client information sent by the SDP controller, the client information is used to indicate that the SDP client device has passed the authentication, and the client information includes the device identifier of the SDP client device; The SDP gateway receives the third message sent by the SDP client device, and the TCP option field of the third message carries the device identifier of the SDP client device; The SDP gateway determines whether the SDP client device is legal according to the device identifier included in the client information and the device identifier included in the third message; If it is determined that the SDP client device is legal, the SDP gateway sends the third packet to the application server, and forwards the service data returned by the application server to the SDP client device. 19. The method according to claim 18, wherein the third message is a synchronous SYN message. 20. The method according to claim 19, wherein the device identification carried in the TCP option field is a device identification in ciphertext form, the method further comprising: The SDP gateway uses the serial number of the SYN message to decrypt the device identification in ciphertext form to obtain a first character string of a specified length, and the first character string is used by the SDP gateway to determine the SDP Whether the client device is legitimate. 21. The method according to claim 20, wherein the SDP gateway determines the SDP client according to the device identifier included in the client information and the device identifier included in the third message Whether the end device is legal, including: The SDP gateway obtains the second character string of the specified length according to the device identification included in the client information; The SDP gateway compares the first character string and the second character string; If the first character string is consistent with the second character string, it is determined that the SDP client device is legal. 22. An access control device, characterized in that the device is used as a software-defined boundary SDP controller or a built-in chip of the SDP controller, comprising: A receiving unit, configured to receive a first message sent by a first SDP client device, wherein the Transmission Control Protocol TCP option field of the first message carries the device identifier of the first SDP client device; A processing unit, configured to perform single-packet authentication on the first SDP client device according to the device identifier of the first SDP client device; The processing unit is further configured to close the communication between the first SDP client device to which the first message belongs and the SDP controller if the single-packet authentication of the first SDP client device fails. TCP connection. 23. The device according to claim 22, further comprising: a sending unit; The receiving unit is further configured to receive the first message sent by the second SDP client device, the TCP option field of the first message sent by the second SDP client device carries the second SDP client The device identification of the end device; The processing unit is further configured to perform single-packet authentication on the second SDP client device according to the device identifier of the second SDP client device; The receiving unit is further configured to receive a second message sent by the second SDP client device if the single-packet authentication of the second SDP client device is successful, and the security transport layer of the second message The protocol TLS option field or the application layer header carries authentication information, and the authentication information includes user information of the second SDP client device; The processing unit is further configured to perform user authentication on the second SDP client device according to the device identifier of the second SDP client device and the user information; The sending unit is configured to send a resource list to the second SDP client device if the user authentication of the second SDP client device is successful, and the resource list includes the resources that are allowed to be accessed by the second SDP client device. The identity of at least one application server for . 24. The apparatus according to claim 23, wherein the first message and the second message sent by the second SDP client device are messages in the same TCP connection; or, The first packet and the second packet sent by the second SDP client device are packets in different TCP connections. 25. The apparatus according to claim 24, wherein if the first message and the second message sent by the second SDP client device are messages in different TCP connections: The sending unit is further configured to send a salt value to the second SDP client device according to the first message sent by the second SDP client device; The second message also carries the salt value, and the processing unit is further configured to determine that the single-packet authentication of the second SDP client device has succeeded according to the salt value carried in the second message . 26. The apparatus according to any one of claims 22-25, wherein the first packet sent by the first SDP client device is a synchronous SYN packet. 27. The device according to claim 26, wherein the device identifier carried in the first message sent by the first SDP client device is a device identifier in ciphertext form, and the processing unit Also used for: Use the serial number of the SYN message to decrypt the device identifier in ciphertext form to obtain a character string of a specified length, and the character string is used by the SDP controller to single-handle the first SDP client device Package authentication. 28. The device according to claim 27, wherein the processing unit is further configured to: Use the character string to compare with the character string corresponding to each registered SDP client device, wherein the character string corresponding to the registered SDP client device is based on the plain text form of the registered SDP client device Generated by the device identification; If the character string is the same as a character string corresponding to a registered SDP client device, it is determined that the single-packet authentication is successful. 29. The device according to any one of claims 23-28, wherein if the user authentication of the second SDP client device is successful, the sending unit is further configured to: Send client information to the SDP gateway, where the client information is used to indicate that the second SDP client device has passed the authentication, and the client information includes the device identifier of the second SDP client device. 30. An access control device, characterized in that the device is used as a software-defined boundary SDP client device or a built-in chip of the SDP client device, comprising: A sending unit, configured to send a first message to the SDP controller, where the Transmission Control Protocol TCP option field of the first message carries the device identifier of the SDP client device. 31. The device according to claim 30, further comprising a receiving unit; The receiving unit is configured to receive the single-packet authentication response sent by the SDP controller; The sending unit is further configured to send a second message to the SDP controller if the single-packet authentication response is used to indicate that the SDP controller succeeds in single-packet authentication of the SDP client device, and the Carry authentication information in the secure transport layer protocol TLS option field of the second message or the application layer message header, and the authentication information includes the user information of the SDP client device; The receiving unit is further configured to receive a resource list returned by the SDP controller, where the resource list includes an identifier of at least one application server that is allowed to be accessed by the SDP client device. 32. The device according to claim 31, wherein the first packet and the second packet are packets in the same TCP connection; or, the first packet and the second packet The second packets are packets in different TCP connections. 33. The device according to claim 32, wherein when the first message and the second message are messages in different TCP connections, the receiving unit is further configured to: receiving the salt value returned by the SDP controller according to the first message; The second message also carries the salt value, and the salt value carried in the second message is used by the SDP controller to determine that the single-packet authentication of the second SDP client device has succeeded. 34. The device according to any one of claims 30-33, wherein the first message is a synchronous SYN message. 35. The device according to claim 34, wherein the device identifier carried in the TCP option field is a device identifier in ciphertext, the device further comprising: A processing unit, configured to obtain a character string of a specified length based on the device identification in plain text of the SDP client device, and encrypt the character string using the serial number of the SYN message to obtain the character string in cipher text Equipment Identity. 36. The device according to claim 35, wherein the character string of the specified length is obtained by performing a hash operation on the plaintext device identification. 37. The device according to any one of claims 30-36, further comprising: a receiving unit; The sending unit is further configured to send a third message to the SDP gateway, where the TCP option field of the third message carries the device identifier of the SDP client device; The receiving unit is configured to receive the service data returned by the application server, the service data is determined by the SDP gateway according to the device identifier carried in the TCP option field of the third message. After the device is legal and forwards the third packet to the application server, it is sent by the application server. 38. The device according to claim 37, wherein the third message is a synchronous SYN message. 39. An access control device, characterized in that the device is a software-defined boundary SDP gateway or a built-in chip of the SDP gateway, comprising: The receiving unit is configured to receive client information sent by the SDP controller, the client information is used to indicate that the SDP client device has passed the authentication, and the client information includes the device identifier of the SDP client device; The receiving unit is further configured to receive a third message sent by the SDP client device, where the TCP option field of the third message carries the device identifier of the SDP client device; A processing unit, configured to determine whether the SDP client device is legal according to the device identifier included in the client information and the device identifier included in the third message; A sending unit, configured to send the third message to the application server if it is determined that the SDP client device is legal, and forward the service data returned by the application server to the SDP client device. 40. The device according to claim 39, wherein the third message is a synchronous SYN message. 41. The device according to claim 40, wherein the device identifier carried in the TCP option field is a device identifier in ciphertext form, and the processing unit is further configured to: Use the serial number of the SYN message to decrypt the device identification in ciphertext form to obtain a first character string of a specified length, and the first character string is used by the SDP gateway to determine whether the SDP client device is legitimate. 42. The device according to claim 41, wherein the processing unit is further configured to: Obtaining the second character string of the specified length according to the device identification included in the client information; comparing said first character string with said second character string; If the first character string is consistent with the second character string, it is determined that the SDP client device is legal. 43. An access control device, characterized in that the device includes a processor and a memory, and instructions are stored in the memory, and the processor executes the instructions, so that the device performs any one of claims 1-8. The access control method described in the item. 44. An access control device, characterized in that the device includes a processor and a memory, and instructions are stored in the memory, and the processor executes the instructions, so that the device performs any one of claims 9-17. The access control method described in the item. 45. An access control device, characterized in that the device includes a processor and a memory, and instructions are stored in the memory, and the processor executes the instructions, so that the device performs any one of claims 18-21. The access control method described in the item. 46. An access control system, characterized in that the system includes: an SDP controller, an SDP client device, and an SDP gateway; wherein the SDP controller includes any one of claims 22-29 or claim 43 In the access control device, the SDP client device includes the access control device according to any one of claims 30-38 or claim 44, and the SDP gateway includes any one of claims 39-42 or the access control device according to claim 44. The access control device of claim 45. 47. A computer-readable storage medium, characterized in that the instructions stored in the computer-readable storage medium, when the instructions are run on a computer device, make the computer device execute any of claims 1-8. The access control method described in one item, or the access control method described in any one of claims 9-17, or the access control method described in any one of claims 18-21.

Images