CN117768137A

CN117768137A - Remote office system and method for providing security mechanism in remote office system

Info

Publication number: CN117768137A
Application number: CN202310475793.1A
Authority: CN
Inventors: 鲍淼; 孙峰; 廖雯; 于佳龙; 王子慧
Original assignee: China Unionpay Co Ltd
Current assignee: China Unionpay Co Ltd
Priority date: 2023-04-27
Filing date: 2023-04-27
Publication date: 2024-03-26

Abstract

The present application relates to network security technologies, and in particular, to a remote office system based on an SDP architecture and a method for providing a security mechanism in the remote office system. The remote office system based on the SDP architecture according to one aspect of the application comprises an SDP controller, an SDP gateway and an SDP client, wherein the SDP client runs on one of a plurality of terminals belonging to the same network, the plurality of terminals access a service system located outside the network via the SDP gateway, wherein the authentication of the terminal running the SDP client is performed in the following way: the SDP gateway forwards an authentication message from the SDP client to the SDP controller, wherein the authentication message comprises a user account number, a password and characteristic information associated with a device ID of a terminal running the SDP client; the SDP controller determines whether the identity verification of the terminal is passed or not based on the user account number, the password and the characteristic information; and if the identity authentication is passed, the SDP controller instructs the SDP gateway to open a service access port, and allows a terminal running the SDP client to establish connection with the service system after the user identity authentication is passed.

Description

Remote office system and method for providing security mechanism in remote office system

Technical Field

The present application relates to network security technologies, and in particular, to a teleoffice system based on a software defined boundary (SDP) architecture and a method for providing security mechanisms in the teleoffice system.

Background

Existing teleoffice schemes based on software defined boundary (SDP) architecture typically employ a "zero trust system technical Specification" (T/CESA 1165-2021) community standard that securely authorizes access principals based on security and trust status and continuously monitors the security of the entire access process.

The SDP architecture consists of two logical components: an SDP host and an SDP controller. The SDP host (including the initiating host and the receiving host) may initiate or accept connections, these actions being managed by the SDP controller, the entire process interacting through the secure channel of the control plane. The data is communicated over a separate secure channel in the data plane. The control plane and the data plane are separated, so that the whole system architecture is flexible and highly expandable.

Disclosure of Invention

It is an object of the present application to provide a teleoffice system based on the SDP architecture and a method for providing a security mechanism in a teleoffice system, which can reduce security risks such as traffic portal hiding failure and knock-out magnification.

According to one aspect of the present application, there is provided a software defined boundary (SDP) -based remote office system comprising an SDP controller, an SDP gateway and an SDP client, wherein the SDP client operates on one of a plurality of terminals belonging to the same network, which access a service system located outside the network via the SDP gateway,

wherein the authentication of the terminal running the SDP client is performed in the following manner:

the SDP gateway forwards an authentication message from the SDP client to the SDP controller, wherein the authentication message comprises a user account number, a password and characteristic information associated with a device ID of a terminal running the SDP client;

the SDP controller determines whether the identity verification of the terminal running the SDP client passes or not based on the user account, the password and the characteristic information;

and if the identity authentication is passed, the SDP controller instructs the SDP gateway to open a service access port, and allows a terminal running the SDP client to establish connection with the service system after the user identity authentication is passed.

Optionally, in the above remote office system, the device ID includes an identification code or serial number of one or more hardware units included in the terminal.

Optionally, in the above remote office system, the method further includes a network admission controller and an endpoint protection platform, when the terminal running the SDP client logs into the network for the first time, performing a network admission check on the terminal in the following manner:

in response to a network admission request from the SDP client, the network admission controller requests the endpoint protection platform to perform a network admission check;

the terminal protection platform determines whether a terminal running the SDP client accords with a preset security baseline or not;

if yes, collecting the device ID of the terminal running the SDP client and adding the device ID into a trust list.

Optionally, in the above-mentioned remote office system, the feature information is obtained by encrypting a hash value of a device ID of a terminal running the SDP client terminal using a preset key.

Further optionally, in the above remote office system, determining whether the authentication of the terminal running the SDP client passes is performed in the following manner:

decrypting the characteristic information to obtain a hash value of the device ID of the terminal running the SDP client if the verification based on the password is successful, otherwise, terminating the identity verification process;

performing hash operation on the device ID of the terminal running the SDP client, which is saved by the SDP controller;

and if the decrypted hash value is matched with the hash value obtained by performing hash operation at the SDP controller, determining that the identity verification is passed.

Optionally, in the above-mentioned remote office system, the dynamic authentication of the terminal running the SDP client is performed in the following manner:

if the identity verification is passed, the SDP controller sends the IP address and the equipment ID of the terminal running the SDP client to the SDP gateway, and the SDP gateway writes the IP address and the equipment ID of the terminal running the SDP client into an equipment information database and updates the access rule of IPtables;

if the identity verification is not passed, the SDP controller queries the device information database for the presence of a record corresponding to the terminal running the SDP client and instructs the SDP gateway to delete the record when the record is present.

Further optionally, in the above-mentioned remote office system, dynamic authentication of the terminal running the SDP client is further performed in the following manner:

the SDP controller responds to the periodically sent authentication message from the SDP client and inquires whether a record corresponding to a terminal running the SDP client exists in the equipment information database;

if so, updating the keep-alive time of the terminal running the SDP client, otherwise, sending the IP address and the equipment ID of the terminal running the SDP client to the SDP gateway, and writing the IP address and the equipment ID of the terminal running the SDP client into an equipment information database and updating the access rule of IPtables by the SDP gateway.

Or further alternatively, in the above-mentioned remote office system, the dynamic authentication of the terminal running the SDP client is further performed in the following manner:

the SDP controller periodically detects whether a record of a terminal with the expired retention time exists in the equipment information database;

if so, notifying the SDP gateway to delete the record of the terminal with the expired keep-alive time and updating the access rule of the IPtables.

Optionally, in the above remote office system, after the device running the terminal of the SDP client terminal passes the authentication, the registration of the terminal is performed in the following manner:

authenticating the user identity in a manner of interfacing with an enterprise instant messaging tool and a unified authentication platform;

if the authentication is passed, the terminal of the SDP client side, the SDP controller and the endpoint protection platform are operated to establish a communication channel for transmitting the equipment ID, the updated security policy and the environment perception information of the terminal;

the SDP client transmits the device ID of the terminal to the SDP controller;

the SDP controller updates the device information database with the received device ID and synchronously updates the device information stored at the endpoint protection platform.

Optionally, in the above-mentioned remote office system, the persistent context awareness of the terminal running the SDP client is performed in the following manner:

the SDP client acquires an environment awareness policy from the endpoint protection platform through the SDP controller after passing identity verification;

the SDP client sends environment information of a terminal running the SDP client to the SDP controller based on the environment awareness policy;

the endpoint protection platform determines the security score of the terminal running the SDP client from the environmental information based on a terminal risk assessment model;

and the SDP controller dynamically adjusts the service access authority of the terminal running the SDP client according to the security score.

Optionally, in the above-mentioned remote office system, the persistent context awareness of the terminal running the SDP client is further performed in the following manner:

the SDP client sends updated environment information of a terminal running the SDP client to the SDP controller when the environment changes;

the endpoint protection platform determines the security score of the terminal running the SDP client from the updated environmental information based on a terminal risk assessment model;

Further optionally, in the above remote office system, the environmental information includes one or more of the following: the identity or serial number of one or more hardware units contained in the terminal, the software information running on the terminal, the login user name and the secure baseline restoration state.

According to another aspect of the present application, there is provided a method for providing a security mechanism in a remote office system based on a software defined boundary (SDP) architecture and comprising an SDP controller, an SDP gateway and an SDP client, wherein the SDP client is operated on one of a plurality of terminals belonging to the same network, which access a service system located outside the network via the SDP gateway, characterized in that the method performs authentication of the terminal operating the SDP client in the following manner:

Drawings

The foregoing and/or other aspects and advantages of the present application will become more apparent and more readily appreciated from the following description of the various aspects taken in conjunction with the accompanying drawings in which like or similar elements are designated with the same reference numerals. The drawings include:

fig. 1 is a schematic block diagram of a remote office system based on an SDP architecture in accordance with some embodiments of the present application.

Fig. 2 shows the overall process flow of the teleoffice system shown in fig. 1.

Figure 3 is a flow chart of network admission check operations according to further embodiments of the present application.

Fig. 4 is a flow chart of authentication operations for a terminal according to still further embodiments of the present application.

Fig. 5 is a flow chart for implementing step 420 of fig. 4, according to still further embodiments of the present application.

Fig. 6 is a flow chart of an SPA authentication process according to still further embodiments of the present application.

FIG. 7 is a flow chart of SPA keep-alive procedures according to still further embodiments of the present application.

Fig. 8 is a flow chart of an expiration process according to still further embodiments of the present application.

Fig. 9 is a flow chart of a terminal registration process according to still further embodiments of the present application.

Fig. 10 is a flow chart of a persistent context awareness process according to still further embodiments of the present application.

Fig. 11 is a flow chart of a persistent context awareness process according to still further embodiments of the present application.

Detailed Description

The present application is described more fully hereinafter with reference to the accompanying drawings, in which exemplary embodiments of the application are shown. This application may, however, be embodied in different forms and should not be construed as limited to the embodiments set forth herein. The above-described embodiments are provided to fully complete the disclosure herein so as to more fully convey the scope of the application to those skilled in the art.

In this specification, terms such as "comprising" and "including" mean that there are other elements and steps not directly or explicitly recited in the description and claims, nor do the subject matter of the present application exclude the presence of other elements and steps.

The teleoffice system 10 shown in fig. 1 comprises a plurality of SDP clients 110, SDP controllers 120, SDP gateways 130, network admission controllers 140, and endpoint protection platforms 150. Illustratively, each SDP client runs on one of a plurality of terminals (not shown) belonging to the same network (e.g., an enterprise network), which access the service system 20 located outside the network via the SDP gateway 130.

It should be noted that the module units of the SDP controller 120, the SDP gateway 130, the network admission controller 140, and the endpoint protection platform 150 described herein may implement the respective functions by means of software running on general-purpose computing devices (e.g., servers and PCs), or may implement the respective functions by means of dedicated hardware modules (e.g., ASIC circuits, FPGA circuits). In some embodiments, each modular unit is implemented using a separate general purpose computing device or dedicated hardware module; in other embodiments, two or more of the modular units are implemented using the same general purpose computing device or special purpose hardware modules.

SDP client 110 may be configured to initiate network admission and remote office connection requests and to enforce policies issued by SDP controller 120 and endpoint protection platform 150. The SDP client 110 illustratively consists of modules such as an assistant providing network admission and an SDP control providing remote office agent access. The SDP controller 120 is configured to perform authentication of the terminal and to formulate access control policies for the terminal. The SDP gateway 130 acts as a security proxy for the network, enforcing corresponding access control policies for each terminal. The network admission controller 140 may be configured to perform identity verification and security check on terminals accessing the network, and reject access to unsafe terminals, thereby improving defensive power against network security threats and protecting intranet infrastructure security. The endpoint protection platform 150 provides network admission and terminal management functions, and realizes integrated management and control of network admission and endpoint security of the terminal.

Fig. 2 shows the overall process flow of the teleoffice system shown in fig. 1.

The overall flow shown in fig. 2 includes the following operations:

operation 210-network admission check

For a terminal running the SDP client 110, a corresponding network admission check will be performed when it first logs into the network. After passing the network access check, the terminal can directly enter the authentication process when accessing the network next time.

Operation 220-authentication of terminal

The terminal running the SDP client 110 is authenticated.

Operation 230 Access to business system

After the terminal passes the authentication, the SDP client 110 may access the service system 20 outside the network via the SDP gateway 130, wherein access control policies are formulated by the SDP controller 120 and executed by the SDP gateway 130.

Operation 240-dynamic authentication of terminal

The SDP controller 120 performs dynamic authentication of the terminal during access of the SDP client 110 to the service system 20 via the SDP gateway 130.

Operation 250 registration of terminal

After the terminal passes the authentication, it will perform registration on the SDP controller 120 and the endpoint protection platform 150.

Operation 260-persistent context awareness

After the terminal finishes registration, the terminal protection platform can dynamically adjust the service access authority of the user by using a terminal risk assessment model established based on terminal data, and acquire the terminal protection management and control strategy in real time, so as to prevent the terminal from running malicious processes and establishing communication connection with an unauthorized system outside the network.

Illustratively, operation 210 (network admission check) may be performed in the manner shown in FIG. 3. Referring to fig. 3, in step 310, in response to a network admission request from SDP client 110, network admission controller 140 requests endpoint protection platform 150 to perform a network admission check. Then in step 320, the endpoint protection platform 150 determines whether the terminal meets a preset security baseline, and if so, goes to step 330, otherwise goes to step 340. Endpoint protection platform 150 collects the device ID of the terminal and adds it to the trust list at step 330. In step 340, the endpoint protection platform 150 returns a message to the network admission controller 140 that the network admission check failed.

Illustratively, operation 220 (authentication of the terminal) may be performed in the manner shown in FIG. 4.

The flow shown in fig. 4 begins at step 410. In this step, the SDP gateway 130 forwards the authentication message from the SDP client 110 to the SDP controller 120. In some embodiments, the authentication message may be an SPA message with an improved format that contains a user account number, a password, and characteristic information associated with a device ID of the terminal running the SDP client. In addition, the authentication message may further include one or more of the following: hardware version number, authentication type, message digest, etc. The device ID as described herein may include various information describing the hardware characteristics of the terminal, such as an identification code or serial number of one or more hardware units contained in the terminal. In some embodiments, the characteristic information may be obtained by hashing the device ID of the terminal using a preset key (which is shared by the SDP client 110 and the SDP controller) and encrypting the hash value. By adding the fields of the legal device ID, the hardware version number, the authentication type, the message abstract and the like in the SPA message, the security and the elasticity of the SPA protocol can be improved, and the knock-on amplification and replay attack can be prevented.

After step 410 is performed, the flow shown in fig. 4 then proceeds to step 420. In this step, the SDP controller 120 determines, based on the user account, the password, and the feature information, whether the authentication of the terminal running the SDP client is passed, and if so, proceeds to step 430, otherwise, proceeds to step 440.

In step 430, the SDP controller 120 instructs the SDP gateway 130 to allow the terminal running the SDP client 110 to establish a connection (e.g., a TCP protocol based connection) with the service system.

In step 440, the SDP controller 120 instructs the SDP gateway 130 to prohibit the terminal running the SDP client 110 from establishing a connection with the service system.

Illustratively, in step 420, the SDP controller 120 may determine whether the identity of the terminal is verified in the manner shown in fig. 5. As shown in fig. 5, in step 510, the SDP controller 120 performs a password-based check, and if the check is successful, proceeds to step 520, otherwise proceeds to step 530.

In step 520, the SDP controller 120 decrypts the characteristic information in the authentication message to obtain the hash value H of the device ID of the terminal.

In step 530, the SDP controller 120 terminates the authentication process.

After step 520, the flow shown in fig. 5 goes to step 540. In this step, the SDP controller performs a hash operation on the device ID of the terminal stored therein and compares the calculated hash value H' with the decrypted hash value H, and if so, determines that the authentication passes, and if not, determines that the authentication fails.

Illustratively, operation 240 (dynamic verification of the terminal) includes the sub-flows of enhanced SPA authentication, SPA keep-alive, and expiration processing.

Fig. 6 is a flow chart of an SPA authentication process according to still further embodiments of the present application. Referring to fig. 6, in step 610, it is determined whether the authentication of the terminal running the SDP client 110 is passed, and if so, step 620 is entered, otherwise step 630 is entered. In step 620, the SDP controller 120 sends the IP address and the device ID of the terminal to the SDPfilter module of the SDP gateway 130, and the SDPfilter module of the SDP gateway 130 writes the IP address and the device ID of the terminal into the device information database and updates the access rules of the IPtables. In step 630, the SDP controller 120 queries the device information database for the presence of a record corresponding to the terminal running the SDP client, and instructs the SDPfilter module of the SDP gateway 130 to delete the record when it is present.

FIG. 7 is a flow chart of SPA keep-alive procedures according to still further embodiments of the present application. Referring to fig. 7, in step 710, the SDP controller 120 queries in the device information database whether there is a record corresponding to the terminal running the SDP client 110 in response to the periodically transmitted authentication message from the SDP client 110, and if so, performs step 720, otherwise, performs step 730. In step 720, the SDP controller 120 updates the keep-alive time of the terminal running the SDP client 110. On the other hand, in step 730, the SDP controller 120 sends the IP address and the device ID of the terminal running the SDP client 110 to the SDPfilter module of the SDP gateway 130, and the SDPfilter module of the SDP gateway 130 writes the IP address and the device ID of the terminal into the device information database and updates the access rules of the IPtables.

Fig. 8 is a flow chart of an expiration process according to still further embodiments of the present application. Referring to fig. 8, in step 810, the SDP controller 120 periodically checks whether a record of a terminal whose lifetime has expired exists in the device information database, and if so, proceeds to step 820, otherwise, continues to check the record of the expired terminal in the next period. In step 820, the SDP controller 120 notifies the SDPfilter module of the SDP gateway 130 to delete the record of the terminal whose keep-alive time has expired and update the access rules of the IPtables.

In the embodiments shown in fig. 6-8, under the condition that the original SPA authentication flow is kept basically unchanged, by replacing the manner of directly updating the access rule in the firewall IPtables with the manner of maintaining the IP trust list of the kernel module SDPfilter, frequent writing operations to the IPtables in a high concurrency scene are reduced, and processing capacity is improved.

Illustratively, operation 250 (registration of the terminal) may be performed in the manner shown in FIG. 9.

The flow shown in fig. 9 begins at step 910. In this step, the user identity is authenticated by interfacing with the enterprise instant messaging tool and the unified authentication platform. If the authentication passes, step 920 is performed, otherwise the registration process is exited.

In step 920, the terminal running the SDP client 110 establishes a communication channel with the SDP controller 120 and the endpoint protection platform 150 for transmitting the terminal's device ID, updated security policy, context awareness information.

After step 920 is performed, the flow shown in fig. 9 proceeds to step 930. In this step, the SDP client 110 transmits the device ID of the terminal to the SDP controller 120.

Subsequently, in step 940, the SDP controller 120 updates the device information database with the received device ID and synchronously updates the device information stored at the endpoint protection platform 150.

Illustratively, operation 260 (persistent context awareness) may be performed in the manner shown in FIG. 10.

The flow shown in fig. 10 begins at step 1010. In this step, the SDP client 110 obtains the context aware policy from the endpoint protection platform 150 via the SDP controller 120 after passing the authentication.

After step 1010 is performed, the flow shown in fig. 10 proceeds to step 1020. In this step, the SDP client 110 transmits context information of a terminal running the SDP client to the SDP controller 120 based on the acquired context-aware policy.

Subsequently, in step 1030, the endpoint protection platform 150 determines a security score for the terminal running the SDP client 110 based on the terminal risk assessment model, the context information provided by the SDP client 110.

Next, step 1040 is entered, where the SDP controller 120 dynamically adjusts the service access rights of the terminal running the SDP client 110 according to the security score determined in step 1030.

Illustratively, operation 260 (persistent context awareness) may also be performed in the manner shown in FIG. 11.

The flow shown in fig. 11 begins at step 1110. In this step, the SDP client 110 transmits updated context information of the terminal running the SDP client 110 to the SDP controller 120 when the context changes.

Then, step 1120 is entered, where the endpoint protection platform 150 determines a security score for the terminal running the SDP client 110 from the updated environmental information based on the terminal risk assessment model.

After step 1120, the flow shown in FIG. 11 proceeds to step 1130. In this step, the SDP controller 120 dynamically adjusts the service access rights of the terminal running the SDP client 110 according to the security score determined in step 1120.

In the embodiment shown in fig. 10 and 11, the environmental information may include one or more of the following: the identity or serial number of one or more hardware units contained in the terminal, the software information running on the terminal, the login user name and the secure baseline restoration state.

In some embodiments of the present application, the problem of SPA authentication knock-out amplification based on UDP ports is successfully solved by adding a way to verify the access terminal device ID (hardware feature value) in SPA authentication. That is, the service entry port is not opened because a certain terminal device under the same NAT completes SPA authentication, so that other devices can access the service entry port without authentication, thereby realizing complete hiding of the service entry.

In other embodiments of the present application, the kernel module SDPfilter of the SDP gateway invokes an interface to update the IPtables and maintain trusted device records in the device information database, and compared with a manner of directly updating the IPtables access rules of the SDP gateway, the manner of the present application solves the problem of access rule insertion failure caused by the IPtables lock mechanism and its own mechanism. According to the performance test result, in a high concurrency scene, the time for adding and deleting IPtables is about 1-3 seconds, and the time for adopting the optimization mode of the application is less than 200 ms.

In still other embodiments of the present application, the endpoint protection platform is integrated such that the terminal, whether in an enterprise network or a non-enterprise network, is strictly defined as a security baseline required for execution. These security baselines include, for example:

1. a terminal which is not provided with safety software such as virus prevention, data leakage prevention and the like according to the enterprise information safety requirements is forbidden to access the network;

2. prohibiting the terminal from connecting with an untrusted peripheral;

3. inhibit untrusted software and processes from running;

4. when the illegal external connection behavior of the terminal is found, the use of the terminal is immediately blocked, and audit information is generated so as to be searched afterwards.

Although only a few specific embodiments of this application have been described, those skilled in the art will appreciate that this application may be embodied in many other forms without departing from the spirit or scope thereof. Accordingly, the illustrated examples and embodiments are to be considered as illustrative and not restrictive, and the application is intended to cover various modifications and substitutions without departing from the spirit and scope of the application as defined by the appended claims.

The embodiments and examples set forth herein are presented to best explain the embodiments in accordance with the present technology and its particular application and to thereby enable those skilled in the art to make and use the application. However, those skilled in the art will recognize that the foregoing description and examples have been presented for the purpose of illustration and example only. The description as set forth is not intended to cover various aspects of the application or to limit the application to the precise form disclosed.

Claims

1. A remote office system based on a software defined boundary (SDP) architecture, comprising an SDP controller, an SDP gateway and an SDP client, wherein the SDP client runs on one of a plurality of terminals belonging to the same network, which access a service system located outside the network via the SDP gateway,

2. The tele-office system of claim 1, wherein the device ID comprises an identification code or serial number of one or more hardware units contained by the terminal.

3. The teleoffice system of claim 1, further comprising a network admission controller and an endpoint protection platform, when a terminal running the SDP client first logs into the network, performing a network admission check on it in the following manner:

4. The teleoffice system of claim 1, wherein the feature information is obtained by encrypting a hash value of a device ID of a terminal running the SDP client using a preset key.

5. The tele-office system of claim 4, wherein the identity verification of the terminal running the SDP client is determined whether it passes by:

6. The tele-office system of claim 1, wherein the dynamic authentication of the terminal running the SDP client is performed in the following manner:

7. The tele-office system of claim 6, wherein dynamic authentication of the terminal running the SDP client is further performed in the following manner:

8. The tele-office system of claim 6, wherein dynamic authentication of the terminal running the SDP client is further performed in the following manner:

9. A teleoffice system as claimed in claim 3, wherein after the device of the terminal running the SDP client has passed the authentication, the registration of the terminal is performed in the following manner:

the SDP client transmits the device ID of the terminal to the SDP controller;

10. A teleoffice system as recited in claim 3, wherein the persistent context awareness of the terminal running the SDP client is performed in the following manner:

11. A teleoffice system as recited in claim 3, wherein the persistent context awareness of the terminal running the SDP client is further performed in the following manner:

12. The tele-office system of claim 10 or 11, wherein the environmental information comprises one or more of the following: the identity or serial number of one or more hardware units contained in the terminal, the software information running on the terminal, the login user name and the secure baseline restoration state.

13. A method for providing a security mechanism in a remote office system based on a software defined boundary (SDP) architecture and comprising an SDP controller, an SDP gateway and an SDP client, wherein the SDP client runs on one of a plurality of terminals belonging to the same network, which access a service system located outside the network via the SDP gateway, characterized in that the method performs authentication of the terminal running the SDP client in the following way:

14. The method of claim 13, wherein the device ID comprises an identification code or serial number of one or more hardware units contained in the terminal.

15. The method of claim 13, wherein the remote office system further comprises a network admission controller and an endpoint protection platform, the method performing a network admission check for a terminal running the SDP client when it first logs into the network in the following manner:

16. The method of claim 13, wherein the characteristic information is obtained by encrypting a hash value of a device ID of a terminal running the SDP client using a preset key.

17. The method of claim 16, wherein the method determines whether the authentication of the terminal running the SDP client passes by:

18. The method of claim 13, wherein the method performs dynamic authentication of a terminal running the SDP client in the following manner:

19. The method of claim 18, wherein the method further performs dynamic authentication of a terminal running the SDP client in the following manner:

20. The method of claim 18, wherein the method further performs dynamic authentication of a terminal running the SDP client in the following manner:

21. The method of claim 15, wherein after the device of the terminal running the SDP client passes authentication, the method performs registration of the terminal in the following manner:

the SDP client transmits the device ID of the terminal to the SDP controller;

22. The method of claim 15, wherein the method performs persistent context awareness of a terminal running the SDP client in the following manner:

23. The method of claim 15, wherein the method further performs persistent context awareness of a terminal running the SDP client in the following manner:

24. The method of claim 22 or 23, wherein the environmental information comprises one or more of: the identity or serial number of one or more hardware units contained in the terminal, the software information running on the terminal, the login user name and the secure baseline restoration state.