Role strategy and role authorizations

One major part of the security strategy is the role strategy which incorporates the following features:

• The roles are graduated:
  Only the necessary interfaces and functions are available to each role.

• Each user account is permanently assigned to a role.

• No rights escalation is possible, i.e. no access (or transition) is possible to interfaces and functions other than those envisaged. In particular, no access is possible to the root account of the base operating system.

• Roles
  The following roles are defined for users:

  • Administrator

  • BS2000 administrator

  • Operator

  • XenVM administrator

  • AU administrator

  • Service

  The administrator role is higher ranking than the BS2000 administrator, operator, XenVM administrator and AU administrator roles and is authorized to execute all functions of the SE Manager and of the recommended CLI.

  The service role is reserved exclusively for Customer Support.

  The BS2000 administrator, operator, XenVM administrator and AU administrator roles have restricted rights which are tailored to their different task areas:

  • A BS2000 administrator only has the authorization for functions of the SE Manager which are necessary to operate BS2000 systems. In addition, he/she also has some administrator authorizations: switching the units SU, MU and HNC on/off, performing a CSR backup, creating diagnostic data, accessing the shadow terminal, read access to the hardware inventory, and configuration of scheduled power on/off of the units SU, MU and HNC.

  • An operator only has the authorization for functions of the SE Manager which are necessary to operate BS2000 systems. The administrator can also configure specific authorizations individually for an operator account.

  • A XenVM administrator only has the authorization for functions of the SE Manager which are necessary to operate XenVM systems.

  • An AU administrator only has the authorization for functions of the SE Manager which are necessary to operate the systems on AUs. In addition, he/she also has some administrator authorizations: switching the AUs on/off, read access to the hardware inventory, and configuration of scheduled power on/off of the AUs.

  Overviews of the role-specific tasks and functions are provided in the “Operation and Administration” manual [2] and in the online help.

• Individual rights

  The administrator can grant and deny rights for certain functions of the SE Manager to an operator account. A distinction is made here between server-related and system-related rights.

  The authorizations below are server-related rights:

  • On/Off
    Displays whether the operator has the right to power Units on/off (Granted or Denied).
    If the right exists, the operator can power all units which are displayed in the unit overview on or off in an emergency.

  • Shadow
    Shows whether the operator is entitled to access the shadow terminal (access Granted or Denied to the Customer Support staff).

  • SVP
    Only on SE servers with SU /390:
    Shows whether the operator has the SVP right (e.g. IPL and shutdown Granted or Denied).

  The rights below are system-related rights:

  • Unit
    Unit for which system-related rights, more precisely console rights, are assigned. The access rights to BS2000 systems of an SU /390 are entered for the Management Unit, the BCAM name of the SU /390 being displayed after them in parentheses. The access rights to BS2000 systems of an SU x86 are entered for the SU x86 concerned.

  • Console rights
    Shows the systems for which the operator has console access authorization. The permitted systems are entered explicitly with KVP and console MN.

  • Dialog
    Shows whether the operator has the right for BS2000 dialog access (access Granted or Denied). This right can only be assigned if at least one console right is entered.

  Security-relevant actions An operator can release or lock the following functions of the SE Manager for operating (see main menu Authorizations -> Users -> Individual rights ):

  • Powering on/off units

  • Access to a shadow terminal

  • Access to the SVP (SE Server with SU /390 only)

  • Access to a BS2000 console on a particular BS2000 system

  • Access to the BS2000 dialog on a particular BS2000 system

  When two SUs form an SU cluster, a Live Migration (LM) of BS2000 systems from one SU to another is possible. For BS2000 systems, the individual authorizations for accessing the BS2000 dialog and the BS2000 console should be identical on each SU of the SU cluster. If not, the originally intended access rights will change when a BS2000 system is migrated!