From everyone’s responses, it sounds like the best way is to use a VPN for user connection to the Ignition system.
What about this scenario?
There is a front end server with just Perspective that can be accessed from the public internet (just like any other website). It has access to the database that we will use across all our servers. This front end server has the remote tag provider reading the tag values from the backend server but is set to read only, just like @PGriffith suggested.
Now when a tag write needs to happen from the front end gateway, it writes to a database table. Then the back end server is constantly listening to this database table. When there’s a new record, perform that tag write. So the front end server does not have direct write access.
Now is this more secure than the previous suggestion? Is this the best possible solution to get some sort of write access from the front end server which is accessible via the public internet?
If you are going to write at all, you may as well use the tag provider. Consider using two–one read-only for most items, and the other read-write but only containing the items those users need.
Would it help if there was a load balancer in front? I know the load balancer is to redirect traffic based on some set of reasons to multiple servers but can it help with security? Can it help prevent unwanted attacks and tag writes from something other than an Ignition HMI?
What happens when an adversary finds a SQL injection vulnerability or some other sort of vulnerability and attacks your central databases to vandalise or control plant?
What do you actually need the users to be able to control remotely? Are they filling out a form saying that they visited a site and checked that the toilets are clean or are you trying to give them access to control switchgear and pumps?
I guess I must be confused as to why @John assumes a VPN Solution won’t work.
This is exactly what I do. My company is in Oil & Gas and we have hundreds of very remote locations that the “Office” people can log into and take all kinds of reports, then we have “Production Managers” that can log in and they can turn pumps on/off, make adjustments to the VFD’s, set new alarm setpoints, adjust PID function, and since I am the administrator I can actually reprogram any device that is connected to our VPN network, this includes IP Camera, Modem, Router, HMI, Gateways, Etc… All this is through our Verizon Vpn and then my adding all the necessary IP and PORT redirects through are special VPN Router.
Been using this setup for almost 6 years and have never had any problems! Works FLAWLESSLY!!
How does someone do this, lets say from their house? Does this person connect to their home internet and then use some sort of VPN software to connect to the Ignition system?
That’s what I’m trying to get away from, is to not have anyone need software and credentials to keep up with. Sometimes it may be people, who will only had read access (controlled by HMI) and will only need to view for a week or 2 then they won’t need to view anymore. These people could be internal users or customers who are not direct employees.
If you have a Verizon or AT&T VPN network you won’t need any software!
You can connect to the VPN tunnel from any device that is connected to the internet through a special IP address that is not public accessible
I connect from all over the USA.
Think of it this way. Log into a special box (without the need of any software) and that box will keep everything secure and you allow who and what they can access just by programing the box.)
I had this battle when I was setting up our system as well.
What we decided to do was to run Ignition in AWS which we then connect to via an onsite VPN. This means it technically has a public IP however the AWS EC2 instance’s firewall only allows access via the VPN IP, essentially making it private. We then also have all of our local devices tunnel through a site-to-site VPN which allows for the local machines to connect to the cloud Ignition instance. So anyone on our local network (requires login credentials) or with VPN credentials is able to connect to the Ignition instance.
I had to learn quite the bit more networking to iron this one out.
To get the service setup and running it took a (1) time fee from Verison for $500.00 - Then we had to purchase a Router that was capable of implementing all of the VPN/Security protocols that needed to be put in place. This was about $800-$1000, now from that point on, it depends on the amount of bandwidth your "Edge of Network" device uses. Almost all of my "EON" are on the $18.00 dollar a month plan, however I do have a couple of larger "EON" setups that cost $25.00, The 10gig a month plan is $50.00 a month. We use MQTT as are remote communication protocol so this really heps to keep bandwidth usage down.
I collect 1000's of tags (refreshed-every 3 minutes, 24/7) from all across the US and I am still only using 10% of my purchased bandwidth.
One of the best features about this configuration is that I can program-debug-upload-download to any device on the Private Network just as if that device is on my bench. And I might be 1000's of miles from that unit.
I'm looking to expose Ignition server running on the edge to a public URL (subdomain), not sure if anyone has used Cloudflare tunnel but is looks like a good solution. Cloudflare will protect the edge endpoint while adding its own authenication to allow traffic to be forwarded to the edge device from the domain. Also it automatically makes the connect SSL even if the edge device doesn't support it.
I have tested this and it works exceptionally well for Perspective in a browser. I cannot get the Android app authenticated.Have not tried iOS or Workstation.
@deon.korb How did you setup the cloud flare routes? I am able to connect to the tunnel and I can visit the gateway page, I can launch the project, but before the login screen comes on up the app, it just hangs there. I am wondering if I have a port issue.
I do have one more layer to this. I am running ignition in a docker container. Outside port is 8089 and maps to 8088 on docker container. The app pulls up fine locally with no issue.
