Thanks for your reply Nathan. I’ve been looking at this from the point of view of providing customers with remote support to cut down on travelling. I’ll summarise what I’ve found in case it helps others or someone can correct a misapprehension.
Connecting over the web to a FactoryPMI server generally requires a port to be opened in the incoming firewall and traffic on that port forwarded to the FactoryPMI server. Connecting this way in theory exposes data on the Internet and relies on one level of security (a username and password) to keep intruders out of the system. (There is also the possibility of flaws in the FactoryPMI code being exploited, but that is well outside my area of knowledge.)
Using SSL to connect to FactoryPMI reduces your exposure by encrypting data travelling across the Internet. It also can be used to confirm you are indeed connecting to the FactoryPMI server before you enter your username and password, as long as you purchase an SSL certificate from a well-known certificate authority - without this, you will get alarming security warnings about the certificate being invalid (due to being self-signed) when you try to connect.
This configuration will allow you to view your system and (if set up in the Gateway web page) alter FactoryPMI settings. It will not however give you access to the underlying server, and therefore to your database, FactorySQL or your OPC server. You can gain access to your database and FactorySQL by opening other ports in your firewall and forwarding them to the server(s), but there is no easy option to use SSL on those connections. I also don’t know of any easy way of accessing an OPC server remotely - I’ve had horrors with DCOM configuration, although these may be relieved by using the Matrikon OPC Tunneller.
If you need access beyond FactoryPMI on a machine therefore, it would appear necessary to consider implementing a VPN solution. This adds security both in the form of encryption and requirement for confirmation of identity through username/passwords or more advanced means such as security tokens etc.
There are at least 3 flavours of VPN:
-
PPTP - Microsoft specific, with a built-in client in most (all?) versions of windows. Their implementation had some security flaws earlier on, but these seem to have been fixed.
-
IPSec - standards based, but requires a 3rd party client to be installed and configured. Colleagues have had good results with the client from http://www.thegreenbow.com.
-
SSL - The OpenVPN project (http://www.openvpn.net) uses SSL for encryption independently of a web browser. This seems to offer a lot of advantages in terms of simplicity of configuration.
Well, that’s my tiny store of knowledge exhausted. If anyone else can comment or recount their own experiences I would be very interested to hear from them.