Analytical Insights #4 - Secure Management of Data Acquisition from Cloud

Part 4 of Microsoft Most Valuable Professional Dave Shook, Fusion’s Chief Data Officer’s 9-part educational series discussing various topics for asset-intensive industrial companies who need analytical insights to improve operations. The fourth part of this series is the topic of Secure Management of Data Acquisition from the Cloud.

Read the video transcript below for your own convenience:

From the cloud or from a computer at some arbitrary location, possibly connecting by way of the internet, we want to be able to configure this data acquisition client to securely collect data from a historian, an alarm historian, or direct from a control system.

How do we do this? 

First of all, we remember that all of the communications are initiated outbound from the client to the relay point and then from the relay point up to the cloud. These are secured in transit, and both ends are authenticated against each other so that we know that this data acquisition client is talking to who it needs to and the IoT Hub knows who's talking to it.

The most convenient way for us to manage the data acquisition is to leverage that communication channel transmitting data. Microsoft has allowed us to do this using the IoT Hub Cloud To Device messaging, which we refer to in this context as our control plane. We will be sending control commands down. It is still an Outward Bound connection, but once that connection has been made, the IoT Hub can send information down to the data acquisition client, and then it will Implement them, and it'll add more tags or retrieve more history or stop acquiring data, whatever the command happens to be. 

That is nice and secure. But, we now need to worry about how a user can enter and act with that system, and we can know that they are who they are. First, we need this data acquisition management application in Azure – think of it as a website. This user needs to be able to talk to that, and that then sends commands to the IoT hub. The IoT Hub then sends the commands back down over the same channel using the control plane. 

How do we authenticate this user to ensure that the person making these commands is allowed to do so?

First of all, Microsoft gives us Uptake Fusion a lot of help here with the active directory and Azure active directory. That makes it possible for an active directory authenticated user to be mapped directly into Azure. Secondly, multi-factor authentication, which is where you have to respond to a text or an authentication application, makes it much less likely that a user can be spoofed by a malicious actor. 

These tools make it very unlikely that anyone other than authenticated users can do this, but we still need to have end-to-end security of the communication channel. That's where we get into things like a VPN, connecting this computer to the Azure endpoint. In fact, practically speaking, this whole system should be within a VPN anyway because it's a logical extension of the DMZ. A user can do things here that can directly affect the DMZ, and so this should be secured about as tightly as a DMZ is itself.

What we do at Fusion is use some network best practices with Azure to make it so that the user, or even go so far as to put a computer certificate so that the computer itself is authenticated. In that case, what we know is that it's that user. We know that it's that computer. We know there's no man in the middle. And therefore, it is valid and secure for us to allow that user to perform the administrative actions that they should be permitted to do, and then the communication through the IoT has a control plane, giving us secure communication down to the data acquisition client.