You've got a pretty good handle on it.
[quote="AlThePal"]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.[/quote]
There's a lot more to consider than the authentication method (username/password). The system generates a throw away key to encrypt traffic, incorporates datetime stamps, etc. At best case, this proves identities of each party (often requires certificates for that), prevents eavesdropping, "replay", and "man in the middle" attacks. Note - that we don't currently use certificates (PKI) to authenticate the client. The current FactoryPMI certificate only provides assurance to the client that the application that they are letting write to their hard drive (just in a temp cache path, not the whole volume) is genuine.
True statements. Providing access to the single port that the FactoryPMI Gateway web server runs on, 8080 by default or 443 for SSL, gives the interface to configure FactoryPMI, but not FactorySQL, your PLC (OPC source), or SQL database. In fact, a more solid enterprise architecture would place the FPMI machine in a DMZ, and the rest further buried in the network. Keep DCOM buried as deep as possible with something like a tunneler - it is impossible to secure on an open network.
[quote="AlThePal"]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.
[/quote]
Not necessarily - SQL databases and FactorySQL support remote connections over a single port - you would open these ports in your firewall. However, these fall under administrative functions and I would highly recommend requiring VPN access for remote configuration of these functions. This gives you better security and auditing options.
[quote="AlThePal"]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 .
-
SSL - The OpenVPN project 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.[/quote]
Good VPN summary. In the network infrastructure world there are many ways of skinning that cat. Many sites interconnect with permanent VPNs between routers and switches, which, in effect, are encrypted BGP tunnels.