icon-arrow icon-check icon-mail icon-phone icon-facebook icon-linkedin icon-youtube icon-twitter icon-cheveron icon-download icon-instagram play close close icon-arrow-uturn icon-calendar icon-clock icon-search icon-chevron-process icon-skills icon-knowledge icon-kite icon-education icon-languages icon-tools icon-experience icon-coffee-cup
Werken bij Integration & Application Talents
Blog 14/09/2012

Role-based access control in Grid Control

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.

Role Based access controle

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.

Overzicht blogs

Geen reacties

Geef jouw mening

Reactie plaatsen

Reactie toevoegen

Jouw e-mailadres wordt niet openbaar gemaakt.


  • Geen HTML toegestaan.
  • Regels en alinea's worden automatisch gesplitst.
  • Web- en e-mailadressen worden automatisch naar links omgezet.

Wil je deel uitmaken van een groep gedreven en ambitieuze experts? Stuur ons jouw cv!