Best practices for creating authorization policies

IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Administrator's Guide > Use role-based authorization policies > Policy management scenarios
IBM Tivoli Monitoring, Version 6.3 Fix Pack 2

Best practices for creating authorization policies

Review the best practices for creating authorization policies in your environment.
Grant permissions to managed system groups rather than to individual managed systems.
This approach has the advantage that authorization policy updates are not required when managed systems are added to your environment. Instead you add a new managed system to a managed system group that has already been granted view permission, and that contains similar systems using the same set of situation definitions or historical collection definitions. For new managed systems, you only need to create a new authorization policy in these scenarios:

There is not an existing managed system group that the managed system can be added to. In this case, add a new managed system group that contains the new managed system. Then grant view permission for the managed system group to one or more roles.

Create an exclude permission for the managed system because it should not be accessed by users who have been granted view permission for managed system groups that contain the new managed system.

Assign user groups to roles rather than assigning individual users to roles.
When you follow this approach, authorization policy updates are not required when there is a new dashboard user. Instead you add the new user to a user group in LDAP that has already been assigned to an authorization policy role matching the new user's job function.
Create a new authorization policy for a new user if there is not an existing user group that the user can be added to. In this case, add a new user group in LDAP, add the new user to the group, and assign the group to one or more authorization policy roles. If necessary, create a new role that matches the new user group's permission scope.

Create a user group in LDAP for your authorization policy administrators and assign the user group to a role that has been granted permission to create, modify, delete, and view roles. The predefined RoleAdministrator role has these permissions. Also ensure that multiple users are members of the user group so that authorization updates can be made by more than one user.
If you want your dashboard users to see monitoring data and situation events for resources, then create roles that grant permission to view monitoring data (attribute groups), and to view situation events for the resources that they can work with.
Only grant permission to view events but not monitoring data and vice versa for those users who need more restrictive access.
When you grant a user group (or user) permission to view attribute groups and events, grant view permission for both object types against the same resource type (either managed system group or managed system).
Exemplary best practice: Grant permission to view events and attribute groups for managed system group resources.
tivcmd grant --rolename "West Coast Administrators" --resourcetype 
managedsystemgroup --resources "West_Coast_Systems" --objecttype 
attributegroup --operations view 
tivcmd CLI> grant --rolename "West Coast Administrators" --resourcetype 
managedsystemgroup --resources "West_Coast_Systems" --objecttype event 
--operations view
Best practice variation: Grant permission to view events and attribute groups to a managed system.
tivcmd grant --rolename "West Coast Administrators" --resourcetype 
managedsystem --resources "Primary:server1:NT" --objecttype 
attributegroup --operations view 
tivcmd CLI> grant --rolename "West Coast Administrators" --resourcetype 
managedsystem --resources "Primary:server1:NT" --objecttype event 
--operations view
Example of a policy that does not meet the best practice criteria:
tivcmd grant --rolename "West Coast Administrators" --resourcetype 
managedsystemgroup --resources "West_Coast_Systems" --objecttype 
attributegroup --operations view 
tivcmd CLI> grant --rolename "West Coast Administrators" --resourcetype 
managedsystem --resources "Primary:server1:NT" --objecttype event 
--operations view 
where, Primary:server1:NT is a member of the West_Coast_Systems managed system group
Example of a policy that does not meet the best practice criteria:
tivcmd grant --rolename "West Coast Administrators" --resourcetype 
managedsystem --resources "Primary:server1:NT" --objecttype 
attributegroup --operations view 
tivcmd CLI> grant --rolename "West Coast Administrators" --resourcetype 
managedsystemgroup --resources "West_Coast_Systems" --objecttype event 
--operations view
where, Primary:server1:NT is a member of the West_Coast_Systems managed system group
Additional best practices and considerations specific to the Infrastructure Management Dashboards for Servers application:

If you want dashboard users to use the Managed System Groups page, they must be assigned a role that grants permission to view events or attribute groups or both for managed system groups. If a user is assigned to roles that only have view permission for one or more managed systems, they will not see any monitored resources on the Managed System Groups page.

If you want dashboard users to use the Situation Events page, they must be assigned a role that grants permission to view events for managed system groups (best practice) or individual managed systems. If you want the user to see the monitoring data that caused the situation event to be opened, the user must also be assigned to a role that grants permission to view attribute groups for managed system groups (best practice) or individual managed systems.
Parent topic:
Policy management scenarios

+
Search Tips | Advanced Search