Sergey Nivens - Fotolia
Corral superuser access via SDP, privileged access management
Keeping control of superusers is an ongoing challenge. Employing SDP and privileged access management can make the job easier. But can SDP replace PAM?
Managing the access rights of superusers is an ongoing challenge in IT. Staff members empowered to fundamentally change networks and systems not only enact planned changes -- among them upgrades and service rollouts -- but they can inflict enormous damage, either accidentally or intentionally. As a result, superusers' accounts must be closely managed and tightly controlled.
Unfortunately, tight control is rarely the reality. Instead, most organizations find themselves in an environment in which:
- some accounts have tight control and others don't;
- access is initially assigned only to those who need it but, over time, includes people who formerly needed it but now have different responsibilities; or
- access is still available to people who only needed it temporarily or in an emergency but from whom that privilege was never removed.
These problems exist for many reasons, including lax enforcement of policy, incomplete privileged access audits, long cycle times on access reviews and "just in case" preservation of access -- as in "just in case the person currently responsible never makes it to work today and there is an emergency."
This security issue, referred to as privilege creep, is a common issue across organizations today. One of the most significant contributors to privilege creep is the fragmented access control environment most organizations live in, with remote work and cloud use increasing exponentially.
To remedy privilege creep and ensure accounts remain safe, a privileged access management (PAM) framework must be adopted and instituted. Software-defined perimeter (SDP) has strong access controls -- but can it handle PAM?
The connection between SDP and privileged access management
While it is not a complete PAM framework, SDP can solve some of PAM's most pressing issues: tracking when and under what circumstances privileged accounts are used and providing a single place from which to control access to those accounts.
SDP establishes an environment where only sanctioned network communications flow. In SDP, a secured network node -- a server, usually -- protects itself through a hardline network policy: Discard all packets unless specifically authorized to receive them. When some other node reaches out to start a network session, if the protected node has not been told by an SDP controller to accept communications from that source, the packets go into the bit bucket.
Clients systems run an SDP agent the same way. When a user authenticates to the SDP controller, it consults its policies and the enterprise directories it is connected to and decides what servers or services that user -- on that machine, at that time, in that place -- will be allowed to talk to. It instructs the client and all the servers accordingly; any attempt to talk to unsanctioned services will fail.
The link between SDP and PAM is straightforward. Through SDP, IT can easily track when privileged accounts are used and from where. IT can also see and control which systems each account can access. IT can even use SDP to prevent some circuitous methods to assert superuser privileges. For example, SDP would block an unprivileged account from accessing Telnet, where a user might use the su command to gain privileged access.
But in the end, SDP ≠ PAM
For all its benefits, using SDP for privileged access management is no panacea. For example, PAM monitors the privileges an account has on systems it is allowed to reach, where SDP might not. In addition, PAM supports features such as password management, vaulting -- that is, monitoring temporary privilege escalations -- and tracking what a user with privileges is doing through the course of a session, flight recorder-style. SDP could add functionality to any of these capabilities, but none are a fundamental component of its design.
