Access Limitations - 11​.10 (d)

21 CFR Part 11:

“(d) Limiting system access to authorized individuals.”

AVEVA Batch Management Security

AVEVA Batch Management has different security options as displayed in Figure 9: AVEVA Batch Management “Standard” (native) security, “Operating System” security and “ArchestrA” security. The “Security Enabled” check box shall be checked in a FDA-audited industry. This enables security verifications and recording of the users who perform the “Done By” and “Check By” signatures.

f

Figure 9 - AVEVA Batch Management security

FDA-audited industries should use the Operating System Security model for best results. Both OS Security models (User based and Group based) use Windows operating system authentication. This permits user name and password management, outside of AVEVA Batch Management, directly in the Windows operating system environment. By using OS Security you benefit from the standard Windows functions for password length and complexity. Other AVEVA products that are typically used with AVEVA Batch Management are also capable of using the OS security. Although an AVEVA Application Server Galaxy used with AVEVA Batch Management may be setup to use OS Group security, the AVEVA Batch Management Server should authenticate directly with the OS rather than through the ArchestrA security.

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. AVEVA Batch Management OS Group-based security uses these Windows features. For more help, see the Microsoft online help or a 3rd party book about Windows security.

When using local OS Groups as Roles, each client node interacting with the Batch server 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 complexity in regulated environments, the use of a Windows Domain controller and Windows Active Directory is recommended in multiple node installations.

AVEVA Batch Management roles should be designed carefully to limit the access to the different AVEVA Batch Management application components and functions. Once AVEVA Batch Management roles have been designed, they can be configured and later linked to different OS groups.

For more information on OS Security configuration, please refer to Chapter - “Security System”, in the AVEVA Batch Management User’s Guide.

Restricting the access to AVEVA Batch Management applications and functions

AVEVA Batch Management security system allows restricting the Application start to one or many roles as depicted in Figure 10. In this example, only the administrator role (ADM) is authorized to start the Environment Display.

Figure 10 - Application access

Some of the AVEVA Batch Management applications have more detailed security configuration possible, especially the Batch Display (batch client function) which is the User interface for Batch execution. The details for each application are setup in the bottom part of the Application-Function Editor, in the Functions section as depicted in Figure 11. The configuration of these functions is critical in FDA-audited industries. The roles that are authorized to access some functions like Aborting a phase, starting a batch, editing a phase parameter are defined through this interface.

In order to record the user who performed an action during the batch as part of the batch record, the specific function need to have the Security Enabled checkbox activated and roles defined in the “Done By” and “Check By” boxes. In Figure 11, the Abort Batch button will require the signature of either an administrator (ADM) or an engineer (ENG) but will not require a second user to perform the ”Check By” action. In this case, only one user’s signature can be recorded for a batch Abort.

Figure 11 - Detailed access to application functions

Defining the security model for phase parameter edition is particularly important. It should be noted that when a parameter is setup with Read/Write access (Edit Allowed or Required) in the phase model, then it can be changed from the Batch Display, as long as the users have the required “Done By” / ”Check By” access rights. This is true whether the parameter is a target or an actual and whether it is critical or not. Therefore, if a parameter has safety or criticality impact, it should be either defined as read only (no Edit Allowed capability) in the model editor or the accesses to the edition of parameters in general should be strictly controlled with severe “Done By” / ”Check By” requirements.

The different settings that impact the capability to edit a parameter and the requirements for “Done By” and ”Check By” signatures are depicted in Figure 12.

Restrictions shall also be added in FDA-audited industries to the “Edit Phase” function which enables a batch client to edit the phase Properties and Instructions in the Inactive Phase Parameter Editor.

Specific recipe signature requirements for phase and transitions

In addition to the detailed functions and parameter access described above, each recipe can:

• Specify if “Done By” or “Check By” signatures are required for entry or exit. This is specified for each individual recipe phase. This requires setting up the security for “Ack to enter”, “Ack to exit” functions as well as checking the appropriate boxes for each phases in the recipe as depicted in Figure 13.

• Require signature to authorize a transition to move on to the next activity in the recipe once the transition condition is met. This requires setting up the security function for “Answer question” as depicted in Figure 13 as well as defining the appropriate condition or question in the recipe transition expression. (Note that a question transition condition will only allow continuing when the “Yes” button is pressed. N parallel transitions need to be set to represent N possible paths, each path requiring its own signature.)

  

Figure 13 - Phase and transition signatures

Batch execution security

During the batch execution, all functions that have been set to require “Done By” / ”Check By” signatures in the Security Editor (and recipe editor for phases enter and exit) will display the corresponding popups before authorizing the action. The meaning of the signature is displayed at the top of the popup, in the Action field. Figure 14 depicts two “Done By” popups with different actions fields.

Figure 14 - “Done By” popups

When “Check By” is required, a second popup is displayed after the “Done By” authentication is successful. Figure 15 shows that the “Check By” popup includes the signature meaning in the Action field and verifies that the “Done By” and “Check By” User IDs are different.

Figure 15 -”Check By” popup

Figure 16 shows that the system verifies the role requested for a specific function.

Figure 16 - Role verification

The detailed authentication information including User_Id, application and function information, date, operator station id, recipe id, success status and reason, is logged in the “AuditEvent“ table as depicted in Figure 17. The AuditEvent table is used to log any authentication information, for all AVEVA Batch Management secured applications (Material Editor, Security Editor, Environment Display, etc).

Figure 17 - Audit Event

In addition to the AuditEvent table, the BatchDetails table includes detailed “Done By”/ ”Check By” information on the events happening in a batch or phase. This is depicted in Figure 18 where we can see some “Done By” and ”Check By” information along with the context of the event (Batch id, unit, procedure, operation, phase) in the first few columns and the description of the event in the description column.

Figure 18 - Batch Details information

Level of approval of the recipes

The usage of a recipe is controlled by:

Up to five levels of approvals before a recipe can be used in production

Up to two levels of approvals before a recipe can be used for tests

Association of recipes to specific users or roles

These access restrictions will be explained in this section.

Approval of a recipe for production

Up to five levels of approvals (including the author’s approval) may be defined for recipes and configured with security enabled and “Done By / ”Check By” roles as depicted in Figure 19. Until the recipe is approved, it is not available for scheduling as a production recipe.

Figure 19 - Configuring the recipe approval requirements

The system does not prevent the same user from approving several levels for the same recipe. There needs to be either a procedure to state that the approvers should be different or the roles need to be set so that no user has more than one level of approval.

Approval of a recipe for tests

In order to use a recipe for test, only the “Author” and “Approval Test” levels of approval are required. It is therefore recommended to add an additional level of security for the Recipe test approval. This can be done either by:

Giving access to test recipes to specific users or roles. The typical configuration of AVEVA Batch Management gives the engineer who develops the recipes access to all recipes so that they can create and test recipes without going back to the security edition for each new recipe. The other users are only given access to the specific recipes that they were trained on.

Requiring “Done By” / ”Check By” signatures for “Approval Test” function. This means that two “Approved for test” signatures are required to enable the corresponding checkbox.

Figure 20 shows the approval popup of a recipe that was approved for test.

Figure 20 - Recipe approval popup

Figure 21 shows the resulting history of a recipe after it was approved for test.

Figure 21 - History of a recipe that was approved for test

When a “Done By” / ”Check By” signature is required for a level of approval, only the “Done By” signature is visible in the user interfaces, while both “Done By” and ”Check By” signatures are recorded in the AuditEvent table as shown in Figure 23.

In this example, the second level of approval requires both “Done By” and ”Check By” signatures.

Figure 22 - “Done By” approval visible in the History interface

Figure 23 - “Done By” and ”Check By”recipe approval are recorded

Recipe Access vs user or role

AVEVA Batch Management Security Editor provides the ability to associate recipes to users and/or groups. This can be used as a way to limit the recipe access to users until they are trained.

In the example in Figure 24, the selected user only has access to the execution of two out of the 4 recipes. When recipes are associated to roles, then the user will have access to all of the recipes associated to his different roles.

Figure 24 - Recipe access

ArchestrA Security and InTouch as a host for AVEVA Batch Management components

InTouch and InTouch for System Platform are often used in an AVEVA Batch Management environment as a host for either AVEVA Batch Management ActiveX or ArchestrA graphics containing InBatch .NET controls. As mentioned before, AVEVA Batch Management should be set to use OS security. It is recommended to use the ArchestrA based security for InTouch applications. ArchestrA security itself should be set to OS security, preferably OS groups to simplify and centralize user management at the IT level.

Please refer to 21_CFR_Part11_Deployment_Guide, section Access Limitations—11.10 (d)

InTouch Security, for more information on InTouch security in FDA-audited industries.

Important: Although AVEVA Batch Management components can be hosted in an InTouch application, AVEVA Batch Management does not use the InTouch user to verify the access rights to AVEVA Batch Management components. The AVEVA Batch Management security is autonomous. The developer may choose to use ArchestrA security to protect buttons leading to an AVEVA Batch Management component but the AVEVA Batch Management function itself is protected through the AVEVA Batch Management Security Manager.

AVEVA BatchHistory Security

The Batch records are stored in the BatchHistory and BatchArchive databases.

AVEVA BatchHistory uses two security mechanisms:

• Windows operating system security

• Microsoft SQL Server security

As mentioned in the beginning of the document, within closed systems access is controlled by the people responsible for the content of the electronic records. Access attempts to the system (successful as well as unsuccessful) are added to the AuditEvent table of the system.

The system does not create a SQL user in the BatchHistory or BatchArchive databases. The user must configure a Windows OS user to run the HistQReader Service and ReportQReader Services.

This configuration is done at install time where the user configuring the system must be a sysadmin. Note that the service user does not need to be an admin or have any SQL rights. He will get the required read/write access to the DB by the system.

In order to access batch reports, the system configures a SSRS data source that is used to retrieve data from AVEVA Batch Management’s HistoryDB. The data source can be configured to use Windows Integrated Security or a specific Standard SQL account. It is in the administrative user’s responsibility to manually create and provide read-only access to any data source user.

SSRS also has a level of security that needs to be configured by the system user using the reporting portal. The system creates a local Windows OS group (ibReportsUsers) that can be used to assign users or groups to so that they can access batch reports.

Alarm and Event Security

Please refer to the AVEVA System Platform CFR Part 11 Deployment Guide for alarm security.