Client security distribution method based on network invisibility in zero trust mode

Abstract

The present invention discloses a client security distribution method based on network invisibility in a zero-trust mode, which distributes clients in a targeted and directional manner through emails or text messages, and automatically and dynamically embeds SDP controller information when the SDP controller configures the client software, so that the client distributed to each user is unique. This also achieves "special terminal for special purpose", and even two legal users cannot mix each other's clients. The built-in knock code in the present invention changes after the first use, and is reversely updated to the installed client, so that the downloaded client software automatically becomes invalid. At the same time, because the present invention has the latest SDP controller global policy and user policy built into the client that the legal user has downloaded, the global policy and user policy can be obtained before knocking on the SDP controller, and the corresponding global policy and user policy can be executed before the user logs in.

Description

Technical Field

[0001] The present invention belongs to the field of computer networks, and in particular relates to a client security distribution method based on network invisibility in a zero-trust mode. Background Art

[0002] The zero-trust SDP security model includes the SDP controller, SDP gateway, and SDP client. The SDP client initiates a connection request, the SDP controller authenticates the client request, and controls the SDP client to establish a data channel with the SDP gateway.

[0003] The SDP client carries authentication information through knocking technology, including user name, password, terminal information, network environment, etc., and then the SDP controller verifies the multi-factor identity of the combination of these authentication information and returns the SDP gateway list and permission list to the client; the SDP controller itself has security policy management, which can dynamically control the user's authentication and access behavior, and connect with the company's existing identity management, situational awareness and other systems; by default, the SDP gateway rejects all connection requests. Only after the SDP controller issues an authentication policy will it dynamically accept the connection of the specified SDP client, and proxy the data communication between the SDP client and the application through encrypted transmission, and manage the communication process according to the control policy issued by the controller.

[0004] As one of the most critical technologies of zero-trust SDP, one of its goals is to overcome the basic characteristics of openness and insecurity of the Transmission Control Protocol / Internet Protocol address TCP / IP and achieve "authentication before connection", so that only authorized users can reliably access, while unauthorized users cannot see these services. The core network security protocol of SDP network stealth is single-packet authorization SPA, which verifies the identity of devices and users before allowing access to the network where related system components such as controllers and gateways are located, realizing the zero-trust "authentication before connection" security model.

[0005] Single-packet authorization SPA includes information about the connection request, including the IP address of the requester, which is encrypted and authenticated in a single network message. The protected service is invisible to the outside world by configuring the default-drop firewall policy. The firewall system discards all TCP and User Datagram Protocol UDP packets and does not respond to connection attempts, thereby not providing potential attackers with any information about whether the port is being listened to. When a user attempts to access, the user's identity, device, and network information must be verified first, and then the user's network access to the zero-trust system components SDP controller and SDP gateway is allowed, and finally the user is allowed to access the service. Therefore, single-packet authorization SPA is indispensable to the zero-trust SDP security model.

[0006] However, the existing zero-trust SDP security model and single-package authorization SPA method have the following technical defects:

[0007] 1) Most existing solutions distribute standard clients without built-in management information. The client needs to configure the management information before logging in, which is not easy to use;

[0008] 2) In order to solve the usability problem, some clients embed the controller information before sending out the client for the installation of the controller at a specific site, and then provide the client to the user for download. In this case, the controller information must be embedded manually at each deployment site.

[0009] 3) Since the prior art provides a general client download page, hackers can also obtain the client software. After obtaining the client software, the probability of successfully breaking into the controller is greatly increased;

[0010] 4) In the existing technical solutions, once the client is downloaded, it can be copied and used anywhere, which poses a great risk to the control of the terminal device;

[0011] 5) Existing technical solutions cannot determine whether a new terminal is allowed to knock on the door. For example, some companies stipulate that only one device can knock on the door for one person;

[0012] 6) The existing solution has no way to pull down the global policy from the controller before the knock is successful. Summary of the invention

[0013] Purpose of the invention: The purpose of the present invention is to solve the deficiencies in the prior art and to provide a client security distribution method based on network invisibility in a zero-trust mode; the present invention can ensure that the terminal is distributed to designated personnel in a targeted manner, and that a dedicated terminal is used for a dedicated purpose. Each legitimate user has one or more designated terminals and can use the controller to actively build the security information he needs into the terminal, thus solving the difficult problem of having to knock on the door for the first time to obtain global policies and user policies.

[0014] Technical solution: A client security distribution method based on network invisibility in a zero-trust mode of the present invention comprises the following steps:

[0015] Step (1) The specific steps to generate the SDP client software are:

[0016] Step (1.1) Install the SDP controller and SDP application gateway; the administrator configures the client software to be distributed in the SDP controller configuration page; after saving the configuration, the SDP controller immediately places the controller encryption file in the specified client software file, and the controller encryption file contains the controller parameters configured during the installation of the SDP controller; here, since the controller encryption file is automatically configured based on the SDP controller, its operation and maintenance cost is relatively low; at the same time, because the controller encryption file is built into the client software, the user can save the step of entering the SDP controller information when installing and logging in later, which can solve the usability problem in the prior art;

[0017] Step (1.2) The administrator configures a global policy that is not related to a specific user in the policy module of the SDP controller; when the administrator clicks Save, an encrypted globalPolicy file is automatically generated in the client software, and the global policy is stored in the globalPolicy file;

[0018] Step (1.3) The administrator creates a user named employee in the user management module of the SDP controller, binds the user's email address or mobile phone number, and sets the employee user's digital unique identifier as employeeKey;

[0019] After clicking Save in step (1.4), the system assigns a globally unique knock code encryptedCode to the user employee; the mapping relationship between the user name and the code is recorded on the SDP controller management end: employeeKey:[encryptedCode]; the knock code code can also be generated in combination with fixed assets, that is, the knock code code is used for device identification, so that only the company's fixed assets are allowed to access the IT system, further improving security performance;

[0020] Step (1.5) then generates a link for the user employee to download the client software, and sends the link to the user employee via email or mobile phone text message;

[0021] Step (2) The specific steps for downloading the SDP client software are:

[0022] Step (2.1) The administrator creates a user policy for the user employee on the SDP controller user configuration page, and generates an employeePolicy file to store the user policy;

[0023] Step (2.2) When the user employee clicks the link to download the client software, the download center first parses the unique identifier employeeKey of the user employee in the link and the corresponding knock code encryptedCode;

[0024] Step (2.3) queries the SDP controller to see if the mapping of employeeKey-encryptedCode exists. If not, an error page is returned. If so, a code file is generated to store the encrypted employeeKey-encryptedCode key-value pair.

[0025] Step (2.4) first copies a copy of the client software, then puts both the code file and the employeePolicy file into the client software, and then returns the modified client software to the user employee.

[0026] The client generated and downloaded so far carries the authentication information required for knocking, so the knocking mechanism and network stealth function of the zero-trust SDP security model are retained; only legitimate clients and users can knock on the door of the SDP controller during the login process, so the global policy can be obtained from the controller before the client successfully logs in; the present invention can solve the problem of mixing and misusing between different legitimate clients, for example, prohibiting user employeeB from using the client distributed to user employeeA, which is more secure.

[0027] Furthermore, it also includes logging into the SDP client software. The detailed process of SDP client logging in is as follows:

[0028] Step (3.1) The employee user installs the modified client software downloaded and then opens the client login page. At this time, the client has the SDP controller address built in. Then the global policy of the globalPolicy file in the client is executed;

[0029] After the global policy execution in step (3.2) is completed, enter the user name on the login page, and then determine whether the user name matches the user name in the code file. If they do not match, return to the login page. If they match, execute the user policy first;

[0030] Step (3.3) The client uses the code file to start knocking on the SDP controller. If the knocking fails, it means that the built-in code file is incorrect and the login page is fed back again. If the knocking succeeds, the SDP controller regenerates a mapping relationship for the user employee, that is, generates a new knocking code: employeeKey-encryptedCodeNew.

[0031] Step (3.4) then writes the new knock code back to the code file of the client (i.e., the client containing the global policy) used by the employee to access; completes the client update, updates the employeeKey-encryptedCode originally saved in the SDP controller to employeeKey-encryptedCodeNew; and deletes the dedicated client software for the employee that was initially stored locally.

[0032] Here, it is assumed that the user employee has successfully logged into the client, and the original mapping relationship from the user name to the code in the generation phase has been modified. Therefore, even if a hacker clicks on the link in the user's email or text message again, an error page will be returned. In other words, once the client software downloaded in the present invention has been used once, it cannot be downloaded again, reducing the number of times the terminal is distributed.

[0033] Even if an employee uses the client software that has been downloaded and used once to register a device (for example, to access company resources through a device at home), the built-in code cannot open the SDP controller because the code has been modified. Similarly, even if a hacker gets a terminal that has been distributed and used, he cannot open the SDP controller again through this terminal.

[0034] Beneficial effects: The client distributed by the present invention is a standard product, which has nothing to do with the specific deployment environment. However, before providing it to users for download, the actual environment information can be automatically preset based on the installation environment of the SDP controller. Compared with the prior art, the present invention has the following advantages:

[0035] First, because the method described in the present invention solves the problem of limited terminal distribution, and the terminal is used as a tool for knocking on the door, the number of malicious knocks is reduced, greatly reducing the risk;

[0036] Second, the end here actually has a similar effect of "use and burn", so when the end is installed again, it is equivalent to being invalid, even if the hacker gets this end, it is useless

[0037] Third, the client's built-in controller address is automatically filled in, without manual intervention or customization

[0038] Fourth, the latest global policies and user policies have been built into the terminal and can be executed before knocking on the door. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 It is a schematic diagram of the zero-trust SDP security model in the prior art;

[0040] Figure 2 It is a schematic diagram of the network stealth principle in the prior art;

[0041] Figure 3 A flow chart for generating and downloading the client software in the present invention;

[0042] Figure 4 This is a client login flow chart in the present invention. DETAILED DESCRIPTION

[0043] The technical solution of the present invention is described in detail below, but the protection scope of the present invention is not limited to the embodiments.

[0044] To facilitate the understanding of the technical solution, the following technology is now explained.

[0045] SPA: In the field of computer networks, port knocking refers to a series of connection actions on a series of pre-specified closed ports. Once the connection sequence is correct, the firewall rules will be dynamically modified to allow the host sending the connection request to connect to the specified port. SPA is a special implementation of port knocking. It only needs to make a single connection action (also called knocking) to successfully open the port on the firewall. The main purpose of using port knocking is to prevent attackers from scanning the system's potential services (exposed in the form of ports) and then making targeted attacks.

[0046] BYOD: Bring your own device (generally refers to employees bringing their own devices to work).

[0047] In a zero-trust scenario, in order to solve the problem of network anonymity and the need to expose the ports of both communicating parties, the existing technology usually adopts the SPA knocking mechanism. Taking the client accessing the controller as an example, when the client uses the SPA knocking mechanism to knock on the door of the controller, the controller will temporarily open the specified port to the client, and other clients still cannot access this port. Ideally, the SPA message generally contains user information and device feature information. During the knocking process, the device feature information needs to be compared for consistency. If the device feature information in the message is different from the device feature information stored on the other end, the door cannot be knocked.

[0048] The current SPA solutions face some problems in the following scenarios:

[0049] (1) New client access

[0050] Consider the scenario where a user uses a new client to connect to the controller (for example, a new employee receives a desktop computer when joining the company). Since this new device has not been registered on the SDP controller, the controller will find that the device feature information in the SPA cannot be queried, so this new end cannot knock on the controller's door. To solve this problem, the following two methods are usually used in actual project implementation:

[0051] A) Disable the SPA knocking function, that is, the port of the communicating peer is open for a long time. The disadvantage of this method is that the port is directly exposed to the outside world, and the attack surface becomes larger.

[0052] B) The SPA message does not contain device information, but this will result in employees being able to use any BYOD device to access company resources. The security of BYOD devices is greatly reduced. When using BYOD devices to access application resources, the security of application resources will be at risk, and it is also inconvenient for the company to perform unified management and control of terminal devices.

[0053] (2) Global Strategy Scenario

[0054] In response to the network protection operation, some existing technologies will set device registration policies, such as not allowing new devices to be registered after July 1, 2022. At this time, whether a new device can be registered depends on the device registration policy configured on the controller, so the device registration policy needs to be synchronized to the client before knocking on the door. However, the prerequisite for synchronization is that the device can knock on the controller's door, and the policy itself prohibits knocking on the door, so this becomes a chicken-and-egg problem, which cannot be solved.

[0055] (3) Scenarios where account passwords are compromised

[0056] If an attacker breaks into the account and password system, they can obtain legitimate user information. As long as the attacker obtains a client and installs it on any computer, the attacker can knock on the door of the SDP controller from this computer (because SPA does not contain device information when knocking on the door, the main identification basis is user authentication information).

[0057] Embodiment 1:

[0058] like Figure 3 and Figure 4 As shown, a client security distribution method based on network invisibility in a zero-trust mode of this embodiment sets the wildcard domain name to "*.c.com" and sets three identities: administrator, user employeeA and user employeeB. Specifically, the following steps are included.

[0059] Step (1) Generate SDP client software

[0060] Step (1.1) Install the SDP controller and SDP application gateway;

[0061] Step (1.2) The administrator configures the client software to be distributed in the SDP controller configuration page. In this implementation, it is assumed that the client software is named clientInstaller.tar. At this time, clientInstaller.tar is directly obtained from the random installation disk. The original clientInstaller.tar does not contain any information about the installation environment of the management end;

[0062] After saving the configuration in step (1.3), immediately place the controller encrypted file in the specified client software clientInstaller.tar file. The controller encrypted file contains the controller parameters configured during the installation of the SDP controller. The controller parameters here include information such as the SDP controller IP and port, the SPA knocking port, etc. This can solve the problem of the client's built-in specific server information;

[0063] Step (1.4) The administrator configures global policies that are not related to specific users, such as allowing a user to log in from two different clients at most, or ensuring that the device where the client is located has antivirus software installed before logging in;

[0064] Step (1.5) When the administrator clicks Save, an encrypted globalPolicy file is automatically generated in the client software clientInstaller.tar (if the globalPolicy file already exists, it will be completely overwritten). The globalPolicy file stores the global policy. When the global policy is updated (added, modified, or deleted) and saved at any time in the future, the globalPolicy file in the clientInstaller.tar file will also be immediately updated.

[0065] Step (1.6) The administrator creates a user named employeeA in the user management module (of course, the data can also be synchronized from other systems). Assume that the digital unique identifier of user employeeA in the system is employeeAKey; when creating user employeeA, the user's email address or mobile phone number must be filled in at the same time.

[0066] After clicking Save in step (1.7), the system assigns a globally unique knock code to user employeeA: encryptedCodeA; the mapping relationship between the user name and the knock code is recorded on the management end: employeeAKey:[encryptedCodeA];

[0067] Step (1.8) then generates a link for user employeeA to download the client software, which is structured as: https: / / employeeAKey.c.com / download / client?code=encryptedCodeA;

[0068] Step (1.9) sends an email or text message to user employeeA through the email address or mobile phone number in step (1.6), and the email or text message contains a special link for downloading the client software;

[0069] Step (2) Download the SDP client software

[0070] Step (2.1) The administrator creates a user policy for user employeeA. For example, employeeA is only allowed to access the system from 09:00 to 12:00 every day. At this time, an employeeAPolicy file is also generated. The employeeAPolicy file contains the latest user policy for user employeeA.

[0071] Step (2.2) After receiving the email or SMS, user employeeA clicks on the dedicated link; the download center first parses out the employeeAKey in the domain name part and the encryptedCodeA in the parameter part, that is, finds out the user ID and knock code;

[0072] Step (2.3) queries the SDP controller to see if the mapping of employeeAKey-encryptedCodeA exists. If not, an error page is returned. If it exists, step (2.4) is executed.

[0073] Step (2.4) generates a code file, which stores the encrypted employeeAKey-encryptedCodeA key-value pair, and uses the key-value pair to knock on the door.

[0074] Step (2.5) Copy a copy of clientInstaller.tar, put the code file and employeeAPolicy file into the client software clientInstaller.tar, and then return the modified new client software clientInstaller.tar to user employeeA.

[0075] Step (3) Log in to the SDP client software

[0076] Step (3.1) User employeeA downloads and installs the new client software clientInstaller.tar, and then opens the client. At this time, the client has the SDP controller address built in;

[0077] Step (3.2) executes the global policy built into the client, that is, the global policy built into the globalPolicy file; after execution, enter the login page and enter the user name employeeA on the login page;

[0078] After step (3.3) is entered (the input focus leaves the username input box), first determine whether the current user is allowed to log in based on the user information in the code file (that is, determine whether the entered username matches the username in the code file). If they do not match, the page for entering the username remains. If the username is legal, the user policy is executed first. Then the client uses the code file to start knocking on the SDP controller.

[0079] Step (3.4) If the knocking fails, it means that the built-in code file is incorrect (for example, the code has become invalid after this terminal has been installed once by someone else). Return to the login page and re-enter the user name; if the knocking succeeds, the SDP controller will regenerate a new mapping relationship for user employeeA: employeeAKey-encryptedCodeANew;

[0080] Step (3.5) writes the new mapping relationship back to the client code file when user employeeA accesses the site to complete the update of the knock code;

[0081] After the knock code is updated successfully in step (3.6), the original mapping in the SDP controller is updated, that is, employeeAKey-encryptedCodeA is updated to employeeAKey-encryptedCodeANew; at the same time, the dedicated client software clientInstaller.tar for employeeA stored locally is deleted.

[0082] As can be seen from Example 1, the client of the present invention is distributed in a targeted and directional manner through emails or text messages, and the SDP controller information is automatically and dynamically built into the SDP controller when configuring the client software, so that the client distributed to each user is unique. This also achieves "dedicated end for dedicated use", and even two legal users cannot mix each other's clients. The built-in knock code in the present invention changes after the first use, and is reversely updated to the installed client, so that the downloaded client software automatically becomes invalid. At the same time, because the present invention has the latest SDP controller global policy and user policy built into the client that the legal user has downloaded, the global policy and user policy can be obtained before knocking on the SDP controller, and the corresponding global policy and user policy can be executed before the user logs in.

Claims

1. A client security distribution method based on network invisibility in zero-trust mode, characterized by: The following steps are involved: Step (1) The specific steps to generate the SDP client software are: Step (1.1) Install the SDP controller and SDP application gateway; The administrator configures the client software to be distributed on the SDP controller user configuration page; after saving the configuration, the SDP controller immediately places the controller encrypted file in the specified client software file. The controller encrypted file contains the controller parameters configured during the installation of the SDP controller; Step (1.2) The administrator configures a global policy that is not related to a specific user in the policy module of the SDP controller; when the administrator clicks Save, an encrypted globalPolicy file is automatically generated in the client software, and the global policy is stored in the globalPolicy file; Step (1.3) The administrator creates a user named employee in the user management module of the SDP controller, binds the user's email address or mobile phone number, and sets the digital unique identifier of the user employee as employeeKey; After clicking Save in step (1.4), the system assigns a globally unique knock code encryptedCode to the user employee; the mapping relationship between the user name and the knock code encryptedCode is recorded in the user management module of the SDP controller: employeeKey:[encryptedCode]; Step (1.5) then generates a link for the user employee to download the client software, and sends the link to the user employee via email or mobile phone text message; Step (2) The specific steps for downloading the SDP client software are: Step (2.1) The administrator creates a user policy for the user employee on the SDP controller user configuration page, and generates an employeePolicy file to store the user policy; Step (2.2) When the user employee clicks the link to download the client software, the download center first parses the unique identifier employeeKey of the user employee in the link and the corresponding knock code encryptedCode; Step (2.3) queries the SDP controller to see if the mapping of employeeKey-encryptedCode exists. If not, an error page is returned. If so, a code file is generated to store the encrypted employeeKey-encryptedCode key-value pair. Step (2.4) copies a copy of the client software, then puts the code file and the employeePolicy file into the client software, and then returns the modified client software to the user employee.

2. According to claim 1, the client security distribution method based on network invisibility in the zero trust mode is characterized by: It also includes logging into the SDP client software. The detailed process of SDP client logging in is as follows: Step (3.1) The employee user installs the modified client software downloaded and then opens the client login page. At this time, the client has the SDP controller address built in. The employee user then executes the global policy of the globalPolicy file in the client. After the global policy execution in step (3.2) is completed, enter the user name on the login page, and then determine whether the user name matches the user name in the code file. If they do not match, return to the login page. If they match, execute the user policy first; Step (3.3) The client uses the code file to start knocking on the SDP controller. If the knocking fails, it means that the built-in code file is incorrect and returns to the login page. If the knocking succeeds, the SDP controller regenerates a new mapping relationship for the user employee, that is, generates a new knocking code: employeeKey-encryptedCodeNew. Step (3.4) then writes the new knock code back to the client code file used by the employee to access; After the client update is completed, the employeeKey-encryptedCode originally saved in the SDP controller is updated to employeeKey-encryptedCodeNew; at the same time, the dedicated client software for the employee initially stored locally is deleted.

Images