In the ever-evolving landscape of cybersecurity in the cloud, Just-In-Time (JIT) access has emerged as a critical feature for managing permissions and minimizing security risks. However, not all JIT implementations are created equal, especially if the nature of the access doesn’t address the root cause of the risk that organizations are trying to address: static or standing access.
Understanding “Just-In-Time” Access
At its core, JIT means that something only happens when it absolutely needs to, never before. With JIT access, a user’s ability to access a resource is granted exactly when required. At all other times, the user cannot access the resource.
The intent behind limiting this access is to ensure that the ability to see or edit sensitive data and resources is temporary and tightly controlled. This is done with the goal of enhancing security and reducing risk by limiting and monitoring the number of users who can access these resources at any given time.
JIT Access Isn’t the Same as JIT Permissions
Existing legacy and even newer PAM solutions claim to offer JIT, but their approach often falls short of truly minimizing risk. That’s because these solutions provide JIT access, not JIT permissions.
While users gain access to requested resources “just in time,” what they’re really gaining isn’t a change of permissions to their individual user account. What they get instead is temporary, “just in time” access to a privileged account that allows them to complete their tasks.
The issues with this approach to JIT boils down to three things:
- Persistent Accounts: Even with limited access to these accounts, the account exists permanently on the system. This represents a significant security risk if the account or the system itself is breached.
- Static Permissions: Alongside these accounts are the persistent, privileged permissions associated with them. In the event of a compromise, these permissions would allow an attacker greater power to move through the system.
- Credential Vaulting: This approach essentially treats privileged access as just-in-time credential vaulting. These credentials are never exposed directly to the user but are used to create a pre-authenticated session. Best practice for securely accessing cloud resources via role assumption does not work with this legacy vaulted approach.
Unique JIT Approach for True Zero Standing Privileges (ZSP)
So, what does secure JIT really look like? Instead of focusing on access, to be truly secure requires JIT privileges. Let’s walk through an example using Salesforce.
Let’s say you’re a Director of Sales. Your normal, day-to-day Salesforce use involves reading existing reports and adding notes to accounts. But on occasion, you need elevated privileges to create or edit an object or group. Such actions are limited to a select number of Salesforce “power users” or admins for your company.
A PAM solution with JIT access handles this in one of three ways. The first way assigns your Salesforce account all your possible permissions and then makes you go through the PAM software every time you wish to use Salesforce—even if just for your daily report viewing.
The second approach is to use a shared privileged account which contains the sensitive permissions. To perform a privileged action, you or anyone else in your company approved to do so are given temporary access through the PAM into the same static, privileged account. There may be further restrictions on the number of users who can check out the shared account simultaneously.
The third method creates a second, privileged account just for you. You use your regular account for day-to-day activities. Then, when you need to perform a privileged action, you must sign out and go through the PAM to access your separate privileged account. When you are done, you will have to again sign into your regular account and resume your normal activities.
All three of these methods are cumbersome. They are also less secure as in each case, there is an account with statically assigned sensitive permissions. The first approach has the additional drawback of not really following the principle of least privilege as your account would always have the administrative permissions, even if you never use them.
Britive takes a different approach: we dynamically manage the permissions themselves, rather than gating access to an account with static permissions.
Through Britive, users temporarily request only the permissions required for a task. Britive securely enables the necessary permissions JIT directly on the user’s account. Users access the systems and resources they need to perform their jobs like they typically would.
In our Salesforce example, this means you can request your admin permissions only when and as needed. Britive tells Salesforce to temporarily add them to your account, then automatically removes them when they are no longer needed, or the configurable allowed time expires. You do not need a separate account, and there are no standing admin permissions associated with your account or any shared or single purpose privileged account.
This approach to JIT access is unique for several reasons:
- Dynamic Permission Delivery: There are no static credentials. Instead, Britive manages the actual permissions directly in the resource, providing them for the user just in time, only as needed.
- Zero Standing Privileges: Permissions are only granted when needed and are removed automatically afterward. This ensures that no privileges exist when they are not required, minimizing the attack surface and risk of credential misuse.
- Role and Responsibility Adaptation: Britive ensures that even as a user’s roles and responsibilities change, static privileges are not required. Instead, permissions are dynamically assigned as needed.
- Principle of Least Privilege: Users can have separate, distinct profiles for different levels of access. For day-to-day activities, they can have basic access. When they need elevated privileges, such as power user functions, they can check out these permissions just in time. Once their task is complete, elevated access automatically expires. The principle of least privilege is truly realized as only the necessary permissions to perform a task are temporarily applied to an account.
By delivering permissions dynamically and only when needed, Britive eliminates the risks associated with static credentials and standing privileges. Granular permissions control enforces least privilege access for any task.
Removing permissions until and unless a valid, authorized need is present helps ensure data and resources are better protected. JIT permissions delivery should be a key component in your CIA triad for data protection. This approach not only enhances security but also aligns with modern zero-trust principles, making it an ideal solution for today’s dynamic and complex cloud environments.
For more insights into Britive’s innovative JIT privilege management and how it can secure your access to resources across your environment, regardless of configuration, learn more about the platform’s Cloud PAM capabilities.
Have specific questions and use cases? Schedule time to chat with a member of the team for a more detailed demonstration.
