Groov EPIC 保证边缘计算的安全性: 系列1 (MQTT)

首页    简体中文    产品信息    Groov EPIC 保证边缘计算的安全性: 系列1 (MQTT)

groov EPIC Security Series Part 3: Device originating communications, or how and why MQTT rocks

Groov Epic安全系列一:设备始发通信,或MQTT如何以及为何发生变化

The story goes that a valve manufacturer wanted to have their networked smart valves certified for use in a nuclear reactor plant. The smart valve could report all sorts of critical data points to a database system and also be controlled by that SCADA system in the plant. But to get it certified for use, the smart valve had to undergo a rigorous security audit by the information technology (IT) department at the plant.

事情是这样的:阀门制造商希望将他们的网络智能阀门获得用于核反应堆工厂认证。 智能阀门可以将各种关键数据点报告给数据库系统,也可以由工厂中的SCADA系统控制。但为了使其获得认证,智能阀门必须经过工厂信息技术(IT)部门的严格安全审核。

After a week of tests, the IT guys gave up and said to the valve manufacturer, “Your smart valve is broken. We can’t communicate to it. There are no open ports at all. It can’t be working, because it won’t respond.”

The smart valve manufacturer simply replied, “Exactly.”

经过一周的测试,IT人员放弃并对阀门制造商说:你的智能阀门坏了。我们无法与之通信。它没有开放的端口。它不能工作,因为它不应答。”

智能阀门制造商简单地回答说:确实是。

Since there were no network ports open on the smart valve, there was no way to reach the valve over the network. But once the manufacturer explained, the IT guys approved the valve for use in the plant.

So, how did the smart valve manufacturer pass muster with IT? And how did the smart valve report its data and accept commands from the SCADA system without any open ports?

由于智能阀上没有打开网络端口,因此无法通过网络到达阀门。但是,一经制造商解释,IT人员就批准了该用于工厂的阀门。

那么,智能阀门制造商是如何通过IT评估的呢?智能阀门如何在没有任何开放端口的情况下报告其数据并接受来自SCADA系统的命令?

The trick is that every bit of data the valve communicated to other systems was device originated. That is to say, data communications originated from the smart valve (the client) and went through the valve’s device firewall and out to the designated service (the server, or database in this example).

 

Let’s quickly summarize our last blog on firewalls (if you haven't read it yet, be sure to check it out). Put simply, firewalls block all incoming connection requests. But firewalls typically permit outbound connections from services that originate from behind the firewall, and keep track of those connections to allow returning data to be passed back through to the originating service.

诀窍是阀门传递给其他系统的每一点数据都是设备发起的。也就是说,数据通信源自智能阀门(客户端)并通过阀门的设备防火墙并进入指定的服务(本例中的服务器或数据库)。

简而言之,防火墙会阻止所有传入的连接请求。 但是防火墙通常允许来自防火墙后面的服务的出站连接,并跟踪这些连接以允许返回的数据传递回原始服务。

 

If youre thinking that means our firewalled device can only send data and not receive data, keep reading. This is where a data communications method like MQTT comes in, and its pretty cool.

We have a great series of instructional videos on the topic of MQTT, including what it is, how it works, what role an MQTT broker plays, and more. So I wont repeat all of that here.

如果您认为这意味着我们的防火墙设备只能发送数据而不能接收数据,请继续阅读。这就是像MQTT这样的数据通信方法有用武之地。

我们有一系列关于MQTT主题的大量教学视频,包括它是什么,它是如何工作的,MQTT代理扮演什么角色等等。

Its enough to say that MQTT is a publish/subscribe protocol a supported device can use to publish real-time values to a central broker over an authenticated, encrypted, persistent connection. And while that connection is active, the device can subscribe to any new values or commands that the broker received from other devices or services.

MQTT是一种发布/订阅协议,受支持的设备可以使用该协议通过经过身份验证的加密持久连接将实时值发布到中央代理。当该连接处于活动状态时,设备可以订阅代理从其他设备或服务接收的任何新值或命令。

 

 

The way it works is that our MQTT-enabled device securely connects over the network to an MQTT broker using TLS encryption, along with a username and password to log into the broker.

Then, once the connection is established and active, the device issues a device-originating data packet that says, Im alive (state), here are my newly changed values (report-by-exception data), and please reply with any new messages for me (new commands or values).

它的工作方式是我们的MQTT设备,用登录代理的用户名和密码使用TLS加密通过网络安全地连接到MQTT Broker

然后,一旦连接建立并激活,设备就会发出一个设备发起的数据包,上面写着“我还激活(状态),这是新变换的值(异常报告数据)”,请回复给我的任何新消息(新命令或值)。“

The broker accepts the data packet and responds by sending our device any data it is subscribed to receive, which could include commands from other devices or services, over that same active connection. The broker also securely forwards our devices data to authenticated devices or services that subscribed to receive it over their active connections.

Meanwhile, the device continues sending a small 2-byte "heartbeat" at a scheduled interval, keeping the secure, encrypted network connection active and keeping the broker notified of its state.

Broker接受数据包并通过向我们的设备发送它订阅的任何数据来响应,该数据可以包括来自其他设备或服务的命令,通过相同的活动连接。 Broker还安全地将我们设备的数据转发给已通过其活动连接订阅的,经过身份验证的设备或服务。

同时,设备继续以预定的间隔发送一个小的2字节“心跳”,保持安全的加密网络连接处于活动状态,并通知Broker其状态。

 

Because the transmission of the heartbeat and new data originates from our device behind the firewall, the firewall allows return communication with any new commands or values from other devices and services. Thus with zero open ports on the firewall, our device can both report values and receive commands. It is two-way communications out and then back in on the same port, a port that is closed from the outside.

由于心跳和新数据的传输源自防火墙后面的设备,因此防火墙允许其与来自其他设备和服务的任何新命令或值进行返回通信。 因此,在防火墙上没有开放端口的情况下,我们的设备可以报告值并接收命令。 它是双向通信,然后返回同一个端口,一个对外部关闭的端口。

Of course, Opto 22's device isnt a smart valve; its the groov EPIC edge programmable industrial controller. groov EPIC is protected by its own device firewall, and the same principles apply. These outbound, device-originating MQTT communications can be transmitted from the EPIC on either network interface, and no firewall ports have to be opened to allow data flow.

Think about this for a moment. If there are no configured open ports on the groov EPICs firewall for a given interface (say, ETH1, the untrusted network), a bad actor running a port scan on your groov EPIC on ETH1 would not find a single port open to exploit.

当然,Opto 22的设备不是智能阀门; 它是groov EPIC边缘可编程工业控制器。 groov EPIC受其自身设备防火墙的保护,同样的原则也适用。 这些出站的,设备发起的MQTT通信可以在任一网络接口上从EPIC传输,并且不必打开防火墙端口以允许数据流。

对此稍加思考。 如果groov EPIC的防火墙上没有针对给定接口(例如,ETH1,不受信任的网络)配置的开放端口,则在ETH1上的groov EPIC上运行端口扫描的不良参与者将找不到可以利用的单个端口。

 

 

But because the MQTT data flow is device originating, and the firewall allows the data to go out, communications will occur. The EPICs firewall keeps track of the session status, and when the packets of data coming back from the broker arrive, they are allowed to pass back through.

Device-originating communications are a very powerful method of ensuring network security, again because theres no need to open ports on the device for data to flow.

但是因为MQTT数据流是设备发起的,并且防火墙允许数据外发,所以会发生通信。EPIC的防火墙跟踪会话状态,当从Broker返回的数据包到达时,允许它们通过。

设备发起通信是确保网络安全的一种非常强大的方法,因为不需要在设备上打开端口以便数据流动。

To be clear, MQTT is not the only option for this method; you can also use HTTP(S) GET and POST, since they also originate from the device. The message goes from the host and passes through the firewall. A packet of data is returned from the service and is allowed to return back through the firewall because it has the same session ID/header. But compared to HTTP(S) GET and POST, MQTT is generally much easier to implement and manage.

需要明确的是,MQTT不是此方法的唯一选择; 你也可以使用HTTPSGETPOST,因为它们也来自设备。 消息来自主机并通过防火墙。 从服务返回一个数据包,并允许它通过防火墙返回,因为它具有相同的会话ID /标头。 但与HTTPSGETPOST相比,MQTT通常更容易实现和管理。

Youre in control

Keep in mind that you are in control of the device firewall in the groov EPIC. You can open ports for services or you can close them. If you choose to use device-originating communications exclusively, you can configure your groov EPIC to have no firewall ports open at all.

一切尽在掌握

groov EPIC中的设备防火墙可控制。您可以打开服务端口,也可以关闭它们。 如果您选择仅使用设备发起的通信,则可以将groov EPIC配置为根本不打开防火墙端口。

And then smile as your IT department says, Your EPIC is broken; it wont respond to our port tests.

One point to make: as part of best practices, all outbound communications should be encrypted with Transport Layer Security, or TLS, even if they're not MQTT traffic. Otherwise, your API keys, usernames, passwords, and data could be susceptible to man-in-the-middle attacks, where a bad actor can view and intercept data on the wire. You dont want that. So use encryption on all outbound traffic. (Look for a future blog post about user authentication, encryption, and certificates.)

需要说明的一点是:作为最佳实践的一部分,所有出站通信都应使用传输层安全性或TLS进行加密,即使它们不是MQTT流量。 否则,您的API密钥,用户名,密码和数据可能会受到“中间人”攻击的影响,不良行为者可以在线上查看和拦截数据。 你不希望这样。 因此,对所有出站流量使用加密。

 

The other major security advantage of this architecture is that all device usernames and passwords (or accounts) are stored in the broker. That means all attempts to connect to the broker are managed at the broker through these device accounts (Access Control Lists, or ACLs). This dramatically simplifies the security management of the MQTT architecture, because theres just one place to manage who or what gets access to your data.

In closing, even if your device, application, or machine is not headed for a nuclear power plant, you should strongly consider the benefits of using device-originating communication methodslike MQTTfor all your device data communication needs, whether in your plant or from far-flung assets, wherever they may be.

此体系结构的另一个主要安全优势是所有设备用户名和密码(或帐户)都存储在Broker中。这意味着所有连接到代理的尝试都通过这些设备帐户(访问控制列表或ACL)在Broker上进行管理。这极大地简化了MQTT体系结构的安全管理,因为只有一个地方可以管理访问您数据的人员或内容。

最后,即使您的设备,应用程序或机器没有用于核电站,您也应该强烈考虑使用设备原始通信方法(如MQTT)的好处,以满足您的所有设备数据通信需求,无论是在您的工厂中或者来自偏远的资产,无论它们在哪里。

2019年6月26日 07:51
浏览量:0
收藏
本网站由阿里云提供云计算及安全服务