Atlassian standard permissions: How do I protect my sensitive data?
With this blog post, I would like to draw attention to Atlassian's position regarding the availability of information. Atlassian believes that information should be available to all users of a product. I support this approach in principle. However, certain projects or areas (e.g. HR topics) may contain sensitive information and should therefore not be visible to all users. Especially among newcomers to the Atlassian world, I sometimes notice that the general concepts are not (yet) known and authorizations are unconsciously given too openly.
3 stumbling blocks are listed below and described how best to avoid them.
Approved domains in the Atlassian cloud
When a new person is added to the admin area, we can immediately approve the entire domain. When adding someone new, we see the following pop-ups:
If we click "Approve" in the second step, it means that in future, all accounts with this domain's email address will be able to access the Atlassian site without having to add them.
This can be very handy if the domain is a small company and you actually want everyone to work in the Atlassian Cloud. This means that we don't have to record employees individually, but can regulate it via the domain.
But even for small companies, this overall permit may allow us to quickly reach the limits of available licenses.
Another, arguably bigger problem is that the site can also contain information that should not be visible to the entire company, but only to a team. And to do this, we actually want to make sure that only people who we've actually added have access.
My tips
Tip 1: Read pop-ups
I know that Atlassian shows a lot of pop-ups and sometimes you just click on the biggest, colored button because of all the warnings and information (this is not just the case in Atlassian products). However, I recommend that everyone read through the pop-ups. This is especially true in the admin area of Atlassian - only what is actually desired should be approved.
If it is too late for tip 1, or if it is too tedious to implement, you can fix everything later with tips 2 and 3.
Tip 2: Check approved domains
The approved domains can be found in the admin area under Products > User Settings. All listed domains can be checked regularly for errors. So just click on "Edit" and check whether the settings are correct. Do we really want to give access to all accounts on a domain if admin approval is not activated?
Tip 3: Respond to notifications
By default, Atlassian sends an email to the organization admins when someone gains access, or rather gains access. So when we receive a notification that someone has access that we don't have permission to, we should respond immediately. That means we check the approved domains (see tip 2), edit the misconfigured person and remove them.
Default permissions in Jira
Basically, it's important to know that Atlassian gives all licensed people access to all content by default. If this is not desired, action must be taken.
The Default Permission Scheme is configured in such a way that many rights are granted to all logged-in users. This means that all logged-in people can also create tasks in all projects and, by default, they also see all tasks in all projects. Under certain circumstances, this may not be desired. Therefore, if restricted authorizations are required for individual projects that contain sensitive data, a new authorization scheme must be created. I recommend going through all the different rights in the scheme and considering who should have these rights. It is best to assign the rights to the project roles so that a scheme can be reused by different projects and still authorize different people. Further information on project permissions is available in this blog post.
Here the listing and explanation of available Atlassian permissions. The list is for company managed projects in the cloud, but also applies to data center/server products.
The most important permission for me is "Browse Project", as this governs who can see processes in a project and who cannot. The other authorizations are then often dependent on this and it is not so bad if the wrong users grant them. Because if I don't see a process, I can't edit it.
Especially in the cloud: Team Managed Projects
In addition to Company Managed, there are also Team Managed projects in the cloud. This gives teams the opportunity to manage their projects independently without having to touch the general Jira configuration.
But even with these projects, all people on a Jira site are authorized by default and see all processes. If this is not desired, access must be adjusted in the project settings. By default, project access is set to "Open", if not all licensed persons should see the tasks in the project, the authorized persons must all be included in the project and the project access must be changed to "Private."
Default Permission Settings in Confluence
In Confluence, it is defined in the admin area under "Area permissions" which groups should be authorized in a new area by default. By default, Atlassian stores the confluence-users group, which is also responsible for granting licenses to users and therefore corresponds to the "all logged-in users" mentioned above.
If an area has already been created and sensitive data is also to be maintained in it, the authorizations can be adjusted at any time in the area settings under Authorizations. Groups or even individual people can be removed or added.
If new areas are regularly created which should not be accessible to all people, it is worthwhile to adjust this default setting and, for example, to store no group or only the Confluence administrators group.
Finally, an important detail about the confluence-administrators group: all people in this group automatically receive reading rights to all content, regardless of whether they are authorized or not. If your Confluence contains sensitive content that the admins should also not have access to, I recommend the following:
- Create a new group (e.g. confluence-system-admins), which has the same global authorization as the confluence-administrators group
- Include everyone who should have Confluence admin rights in this new group
- Removes everyone from the confluence-administrators group and ensures that this group remains empty
Are you not sure how to best implement what you have read in your organization? Our experts are happy to help you. Together with you, we analyze your security and permission settings and adapt them optimally to your organization and needs. This protects your sensitive information and ensures that only the people you want have access to your data. If you need assistance or have any questions or suggestions, feel free to write to us via chat or at: info@linkyard.ch. We look forward to hearing from you.
