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 29/11/2013

Cloud Control Security: Role-based access control

Cloud control

Role-based access control (RBAC) makes for easy management, protection and adoption of Cloud Control.

Essentially Cloud 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 Role-based access control, define some functional fields/roles that might need access to Cloud Control. For these fields/roles create a role and a Privilege Propagation Group.

RBAC Cloud Control

To illustrate role-based access control in Enterprise Manager Cloud Control, let’s implement access for developers to all targets in the developement lifecycle.

We need to create TWO groups:

  • Administration group for aggregating targets based on one or more properties. Target membership is dynamic based on the properties of targets. Working with administration groups will be covered more detailed in a separate blog.
  • Privilege Propagation group (PPG) for implementing privilege propagating on the connected targets

cc_ppg_cr_administartion_group

I already created a hierarchy based on the Lifecycle Status property.

cc_ppg_administartion_group_hierarchy

Next create the Privilege propagation group.

cc_ppg_menu_create_group

cc_ppg_cr_group_add_targets

Add the targets needed in the group. Here we select the relevant Administartion group. Make sure you enable Privilege Propagation.

That’s all we need to do for the groups.

Next we need to create two roles.

  • role for connecting the Privilege propagation group and the needed resource privileges.
  • role for grouping accounts (like our fine developers)

Go to setup > Security > Roles

cc_ppg_menu_roles

Create the role to host the resource privileges.

c-ppg_cr_role_resource_privs

Add the Privilege Propagation Group.

cc_ppg_cr_role_privs_add_PPG_group

Define the resource privileges you want enabled through this role. In this case I want to add Application Performance Managent (APM) and JVM Diagnostics privileges.

cc_ppg_cr_role_resource_privs

When clicking the pencil you can specifically select the needed privileges.

cc_ppg_cr_role_resource_privs_grant_JVMD

You can skip the Roles and Administrators part.

Next create the users role.

cc_ppg_cr_role_props

Link the role with the targets and privileges to the user role.

cc_ppg_add_resprivs_role

Add all ‘administrator’ accounts of the developers. Don’t add any targets or resource privileges.

cc_ppg_add_dev_to_role

Now developers can access only those targets defined in the administration group with the applied privileges. When new developers are added to the user role, they will automatically inherent the privileges of all other developers.

Overzicht blogs

Geen reacties

Geef jouw mening

Reactie plaatsen

Reactie toevoegen

Jouw e-mailadres wordt niet openbaar gemaakt.

Geen HTML

  • 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!