Atlassian Standard Permissions: How do I protect my sensitive data?

With this blog post I would like to point out Atlassian's stance on information availability. Atlassian believes that information should be available to all users of a product. I generally support this approach. However, it may be that certain projects or areas (e.g. HR topics) contain sensitive information and therefore should not be visible to all users. Especially with newcomers to the Atlassian world, I sometimes observe that the general concepts are not (yet) known and permissions are unconsciously assigned too openly.

Below are 3 stumbling blocks listed and described how best to avoid them.

Approved domains in the Atlassian Cloud

When a new person is added in the admin area, we can approve the whole domain right away. When adding a new person, we will see the following pop-ups:

If we click "Approve" at the second step, it means that in the future all accounts with email address of this domain will be able to access the Atlassian site without the need to add them additionally.

This can be very practical if the domain is a small company and we actually want everyone to work in the Atlassian Cloud. This way, we don't have to register the employees individually, but can regulate it via the domain.

But even in the case of small companies, this overall approval may mean that we quickly reach the limit of available licenses.
Another, arguably bigger problem is that there may also be information on the site that is not allowed to be visible to the entire company, but only to one team. And for this, we actually want to make sure that only people we've actually added have access.

My tips

Tip 1: Read pop-ups

I know 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 only the case in Atlassian products). But I recommend everyone to read the pop-ups. Especially in the admin area of Atlassian - there you should only approve what you really want.

If it's too late for tip 1, or it's too tedious to implement, you can fix everything afterwards with tips 2 and 3.

Tip 2: Control approved domains

We can find the approved domains in the admin area under Products > User Settings. All listed domains can be checked regularly for errors. So just click on "Edit" and check if the settings are correct. Do we really want to give access to all accounts of a domain if the admin approval is not activated?

Tip 3: Respond to notifications

By default, Atlassian sends a mail to the organization admins when someone gets access, or rather takes access. So if we receive a notification that someone has access that we have not authorized, we should react to it immediately. That is, we check the approved domains (see tip 2), edit the misconfigured person and remove him.

Default permissions in Jira

Basically, it is important to know that Atlassian gives access to all content to all licensed persons by default. If this is not desired, one must act.

The default permission scheme is configured in such a way that many rights are assigned to all logged-in users. This means that all logged in users can create tasks in all projects and by default they can see all tasks in all projects. This may not be desirable under certain circumstances. So if restricted permissions are desired for individual projects that contain sensitive data, a new permission scheme must be created. I recommend going through all the different permissions in the schema and considering who should have those permissions. It is best to assign permissions to project roles so that a schema can be reused by different projects and still authorize different people. For more information on project permissions, see this blog post.

Here is the list and explanation of the available permissions from Atlassian. The list is for Company Managed Projects in the Cloud, but applies just as well to the Data Center/Server products.
The most important permission for me is the "Browse Project", as this controls who can see tasks in a project and who cannot. The other permissions are then also often dependent on this and it is not so bad if the wrong users are assigned. Because if I can't see a task, I can't edit it.

Especially in the cloud: Team Managed Projects

In the cloud, in addition to Company Managed, there are also Team Managed projects. This allows teams to manage their projects independently without having to touch the general Jira configuration.

But even with these projects, all persons of a Jira site are authorized by default and see all tasks. If this is not desired, the access must be adjusted in the project settings. By default, the 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, you define in the admin area under "Area permissions" which groups are to be authorized by default in a new area. By default, Atlassian stores the confluence-users group there, which is also responsible for granting licenses to users and thus corresponds to the above-mentioned "all registered users".

If an area has already been created and sensitive data is to be maintained in it, the permissions can be adjusted at any time in the area settings under Permissions. Groups or individual persons can be removed or added.

If new areas are created regularly, which should not be accessible for all people, it is worthwhile to adjust this default setting and, for example, to store none, or only the confluence-administrators group.

Finally, an important detail about the confluence-administrators group: all people in this group automatically get read permissions to all content, no matter if they are authorized or not. If there is sensitive content in your confluence that even the admins should not have access to, I recommend the following:

1. Creates a new group (e.g. confluence-system-admins), which will have the same global permissions as the confluence-administrators group.
2. Include all people who should have Confluence Admin rights in this new group
3. Removes all people from the confluence-administrators group and ensures that this group remains empty

You are not sure how to best implement what you have read in your organization? Our experts will be happy to help you. Together with you, we analyze your security and authorization settings and adapt them optimally to your organization and needs. This will protect your sensitive information and ensure that only the right people have access to your data. If you need assistance or have any questions or suggestions, please feel free to contact us via chat or at: info@linkyard.ch. We look forward to hearing from you.