1. Network Access Between Stations

Typical access to PI data is provided using the client-server model with workstations accessing data stored on the server by making requests over a LAN or WAN. The network link provides another point for access control.

Firewalls can be installed on the server or routers to restrict access to a known set of client addresses and to limit communications to particular ports. PI client-server connections operate primarily on a single known port making it possible to prevent access to ports used for file transfer, terminal access, mail, and other potential security weak points.

The ability to communicate with the server system is dependent on proper installation of client and server protocol stacks and availability of properly configured name resolution services. Restricting access to name servers or providing reverse name resolution on the servers through static files can be used to further restrict network access.


PI Universal Data Server on Windows NT and UNIX (PI3) supports a finer level of granularity of privileges than PI on OpenVMS (PI2). The systems also differ in the mechanisms used to provide and manage security. Detailed information can be found in the respective Data Archive documentation. A brief comparison is provided here.

 

PI on Windows NT and UNIX (PI3)

PI3 provides connection level security support through its PIFirewall table. By configuring this table one can include or exclude specific addresses and sub-nets from connections. This provides a quick way to isolate a system from external connections without requiring enforcement of any particular user name and password management scheme.

PI3 (version 3.2) supports a PIProxy table, which is a mechanism for providing a default association between a client node address and a user name. In version 3.3 this mechanism is expanded and migrated to the PITrust table. This feature is particularly useful for interface nodes that generally run continually but need to connect automatically if the hardware is rebooted. Rather than storing a user name and password on the client in a file to be used on connection, the server administrator can establish the association of the client's network address (name or number) and a particular user account on the PI Server. Connections from that address are given the specified user's permissions unless the application specifically makes a login call. Server version 3.4.380 provides extensive support for Windows Integrated Authentication (SSPI) and enhances the PITrust mechanism with mapping of Windows principals to PI Identities used in access control lists (described in following sections).  Note the PI-SDK does not support automatic logins with the PIProxy table but with the release of PI-SDK 1.1 and PI3.3 supports the PITrust mechanism.  Support for SSPI begins with PI-SDK version 1.3.6. 

In addition, starting with PI SDK 2016 (1.4.6.494), transport security is enabled for Windows authenticated connections to PI Data Archive 2015 (version 3.4.395) or later. Cipher suites are negotiated during the Windows authentication handshake and logged in PI Data Archive message ID 7082. If a buffering node connects to multiple PI Data Archive servers of varying versions, transport security is enabled only on the connection to the PI Data Archive(s) with version 3.4.395 or later. Transport security ensures message integrity and privacy. PI SDK internally routes messages to the local PI Network Manager, which manages transport security with the PI Data Archive server.

 

PI on OpenVMS (PI2)

PI2 systems use a file on the server to provide security configuration at a per client machine level. There are 3 basic levels of permission that are applied across all calls, default, read, and write. When first connecting to a PI2 machine the server examines the address of the calling client from its network packet and performs a reverse name lookup to determine a name for the calling machine. It then consults its security file, piserver.dat, looking for an entry for that machine name. If a match is found the setting is applied, if no match is found a default setting, specified at the top of the file is applied.

Enabling Operational Intelligence