17 January,20 at 06:27 PM
Part 1 - Using Sudoers to understand Centrify DirectAuthorize: We’ll discuss the key gaps in “native” sudoers heard from our customers and why you should consider migrating to DirectAuthorize. Next, we’ll compare how UNIX users interact in the UNIX environment through “dzdo” (Centrify’s enhanced implementation of sudo). And then we'll use sudoers as a frame-of-reference to introduce the DirectAuthorize policy model.
The goal of this series is to help Centrify Server Suite customers take better advantage of our enhanced implementation of sudo and sudoers known respectively as "dzdo" and DirectAuthorize. In this series we'll address several areas around UNIX privilege elevation, such as our Sudoers to DirectAuthorize migration tooling. To kick-off the series, its important that we have a basic understanding of the DirectAuthorize policy model. If you are familiar working with sudoers, you will be right at home with DirectAuthorize. And if you’re not familiar with sudoers, no problem… we’ll show you how the pieces logically fit together. At this point, I’ve identified the first three parts to series with more to come:
Sudo authorizes UNIX users to run specific commands within the "elevated" context of a privileged account (e.g. root). Sudo has been evolving since its introduction in the 1980’s. Given “native” sudo’s longevity, UNIX administrators are well accustomed to working with it. However, sudo also has key gaps when considering today’s enterprise climate of privilege identity related breaches, compliance reporting, and IT operations spanning on-prem and Infrastructure-as-a-Service. So when we first discuss with our customers that Centrify Server Suite includes a simpler, scalable, and more secure approach to native sudo, it is not surprising to see conflicting reactions of both optimism and apprehension. As one customer put it, “On the upside, I can see how Centrify's approach to UNIX privilege elevation addresses native sudoers' shortcomings. That said, we’ve worked with sudoers for years. And as a sys-admin I can say that we're all creatures-of-habit.” As a result, we see some customers use Centrify Server Suite primarily for authentication and session auditing/recording without fully taking advantage of Centrify's enhanced implementation of sudo. So, how do we reconcile these conflicting reactions to sudoers' (e.g. its shortcommings and comfort/familiarity)? In short, once UNIX administrators understand how Centrify's RBAC policy model parallels the native sudoers format they're accustom to, everything starts to click. From there, the value of Centrify's enhanced sudoers implementation becomes readily apparent. As a UNIX administrator you will see that our approach is both familiar to work with AND it resolves native sudoers' major shortcomings.
Let's drill-down on some examples of sudoers' shortcomings we hear from customers:
“We’ve used sudo for years. It’s fine…for the most part. That said, sudoers has its challenges within our enterprise:
So, what can you do for us? Before you answer, keep mind that we don’t have the appetite to deploy massive infrastructure and retrain my staff on some new and proprietary security paradigm. Whatever the solution is, it must be familiar… don’t reinvent the wheel… just make the wheel enterprise class. So please, tell me…”
When we first start working with customers, most use sudo. The sophistication to which sudo is configured ranges from fairly coarse grained controls to very granular and complex policy rules that grow over the years. We encounter customers disciplined about using named accounts to perform administrative tasks. On the other hand, even with sudo in place, some shops still struggle with admins authenticating directly with privileged account (e.g. root) rather than their personal named accounts.
What is consistent across orgs is that sudo is a bear to administer consistently. Most shops rely on local sudoers files to administer policy. To maintain consistency, larger enterprises might push a “master” sudoers file through a configuration management solution such as Puppet or Chef. Configuration management has an important place in the enterprise. That said, config management tools are not the same as a purpose-built UNIX policy administration point. Furthermore, the challenge with treating sudoers as “just another config file” is that maintaining the “one sudoers file to rule them all” usually results in a file that is very complex and brittle. This complexity creates lifecycle management headaches and potential policy blind spots where access is granted in unintended ways.
Now that we’ve shared some of native sudoers key gaps we hear from our customers, lets discuss how we’re similar to sudo and what we do better…
First the basics… here’s an example Illustrating how to invoke a privileged operation first with sudo and DirectAuthorize (dzdo).
Figure 1
And if typing “dzdo” to invoke a privileged command seems strange, no problem. Simply set an alias to sudo.
Regarding the advanced persistent threat (APT) and bot concern mentioned above, lets take a look at another example (Figure 2 and 3). Here a web administrator, Wanda, needs to perform a privileged action such as restarting the production web server. Since this is a particularly sensitive operation, we want to make sure it really is Wanda behind the keyboard first. Before the command executes, a multi-factor authentication challenge is presented to Wanda via her Centrify mobile app.
Figure 2: Similar to "sudo", the user types in "dzdo" to run a command in a privileged user context. The policy for this command was set to require an MFA challenge. The user is then presented simple options to complete the MFA challenge.
Figure 3: The user then accesses her Centrify mobile app (iOS or Android) to complete the MFA challenge. Available options include the app’s Approve/Deny buttons, a one-time-passcode, etc.
Before we begin to layout the parallels between the DirectAuthorize and sudoers policy models, let’s level set and build out a few simple sudoers policy definitions. Here a sys admin, Gautam, needs the rights to perform a few privileged back-up related commands on a Linux machine (us-nonprod-rh-web1):
Figure 4
Easy, right? OK… now Becky needs those same rights:
Figure 5
Now let’s say that Gautam, Becky, and the back-up team (e.g. ADM_US_RH_BKUP) are responsible for all back-ups on all Red Hat machines in the US (e.g. SVR_US_RH). Along with this, the non-production web admin team (e.g. ADM_NP_RH_WEB) is responsible for managing Apache on all non-production Red Hat servers globally (SVR_NP_RH_WEB). Let’s add the non-prod US databases (SVR_US_NP_RH_ORCL) and DBA’s (ADM_US_NP_ORCL) to the mix as well. Relatively speaking, the sudoers example below is just a baby. But its easy to see that overtime these policies can grow to the point where keeping the file organized and error free becomes a complex undertaking and a source of security risk.
Figure 6
Its important to understand that DirectAuthorize’s policy model provides everything you need to represent your sudoers policies and then some. Table 1 provides a quick cheat sheet that maps sudo terms to Centrify Server Suite’s RBAC model.
Table 1: Sudoers to Centrify Server Suite RBAC terminology
Let’s review this from the perspective of an example sudoers file in Figures 7-10.
Figure 7: The User_Alias corresponds to AD groups of users
Figure 8: The Host_Alias corresponds to an AD group of computers
Figure 9: The Cmnd_Alias corresponds to Centrify Roles. The UNIX commands comprising a Cmnd_Alias also appear individually in the Centrify UI as UNIX Rights. Customers can then recombine Centrify “UNIX Rights” to form new Centrify Roles (which we’ll cover in the next article)
Figure 10: The Sudoers User Specification (User_Alias, Host_Alias, and Cmnd_Alias) equates to Centrify Computer Roles (e.g. AD User Group, AD Computer Group, and Centrify Role).
Hopefully you found this opening article to the “A Better Way to Sudo” series helpful. I look forward to your feedback and questions. In the next series installment, we’ll cover how the sudoers policies introduced in Part 1 are represented through the Centrify user interface and Active Directory.