Vandelay Chronicles: This is the Story of Cal
In the last installment, we learned about Vandelay Industries, and how their lack of a just-in-time (JIT) access-management solution was a boon to engineer Alice’s “coffee on the lake” moments, while being a real bust to Jack and Cal in Compliance and IT.
We saw how without a solution in place, requests for escalated access could take forever, resulting in an inefficient workforce and slow customer service response times… not to mention access approval grant/deny/revoke audit trails and on-demand reporting capability.
Trustle to the Rescue
Upon implementing Trustle’s JIT (just-in-time) solution, Alice was able to do her job faster and more securely, all while increasing customer support response times.
In this installment, we revisit our friends at Vandelay Industries to see how they are making the most out of their Trustle implementation, including the newest feature: Fine-Grained Access and Provisioning controls.
Frictionless Roll Out
Going from no ID access escalation process, to an easy to use, auto-revoking, JIT access model with Trustle was easier than the folks at Vandelay expected. This is because JIT was rolled out in thoughtful, friction-free steps…
The first priority was to move users from “always provisioned” access, to JIT; that is, giving them the access they need when they need it, and auto-revoking it (by default, after eight hours) when they don’t. Users could request the access JIT directly through Trustle, or via the Slack app.
The second priority, as this was a new software rollout, was to allow the JIT access requests to be auto-approved, with no stakeholder intervention required. In lieu of approvals, access requests are audited and available for review, or ad-hoc reporting.
This access control workflow was defined as “Preset 0”, and set as the default behavior for access to all systems Trustle manages. Using this walk before you run approach, it made the transition to a JIT access system much easier for users, system owners, and admins.
With these changes in place, users were onboarded to the system, and kept at zero standing privilege (ZSP) until least privilege access (LPA) is needed to do their jobs. After users are provisioned with the access, it is automatically revoked (until the user re-requests it).
By switching to a ZSP to LPA access provisioning model:
- Attack surface is reduced by 75% !
- Request, approval, and access patterns are tracked and available for auditing and reporting.
Fine Grained Access and Provisioning, Take One!
The team began with no approvals in place to get users acclimated with Trustle. Then Cal, the IT Manager, identified some higher sensitivity permissions (AWS Groups) in their AWS environment which granted access to buckets holding PII and virtual machines running the company’s ERP software.
For AWS Groups only, he decided to mandate manager approval for access. He only wanted managers to get involved in the approval process every three months, so he set Approval duration to three months.
Once approved, a user could have access to these resources for up to four hours at a time, until the system auto-revoked them. As long as the user was within the three hour approval window, they could easily re-request and regain four hour access to them without manager involvement.
Cal also wanted to have a human in the loop at provisioning time (not deprovisioning) for these higher-sensitivity resources, as a final oversight when granting access to them.
For all non-AWS Group permissions, they would inherit the initial, global setting (Preset 0) of no approval required, eight hours until auto-revoke workflow. From the AWS group-level down, this more stringent workflow would now be applied.
With a couple clicks, Cal was able to configure manager and IT oversight when these permissions were requested.
At this point, Cal’s access and provisioning configuration looks like this:
- Preset 0: For non critical resources, principals can request and be granted immediate access to them as needed, without any sort of manager approval or IT provisioning oversight. All permissions at Vandelay will use these defaults, unless overridden with another preset.
- Preset 1: For AWS Group permissions which enable access to PII data on AWS, manager approval is needed every three months, with JIT access grants auto revoked every four hours. Provisioning oversight is required, but deprovisioning oversight is not.
- For both, there is an audit trail each time a permission is requested, approved or denied, and provisioned or deprovisioned.
This configuration keeps the manager and system owners in the loop when their teams request access to more sensitive systems, but allows for a more streamlined and audited access to less sensitive data.
Enter a new Cloud Provider
Vandelay’s IT team decided to go multi-cloud, and bring in GCP in addition to their existing AWS infrastructure.
All of the access Cal wants to manage with Trustle in this new GCP environment is in the form of GCP security groups. There are over 100 of these new groups, and Cal wanted a quick way to force manager approval (in the same way he did earlier with AWS groups) on all except five of them – the dev and test-related group permissions.
For the dev and test-related group access, Cal didn’t want to burden the system owners to be in the loop to provision or deprovision access post-manager approval. He wanted access to these permissions to be as streamlined as possible. As a hedge to not requiring approvals, he did want to also limit the access duration to one hour.
Fine Grained Access and Provisioning, Take Two!
Trustle’s new provisioning and access controls allow for maximum flexibility at the global, system, and individual permission levels. And yes, you guessed it, implementing these new GCP-level requirements with Trustle is easy by using the new fine-grained provisioning features…
- Cal will assign Preset 1 to the new GCP integration as a whole. This will mimic the workflow his users encounter with AWS Groups, but in this case, with all GCP resources.
- For the five specific dev and test-related groups, Cal overrides the access duration on them from Preset 1’s default of 4 hours, to one hour.
Fine Grained Access and Provisioning, Take Three!
As part of their multi-cloud exercise, Cal onboards a new Azure environment into Trustle. Vandelay uses Azure right now more in a non-production / experimentation sandbox, so to keep things simple, he wishes to have the no approval required workflow (Preset 0) applied to it.
Because Preset 0 is the default, top-level permission, he doesn’t need to make any changes after he adds it to Trustle. Azure inherits the top level preset (unless it's manually overridden, as we saw with GCP and AWS).
As we saw, Cal can now set defaults globally at a top level. For each integrated system, or portion thereof (resource type, individual resource, etc), he can override those top level defaults. Whether its visibility, sensitivity, provisioning, deprovisioning, or duration settings, they can now inherit defaults, and be overridden individually, enabling fully customized access request workflows!
Cal and his users are now happy campers with Trustle’s new access controls!
More About Trustle
Read more about this new feature and try Trustle today! Sign up for a free trial in just minutes. And don’t leave without checking out our blog for ongoing thought leadership and expert insights on identity and access management, cybersecurity and data security topics.
