5 Reasons Lifting-and-Shifting Legacy PAM to the Cloud Doesn’t Work
Reason #1: Cloud is TransientMoving traditional PAM solutions to manage and monitor cloud ecosystems failed primarily because on-premises IT infrastructures are static in nature, while cloud infrastructures are ephemeral and extremely dynamic. Companies are migrating workloads to the cloud to achieve all the advantages of elasticity, scalability, resiliency and cost optimizations that it provides. Spinning up new workloads or services in the span of few seconds or minutes and scaling them back down when not in use has allowed organizations to meet their compute needs much effectively. However, this flexibility that creates business efficiencies also leaves legacy PAM solutions at a disadvantage. Their cumbersome architecture lacks the nuance and speed necessary for managing and monitoring privileged identity lifecycles, leaving organizations at risk. Legacy PAM solutions scan environments at regular intervals, but those intervals don’t match organizational auto-scaling policies. Discovering for new or modified privileged identities or workloads over weekends or once a week means the PAM solution is not continuously monitoring the cloud environment. This means that organizations are not proactively keeping track of risks—or even keeping track of all of them.
Reason #2: New Identities Need to be IdentifiedCloud migration brings new conduits and different interfaces through which administrators can gain privileged access on a cloud ecosystem. After all, cloud is much more than just Virtual Machines (VMs, EC2 instances) or databases. Cloud migration or a cloud-architected strategy includes the usage of devOps tools and CI/CD processes to orchestrate cloud workloads. Serverless functions, containers, Kubernetes workloads-as-services have become the mainstream strategies not only to run workloads but also to operationalize the cloud ecosystem at scale. A core component to organizational PAM strategy should be to determine the various privileged identities and interfaces. Unfortunately, once again, legacy PAM solutions fall short because they lack the ability to identify new cloud-based identities and their focus remains on VMs running on cloud.
Reason #3: Software-as-a-Service (SaaS) Needs a New ParadigmSaaS applications are one of the three main new technologies driving digital transformation, yet organizations continue to solve identity and access problems arising from SaaS with traditional methods. Users who require privileged access to applications are provided two user IDs, one for standard access and one for privileged access. This simple, rudimentary method worked in on-premises implementations because of perpetual licensing models. However, most SaaS offerings are licensed “by the user seat.” This dual-ID method increases organizational licensing costs and adds additional, often unnecessary, overhead and complexity to managing and governing the identity lifecycle. It also leaves high-privileged accounts with excess standing privileges in the environment as an attack vector. Using a “lift and shift” approach to cloud privileged access management fails because SaaS applications use a different security model than traditional applications. SaaS applications require a different approach and just changing the deployment model does not solve the inherent risks and complexities of privileged access in these applications.
Reason #4: Attack Surface Needs ReductionOrganizations with legacy PAM solutions have used the strategy of persistent operating system (OS) accounts with static permissions. This design approach has several inherent flaws due to the increased risk exposure and standing privileges. In cloud, the same strategy creates even bigger risk exposure and audit concerns due to its elastic nature. Workloads are ephemeral, and that practically necessitates non-persistent accounts with zero standing privileges (ZSP). Migrating legacy PAM solutions to the cloud does not eliminate or reduce the attack surface because of their rudimentary, static account design and traditional datacenter-based approach.
Reason #5: PAM Needs More than IAM IntegrationGovernance over privileged identities is paramount not only from an internal and external IT audit perspective, but also to improve the security posture of cloud ecosystem. Often, organizations implement legacy PAM solutions that have an over-reliance on an Identity and Access Management (IAM) platform or product for provisioning needs, service account lifecycle management, and local OS account lifecycle management. This integration often becomes the ‘long pole’ in PAM rollouts and organizations tend to either implement the bare minimum or shelve the program due to change in organizational priorities
The Solution: Converging PAM with IGAA modern datacenter on AWS, Azure or GCP is comprised of users in the form of local users, federated users and assets such as VMs, serverless functions, Kubernetes pods, containers, and databases as services. Employees, contractors, and customers are identities in this ecosystem, but so are machine identities such as the workloads, serverless functions, containers, and other cloud artifacts. And Identity is the attack vector for multi-cloud environments. With identity as the new attack vector, converging a cloud-based Identity Governance and Administration (IGA) solution with PAM in a single platform is the logical way to address the attack surface and secure the perimeter. Governance added to this new array of existing and emerging identities assures their integration with the governance and privileged access solution. A cloud-based, converged solution has the speed and flexibility to continually identify and integrate new workloads or other privileged identities. There is no lengthy window of vulnerability where new identities aren’t enrolled in the PAM solution. With the convergence of IGA and PAM, administrative privileges in SaaS applications no longer require a separate account. When a user needs to perform an administrative task, they can request elevated access and have temporary privileges assigned to their user account to perform the task. After an elapsed time, the privileges are removed. This simplifies licensing by only requiring one account, simplifies monitoring by not requiring resolution between two separate identities, and simplifies risk as an account never has more privileges than necessary. Implementing the principle of least privilege and ZSP reduces the attack surface. For both for SaaS and IaaS, specific and time-bound granting of privileges means no vulnerability from lingering accounts with excess access. The element of risk is core to an intelligent IGA platform, and converging IGA with PAM allows PAM processes to be “risk-aware” and “intelligent”. Risk-aware scores can be calculated from user risk, endpoint risk, infrastructure misconfigurations, access-plane risks and control-plane risks. PAM processes and actors can make informed, intelligent decisions with these risk scores. Organizations gain even more benefits from this integration of IGA and PAM, such as:
- Visibility of toxic access combinations
- Detective and preventive separation of duties for privileged access
- Privileged access reviews to evaluate risk on a periodic basis
- Privileged account ownership and management
- Succession management for privileged IDs