Role-based access control in Grid Control

Role-based access control (RBAC) makes for easy management, protection and adoption of Grid control. This way not only administrators should be able to get access.

Essentially Grid control is used by administrators to manage and monitor targets in the infrastructure. There are however some interesting views that can benefit other roles (eg: developers, Business Analysts, managers). From a security perspective there are a number of practical things to consider when implementing and rolling out RBAC.

• Use roles (never individual granted privileges)
• Least privilege principle (protection, resposibilities)
• Use Privilege Propagation Groups (easy of administration)
• Audit grants

To be able to configure RBAC, define some functional fields/roles that might need access to Grid control. For these fields/roles create a role and a Privilege Propagation Group.

To illustrate RBAC in grid control, let’s implement access for Developers to Grid Control, so they can view performance pages of databases in the development cycle (dev,test,QA etcetera)

Creating the Privilege Propagation Group (PPG): Targets > groups > select PPG and Go .

Add the targets needed in the group. In this case we added all database instances in the development cycle, except production.

Create a role that will be the placeholder for the PPG and its privileges.

Roles: Add additional roles when necessary (not in our case)
System Privs: None
Target Privileges: Add the PPG group > add > target type group > select. The privilege defaults to ‘View’.

Administrators (accounts): Now you can add accounts to the role and finish the wizard.

Create an account that belongs to the Development group. The account will only receive the privileges and access to targets via the previously create role.
Select setup > Administrators

Next fill in the neccessary properties. Make sure you add the correct profile. This will introduce at least a minimal password policy.

Give the account the previously created role DEV_ROLE.

System privileges: none
Target privileges: none

Now the account has view privileges on the targets (database instances and the platform it is running on) in Grid Control. But users still cannot access the performance pages in a database instance.

A database account is needed to view among others performance pages. This should preferrably be a personal account.

create user devops identified by devops;
create role devops_role;
grant oem_monitor to devops_role;
grant devops_role to devops;

Now our devops user can view database performance metrics.

If you want the users to be able to schedule tuning advisors aswell, grant the OEM_ADVISOR role to the devops_role role.