Centrify Access and Privilege Management
Privileged Access Management and Privileged Identity Management (PAM and PIM) are a recurent subject of attention in IT department in any modern company. There is so may threat of hacking or data leaks now days that this topic took an important place in the security landscape.
I already covered in the first part of this article how Centrify RBAC is articulate: Roles and Rights canbe created and then applied using Role Assignments and AD Groups. Now let me talk about few Roles and Rights example and Centrify features that can help address common use case scenarios of Access Control and Privilege Management.
Simple Privilege Elevation
In UNIX and Linux world, privilege elevation is mainly provided by the usage of sudo that, using Centrify, can be supplented by DirectAuthorize equivalent dzdo. Main difference being that dzdo get the policies settings from Active Directory via the Roles and Rights stored in Centrify Zones, where sudo get the policies settings from a flat files named /etc/sudoers. In any other considerations dzdo is working exactly the same way as sudo and when a company was already using sudo to control privileges elevation it is very common to translate those policies into DirectAuthorize Roles.
Let's have as example two simple commands definition allowing to restart the httpd service on a system, and edit the /etc/httpd/httpd.conf file, which both require privilege elevation. Note that the service control can be written using a single command definition as Centrify support regular expressions for Rights definitions (this particular commands reads, run service https start or stop or restart or status).
At this point, and for each command definition, the user can be asked to re-authenticate using his AD Password, the target user password (root in this example) or ask for Multi-Factor Authentication (MFA) using the Centrify Identity Services suite.
Then by adding these two commands to a Role named WebAdmin, any AD Users that will login on a system where the Role is assigned to him will be able to run those commands through dzdo command.
High Privilege Elevation and Shared Accounts access
Another very common privilege elevation is to provide a User with full root access on a system, still not requiring for him to logon as root or to even have to know root credentials. Allowing the user to su to root or run any command as root is a common practice often seen on Linux distribs. This is also a setup that is easy to deploy in enterprise for high privilege roles like the System Administrators.
A command Right named dzdo-all is setup to allow any commands run from any location to be run as root. A good practice is to require AD User to re-autenticate for such command Right.
Another common practice, is to use the su command through privilege elevation to get access to Shared Accounts without to have to know the account credentials. Indeed by allowing access to another identity using su does not even require to set a password for this account, preventing anybody except someone with root privilege to switch to this account.
A command Right named dzdo-su-oracle can allow a user that have a Role with this command associated to swith to the Shared Account without knowing the target account password. Depending of the level of privilege you associate to this Shared Account, it is a best practice to require the AD User to re-authenticate or even to require Multi-Factor Authentication.
Next article in this serie will go through several exemples of Roles and Rights on Windows systems.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.