CN113632437A - Secure remote connection in industrial internet of things - Google Patents
Secure remote connection in industrial internet of things Download PDFInfo
- Publication number
- CN113632437A CN113632437A CN202080025219.0A CN202080025219A CN113632437A CN 113632437 A CN113632437 A CN 113632437A CN 202080025219 A CN202080025219 A CN 202080025219A CN 113632437 A CN113632437 A CN 113632437A
- Authority
- CN
- China
- Prior art keywords
- tunnel
- gateway
- service
- user
- target device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
A method for establishing a secure remote connection between a user device and a target device, wherein the target device does not have a direct internet connection, is disclosed. The first gateway receives a first connection request from a user device, the first connection request including an access token. The access token is authenticated in the identity and access management service, and after successful authentication, a first tunnel is established between the user device and the target device via one or more intermediate gateways. The target device receives a second connection request from the user device, the second connection request including an access token. A second tunnel is established between the target device and the identity and access management service via one or more intermediate gateways, and the access token is verified in the identity and access management service via the second tunnel.
Description
Technical Field
The invention relates to remote connection in an industrial internet of things.
Background
The internet of things (IoT) is a networking of physical devices (also referred to as "connected devices" and "smart devices"), such as vehicles, home appliances, machines, computers, and other network-connected items embedded with electronics, software, sensors, actuators, and enabling these objects to collect and exchange data. IoT enables objects to be remotely sensed and/or controlled over existing network infrastructure. Industrial internet of things (IIoT) is the use of IoT technology in manufacturing. It combines machine learning and big data technologies, taking advantage of sensor data, machine-to-machine communication, and automation technologies that have existed in industrial environments for many years. IIoT also provides a mechanism to connect industrial devices to the cloud computing platform and transmit information to the cloud platform to perform various operations (e.g., analysis of industrial data or data mining). As is apparent from the above, a large amount of data is collected in the IIoT area, and it is also apparent that not every user of the system should be allowed to see every data item in the system. Since cloud computing platforms inherently include data from a large user base, the existence of access control is critical to the protection of sensitive industrial data. Furthermore, since the cloud computing platform is envisioned as a central repository of data that may belong to different stakeholders with different requirements for access control, the ability to provide controlled access to data collected throughout the life cycle of the system and devices is an important requirement within IIoT.
In IIoT, the data source may be some industrial device, such as a robot, motor, or drive. If the IIoT solution builds on top of existing automation and monitoring systems, or otherwise connects old devices, the IIoT solution may be required to support legacy protocols and technologies, such as the SCADA protocol, which may not be secure. This results in a hierarchical overall system structure containing multiple different security areas or system levels for different types of usage in the same plant. Many of the legacy systems and protocols are not designed to take into account current security principles, as there are multiple legacy systems and protocols still in use, and the network may be isolated as a separate secure area with limited external connections. To update software, analyze problems, manage configuration parameters, or monitor the operation of an industrial device, a user (e.g., a service technician) is typically required to remotely connect to the industrial device over the internet. However, for security reasons, industrial devices in legacy systems are not allowed to directly accept connections from the internet, and typically only allow secure output connections from them. In this case, the industrial device itself is not connected to any internet-facing device, but rather to a local interior gateway or edge computing device. The gateway may again connect to another interior gateway at a higher system level and so on until the last highest level interior gateway then connects to the internet.
Traditional remote access methods such as Virtual Private Networks (VPNs) and Remote Desktop Connections (RDCs) lack the flexibility and intelligence to meet today's needs of industrial organizations due to time consuming and complex setup and security issues. Accordingly, there is a need to improve the security and usability of existing mechanisms for establishing a remote connection to an industrial device.
Disclosure of Invention
It is an object of the present invention to provide a mechanism for establishing a secure remote connection between a user equipment and a target device. The object of the invention is achieved by methods, computer program products, apparatuses and systems which are characterized by what is stated in the independent claims. Preferred embodiments of the invention are disclosed in the dependent claims.
According to an aspect of the invention, there is provided a computer-implemented method comprising: receiving, by a first gateway, a first connection request from a user device, the first connection request comprising an access token; verifying the access token in the identity and access management service; after successful authentication, establishing a first tunnel between the user device and the target device via a chain of trusted certificate-based point-to-point connections, the chain passing through one or more intermediate gateways, wherein the first tunnel is established by using a reverse connection from the first gateway to the target device, the reverse connection being based on a pre-established connection from the target device to the first gateway via an outbound port in the target device and an outbound port in each of the one or more intermediate gateways in the chain, the target device not having a direct internet protocol connection to the user device without the first tunnel; receiving, by the target device, a second connection request from the user device via the first tunnel, the second connection request including an access token; establishing a second tunnel between the target device and the IAM service via a chain of trusted certificate-based point-to-point connections, the chain passing through one or more intermediate gateways, wherein the second tunnel is established by using a reverse connection from the first gateway to the target device, the target device not having a direct internet protocol connection to the IAM service without the second tunnel; and authenticating the access token in the IAM service via the second tunnel.
Drawings
In the following, exemplary embodiments will be described in more detail with reference to the accompanying drawings, in which,
FIG. 1 shows a simplified architecture of a system;
FIGS. 2 and 3 are flowcharts illustrating exemplary functions;
FIG. 4 illustrates information exchange; and
fig. 5 is a schematic block diagram.
Detailed Description
The following embodiments are exemplary. Although the description may refer to "an", "one", or "some" embodiment in several places, this does not necessarily mean that each such reference is to the same embodiment, or that the feature only applies to a single embodiment. Individual features of different embodiments may also be combined to provide other embodiments.
The invention can be applied to any system for realizing central management and edge calculation of data collected by the industrial Internet of things or a corresponding industrial system for generating data. Different embodiments and examples are described below without limiting the embodiments/examples to such solutions. A concept known as cloud computing and/or virtualization may be used. Virtualization may enable a single physical computing device to host one or more instances of a virtual machine that appears and operates as a standalone computing device, such that the single physical computing device may create, maintain, delete, or otherwise manage the virtual machine in a dynamic manner. Device operation will likely also be distributed among multiple servers, nodes, devices or hosts. In a cloud computing network device, computing devices and/or storage devices provide shared resources. Some other technological advancements, such as Software Defined Networking (SDN), may migrate one or more of the functions described below to any respective abstract concept or device or equipment. Accordingly, all words and expressions should be interpreted broadly and they are intended to illustrate, not to limit, the embodiments.
Fig. 1 shows a general exemplary architecture of a system. Fig. 1 is a simplified system architecture showing only some equipment (devices, apparatuses, nodes) and functional entities, all of which are logical units whose implementation and/or number may differ from that shown. The connections shown in FIG. 1 are logical connections; the actual physical connections may differ. Data collection may use a so-called master protocol (master is also referred to as protocol client), in which a network node subscribes to data from a slave (device that wants to have its data) and/or a slave protocol (slave is also referred to as protocol server), in which a device/network node sends its data to a receiver on query basis or automatically on subscription basis. It is obvious to a person skilled in the art that the system may also comprise other nodes (devices, apparatuses), functions and structures used in or for industrial internet of things, big data, virtualization, data management and communication in the system or in a part of the system. They and the protocols used are well known to those skilled in the art and are not relevant to the actual invention. Therefore, they need not be discussed in more detail here.
In the following embodiments, a concept called an equipment model is used as an example of the information model, without limiting the embodiments to the equipment model. It will be apparent to those skilled in the art how the disclosed principles may be implemented when other information models are used, such as information models relating to production transactions.
The architecture may be based on an edge computing model in which data from things may be processed by nearby edge computing devices, which may also be referred to herein as gateways.
In the embodiment shown in FIG. 1, the system 100 includes four different hierarchical levels: a global cloud level 101, forming a central management level, one or more enterprise levels 102 (only one depicted in fig. 1), one or more factory levels 103 (only one depicted in fig. 1), and one or more device levels 104 (only one depicted in fig. 1), which depict levels of different "things". It should be understood that any other level structure and/or hierarchy may be used between the device level 104 and the global cloud level 101.
The global cloud level 101 includes a global cloud 101 ', and the global cloud 101' includes data 110(IIoT data) originating from things. The data 110 may include raw data and/or analytical data. Further, the global cloud 101' may include a global equipment model repository 111, the global equipment model repository 111 including a plurality of equipment models 111-1.
The global cloud 101' may also include a server 112 that executes identity and access management service units, referred to herein as IAM services. Typically, there may be a large number of users in an IIoT system, but not every user should be allowed access to all devices or data in the system. To address this issue, a means of storing user-specific data 112-1 may be provided based on, for example, the IAM service 112 of OAuth 2.0, and the user-specific data 112-1 may include, for example, data regarding the role of each user in the organization/enterprise (e.g., system administrator, service technician, operator, plant manager, etc.). For example, communication with the IAM service 112 may be based on Lightweight Directory Access Protocol (LDAP). The IAM service 112 may also be configured to provide an access token to an authenticated user. These access tokens, e.g., based on Security Assertion Markup Language (SAML), may include authentication and authorization data for the user to exchange that data between the parties in system 100. As known to those skilled in the art, the access rights verification process may be defined in a separate security structure and therefore will not be described in detail herein. It should also be understood that, for example, the IAM service 112 may alternatively be located on the enterprise level 102.
In addition, the global cloud 101' may include a gateway 113, and the gateway 113 may include a tunnel service unit 113-1, referred to herein as a tunnel service. For example, the tunnel service may provide functionality for establishing an end-to-end tunnel between the user device 114 and the devices 141, 141' on the device layer 104. In other words, an authorized user may connect to the tunnel service to establish an Internet Protocol (IP) tunnel to the target service 141-2, 141 '-2 in the target device 141, 141'. The tunnel may use the Transmission Control Protocol (TCP), and is thus a TCP/IP tunnel. However, for example, User Datagram Protocol (UDP) may be used as an alternative to TCP. The TCP/IP tunnel may be relayed via an intermediate tunnel service 120-1, 130 '-1 between the cloud tunnel service 113-1 and the target service 141-2, 141' -2. The process for establishing the tunnel will be described in more detail later.
An equipment model describes metadata that is used to interpret the semantics of a device or piece of equipment. In other words, the equipment model describes the properties of the devices it models, and it is a type or definition of a virtual equipment type to provide a particular desired function. The term "equipment" or "equipment instance" refers herein to a virtual representation of something. The equipment instance contains the actual attribute values of the attributes of the thing, while the equipment model describes the information model and metadata of the attributes. There may be different equipment models for different hierarchical levels. The equipment model may include each attribute in the model definition, such as description, units, aggregation rules, and data collection protocols with sampling rules. For example, the equipment model may include the following definitions:
name of the model
Links to owners of models and other documents
Version number of model
Possible inheritance from another model
-for each possible attribute definition: data type of attribute (floating point of something, integer, text, array, etc.), scalar or time series, unit, numerical range, history type to collect (storage, aggregation rules such as time average, standard min/max, run time, etc.), data acquisition definition (protocol, project id, collection period, etc.), alarm limit. Further, the attribute definition may contain rules or definitions of how to map local data in the device/node to model attributes. Examples of mapping definitions include defining from which variable, register, or memory location data in a device is read to a particular attribute value and how often.
-function definitions describing which functions a device can perform
-interface definitions for exposing model-specific Application Programming Interfaces (APIs)
List of TCP/IP tunnels to a target service available from a device (e.g. a remote desktop service within the device itself or in another connected device)
In addition to equipment models for things, there may be one or more equipment models for gateways. The equipment model of the gateway may include, for example, both internal and security configurations of the gateway operation. However, part or all of the security configuration may be given in a separate equipment model (e.g. in the equipment model of a firewall or in the equipment model of a port). The internal configuration may include definitions of different alarm limits (i.e., specific types of notifications) that define which data for the internal telemetry operation is to be provided, what is reported, when to report, and alarms. The generic security definition for a gateway may be an internal secure communication protocol used in gateway-to-gateway communications.
For example, the model definition of equipment model 111-1 may be defined according to an ISA-95 type equipment model. ISA-95 is an ISO standard in which standard terms and information models are defined, which can be used to define equipment models. It should be understood that any other model definition of the information model may be used.
In summary, the equipment model can define the semantics of the data, control the plant data records, provide the basis for analysis and application and visualization without detailed information about the actual plant instances or signal names, and provide an integrated security model. The equipment model may thus provide a tool for common information modeling for network security with centralized design and unified application. Thus, data from heterogeneous data sources may be combined in a structured manner.
Although not shown in fig. 1, rules for data flow may be defined in addition to or included in the equipment model. For example, a rule may be referred to as a data flow rule, a data transmission rule, or a communication rule. The data flow rules may define what data is sent from the gateway and may also define when the data is sent. The data flow rules may also define what types of data will be received and/or how the data will be converted if conversion is required, for example because of different equipment model definitions in use. It should be understood that the data flow rules may be directed to data flows within the system, while notifications or different outputs on a user interface, etc. may not be within the definition of the data flow rules. However, no such distinction is made herein, and the following report may encompass, in addition to notifications or other information to which the user has subscribed, sending data according to one or more data flow rules, whether such rules are part of or separate from the equipment model.
Further, in the illustrated embodiment, one or more user devices 114 are connected to the global cloud 101'. For example, a service technician (with appropriate access rights) may use the user device to provide remote maintenance services to different enterprises, such as installing software updates to one or more devices 141, 141' at the device level 104. A non-limiting list of examples of user devices 114 includes a laptop, a workstation, a smart phone, a mobile phone, or a tablet. In the illustrated embodiment, the user device includes a tunnel client unit 114-1, referred to herein as a tunnel client, for remotely connecting to the device 141, 141 ', or more specifically, to a target service unit 141-2, 141' -2 (e.g., a remote desktop service), referred to herein as a target service. For example, tunnel client 114-1 may include a graphical user interface or a command line interface. Further, in the illustrated embodiment, device 141 and device level gateway 140 may include Role Based Access Control (RBAC) components for controlling access to target services 141-2, 141' -2 as part of tunnel services 140-1, 141-1. Alternatively, the global cloud 101' may include RBAC services for controlling access to target services. The RBAC is a user authorization mechanism that may be provided by the cloud computing platform to provide granular access control to the system based on the user's associated role in the organization/enterprise. It should be understood that although not depicted in fig. 1, at each level, the user may also connect directly to the gateway (if the gateway accepts a connection from the internet) by means of his/her user device in order to connect to the target service or to learn, process, etc. data at the required level, provided that the user has the required access rights.
The factory level 103 may comprise a plurality of gateways 130, 130 ', 130 ", 130'" (computing nodes). The gateways 130, 130 ', 130 ", 130'" at the plant level may provide a plant-wide service platform for applications including, for example, equipment models and instances, data collection, plant analysis, and other application runtimes. The factory level may be implemented through the use of one or more clouds, virtual machines, and/or physical computers. As can be seen in fig. 1, the gateways 130, 130 ', 130 "' at the plant level may be connected to the global cloud 101 'directly or to the global cloud 101' via one or more gateways 120 at the enterprise level. Each of the plant- level gateways 130, 130 ', 130 ", 130'" if directly connected thereto may include an intermediate tunnel service unit 130-1, 130 '-1, 130 "-1, 130'" -1 for relaying TCP/IP tunnels between the enterprise-level tunnel service 120-1 and the tunnel services 140-1, 141-1 on the device level 104.
In addition to the plurality of devices 141, 141 ', the device level 104 may include one or more gateways 140 (computing nodes), and the devices 141' may be connected to the one or more gateways 140. The gateway 140 at the device level may provide a device, system, or production line wide service platform for applications including, for example, equipment models and instances, data collection, analysis, and other application runtimes. Although not shown in fig. 1, the gateways 140 at the device level 104 may be directly connected to the global cloud, or connected to the global cloud via one or more gateways at the enterprise level 102, or via one or more gateways at the plant level 103, or via one or more chains of gateways at the plant level and gateways at the enterprise level as shown in fig. 1. It should be understood that although only shown in the device level gateway 140, any level of gateway may send data (communicate data) to multiple gateways (two, three, four, etc.) at higher levels. For example, a gateway may send data to gateways that represent different functional purposes, such as one for asset monitoring and production tracking, one for energy management, and one for gateway monitoring. Each of the device level gateways 140 may also include a tunnel service unit 140-1 for relaying TCP/IP tunnels between the factory level tunnel services 130 '-1, 130 "' -1 and target services 141 '-2 (e.g., remote desktop services) in the target device 141'. As shown in FIG. 1, the target device 141 at the device level 104 may also include a gateway function and a tunnel service 141-1 in the device itself to connect to the plant level gateway 130' without a separate device level gateway in between.
In fig. 1, the devices 141, 141' may represent what the industrial internet of things includes. Things can be different devices, machines, apparatuses, equipment, systems, subsystems, processes, etc. Some examples of things include pumps, motors, valves, industrial PCs, production lines, and control loops. There is no limitation on the composition of the matter. It is sufficient that the transaction comprises, for example, means for performing one or more different measurements and/or one or more operations on the environment and means for sending information to at least one or more gateways. Further, the things themselves may include things that are considered a combined thing by the analysis. The implementation of the industrial internet of things, the data collected therefrom and the means for information exchange are not of significance to the present invention and are therefore not described in detail here. It will be obvious to a person skilled in the art that any known or future solution may be used.
In fig. 1, a gateway is a computing device (node) configured to at least send and/or receive data, either as a stand-alone device or embedded in an existing device. Depending on the gateway and its use, the gateway may be a small electronic device, a mobile device, a laptop, a personal computer, a server, an edge computing device, a virtual machine, or cloud functionality, to name a few examples. Naturally, the gateway may comprise a data storage and/or one or more user interfaces.
To protect the IIoT system, in the illustrated embodiment, one or more Firewalls (FWs) may exist between the gateways, and the gateways may be configured to communicate with each other using a secure communication protocol. Thus, end-to-end security may be provided through an intermediate system (with corresponding middleware) to enable secure communication between different gateways. In this embodiment, data traffic from the gateway to northbound nodes (e.g., nodes at higher levels) may use an outbound port, such as port 80 or 443 in the gateway. The firewall may be configured to disallow connections to southbound nodes, e.g., gateways at lower levels, as depicted by the direction indicated by the arrowed end of the connection in fig. 1. More specifically, the gateways 140 and devices 141 at the device level 104 may be connected to gateways at higher levels via firewalls 154, 154', 154 ", but the gateways 140 and devices 141 may not be directly connected to the cloud, and thus they may not have a direct IP connection to the user device 114. Further, the gateways 130, 130 ', 130 "' at the factory level may in turn be connected to gateways at higher levels via firewalls 153, 153 ', 153"' or, if connected directly to the cloud, and the gateway 120 at the enterprise level may be connected to the cloud via firewall 152. This may lead to a situation where outbound connections from nodes in the industrial plant to the cloud are possible, but inbound connections from the cloud to nodes in the industrial plant are not possible. However, all connections may be bidirectional, such that when a node establishes an outbound connection to its northbound neighbor (e.g., a node at a higher level) via an outbound port, the connection is also established backwards. This may be referred to as a reverse connection. For example, device 141 at the device level may establish an outbound connection from device 141 to cloud gateway 113 via an outbound port in device 141 and an outbound port in an intermediate gateway on the path to cloud gateway 113, and cloud gateway 113 may then establish a reverse connection from cloud gateway 113 to device 141 using the pre-established active connection to enable bidirectional communication between cloud gateway 113 and device 141. In such an environment, the information of the connected nodes may include only northbound nodes with which outbound connections may be established. Further, the data flow rules may be bi-directional and include a definition of which direction (e.g., southbound to northbound or other) the data may be transmitted to. The various connections between the various nodes may collectively form a chain of trusted point-to-point connections (e.g., secure network socket connections) with certificate-based mutual authentication between the nodes in the system, and the cloud gateway 113 may be configured to have trusted bidirectional communication with one or more target devices 141, 141' via the chain. In particular, a point-to-point connection herein means a connection between a pair of adjacent nodes/gateways (e.g., between gateway 140 and gateway 130'). For example, the Transport Layer Security (TLS) protocol and x.509 Public Key Infrastructure (PKI) may be used to create a chain of trust and secure communications in the system. Additionally, the root certificate may be used to create certificates for target devices 141, 141', and user device 114 may be configured to trust the root certificate by default. Thus, the user device may also automatically trust the target device certificate. The TLS protocol, as well as the x.509pki and methods of creating certificate chains are well known to those skilled in the art, and therefore, will not be described in detail herein.
It should be understood that there may be other firewalls in addition to the firewall depicted in fig. 1.
Although not shown in fig. 1, the connections may be through one or more networks, which may be of the same type or different types. The type of network and protocol used is not significant to the present invention and, therefore, is not described in detail herein.
As previously mentioned, the hierarchy shown above depicts only one embodiment. In another embodiment, at the device level, there may be a gateway connected to multiple devices and to one or more gateways, which in turn are connected to multiple devices. In addition, gateways on the same level may be connected to each other. The hierarchy may enable centralized management of equipment models and data flow rules, including their distribution within the gateways, where they may be pushed down the hierarchy from the cloud and thus may be applied by all gateways (compute nodes). However, the equipment models in each gateway need not be the same, and the data flow rules may provide tools to enable conversion between equipment models and conversion between different data types.
In summary, figure 1 shows an IIoT platform architecture that can provide connectivity and access deep through the levels to get the required detailed information regardless of the actual data storage. Furthermore, the IIoT platform architecture may provide a means for integrated management and control of the fundamental resources from the device level 104 through to the global cloud 101', including security and devices that include the IIoT platform. The main information flow directions are from the global cloud level to lower levels (top to bottom) and from the device level to higher levels (bottom to top). It should be understood that the actual system topology, integration with external systems, etc. may vary depending on industry requirements and products, for example.
FIG. 2 illustrates software enabled functionality of an embodiment of the present invention. In step 201, a connection request is sent from a tunnel client application running on a user device to a tunnel service running on a first gateway (or on an enterprise level gateway) in a global cloud.
The tunnel service of the first gateway then sends a redirect request for an Identity and Access Management (IAM) service to the tunnel client application for authenticating the user and for obtaining a SAML access token for the user in step 202. It should be understood that other authentication protocols and token formats may be used. In step 203, the tunnel client application sends an authentication request to the IAM service and the user logs in, e.g. using his/her federated identity (i.e. username and password).
In case the authentication is unsuccessful (step 204: no), an appropriate error message is displayed to the user in step 205 and the process will not continue. In case of success (step 204: YES), the IAM service sends a user-specific access token to the tunnel client application in step 206.
The tunnel client application then sends a second connection request containing the user's access token to the tunnel service of the first gateway in step 207. The tunnel service of the first gateway then sends the user's access token to the IAM service for authentication in step 208.
In case of an unsuccessful authentication (step 209: no), an appropriate error message is displayed to the user in step 210 and the process will not continue. If the access token is successfully verified (step 209: YES), the tunnel client application then sends a query to the tunnel service of the first gateway in step 211 for a list of target services (e.g., remote desktop services) in the target device at a lower level (e.g., device level), which are assigned roles that are available for association with the user in the organization/enterprise. In another embodiment, the list may include available target devices rather than target services. Upon receiving the list, the tunnel client application presents the list to the user in a graphical user interface (or, for example, in a command line interface) of the tunnel client application.
In step 212, the user then selects an available target service from the list to attempt a connection, and the tunnel service of the first gateway communicates with tunnel services in other gateways on the path to the target service in order to open an end-to-end tunnel, e.g. a TCP/IP tunnel encrypted with TLS, between the user equipment and the tunnel service controlling access to the selected target service (i.e. the tunnel service in the same target device as the selected target service, or the tunnel service in another device/gateway directly connected to the target device containing the target service). The tunnel is relayed via a chain of trusted certificate-based point-to-point connections (e.g., secure web socket connections) that passes through an intermediate gateway between the user device and the tunnel service of the target (i.e., the tunnel service that controls access to the selected target service as previously described). Even though each of these intermediate point-to-point connections is thus individually encrypted, the end-to-end tunnel itself is individually encrypted using TLS in order to achieve end-to-end encryption. It should be noted that the tunnel is not established by any one gateway alone, as each of the intermediate gateways in the chain/path may also include its own tunnel service that may work with the tunnel service of the first gateway and the tunnel service of the target to open the tunnel. In other words, all tunnel services in a chain/path may include functionality that may be coordinated to work together in establishing an end-to-end tunnel.
In step 213, the tunnel client application sends a connection request containing the user's access token to the target tunnel service using the tunnel opened in step 212. Before granting the user access to the target service, another end-to-end tunnel is opened between the tunnel service of the target and the IAM service, e.g., a TCP/IP tunnel encrypted with TLS, by relaying the tunnel via a chain of trusted certificate-based point-to-point connections, which passes through an intermediate gateway between the tunnel service of the target and the IAM service, in step 214. The tunnel may also be established by all tunnel services working together in the chain/path, as in step 212. The tunnel service of the target then sends the user's access token to the IAM service via the tunnel for authentication.
In case of unsuccessful authentication (step 215: no), an appropriate error message is displayed to the user in step 216 and the user is denied access to the target service. If the access token is successfully verified (step 215: YES), then in step 217 the tunnel service of the target checks whether the user is authorized to access the target service based on the role associated with the user, e.g., using RBAC or some other authorization method. In case the authorization is not successful (step 218: no), an appropriate error message is displayed to the user in step 219 and the user is denied access to the target service. If the authorization is successful (step 218: YES), the tunnel service of the target grants the user access to the target service and an end-to-end connection is established between the user device and the target service via a tunnel between the tunnel service of the target and the user device in step 220. The user may then communicate with a target service (e.g., a remote desktop service) in the target device, for example, to remotely control it.
However, depending on how the target service itself is configured, the target service may also apply further actions to authenticate the user before granting access thereto, for example by requiring a username and password, or by re-verifying the user's access token using a tunnel from the target's tunnel service to the IAM service. In this case, the target service may request the user's access token separately from the user device. If the target service receives a connection request including the user's access token, the target service may then send the access token to the IAM service to verify the access token before granting the user access to the target service (a third time).
The steps and associated functions described above in fig. 2 are not in absolute chronological order, and some steps may be performed simultaneously or in an order different from the given order. Other functions may also be performed between or within the steps, and other information may be transmitted. Some steps or parts of steps may also be omitted or replaced by corresponding steps or parts of steps. For example, if the user device has previously obtained an access token, it may already be included in the first connection request of step 201, in which case the process will continue directly to step 208.
A particular problem with conventional remote access methods is user authentication, as user authentication in legacy systems typically requires the user to know the specific access credentials of each individual device in order to connect to it. Managing all individual credentials for potentially thousands of industrial devices is time consuming for service technicians, and managing all user accounts for potentially hundreds of service technicians is also time consuming for device management, especially with changing user roles. Due to this complexity, such legacy authentication systems may result in a compromise in corporate security policies. For example, in a legacy system, a discontented previous employee may still be able to use his/her user credentials to cause damage or injury to the system after his/her employment has ended. Thus, a particular benefit of some embodiments may be that they may be used to add an additional authentication layer for accessing the target service. Alternatively, if the tunnel is the only way to remotely access the target service, and all other ports are disabled, some embodiments may alternatively be used to replace existing authentication protocols used by the target service, such as by replacing the device-specific username and password with authentication using federated identity and authorization with the RBAC.
The tunnel between the user device and the target service may be used to forward any TCP/IP connection in either direction between the user device and the target service (e.g., a remote desktop connection from the target service to the user device is also possible) as long as the user is authenticated and the target service is configured to allow that connection for that particular user. For example, the target service may thus also use the tunnel to obtain software updates from a software repository on the user device's network. Another benefit of some embodiments may be that they may not require as complex a setup configuration to establish a remote connection as traditional remote access methods may do. Furthermore, some embodiments may enable remote access through multiple network level hierarchical tunnels using only existing (legacy) network infrastructure, such that, for example, there is no need to install any separate remote access gateway into the system. Although there may be multiple intermediate hops through different network levels, the connection may be established with end-to-end encryption between the target's tunnel service and the user equipment to prevent the intermediate node from establishing a man-in-the-middle attack even if the intermediate node is compromised. In other words, if a node is damaged, the point-to-point connection from that node may be disconnected, and as a result the end-to-end tunnel may be disconnected accordingly. The tunnel may also be automatically disconnected when the user's access token expires.
Figure 3 illustrates the software enabled functionality of an embodiment of the present invention from the perspective of a user device comprising a tunnel client application. In step 301, the tunnel client application detects, via a graphical user interface (or command line interface), a user input requesting a connection to a tunnel service running on a first gateway (or on an enterprise level gateway) in the global cloud. In step 302, the tunnel client application then sends a corresponding connection request to the tunnel service running on the first gateway.
In step 303, the tunnel client application receives a redirect request for an Identity and Access Management (IAM) service from the tunnel service of the first gateway for authenticating the user and for obtaining a SAML access token for the user. In step 304, the tunnel client application sends the connection request to the IAM service, and in step 305 the user is required to log into the IAM service in a web browser window, for example by using a user-specific federated identity.
In case the login is unsuccessful (step 306: no), the tunnel client application displays an appropriate error message to the user in step 307, and the process will not continue further, or the user may be required to retry the login. In case of success (step 306: yes), the tunnel client application receives the user's user-specific access token from the IAM service in step 308.
The tunnel client application then sends a second connection request containing the user's access token to the tunnel service of the first gateway in step 309. Then, in step 310, the tunnel client application receives a reply from the tunnel service of the first gateway as to whether the connection was successful. In case of an unsuccessful connection (step 310: no), the tunnel client application displays an appropriate error message to the user in step 311 and the process will not continue. If the connection is successful (step 310: YES), the tunnel client application then sends a query to the tunnel service of the first gateway in step 312 for obtaining a list of target services (e.g., remote desktop services) that are assigned roles that are available for association with the user in the organization/enterprise. In step 313, the tunnel client application receives the list and presents it to the user in a graphical user interface (or, for example, in a command line interface) of the tunnel client application.
The tunnel client application then detects, in step 314, a user input requesting connection to a target service specified by the user, and in step 315, the tunnel client application sends a request to the tunnel service of the first gateway to establish a tunnel between the user device and the tunnel service controlling access to the selected target service (i.e., the tunnel service in the same target device as the selected target service, or the tunnel service in another device/gateway directly connected to the target device containing the target service). In step 316, the tunnel client application receives the information that the tunnel is established, and in step 317, the tunnel client application sends a connection request containing the user's access token to the tunnel service of the target (i.e., the tunnel service that controls access to the selected target service).
Then, in step 318, the tunnel client application receives a reply from the tunnel service of the target as to whether the connection was successful. In case of an unsuccessful connection (step 318: no), the tunnel client application displays an appropriate error message to the user in step 319 and the process will not continue. If the connection is successful (step 318: YES), the user equipment may use the tunnel created between the user equipment and the tunnel service of the target to communicate with the target service in step 320.
The steps and associated functions described above in fig. 3 are not in absolute chronological order, and some steps may be performed simultaneously or in an order different from the given order. Other functions may also be performed between or within the steps, and other information may be transmitted. Some of the steps or parts of the steps may also be omitted or replaced by corresponding steps or parts of the steps.
FIG. 4 shows the basic functions of an embodiment of the present invention in the form of a simplified swim lane diagram. This embodiment includes an IAM service 401, a user device 402 including a tunnel client application, a first gateway 403 including a tunnel service, one or more intermediate gateways 404 including a tunnel service, one or more device gateways 405 including a tunnel service, and one or more target services 406. The device gateway 405 is a gateway that directly connects to one or more target devices including one or more target services 406 (e.g., remote desktop services). Alternatively, the device gateway 405 may also be a target device that itself includes gateway functionality, in which case the target service 406 would be internal to the device gateway 405. In the illustrated embodiment, the IAM service 401, the user device 402, and the first gateway 403 are all on the public internet, while the intermediate gateway 404, the device gateway 405, and the target service 406 are on a protected intranet network that is separated from the public internet by a Firewall (FW) 407. There is also another firewall 408 within the intranet network between the intermediate gateway 404 and the device gateway 405. In this embodiment, there are trusted certificate-based connections, e.g., secure web socket connections, between the device gateway 405 and the intermediate gateway 404 and between the intermediate gateway 404 and the first gateway 403. These connections may use outbound ports in the device gateway and outbound ports (e.g., ports 80 or 443) in the intermediate gateway.
In point 410 a connection request is sent from the user equipment to the first gateway. In point 411, the first gateway does not detect the access token in the connection request and sends a redirect request to the IAM service to the user equipment for authenticating the user and for obtaining a SAML access token for the user. In point 412 the user device sends an authentication request to the IAM service and in point 413 the user logs in with e.g. his/her federated identity (i.e. username and password). Upon successful login, in point 414, the IAM service sends a user-specific access token to the user device.
In point 415 the user device then sends a second connection request to the first gateway containing the user's access token. The first gateway then sends the user's access token to the IAM service for authentication, in point 416. After successful verification, in point 417, the IAM service sends a reply stating that the verification was successful to the first gateway. Then, in point 418, the first gateway allows the connection and sends a reply stating that the connection request was successful to the user equipment.
In point 419 the user device sends a query to the first gateway for a list of target services (e.g. remote desktop services) that are assigned to roles available for association with the user in the organization/enterprise, and in point 420 the first gateway sends the list as a reply to the user device. In point 421, the user device sends a request to the first gateway to open a tunnel to the device gateway controlling access to the target service to which the user wants to connect.
In point 422, the user device, the first gateway, the intermediate gateway and the device gateway communicate with each other to establish an end-to-end tunnel between the user device and the device gateway, e.g. a TCP/IP tunnel encrypted with TLS. The tunnel is relayed via a chain of trusted point-to-point connections (e.g., secure web socket connections) through an intermediate gateway and a first gateway between the user device and the device gateway. Even though each of these intermediate point-to-point connections is thus individually encrypted, the end-to-end tunnel itself is individually encrypted using TLS in order to achieve end-to-end encryption.
In point 423, the user device sends a connection request (via the tunnel) to the device gateway containing the user's access token for requesting access to the target service. Before granting the user device access to the target service, a second encrypted end-to-end tunnel, e.g., a TCP/IP tunnel encrypted with TLS, is opened between the device gateway and the IAM service in point 424 by relaying the tunnel through an intermediate gateway and a first gateway between the device gateway and the IAM service.
In point 425, the device gateway then sends the user's access token to the IAM service for authentication via the second tunnel. After the verification is successful, the IAM service sends a reply stating that the verification was successful to the device gateway, in point 426. Then, in point 427, the device gateway sends a reply to the user device stating that the connection request was successful and that the user device is now allowed to communicate with the target service. Finally, in point 428, the user equipment may communicate with the target service using the first tunnel.
Fig. 5 is a simplified block diagram illustrating some elements of a device (apparatus) 500, the device 500 being, for example, a user equipment, a device-level device, a gateway for IIoT, or a corresponding computing device. In the example shown, the apparatus comprises: one or more Interfaces (IF)501 for receiving and/or retrieving information from other devices and possibly from a user and/or sending information to other devices and possibly to a user; a processor 502; an algorithm 503 corresponding to one or more of the functions described above in connection with fig. 1-4; and a memory 504 operable to store computer program code required for the algorithm to implement the function. Memory 504 may also be used to store other possible information such as configuration, lists, data flow rules, equipment models, telemetry data, firewall data, and the like.
In other words, a device (apparatus) configured to provide one or more of the functions described above in connection with fig. 1-4 is a computing device, which may be any apparatus or device or equipment or node configured to perform one or more of the respective device functions described with an embodiment/example/implementation, and which may be configured to perform functions from a different embodiment/example/implementation.
The apparatus/device may include a processor, controller, control unit, microcontroller, etc. connected to the memory and various interfaces of the device. The processor may be a central processing unit or the processor may be an additional operational processor. Each or some or one of the units/sub-units and/or algorithms described herein may be configured as a computer or processor, or a microprocessor, e.g. a single chip computer element or e.g. a chip set, comprising at least a memory for providing a memory area for arithmetic operations and an operation processor for performing arithmetic operations. Each or some or one of the above units/sub-units and/or algorithms may comprise one or more computer processors, Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), logic gates and/or other hardware components that have been programmed and/or are to be programmed in a manner that downloads computer program code (one or more algorithms) to perform one or more functions of one or more embodiments/implementations/examples. Embodiments provide a computer program embodied on any client-readable distribution/data storage medium or storage unit or article of manufacture, comprising program instructions executable by one or more processors/computers, which instructions, when loaded into an apparatus, constitute one or more of the functions described above in connection with fig. 1-4. Programs, also called program products, including software routines, program fragments constituting "program libraries", applets and macros, may be stored in any medium and downloaded into a device. In other words, each or some or one of the above units/sub-units and/or algorithms may be an element comprising one or more arithmetic logic units, a plurality of special registers and control circuitry.
Furthermore, a device/apparatus configured to provide a gateway for IIoT or a device configured to provide one or more of the respective functions described above with reference to fig. 1-4 may include volatile and/or non-volatile memory, such as EEPROM, ROM, PROM, RAM, DRAM, SRAM, dual floating gate field effect transistors, firmware, programmable logic, etc., and typically stores content, data, etc. The one or more memories may be of any type (different from each other), have any possible storage structure, and are managed by any database management system, if desired. In other words, the memory or a portion thereof may be any computer-usable non-transitory medium internal to the processor/device or external to the processor/device, in which case it can be communicatively coupled to the processor/device via various means as is known in the art. Examples of the external memory include a removable memory detachably connected to the apparatus, a distributed database, and a cloud server. The memory may also store computer program code, such as software applications (e.g., for one or more of the units/sub-units/algorithms) or operating systems, information, data, content, etc., for the processor to perform steps associated with operation of the apparatus according to examples/embodiments.
It will be obvious to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The invention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.
Claims (15)
1. A computer-implemented method, comprising:
-receiving, by the first gateway (113), a first connection request from the user equipment (114), the first connection request comprising an access token;
-verifying the access token in an identity and access management, IAM, service (112);
-establishing a first tunnel between the user device (114) and a target device (141, 141 ') via a chain of trusted certificate-based point-to-point connections after successful authentication, the chain passing through one or more intermediate gateways (120, 130', 140), wherein the first tunnel is established by using a reverse connection from the first gateway (113) to the target device (141, 141'), the reverse connection is based on a pre-established connection from the target device (141, 141 ') to the first gateway (113) via an outbound port in the target device (141, 141 ') and an outbound port in each of one or more intermediate gateways (120, 130 ', 140) in the chain, the target device (141, 141') does not have a direct internet protocol connection to the user device (114) without the first tunnel;
-receiving, by the target device (141, 141'), a second connection request from the user device (114) via the first tunnel, the second connection request comprising the access token;
-establishing a second tunnel between the target device (141, 141 ') and the IAM service (112) via a chain of trusted certificate-based point-to-point connections, the chain passing through the one or more intermediate gateways (120, 130', 140), wherein the target device (141, 141 ') has no direct internet protocol connection to the IAM service (112) without the second tunnel by establishing the second tunnel using a reverse connection from the first gateway (113) to the target device (141, 141');
-verifying the access token in the IAM service (112) via the second tunnel.
2. The computer-implemented method of any preceding claim, wherein an X.509 public key infrastructure is used to create the chain of trusted certificate-based point-to-point connections, and a root certificate is used to create a certificate for the target device (141, 141'), wherein the user device (114) is configured to trust the root certificate by default.
3. The computer-implemented method of any preceding claim, further comprising:
-receiving, by the first gateway (113), a token-less connection request from the user equipment (114);
-redirecting, by the first gateway (113), the user equipment (114) to the IAM service (112);
-authenticating a user of the user equipment (114) in the IAM service (112);
-receiving, by the user equipment (114), the access token from the IAM service (112) upon successful authentication;
-receiving, by the first gateway (113), the first connection request from the user equipment (114), the first connection request comprising the access token.
4. The computer-implemented method of any preceding claim, further comprising:
-verifying, by the target device (141, 141 '), that the user is authorized to access a target service (141-2, 141 ' -2), the target service (141-2, 141 ' -2) being comprised in the target device (141, 141 ') or in another device directly connected to the target device (141, 141 ');
-upon successful authorization, granting the user equipment (114) access to communicate with the target service (141-2, 141' -2) via the first tunnel.
5. The computer-implemented method of claim 4, further comprising:
-receiving, by the target service (141-2, 141' -2), a third connection request from the user equipment (114) via the first tunnel, the third connection request comprising the access token;
-verifying the access token in the IAM service (112) via the second tunnel.
6. The computer-implemented method of any of claims 4 to 5, wherein the authorization of the user is based at least on one or more roles associated with the user.
7. A computer program product comprising program instructions which, when run on a computing device, cause the computing device to perform the method of any preceding claim.
8. An apparatus comprising means for implementing the method of any of claims 1-6.
9. The apparatus of claim 8, the apparatus comprising: at least one processor; and a memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, provide the apparatus for implementation.
10. A system, comprising at least:
-a user equipment (114);
-a target device (141, 141');
-three or more gateways (113, 120, 130', 140);
-wherein one of the three or more gateways is a first gateway (113), the first gateway (113) being configured to receive a first connection request from the user equipment (114), the first connection request comprising an access token;
-wherein one of the three or more gateways is a device gateway (140) directly connected to the target device (141') or comprised in the target device (141);
-wherein at least one of the three or more gateways is an intermediate gateway (120, 130') between the first gateway (113) and the device gateway (140);
-wherein the first gateway (113) is further configured to: having trusted bidirectional communication with the target device (141, 141 ') via a chain of trusted certificate-based point-to-point connections by using a reverse connection from the first gateway (113) to the target device (141, 141 '), the reverse connection being based on a pre-established connection from the target device (141, 141 ') to the first gateway (113) via an outbound port in the target device (141, 141 ') and an outbound port in the intermediate gateway (120, 130 ');
-wherein the first gateway (113) is further configured to send the access token to an identity and access management, IAM, service (112) for verification of the access token;
-wherein the three or more gateways (113, 120, 130', 140) are configured to: establishing a first tunnel between the target device (141, 141 ') and the user device (114) by using a reverse connection from the first gateway (113) to the target device (141, 141 '), the target device (141, 141 ') not having a direct internet protocol connection to the user device (114) without the first tunnel;
-wherein the target device (141, 141') is further configured to receive a second connection request from the user device (114) via the first tunnel, the second connection request comprising the access token;
-wherein the three or more gateways (113, 120, 130', 140) are further configured to: establishing a second tunnel between the IAM service (112) and the target device (141, 141 ') via the chain of trusted certificate-based point-to-point connections using a reverse connection from the first gateway (113) to the target device (141, 141 '), the target device (141, 141 ') not having a direct Internet protocol connection to the IAM service (112) without the second tunnel;
-wherein the target device (141, 141') is further configured to send the access token to the IAM service (112) via the second tunnel for verification of the access token.
11. The system of claim 10, wherein the target device (141, 141') is further configured to: verifying that a user associated with the access token is authorized to access a target service (141-2, 141' -2); and upon successful authorization, granting the user equipment (114) access to communicate with the target service (141-2, 141' -2) via the first tunnel.
12. The system of claim 11, wherein the target service (141-2, 141' -2) is configured to: receiving a third connection request from the user equipment (114) via the first tunnel, the third connection request comprising the access token; and sending the access token to the IAM service (112) via the second tunnel for verification of the access token.
13. The system of any of claims 11 to 12, wherein the authorization of the user is based at least on one or more roles associated with the user.
14. The system of any of claims 10 to 13, wherein the first gateway (113) and the IAM service (112) are comprised in a global cloud (101 '), and at least one intermediate gateway (120) is connected to the global cloud (101').
15. The system of any of claims 10 to 14, wherein an x.509 public key infrastructure is used to create the chain of trusted certificate-based point-to-point connections.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP16060737 | 2019-03-29 | ||
| EP191660737 | 2019-03-29 | ||
| PCT/EP2020/058795 WO2020201128A1 (en) | 2019-03-29 | 2020-03-27 | Secure remote connections in industrial internet of things |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113632437A true CN113632437A (en) | 2021-11-09 |
| CN113632437B CN113632437B (en) | 2023-05-30 |
Family
ID=78378420
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202080025219.0A Active CN113632437B (en) | 2019-03-29 | 2020-03-27 | Secure remote connection in industrial Internet of things |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113632437B (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113890767A (en) * | 2021-11-12 | 2022-01-04 | 中国联合网络通信集团有限公司 | Network access method, device, equipment and storage medium |
| CN115550179A (en) * | 2022-09-28 | 2022-12-30 | 国网北京市电力公司 | Information physical system remote debugging method and device, storage medium and equipment |
| CN116527396A (en) * | 2023-06-09 | 2023-08-01 | 数篷信息技术(深圳)有限公司 | Intranet business service system, intranet business data access method and device |
| CN119814755A (en) * | 2024-12-27 | 2025-04-11 | 临海市新睿电子科技股份有限公司 | Remote control method for industrial Internet of Things equipment and computer readable storage medium |
Citations (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1999056434A1 (en) * | 1998-04-29 | 1999-11-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Method, arrangement and apparatus for authentication |
| CA2683510A1 (en) * | 2007-04-25 | 2008-11-06 | Qualcomm Incorporated | Route protocol |
| US20090016300A1 (en) * | 2007-06-18 | 2009-01-15 | Qualcomm Incorporated | Method and apparatus for fast inter-system handover |
| US20090328182A1 (en) * | 2008-04-17 | 2009-12-31 | Meher Malakapalli | Enabling two-factor authentication for terminal services |
| EP2660667A2 (en) * | 2012-05-04 | 2013-11-06 | Rockwell Automation Technologies, Inc. | Cloud gateway for industrial automation information and control systems |
| US20140123231A1 (en) * | 2012-10-31 | 2014-05-01 | International Business Machines Corporation | Extending authentication and authorization capabilities of an application without code changes |
| US20150188949A1 (en) * | 2013-12-31 | 2015-07-02 | Lookout, Inc. | Cloud-based network security |
| US9148408B1 (en) * | 2014-10-06 | 2015-09-29 | Cryptzone North America, Inc. | Systems and methods for protecting network devices |
| US9298935B1 (en) * | 2013-09-20 | 2016-03-29 | Piyush Kumar | Distributed privacy framework system and method of implementation |
| US20170026339A1 (en) * | 2015-07-21 | 2017-01-26 | Sap Se | Centralized authentication server for providing cross-domain resources via a rest-based tunnel |
| US9560015B1 (en) * | 2016-04-12 | 2017-01-31 | Cryptzone North America, Inc. | Systems and methods for protecting network devices by a firewall |
| US20170289882A1 (en) * | 2016-04-01 | 2017-10-05 | Qualcomm Incorporated | Interworking with legacy radio access technologies for connectivity to next generation core network |
| WO2017176398A1 (en) * | 2016-04-06 | 2017-10-12 | Qualcomm Incorporated | Network verification of wearable devices |
| US9948612B1 (en) * | 2017-09-27 | 2018-04-17 | Citrix Systems, Inc. | Secure single sign on and conditional access for client applications |
| CN108600204A (en) * | 2018-04-11 | 2018-09-28 | 浙江大学 | A kind of corporate intranet access method based on Opposite direction connection and application layer tunnel |
-
2020
- 2020-03-27 CN CN202080025219.0A patent/CN113632437B/en active Active
Patent Citations (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1999056434A1 (en) * | 1998-04-29 | 1999-11-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Method, arrangement and apparatus for authentication |
| CA2683510A1 (en) * | 2007-04-25 | 2008-11-06 | Qualcomm Incorporated | Route protocol |
| US20090016300A1 (en) * | 2007-06-18 | 2009-01-15 | Qualcomm Incorporated | Method and apparatus for fast inter-system handover |
| US20090328182A1 (en) * | 2008-04-17 | 2009-12-31 | Meher Malakapalli | Enabling two-factor authentication for terminal services |
| EP2660667A2 (en) * | 2012-05-04 | 2013-11-06 | Rockwell Automation Technologies, Inc. | Cloud gateway for industrial automation information and control systems |
| US20140123231A1 (en) * | 2012-10-31 | 2014-05-01 | International Business Machines Corporation | Extending authentication and authorization capabilities of an application without code changes |
| US9298935B1 (en) * | 2013-09-20 | 2016-03-29 | Piyush Kumar | Distributed privacy framework system and method of implementation |
| US20150188949A1 (en) * | 2013-12-31 | 2015-07-02 | Lookout, Inc. | Cloud-based network security |
| US9148408B1 (en) * | 2014-10-06 | 2015-09-29 | Cryptzone North America, Inc. | Systems and methods for protecting network devices |
| US20170026339A1 (en) * | 2015-07-21 | 2017-01-26 | Sap Se | Centralized authentication server for providing cross-domain resources via a rest-based tunnel |
| US20170289882A1 (en) * | 2016-04-01 | 2017-10-05 | Qualcomm Incorporated | Interworking with legacy radio access technologies for connectivity to next generation core network |
| WO2017176398A1 (en) * | 2016-04-06 | 2017-10-12 | Qualcomm Incorporated | Network verification of wearable devices |
| US9560015B1 (en) * | 2016-04-12 | 2017-01-31 | Cryptzone North America, Inc. | Systems and methods for protecting network devices by a firewall |
| US9948612B1 (en) * | 2017-09-27 | 2018-04-17 | Citrix Systems, Inc. | Secure single sign on and conditional access for client applications |
| CN108600204A (en) * | 2018-04-11 | 2018-09-28 | 浙江大学 | A kind of corporate intranet access method based on Opposite direction connection and application layer tunnel |
Non-Patent Citations (1)
| Title |
|---|
| 陈艺: "浅析HTTP隧道个人防火墙技术", 《煤炭技术》 * |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113890767A (en) * | 2021-11-12 | 2022-01-04 | 中国联合网络通信集团有限公司 | Network access method, device, equipment and storage medium |
| CN113890767B (en) * | 2021-11-12 | 2023-07-11 | 中国联合网络通信集团有限公司 | Network access method, device, equipment and storage medium |
| CN115550179A (en) * | 2022-09-28 | 2022-12-30 | 国网北京市电力公司 | Information physical system remote debugging method and device, storage medium and equipment |
| CN116527396A (en) * | 2023-06-09 | 2023-08-01 | 数篷信息技术(深圳)有限公司 | Intranet business service system, intranet business data access method and device |
| CN119814755A (en) * | 2024-12-27 | 2025-04-11 | 临海市新睿电子科技股份有限公司 | Remote control method for industrial Internet of Things equipment and computer readable storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113632437B (en) | 2023-05-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3949318B1 (en) | Secure remote connections in industrial internet of things | |
| US12052137B2 (en) | Centralized security event generation policy | |
| CN113632437B (en) | Secure remote connection in industrial Internet of things | |
| US9772623B2 (en) | Securing devices to process control systems | |
| US11799911B2 (en) | Systems and methods for security protocol execution in a hierarchical state machine-driven execution plan | |
| US10749692B2 (en) | Automated certificate enrollment for devices in industrial control systems or other systems | |
| Tsuchiya et al. | Software defined networking firewall for industry 4.0 manufacturing systems | |
| JP7383368B2 (en) | Methods, systems for securely transferring communications from a process plant to another system | |
| US11588856B2 (en) | Automatic endpoint security policy assignment by zero-touch enrollment | |
| US10257163B2 (en) | Secured process control communications | |
| Alcaraz et al. | Policy enforcement system for secure interoperable control in distributed smart grid systems | |
| WO2020051486A1 (en) | Blockchain-based secured multicast communications | |
| JP6766895B2 (en) | How to communicate securely and industrial computing equipment | |
| EP3667526B1 (en) | Rapid file authentication on automation devices | |
| CN114746818B (en) | Method and system for providing data from an internal data processing system of an industrial plant to an external data processing system | |
| CN102714661B (en) | System for remote servicing of technical equipment | |
| Suciu et al. | IoT platform for personal data protection | |
| Chenaru | Gateway for secure IIoT integration in industrial control applications | |
| AU2017228252B9 (en) | Method and system for providing permissions management | |
| Rogers | IRI Technology Landscape--A survey of re-usable components and methodologies | |
| EP3889711A1 (en) | Portable cybersecurity run-time engines | |
| GB2581473A (en) | Electronic device configuration mechanism |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |