Follow Us on Twitter

Role-based access control in Grid Control

by Tony van Esch on September 14, 2012 · 0 comments

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.

 

Role-based access control in Grid Control, 5.0 out of 5 based on 2 ratings
Ratings:
VN:F [1.9.22_1171]
Rating: 5.0/5 (2 votes cast)
Tags: , ,

Leave a Reply

Your email address will not be published. Required fields are marked *

*

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

 

Previous post:

Next post:

About Whitehorses
Company profile
Services
Technology

Whitehorses website

Home page
Whitebooks
Jobs

Follow us
Blog post RSS
Comment RSS
Twitter