As cloud migrations, workloads, microservices, and the use of SaaS explodes, infrastructure has become hyper distributed and increasingly dynamic. And with existing “private clouds” proving that they’re sticking around for a while longer, engineers sure have their hands full.
DevOps teams are looking to secure access to and within their production environment and are often considering a few different technologies. In this post, we’ll deep dive into one of those – privileged access management (PAM) – and provide a light comparison to an adjacent domain: workload identity and access management (IAM).
There’s never a single solution to a complex problem, but with some careful research and prioritizing your specific problems, you can make an informed investment in the right tech for you, right now.
The Access Management Universe
At the top level, there are three types of access management that matter to enterprises.
1) Workforce (User) IAM: This is what’s most commonly associated with IAM. It’s a system that simplifies and secures access between a user and the software systems to which they require regular access. This is a large area of the market today and also breaks down into specialized areas for types of users. More on this in a moment.
2) Customer IAM: These are the processes and tools that allow you to manage customers’ identity and access information. Think of this as third parties – excluding vendors and agencies – that need to access specific public-facing software and applications.
3) Workload IAM: Instead of a user or customer accessing a system, Workload IAM focuses on system-to-system communication. That is, one piece of software or infrastructure needs to communicate with another, whether it is in the same domain, a system distributed elsewhere, a SaaS service, or even a system belonging to a partner of yours.
You may be asking: Wait, where is PAM on this list? It turns out that Workforce IAM is broken down into a number of important subcategories. Among these are the management of third-party vendors, frontline workers, and notably, privileged access.
What’s the Difference Between PAM and Traditional IAM?
IAM is a system designed to manage enterprise user access at scale to typical systems such as collaboration tools, finance and accounting systems, HR tools, and so on. PAM, meanwhile, is targeted at a subset of systems (your production software) and a set of enterprise users (dev and ops) who need to access those sensitive systems in production.
What’s the Difference Between PAM and Workload IAM?
The biggest similarity and difference between privileged access management and workload IAM is that both focus on controlling access to the most sensitive systems you operate. PAM, however, is a form of controlling user access to sensitive systems, whereas workload IAM is focused on applications, scripts, and services accessing other sensitive systems.
Let’s now dig into PAM to provide a bit more detail on how it fits into your production environments – and when you need it.
Do I Need a PAM?
PAM Workflow and Use Cases
With a basic understanding of where PAM fits, let’s now understand the core use cases of privileged access management and whether you need to solve for them. PAM will typically apply when you:
- Build and operate systems that contain highly sensitive data (think credit cards or health records).
- Operate in a highly regulated environment (i.e. banks, government, health care etc.).
While some might say that you should always manage access to your most sensitive systems, if either of the above two criteria do not apply to you, you may be able to get by with a lighter-weight process or tools rather than a dedicated PAM solution.
With PAM, you’ll get an opinionated, technical solution to solve for the following key workflows:
1) Permissions Management: Setting the right level of permissions based on users and workgroups to reduce ongoing management and one-off privilege escalation.
2) Privileged Session Management: Establish, manage, record, and replay user sessions that access sensitive infrastructure.
3) Just-in-Time Access: Grant access, log, and manage one-off or “break glass” access in an easy and auditable way.
4) Credential Management: Broker access to sensitive credentials and the vaults that store them.
5) Logging, Compliance, and Audit: Log access to sensitive systems to simplify compliance and audit requests.
Of course, all of this comes with cost, both in terms of dollars and effort, to set up a PAM. So let’s take a look at a typical PAM architecture and what you should expect.
PAM Architecture and Components
While individual PAM offerings may vary slightly, there are four core elements that you should expect to deploy, integrate, and manage. Let’s examine an architecture example.
1) Client: Central to PAM’s functionality is the client interface, an application installed on the user’s device that grants them authorized access as needed. It’s crucial that this client is compatible with a variety of operating systems to accommodate diverse user environments. Authentication can occur directly through the PAM system or indirectly via a third-party service that verifies the user’s identity.
2) Gateway: The gateway brokers access to sensitive applications and services.
3) Relay (Optional): If your network is highly segmented, you may require relays within different environments to proactively open connections to the gateway.
4) Management Interface: Serving as the central hub for configuration and oversight, this interface allows for comprehensive control over the PAM system. Whether it’s implemented as on-premise software or accessed through a cloud-based service, this interface is pivotal for administering user roles, managing access permissions, distributing credentials, and logging activity.
Individual systems will have different workflows for you to learn and set up, in addition to separate lists of requirements or restrictions. See our section below on the important questions to ask your PAM vendor to understand the choices you’re making.
PAM Alternatives to Consider
First, let’s assess the marketplace. While this isn’t meant to be an exhaustive list of privileged access management vendors, they should give you a sense of the options available:
1) CyberArk: Considered a long-time leader in the space, CyberArk has been tackling PAM for a couple decades. As a result, its product works well in many different environments, although the model may not be as easily replicable in more modern infrastructure.
2) StrongDM: A newer entrant to the space, StrongDM’s SaaS approach takes into account both modern infrastructure but also modern workflows.
3) JumpServer: An open-source alternative to PAM. With more than 23,000 “stars on its Github listing and over 200 releases, this is a highly active project. The people behind the project also provide enterprise support, should you aim to progress from
4) Okta: Of course Okta is known for its user IAM solutions, but it recently introduced a PAM product. While the company is a late participant to this category, its pedigree as the most successful standalone IAM company makes it a force to be reckoned with.
Top Questions to Ask When Deciding on a Privileged Access Management Vendor
How Does Your PAM Solution Handle Password Management?
- Inquire about the provider’s password management capabilities, including password rotation, complexity requirements, and secure storage.
- Ask about support for multifactor authentication (MFA) to enhance access security.
- Seek details on how the solution addresses privileged account password vulnerabilities
What Session Monitoring and Recording Features Does Your PAM Solution Offer
- Explore the session monitoring capabilities, focusing on real-time monitoring and recording of privileged user sessions.
- Inquire about the granularity of session recording, including the ability to capture commands and activities during privileged sessions.
- Assess the ease of accessing and reviewing session logs for auditing and forensic purposes.
Does Your PAM Solution Support Privilege Elevation and Delegation?
- Understand how the solution enables privilege elevation for users who need temporary access to sensitive systems.
- Inquire about delegation features that allow the assignment of specific privileges without compromising overall security.
- Evaluate the flexibility of privilege management to accommodate diverse roles within the organization.
How Does the PAM Solution Address Least Privilege Principles?
- Discuss how the PAM solution enforces the principle of least privilege to limit access rights for users, applications, and systems.
- Inquire about automated workflows for requesting and granting elevated privileges based on predefined policies.
- Assess the granularity of privilege assignment and the ability to customize access levels.
What Reporting and Compliance Features are Available in Your PAM Solution?
- Explore reporting capabilities for tracking privileged access, security incidents, and compliance status.
- Inquire about predefined compliance templates and the ability to customize reports based on regulatory requirements.
- Assess how the solution facilitates compliance with industry standards, such as PCI DSS, HIPAA, or GDPR.
By asking these technical questions, you can gain insights into the specific features that a PAM solution offers and how well they align with your organization’s technical requirements.
Signs You May Need Workload IAM Instead of PAM
You probably now have a sense that PAM can be valuable. But the real question is, will it solve your biggest problem right now? Here are five considerations that, when evaluating your overarching IAM strategy, may suggest you need something other than a privileged access management solution.
1) You are concerned about your workloads, apps, scripts – and if they are securely accessing your sensitive data and infrastructure.
2) You are concerned with automating secure access between workloads as they spin up and scale – or you introduce new connections to additional SaaS services or APIs.
3) You are looking to implement Zero Trust-style access where conditional access policies are continually evaluated before access is granted
4) You want to accelerate the move to secretless identity and access workload credentials.
5) You want to fill the audit and compliance gap to show when credentials are issued – and which application used them to access a service.
If these are top considerations for you, then you might consider taking a deeper look at Workload IAM. This technology automates secure workload-to-workload access, instead of focusing on user-to-workload access.
This is valuable because the needs, technology requirements, and integration of securing access between workloads must map to an entirely different workflow than the privileged access workflow that we’ve described in detail here.
Hopefully this article gives you a good anchor to start your access management exploration. If you need more assistance, reach out to us!
The Workload IAM Company
Manage Access, Not Secrets
Boost Productivity, Slash DevSecOps Time
No-Code, Centralized Access Management
