Define the security model

The fifth workflow task defines the security model.

The following basic concepts are reviewed in order to reinforce understanding of the System Platform security model:

• Users: A user is each individual person that will be using the system (for example, John Smith and Polly Perez).

• Roles: Roles define groups of users within the security system. Roles usually reflect the type of work performed by different groups within the production environment. For example, Operators and Technicians.

• Permissions: Permissions determine what users are allowed to do within the system. For example: Operate, Tune, and Configure.

• Security Groups: A security group is a group of objects with the same security characteristics. The purpose of a security group is to simplify object security management by avoiding the need to assign security permission for each role to each individual object.

  Security groups let you define groups of objects, and determine who within your organization is allowed to make changes to the different object groups. Security groups typically map to areas within your System Platform installation, but more than one security group for each area may be needed within a single area. For example, you may need to assign specific operators to the "Line_1" security group, but assign a different set of operators to the "Line_2" security group.

Security model checklist

1. Configure a System Management Server (SMS) node. Set up only one SMS node in your topology. The SMS node secures the communication between all System Platform nodes.

2. If you are using an external authentication provider for Single Sign-On (SSO), such as AVEVA Connect or Azure Active Directory, configure the SMS to utilize the authentication provider as described in the System Platform Installation Guide. Note that the Certificate Manager authenticates users, not the SMS.

   You can also configure other deployed nodes as Redundant SSO server nodes. More than one RSSO node can be configured, but additional nodes can incur more network overhead..

3. Define Users, Roles, Permissions, and Security Groups necessary to implement security for the production environment. Select Users and Roles previously defined within the Operating System Security model, or define them within the IDE.

   Using Operating System Users and Roles facilitates object deployment and makes future maintenance easier.

4. Determine security settings for writable attributes of objects. Security permissions reflect the rights of different groups of users to change the attribute value. The available security options for writeable attributes are:

   • Read Only

   • Operate

   • Tune

   • Secured Write

   • Verified Write

   • Configure

   Review the functional worksheet that lists the objects (and their attributes).

   An Operate permission requirement does not mean that the user must be an Operator. A QA inspector might have Operate permissions to change a value on an object that that collects QA data, while an operator on the same production line would not have this permission.

To set up security using the IDE

5. Set the Galaxy security mode:

   • Galaxy

   • OS based (user or group)

   • Authentication provider

6. Create security groups.

7. Create roles and assign them to security groups.

8. Select permissions and grant them to roles.

9. Define users and assign them to roles.

10. Configure attribute security at the Template level.

See Security for more information. For details about security configuration and options, see the Application Server User Guide and the System Platform Installation Guide. In addition to procedures for implementing securing, the user guide also contains a reference section that lists general security guidelines. Additional information about security across AVEVA products is available in the AVEVA Cybersecurity Deployment Guide.