Deprovisioning is a critical step in the Privileged Access Management (PAM) lifecycle. Without deprovisioning, privileged accounts that are no longer required are easily forgotten. This contributes to the problem of privilege sprawl and violates least privilege best practices and compliance requirements, creating serious vulnerabilities.
In this blog, you’ll learn about deprovisioning strategies that reduce your risk. You’ll understand the difference between deprovisioning privileged identities and deprovisioning privileged access. You’ll also discover new methods for deprovisioning that take advantage of automation and machine learning, ensuring consistency and efficiency in the deprovisioning process, particularly with those often forgotten service accounts.
Deprovisioning means that an IT asset, digital identity, or access is removed from your environment. It’s deactivated or deleted so it can’t be used, but you can still decide to bring it back at a different time and use it for a different purpose. Deprovisioning is the exact opposite of provisioning.
Deprovisioning has a different meaning from decommissioning. Compared to deprovisioning, decommissioning is more final. With decommissioning, you remove the asset from your books entirely to no longer pay license or maintenance fees, and you don’t plan on using the account ever again. This blog post focuses on deprovisioning.
There are risks associated with failing to deprovision a user or getting your deprovisioning wrong. When deprovisioning doesn’t happen or doesn’t happen properly, your risk of cyberattack increases.
Without a documented and enforced deprovisioning process, it’s impossible to get an accurate view of your attack surface and risk exposure, because you don’t know who has access to what. Any report you attempt to provide regulators, auditors, executives, or cyber insurance companies will be incorrect.
When identities and access are left in place but unmanaged, cyberattackers can leverage them for their own nefarious purposes. Using these unmanaged accounts and identities, attackers can gain entry to your IT environment and navigate freely while undetected, thanks to the attackers looking and acting like a known, expected user.
One of the most frustrating challenges IT organizations face is managing identity sprawl. In many organizations, users have one identity for managing sensitive systems and another for day-to-day work. Organizations typically have identities set up in Active Directory, but they also must account for identity trees in third-party SaaS and cloud platforms. Also, different identities may be used for managing Windows systems vs. Linux or Unix.
As part of the employee offboarding process, departing users must have all of their identities deprovisioned in multiple locations. This process is time-consuming and prone to mistakes, which is why it’s common for employees to report that they still have access to employer accounts well after they have left an organization.
It’s important for human resources and IT teams to work together to deprovision all employee identities in use after that employee leaves the company. This is otherwise known as “user deprovisioning.”
While the identity deprovisioning process varies depending on the applications, systems, and infrastructure involved, the basic steps are as follows:
Deprovisioning privileged access is a more nuanced and continuous approach than deprovisioning privileged identities. When an identity is deprovisioned, it’s deleted or removed from a directory or third-party system entirely. Essentially, that user no longer exists and has zero access to any part of your IT environment.
Deprovisioning access, on the other hand, could mean that a user may continue to use certain systems and conduct certain activities, but no longer has permission for others. For example, that user may be granted the ability to view files based on their role and permissions, but not create or modify them.
Deprovisioning access in this way gives you finer control over what people do and how they do it. In today’s environment of rapid change, deprovisioning access is essential because it allows you to keep up with a fluid risk profile and shifting attack surface.
Just like provisioning access, the deprovisioning process comes into play when a user changes roles in the organization and has new job responsibilities or levels of authority. It could also happen when a particular activity or initiative is complete. For example, a user may need a high level of access to a certain system for troubleshooting or upgrades—a temporary project. You would not want that user to have standing access when the project isn’t active, so you must deprovision.
The deprovisioning process applies to internal employees as well as third-party contractors and partners who frequently shift projects. It also applies to non-human identities such as service accounts, which interconnect and share sensitive information.
Access to cloud services: In today's cloud-centric environment, employees often have access to various cloud-based services and applications. Neglecting to revoke or disable access to these services can leave sensitive data vulnerable.
Third-party integrations: Many organizations use third-party applications and services that integrate with their internal systems. You’ll want to check in regularly to ensure that access is still required and determine whether it should be deprovisioned.
Shared accounts and passwords: In some cases, multiple employees may share a common account or password to access certain systems or applications. Be sure if you deprovision access for one person that you aren’t deprovisioning access for others who need it. For that reason, it’s always good practice to avoid shared accounts.
To keep up with the requirements for deprovisioning access, automation is key. Using deprovisioning technology has many benefits.
In a typical enterprise, an employee may use hundreds of systems, including enterprise applications, databases, cloud platforms, mobile apps, SaaS tools, etc. And those service accounts? A single organization may have hundreds of systems interacting in a complex web of dependencies. Both provisioning and deprovisioning access for all those systems is impossible without some level of automation.
While it may seem counterintuitive, the most effective way to automate the deprovisioning process is to consider it upon the first stage of the account management lifecycle—provisioning. For example, Privileged Access Management (PAM) solutions like Delinea Secret Server give you the ability to set an expiration date at the point of initial provisioning, so that deprovisioning happens without manual intervention.
Service account governance solutions like Delinea Account Lifecycle Manager ensure you set up service accounts properly from the start, including their dependencies to other systems. Then, when you deprovision their access, you can feel confident that no processes will be broken.
To ensure the right level of access, you can also set up automated provisioning and deprovisioning approval workflows. With this type of deprovisioning process, the executive or manager in charge of the employee or the owner of the IT system can make the call. Automated reports provide information to the decision-maker so they can understand current access levels and make an informed decision as to what should be deprovisioned and when.