This chapter gives a short overview of the applications security module.
The security module implements FDA/GXP requirements according to 21 CFR
part 11. Using the security module makes the software fully compliant
to FDR/GXP regulations as stated in software compliance statement document.
The application offers different security scenarios which range from managing
standalone setups and small workgroups up to large installations with
a dedicated security server setup. The security functions of the software
are split into four main sections:
this also represents the fundamental hierarchy of the security system.
The basic security policy needs to be selected before users can be managed
and data access control can only be achieved by authorized users who are
known by the system.
Before any of the security functions of the software can be used, a
basic security policy needs to be selected. The user needs to select the
Security Module in the Security menu to start the
security setup. However, it is always possible to postpone the initial
security setup or change the security settings later on. The software
distinguishes three different security policy scenarios:
Security Policy (default setting)
Software' Security Policy
Windows' Security Policy
No Security Policy
The 'No Security Policy' is the default setting of the software. All
security functions are completely disabled when using this policy and
the software acts just as a regular application with all functions available
which are provided by the individual license. A higher level of security
can always be chosen later on by selecting the command 'Setup Security
Module' in the Security Menu.
By Software Security Policy
When using the 'By Software Security Policy', all security settings
are managed by the application itself. This policy is suitable for standalone
setups. Initially an Administrator User needs to be chosen, who will then
manage all users and data access control settings for the application.
The Administrator User is intended for managing purposes only and is not
supposed to be a regular user of the application. Consequently the administrator
permission scheme only unlocks the managing and security functions of
the software. Switching to other security policies is possible and the
software will retain the settings made previously. Therefore, when returning
to this policy it is possible to restore the previous user settings.
By Windows Security Policy
The 'By Windows Security Policy' seamless links to the security settings
of the Windows Operating System the application is running on. To be able
to use the software, the user needs to have a valid windows user account.
All users that have access to the local computer can be added as users
for the application. A list of all available users will be retrieved from
the operating system or from a LDAP-server of the IT-infrastructure and
selected users can be added to the application by the Administrator User.
As with the 'By Software Policy', the first user that runs the security
setup will be the added as Administrator User who will then manage all
users and data access control settings for the application. Switching
to other security policies is possible and the software will retain the
settings made previously. Therefore, when returning to this policy it
is possible to restore the previous user settings.
The first user that logs in after the initial security policy selection
will always be an Administrator User. The Administrator User is responsible
for managing all users of the application, for assigning Permission Schemes,
managing Data Access Roles and assigning Signature Roles. The administrator
account should only be used for managing purposes and not for regular
use of the application.
The user management for both available security policies is very similar.
When using the 'By Software Security Policy', the administrator has full
control over the users. He can create new users, assign a user name and
password and can control password details. In case of the 'By Windows
Security Policy' those details are handled by the operating systems security
functions. Instead the administrator is presented with a list of all users
authorized to use the local windows system and he is able to grant access
to the application for designated users from this list. Once a user is
authorized to use the application, detailed access rights can be assigned.
These may range from a simple "guest user" with no access to
menu functions and data, up to a "supervisor user" will full
access to data and software functions. Access to software functions is
managed by Permission Schemes, data access is controlled by Signature
Roles. Please refer to the chapter User Management for further
Data access control is accomplished by defining a data access hierarchy
with a certain number of levels and utilizing so called signature roles.
The default hierarchy consists of four levels: Guest, Operator, Chemist
and Supervisor. Each level consists of a number access rules which are
combined in the signature role. The overall number of levels and specific
access rules can be customized to fit the individual working environment.
The general access rights for each level are read, write, copy and delete,
which can be assigned to spectra, projects and calibrations. Users assigned
to the lowest level (e.g. "Guest") will only have very limited
rights, whereas users of the highest level will be granted unlimited access.
This reflects a general workflow from lower levels to higher levels of
the hierarchy, for example: The operator records a spectrum, the chemist
checks and edits the spectrum and creates calibrations, and the supervisor
manages the complete workflow and may delete any data. Please refer to
the chapter Data Access Control for detailed description.
Apart from the main security features additional functions to control
the application and data are available. All actions that occur when using
the application can be logged by activating the Activity/Event Log. Logged
events will be written to a dedicated log file and/or the operating systems
To prevent unauthorized users from accessing the software, the application
lockout feature can be activated. This allows the operator to manually
lock the software when leaving the workstation unattended. Alternatively
a lockout time interval can be defined, which will automatically lock
the application after a defined time of inactivity.
If Object versioning is activated an unmodified copy of the original data
will always be kept when applying changes to an object. This
makes it possible to reconstruct all modifications that were applied to
a data object.