With the massive increase in remote work, it has never been more important to track which applications and systems a user has access to. With the increase in use of SaaS based platforms, many of which do not support Single Sign On (SSO), user access is no longer controlled from a Single Active Directory instance.
The obvious need for tracking users and systems is when an employee or consultant is no longer working with the company and their access needs to be terminated. But, there are other cases that must be considered. for example:
In large organizations that have successfully deployed an Identity and Access Management (IAM) system, such as those from SailPoint or Imprivata, these issues are easily managed. Using these tools allows you to define "roles" within your enterprise and provision / de-provision not just the account, but also the precise level of access that the user requires to every system they will need to use to complete their duties. These tools also allow you to define separation of duties, for example if you administer a system, you cannot be a user of the system. However, these tools take an enormous amount of effort and money to deploy and require leaders from the entire organization to be involved. As with all security initiatives, deploying and maintaining these solutions is an ongoing process and they require great attention to detail.
But what about most organizations who have not implemented an IAM solution- how do they manage these issues?
We have seen some organizations rely on spreadsheets, SharePoint Lists, or other cloud solutions to track users and the systems they use. Most of the organizations that I have worked with that do this do a good job of tracking additions but do a terrible job of removals. This is especially true when a user does not leave the organization, but changes roles. The process of a user continually gaining access rights as they change roles is known as privilege creep. Many organizations do not track user access at all, and resort to checking each application system used to see if the user should be added, removed, or access modified. This is a slow, manually intensive, and error prone process.
Now if access to every single one of your applications is controlled via Active Directory or Azure Active Directory, removing access is easily achieved, but privilege creep is still likely to happen. What about if you are using cloud applications that do not support Single Sign On with Azure AD- how are you tracking that? Then, there are also applications that do support either AD or SSO, perhaps cloud based- how are you tracking access to those ones?
Working with our clients, especially those under government compliance requirements, we needed a solution to these problems. Our clients had neither time nor budget to implement a full IAM solution like SailPoint. However, all the users are licensed with Azure AD P2 license, which allows us to leverage a suite of great features, Identity Governance in Azure AD. There are many features in Identity Governance, and we specifically leverage the Entitlement Management features. Using these features is a good first step towards a full IAM solution. These include:
I am not going to go into a deep dive on the features in Entitlement Management, but at a high level, an access package defines a set of Security Groups, Office 365 Groups, and Enterprise Applications that an assigned user is added to. Additionally, the package can define a multi-level (up to 3) Approval Process, and Access Reviews to verify periodically that the users assigned should still have the assignment. For more information on Entitlement Management see- What is entitlement management? - Azure AD - Microsoft Entra | Microsoft Learn.
To control access to applications that use Active Directory Groups and/or Azure Active directory groups, we create Access Packages that the user can be assigned, approved, and then are added to the applicable Security Group.
The Access Packages are configured with access reviews. The access review allows a manager or system owner to review who has access on a defined schedule. A review can be configured such that if no one responds to the review, access is either automatically granted or removed.This addresses the major issue of privilege creep.
By using the access package, the user can also be added to Azure AD Enterprise Applications, which can be used to control access to applications that rely on Azure AD for SSO like Salesforce, Calendly, and other SaaS platforms.
To track applications that the user has access to but that are not controlled from Active Directory, we still use an access package. The user is added to a group that tracks the application usage. Again, we leverage access reviews here.
By using the access packages to track all systems that the user has access to, it is possible to use a report to find all the systems the user has access to. By removing the user from the access packages, their access is removed for all systems controlled by Enterprise Applications or Security Group.
Another feature that we make use of is the request forms in the access packages. An access package can define a set a of questions the user must answer when requesting access. This enables us to switch from paper, email, or ITSM based access request forms to portal based with process. Access package management can be delegated to non-IT resources, this allows systems owners to manage their request and approval processes. In situations where user access does not need approval, Access Packages can be defined with no approval and allow user Self Service to gain access.
Using Azure Entitlement Management is a great first step towards full system access tracking and role-based access control. You may well be already licensed for these great capabilities, and we can assist you deploying them.
If you want to learn more about access control or have any questions, please contact us today!