User Access Reviews are a necessary part of the security and compliance journey. When done right, enabled by automation, UARs can become a powerful tool to reduce standing and unused access. At ConductorOne, we believe that security and compliance should be continuous, and that UARs can be triggered exactly when they’re needed, for example when there’s a role change, someone on-call, or a departure—in addition to being run on a periodic or quarterly cadence.
If you’ve ever been a part of running your company’s UAR campaigns, then you know the devil is in the details. So today, we’re breaking down and exposing all of our UAR scoping details so you can see how easy it is to set up a UAR campaign.
Let’s dive in!
Scoping your campaign with fine-grained reviewer workflows
Certification workflows are the starting point and foundation for your UAR campaign because they define how you certify access. This is where you’ll define the reviewers, how many steps are in the approval process, whether or not you’ll start with a self-review, and whether or not the review can be reassigned. You can make the workflow as granular as needed, for example all the way at the entitlement level, the application level, or at the campaign level. ConductorOne will always default to the most specific workflow and move up the stack if needed (i.e. entitlement → application → campaign).
This is important when considering more critical data sources, for example access to assume-admin-roles in production environments where you could create an entitlement level workflow with a self-review to confirm you still need that access, a manager review, and an application owner review that cannot be reassigned at any step. If access needs to be changed as a result of the review, ConductorOne can kick off revocation automatically.
Adding filters and parameters to focus what’s in scope
Creating a campaign is as easy as giving it a name, adding owners, turning on reminder notifications, and selecting a campaign level certification workflow (but remember, ConductorOne will default to the entitlement level or app level workflow first and foremost).
Here’s where the fun starts… now you need to select what’s in scope for review. ConductorOne uses robust data modeling to pull in and map all sorts of identity data from each app. For example you might want to select certain groups within Okta, projects within GCP, or repositories within GitHub, to name a few. ConductorOne gives you the ability to easily select the app, role, group, or resource, and filter to exactly what you want to review. You can even add attributes, or metadata tags, like risk level and compliance framework to any entitlement or app to easily pull in anything tagged with SOC2, for example.
You can get even more granular by setting up campaign parameters to review access that could be specifically problematic. For example, you can select every user within your IdP that was disabled, but still has an active account.
All that’s left to do is prepare your campaign and review the scope. Traditionally, scoping and setting up campaigns like the examples above would take weeks of time from collecting identity data from each application, mapping it all out in excel, to preparing the review process. With ConductorOne it takes minutes, and you have the ability to scope it as granular or high-level as needed.
Stay tuned because next week we’re going to take our UAR functionality to the finish line and dive deep into campaign execution, the reviewer experience, and reporting to auditors!
