CN113632437B - Secure remote connection in industrial Internet of things - Google Patents
Secure remote connection in industrial Internet of things Download PDFInfo
- Publication number
- CN113632437B CN113632437B CN202080025219.0A CN202080025219A CN113632437B CN 113632437 B CN113632437 B CN 113632437B CN 202080025219 A CN202080025219 A CN 202080025219A CN 113632437 B CN113632437 B CN 113632437B
- Authority
- CN
- China
- Prior art keywords
- tunnel
- user
- gateway
- target device
- identity
- 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.)
- Active
Links
Images
Abstract
A method for establishing a secure remote connection between a user device and a target device is disclosed, wherein the target device does not have a direct internet connection. The first gateway receives a first connection request from a user device, the first connection request including an access token. The access token is verified in the identity and access management service and after successful verification 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 the one or more intermediate gateways, and the access token is authenticated in the identity and access management service via the second tunnel.
Description
Technical Field
The invention relates to remote connection in industrial Internet of things.
Background
The internet of things (IoT) is a network 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 network-connected items that enable 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 a use of IoT technology in manufacturing. It combines machine learning and big data techniques, exploiting sensor data, machine-to-machine communication and automation techniques that have existed in industrial environments for many years. IIoT also provides a mechanism to connect industrial devices to the cloud computing platform and to transmit information to the cloud platform to perform various operations (e.g., analysis or data mining of industrial data). It is apparent from the above that a large amount of data is collected in the IIoT area and that also not every user of the system should be allowed to see every data item in the system. Since cloud computing platforms essentially include data from a large library of users, the presence of access control is critical to the protection of sensitive industrial data. Furthermore, because cloud computing platforms are envisioned as a central repository of data that may belong to different stakeholders having different requirements for access control, the ability to provide controlled access to data collected throughout the lifecycle of the systems and devices is an important requirement within IIoT.
In IIoT, the data source may be some industrial equipment, such as a robot, motor, or drive. If the IIoT solution is built on top of an existing automation and monitoring system or otherwise connects to legacy equipment, the IIoT solution may be required to support legacy protocols and technologies that may not be secure, such as SCADA protocols. This results in a hierarchical overall system structure that contains multiple different security zones or system levels for different types of use in the same plant. Because there are multiple legacy systems and protocols that are still in use, many of the legacy systems and protocols are not designed to take into account current security principles and the network may be isolated as a separate security area with limited external connections. In order to update software, analyze problems, manage configuration parameters, or monitor operation of industrial equipment, it is often necessary for a user (e.g., a service technician) to remotely connect to the industrial equipment via the internet. However, for security reasons, industrial devices in legacy systems are not allowed to accept connections directly from the internet, and are typically only allowed to secure output connections from them. In this case, the industrial device itself is not connected to any internet-oriented device, but rather to a local interior gateway or edge computing device. The gateway may connect again 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 (VPN) and Remote Desktop Connections (RDC) lack the flexibility and intelligence to meet today's industry organization needs due to time consuming and complex setup and security issues. Thus, there is a need to improve the security and usability of existing mechanisms for establishing remote connections to industrial equipment.
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 a method, a computer program product, an arrangement and a system characterized in what is stated in the independent claims. Preferred embodiments of the invention are disclosed in the dependent claims.
According to an aspect of the present 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 including 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 having no 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 having no direct internet protocol connection to the IAM service without the second tunnel; and verifying the access token in the IAM service via the second tunnel.
Drawings
Hereinafter, 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 specification may refer to "an", "one", or "some" embodiment at several locations, this does not necessarily mean that each such reference is to the same embodiment, or that the features are applicable to only a single embodiment. Individual features of different embodiments may also be combined to provide further embodiments.
The invention can be applied to any system for realizing central management and edge calculation on data collected by the industrial Internet of things or a corresponding industrial system for generating data. The 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 stand-alone computing device such that the single physical computing device may dynamically create, maintain, delete, or otherwise manage the virtual machine. Device operations will also likely be distributed among multiple servers, nodes, devices, or hosts. In a cloud computing network device, a computing device and/or a storage device provide shared resources. Some other technological advances, such as Software Defined Networking (SDN), may enable one or more of the functions described below to migrate to any corresponding abstract concept or apparatus or device. Thus, all words and expressions should be interpreted broadly and these words and expressions are intended to illustrate, not to limit, the embodiments.
Fig. 1 illustrates a general exemplary architecture of a system. Fig. 1 is a simplified system architecture showing only some of the equipment (devices, apparatuses, nodes) and functional entities, all of which are logical units that may be implemented in a different manner and/or number than shown. The connections shown in fig. 1 are logical connections; the actual physical connections may be different. The data collection may use a so-called master device protocol (master device also called protocol client), wherein the network node subscribes to data from the slave device (device that wants to have its data) and/or from the device protocol (slave device also called protocol server), wherein the device/network node sends its data to the receiver based on the query or automatically sends its data to the receiver based on the subscription. It will be apparent to those skilled in the art that the system may also include other nodes (apparatus, devices), functions and structures used in or for industrial internet of things, big data, virtualization, data management and communications in or of the system or a portion 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 herein.
In the following embodiments, a concept called an equipment model is used as an example of an information model, and the embodiments are not limited to the equipment model. It will be apparent to those skilled in the art how to implement the disclosed principles when using other information models, such as information models related 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, system 100 includes four different hierarchical levels: a global cloud level 101, one or more enterprise levels 102 (only one depicted in fig. 1), one or more plant 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," form a central management level. It should be appreciated 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 101' may also include a server 112 executing an identity and access management service unit, referred to herein as an IAM service. In general, 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 IAM service 112, such as OAuth 2.0, and user-specific data 112-1 may include, for example, data regarding the roles of each user in the organization/enterprise (e.g., system administrator, service technician, operator, plant manager, etc.). For example, the 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 the authenticated user. These access tokens, for example based on the Security Assertion Markup Language (SAML), may include authentication and authorization data for the user in order to exchange this data between the parties in the system 100. As known to those skilled in the art, the access rights verification process may be defined in a separate security structure and thus will not be described in detail herein. It should also be appreciated that, for example, the IAM service 112 may alternatively be located on the enterprise level 102.
Further, global cloud 101' may include gateway 113, and gateway 113 may include 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 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 intermediate tunnel service 120-1, 130'-1 between cloud tunnel service 113-1 and target service 141-2, 141' -2. The process for establishing the tunnel will be described in more detail later.
The 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 device it models, and it is a type or type definition of virtual equipment to provide a particular desired function. The term "equipment" or "equipment instance" refers herein to a virtual representation of things. 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 model
Links to owners of models and other documents
Version number of model
Possible inheritance from another model
-for each attribute, possibly included an attribute definition: the data type of the attribute (floating point of something, integer, text, array, etc.), scalar or time series, unit, range of values, type of history to collect (storage, aggregation rules such as time average, standard min/max, run time, etc.), data acquisition definition (protocol, item 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 variables, registers, or memory locations data in a device is read to a particular attribute value and how often.
Function definition describing what functions a device can perform
-interface definition for exposing model-specific Application Programming Interfaces (APIs)
List of TCP/IP tunnels to a target service available from a device (e.g. remote desktop service within the device itself or in another connected device)
In addition to the equipment model for things, there may be one or more equipment models of the gateway. 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 a definition of which data defining the internal telemetry operations are to be provided, what is reported, when reported, and the different alarm limits (i.e., specific types of notifications) of the alarm. The generic security definition of the gateway may be an internal security communication protocol used in gateway-to-gateway communications.
For example, the model definition of equipment model 111-1 may be defined in accordance with 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 appreciated that any other model definition of an information model may be used as well.
In summary, the equipment model may define the semantics of the data, control the device data records, provide a basis for analysis and application as well as visualization without detailed information about the actual device instance or signal name, and provide an integrated security model. The equipment model may thus provide a tool for public information modeling of network security with centralized design and unified application. Thus, data from disparate data sources can be combined in a structured manner.
Although not shown in fig. 1, rules for the data flow may be defined in addition to or included in the equipment model. For example, the rules may be referred to as data flow rules, data transmission rules, or communication rules. The data flow rules may define what data is sent from the gateway, and also when data is sent. The data flow rules may also define what type of data is to be received and/or how to transform the data if the transformation is required, for example, because of different equipment model definitions in use. It should be appreciated that the data flow rules may be for data flows within the system, while notifications or different outputs on the 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 these 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 a 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, workstation, smart phone, mobile phone, or 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 precisely to the target service unit 141-2, 141' -2 (e.g., remote desktop service), referred to herein as 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 an RBAC service for controlling access to a target service. RBAC is a user authorization mechanism that may be provided by a cloud computing platform to provide granular access control to a system based on the user's associated roles in an 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 by means of his/her user device (if the gateway accepts a connection from the internet) in order to connect to the target service or to learn, process, etc. data on the required level, provided that the user has the required access rights.
The plant level 103 may include a plurality of gateways 130, 130', 130", 130'" (compute 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", 130'" at the factory level may be connected directly to the global cloud 101 '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'" 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, if directly connected thereto.
In addition to the plurality of devices 141, 141', the device level 104 may include one or more gateways 140 (computing nodes), and the device 141' may be connected to the one or more gateways 140. The gateway 140 at the device level may provide a device, system, or 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 gateway 140 at the device level 104 may be connected directly to the global cloud, or 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 appreciated that although shown only in the device-level gateway 140, any level gateway may send data (transfer data) to multiple gateways (two, three, four, etc.) at higher levels. For example, one gateway may send data to the gateway representing 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 plant-level tunnel services 130'-1, 130"-1, 130'" -1 and a target service 141'-2 (e.g., a remote desktop service) 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 therebetween.
In fig. 1, devices 141, 141' may represent things that the industrial internet of things includes. The thing may be a different device, machine, apparatus, equipment, system, subsystem, process, etc. Some examples of things include pumps, motors, valves, industrial PCs, production lines, and control loops. There is no limitation on the composition of things. It is sufficient that the thing comprises means for performing one or more different measurements and/or one or more operations on the environment, and means for sending information at least to one or more gateways, for example. Further, the things themselves may include things that are analyzed as a composite thing. The implementation of the industrial internet of things, the data collected therefrom, and the means for information exchange are not significant to the present invention and therefore will not be described in detail herein. It will be apparent to those 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, mobile device, laptop, personal computer, server, edge computing device, virtual machine, or cloud function, to name a few examples. Naturally, the gateway may comprise a data store and/or one or more user interfaces.
To protect the IIoT system, in the illustrated embodiment, one or more Firewalls (FWs) may be present between the gateways, and the gateways may be configured to communicate with each other using a secure communication protocol. Thus, secure communication between different gateways may be achieved by providing end-to-end security through an intermediate system (with corresponding middleware). In this embodiment, data traffic from the gateway to the northbound node (e.g., a node at a higher level) may use an outbound port, such as port 80 or 443 in the gateway. The firewall may be configured to not allow connection to a southbound node, such as a gateway at a lower level, as depicted by the direction indicated by the arrow end of the connection in fig. 1. More precisely, gateway 140 and device 141 at device level 104 may be connected to gateways at higher levels via firewalls 154, 154', 154", but gateway 140 and device 141 may not be directly connected to the cloud, and thus they may not have a direct IP connection to user device 114. Further, the gateways 130, 130', 130", 130'" at the factory level may in turn be connected to the gateway at a higher level via firewalls 153, 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 a 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 bi-directional, such that when a node establishes an outbound connection to its northbound neighbors (e.g., nodes at higher levels) 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 use the pre-established active connection to establish a reverse connection from cloud gateway 113 to device 141 in order to enable bi-directional 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 data may be transferred to (e.g., from a southbound node to a northbound node or to other directions). The various connections between the various nodes may together form a chain of point-to-point connections (e.g., secure web socket connections) with trust of certificate-based mutual authentication between the nodes in the system, and cloud-level gateway 113 may be configured to have bi-directional communication with trust of one or more target devices 141, 141' via the chain. In particular, point-to-point connection herein means a connection between a pair of neighboring 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. In addition, the root certificate may be used to create a certificate for the target device 141, 141', and the user device 114 may be configured as a default trust root certificate. Thus, the user device may also automatically trust the target device certificate. The TLS protocol and 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 other firewalls may exist in addition to the one depicted in fig. 1.
Although not shown in fig. 1, the connection 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 will not be 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 the multiple devices. Furthermore, 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 gateway, where they may be pushed down from the cloud in the hierarchy and thus may be applied by all gateways (compute nodes). However, the equipment models in each gateway need not be identical, and the data flow rules may provide a tool to effect transitions between equipment models and transitions between different data types.
In summary, FIG. 1 illustrates an IIoT platform architecture that can provide connectivity and through a level of deep data access to get the required detailed information regardless of the actual data store. Furthermore, the IIoT platform architecture may provide a means for integrated management and control of basic resources from the device level 104 up to the global cloud 101', including security and devices including the IIoT platform. The main information flow directions are from global cloud level to lower level (top to bottom) and from device level to higher level (bottom to top). It should be appreciated that, for example, the actual system topology, integration with external systems, etc. may vary depending on industry requirements and products.
Fig. 2 illustrates a software-enabled function 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.
In step 202, the tunnel service of the first gateway then sends a redirect request to the tunnel client application for Identity and Access Management (IAM) service for authenticating the user and for obtaining a SAML access token for the user. It should be appreciated 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 the event of success (step 204: yes), the IAM service sends the 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 the event that the verification is unsuccessful (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 authenticated (step 209: yes), then in step 211 the tunnel client application then sends a query to the tunnel service of the first gateway for a list of target services (e.g., remote desktop services) in target devices at a lower level (e.g., device level) that are assigned as roles available for association with users 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 of the tunnel client application (or, for example, in a command line interface).
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 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), such as a TCP/IP tunnel encrypted with TLS. The tunnel is relayed via a chain of trusted certificate-based point-to-point connections (e.g., secure network socket connections) through an intermediate gateway between the user device and the target's tunnel service (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 so individually encrypted, the end-to-end tunnel itself is individually encrypted using TLS to effect end-to-end encryption. It should be noted that the tunnel is not established by any gateway alone, as each of the intermediate gateways in the chain/path may also include its own tunnel service, which 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 the chain/path may include functionality that may be coordinated to work together when 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, in step 214, the other end-to-end tunnel is opened between the target's tunnel service and the IAM service by relaying the tunnel via a chain of trusted certificate-based point-to-point connections, e.g. TCP/IP tunnels encrypted with TLS, which chain passes through an intermediate gateway between the target's tunnel service and the IAM service. The tunnel may also be established by all tunnel services working together in the chain/path, as in step 212. The targeted tunnel service then sends the user's access token to the IAM service via the tunnel for authentication.
In the event that the verification is unsuccessful (step 215: no), then an appropriate error message is displayed to the user at step 216, and the user is denied access to the target service. If the access token is successfully authenticated (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 the event that the authorization is unsuccessful (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), then in step 220 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 the tunnel between the tunnel service of the target and the user device. The user may then communicate with a target service (e.g., a remote desktop service) in the target device, e.g., 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, such as by requiring a username and password, or by re-authenticating 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 access token of the user from the user device alone. If the target service receives a connection request that includes the user's access token, the target service may then send the access token to the IAM service to verify the access token (a third time) before granting the user's access to the target service.
The steps and related functions described above in fig. 2 are not in absolute time 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 steps, and other information may be sent. 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 have been included in the first connection request of step 201, in which case the process would proceed directly to step 208.
A particular problem with conventional remote access methods is user authentication, as user authentication in legacy systems typically requires that the user know the specific access credentials of each individual device in order to connect to it. For service technicians, it is time consuming to manage all individual credentials of potentially thousands of industrial devices, and for device management, it is time consuming to manage all user accounts of potentially hundreds of service technicians, especially if the user roles are changing. Because of this complexity, such legacy authentication systems may result in compromised corporate security policies. For example, in legacy systems, an ill-minded pre-employee can still use his/her user credentials to damage or harm 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 tunneling 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 device-specific usernames and passwords with authentication using federated identities and authorization with RBACs.
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 network of user devices. Another benefit of some embodiments may be that they may not require as complex a setup configuration to establish a remote connection as conventional remote access methods may do. Further, some embodiments may enable remote access through multiple network-level hierarchical tunnels by using only existing (legacy) network infrastructure, such that, for example, no separate remote access gateway needs to be installed to 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 targeted 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 as well. The tunnel may also be automatically disconnected when the user's access token expires.
Fig. 3 illustrates software-enabled functions of an embodiment of the present invention from the perspective of a user device including a tunnel client application. In step 301, a tunnel client application detects, via a graphical user interface (or command line interface), a user input requesting to connect to a tunnel service running on a first gateway (or on an enterprise-level gateway) in a global cloud. The tunnel client application then sends a corresponding connection request to the tunnel service running on the first gateway in step 302.
In step 303, the tunnel client application receives a redirect request for an Identity and Access Management (IAM) service from a 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, for example by using the user specific federated identity in a web browser window.
In the event that 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 or the user may be required to retry the login. In the event of success (step 306: yes), the tunnel client application receives a user-specific access token for the user 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 the connection is unsuccessful (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), then the tunnel client application then sends a query to the tunnel service of the first gateway to obtain a list of target services (e.g., remote desktop services) assigned to roles available for association with users in the organization/enterprise in step 312. 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 user input requesting connection to the target service specified by the user in step 314, and 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 315. In step 316, the tunnel client application receives the tunnel established information and in step 317, the tunnel client application sends a connection request containing the user's access token to the target's tunnel service (i.e., the tunnel service that controls access to the selected target service).
The tunnel client application then receives a reply from the targeted tunnel service as to whether the connection was successful, step 318. In the event that the connection is unsuccessful (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 in order to communicate with the target service in step 320.
The steps and related functions described above in fig. 3 are not in absolute time 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 steps, and other information may be sent. Some or a portion of the steps may also be omitted or replaced by a corresponding step or portion of the steps.
FIG. 4 shows the basic functions of an embodiment of the present invention in the form of a simplified 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. Device gateway 405 is a gateway that directly connects to one or more target devices that include 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 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 is a trusted certificate-based connection, such as a secure network socket connection, 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 in the intermediate gateway (e.g., ports 80 or 443).
In point 410, a connection request is sent from the user device to the first gateway. In point 411, the first gateway does not detect the access token in the connection request and sends a redirection request to the IAM service to the user device 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, for example, his/her federated identity (i.e. user name and password). After successful login, the IAM service sends a user-specific access token to the user device in point 414.
The user device then sends a second connection request containing the user's access token to the first gateway in point 415. Then, at point 416, the first gateway sends the user's access token to the IAM service for verification. After successful authentication, the IAM service sends a reply to the first gateway stating that the authentication was successful in point 417. Then, in point 418, the first gateway allows the connection and sends a reply to the user equipment stating that the connection request was successful.
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 users 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, such as a TCP/IP tunnel encrypted with TLS, between the user device and the device gateway. The tunnel relays via a chain of trusted point-to-point connections (e.g., secure network 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 so individually encrypted, the end-to-end tunnel itself is individually encrypted using TLS to effect end-to-end encryption.
In point 423, the user device sends (via the tunnel) a connection request containing the user's access token to the device gateway for requesting access to the target service. Before granting the user device access to the target service, a second encrypted end-to-end tunnel, such as a TCP/IP tunnel encrypted with TLS, is opened between the device gateway and the IAM service by relaying the tunnel through an intermediate gateway and a first gateway between the device gateway and the IAM service in point 424.
The device gateway then sends the user's access token to the IAM service for authentication via the second tunnel in point 425. After verification is successful, the IAM service sends a reply to the device gateway stating that verification was successful at 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 device may communicate with the target service using the first tunnel.
Fig. 5 is a simplified block diagram showing some elements of a device (apparatus) 500, the device 500 being, for example, a user device, a device-level device, a gateway for IIoT, or a corresponding computing device. In the example shown, the device comprises: one or more Interfaces (IF) 501 for receiving and/or retrieving information from and/or sending information to other devices and possibly to users; a processor 502; algorithm 503, which corresponds 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 implementing the algorithms for the functions. Memory 504 may also be used to store other possible information such as configuration, lists, data flow rules, equipment models, telemetry data, firewall data, etc.
In other words, a device (means) 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 corresponding device functions described with the embodiments/examples/implementations, and which may be configured to perform functions from different embodiments/examples/implementations.
The apparatus/device may include a processor, controller, control unit, microcontroller, etc. connected to various interfaces of the memory and device. The processor may be a central processing unit or the processor may be an additional processor of operations. 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, such as a single-chip computer element or, for example, a chipset, 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-described units/sub-units and/or algorithms may include 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 and/or will be programmed by the downloading of 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, including program instructions executable by one or more processors/computers, which when loaded into a device constitute one or more of the functions described above in connection with fig. 1-4. Programs, also referred to as program products, including software routines, program fragments, applets, and macros, that make up a "program library" may be stored in any medium and downloaded into the device. In other words, each or some or one of the above units/sub-units and/or algorithms may be elements comprising one or more arithmetic logic units, a plurality of special registers and control circuitry.
Further, devices/means configured to provide a gateway for IIoT or devices 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 store 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 either internal to the processor/device or external to the processor/device, in which case it may be communicatively coupled to the processor/device via various means as is known in the art. Examples of external memory include removable memory that is removably connected to the device, 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 the example/embodiments.
It will be obvious to a person skilled in the art that as 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 for establishing a secure remote connection between a user device and a target device, the method comprising:
receiving, by a first gateway, a first connection request from the user device, the first connection request including an access token;
verifying the access token in an 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 having no 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 the access token;
establishing a second tunnel between the target device and the identity and access management service via a chain of trusted certificate-based point-to-point connections, the chain passing through the 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 having no direct internet protocol connection to the identity and access management service without the second tunnel; and
the access token is verified in the identity and access management service via the second tunnel.
2. The computer-implemented method of claim 1, wherein an x.509 public key infrastructure is used to create a chain of the trusted certificate-based point-to-point connections, and a root certificate is used to create a certificate for the target device, wherein the user device is configured to trust the root certificate by default.
3. The computer-implemented method of claim 1 or 2, further comprising:
Receiving, by the first gateway, a token-less connection request from the user device;
redirecting, by the first gateway, the user device to the identity and access management service;
authenticating a user of the user device in the identity and access management service; and
upon successful authentication, receiving, by the user device, the access token from the identity and access management service;
wherein the first connection request is received by the first gateway from the user device after authenticating the user of the user device in the identity and access management service.
4. The computer-implemented method of claim 1, further comprising:
verifying, by the target device, that the user is authorized to access a target service, the target service being included in the target device or in another device directly connected to the target device; and
upon successful authorization, the user device is granted access to communicate with the target service via the first tunnel.
5. The computer-implemented method of claim 4, further comprising:
receiving, by the target service, a third connection request from the user device via the first tunnel, the third connection request including the access token; and
The access token is verified in the identity and access management service via the second tunnel.
6. The computer-implemented method of claim 4, wherein the authorization of the user is based at least on one or more roles associated with the user.
7. A computer readable medium comprising program instructions that when run on a computing device cause the computing device to at least:
receiving a first connection request from a user equipment, the first connection request comprising an access token;
verifying the access token in an identity and access management service;
after successful authentication, establishing a first tunnel between the user equipment and a 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 computing device to the target device, the reverse connection being based on a pre-established connection from the target device to the computing device 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 having no direct internet protocol connection to the user equipment without the first tunnel;
Establishing a second tunnel between the target device and the identity and access management service via a chain of trusted certificate-based point-to-point connections, the chain passing through the one or more intermediate gateways, wherein the second tunnel is established by using a reverse connection from the computing device to the target device, the target device having no direct internet protocol connection to the identity and access management service without the second tunnel; and
the access token is verified in the identity and access management service via the second tunnel.
8. An apparatus for establishing a secure remote connection between a user device and a target device, the apparatus comprising: at least one processor and at least one 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, cause the apparatus to:
receiving a first connection request from the user equipment, the first connection request including an access token;
verifying the access token in an 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 appliance to the target device, the reverse connection being based on a pre-established connection from the target device to the appliance 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 having no direct internet protocol connection to the user device without the first tunnel;
establishing a second tunnel between the target device and the identity and access management service via a chain of trusted certificate-based point-to-point connections, the chain passing through the one or more intermediate gateways, wherein the second tunnel is established by using a reverse connection from the appliance to the target device, the target device having no direct internet protocol connection to the identity and access management service without the second tunnel; and
The access token is verified in the identity and access management service via the second tunnel.
9. The apparatus of claim 8, wherein the apparatus is further caused to:
receiving a token-free connection request from the user equipment;
redirecting the user equipment to the identity and access management service; and
authenticating a user of the user device in the identity and access management service;
wherein the first connection request is received from the user device after authenticating the user of the user device in the identity and access management service.
10. A system comprising at least a user device, a target device, and three or more gateways;
wherein one of the three or more gateways is a first gateway, the first gateway (113) being configured to receive a first connection request from the user equipment, the first connection request comprising an access token;
wherein one gateway of the three or more gateways is a device gateway directly connected to or included in the target device;
wherein at least one gateway of the three or more gateways is an intermediate gateway between the first gateway and the device gateway;
Wherein the first gateway is further configured to: having trusted two-way communication with the target device via a chain of trusted certificate-based point-to-point connections 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 the intermediate gateway;
wherein the first gateway is further configured to send the access token to an identity and access management service for verifying the access token;
wherein the three or more gateways are configured to: establishing a first tunnel between the target device and the user device using a reverse connection from the first gateway to the target device, the target device having no direct internet protocol connection to the user device without the first tunnel;
wherein the target device is further configured to receive a second connection request from the user device via the first tunnel, the second connection request comprising the access token;
wherein the three or more gateways are further configured to: establishing a second tunnel between the identity and access management service and the target device using a reverse connection from the first gateway to the target device via the chain of trusted certificate-based point-to-point connections, the target device having no direct internet protocol connection to the identity and access management service without the second tunnel;
Wherein the target device is further configured to send the access token to the identity and access management service via the second tunnel for verifying the access token.
11. The system of claim 10, wherein the target device is further configured to: verifying that a user associated with the access token is authorized to access a target service; and upon successful authorization, granting access to the user device to communicate with the target service via the first tunnel.
12. The system of claim 11, wherein the target service is configured to: receiving a third connection request from the user equipment via the first tunnel, the third connection request including the access token; and sending the access token to the identity and access management service via the second tunnel for verifying the access token.
13. The system of claim 11, wherein the authorization of the user is based at least on one or more roles associated with the user.
14. The system of claim 10 or 11, wherein the first gateway and the identity and access management service are included in a global cloud, and at least one intermediate gateway is connected to the global cloud.
15. The system of claim 10 or 11, 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 CN113632437A (en) | 2021-11-09 |
| CN113632437B true 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) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113890767B (en) * | 2021-11-12 | 2023-07-11 | 中国联合网络通信集团有限公司 | Network access method, device, equipment and storage medium |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2683510A1 (en) * | 2007-04-25 | 2008-11-06 | Qualcomm Incorporated | Route protocol |
| US9298935B1 (en) * | 2013-09-20 | 2016-03-29 | Piyush Kumar | Distributed privacy framework system and method of implementation |
| WO2017176398A1 (en) * | 2016-04-06 | 2017-10-12 | Qualcomm Incorporated | Network verification of wearable devices |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FI109254B (en) * | 1998-04-29 | 2002-06-14 | Ericsson Telefon Ab L M | Method, system and device for verification |
| US9049629B2 (en) * | 2007-06-18 | 2015-06-02 | Qualcomm Incorporated | Method and apparatus for fast inter-system handover |
| US8756660B2 (en) * | 2008-04-17 | 2014-06-17 | Microsoft Corporation | Enabling two-factor authentication for terminal services |
| EP2660667B1 (en) * | 2012-05-04 | 2021-11-10 | Rockwell Automation Technologies, Inc. | Cloud gateway for industrial automation information and control systems |
| US10069827B2 (en) * | 2012-10-31 | 2018-09-04 | International Business Machines Corporation | Extending authentication and authorization capabilities of an application without code changes |
| WO2015103338A1 (en) * | 2013-12-31 | 2015-07-09 | 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 |
| US9961062B2 (en) * | 2015-07-21 | 2018-05-01 | Sap Se | Centralized authentication server for providing cross-domain resources via a rest-based tunnel |
| US10257078B2 (en) * | 2016-04-01 | 2019-04-09 | Qualcomm Incorporated | Interworking with legacy radio access technologies for connectivity to next generation core network |
| 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 |
-
2020
- 2020-03-27 CN CN202080025219.0A patent/CN113632437B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2683510A1 (en) * | 2007-04-25 | 2008-11-06 | Qualcomm Incorporated | Route protocol |
| US9298935B1 (en) * | 2013-09-20 | 2016-03-29 | Piyush Kumar | Distributed privacy framework system and method of implementation |
| WO2017176398A1 (en) * | 2016-04-06 | 2017-10-12 | Qualcomm Incorporated | Network verification of wearable devices |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113632437A (en) | 2021-11-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109901533B (en) | Method and apparatus for use in a process control system | |
| JP7383368B2 (en) | Methods, systems for securely transferring communications from a process plant to another system | |
| US10257163B2 (en) | Secured process control communications | |
| US10749692B2 (en) | Automated certificate enrollment for devices in industrial control systems or other systems | |
| US10270745B2 (en) | Securely transporting data across a data diode for secured process control communications | |
| US10855448B2 (en) | Apparatus and method for using blockchains to establish trust between nodes in industrial control systems or other systems | |
| JP6656157B2 (en) | Network connection automation | |
| Tsuchiya et al. | Software defined networking firewall for industry 4.0 manufacturing systems | |
| EP3254415B1 (en) | Multi-tunneling virtual network adapter | |
| EP3738029B1 (en) | Method and system for managing sub-tenants in a cloud computing environment | |
| EP3949318B1 (en) | Secure remote connections in industrial internet of things | |
| US11405373B2 (en) | Blockchain-based secured multicast communications | |
| US11575571B2 (en) | Centralized security event generation policy | |
| US20170222977A1 (en) | Configuring network security based on device management characteristics | |
| EP3667526B1 (en) | Rapid file authentication on automation devices | |
| CN113632437B (en) | Secure remote connection in industrial Internet of things | |
| US9940116B2 (en) | System for performing remote services for a technical installation | |
| JP2009508213A (en) | Providing consistent application-compatible firewall traversal | |
| Suciu et al. | IoT platform for personal data protection | |
| US20220103527A1 (en) | Cloud-based explicit proxy with private access feature set | |
| Kumari et al. | Internet of Things (IoT): Concepts, Protocols, and Applications | |
| GB2581473A (en) | Electronic device configuration mechanism | |
| Siriwardena et al. | Basic/Digest Authentication | |
| Siriwardena et al. | HTTP Basic/Digest Authentication | |
| CHENARU | GATEWAY FOR SECURE IIoT INTEGRATION IN INDUSTRIAL CONTROL APPLICATIONS |
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 |