What should you look for in your Access Management and Governance solution?

Choosing any solution for your organization is always an important decision. But when that decision is going to impact both your efficiency and productivity and your IT security then it is critical to think carefully about the features that meet your needs. And that is the case of Identity and Access Management (IAM) solutions.

Here is a list of things that you should look at when looking for your perfect Access Management and Governance solution.

1. Least-privilege approach

When talking about access to organization resources, it is of the greatest importance to protect critical accesses which could compromise your organization security. Privileged accounts such as IT admins must be reserved for only the situations that they are really needed.

Therefore, we must use a least-privilege access approach. Users must exclusively have access to those resources that they really need to perform their roles, and the access level must be the lowest needed. This way, regular users cannot do any action that may pose a security risk to your organization, either by mistake or on purpose by an insider. And privileged accounts will also be protected from outsiders trying to steal the identities of your users, managing them by Privileged Access Management tools that ensure they are only used during the time that specific applications and tasks need them, without exposing credentials to users and attackers.

2. Finest granularity of application permissions

Most applications contain different resources that users can access. And access to each of those resources can be divided into access levels, from read only to different write rights depending on the type of resource: it can be read only, contributor, editor, administrator… And each user will need a different access level to each of the resources in one application, depending on the tasks they need to perform. According to the least-privilege approach we mentioned above, the access rights of a user must be granted for each of the resources within the application: granting the same access level to all the resources means over-provisioning the user, giving him permissions that are not needed for his job.

Let’s make it clearer with an example. We may have a ticketing application, with different resources which are each of the projects that are managed with that application. A user working in Project A will need to have write access to the resource corresponding to his project. However, he will need to have read-only access to other resources, as issues raised on Project A may be related with problems found in other projects, so he needs to be able to search for issues in resources that correspond to those projects. Therefore, this user will need different access levels to each of the resources within the ticketing application.

3. Simplified workflow approval

Approvals are needed to perform different tasks, and are very important when those tasks involve critical resources such as personal data, or system administration. However, those approvals should not annoy users and slow down their daily work but be integrated in automated processes to streamline the user experience and increase their productivity.

Access to critical resources needing approval can be done using workflows that simplify both requesters and approvers tasks. Privileged Access Management tools to control these resources must include those workflows, so access is approved or denied during the workflow. Integrating an automatic execution step to that workflow would confer extra benefits: (1) privilege accounts would be kept safe, as no user would have direct access to those accounts, (2) approvers always know the exact tasks that are going to be performed, as the requester has to indicate them on the request, and (3) the requester saves time because, once approved, the request is executed and the user just receives the result, instead of be waiting until the approval is received to then access and perform the needed tasks.

A different situation is access to regular resources. When application administrators are responsible for granting and revoking permissions, managers are needed to approve those actions, as administrators do not know if the user requires those accesses. This creates an unnecessary burden, adding an irrelevant step that could be skipped if the provisioning were directly made by the team leader, who knows the permissions required and is the ultimate person that is responsible for the rights granted to his team members.

4. Delegated permissions and administration

Relying on administrators has several disadvantages. Not only impedes agile methodologies and reduces productivity due to the time consumed by the process, it also makes it difficult to have a full vision of the available permissions and therefore perform a proper and full provisioning of users. Requesters may not be sure about the exact resource or access level that is needed, what is imprescindible to achieve the least-privilege and finest granularity approaches that we talked about earlier, and they will need to contact administrators to know what options they have before making the request.

Team leaders should have a UI where they can easily identify the available resources and the access levels they are able to request. The access rights shown must be a list of those that the user is able to manage and assign. This way, the access can be immediately granted, as the team leader is responsible for the accesses given to his team members, saving time to the team leader, the team members and the administrators.

If the implemented system allows to delegate any individual permissions that a team leader has, it will also help achieve least-privilege and finest granularity approaches, simplify approval processes and allow an easy and efficient self-service. This avoids business disruptions during tasks changes and user relocations and reduces help desk support costs. However, the delegation structure must be created in a way that ensures that the process is also secure.

The best approach is using a hierarchical structure that reflects the delegation of work. Any team leader that delegates tasks should also be able to delegate permission to perform those tasks. And that is possible when permissions can be delegated through that hierarchy of work delegation.

Any user in this hierarchy can create children roles to assign users that are going to perform some tasks, and he will delegate some of his permissions to those roles. The user will delegate only the access rights needed for the tasks that they are going to perform within that role, so the least-privilege approach is fulfilled. And the access level will be the lowest needed for each of the resources, because the user knows exactly what resources he has access to, and can choose the correct permissions at the finest granularity possible.

The delegation of permissions also removes the need of application administrators, simplifying the approval process and allowing a self-service system for provisioning users, as the team leader is responsible for the selection and delegation of access rights that are needed by their team members, and no extra approvals by third parties are needed.

5. Monitoring and auditing

This orchestration of permission delegation needs controls to ensure that team leaders are properly managing access rights of the members. It is important therefore that these systems include logs with any change made in users and permissions, so it is possible to know who and when added or removed permissions.

These logs should be available to the team leader and also to any user involved in auditing processes.

Besides a change log, having the possibility of an easy and quick overview of permissions assigned to users at any time improves an access management and governance system, helping in provisioning and de-provisioning processes as the team leader can quickly identify users that no longer need to have access and revoke the permissions for those users.

6. Reliable de-provisioning

One of the biggest challenges for IAM systems is to ensure that users are properly de-provisioned when leaving an organization. Leaving user rights assigned to an account when the user no longer works in the organization is known as an orphan account, and they pose a high risk for the organization. Orphan accounts have access to organization systems and resources, and represent a gateway for attackers.

These problems make it necessary to establish periodic audits to identify and remove orphan accounts. However, automating the de-provisioning processes is the best strategy to ensure that users are fully de-provisioned, reducing the need of auditing and securing the user lifecycle. This automation involves using a single tool to revoke all the rights granted to a user at the same time on the appropriate date, ensuring that no application is forgotten and that the account will never have access to any resources anymore.

Check how Permeasyon helps you to fulfill these requirements, and Privival improves your approval workflows for critical resources.