T315-24 Security - RevC PDF

System 800xA Training
Chapter 24 Security
TABLE OF CONTENTS
Chapter 24 Security ....................................................................................................................................................................... 1
24.1 General Information........................................................................................................................................................... 2
24.1.1 Objectives ................................................................................................................................................................... 2
24.1.2 Legend ........................................................................................................................................................................ 2
24.1.3 Reference Documentation........................................................................................................................................... 2
24.2 Overview ........................................................................................................................................................................... 3
24.2.1 Domain versus Workgroup ......................................................................................................................................... 3
24.2.2 800xA Security Model................................................................................................................................................ 4
24.3 Windows Security.............................................................................................................................................................. 5
24.3.1 Group Policy............................................................................................................................................................... 5
24.3.2 Organizational Units ................................................................................................................................................... 6
24.3.3 Windows Security Groups .......................................................................................................................................... 6
24.3.4 Default Windows Security Groups ............................................................................................................................. 7
24.4 System 800xA User Handling ........................................................................................................................................... 8
24.4.1 Windows Groups and 800xA User Groups................................................................................................................. 8
24.4.2 Default 800xA User Groups ....................................................................................................................................... 9
24.4.3 Adding Individual Windows Users........................................................................................................................... 10
24.4.4 Associating Groups................................................................................................................................................... 11
24.5 User Roles........................................................................................................................................................................ 12
24.5.1 User Structure ........................................................................................................................................................... 12
24.5.2 Example Audit Lists ................................................................................................................................................. 13
24.5.3 Indexes Linked to User Roles ................................................................................................................................... 14
24.5.4 User Role Mapping................................................................................................................................................... 15
24.6 Permissions...................................................................................................................................................................... 16
24.6.1 Main Default Permissions......................................................................................................................................... 16
24.6.2 Operations Linked to Permissions ............................................................................................................................ 17
24.6.3 Required Permission Mapping.................................................................................................................................. 18
24.7 Security Definition Aspects ............................................................................................................................................. 19
24.7.1 Evaluation Order....................................................................................................................................................... 20
24.7.2 Changing Security Settings....................................................................................................................................... 21
24.7.3 Granted Permissions View........................................................................................................................................ 23
24.8 Log Over.......................................................................................................................................................................... 24
24.8.1 Overview and Operation ........................................................................................................................................... 24
24.8.2 Log Over Configuration............................................................................................................................................ 25
24.9 Security Reports............................................................................................................................................................... 26
24.9.1 How to Create a Report............................................................................................................................................. 27
Chapter 24 - 1
T315-24 Security - RevC
24.1 General Information

24.1.1 Objectives
On completion of this chapter you will be able to:
Explain the link between Windows and 800xA users
Configure new users
Associate Windows users to user groups in 800xA
Describe the function of roles and permissions
24.1.2 Legend
>
Indicates when you go from one menu to a sub-menu
Italic
Indicates object and file names
Indicates dialog box buttons, tabs, menus etc.
Bold
Indicates important topics

Indicates start/explanation of student activity
24.1.3 Reference Documentation
Chapter 24 - 2
3BSE037410
Industrial IT 800xA System

Administration and Security
3BSE036904
Industrial IT 800xA - System

Extended Operation
3BSE030322
Industrial IT 800xA Operations

Operator Workplace Configuration
3BSE034463

Automation System Network Design and Configuration
2PAA101888

Tools
24.2 Overview
Security configuration can be used to change what a particular user can do such as
gaining access to files, controlling a process, or configuring security itself. There are
also ways to control what can be seen in the 800xA application or even on the desktop
of a computer.
The first rule of security configuration is:
Dont make it any more complex than it needs to be to accomplish the needs of
the system!
24.2.1 Domain versus Workgroup

For a small system a workgroup can be an alternative to using a Windows domain.
Using a domain is the preferred way, because the user handling is done on a central
place and consistency can be better guaranteed.
In a workgroup environment, a user on each node is a local user. This means that users
need to be added and configured on each node separately. Even if users have the same
username and passwords on each node of the workgroup, there still can be local
differences concerning the windows security permissions and policies.
For a domain environment, the standard model is to have Users defined in the domain
controller. These Domain Users are added to Global Groups, which are only defined
on the domain controller. In a domain it does not matter on which node you login as a
domain user, you always get the same defined windows security permissions and
policy.
NOTE!
There are still local users on domain client nodes. When

adding users to 800xA in a domain environment make
sure that you choose the domain users, especially when
both local and domain users have the same name.
Chapter 24 - 3
24.2.2 800xA Security Model

The 800xA security model is based on extensions to Windows security model, adding
certain features and capabilities that allow products and systems built on the
architecture to comply with relevant regulatory requirements.
Security is a function of the system 800xA and no separate installation procedure is
necessary. Security checks in the Industrial IT 800xA System are based on the
Windows user identity.
The security is integrated into the Aspect system so that the accessibility of an object
is defined as an aspect of the object. Functions in the 800xA security model:
The operation the user wants to perform
The aspect object that the user wants to perform the operation on
The node where the user is logged in (e.g. close to the process equipment)
Audit trail
Authentication and Digital signature
Log over
Related to the security is the usage settings are user roles. Roles adapt the user
interface for different types of users, i.e. user groups. Some operations require an
application engineer or system engineer role to be performed.
NOTE!
User Roles define what you can SEE.
However, having the correct user role does not give the user the permission to perform
the operation. The permission is completely controlled by the security configuration of
the system.
NOTE!
Permissions define what you can DO.
To view an object, a user requires an 800xA role like Operator or Application

Engineer. To access, or manipulate an object a user requires an appropriate permission
added to his/her role. This appropriate permission can only be defined by a specific
Security Definition aspect and the identity of the Windows user.
Chapter 24 - 4
24.3 Windows Security

In Microsoft Windows security, a resource can have a permission allowed or denied,
or there may be no configuration regarding that particular permission. In the picture
below you see the permissions on the OperateITData folder for the member users of
the user group IndustrialITAdmin.
If there is no configuration anywhere for a particular permission, the default is not

allowed. Permissions are cumulative unless denied. For example if a user is in two
groups and one group grants a permission and the other does not, the user gets the sum
of the two groups and thus has the permission.
NOTE!
Deny overrides Allow.
For instance, if a user is a member of five user groups and four of them allow the
permission but in the fifth group this permission is set to deny, the permission for that
source is denied in the whole system (It is recommended to Not Allow a feature in
preference to a Deny).
24.3.1 Group Policy

Security configuration may involve more than removing permission; it may involve
removing the view.
In Windows 2003 domains, Group policies can be used effectively to control the
desktop of a user or a group of users. Items can also be removed from the Start Menu
so that a user can only interact with a particular application such as System 800xA.
Chapter 24 - 5
24.3.2 Organizational Units

Security for users and computers which are not part of a Windows domain is not as
easy to accomplish as setting security with a Domain environment.
NOTE!
Workgroup security will not be discussed in this course.
Organizational Units (called OUs) are objects created within the Windows Active
Directory to simplify a centralized security management.
Windows Group Policies can be applied to an OU to prevent or allow the members of

the group policy access to icons and programs on the desktop. It can also handle
access rights to services and log-on or log-off privileges.
24.3.3 Windows Security Groups

Windows Security Groups are used to grant permissions to similar types of users and
to simplify account administration. Thus, you can give a user access to various workrelated resources just by making the user a member of the correct group.
Chapter 24 - 6
24.3.4 Default Windows Security Groups

During installation of System 800xA, two Windows Global Groups are created.
IndustrialITUser
This group is intended to contain all the users of the system. Any user accounts
that are not in this group will not work in System 800xA.
IndustrialITAdmin
All users in this group have administrative privileges in System 800xA.
System 800xA refers to these groups in the Configuration Wizard under System
Software User Settings. The Configuration Wizard can be found under:
Start > Programs > ABB IndustrialIT 800xA > System >Configuration Wizard
One user account must be reserved for use by 800xA system services. This service
account will NOT be used for installation, administration, configuration, or any other
system-related procedures.
Chapter 24 - 7
24.4 System 800xA User Handling

24.4.1 Windows Groups and 800xA User Groups
The security system in 800xA is based on the Windows user accounts. The user must
be member of a Windows Group and an 800xA User Group.
800xA
Windows Environment
Group
Group
User account
(operator)
Group
User Group
User account
(engineer)
User Group
User Group
User account
(administrator)
Its recommended that the Windows Groups and 800xA User Groups tree structure
maps the plant roles and plant areas, as shown below.
In many cases there will be different operators for different parts of the process. They
may need access to only part of the controls and need to have restrictions for other
parts.
In this case, Windows Security Groups could be created such as IndITOperatorA and
IndITOperatorB or some other descriptive name. These Windows Groups can then be
mapped to 800xA User Groups such as OperatorsA and OperatorsB. That way,
different permissions could be given to each group.
Chapter 24 - 8
24.4.2 Default 800xA User Groups

The default 800xA Users Groups automatically appear in the User Structure.
Remember, by default these are only the internal 800xA groups not the Windows
groups. Under each group in the tree, any users in that group will appear.
Any Windows User can be added directly to an 800xA User Group.
Everyone (contains all System 800xA users)
Operators
Control the process and acknowledge alarms, but do not tune or configure
Application Engineers
Tunes the process and makes all application configurations
Administrators
A group with the security system disabled, i.e. a member of this group has full
access to everything.
System Engineers
Handles the physical configuration like server configurations, adding users, and
setting up security.
NOTE!
Users are automatically added to the 800xA User Group

Everyone.
New 800xA User Groups can be created in the User Structure as well. This would be
appropriate if there are several kinds of operators for example. Keep in mind the first
principle of security: Only make security configuration as complex as it needs to be to
do the job. Dont unnecessarily complicate it.
Chapter 24 - 9
24.4.3 Adding Individual Windows Users

Windows users can be added or removed to the 800xA User Groups using the
Configuration Wizard.
NOTE!
The user accounts must exist in the Windows security

first and must be member of the IndustrialITUser group.
1. Start the Configuration Wizard, select System Administration and click Next.
2. Select Users and click Next.
3. Click Add Windows Account. Select the desired user/users (one at a time)
and click Add.
4. Then assign the user to one or more of the 800xA User Groups.
Chapter 24 - 10
24.4.4 Associating Groups

In addition, Windows Groups can be associated with 800xA User Groups so that
every user added to the Windows Group automatically is added to the 800xA system
with the appropriate set of rights.
NOTE!
This is the best option for most systems.
The properties of the 800xA Users groups can be set by clicking on the group and
selecting the User Group Definition aspect. On the User Group Configuration tab,
the 800xA User group can be associated with a Windows Group.
NOTE!
Ensure that there is at least one Administration User

account who is a member of all the 800xA User Groups.
Once the Windows and 800xA user groups are associated, new Windows users can be
added to the Windows Groups that have been associated. On the Members tab there
is a button to synchronize the groups, and this will cause the added Windows users to
show up in System 800xA without having to run the Configuration Wizard.
Chapter 24 - 11
24.5 User Roles

24.5.1 User Structure
The user role is used to adapt the user interface to work in a typical way for 800xA
User Groups. User roles affect what kind of objects or aspects a specific user can SEE.
For instance, configuration dialogs are removed from users with an Operator role.
By adding a Windows user to an 800xA User Group the user gains a user role which
was assigned to the User Group.
Occupying one of the default roles does not mean that the 800xA user unconditionally
has permission to perform a task:
Operator role
Application Engineer role
System Engineer Role

NOTE!
Permissions have nothing to do with the User Role.
Permissions are defined by the Security Definition aspects and Windows user identity
only.
Chapter 24 - 12
24.5.2 Example Audit Lists

For instance, lets look at who can look at audit lists.
A context menu for an audit list with an Operator login looks like this:
While the same context menu for the list under an Administrator account looks this
way:
The role a user has is set per User Group and defines what user interfaces he/she will
have.
Chapter 24 - 13
24.5.3 Indexes Linked to User Roles

Roles are assigned to categories of aspects or objects and define levels of operations
(indexes) on those categories.
To each Index its possible to select a User Role (creating a role map).
By assigning the roles to aspects in the Aspect System Structure, all aspects of a type
will inherit the same role bindings. By assigning the roles to objects in the Object
Type Structure, all instances of a type will inherit the same role bindings.
Role map
Default User Roles are:

Application Engineer
Operator
Software Developer
System Engineer
System Extension
User Role
User Role
Role map
Object Type
Aspect Category
Index 1
Index 1
User Role
User Role
Index 2
Index 2
User Role
User Role
Index n
Index n
User Role
User Role
Default Indexes are:

Read
Modify
Create
Config View
Operate
User Group
User Group
User
Maintenance Aspect
Mr X
Mr. X logs on as a user and gets user roles from the 800xA User Groups.
If we examine the role definitions for existing aspects we can view (and modify) what
capabilities each role provides for that aspect. Granted user roles are checked against
the role map.
Chapter 24 - 14
24.5.4 User Role Mapping

The connection between indexes and needed user roles is done in the Aspect Category
Definition aspect. Select the User Role Bindings tab to see and modify the default
settings.
Aspect Category Definition aspect
Aspect Category or
Object Type
A blank in the user role column indicates that all roles can do the operation. If Read
rights were removed we would not even be able to see the aspect when logged in as a
user with that role.
NOTE!
To be able to modify an object type in the AC 800M

Connect, the library has to be open.
Chapter 24 - 15
24.6 Permissions
Permissions, on the other hand, are defined for aspect objects and grants certain
permissions (such as read, operate, configure) to a user. This in effect, defines what a
user can DO to an object.
A user or group is allowed or denied access to an object based on the Granted
Permission compared to the Required Permission:
Required permission
Required permission is given per Aspect Category, and defines the permission
necessary to perform an operation like Read or Modify of aspects in the category.
Granted permission
Defines the permission for a user or group on the complete system, on a structure
or on an object.
24.6.1 Main Default Permissions

Read
Permits a user to read information.
Configure
Permits a user to configure an aspect.
Operate
Permits a user to operate the system. Normally given to the

Operator Group.
Tune
Permits a user to tune a process.
Shutdown
Permits a user to shutdown an area. Not used in the default

setting.
Security Configure Permits a user to change/add permission on objects.

Administrate
Permits a user to do administration of the Aspect System itself,

for example add new 800xA users.
There may be additional permissions depending on the installed system extensions.
Chapter 24 - 16
24.6.2 Operations Linked to Permissions

Operations define levels of operations on the object, aspect or OPC property.
To each Operation its possible to select a Permission, which will create then a
required permission map. Granted permissions are checked against the permission
map.
Chapter 24 - 17
24.6.3 Required Permission Mapping

The required permission is configured for an object in a similar way as was the role
definitions. The required permissions are set on the Permissions tab of the Aspect
Category Definition aspect.
Aspect Category Definition aspect
Aspect Category or
Object Type
To acknowledge an
alarm, an OPERATE
permission is required
For an OPC server the required permission for is set per property. Set Read/Write
permissions in the Control Module, Function Block or Control Connection aspect.
Chapter 24 - 18
24.7 Security Definition Aspects

Security settings are customized by adding and setting Security Definition aspects to
objects. System 800xA has a default Security Definition aspect defined in the Admin
Structure which is usually suitable for most installation needs.
You can add a Security Definition aspect to almost any other object in the system. But
remember to keep security as simple as possible. For this reason it would usually not
be a good idea to place a Security Definition aspect on every object. It would make
more sense to place the security on the unit or equipment for which an operator has
authority and let all objects in the unit or equipment inherit that security.
NOTE!
Several Security Definition aspects can define the

security for the same object.
In the tab Permissions are the default permissions specified for the entire system:
Permission what can they do?
Access can they do it (denied / allowed)?
User or Group who can do it?
Node where can they do it?
Chapter 24 - 19
24.7.1 Evaluation Order

The default Security Definition aspect in the Admin Structure, unlike Security
Definition aspects instantiated elsewhere in Plant Explorer, has an additional tab
Evaluation Order. It sets the search order for the default as well as all other Security
Definition aspects in the system.
A Security Definition aspect, by default, applies to every object below it in the tree. If
no Security Definition aspect exists for an object, the parent objects will be checked
and so on up the tree. If no security definition is found for the object or a parent
object, the default Security Definition aspect is applied.
Milko Chemical
Solid Processing
Liquid Processing
Security Definition Aspect
Mixing Unit BV1

Mixing Unit BV2
BV2TemperatureControl
BV2QuantityControl
BV2ProductTransfer
BV2Agitation
BV2MilkSupply
FIC201
FIC201Valve
FIC201FlowTransmitter
FIC201Control
Chapter 24 - 20
24.7.2 Changing Security Settings

Select the default Security Definition aspect or a Security Definition aspect on any
object for which you want to define security.
The security is set by changing the following elements of a Security Definition aspect:
Permissions
Authority Range
Search Option
Double-click on the user or add a new permission configuration. This will open a
Permissions dialog in which you can define the various permissions to be associated
with that object.
Select the operations which you want to grant or deny access. Select then which
800xA Users or Groups to which the permission will apply. Finally, select which
specific node, if any, the operator must be logged on to for the security definition to
apply.
In this example, OperatorX had been allowed to operate the object Production_Plant
from all the nodes.
Chapter 24 - 21
Next you should define the Authority Range from the list:
Object - valid for this object.
Structure - valid for this object and down in the structure.
None - security definition aspect disabled
When an object is accessed by a user, and the Search Order is set to Continue
Search, the system goes into every structure where the object is present. The search
will go on according to the order in the Evaluation Search Order (as defined in the
default Security Definition aspect) list from top to bottom.
When a Security Definition aspect is found that gives security information about the
user, the search stops and the permissions configuration for that user is applied.
Chapter 24 - 22
24.7.3 Granted Permissions View

When making the security configuration in a system it might be convenient to see how
the security for an object is set for a specific user or user group.
Right click on the object and select Properties from the context menu. Click on the
Change user button.
Select the User Group and optionally the individual user (member).
The result is shown for the user or user group:
Chapter 24 - 23
24.8 Log Over

The log over function enables a fast and temporary switch between users in a running
Workplace. For example if an operation requires a permission not held by an operator,
another user (e.g. a system engineer) that holds the required permission, can log on to
perform that operation.
24.8.1 Overview and Operation

The log over changes the permissions and user roles but keeps all open windows with
their present contents. The permitted actions in the open windows are controlled by
the permissions of the logged over user.
Right click on the user in the Operator Workplace and select Change User
Type the username and password, click OK.
NOTE!
The log over only affects the System permission.
Windows security is still the same as the user logged in. This means that
the access to files is still controlled by the user logged in.
To return to the first user right-click on the user name again and select Revert To...
The revert user operation requires authentication in order to change back to the
original user.
Chapter 24 - 24
24.8.2 Log Over Configuration

To enable the logover functionality, follow the steps below:
1. Open the Admin Structure in the Plant Explorer and expand Administrative
Objects.
2. Expand Domains and select the object with the name you gave to your system.
By default this is <server node name> System.
3. Select the Logover Settings aspect in the aspect list.
4. Check Enable Logover.
It is also possible to configure an inactive user, who is a user that the system
automatically will revert to after a certain amount of inactive time. This could be a
user with limited permission (read only).
Select which user should be the inactive user and enter the password. Set the time for
automatic revert to inactive user in the Revert to Inactivity field.
Chapter 24 - 25
24.9 Security Reports

There are several things that we can do to verify our security settings. It is very
important to do this after making any security changes to determine whether there
were any unintended results.
Since the default Security Definition aspect is always used whenever another
definition does not apply, we should always check to make sure that it is set the way
we want it to be.
If we have a more complex need for access to controls, and we have configured
additional Security Definition aspects, it will be necessary to check the permissions of
an object in each structure. We also have to be aware that parent objects affect the
determination of rights. This evaluation can be complex and time consuming.
NOTE!
Fortunately we can generate a Security Report that

brings together all the security definitions in one place.
By evaluating this report, we can assess whether or not we have conflicts. This report
also provides a way of entering our security configuration again if it is lost. The
Security report can be printed, but we can also select all the text and copy it to Word,
Wordpad or some other text editor. This would allow us to do searches on an object
name and find all the instances to compare the security settings.
Chapter 24 - 26
24.9.1 How to Create a Report

In the system you will find a Security Report aspect. If this aspect cannot be found,
add it anywhere, although it makes most sense to add it to the Domain object in the
Admin Structure. No matter where it is added it reports the entire system.
Use this aspect to get a printed report showing the security settings of the system and
to compare a new security report with an old one so that changes in the security
settings of the system can be seen.
To add a Security Report aspect, follow the steps below:

1. Add a Security Report aspect to any object in any structure.
2. Press the Update button to get an updated security report.
3. Click the Print button to get the security report printed.
Chapter 24 - 27

T315-24 Security - RevC PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

T315-24 Security - RevC PDF

Загружено:

Авторское право:

Доступные форматы

System 800xA Training