Embed Size (px)
Citation preview
SECURITY GUIDE | PUBLICDocument Version: 15.4.0 – 2020-05-15
Security Guide PCo 15.4
© 2
020
SAP
SE o
r an
SAP affi
liate
com
pany
. All r
ight
s re
serv
ed.
THE BEST RUN
Document History
Versions
Version Date Description
1.0 2020-05-15 Initial version for PCo 15.4 (SP00)
2 P U B L I CSecurity Guide PCo 15.4
Document History
SAP Plant Connectivity
Introduction
This document outlines the available options in the Microsoft Windows operating system that you use to implement the security policy that controls the access to SAP Plant Connectivity (PCo).
CautionThis guide does not replace the administration or operation guides that are available for productive operations.
NoteFor a complete list of SAP Security Notes, see https://support.sap.com/en/my-support/knowledge-base/security-notes-news.html .
Security Required by Plant Connectivity
With the increasing use of distributed systems and the Internet for managing business data, the demands on security are also on the rise. When using a distributed system, you need to be sure that your data and processes support your business needs without allowing unauthorized access to critical information. User errors, negligence, or attempted manipulation of your system should not result in loss of information or processing time. These demands on security apply likewise to SAP Plant Connectivity (PCo).
The following prerequisites apply to the correct operation of SAP Plant Connectivity:
● PCo can only be installed by a user with administrator privileges.● Agent instances cannot be created or deleted unless the user has administrator privileges.● Microsoft Windows users which are assigned to an agent instance are granted the Log on as a service
privilege.● If the PCo Management Console is started by a user without administrator privileges it is shown in display
mode only. The display mode allows read access to all configuration data and logs but does not allow configuration changes or starting and stopping of agents.
Security Guide PCo 15.4SAP Plant Connectivity P U B L I C 3
About this Document
The Security Guide provides an overview of the security-relevant information that applies to PCo.
Overview of the Main Sections
The Security Guide comprises the following main sections:
● Before You StartThis section contains information about why security is necessary, and how to use this document.
● Technical System LandscapeThis section provides an overview of the technical components and communication paths that are used by PCo.
● User Administration and AuthenticationThis section provides an overview of the following user administration and authentication aspects:○ Recommended tools to use for user management○ User types that are required by PCo
● AuthorizationsThis section provides information about the authorizations required to run PCo.
● Network and Communication SecurityThis section provides an overview of the communication paths used by PCo and the security mechanisms that apply. It also includes our recommendations for the network topology to restrict access at network level.
● Data Storage SecurityThis section provides an overview of any critical data that is used by PCo and the security mechanisms that apply.
● Dispensable Functions with Impacts on SecurityThis section provides an overview of the functions that have an impact on security, but which can be disabled or removed from the system if necessary.
4 P U B L I CSecurity Guide PCo 15.4About this Document
Before You Start
Important SAP Notes
For a list of additional security-relevant SAP Hot News and SAP Notes, see https://support.sap.com/en/my-support/knowledge-base/security-notes-news.html .
Additional Information
For more information about specific topics, see the Quick Links as shown in the table below.
Content Quick Links on SAP Support Portal or SDN
Security http://sdn.sap.com/irj/sdn/security
Related SAP Notes ● https://launchpad.support.sap.com/#/mynotes?tab=Search
● https://support.sap.com/en/my-support/knowledge-base/security-notes-news.html
Product Availability Matrix https://support.sap.com/en/release-upgrade-maintenance.html#section_1969201630
SAP NetWeaver http://sdn.sap.com/irj/sdn/netweaver
Security Guide PCo 15.4Before You Start P U B L I C 5
Technical System Landscape
For an overview of the Plant Connectivity system landscape, refer to the corresponding Master Guide in the SAP Service Marketplace.
Topic Guide / Tool Quick Link
Technical description of PCo Master Guide http://help.sap.com/pco#section2
https://help.sap.com/viewer/p/SAP_PLANT_CONNECTIVITY
Technical Landscape Design See applicable technical documents http://sdn.sap.com/irj/sdn/landscapedesign
Security See applicable security documents http://sdn.sap.com/irj/sdn/security
6 P U B L I CSecurity Guide PCo 15.4
Technical System Landscape
User Administration and Authentication
PCo does not have its own user management for using the software on-premise, but instead uses the standard Microsoft Windows domain user accounts.
Authentication for the Plant Connectivity Management Services is done using Basic Authentication, that is, the given user is authenticated using Microsoft Windows authentication. The same applies when Web server(s) are configured in the PCo agent instance(s) and Basic Authentication is set. Additionally you can set Client Certificate Authentication for PCo Web servers.
The information about the configuration of the Cloud Integration, including security settings, can be found in the Application Operations Guide under Cloud Integration.
NoteFor more information about Windows authentication, see https://docs.microsoft.com/en-us/windows-server/security/windows-authentication/windows-authentication-overview .
Security Guide PCo 15.4User Administration and Authentication P U B L I C 7
Authorizations
Authorization for Management Console
To launch the Plant Connectivity Management Console to perform configuration changes or to start and stop agents, you must have the corresponding administrator privileges. Administrator users can use PCo without limitations.
PCo does not provide built-in user management. It uses standard Microsoft Windows domain user accounts. It does not provide additional roles for controlling the user or group accounts specific to PCo on-premise functionality. For more information about user management and security audits, see https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts and https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/security-auditing-overview
.
NoteIn Windows 7 and higher the User Account Control (UAC) automatically detects that administrator privileges are required.
Users without administrator privileges can start the PCo Management Console in display mode only. They have read-only access to configuration details and logs. They are also allowed to export the configuration; however, the exported XML file will not contain password information.
If required, you can run the Management Console in administrator mode while being logged on as a normal user at the operating system. For this scenario, you need to log on as a normal user to Windows and start the Management Console in display mode. Then choose Plant Connectivity Run as Administrator User in the menu. The User Account Control (UAC) will prompt you for the credentials of an administrator user. The Management Console will restart in administrator mode afterwards.
NoteOnly one instance of the Management Console at a time can be operated in administrator mode. Further instances will automatically open in display mode. A dialog informs you about the competing instance running in administrator mode. Administrators can terminate this competing instance and reopen their own instance in administrator mode from this dialog.
Authorization for Agent Instance Services
Agent instances running as a service may be configured to use a specific user. The user account used for this needs the log on as a service privilege. This privilege is granted automatically when you assign a user to an
8 P U B L I CSecurity Guide PCo 15.4
Authorizations
agent instance. Alternatively, this can be configured in the Group Policy Editor. You can find more information about this on the Microsoft Developer Network (MSDN) Web site under the following links:
● Log on as a service privilege: http://msdn.microsoft.com/en-us/library/ms813948.aspx
● Service Logon Accounts: http://msdn.microsoft.com/en-us/library/ms677948(VS.85).aspx
To control the general access to the Plant Connectivity Management Console, you can use the following technologies for the PCo system folder (usually found under C:\Program Files (x86)\SAP\Plant Connectivity\System):
Technology Quick Link
Group Policy Objects (GPO) http://technet.microsoft.com/en-us/library/cc754286.aspx
Access Control Lists (ACL) http://technet.microsoft.com/en-us/library/cc770749(WS.10).aspx
Authorization Management in SAP Plant Connectivity
You can use authorization management to define specifically which PCo services you want external callers to be able to access.
Standard Settings
After installing PCo, only users that belong to the Administrators user group have access to the services provided by the Management Service. The PCo Web server can be called by users that belong to the PCoWebServer user group provided this user group existed at the time of installation. Otherwise, and for all other services, the default setting is No Access for the topmost level and Access Inherited from Superordinate Service for the lower levels. After installation, you can revert at any time to these standard settings by choosing the relevant pushbutton.
Authorization Services
SAP Plant Connectivity provides several services that can be used by remote computers:
● Management ServiceUsing the Management Service, you can call PCo functions using Web services. You can configure, start, or stop agent instances and query configurations, status information, or protocols.
● Remote ClientThe remote client enables you to monitor PCo from a remote computer, to start or stop agent instances, to export and import configurations, and to query protocols.
Security Guide PCo 15.4Authorizations P U B L I C 9
● PCo Web ServerThe PCo Web server provides configurable methods in the form of Web service endpoints.
You should use https for the service and, in addition, client certificate authentication. When using basic authentication or client certificate authentication the services require that the user can log on to the Windows computer on which PCo is installed. In addition you have to use the authorization management in the PCo Management Console to control which PCo services can be accessed by external callers.
Authorization Management for the SAP Digital Manufacturing Cloud
If you use PCo together with the SAP Digital Manufacturing Cloud you have to define the rights of the users who can access the services provided by the CloudServicesHost. Predefined roles are assigned to individual services. You can assign the roles to the individual users in the Management Console under Tools Cloud Integration User Configuration .
The following roles have been defined in release PCo 15.3 (SP01):
Roles
Role Description
Administrator This role is used for the administration of users and authorizations.
RecommendationSAP recommends that users with this role should not be assigned to any additional business roles.
Users with the Administrator role can only be created locally in PCo.
CertificateAdministrator A user with this role can manage certificates. In particular, he or she can establish the trust relationship with communication partners.
PCoConfigurator A user with this role can create and change PCo configuration elements, in particular service providers and their dependent configuration elements such as source and destination systems.
ServiceExecutor This role is required to execute machine methods of the machine model. (For more information about the machine model, see https://help.sap.com/viewer/76070b83a9954174b76a3411ad31f034/latest/en-US.)
10 P U B L I CSecurity Guide PCo 15.4
Authorizations
Role Description
DataReader This role is required to read data from a source system using a query.
DataStorer A user with this role can use a store query to write data back to a source system.
FileProcessor A user with this role can read and write files. This allows files to be written via the Digital Manufacturing Cloud for handover to a print server to a folder that you have configured for this purpose. For more information about setting up the print function in the DMC, see https://help.sap.com/viewer/76070b83a9954174b76a3411ad31f034/latest/en-US.
Operator A user with this role can start and stop service providers and query the runtime status of service providers (agent instances).
The Operator role has been newly introduced with PCo 15.3 (SP01). Other roles, like the Administrator role and the CertificateAdministrator role, have changed their meaning, compared to earlier releases of PCo. Hence, the assigned roles of the Cloud users will be migrated when upgrading to PCo 15.3 (SP01), following the schema below:
Migrated Roles
Role before Migration Role(s) after Migration
Administrator Operator, PCoConfigurator
CertificateAdministrator PCoConfigurator
PCoConfigurator PCoConfigurator
DataReader DataReader
DataStorer DataStorer
ServiceExecutor ServiceExecutor
FileProcessor FileProcessor
NoteAfter migration the roles Administrator and CertificateAdministrator will not be assigned to users any longer. You have to create a new assignment to users. SAP recommends keeping these roles separate from the roles for configuring and operating PCo.
Security Guide PCo 15.4Authorizations P U B L I C 11
Communication and Network Security
Your network infrastructure is extremely important in protecting your system. Your network needs to support the communication necessary for your business needs without allowing unauthorized access. A welldefined network topology can eliminate many security threats based on software flaws (at both the operating system level and the application level) or network attacks such as eavesdropping.
If users cannot log on to your application or database servers at the operating system or database layer, then there is no way for intruders to compromise the machines and gain access to the back-end system’s database or files. Additionally, if users are not able to connect to the server LAN (local area network), they cannot exploit well-known bugs and security holes in network services on the server machines.
Communication Channel Security
The table below shows the communication channels used by PCo, the protocol used for the connection, and the type of data transferred.
Communication Path Protocol Used Type of Data Transferred Data Requiring Special Protection
Classic OPC (DA, HDA, and A&E) data source to PCo (and vice versa)
COM/DCOM Tag values, metadata, and hierarchical structure of tags
OPC UA data source to PCo (and vice versa)
HTTP (deprecated)/ HTTPS or OPC UA specific protocol via TCP
Tag values, metadata, and hierarchical structure of tags
Password for user session (if used), private key of certificates
OPC UA destination Inherited from OPC UA source system
Method call Inherited from OPC UA source system
Data source to PCo (and vice versa) (this applies to the following agents: Citect, IP21, PI, PI-AF, Proficy)
Vendorspecific proprietary protocol
Tag values, metadata, and hierarchical structure of tags
Password for logon to data source
Modbus data source TCP/Serial Protocol Tag values, metadata, and hierarchical structure of tags
PCo to MII (destination) HTTP/HTTPS Tag values, metadata, and hierarchical structure of tags
Password for logon to MII
12 P U B L I CSecurity Guide PCo 15.4
Communication and Network Security
Communication Path Protocol Used Type of Data Transferred Data Requiring Special Protection
PCo to Web service destination
SOAP Tag values, metadata, and hierarchical structure of tags
Password for Web service
PCo to ABAP NetWeaver AS (destination)
RFC Tag values, metadata, and hierarchical structure of tags
Password for logon to NetWeaver system
PCo to OData destination HTTP/HTTPS Tag values, metadata, and hierarchical structure of tags
Password for OData service
PCo to Restful Web service destination
HTTP/HTTPS Tag values, metadata, and hierarchical structure of tags
Password for Restful Web service
PCo to Universal Web service destination
HTTP/HTTPS Tag values, metadata, and hierarchical structure of tags
Password for Web service, private key of certificates
PCo to Sybase ESP destination
HTTP/HTTPS Tag values, metadata, and hierarchical structure of tags
Password for Sybase ESP
PCo to ODBC destination ODBC Tag values, metadata, and hierarchical structure of tags
Password for ODBC data source
MII (TagQuery) to PCo LISA (MII specific binary protocol)
Tag values, metadata, and hierarchical structure of tags
MII (PCoQuery) and NetWeaver to PCo
xMII data transfer protocol (new MII specific protocol)
Tag values, metadata, and hierarchical structure of tags
private key of certificates (optional)
PCo Remote Client to PCo Management Host
NET.TCP (and potentially also WCF (Windows Communication Foundation)
Commands, status information, configurations, and logs
(Encrypted) passwords in configuration data
MII (PCoQuery) to PCo Management Host
HTTP/HTTPS Commands, status information, configurations, and logs
(Encrypted) passwords in configuration data
WebSocket WebSocket Protocol
WebSocket Protocol over TLS
Commands, status information, configurations
private key of certificates (optional)
Web client to PCo web server HTTP/HTTPS Command, status information, configurations
Windows account credential which is part of the windows group PCoWebServer
Security Guide PCo 15.4Communication and Network Security P U B L I C 13
Communication Path Protocol Used Type of Data Transferred Data Requiring Special Protection
MQTT to PCo and vice versa TCP
TCP over TLS
WebSocket Protocol
WebSocket Protocol over TLS
MQTT packets Password for MQTT Server,
Private keys for the client certificates.
Note the following protection options:
● RFC connections can be protected using Secure Network Communications (SNC).● HTTP connections can be protected using the Transport Layer Security (TLS) protocol.● SOAP connections are protected with Web services security.● Universal Web service destination allows the usage of tokens to prevent CSRF attacks. For more
information, see Application help for Universal Web service destination.
RecommendationWe strongly recommend using secure protocols (TLS, SNC) whenever possible.
Related Information
DCOM Security [page 14]OPC UA Security [page 19]Application Certificate Management in Plant Connectivity OPC UA Components [page 21]Application Certificate Management in Plant Connectivity MQTT Components [page 22]TLS-Based Secure Communication in PCo [page 24]Enabling TLS for the Management Host Service [page 26]Enabling TLS for an Agent Instance [page 27]Enabling TLS for the Web Server Hosted in an Agent Instance [page 27]
DCOM Security
The OPC standards DA, HDA, and A&E use DCOM security. To implement DCOM security, carry out the following steps:
1. On the machine where the OPC server is running, use the command dcomcnfg.exe to carry out the following steps:
○ Check the launch and the activation limits under My Computer Properties COM Security .○ Check the access limits.
14 P U B L I CSecurity Guide PCo 15.4
Communication and Network Security
○ Verify the OPCEnum application's DCOM security settings for launch/activation and access.○ Verify the respective OPC server application’s DCOM security settings for launch/activation and
access.○ Then make the following settings for the agent instance:
○ Grant the Anonymous Logon account local and remote permissions.○ Grant the Everyone group local and remote permissions.
For a simple setup of both, you can grant the Anonymous Logon account and the Everyone group local and remote permissions.
○ Set a valid domain user account.2. On the machine where PCo is installed and the agent instance is running, use the file dcomcnfg.exe to
verify or change the launch and activation limits.○ OPC server credentials for the local system:
○ Grant the Anonymous Logon account local and remote permissions.○ Grant the Everyone group local and remote permissions.
○ Valid domain user accountThe Everyone group covers all authenticated user accounts. You can grant permission to a specific user or group to achieve a higher level of security.
Use of Certificates
In an SSL or TLS communication you have to distinguish between client and server certificates. A server can also have the role of a client when communicating with another server. Whenever you generate a client or a server certificate, a public and a private key are used for the generation. Within PCo the following two use cases, where certificates come into play, are explained in this document:
● Certificates that the server and/or the client uses to identify themselves to a communication partner. These certificates must be certificates with a private key.
● Certificates that are sent from the communication partner. The server and/or the client must verify the trustworthiness of the certificates. Therefore, the public key of the certificates or the public key of the issuer certificates has to be available in the corresponding certificate store (the trust store).
Certificates can have very different purposes, but regardless of their purpose, all these objects are called certificates. On a Microsoft platform these certificates are typically maintained through a certificate manager. That certificate manager shows a type of folder structure. Each of these folders is either a trust store or a certificate store, depending on the types of certificates stored in it. Certificates without a private key, which are usually used to verify the trustworthiness of communication partners, can also be stored outside of this Microsoft certificate store somewhere in the file system.
SAP Plant Connectivity creates some of the aforementioned certificate stores in the Microsoft Certificate Manager as well as in the folders of the file system certificate store.
Depending on the protocol of the source system or the destination system, we recommend that you use the following certificate stores, which are created by the installation of Plant Connectivity inside the Microsoft Certificate Manager:
● Web Machine DefaultCertificate store for certificates with private key used for Web communication (SOAP, Rest, OData).
● UA Machine Default
Security Guide PCo 15.4Communication and Network Security P U B L I C 15
Certificate store for certificates with private key used for OPC UA communication.
These are only recommendations and it is also possible to select other certificate stores for identification purposes. However, we do not recommend that you use a trust store for this purpose.
The second use case (see above) is about verifying the trustworthiness between the communication partners of an SSL or TLS connection. In order to understand how the trust needs to be configured, it is necessary to know which certificates are sent during the communication set-up phase.
In a simple case the communication partner sends a self-signed certificate. The public key of the received certificate must be known to the recipient. In order for PCo to verify if it can trust that certificate, the self-signed certificate has to be located in the correct certificate store.
In a complex case the communication partner identifies himself by a certificate that is issued by a Certificate Authority (CA) and thus typically includes a chain of certificates. The server or the client can only verify the trustworthiness of the certificate, if they know the complete chain of certificates with public keys.
The communication partner can send the complete certificate chain, but it is also possible, that they only send a certain part of the certificate chain. The receiving communication partner has to know the certificate store where the missing issuer certificates or the used root certificate can be found. By specifying a certificate store for issuer certificates, it is possible to do a complete verification of the sent certificates.
For convenience reasons, there is a third store that contains certificates that were sent from a communication partner but could not be verified as trusted certificates. Due to the failing trust check, these certificates are moved to the folder for rejected certificates.
In SAP Plant Connectivity, these certificate stores are designed as described below. SAP Plant Connectivity offers two options to define the different certificate stores. The administrator can choose which he prefers and can even override the default settings below. The decision about which certificate store to use is not made centrally for PCo, but for each entity in PCo itself. Therefore, it is possible, for example, to have different certificate stores for different source systems located on the same PCo instance. The following store types are offered:
● Microsoft Certificate Store● File System Certificate Store
The default certificate stores for the Microsoft Certificate Store are:
Microsoft Certificate Stores
Folder Selected Entry
Trusted Certificate Store ● Trusted Publishers (Web)● UA applications (OPC UA)
Issuer Certificate Store ● Intermediate Certificate Authorities (Web)● UA Trusted Issuers (OPC UA)
Rejected Certificate Store ● Untrusted Certificates (Web)● Rejected Certificates (OPC UA)
●●
16 P U B L I CSecurity Guide PCo 15.4
Communication and Network Security
The default certificate stores for the File System Certificate Store are:
File System Store
Folder Directory
Trusted Certificate Store ● Web: C:\ProgramData\SAP\PCo\CertificateStores\TrustedCertificates
● OPC UA: C:\ProgramData\SAP\PCo\CertificateStores\UA Applications
Issuer Certificate Store ● Web: C:\ProgramData\SAP\PCo\CertificateStores\TrustedIssuers
● OPC UA: C:\ProgramData\SAP\PCo\CertificateStores\TrustedIssuers
Rejected Certificate Store ● Web: C:\ProgramData\SAP\PCo\CertificateStores\RejectedCertificates
● OPC UA: C:\ProgramData\SAP\PCo\CertificateStores\RejectedCertificates
Validation Checks for Certificates
In order to validate whether a certificate is acceptable, Plant Connectivity executes the following checks:
● Verifying the signatures of the certificates in the certificate chain and the completeness of the certificate chain. If a self-signed certificate is being used, there is no certificate chain, and only the signature of the certificate itself is checked.
● Checking the revocation status of the certificate.● Checking the following attributes of the certificate:
○ Validity period of the certificate○ Subject of the certificate, for example, check, whether it contains the host name for the server
certificate as the Common Name.○ Subject Alternative Name○ Key usage attribute: Check, whether the key usage attribute matches the intended usage.
● Check trust, that is, check if the CA that signed the request is being trusted.
If one of the validation checks fails, the SSL or TLS connection cannot be established. In various security settings you can configure which of these checks should be ignored by PCo.
The previous sections explain in detail how trust could be established within SAP Plant Connectivity. If a server possesses several alternative host names, the validation of the subject can sometimes lead to unexpected results. In this case it is often not sufficient to specify only the host name in the subject, but it will also be necessary to specify the alternative host names or even the IP addresses in the certificate. This should be reflected when generating certificate signing requests or self-signed certificates. See also: Generating Certificate Signing Requests or Self-Signed Certificates [page 18]
Security Guide PCo 15.4Communication and Network Security P U B L I C 17
Generating Certificate Signing Requests or Self-Signed Certificates
You can use the Microsoft Powershell in administrator mode to generate a self-signed certificate with alternative host names. You can use the following command:
New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -Type Custom -Subject "CN=ServerNameAlternative1, O=Company SE, OU=Manufacturing, C=DE" -TextExtension @("2.5.29.17={text}DNS= ServerNameAlternative1&DNS= ServerNameAlternative2&DNS= ServerNameAlternative3") -NotBefore (Get-Date).AddDays(-1) -NotAfter (Get-Date).AddMonths(12)
This command creates a self-signed certificate that is valid starting from yesterday and for the next 12 months. The certificate has three alternative host names and the certificate will be stored in the local machine certificate store inside the LocalMachine\My folder where the My store is displayed as Personal.
You can find the details about the New-SelfSignedCertifcate command in the Microsoft documentation under https://docs.microsoft.com/enus/powershell/module/pkiclient/newselfsignedcertificate?view=win10ps
Import a Certificate into a Microsoft Certificate Store
In order to import a certificate into a Microsoft Certificate Store we recommend that you execute the following steps, rather than installing the certificate by double-clicking on it:
1. Open the Microsoft Certificate Store by using certlm.msc.
NoteDo not use the User Certificate Store. Make sure that you to call the local computer store as described above.
2. Navigate to Personal Certificates folder.
3. Select the following entry in the context menu: All Tasks Import .4. Follow the steps for importing the certificate.
As a result, the certificate will be imported in the selected store.
Recommendation to Use Certificates Signed by a CA
As certificates signed by a Certificate Authority (CA) provide a higher level of security, we recommend that you use these certificates signed by a CA, although it is also possible to use self-signed certificates.
To obtain certificates signed by a CA you must create a certificate signing request (CSR) and must submit this CSR to a Certificate Authority. This might be a commercial or a local CA. This CA must verify your request and
18 P U B L I CSecurity Guide PCo 15.4
Communication and Network Security
will then sign it. The resulting certificate must then be assigned to the PCo application for which you want to use secure communication.
Additionally, certificates signed by a CA make it easier to establish the trust relationships. With these certificates it is possible to establish trust by trusting the CA root certificate only. Therefore, all certificates that share the same root certificate are automatically trustworthy, too.
Currently there is no support for creating CA certificates in SAP Plant Connectivity. However, self-signed certificates can be created by a user with administration rights. For some applications self-signed certificates can be created and assigned in the Management Console directly.
NoteWhen using self-signed certificates, the trust must be established for each certificate.
OPC UA Security
This section applies to both the OPC UA source system, the OPC UA server, new as of PCo 15.1 (SP03), and the OPC UA destination system, which inherits its properties from an OPC UA source system.
NoteRecommendations for security policies may change over time due to increasing computing power. You should review your settings regularly.
OPC UA security is divided into the following categories:
● Channel Communication: The channel communication uses the standard X.509 v3 certificates.● User Session: The user session may use Anonymous, User name and Password, or Credentials.
OPC UA security for channel communication is governed by the OPC UA specification, which has been made open source in 2015. The current version of PCo supports version 1.03 of the OPC UA specification.
NoteVersion 1.04 has been released but is not yet supported.
It is based on the usage of X.509 v3 certificates for both client and server. It defines several security modes:
● NoneWith None, no security is provided.
● SignWith Sign, data is transferred unencrypted but with digital signatures that allow verification of data integrity.
● SignAndEncryptWith SignAndEncrypt, data is signed and encrypted.
The profile security category lists several policies:
● None● Basic256Sha256
Security Guide PCo 15.4Communication and Network Security P U B L I C 19
● Aes128_Sha256_RsaOaep● Aes256_Sha256_RsaPss
The policies can be combined in certain, predefined ways with the security modes.
The following security policies are deprecated since they support certificates with SHA1 as signing algorithm or a key size of 1024:
● Basic128Rsa15● Basic256
You should only use them for connections to legacy systems that do not support stronger policies. In the OPC UA source system, these policies are marked as deprecated. In the OPC UA server, they are not available by default.
If you need any of them, you can switch on the corresponding configuration option ( Tools OptionsCompatibility OPC UA Server: Allow Usage of Deprecated Security Options ) . If you do this, they can then be chosen in the configuration dialog for the OPC UA server endpoints, but are marked as deprecated,
NoteUsing the security policy Basic128Rsa15 will also result in the enablement of a known vulnerability (see SAP Security Note 2732527 ).
In short:
● Security policy None only supports security mode None and should only be used for testing or for connecting to devices that do not support other security modes.
● Security policy Aes128_Sha256_RsaOaep is a security policy for configuration with average security needs.
● Security policy Basic256SHA256 is a security policy for configurations with high security needs.● Security policy Aes256_Sha256_RsaPss is another security policy for configurations with high security
needs.
In PCo, all security policies (with the exception of None) are supported with both security modes Sign and SignAndEncrypt. If the computation power of a device to which you want to connect is low and confidentiality is not an issue, but data integrity is important, you may consider using the security mode Sign.
NoteWhen using no security (security mode None), it may still be necessary to authenticate a user to a session by means of a password. In this case, the password must be encrypted before it is transferred to the server. This is only possible if:
● The server provides a certificate● The server certificate is trusted by the client
Therefore, even though the connection is configured without security, an error will occur if you try to connect without trusting the server certificate.
For more information on security policies, see https://apps.opcfoundation.org/profilereporting/ under Security Category Security Policy . This link provides detailed descriptions of the algorithms and other
attributes of the different security policies, as well as recommendation for their use.
20 P U B L I CSecurity Guide PCo 15.4
Communication and Network Security
The OPC UA specification details the process of certificate validation for the creation of secure channels (Release 1.03, Part 4, section 6.1.3). This process description allows the creation of a secure channel even though some checks may have failed.
The PCo UA source system and server rely on the (open source) .Net SDK of the OPC Foundation, which currently does not fully support this part of the specification, meaning that the same holds for SAP Plant Connectivity OPC UA applications. This means for the UA source system, in particular:
● Certificate revocation lists are only supported for filebased storage of certificates. They are considered automatically if they are present in the crl subfolder of the folder that is configured as trusted store or trusted issuer store.
● Missing certificate revocation lists do not lead to certificate validation failure.● Certificate revocation list checks cannot be configured.
The PCo OPC UA server currently does not support validation failure exceptions at all which leads, in general, to higher security but fewer configuration options. The PCo OPC UA server only supports certificate revocation lists for filebased certificate storage. As for the OPC UA source system, missing certificate revocation lists do not lead to certificate validation failures.
Providing the option to use session security is the task of the OPC UA server. The PCo OPC UA server functionality currently does not support user-based or certificate authentication for sessions; only anonymous access is supported.
The PCo OPC UA source system supports user/password and certificatebased authentication if the OPC UA server to which it connects supports this too.
Application Certificate Management in Plant Connectivity OPC UA Components
OPC UA source system and server need an X.509 v3 certificate as application certificate for setting up a secure connection, and for this application certificate the private key must be accessible to the OPC UA application. If an OPC UA application provides an application certificate, it must be a formally valid certificate or empty (null), otherwise the connection is refused by the other party. No secure connection can be established with an empty certificate, of course.
NoteAs of version 15.3, SAP Plant Connectivity allows you to create self-signed X.509 v3 certificates for OPC UA applications.
You can also use self-signed certificates, certificates created by a UA server certificate creation utility from another vendor, or certificates from a certificate authority to create application certificates.
PCo UA applications support both certificate chains as well as self-signed certificates for the creation of secure channels. Since some UA applications may not be able to receive (partial) certificate chains, PCo UA applications allow you to configure whether a certificate chain is sent or whether only the application certificate is sent. This is the default.
To send a certificate chain, you must store the application certificate in the Microsoft Certificate store and the other (intermediate and CA) certificates of the chain in the folders your application uses as store for trusted issuers or the trust store. If you send only a partial chain, the missing parts must be available to the other party
Security Guide PCo 15.4Communication and Network Security P U B L I C 21
by other means (usually in the trusted store or trusted issuer store of that other application). Collecting the certificates of a chain to send them to the other party relies on finding, recursively, the certificate that was used to sign those certificates in the chain that were already found. This is only possible if there is no gap in the chain as it is stored in the folders in which the application can search for them.
In Plant Connectivity the application certificate must be stored in the Microsoft certificate store to protect the private key. The recommended way to provide it is either to generate it or to import it as a .pfx file into the UA Machine Default folder of the LocalMachine store in the Microsoft certificate store. Other folders can be used to provide backward compatibility. If the Current user store is used, PCo agent instances, which run as a service, may not be able to access the private key, unless the service is run with the identity of the same user. In this case the private key is, however, better protected.
File-based certificate stores can only be used as a trust store for application certificates from other UA applications (without their private key). This can be set up on the Security tab of UA source systems and UA servers. If you choose to change the default settings, you should follow the instructions in the Storing Configuration Information and Data Privacy Protection section to protect that location appropriately.
NoteThe OPC UA specification requires that certain attributes and extensions of application certificates are set to specific values. These requirements may differ from what you are used to from other certificatebased secure connections. They are detailed in section 6.2.2, Part 6 of revision 1.03 of the OPC UA specification.
NoteSome UA applications may refuse to establish a secure connection if a self-signed certificate does not specify CertificateSigning as intended key usage. The specification only requests digitalSignature, nonRepudiation, keyEncipherment, and dataEncipherment.
NoteThe validation functionality for CA-signed certificates or chains of the Microsoft certificate store is, in general, different from the one used by OPC UA applications. If the Microsoft certificate store can validate a certificate signed by a CA, this means that the CA certificate is stored in the Trusted Root Certification Authorities folder of the Microsoft certificate store. This is not normally the place where an OPC UA application searches for the CA certificate. These latter locations are configured on the Security tabs of the PCo UA application.
Application Certificate Management in Plant Connectivity MQTT Components
The PCo MQTT client can optionally use an X.509 certificate as application certificate for setting up a secure connection, but a secure connection using TLS can also be established without such a certificate. If the PCo MQTT client uses an application certificate, its private key must be accessible. The PCo MQTT clients will not start if an invalid certificate is used.
If you use certificate chains for client authentication, all intermediate CA certificates must be installed in the Intermediate Certification Authorities store . The root CA certificate must be installed in the Trusted Root Certification Authorities store.
22 P U B L I CSecurity Guide PCo 15.4
Communication and Network Security
NoteThe Microsoft Certificate store is always used for the client certificates. The configurable certificate store type is only used during the validation of the server certificates.
When the PCo MQTT clients are used on Windows OS, the following security settings are recommended:
Recommended Settings on the Connection Tab
Field Recommended Setting
Store Type Microsoft Certificate Store
NoteNote that the certificates for the current user may be not visible during runtime if you start the corresponding agent instance with other credentials. This will prevent the agent instance from starting.
Trusted Certificates/Issuer Certificates/Rejected Certificates For the certificates, you choose a certificate storage location on the local computer or the current user.
Revocation Check Check Online Revocation Lists
Revocation Check Scope Check Entire Chain
Ignore Server Host Name Do not select the checkbox.
Ignore Validity Period Do not select the checkbox.
If you use the File System Certificate Store, we encourage you to discuss the settings with your system administrators.
NoteFile System Certificate Store does NOT support Indirect Certificate Revocation Lists.
During the validation of the server certificate chain the following algorithm is used:
1. The certificate chain is built by PCo using the sent certificates, the trusted certificate folders, and the issuer certificate folders. The rejected folder is used only for temporary storage of the certificates.
2. If the chain is incomplete, the certificate is not trusted.3. If the chain is built and at least one of the certificates is taken from the trusted folder, the certificate is
trusted.4. The revocation check is only performed if the certificate chain is complete and the certificate is trusted.5. During every online revocation check, the crls folder under the trusted folder will be updated according to
the last CRLs.
The following asymmetric hash algorithms are supported (in the brackets is the algorithm Object ID):
● SHA1 DSA (1.2.840.10040.4.3)● SHA1 RSA (1.2.840.113549.1.1.5)
Security Guide PCo 15.4Communication and Network Security P U B L I C 23
● SHA256 RSA (1.2.840.113549.1.1.11)● SHA384 RSA (1.2.840.113549.1.1.12)● SHA512 RSA (1.2.840.113549.1.1.13)
The following asymmetric hash algorithms are considered insecure and are not supported (in the brackets is the OID ):
● MD2 RSA (1.2.840.113549.1.1.2)● MD5 RSA (1.2.840.113549.1.1.4)
TLS-Based Secure Communication in PCo
Transport Layer Security (TLS) is the successor technology for SSL. TLS should be used in version 1.2, earlier versions are deprecated. In PCo 15.2 SP03, FP 1 TLS 1.2 is supported for all TLS -based connections. In earlier versions of PCo, only the predecessor technologies may be available for certain connections. This will be fixed by patches.
New functionality in PCo will only support version 1.2 of TLS. Existing functionality may support earlier versions to ensure backwards compatibility. Not supporting earlier versions may break connectivity. In future versions of PCo, support for TLS 1.0, 1.1, or SSL may be disabled by default, though. You should use TLS 1.2 wherever possible.
PCo uses Transport Layer Security (TLS) to secure the communication between PCo and the following:
● SAP MII, if PCo acts as MII client● SAP ME, if PCo acts as Web client● OData server, if PCo acts as OData client● Web server for Restful Web services, if PCo acts as Web client● ESP server, if PCo acts as ESP client● SAP MII, if PCo acts as socket server● WebSocket clients, for example, SAP MII, if PCo acts as WebSocket server● Web service client, when PCo acts as Web server● PCo MQTT source/destination system and an MQTT server
In addition, TLS is used in PCo services offered by the Management Host Service and by the Cloud Host Service.
TLS is based on the exchange of certificates between server and client. During the handshake between server and client, the server identifies itself by a certificate that is sent to the client. The client checks whether the given certificate is a trusted and a valid certificate. Optionally, the server could request a client certificate. In this case, the client also must send the certificate to the server that is checking the validity and the trustworthiness of the certificate. A secure communication channel is only created successfully, if all checks are passed.
In principle, there are two types of certificates:
● Self-signed certificates● Certificates issued by a trusted Certification Authority (CA)
24 P U B L I CSecurity Guide PCo 15.4
Communication and Network Security
The type of certificate determines how to set-up the certificate infrastructure to get the secure communication working:
● If certificates issued by a trusted CA are used, it is not necessary that the client knows the server certificate and vice versa. It is only necessary that the client knows the CA certificate that issued the server certificate. Accordingly, the server has to know the CA certificate that issued the client certificate. This means that the server keeps the server certificate and the CA certificate in its certificate store, while the client stores the client certificate and the CA certificate.
● If self-signed certificates are used, the certificates have to be exchanged between server and client. This means that the server has to import the client certificate without a private key , while the client has to import the servert certificate without a private key. Finally, the server certificate store contains the server certificate (with a private key) and the client certificate (without a private key). Accordingly, the client certificate store contains the client certificate (with a private key) and the server certificate (without a private key).
● A Web server in PCo agent instance is configured with only one server certificate which is imported by the client during the initial ‘handshake’. This certificate contains information such as expiration date, issuing authority and the service end point URI (Uniform Resource Identifier). During handshake, the client compares the URI to the URI it had originally communicated to ensure the match and it also checks the issuing authority and expiration date. The encryption and decryption during this process occur as explained below:○ The client encrypts with the server’s public key and the server decrypts with its private key, thus only
the entity with the private key can decrypt the client’s encrypted data.○ The server encrypts with its private key and the client decrypts it with the public key of the server, thus
providing the assurance to the client that the data must have come from the owner of the certificate
● After this initial handshake process, both the server and the client agree on a shared secret symmetric key, which involves less computation overhead and is responsible for establishing the secure communication.
In order to grant a Secure Socket communication between MII and PCo, a server and a client authentication have been implemented. For more information about Configuring the Use of TLS on the AS Java, see http://help.sap.com/saphelp_nw73ehp1/helpdata/en/4a/015cc68d863132e10000000a421937/content.htm . The steps in PCo are described in the section Enabling TLS for an Agent Instance [page 27].
If PCo acts as an MII client or ME Web client, only a server authentication with certificates takes place. According to the description above, a server certificate has to be imported onto the MII server or the ME server. On the PCo side, the appropriate certificate has to be imported into the trusted certificate store.
To enable TLS for the Management Host service, the steps described in the corresponding section have to be considered.
NoteSelf-signed certificates for PCo can be created with certificate creation tools like OpenSSL . (See PCo application help for Default Certificates).
The Microsoft tool makecert is deprecated. Microsoft offers functionality to create self-signed certificates in a newer version of MS PowerShell. See: https://docs.microsoft.com/en-us/windows/desktop/seccrypto/makecert
To create a certificate request that could be sent to a CA, Microsoft IIS or certificate creation tools as described above could be used.
Security Guide PCo 15.4Communication and Network Security P U B L I C 25
Enabling TLS for the Management Host Service
You can enable TLS for the Management Host service by editing the file ManagementHost.exe.config. Since the Management Host service is based on the Windows Communication Framework (WCF), potentially all options provided by the WCF apply. It cannot be guaranteed, however, that all possible and valid configurations will work in your environment. In particular, it is known that message security with wsHttpBinding for connections between WCF -based applications and Java applications is problematic or difficult to set up.
One particular example setup which enables transport security with the basicHttpbinding is described below:
To do this, carry out the following steps:
1. You can modify the corresponding endpoint in the Services section by replacingaddress=”http://withaddress=”https://
2. In the serviceBehaviors section, replace<serviceMetadata httpGetEnabled="True" httpGetUrl="http://hostname:port "with<serviceMetadata httpsGetEnabled="True" httpsGetUrl=”https://hostname:port”
3. Assign a certificate to the TLS port for the host name with Windows Command Prompt.4. Open the Windows Command Prompt as Administrator and execute the following command:
netsh http add sslcert ipport=[IP address of PCo Server]:[Port of the Management host] certhash=[thumbprint of certificate] appid=[Guid for the owning application]
5. Here you have to enter the following parameters:
Parameter Description
ippport IP address and port for the binding
certhash The hash of the certificate. The hash is the thumbprint of the certificate in capital letters.
appid GUID to identify the owning application. The GUID = [1A570ED4-80D1-4A98-A7AB-8B4C6D5A42A5] shall be used as PCo application GUID.
Example add sslcert ipport=1.1.1.1:443 certhash=0102030405060708090A0B0C0D0E0F1011121314 appid={1A570ED4-80D1-4A98-A7AB-8B4C6D5A42A5}
26 P U B L I CSecurity Guide PCo 15.4
Communication and Network Security
Enabling TLS for the Cloud Host Service
You can enable TLS for the Management Host service by assigning a server certificate in the configuration of the Cloud Integration in the Server Security Settings.
The complete information about the configuration of the Cloud Integration, including security settings, can be found in the Application Operations Guide under Cloud Integration.
Enabling TLS for an Agent Instance
1. Create a server certificate that is either self-signed or issued by a CA.2. Import the server certificate to the personal certificate store.3. Create a client certificate that is either self-signed or issued by a CA.4. Import the client certificate or import the CA certificate to the trusted root CA store.5. On the PCo Management Console, select an agent instance.6. On theServers tab, select the entry SAP MII Query Server.7. Select Server Certificate as the authentication type.8. Click Browse to select the appropriate certificate.
Enabling TLS for the Web Server Hosted in an Agent Instance
The Web server hosted within the agent instance can be secured by enabling TLS technology for a Web client and Web server communication over an insecure network that is encoded with the HTTP protocol. This use of TLS to encrypt the HTTP traffic constitutes the HTTPS protocol.
The Web server is a self-hosted Windows Communication Foundation (WCF) service with BasicHttpBinding (in the case of a SOAP-based Web service) and WebHttpBinding (in the case of a REST- and ODATA-based Web services) classes that employ transport security. In order to enable TLS, it is mandatory to configure the Web server port with an X.509 certificate during PCo Web server endpoint configuration. The default URI scheme in this endpoint configuration is HTTPS and the user is required to attach the server certificate with this URI scheme. This feature can be disabled by manually changing the endpoint URI scheme from HTTPS to HTTP.
Additionally, the PCo Web server also provides the basic authentication and authorization mechanism to verify identity and check the privileges of the authenticated user on the Web server and its operations. The user should be defined on the host machine where PCo is installed. The authorization permissions can be set either on the Web server or its individual operations. The authentication and authorization in that order is the default behavior during the configuration of the Web server endpoint. However, this behavior can be turned off by turning off the authentication in the Web Server Endpoint Configuration dialogue. When authentication is turned off, it also automatically hides the authorization check and all the Web server operations can be accessed without entering any user credentials. Certificatebased authentication to the Web server has been introduced in the Web server, but certificatebased authorization in this process has been turned off.
Security Guide PCo 15.4Communication and Network Security P U B L I C 27
NoteThe Microsoft Certificate store is always used for the Web server certificate.
Network Security
If the business system and the data source that are to be connected by PCo are located in different network segments and/or separated by a firewall, the following considerations should be taken into account:
● The basic recommendation is to run PCo (or the agent instances, to be precise) close to the data source.● For the notification scenario, PCo has to be able to reach the business system. The details for this are
configured in the notification destination in the PCo Management Console.● For the query scenario, the business system needs to be able to reach the agent instance. The port used
for this can be configured in the agent configuration in the PCo Management Console.● To use the remote console, the MMC (Microsoft Management Console) has to be able to reach the PCo
Management Host. The port used for this can be configured in the PCo Management Console.● To create a data source of type PCo Connector in MII, the system needs to be able to access the PCo
Management Console.
Ports
All ports that an agent instance opens for incoming connections can be configured in the PCo Management Console. For this, navigate to the Query Ports tab in the agent instance configuration.
Using the PCo Management Console, you can also configure the port that is opened by the PCo Management Host. For this, navigate to Tools Options Management Host Settings .
28 P U B L I CSecurity Guide PCo 15.4
Communication and Network Security
Storing Configuration Information and Data Privacy Protection
PCo stores all configuration information for source systems, destination systems, and agent instances in configuration files. The location of these files depends on the operation system, but usually you can find the folder under:
C:/ProgramData/SAP/PCo
This folder also contains the configuration audit log with the change history. This change history includes the user ID of the person who made the changes. The system administrator with the relevant authorization can delete the file depending on how long the audit data needs to be retained.
From the PCo Management Console you can reach this log using the View Menu.
NotePCo does not store any runtime data and does not provide other security audit capabilities.
In addition, this folder contains the default location for the filebased certificate trust stores. It must be ensured that access, specifically write access, to these folders is restricted to administrators, if filebased trust stores are used. The content of these folders is, in general, not confidential. Therefore, there is no need to encrypt them.
For the encryption of passwords in the configuration database files, PCo uses built-in Microsoft operating system support.
On agent instance level, under Notification Processing, you can set the storage method for the notification message queue to File System. In this case, PCo creates a sub-folder Queues in the folder C:/ProgramData/SAP/PCo. Inside this folder, PCo then creates additional folders for every agent instance that uses the storage method File System. Since notification messages that are temporarily stored in the message queue may contain confidential data, the system administrator is advised to restrict access to the folder C:/ProgramData/SAP/PCo/Queues to those users who will run the agent instance.
Security Guide PCo 15.4Storing Configuration Information and Data Privacy Protection P U B L I C 29
Dispensable Functions with Impacts on Security
The following functions that are relevant to security aspects can be switched off if you are not using them:
● Management Host: The Windows service for the PCo Management Host can be deactivated. The Management Host is required for the following scenarios:○ Creation of a PCoConnector data server in MII○ Use of the Remote Client
● Active Monitor: If you are not using the Active Monitor scenario, you can deactivate the corresponding Windows service, or you deselect the corresponding component already during installation .
30 P U B L I CSecurity Guide PCo 15.4
Dispensable Functions with Impacts on Security
Important Disclaimers and Legal Information
HyperlinksSome links are classified by an icon and/or a mouseover text. These links provide additional information.About the icons:
● Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your agreements with SAP) to this:
● The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.● SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any
damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.
● Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering a SAP-hosted Web site. By using such links, you agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this information.
Beta and Other Experimental FeaturesExperimental features are not part of the officially delivered scope that SAP guarantees for future releases. This means that experimental features may be changed by SAP at any time for any reason without notice. Experimental features are not for productive use. You may not demonstrate, test, examine, evaluate or otherwise use the experimental features in a live operating environment or with data that has not been sufficiently backed up.The purpose of experimental features is to get feedback early on, allowing customers and partners to influence the future product accordingly. By providing your feedback (e.g. in the SAP Community), you accept that intellectual property rights of the contributions or derivative works shall remain the exclusive property of SAP.
Example CodeAny software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax and phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of example code unless damages have been caused by SAP's gross negligence or willful misconduct.
Gender-Related LanguageWe try not to use genderspecific word forms and formulations. As appropriate for context and readability, SAP may use masculine word forms to refer to all genders.
Videos Hosted on External PlatformsSome videos may point to third-party video hosting platforms. SAP cannot guarantee the future availability of videos stored on these platforms. Furthermore, any advertisements or other content hosted on these platforms (for example, suggested videos or by navigating to other videos hosted on the same site), are not within the control or responsibility of SAP.
Security Guide PCo 15.4Important Disclaimers and Legal Information P U B L I C 31
www.sap.com/contactsap
© 2020 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company. The information contained herein may be changed without prior notice.
Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies.
Please see https://www.sap.com/about/legal/trademark.html for additional trademark information and notices.
THE BEST RUN
