Access Limitations—11​.10 (d)

"(d) Limiting system access to authorized individuals."

Application Server Security

The Application Server IDE security system is a global function that applies to every object in the Galaxy database. It is a relationship-based security system between users and the objects and functions stored in a Galaxy.

IDE security is designed to allow system administrators to easily define users and assign the operations they are allowed to perform. The security permissions are defined in terms of the operations the users can perform using automation objects.

FDA-audited industries should use the OS User Based or OS Group Based Security model for best results. Both OS Security models use Windows operating system authentication. This permits user name and password management, outside InTouch, directly in the Windows operating system environment. By using OS Security you benefit from the standard Windows functions for password aging, logon maximum trial, user name uniqueness and more.

If using OS Group Based Security Authentication Mode, make sure there is an understanding of the Windows operating system, particularly its user permissions, groups and security features. IDE OS Group-based security uses these Windows features. For more help, see the Microsoft online help or third-party documentation about Windows security.

When using local OS Groups as Roles, each node within a Galaxy must have the same OS Users, Groups, and user-group mappings to get the same level of access to the user at each node. In order to avoid this in regulated environments the use of a Windows Domain controller and Windows Active Directory is recommended in multiple node installations.

For information on OS Security configuration, see the section "About OS Group-Based Security," under "Configuring Security" in the AVEVA System Platform IDE online help.

IDE-based security includes advanced security mechanisms that also affect InTouch.

InTouch HMI Security

When using InTouch in architectures based on tag databases. InTouch offers multiple security configurations. FDA-audited industries should use the OS Security model for best results. OS Security model uses Windows operating system authentication. This permits user and password combination management, outside InTouch, directly in the Windows operating system. By using OS Security, you benefit from existing functions for password aging, logon maximum trial, user name uniqueness and more.

For information on OS Security configuration, see the section "Using Operating System-Based Security," under "Securing InTouch" in the AVEVA InTouch HMI online help.

InTouch also offers an option for IDE-based security. When an InTouch node is configured to use ArchestrA security, the InTouch HMI uses methods and dialog boxes from Application Sever for logon and logoff operations. Users are configured in the Application Server IDE. An InTouch application configured to use IDE security provides the additional functions, which are useful in a regulated environment.

AVEVA OMI Security

AVEVA OMI extends security to the pane level of a ViewApp by restricting viewing of the pane's content to those user roles with sufficient access levels. Before you can configure security in a ViewApp, the following prerequisite tasks must be completed:

• Security roles must be assigned to those users who will interact with a running ViewApp. Each user role must be assigned an access level.

• Security must be configured to authenticate users by their user names and passwords as part of the ViewApp login process.

• Layout panes containing secure, restricted content must have an assigned access level.

  Configuring Secured or Verified Writes with IDE Security

Attributes in a Galaxy can be configured to have an access control as Secured Write or Verified Write. Secured Write attributes require users to re-enter their passwords to complete the write to a Galaxy Attribute. Attributes configured with Verified Write require users to re-enter their passwords and also require authorization of a second operator to complete the write operation.

Using Secured Write and Verified Write with IDE-Based Security

Writing to an attribute that is configured for Secured Write in InTouch run time requires users to re-enter their passwords to complete the write operation. The following illustration shows the InTouch run-time dialog for Secured Write authentication.

Writing to an attribute that is configured for Verified Write, in InTouch run time requires users to re-enter their passwords and also requires authorization of a second operator to verify the write operation. The following illustration shows the InTouch dialog for Verified Write authentication.

The operator must have "Can Modify Operate Attributes" operational permission to perform a Secured or Verified Write. The verifier must have "Can Verify Writes" operational permission to confirm the Verified Write.

The operator can add a comment for the Secured or Verified Write operation by selecting from a predefined Comment list or by entering a comment in the Comment box.

Following a Secured or Verified Write a security Event is written to the event log, including the following information:

• The signer name

• Verifier name, if any

• Type of write: "Secured Write" or "Verified Write"

• Date timestamp

• Comment, if any entered by user

• Reason Description, if any provided

• Attribute description, if any, or the Short Description of the Application Object, if no Attribute description exists

  Historian Security

Historian uses two security mechanisms:

• Windows operating system security

• Microsoft SQL Server security

Historian uses Microsoft SQL Server security configured in SQL Server Authentication mode or Mixed mode. Mixed mode allows users to connect to an instance of SQL Server using either Windows authentication or SQL Server Authentication.

The security choice from either SQL Server Enterprise Manager or Historian Console is offered when registering a server. FDA-audited industries should use Mixed mode and Windows Authentication. Windows Authentication offers consistency with the OS Security models. SQL Server allows you to define Windows user groups as SQL Server users thus ensuring centralization of all user related information and facilitating management of all parameters.

When the Historian is installed, default SQL Server logins are created that can be used for logging on to the Historian from client applications. These default logins provide "out of the box" functionality so that logins do not have to be created to start using the system. The following table describes the preconfigured logins:

Applications that are deployed in FDA-regulated industries should always change the default passwords for the SQL Server logins.

For information on Historian and related Microsoft SQL Server functions, see "Managing Security" in the AVEVA Historian online help.

For more information on server registration, see "Registering AVEVA Historian Servers" in the AVEVA Historian online help. .

For a more secure installation, check the "Always prompt for login" information check box in the Registered Wonderware Properties window.

For information on SQL Server security and registration, see your Microsoft SQL Server documentation.

Alarm and Event Security

The InTouch Distributed Alarm system includes the Alarm DB Logger utility that logs alarms and events to an alarm database. The Alarm DB Logger Manager uses fixed accounts in the Microsoft SQL Server database to access the data. The DB Logger needs to have a write-access account which is specified using the Alarm DB Logger manager utility.

The fixed user accounts (names and passwords) present a possible compliance risk. Companies should consider the potential for un-audited changes to the alarm database and determine if any procedural controls should be employed to address the potential risks. These procedural controls could include limiting access to the database by isolating the system network and databases from the corporate network and physical limitations to HMIs that can access the alarm database.