What Makes a Secure IoT Gateway Architecture?
With the advent of Industrie 4.0 and Industrial IoT, there has been increasing interest in connecting plant systems to cloud services. Companies seeking to gain insights into their processes can run analytics on cloud-based IoT platforms and use the results to improve performance. One popular way to make the connection from their equipment to the cloud has been to use OPC UA for in-plant data communications, and an MQTT gateway to send their data to the cloud. While this combination provides some desirable security features, it may not meet everyone’s needs. To explain why, let’s look first at a typical IoT gateway scenario, and then at an enhanced one that substantially improves plant security.
Typical Scenario
The typical IoT gateway combines two types of data communications: in-plant and plant-to-cloud. OPC UA is often recommended for secure in-plant communications for Industrie 4.0 and Industrial IoT. That’s because OPC UA offers multilayer security, including authentication and authorization at the application layer, as well as encryption and data integrity through the use of certificates at the transport layer. But for out-of-plant connections OPC UA is not secure because it requires opening a firewall port to allow a client to connect into the plant.
For plant-to-cloud connections, MQTT is often used. MQTT is a useful protocol for an IoT gateway because the popular cloud services like Microsoft Azure, Google Cloud, and AWS IoT Core support it. With MQTT you can make an outbound connection from the plant to the cloud service without opening any inbound firewall ports. This is essential for plant security. Thus, a software IoT gateway like Skkynet’s DataHub IoT Gateway can offer secure connectivity within the plant through its OPC UA interface, and a secure outbound connection to a cloud service via MQTT.
* Arrows illustrate initial connection path; all connections enable bi-directional data
Any IoT gateway software should be fully compatible with and support the OPC UA security features. And, in addition to MQTT’s secure outbound connection, it should support some kind of secure transport layer, such as SSL certificate-based security. With this combination in place, you can expect a reasonably secure data path from device to cloud.
However, there is one drawback. The typical IoT gateway that sends OPC UA data to the cloud needs a direct connection to the Internet. If a company’s security policy does not allow a direct Internet connection into the plant, then something more is needed.
Daisy Chain Connections
For more secure IoT communication, many companies prefer to use an isolated computer running outside the plant network, often referred to as a DMZ (Demilitarized Zone). Or, a company might want to send the data first to the IT department to access parts of the data stream before sending it along to the cloud. In fact, highly secure production systems normally do not have a direct connection to the Internet, and so are obliged to direct traffic through IT or a DMZ. Both use cases require a multi-hop architecture, also known as a “daisy chain.” In a robust daisy chain connection, each hop must reliably retransmit all of the incoming data, while also informing downstream clients of any failures in the network connections anywhere along the chain. Unfortunately, neither OPC UA nor MQTT were designed for this task.
The OPC UA protocol assumes that a client will be connected directly to a server, and that the server is the primary source of information. In a daisy chain, hops along the chain must be both clients and servers, so each hop must reconstruct the original server’s data model and behaviour. The OPC UA protocol is simply too complex to do this. In addition, the OPC UA protocol requires the client to connect to the server, meaning that each hop in the chain must open itself up to incoming connections, which is exactly the behaviour the system is trying to avoid.
MQTT can be daisy-chained with specially designed brokers, but it requires each node in the chain to be aware that it is part of the chain, and to be individually configured. All clients in the system need to be aware of all other data source clients, and must be configured to associate each data item with a source-dependent connection status message. In non-trivial systems this imposes an enormous maintenance cost. In addition, MQTT’s Quality of Service guarantees cannot propagate through the chain, so a multi-hop configuration would not be able to ensure that clients have the most recent values.
Enhanced Scenario
What is needed is a new, enhanced, scenario―one that can mirror the full data set at each node, and provide access to that data both to qualified clients, as well as the next node in the chain. This, for example, would give the IT department full access to the data, even as it is being passed along to the cloud service.
This enhanced scenario can be implemented by using a middleware product like the DataHub, installed at each node. The DataHub is capable of tunnelling the data between an in-plant node and a DMZ or IT server without opening any inbound firewall ports on the plant. A second DataHub, installed on the DMZ or IT server can then pass the data along to the MQTT service.
* Arrows illustrate initial connection path; all connections enable bi-directional data
The DataHub-to-DataHub connection uses the DataHub Transfer Protocol (DHTP), which sends and receives data in real time using TCP across a LAN, WAN, or the Internet. The OPC UA connection to the DataHub at the plant is a single hop. And the MQTT connection from the DataHub to the cloud service is also a single hop. DHTP handles the daisy-chain connections, mirroring the full data set and connection status at each node. The DataHub allows access to that data by qualified clients, as well as passing it along to the next node in the chain, maintaining consistency of the data. The DHTP Quality of Service guarantee ensures that any client or intermediate point in the chain will be consistent with the original source, even if some events must be dropped to accommodate limited bandwidth. If a network connection is lost, DataHub will automatically update data qualities for all related data points to ensure that every client in the chain is immediately aware of that connection loss.
The upshot is that there is a proven way to configure an MQTT gateway connection securely through a DMZ, the IT department, or another Internet node. Most IoT gateway products are not suited to the task, and can offer only the typical OPC UA to MQTT scenario. That may be fine for non-critical systems, but industrial applications require more. For those that need to secure their plant using a DMZ, or who want to send their data to the IT department before passing it to the cloud, DataHub middleware from Skkynet provides a secure and robust solution.
