Getting Started: Role & Access Discovery

strongDM manages and audits access to infrastructure.
  • Role-based, attribute-based, & just-in-time access to infrastructure
  • Connect any person or service to any infrastructure, anywhere
  • Logging like you've never seen

“Does this person in this role need access to that system?” 


That question is at the core of Role and Access Discovery—and a critical step to addressing privileged access management (PAM) and zero trust. You can’t restrict access without clarity around who actually has or needs access.


Which raises the next question—how do you define who has and needs access to each system? To that end, here are six distinct steps (and a free workbook) that you can use to get the process started. Before we jump in, some quick terminology:

  • Test Cases: Real-world examples from within your organization that specify who needs access to what and why. These will be used later in the process to validate your Slices and Roles. 
  • Slices: A Slice is a single use case for access, and may include access to multiple systems or apply to multiple Roles. For example, “reconfiguring all cache servers.”
  • Roles: An individual Slice or group of Slices that represent the access required for a specific task within your organization. Specific job titles may have multiple Roles based on the specific tasks they are responsible for managing. (Example: A cashier [job title] at a restaurant may need the receiving cash [role 1] and accepting orders [role 2] Roles.)

Step 1: Solicit Test Cases

To get started, we recommend reaching out to users to collect tangible examples of access required by Role. The idea is to start here, then move on to steps two and three while your stakeholders are simultaneously providing this information. 

The easiest way to collect Test Cases is to create a  "Test Cases" form and send it to anyone that likely requires access. Make sure to aim for a large number of examples, even at the risk of repetition and inconsistency. Refining and reducing these cases to a usable set of Roles and access will be significantly easier than generating a set from scratch.

The form itself should follow this framework:

  • As a _______ I need access to _______ so that I can _______.
  • Example: As a data scientist I need access to raw traffic logs so that I can ingest them to our data lake.

The intent is to use this information as a real-world starting point for access that needs to be provisioned based on your organization. 

Step 2: Gather your “who” for each list

Next, you’ll need to identify which individuals fit each list/profile. Who should be in the marketing profile? What about data science? This is a logical collection of individuals based on Role.

Often, it’s easiest to use a directory such as your HRIS, your email system, Active Directory, or an SSO—export a list of all users, ideally including their department and business title. You won't need to match every user during the discovery process, but you should use the list to identify possible gaps in your discovery, such as Roles that did not appear in your Test Cases.

Step 3—Gather your “what” for each list

Now you’ll need to identify your list of systems that employees need access to. For SaaS applications, check if IT or HR maintains a list of services considered during onboarding or offboarding, which can serve as a great starting point.

For Data and Infrastructure, you’ll want to use inventories of existing servers, databases, environments, clusters, applications, and data lakes that may exist in one or more of the following locations: public cloud listings, configuration management systems (e.g., Chef, Puppet, Ansible), provisioning systems (e.g., Terraform, CloudFormation, Pulumi), or k8s clusters. Seek out as many listings as possible, but expect the items to be of dissimilar types (e.g., S3 buckets, virtual machines, Snowflake instances).

Step 4—First rollup: Slices

Slices capture the access necessary for a limited use case across one or more resources (e.g., "reconfigure all cache servers"). You can use Slices to assemble Roles, which will closely align with a specific team member's responsibilities.

Step 5—Second rollup: Roles

Roles are easily understood groupings of access across your infrastructure. A Role may contain as little as one Slice but will often contain many. In most cases, users will have more than one Role. The collection of Roles that are given to a specific user will determine which systems they have access to.


Roles Slices Image
Example alignment of Roles and Slices.

Step 6: Review and Test

For each submitted Test Case, attempt to match the case to a Best Role. When you find that an existing Role confers too much or too little access, you may need to split an existing Role into two smaller Roles.

Get Started with the Role & Access Discovery Workbook

Download our Role & Access Discovery Workbook, an interactive tool that will help drive the process forward. The workbook includes:

  • The steps required to run a Role & Access Discovery project
  • Tabs that you can use to track who, what, Roles, and Slices
  • Example Test Cases that show how you can attempt to match the case to the best Role 

You can also check out our webinar, Getting Started with Access Management, where we walk through each of the steps and get hands on with how to use the workbook. Check out the webinar here.


About the Author

, Co-founder / CTO, originally developed empathy for Operations as a founding and pager-carrying member of many operations and data teams. As an Executive, he has led Engineering and Product in high-throughput and high-stakes e-Commerce, financial, and AI products. Justin is the original author of strongDM's core protocol-aware proxy technology. To contact Justin, visit him on Twitter.

logo
💙 this post?
Then get all that strongDM goodness, right in your inbox.

You May Also Like

SSH and Kubernetes Remote Identities
Supercharge Your SSH and Kubernetes Resources with Remote Identities
Learn how Remote Identities helps you leverage SSH and k8s capabilities to capitalize on infrastructure workflow investments you’ve already made.
strongdm program gif with animated title flashing onto the image
strongDM kicks it into overdrive
With the release of tighter integrations with Okta and Azure AD (or any SCIM-based directory service for that matter), you now have the ability to manage just-in-time, least-privilege access to your critical infrastructure right from your preferred identity provider (IdP), dramatically reducing the time needed to approve requests and grant access.
2022 glasses with confetti and year of access words
Welcome to the Year of Access
strongDM asked 600 DevOps pros about the state of infrastructure access today. Their response? It’s out of control. Here’s an overview of our results.
RBAC vs ABAC
RBAC vs. ABAC | Pros, Cons, and Major Distinctions
This article presents an overview of RBAC vs. ABAC, plus several additional models of access control, including PBAC, ACL, and DAC. You will learn what these methods are, how they differ from each other, and the pros and cons of each.
The access management challenge.
Access Management 101: Understanding Roles & Access
Here’s the scenario: On one side, you’re inundated with requests to provide access to critical infrastructure in order to enable teams to do their jobs; on the other side, you’re tasked with auditing access and ensuring that security to those systems is solid.