Leveraging Data Security in Jira Using Logical Separation

Our previous blog discussed the benefits of implementing a logical separation to protect data in Jira and Confluence, and factors you should consider before doing so. Here, we will cover some of the architectural and configuration considerations when implementing a logical separation.

How can you implement a logical separation in Jira?

Many of the principles covered below for a secure logical separation also apply to both cloud and data center instances.

Manage classification in centralized AD groups

When implementing a logical separation, there are two considerations:

1. What data should be restricted
2. Who should and should not be able to view that data

Here you would want to define your classifications of data such as ITAR, PII, proprietary information, etc.

Once you establish your data types, you can define which users can view each class of data. This could mean dividing your users. You can divide them into internal and external users, or U.S. persons versus non-U.S. persons. These are just examples; use whatever works for your situation. Working with your compliance teams is vital at this stage if you plan to replicate these classifications across your organization and applications. They will ensure that your user and data classifications are correct and compliant for your intended design.

Once your organization has decided upon your data and user classifications you have to consider how you will manage your new user and data classifications. The most secure and consistent user classification model should use a centralized user classification mechanism.

Though this may sound fancy, this can simply mean that you have a centralized AD, LDAP, or Azure AD directory with all of your users, internal and external. At an application level, this means there should be no internal user accounts, with the exception of admin recovery accounts. Manage and maintain all users by syncing Jira with your centralized user management system. These include external customers, integration accounts, and application admin accounts. Managing your users in Jira’s internal directory will quickly become unsustainable and increases your overall risk pool by maintaining your user management, restricted data, and classification system all within one application.

Classify your users

It is crucial to have your centralized user management system be responsible for the classification of users. This will ensure scalability and security. The most efficient way to classify your users is to create a group for:

• Each high-level user classification and
• The criteria to use to validate if a user will be able to view restricted data

Let’s take the case of export control data. You would want to validate if the user is a U.S. person, non-U.S. person, or an international user. Therefore, you should create an AD group for each of these three high-level classifications. These then sync down to Jira to provide a consistent, up-to-date, centralized classification mechanism. We don’t need to know if the user is from a particular country as it will not change the classification of data that they are authorized to view. Although you may track that information in your AD, it would not require a separate classification group for each country. You can apply the same principle to other sensitive data that needs to be regulated at an enterprise level.

Configure issue security schemes

You will then have to consider how you can configure your issue security schemes. This is regardless of whether you want to implement a logical separation at an enterprise or individual project level.

Here we can use an example of a company which is going through a divestiture. Before they perform a full physical separation, the company wants to have an intermediary logical separation. Not only will this protect the two companies’ data, but it will also help classify and ease migration of the data to other instances for the physical separation.

At our issue security level, we will have two schemes: one for the Core enterprise that will remain, and one for the Subsidiary that is split from the Core enterprise. Each side should not be able to see the other’s data. We can achieve this by using our user classification from AD. The groups that were synced from AD should be assigned to a security level on an issue security scheme for each respective classification. Each project would then need to be classified as Core or Sub, and then have their issue security scheme assigned. It is important to ensure that for projects with existing data, the new security level is applied to all issues in the project.

Enforce a naming and classification convention

This then leads us to our next configuration, the project names. If you need an enterprise-wide classification system, all projects should abide by a standardized naming convention. These same principles also apply to lower level, project-specific classifications, such as security or HR projects. The data in these types of projects should only be visible by those respective teams due to the sensitive data they handle.

Whether your classifications are across the app or for a single project, the classification should be the first identifier of the project. In other words, prepend the project name with the classification or a shorthand of the classification of the project. The rest of the project name can then come after the classification. However, it is vital to have the classification clearly identified at the beginning of the project name.

You should also construct your project key in this way. Prepend the key with a shorthand of the project classification for easy identification.

Another way to clearly signify the classification of a project is to have standardized, color-coded project icons to signify the level of classification.

Finally, you can also use apps like Announcer for Jira to add project-specific banners. You can color-code these banners to signify the project classification, as well as providing a clickable link to your company’s classification standards.

Manage permissions with role-based groups

Now that you have your naming conventions, you can use them to easily manage your users’ project-level access. Though it may seem counterintuitive at first, the best way to manage users is through project-level groups.

These would require some prerequisites, such as having standardized role across the organization and standardized permission schemes which are based on these roles. Having numerous role and permissions schemes will make it difficult if not impossible to implement instance-wide classification controls. Assuming these are in place, your project-level groups should follow the naming conventions used for your projects. Create a group for each role and prepend each group with the project key. Finally, add each project group to its corresponding role.

You may have some questions about the impacts of managing users in this manner. Compliance and security sometimes require compromises.

First, how would project admins see what users are in these groups?

Project admins are not able to view these users directly. However, we can put solutions in place to allow project admins to submit a request that will automatically provide them with a list of the users for their provided group, after the system validates that they have the right to see those users.

Second, will admins have permission to add users directly to their projects?

To maintain a clear audit trail and quarantine mechanism, and ensure the integrity of the project permissions, the ability to directly add users to projects must be restricted. Robust automation to provision users and add them to the correct project groups can compensate.

Considering these restrictions, what are the benefits of managing your users in this way?

• Firstly, this process is easy to replicate and automate across your instance and provides a centralized provisioning process for a clear audit trail and quarantine mechanism over other solutions.
• Centralizing your access provisioning allows you to automate these processes which provides added security as you remove the risk of human error and can put automated checks in place to ensure that users are only provided access appropriate to their classification.
• Having a structured design allows for an easier governance model, as there is a strong foundation in place. Unrestricted customizations could impact the integrity of classification of data or make it more difficult to enforce or monitor your data compliance.
• Finally, for added confidence and security, SIL or ScriptRunner listeners could also be used on data center instances to monitor your project groups and automatically remove an unauthorized user from being added to a restricted group. This will mitigate any manual errors from your application admins.

Review your add-ons and integrations

When securing your application, don’t forget to audit your addition apps and integrations. Securing your project may not provide the same logical split in all of your additional Jira apps. Be sure to inventory all of your installed apps and validate each one against the classification model that you have built to make sure they do not subvert or lie outside of the restrictions you have built. It is important to test that data in restricted projects cannot be viewed in other installed apps, and to identify apps which cannot restrict data based on the classification groups you created.

How do we establish a logical separation in Confluence?

Many of the principles outlined above can be directly applied to a Confluence configuration:

• Manage classification in centralized AD groups
• Enforce a naming and classification convention for space names, keys, and icons
• Use space-specific banners if possible
• Manage space permissions with role-based groups
• Restrict space admin permissions
• Check your apps
• Automate!

As Confluence doesn’t have a secondary authorization mechanism (like Jira’s issue security schemes) you can utilize the page restrictions.

When you create a space, ensure that it has a dedicated home page. Here you can establish read and edit restrictions, or make pages read-only for restricted groups. But, authorized users have permission to create and edit pages in the space. Like in Jira, this will ensure that if you add a non-authorized user to a restricted space, they will still not be able to view the space pages. If possible, space admin rights should not be provided to users, as this would allow them to remove the top-level home page restrictions, which could lead to a data leak.