Securing Jira Service Management with permissions

 Originally published August 12, 2019, updated on May 11, 2022

Online security is not only about the technology and processes, but also about the people. Especially that over 95% of security breaches happen because of human error. And such error may give unauthorized people access to vulnerable data that not only our customers but also our employees entrusted us with. The best example is the recent news about big international corporations having a misconfigured Jira expose their servers. The same may happen also in case of service desks, seeing as nowadays we’re in such a hurry to better resolution time that they may become at risk of cyberattack. 

Just like we should care about our online security, we also should make the best use of the tools that the modern digital age gives us. That’s why, in this article, we focus on making Jira Service Management a safe haven for your customers and employees’ data with customer permissions.

It’s important to build your protection steadily. Start from the most basic things like defining project roles, organizing users into groups and organizations, specifying their roles within the service desk, creating permission and issue security schemes, and assigning them to each project.

Each user can have a different role within the service desk: administrators, service desk team or customers. And so, the Jira administrators may create and configure projects, customers raise requests, and agents from the service desk team can comment internally (visible only on the issue) or share their comments with customers. Moreover, we can assign more than one role to each user. Remember that the new users (invited via e-mail or who signed up through the Customer Portal) are automatically assigned to Service Management Customers project role.

There are three user groups out of the box:

If we have an internal customer portal, we can classify our users according to their position that grants them a specific authorization level. So, Jira Admins will go to the jira-administrators group because they need all the permissions that are necessary to do their job properly. And a customer support manager or even a team leader of each service desk team will be assigned to i.e. jira-service-desk-project-admins.

It’s worth to remember, though, that Jira Service Management also enables us to create Organizations, but we’ll discuss it later on.

The first thing to remember after creating user groups is to assign them the right permissions that apply to all projects on our instance. We can grant six permissions:

We should pay close attention to what project permissions we give to the users, both internal and external, of our Customer Portal. For example, our clients shouldn’t have access to every part of the platform, especially to the Jira Administrator menu where they would be able to butcher the most important configurations. That’s why Jira Service Management has various permissions we can grant to the users depending on their role, user group they belong to or other variables.

As we can see from the graph, there are six groups of permission types that the user can get:

Remember that we can grant numerous permissions to each user group, project role or other variables available to select.

Another key point is to define authorization levels for viewing issues. To specify, issues are assigned specific security level which includes a group of users permitted to use them. This way, only those with the right authorizations will be able to access the specific ticket. The variables here enable us to set the access not only for options varying from application access to user and group custom field value to project role and single user. By creating these schemes, we restrict Browse Project permissions in a way. As Browse Project permits users to see all the issues within a service desk, we can limit their visibility by assigning appropriate security levels to them.

Remember that each level may include numerous users, groups or project roles, depending on who needs the specific authorization.

Basically, we can define who may become a customer of our Portal, as well as with whom they can share a request. We can set this up in Project Settings under Customer Permissions.

Also, we can add users to Organizations. Those users invited to Organization and not created in Jira Service Management won’t be added to the jira-service-management-customer project role. Also, Organizations enable customers to share their requests with other members of their organization. For example, those who are part of the corpoplanet organization will be able to share their requests from a service management project dedicated to their company with another employee included in it, however, only a specific number of its users will be assigned to a specific project role.

Whenever a new customer joins the service management, they get restricted access to the Customer Portal. As a part of an organization, these customers aren’t added to the Service Management Customers project role, but they can still raise requests in all projects their organization is assigned to.

To keep ourselves safe from online security threats and boost the usability of Jira Service Management, we should also make sure that we have some more advanced permissions in place. Just to be sure, we should go more in-depth into the Service Management accessibility and define the visibility of its other parts to various user groups. In particular to such elements as:

This specific set of advanced permissions is available in Extension for Jira Service Management app.

If we want to use Visibility feature of the app, we should create additional user groups. Creating two or three user groups per Organization is the most effective way of managing customers because then we’ll be able to grant them appropriate permissions, i.e corpoplanet-directors will be able to do more within the service management than corpoplanet-managers just because they are more inclined to make some decisions. And to make this even easier on us, we can synchronize Organizations with user groups with a feature provided by Extension. 

For example, we have a service desk project called Expeditions available for a few user groups, including corpoplanet-directors and corpoplanet-astronauts. Users from corpoplanet-directors will see only request types, such as Introduce an expedition, Register astronauts, Cancel expedition, etc., while those from corpoplanet-astronauts will have access to a different set of request types, i.e. Enter for clearance, Sign up for qualification exams, etc. Both groups also will have some shared request types like Order gear and Order equipment. This way, we ensure that a specific user group can choose from the most relevant requests for them.

Sometimes, simple safety measures as set permissions and limited visibility of some elements for specific user groups is a good start in cybersecurity. But, making sure that our Customer Portal and thus our customer’s data is safe and secure is a long-term goal. That’s why we shouldn’t limit ourselves to the basic service desk protection supported by good anti-malware software. Even adding such things as self-service or automation to our service desk may help secure it. Also, building a process that includes risk and incident management is a necessary precaution against online security threats.