Introducing Safeguard for Sudo
Introducing Safeguard for Sudo
Safeguard for Sudo helps Unix/Linux organizations take privileged account management through sudo to the next level: with a central policy server, centralized management of sudo and sudoers, centralized reporting on sudoers and elevated rights activities, event and keystroke logging of activities performed through sudo, and offline policy evaluation. With Safeguard for Sudo, One Identity provides a plugin to Sudo 1.8.1 (and later) to make administering sudo across a few, dozens, hundreds, or thousands of Unix/Linux servers easy, intuitive, and consistent. It eliminates the box-by-box management of sudo that is the source of so much inefficiency and inconsistency. In addition, the centralized approach delivers the ability to report on the change history of the sudoers policy file.
Figure 1: Safeguard for Sudo Architecture
Safeguard for Sudo enables you to get more value, security, and compliance out of your existing investment in sudo across any number of Unix/Linux systems.
Features and benefits of Safeguard for Sudo
Embracing and enhancing Sudo
The vast majority of organizations with Unix/Linux machines in their infrastructure use the open-source sudo project to help delegate the Unix root account to achieve privileged account management objectives. Sudo has a proven history of delivering value, however, management of sudo can be cumbersome, sudo policy across multiple servers is often inconsistently written and executed, and sudo does not include the ability to centrally manage the sudoers policy on multiple systems that is so critical to security and compliance initiatives. One Identity LLC, the company that pioneered the "Active Directory bridge" market with Authentication Services, continues to lead the way for identity and access management in Unix environments, with powerful and innovative new capabilities that provide enterprise-level privileged account management (PAM) by enhancing an existing sudo installation with centralized policy, reporting, management, and keystroke logging through Safeguard for Sudo.
Safeguard for Sudo provides powerful capabilities:
Extend Sudo
Safeguard for Sudo enhances sudo with new capabilities (central policy server and keystroke logging) that embrace and extend sudo through the Sudo Plugin which fits into the Sudo modular architecture.
Central Sudo policy
Safeguard for Sudo permits sudo to use a central service to enforce a policy, removing the need for administrators to manage the deployment of the sudoers policy file on every system. This improves security and reduces administrative effort by centrally administering sudo policy for privileged account management across any number of Unix/Linux servers.
Safeguard for Sudo also offers the ability to join a policy server in pmpolicy mode. The pmpolicy mode supports a script-style policy format that can be used to build custom security policies with fine-grained control of privileges.
Event logging
The Safeguard for Sudo event logging feature provides the ability to log all commands performed through sudo to know which commands were accepted and rejected, who performed the command, and when the command was performed.
Keystroke logging
The Safeguard for Sudo keystroke logging feature provides the ability to log keystrokes, then view and replay keystroke logs for end-users that perform activities through sudo. The keystroke log provides a comprehensive view of what activities were performed and the commands that were run across all systems. You can filter the report in many ways to find data quickly. For example, you can filter on specific commands or for commands run during a specific time period.
Audit server logging
Administrators can stream event logs and keystroke (IO) logs from a client to a sudo log audit server (or compatible server). A syslog output of streamed keystroke (IO) logs can be used to send the data to a Security Information and Event Management (SIEM) tool.
Offline policy evaluation and log synchronization
Safeguard for Sudo supports offline policy caching. When a Sudo Plugin host operates offline, it stores all log files on the host, then synchronizes the log data back to the primary policy server when it becomes available. See Safeguard for Sudo Policy Evaluation for more information.
How Safeguard for Sudo works
A basic Safeguard for Sudo configuration would include a primary and a secondary policy server, (known as a policy group), and any number of hosts with the Sudo Plugin installed.
Figure 2: How Safeguard for Sudo Works
The first policy server configured is the primary policy server which holds the master copy of the sudoers policy. Additional policy servers configured in the policy group are secondary policy servers. The primary policy server and any number of additional secondary policy servers share the common sudoers policy.
The Sudo Plugin is installed on each host system. Then the hosts are joined to the policy group. Once joined, sudo commands that run on the hosts are sent to the primary policy server to be evaluated against the centralized policy. (Note: The local sudoers files (/etc/sudoers and /etc/sudoers.d) are no longer used to evaluate the sudo policy on joined hosts.)
The primary policy server either accepts or rejects the commands; that is, the primary policy server either allows the command to run on the host or not. The primary policy server records an event each time a command is accepted or rejected. And, if enabled for keystroke logging, the primary policy server records the keystrokes entered on the hosts.
Planning Deployment
Before you run the installer, consider the following questions:
- Which machines in your network will run policy servers?
If you only plan to use one policy server for an entire network, it should be the most reliable and secure machine.
You can specify multiple policy servers to avoid having a single point of failure.
If more than 150 users will be using a single pmmasterd for validation, you will want to have multiple policy servers to avoid a UNIX network resource bottleneck. Plan to have a maximum of 150 users validating at a single policy server.
- Which machines will be managed hosts?
Only those hosts running the Sudo Plugin may receive and run Safeguard for Sudo requests.
One Identity recommends that you initially specify one policy server and three or four Sudo Plugin hosts when you first install and experiment with Safeguard for Sudo.
- What level of protection do you require?
If you require greater protection, you can select an encryption level such as AES, or a dedicated encryption system such as Kerberos. When configuring Safeguard in interactive mode, you are asked if you are using Kerberos. If you are using Kerberos, Safeguard automatically uses Kerberos for encryption.
- What port number should pmmasterd use to listen for network requests?
Choose numbers that do not conflict with other numbers in the /etc/services file. Ensure these entries are propagated to all machines accessing Safeguard.
- Which directory should contain the Safeguard log files?
By default, the log files are placed in /var/adm or /var/log depending on the host architecture. The installer allows you to change the directory by specifying command line options to the Safeguard daemons. The partition needs to contain enough space for log files to increase in size.
