User Roles and Permissions

Nearly every organization has security and compliance requirements around data access. IT Operations teams must adhere to a standardized process to correctly roll out tools and resources to all users with respect to on-boarding, configuration, permissions, and security — especially as organizations scale. It’s table stakes to implement a permissions model that ensures users only have access to the data required to perform their respective roles.

Locking down user access to different enterprise resources is foundational for upholding security standards and ensuring organized and purposeful resource provisioning. That’s why enforcing user privileges with permissions has long been an IT governance best practice,  ensuring that appropriate levels of data access are granted based on user roles.

Permissions models typically follow the principle of least privilege. This is a standard concept in security practices that requires that any module (i.e. a user, process, etc.) only be granted the minimum level of privileges required to execute its intended function. Abstracting data so that users don’t see details that are nonessential for their roles also improves productivity, as users can focus solely on the information that matters. Organizations also bolster this with the separation of duties concept, which disseminates critical responsibilities to more than one person or department to manage risk, error, and fraud. Most permissions models build on a predefined access control list, a set of data that defines which access rights each user has to specific system objects. When a request is received, the tool will check the access control list for its associated security attribute to ensure the requester has the permissions required to access the resource.

With any tooling investment, organizations seek solutions where teams are using the same tooling in the same capacity. When teams start employing their own solutions (Shadow IT), locking down access and enforcing behaviors to meet organizational requirements becomes very difficult and can quickly complicate things such as billing. In the optimal scenario, a central admin has the ability to control the level of access users have through a single instance of the tool, and the tool meets the organization’s policies and guidelines as related to information security and data protection. Admins are thus able to track activity across all of the different teams, while teams can only manage the specific objects they need access to.

When choosing a solution that upholds permissioning standards, benefits that tools and process owners seek include:

• The solution should fit different types of teams
• The solution should align with existing security policies
• The solution should integrate with existing infrastructure and user repositories defined in their identity management solution (e.g. AD / LDAP). This manages access across applications that align with organizational hierarchy and structure, definition of user groups, and distribution of access privileges
• The solution should associate outcomes, usage, and other metrics with specific users and teams to show the business improvements and optimizations made

Why do user permissions matter in incident management?

Just as with any other tooling investment, user permissions matter a lot in any incident management solution. They’re critical to protecting data, especially if there is any sensitive information around any incident that must only be accessible by a specific individual or team. They help teams adhere to compliance requirements around data access and they improve user and team productivity when responding to issues, as people aren’t trying to parse through a ton of information that’s irrelevant to them.

When it comes to enterprise permissions, the model must be highly scalable. This way, administrators can map access to groups of users, instead of having to manually configure access for each individual user.

Here are the key reasons why it’s important to ensure incident management roles and permissions are aligned to your organizational requirements:

• Enhance security across all objects. Only admins and account owners should have the centralized ability to lock down and secure read/write access to specific objects within the incident management solution (e.g. schedules, escalation policies, incidents that are aligned to specific IT services, etc.). This ensures users can only view and perform actions on objects they are supposed to.
• Increase user productivity. Teams gain productivity as individual users access only those resources specific to their role. As users no longer need to toggle through every single object in order to find the relevant ones to interact with, they can focus their attention on data points that actually matter to their role.
• Protect data and meet compliance requirements. Organizations of any scale are better positioned to meet compliance requirements when designated admins or account owners can exercise security principles.
• Granularly define access. Admins should manage access to various objects within the incident management solution across independent teams. This is done through the creation of custom user roles, or if a more scalable solution is required, then access permissions should be defined for groups of users requiring the same set of functionality. Access to specific objects can be layered on top of a base role to maximize granularity,  enabling admins to manage and secure resources without over or under-provisioning user privileges.
• Enforce API access. Many incident management solutions pull in third party monitoring data and can extend functionality via an API. Being able to customize the incident response workflow to meet specific needs and shave off time during response is an important value for most who operate IT services. As such, it’s important to leverage an incident management solution where API access is automatically enforced across the entire platform including the API. API keys retrieved through the platform should be authorized to only provide a user the level of access to objects in the API as are defined in the pre-existing role.

Who needs to consider permissions?

Permissions should be a priority for companies of all sizes. Your organization may be a large enterprise with a central operations team and independent siloed teams. Or, it may be a mid-sized organization with growing infrastructure complexity and distributed ownership over operational responsibilities. Regardless of your organization’s size and mode of operations, permissions matter to any stakeholder who is responsible for tooling investments and for centrally managing implementations.

They also must be considered by individuals who are both administrators and users of the tools, such as NOC, CentralOps, and DevOps managers. These individuals need to manage visibility and access to objects across independent, siloed teams, and do so in a nimble way. This way, their teams can only interact with what they need and aren’t stuck submitting tickets to HelpDesk every time they need access to various objects.

What permissions does PagerDuty include?

PagerDuty’s Custom Permissions enable capabilities around powerful security and access control. There are two different models within PagerDuty that maximize flexibility in how permissions can be granted and modified. First, admins and account owners can create custom roles for specific users, ensuring users are only granted the permissions they need. The second option enables admins and account owners to enforce permissions and visibility control at the team level as well, to improve efficiency and scalability when dealing with large groups of users. Organizations can exceed tight compliance requirements and exercise full control and management over user access and level of interaction with individual objects.

There are three fixed roles in PagerDuty that cannot be granted any additional access on top of their existing privileges:

• Account Owner — Full access to create, update, and delete objects, including a user’s permissions. This access cannot be restricted. Can also access the Billing page.
• Global Admin — Full access to create, update, and delete objects, including a user’s permissions. This access cannot be restricted.
• Stakeholder — Can view objects, but cannot make any modifications. Cannot be given Additional Permissions.

Any user that is not an Account Owner, Global Admin, or Stakeholder is assigned one of the following four base (flexible) roles, on top of which they are granted the level of access they need to specific objects. A single user can have multiple roles to define the level of access they get to different objects in PagerDuty. For instance, an individual can have Manager access for objects required for a team they manage, but have Responder or Observer access to other services, escalation policies, etc.

• Restricted Access — Users can’t see anything in the account until they’re added to a Team and assigned a Team role.
• Manager — Full access to create, update, and delete objects and all of their configuration.
• Responder — Can take action on incidents and create overrides.
• Team Responder — For objects belonging to their teams, able to take action on incidents, create overrides, and set maintenance windows.
• Observer — Can view objects, but cannot make any modifications.

» Learn more about permissions in PagerDuty at our Support Knowledge Base here.

Learn more about team and user-based access controls in incident management

PagerDuty enables teams to streamline permissioning in incident management with scalable team-based permissions and visibility control, highly granular user permissions, simple user association between PagerDuty and other tools such as ChatOps, and more. Try it out now for yourself with a free 14-day trial.

We hope these resources enable you to optimize permissions in incident management so users and teams can administer independently while operating and taking action on issues effectively.