The daily challenges for system administrators
Many of the tasks performed by the system administrator can be time-consuming, such as maintenance and configuration of user accounts, authorizations, and access rights. In your regular work, you keep complex systems in top condition and always bear a great degree of responsibility – especially when it comes to complying with data privacy laws. After all, even minor violations can result in heavy penalties. And as the person in charge, you are responsible for any errors that occur in your system.
In order to guarantee the security of the system, it is essential to quickly gain insight into which user (groups) have which rights, so that you can trace any incidents or peculiarities and follow them up appropriately. But managing permissions for individual user IDs in Jira can be very confusing, especially when there are many users to deal with.
Many clicks are necessary to find out which employee has access to which dataset and how exactly the permissions are assigned.
What are (Jira) permissions?
In general, permissions define the access that a user or user group has to a specific resource (a project, an issue, etc.). Permissions can vary from object type to object type. However, the common permissions are: reading, editing, changing owner, and deleting.
In Jira, permissions are the settings that control what users can see and do within specific applications.
Permissions address for example the following questions:
Who can create new projects?
Who has access to which project?
Who can create issues?
Who can post a comment?
Who can run a sprint?
Who can watch which issue?
Who can delete tickets?
The type of permissions differs within Jira applications and from project to project. Consequently, there are numerous permissions that a person can have. The best practice for Jira is that rather than assigning permissions at the user level, to group the permissions into a role. In this way, you can create a role which should be the “actor” for a particular set of changes in a project, such as Scrum Master, who can start, close and assign work to a Sprint. This makes sense in the context of the project administration. But from the data management point of view, it can mean that it is more difficult, at a glance, to understand exactly how much permission, and to which areas of Jira, that an individual user has.
And this is where our GDPR tool becomes interesting for system administrators.
Permission Monitoring in Jira
Imagine that you as a system administrator want to find out which projects an employee has access to. If you use Jira without our app, you can’t see in the Jira User Management which projects the employee has joined. Group assignments are also not visible at a glance. You can’t just select a specific group and see all the permissions in the system.
It takes a lot of work to find out all permissions from one person in the system. Without GDPR (DSGVO) and Security for Jira, system administrators have to look in every single project. It takes many clicks and even more time to get the information they need — and then it’s not presented in an appealing visual way.
Problems with Jira Permission Monitoring
Lack of an overview of thousands of permissions
Security vulnerabilities occur due to incorrectly assigned permissions
Critical audit findings during tests, if authorization assignments are not traceable
Lack of acceptance of the role model in the departments
Implementing Actonic’s GDPR tool can shed light on all the darkness of Jira authorization monitoring.
Permission Monitoring with GDPR (DSGVO) and Security
The Permission Monitoring module provides the ability to track and view 2 types of permissions:
Current permissions: This is a list of all current project permissions for a specific user, group, or an entire project.
Historical permissions show a history of all permission changes for a user, group, or project.
Current permissions – filter options