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.
We often act as though cyber security and ITSM are completely different areas, with work carried out by different people for different purposes. In fact they both contribute to how we run and manage IT, and they need to work together to provide the protection we need to operate securely in a modern digital age. – Joe the IT Guy
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.
Guide to Jira Service Management 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:
- Jira System Administrators gives the assigned user groups access to all administration functions;
- Jira Administrators is similar to the previous one, though limited. The assigned user group still can perform most of the actions included in the System Administrators permits but import, export, some more advanced configurations, etc.;
- Browse Users is kind of tricky because it enables to select users or groups, share the issues, as well as make all this data in the system visible to the assigned user group. So, be careful when granting this and remember to make it available to those with the right authorization level within the service desk;
- Create Shared Objects enables us to share dashboards and filters with others.
- Manage Group Filter Subscriptions;
- Bulk Change comes in handy when we have to change or delete multiple issues at once.
Global permissions override the Permission schemes. Because of that, we should always grant adequate general permissions to user groups before defining which actions they can perform within a project. And if we can’t give some permits to the users, it’s probably because they’re not assigned to the specific global permission.
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:
- Project permits define which actions a user can perform within the service desk project, i.e. if they can administer a project, browse projects, interact with customers, etc.;
- Issue permissions decide what users can do on the issue level, for example, if they can assign issues or be assigned to them, close them, change the reporter, etc.;
- Voters and Watchers allow to see the voters and watchers of the issue, as well as manage the latter;
- Comments permissions enable users to add comments to an issue, delete them, edit, etc.;
- Attachments permits include the most basic actions, such as adding attachments or delete them;
- Time tracking gives users the possibility to log their work, edit or delete it. This type of permissions is dedicated only to the service desk team, developers or administrators project role.
Remember that we can grant numerous permissions to each user group, project role or other variables available to select.
Project roles are useful for defining specific team members for each project. Referencing project roles (rather than users or groups) in your permissions can help you minimize the number of permission schemes in your system. – Atlassian
Issue security schemes
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.
Customer permissions and Organizations
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.
Advanced safety measures
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:
- Customer Portal – seeing as not all our users need to see some Customer Portals, we can limit their visibilities to only those who should have access to them. For example, if we have customer portals for both external and internal users available in the service desk, we should ensure that only our employees will have access to the internal one. This will also work even when an external customer knows the link to the internal portal because they will be blocked from entering it;
- request types – the same goes for the request types. For instance, the higher-ups in the company should be able to ask for a business car or more valuable hardware. This way, i.e. the interns won’t even see this request type when browsing the service desk;
- fields – similarly to request types, some fields should be available only for those user groups that have the appropriate authorization to access them, i.e. only those who belong to corpoplanet-directors user group may share the requests with other users and view the request participants;
- options – if we have a field in which the requester needs to define, i.e. the budget for a hotel room, we can make the most expensive option to choose available only for the directors;
- SLAs – some user groups may require to view the progress in the realization on the request, so displaying SLA measurement to those specific groups may be a good idea. Also, it will ensure that users from other groups won’t be able to see this metric even if they’re participating in the request.
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.
Safe and sound Customer Portal
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.
Try Extension for Jira Service Management
Take a free 30-day trial from the Atlassian Marketplace!