This series of articles will walk you through some real-life examples of how Centrify Role-Based Access Control (RBAC) can help get better control of your Identity Access and Privilege management.
This first article is presenting few examples of the three possible scopes for Role Assignments.
Centrify Role-Based Access Control (RBAC)
Centrify Server Suite is providing an efficient Identity Access control and Privilege management based on Active Directory Groups. Thanks to DirectAuthorize you can control access and privilege elevation on Windows servers but also on UNIX/Linux by integrating them to Active Directory using DirectControl (agent-based AD bridging).
Deploying Centrify agents on Windows and non-Windows is a rather easy task, migrating UNIX namespace identites is also not so complex as the Centrify Zone technology and the Zone Provisioning Agent can help you rationalise those identities (see other posts on those subject on this Community forum). But when come to control Access and Privileges, the main difficulty is that nobody has a clue of what Roles they already have or which one they should create.
Professional Services came up with several best-practices and recomendations based on field experience harvested in the last 10 years of Centrify deployment in companies of all size and from all business. Indeed, there is recurent Roles and needs that are shared by a lot of IT department.
Centrify Roles and Rights
Centrify Roles and Rights can be defined at Zone level to control Access (via Roles) and Privileges (via Rights). There is few Roles predefined when you create a Zone, the most commonly used are "UNIX Login" and "Windows Login" that can help setup simple Access control.
Windows Rights and UNIX Rights can be setup to elevate privileges, I will show few examples in this article and also come back to this in more details in follow-up articles.
Centrify Role Assignments
Creating Roles serve nothing until they are assigned to Users directly or via AD Groups. A Role is assigned by creating a Role Assignement that associate a Role to preferably an AD Group (unless this is a Role made for a Service Account) and that can be temporary or permanent (by setting starting and ending date).
Finally a Role Assignment as a scope, where this Role will be effecitve. There is three possible kind of scopes that can be defined by creating Role Assignments at:
- Zone level
- Computer level
- Computer Role level
Let's visit real-life exemples of different Role Assignments and what scope serves them best.
Role Assignments at Zone level
When a Role Assignment is made with the scope of a Zone, it become effective for every Computer joined to this Zone and also every Computers joined to every Child Zones of this Zones. So if created on the Zone parent of the hierarchy, it become a Global Role Assignments effective on every Computers.
There is few different reasons of setting such Role Assignments, recomendation is to use them for Roles that should be effective on a large numbers of Computers if not all of them.
The Role "UNIX Admin" defined in the Zone GLOBAL is assigned on the top parent Zone, which make it effective on every joined computers and then answer the simple statement: every UNIX Admin should have access to all servers.
If there is a need to specifiy different rules in between the production and test servers, then the Role Assignment could be instead created at child Zone level (as in this example the child Zones differenciate production from non-production servers).
This type of assignments is perfect for global access rules: e.g. SysAdmins team, Support team, OS specific Role.
Role Assignments at Computer level
When a Role Assignment is made with the scope of a Computer, it become effective for this and only this Computer.
There is few different reasons of setting such Role Assignments, recomendation is to use them for Roles that should be effective on a single Computers or on a temporary basis and then giving the most fine-grained granularity of access control.
The Role "TPA Root" defined in the Zone GLOBAL is assigned on the Computer engcen5 member of the child Zone PROD, which make it effective only onto this computer.
This Role is defined as Temporary Privileged Access (TPA) Role, idea of this being that this Role would be asisgn to users that need to be granted Root access on a particular server for a limited amount of time. I will come back in details on those TPA Roles in the following part of this serie of articles.
This type of assignments is perfect for temporary and/or localised access rules: e.g. incident ticket on a given computer, contractor access on a computer for limited time, Service Account for an Application existing on very localised computers.
Role Assignments at Computer Role level
When a Role Assignment is made with the scope of a Computer Role, it become effective for all the Computers that are member of this Computer Role. When creating a Computer Role, this one is always associated with an AD Group. Computers that are Members of this AD Group are members of the associated Computer Role.
There is few different reasons of setting such Role Assignments, recomendation is to use them for Roles that should be effective on a group of Computers to apply consistant access control rules. This is also useful to apply different variation of Roles depending of the targeted Computers.
The Role "Application Developer", "Application User" and "Application Admin" defined in the Zone PRD are assigned on the Computer Role "Application", which make it effective on every joined computers members of this Computer Role.
This type of assignments is perfect for consistancy in your access rules: e.g. Application access control, OS specific Role.
Next article in this serie will go through several exemples of Roles and Rights and how they can answer various IT security rules in real life examples.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.