Security Corner: Establishing an Identity and Access Governance Model for UNIX/Linux with Centrify and Active Directory - Part 1

Background

An Identity and Access governance model establishes how end users will access your systems, this entails

• Establishing the rules of who should have access to which system
• Establishing what functions (or privileges) they're allowed to perform or use
• Establish the provisioning process (Add/Moves/Changes)

But first, a quick refresher:

Provisioning

As defined by the dictionary, provisioning  means to provide, the reverse is to withdraw or to deprovision.  

In Identity Management, provisioning may mean User provisioning into different systems from an authoritative source.  User provisioning as per Gartner is a whole IT capability (and a source of much confusion)

In the context Identity and Access Management with Centrify for UNIX, the authoritative source is Active Directory;  regardless of how the Active Directory user is provisioned (manually, with an Identity Management solution like Oracle, Courion or Sailpoint, or with other tools) UNIX identity provisioning in AD can be performed in different ways.  With Centrify, the preferred method is with a SCP that contains the user's identity (created manually via Access Manager, or automatically with the ZPA).  

Fortunately, Centrify makes the integration very easy.  It's all about placing users in a security group in AD.

As a refresher, for an AD user to have access to UNIX system in a Centrify Zone, they need two things:

• A user Identity
• A role that allows the right to log in

Therefore, both identities and roles can be granted (provisioned) and removed (deprovisioned).  Centrify implements an RBAC model for UNIX that grants Access and Privileges.

The group nesting feature of AD can be leveraged
to provide Identity and Access with automation.

Access

In a properly managed enterprise, not everyone has access to all systems, and with Centrify you can implement virtually any governance model.  The design ideally is as flat as possible, with a single hierarchical zone and computer roles as the way to establish a governance model.  For example, in our lab we have a simple Access Model:

• Web Servers can be accessed by super users and web administrators
• Database Servers can be accessed by super users and DBAs
• Filers can be accessed by super users, and all UNIX users are listed in the system.

This model works great for our example, but we know that the real world is different.  The guideline is to try to enforce the least access principle.

In Centrify,  access is granted by direct assignment or by making a user a member of an AD group that has been granted the assignment (role granting group), the rest implies to manage the server memberships.

For example:  when a new web server is provisioned, it's dropped into the Web Servers group, and by way of the role assignment, all users that have access (and privileges) will get access automatically.

Privileges

With Centrify, in UNIX, the rights are:

• PAM Access: meaning, "how the system is accessed" or "what protocol"   this allows to grant access via the console and SSH for super users, but only SSH for the rest of the world.  We can go deeper into SSH rights, like allowing a secure file copy, but we aren't going to go that deep.
• Commands:  meaning "what can the user do?" "in the context of what account?" etc.  For example, a super user may leverage Centrify-enhanced sudo to run any command as root, but a DBA may only have one privileged command, like "su - oracle"

Note that Centrify can also perform privilege management for Windows, but that's a whole other topic.  In here, the idea is to start broad (define super users and regular users) and slowly adjust to provide people with the roles that give them just what they need, again, in accordance with the least access principle.

With Centrify roles, there are other settings that can be adjusted like:

• At what time is the role available?  (e.g.  backup operator that runs the tar command as root from 10pm to 4am)
• What is the shell experience for privileged commands (a whitelist of commands or a free-range shell)
• Is the role permanent or just temporary (like in a change control window)

In Centrify,  privileges are granted by direct assignment or by making a user a member of an AD group that has been granted the assignment.

Putting it all together

1. Centrify does not provision AD users, this happens upstream (manually, Idm, etc)
2. To access Centrified servers in AD in a zone a user needs an identity and a role that grants access and privileges.
3. Identities can be granted manually or automatically (by placing the user into an AD provisioning group)
4. Access and privileges can be granted manually or automatically (directly or by placing a user into an AD role-granting group)
5. The reverse of 3 and 4 is possible.
6. Automation and integration is always possible and very simple due to the link to AD groups.