Basics: Privilege Management Planning on UNIX/Linux using Centrify and Active Directory

Background

Privilege Management (or Privilege Access Management):  is the capability to control and limit users activities in accordance with the least privilege principle, some key goals:

• Limit access to systems based on business need-to-know
• Limit privileges or actions to those required to perform the job function
• Provide timely information for the purposes of attestation or auditing
• Enforce separation of duties.

In the context of UNIX and Linux systems, Centrify provides capabilities to establish a Privilege Management model that satisfies all these goals (since version 2013, these benefits extend to Windows systems too).

To perform a Plan-Do-Check-Adjust exercise on Privilege management, we will break down the activities in Access, Privileges, Governance and Reporting.  To keep the posts a short read, we'll focus on planning.

Planning Privilege Management with Centrify for UNIX/Linux

Governance

Governance is related to separation of duties and ideally, the people who define the access, rights and privileges (Security Analysts, compliance, etc.) are different than the people who access the systems (System Admins, DBAs, etc);  however, in the real world the expertise and organizational history required to establish a governance model is in the hands of the most senior administrators.  

Delegation of Centrify objects is performed in two places:

• In Active Directory (this is another topic)
• At the zone level, Centrify breaks the actions to be performed as follows:

Rights	Category	Description
Change zone properties	Operational	Changing zone properties may imply changing the UID/GID defaults, renaming the zone or how the zone is provisioned.  These actions should be change-controlled.
Add users	Operational	Adding users is basically UNIX-enabled AD users.  This is delegated to the ZPA service account in an automatically provisioning scenario.  In a manual zone, this is just day-to day activities.
Add groups	Operational	Same as above, but with groups; however, this is a one-time setting, the real operations are Add/Removes from the mapped AD group.
Join computers to the zone	Operational	This is the equivalent to joining computers to the domain, the Windows process can be reused here.  UNIX operations are typically granted this role.
Remove zones	Operational	Deleting zones (in production) should be a change-controlled activity.
Remove users	Operational	See “Add users”
Remove groups	Operational	See “Add groups”
Remove computers from the zone	Operational	See “Join computers to the zone”
Modify user profiles	Operational	See “Add users”
Modify group profiles	Operational	See “Add groups”
Allow computers to respond to NIS client requests	Operational	With Centrify, NIS maps can be reused securely in a clientless scenario, Operations may need to configure computers to act as NIS proxies for appliances, legacy systems, etc.
Import users and groups to the zone	Operational	See “Add groups”
Manage roles and rights	Governance	Roles and rights are the building blocks of RBAC.  See below.  This activity should be reserved for Security or Compliance, although in an initial implementation may be granted to UNIX administrators.
Manage role assignments	Governance	Role assignments entitle AD user or group principals to access or privileges based on a role.  The guidance is the same as “Manage roles and rights.”
Modify computer roles	Governance	Computer Roles are the groupings of systems.  They define the types of systems and the scope of access. The guidance is the same as “Manage roles and rights.”
Add or remove NIS map entries	Operational	With Centrify, NIS maps can be reused securely in a client scenario, Operations may need to add/remove/change those maps.
Modify NIS map entries	Operational	See “Add/Remove NIS map entries”
Remove NIS maps	Operational	See “Add/Remove NIS map entries”

During the implementation phase, the trusted administrators that are implementing Centrify may have full control, but as the implementation matures, as part of the adjust phase, the governance rights can be split from operations.  The key questions are:

• Who are the individuals that have operational responsibility for your UNIX/Linux systems?
• Who are the individuals that have governance responsibility for your UNIX/Linux systems?
• Is there a geographical o divisional breakdown that we should be aware of?
  The answer to this final question is very important.  It may trigger the need to have parallel or child zones.  Try to do as much as you can to keep things as flat as possible.

Privileges

Planning for privileges is one of the hardest activities;  and this is because the people using the system may not be used to thinking about Roles-Based Access Controls.  A good starting point may be a sudoers file (Centrify can import them); but even that may carry legacy information;  the worst case scenario is the implementation of a centralized mess.  Here are some base questions for a table-top exercise:

Questions	Typical answers	Comments
1.      What are the user populations that access UNIX/Linux systems?	DBAs, Developers, System Administrators, etc.	The goal of this question should be to identify user populations.  Moderating the scope of this answer is critical. Also, try to find out if users are within an AD domain, across domains, etc.  This has an effect on the type of Security groups used for role assignment.
2.      What are the groups of systems they access today?	Oracle servers, Apache servers, Dev Servers, Filers, etc.	The goal of this question is to identify how systems should be grouped.  This question is the key to establish the governance model because it will produce the Computer Roles.  An advantage of Centrify is that a system can have multiple roles.  It can be a Database System and a Web System at the same time.
3.      What are the groups of systems they should have access to?	The answer varies	It’s possible that this may be the hardest question to answer; this is because other than Netgroups, organizations may not have a mature way to group systems and grant access.
4.      How do these users access the systems today?	SSH, console, VNC, FTP, NFS, Samba, etc	This is key, because Centrify can control how PAM access is granted.
5.      How do these users should access these systems?	This varies too	With Virtualization, console access is rare; also, unless there are HPUX, Solaris or AIX systems, console access is limited to a trusted set of administrators; there will be a bias towards SSH, but even that can be controlled granularity with Centrify.
6.      How do people use privileges today?	The answer to this question may vary.	The best way to explain this is with an example.  How do DBAs use the oracle account? Answer: “they access with their account, and sudo as oracle or su to oracle” Upon verification, turns out those DBAs were logging in directly with the Oracle account.
7.      What are the privileges that they have today?	Everyone is can be root, sudo access, etc.	The answer to this question depends on the maturity level of the organization.
8.      What are the privileges that they should have?	The answer varies	Just like the answer to question 3, since the possibilities are unknown, it may be hard to get.

Again, the hardest part of this planning exercise is to get people that know enough about what's possible with Centrify (see implementation below), and that privilege management has its own roadmap. 

Access

Access involves planning the types of systems available in the enterprise.  Grouping systems based on type,  or environment allows the scoping of roles to be tied to groups of servers, effectively enforcing both access and privileges.  For example, a group of systems may be defined for Application A, that has web, application and database servers; it's possible to group these systems together and have a different access/privilege model for DEV, QA and Prod.

The Output of the Planning Session

In Business Problem # 1, the access model was well defined;  and in Business Problem #2, the privigeles are going to be expanded:

User Populations	Access / Protocols	Privileges
System Administrators	All Systems via any protocol	Run any command as root
DBAs	Database Systems via SSH	Elevate to db2inst Run db2 commands as db2inst DB2 instance service control
Web Admins	Web Systems via SSH	HTTP daemon service control (as root) Edit http daemon configuration file (as root)
Developers	Database and Web Systems via SSH	Run application X, service control
All UNIX-enabled users	Listed on Filers	No access, no privileges.

Stay tuned, in the next post we'll talk about Implementation and Verification.