Need-to-Know Access and Atlassian Applications: Establishing Permissions, Roles, and Issue-Level Security

In the realm of Federal applications, maintaining a balance between collaboration and confidentiality is paramount. Not everyone can or should have access to every piece of information, especially in sensitive environments. This principle, known as "need-to-know basis," is crucial in the government sector.

The Role of Permissions and Issue-Level Security

Atlassian applications are intentionally designed to foster a high level of collaboration, so the default security settings are a little more open than some administrators are used to. However, controlling access to project-specific data or even particular issues within those projects is essential and can be  effectively managed through the use of permissions, roles and issue/space/page level security.

Project permission schemes in Jira allow application administrators to define who can do what within a project. Specific permission such as browse, assign, create, close, etc. are associated with users via a defined entity. Those entities could be individual users, groups, custom fields, roles, etc. In the case of a role being used, that enables the assignment of permissions to the project administrator as they control who is in what role. 

Project admins can then assign roles to individual users which grant the permissions related to  that project's permission scheme.

Additionally, Issue level security can be applied within a project to control who can view a specific issue. 

To learn more, read Atlassian’s Project Permission documentation. 

Implementing Effective Permission Schemes

By default, many applications allow all users to browse projects, which is suitable for less sensitive information. However, in environments where confidentiality is key, it is important to tailor who can view certain projects or issues. This involves:

1. Identifying who needs access to the information.
2. Determining the types of permissions required.
3. Applying these permissions to the relevant entities within the permission scheme.

That doesn’t mean each individual project needs its own permission scheme. On the contrary, it’s a best practice to have a few different permission schemes that can be shared between projects,  but are configured so the project admins can control the granted permissions through roles. Some examples of permission schemes include Wide Open, Project Level Control, Director Only, etc.

Case Study: On- and Off-Boarding in HR

A practical example of implementing advanced permission settings could be in managing HR processes, such as on- and off-boarding. Using Jira Service Management, we developed a process where managers initiate off-boarding through a portal. The process includes a question about whether the off-boarding is sensitive, indicating that the individual is being let go under less than optimal circumstances.

For such cases, we set up a permission scheme that restricts visibility of the project to HR personnel only, and within HR, only certain individuals can work on the issues. We further enhanced this by introducing a custom field named "Privileged Viewers," which is a multi-select field for individuals. If the off-boarding is marked as sensitive, an issue-level security scheme is triggered, adding the head of HR to the "Privileged Viewers" field, ensuring that individual is the only one to see the issue and can then designate other individuals to view and work the request.

Implementing Space and Page Permissions

Confluence has space and page level controls that enable you to limit who has access to certain information.

The application administrator can set a global configuration which becomes the default space permission on newly created spaces. Atlassian’s documentation does a good job of covering that information here, but there are still some best practices I have employed as a user and “gotchas” I have run into as an administrator.

For best practices, I try to ensure that at a minimum, my home page is accessible to all. I might then create a child page called Public and one called Private. The Private one would then have a page restriction set to control who can view and edit pages under that child. And under that child is where I typically see gotchas.

Confluence respects / inherits the permissions above it, so if I grant you read and write permissions to my Private child page, if you don’t have those same permissions at the Space level permissions for that space, you won’t be able to do anything. This can be  confusing because:

1. Other applications like Sharepoint do not behave that way.
2. When setting page level restrictions, the interface lets you choose any individual within the Confluence directory, regardless of their space permissions.

The other gotcha I have seen along those lines is the user not understanding that because the child inherits the parents permissions, you don’t have to set page restrictions on every page.

In the above example, under the Private page, I created a page titled Leadership. That page had read/write restrictions for just my leadership team. That way, anyone could reach my team's Confluence page and was able to view content within the Public page, without seeing a page title Private, while my team did and could access that content. The same then applied to the Leadership page—only my Leadership team could see it. 

Permissions Schemes Ensure Compliance and Safeguard Privacy

Setting up permission schemes and issue-level security in Jira, alongside managing space permissions and page restrictions in Confluence, enables organizations, especially within the Federal sector, to tightly control access to sensitive information. This ensures compliance and safeguards privacy. Such measures secure data and enhance operational efficiency by controlling information on a need-to-know basis.