The SQL Gateway functions support secure connections over TLS (Transport Layer Security) / SSL (Secure Socket Layer) between the SQL Gateway and MySQL databases or Microsoft SQL Server databases. If you configure these connections properly, the databases may be located outside your industrial network.
The communication between the controllers and the SQL Gateway is not protected and must only be performed inside your industrial network, isolated from other networks inside your company, and protected from the Internet.
NOTE: Schneider Electric adheres to industry best practices in the development and implementation of control systems. This includes a "Defense-in-Depth" approach to secure an Industrial Control System. This approach places the controllers behind one or more firewalls to restrict access to authorized personnel and protocols only.
|
|
|
UNAUTHENTICATED ACCESS AND SUBSEQUENT UNAUTHORIZED MACHINE OPERATION |
|
oEvaluate whether your environment or your machines are connected to your critical infrastructure and, if so, take appropriate steps in terms of prevention, based on Defense-in-Depth, before connecting the automation system to any network. oLimit the number of devices connected to a network to the minimum necessary. oIsolate your industrial network from other networks inside your company. oProtect any network against unintended access by using firewalls, VPN, or other, proven security measures. oMonitor activities within your systems. oPrevent subject devices from direct access or direct link by unauthorized parties or unauthenticated actions. oPrepare a recovery plan including backup of your system and process information. |
|
Failure to follow these instructions can result in death, serious injury, or equipment damage. |
The SQL Gateway uses a single TCP port through which the controllers send their SQL queries. Set up your network structure and configure your firewall so that this TCP port is accessible to the controllers, but not accessible from outside your industrial network.
With each SSL encrypted connection, SSL certificates are verified. This helps to ensure that the SSL client is connected to the intended SSL server and vice versa.
For SSL encryption, two different types of certificates are available:
oServer certificates:
Certificates for the SSL servers. They serve two purposes:
oProviding public and private keys to be used for encrypting data that is sent from the SSL client to the SSL server.
oProviding information that allows the client to verify that it is connected to the correct SSL server.
oClient certificates:
Certificates for the SSL clients. They are not needed for encrypting data but only for client authentication. The usage of client certificates is optional, but may be required by the server to verify whether the SSL client is allowed to connect to the SSL server.
You can create self-signed certificates or you can use certificates signed by a certificate authority (CA). A short description on how to create self-signed certificates is provided in the Configuring SSL Encrypted Connections chapter for each SQL database type.
Validation of the Server Certificates
It is a good practice that the SSL client validates the server certificate in order to make sure that it is connected to the intended server when a connection is established.
There are two different validation procedures that can be executed by the client:
oValidate Certificate: This procedure verifies whether the server certificate or one of its root certificates is a trusted certificate. This means that it is available in the Trusted Root Certification Authorities folder of the certificate store.
oVerify Name: This procedure verifies whether the subject name in the server certificate matches the name of the server in the TCP connection.
Managing Certificates in the Certificate Store
The certificate store is a Windows component for managing certificates.
|
Step |
Action |
Comment |
|---|---|---|
|
1 |
On a Windows PC, execute the command mmc. |
Result: The Microsoft management Console opens. |
|
2 |
Execute the command File > Add/Remove Snap-In.... |
– |
|
3 |
In the Add or Remove Snap-ins dialog box, select Certificates, and click the Add > button. |
– |
|
4 |
In the Certificates snap-in dialog box, select the option Computer account and click Next, then click Finish. |
– |
|
5 |
Close the Add or Remove Snap-ins dialog box by clicking OK. |
Result: The Microsoft management Console contains two relevant Certificates folders: oPersonal: Contains the server and client certificates. oTrusted Root Certification Authorities: Contains the trusted root certificates. |
To import a certificate, right-click the Personal or Trusted Root Certification Authorities folder, and execute the command All Tasks > Import.... Follow the instructions provided by the Certificate Import Wizard. Select the option Automatically select the certificate store based on the type of certificate.
|
Step |
Action |
|---|---|
|
1 |
Right-click the certificate in the certificate store, and execute the command All Tasks > Manage Private Keys. |
|
2 |
In the next dialog box, click the Add button. |
|
3 |
Select the option Object Types > Service Accounts. |
|
4 |
Click the button Locations, select the entry of your local PC, and click OK. |
|
5 |
Copy the name to the text box. |
|
Step |
Action |
|---|---|
|
1 |
Double-click a certificate. |
|
2 |
In the Details tab, select the Thumbprint entry, and copy its Value. |
