In Megavatio Control we have very internalized this need from the beginning. Our system has been designed based on security so that it is very robust. In this post we will explain with which tools we implement these maximum safety standards.
We have several dedicated physical servers hired from a high level hosting provider. These servers are physically hosted in multiple locations. We also have several servers and equipment in our corporate locations.
Our servers have Linux-based operating systems, the most secure and versatile distributions, that allow us to create virtualized servers inside. So we have a Linux server (physical or virtual) for each client, service, application … For example one for MVScada, another for public webs, another for backups, another for ener.com.es, another for Green Energy Tracker …
The local servers, in addition, count in some cases, with hard disk encryption.
We have a bunch of IP addresses and domains that we can balance between all the machines.
In case of failure of one of the servers there is a backup of all the information in several locations, but also the service can be started in another location. This way protect us against equipment failures, data corruption and even denial of service attacks.
Communications between users and servers
All communications between users and facilities are done through the server. From your web interface. That is, users do not have direct access to field equipment. They are “shielded”.
Web communications are done using a Secure Hypertext Transfer Protocol (HTTPS), so the client’s browser verifies the certificate on our website and establishes a communication through an encrypted channel.
We try to avoid installing field equipment and thus make remote and direct readings from the server, but it is not always possible. When needed, we install Linux-based computers, although of different nature. These computers are secured like the servers.
In cases where automatic solutions are required we use Arduino or commercial industrial equipment. The communications between these and the bedside equipment (Minipc’s) are made using protocols based on Modbus and encrypted data.
When wireless communications are required we use ZigBee protocols that allow us to create mesh networks with the possibility of encryption. An example of mesh network is the one that we create in the Photovoltaic Plant of Carbonero el Mayor (Segovia) [Access to HMI with user and password “demo”]
The communication systems between the field devices and our servers allows to close the access of the facilities to the outside networks and even , eliminates the need of buying a Static IP address. This gives total security to the local installation. Communications with local devices are done through secure channels through our gateways.
Communications between computers and our servers
Communication between minipcs or MVScada field devices and the server is done directly through a virtual private network (VPN). That is, a direct tunnel with the server that prevents access to intruders.
Field devices are fully protected, all remote access is closed on the router. The installation minipc belongs to a VPN network. The communications with our servers are encrypted and protected within the tunnel. The Minipc only communicates with the server. Field devices only communicate with the Minipc. Users communicate with our servers via HTTPS.
Facilities are completely protected, the communications of their devices with the servers and those of the users with the server are secured as well. There are no other possibilities of communication.
When a user wants to access some services of the installation outside MVScada (such as video surveillance cameras or remote meter reading), if they wish, it can be done through the MVScada gateway of the VPN, entering the VPN tunnel from the server. Thus the communications will be protected and users will not change the way they work.
In the case of the network of Bidgate IOT equipment for Energibid is different since the devices, when they initiate their connection only communicate with our server in a unidirectional way, ie no direct connections are allowed to the equipment, this, which seems a disadvantage, is an advantage since it’s the client that initiates the connection and the server software that handles the responses with an event-driven programming. It’s a direct communication between computer and server, only the M2M operator as an intermediary without access to the rest of the internet.