In many applications, a user with a given access level has a fixed number of tasks that they can always perform. Some users can log in and access some privileged data, admins can log in and do protected tasks, and root users can log in and do anything. This method of granting unchanging user privileges is called standing access.
If we realize that the most common vector of attack on computer systems is through compromised credentials (see page 19 of Verizon’s 2020 Data Breach Investigations Report), it’s easy to appreciate how standing access can help these attacks succeed. When an attacker is able to compromise the credentials for an admin or root user, they can see and act upon sensitive information and infrastructure with very few limitations. Standing access also makes infrastructure more vulnerable to mistakes, like when a developer who thinks they’re modifying test data is actually logged into a production environment, or when someone leaves a role but their credentials linger on.
The fundamental idea behind just-in-time (JIT) access is removing these long-standing credentials. Instead of always allowing certain users access, you give them access only to what they need when they request it, then you remove their access once the task is completed.
The standing access authentication flow is relatively simple. When a user makes an account, they are given permissions to do things based on the type of user role they are assigned. Those permissions exist until the role of the user is changed or the account is removed. In some situations, like if a user loses access or the account is compromised, the authentication credentials are changed.
The JIT authentication flow is different. Instead of logging in and automatically having access to an application, a user (or a vendor or another application) requests permission to access a service.
That request is reviewed by a person or a machine, then if the request is granted, either manually or via an automated process, the user is granted temporary credentials. The user can use these limited credentials to perform that specific task. The final step of JIT access is removing the created credentials after some amount of time.
There are few ways of handling JIT access. The easiest to implement is having a limited number of administrative accounts with escalated privileges. When a user requests access, you give them access to an administrative account, then cycle the password after their work is completed.
This is a step in the right direction, but also encounters the same fundamental problems as standing access. If those user accounts are compromised, so is the infrastructure they have access to. This strategy merely mitigates the blast radius by ensuring those accounts will have their passwords cycled. If creating an audit trail is important for your JIT strategy, this situation is difficult to manage, because it can be hard to clearly establish who is doing what with shared accounts.
Another option is to elevate the privileges for existing accounts by giving escalated privileges to users who request access and are approved, and then revoking that access after their session. The third option is to create entirely new accounts when users request access, then decommission the account after their task is done.
Both of these options are more complicated to implement than standing access, but they allow organizations to enforce a policy where users by default have no ability to access privileged data and infrastructure. This removes much of the vulnerability associated with compromised credentials, as privileged access credentials have to pass through an additional verification step before they are granted to users.
For all of these methods, you should also consider implementing multiple types of privileges, just as you would with standing access. For example, people who need to reset a password should only be given access to the resources they need to accomplish that task.
You’ll need to understand in depth the access patterns across your organization, and continually monitor and audit your access levels to implement additional policies and ensure they don’t fall out of date.
JIT access helps reduce the security risk to your application, but it also requires infrastructure to implement and maintain.
Any situation where you want an auditable trail of who has access to your infrastructure is a great candidate for a JIT access pattern. An auditable trail of exactly who wanted access to each service and the reason they wanted to use it is built into the process of granting credentials because all requests for access are routed through a centralized authentication control system.
However, for small organizations where a few people regularly range very broadly over the architecture of the whole system, JIT access can be burdensome. You’ll need to consider the time that it takes to complete and maintain JIT access patterns, and weigh that against the cost of losing credentials.
JIT access might also not be the best pattern for an application or individual that needs constant and sustained access to certain systems.
It is, on the other hand, extremely useful for handling vendor access, or any other situation where people outside your organization need to be given access to your network. It’s well suited for roles in your organization that require occasional access to sensitive information, like resetting a password or marking data as do not delete, but often don’t require application privileges. It’s also helpful in development workflows where most actions are performed in a local development environment, but occasionally require access to production infrastructure in order to make specific changes or address bugs.
Just-in-time access is great for the security of your system, but it’s often not the default because it can be hard to implement.
To create your own solution, you need a centralized authentication system that’s able to generate and destroy credentials for all the other infrastructure in your organization while maintaining the secure flow of data across those systems. You need that system to be able to track who should have access, and audit every authentication-based task for every role within and outside of your organization to see what access it requires. You have to create a workflow users can follow to get access in a reasonable amount of time.
It’s also challenging to make sure that requesting access isn’t an unreasonable burden, particularly when handling high-urgency tasks.
It’s challenging but possible to create and maintain your own JIT access platform. This can work for smaller teams or in organizations that do not yet have complex compliance requirements. However, once the organization has more than just a few vital resources and the team has started to grow, custom in-house JIT access platforms can quickly become unmaintainable.
Organizations focused on growth or with more complex requirements will need a framework that will make it both easier and feasible to implement such a platform. That's where Sym comes into the picture.
Sym is the platform and framework that eases the burden of creating, implementing, and maintaining JIT access patterns. Sym provides templates and workflows that are customizable and reusable. As a platform, Sym gives you control over dynamic approval, access to the right resources at the right time, and drastically reduces the scope of access required.
Engineering teams can use Sym to easily create workflows in code and manage credential creation and access to sensitive resources as needed. As your teams begin to design how to implement a solution with Sym, they'll need to consider a few things.
First, you’ll probably want to develop a set of approval rules and guidelines that determine who can request access, what resources they need access to, the types of tasks that should be granted access, the permission levels that are required by those tasks, and finally, how long that access should last. Once those questions have been answered, your engineering team will set up the Sym platform to make it aware of the resources required for your organization. Then, you can author a Sym Flow and deploy it to make it available to your users.
Next, when everything is set up and ready, your users will be able to use Sym to access the resources they need. For example, they might use the Slack integration to request access from an easy to use modal within Slack, which then notifies the approvers via a channel. Once approved, the user will be notified, and Sym will handle the heavy lifting of providing access, whether that’s assigning an IAM role in AWS, creating an SSH session, or other types of integrations.
Finally, the user will be notified that their access has been revoked after they no longer need it. No manual intervention is required—unless they need to extend access to the required resources—Sym handles it all and makes an access log available for compliance and tracking purposes.
For more information about Sym Flows and Templates, check out the docs site. To contact Sym for a demo, get in touch with our sales team.
