3 Critical Levels For Improving Security in Jira

Apps, Atlassian

15 January 2018 • 11 min read

    Jira is a platform integral to your teamwork. Chances are high that your team stores and manages plenty of sensitive information inside Jira – that’s why it makes sense to get interested in the topic of security.

    In general, when configuring security for your Jira instance, you need to address different areas to ensure maximum efficiency of your security measures.

    In this article, I present 3 simple steps that will help you significantly improve security in Jira.

    1. Security in the system environment

    Most of the time, your Jira instance will include sensitive information so you need to first consider securing in the environment in which your Jira is running.

    With that in mind, you should consider the following areas:

    • File system – make sure to restrict access to index directory and attachments directory;
    • Database – if you’re using an external database as the recommended one for your production systems, restrict the access to the database of your Jira instance. If, on the other hand, you are using Jira’s internal/bundled H2 database, you need to restrict access to the directory in which you have installed Jira. Remember that the user your Jira instance is running will require full access to this directory as well;
    • SSL – if you’re running your Jira instance on the Internet, consider using the SSL protocol for extra security.
    1. Manage security in Jira apps

    Jira applications have flexible security systems that allow users to configure who can access them, as well as what they can see within them or do with them.

    There are basically five security levels inside Jira applications:

    • Global permissions – they apply to entire Jira applications;
    • Project permissions – project permissions are organized into permission schemes that apply to entire projects (for example, they say who can see, create, edit and assign project issues);
    • Issue security – you can set different security schemes inside your issues which adjust their visibility within the boundaries of project permissions;
    • Comment visibility – you can restrict the visibility of individual comments within an issue;
    • Work-log visibility – you can also restrict the visibility of individual work-log entries inside issues. Remember that this doesn’t restrict the visibility of progress bar on issue time tracking.

    In general, a user can belong to three groups that are relevant for security settings:

    • Group
    • Project Role
    • Issue Role (for example, Assignee)

    A user who is part of a Group can be granted global permissions. For example, you can allow such a user to log into your Jira instance.

    A user who belongs to a Project Role or an Issue Role can be granted global, as well as project permissions and issue security permissions. For example, you can allow this user to create Jira issues in a way that is consistent with the permission scheme you set for a specific project. You can restrict their access to issues on the basis of the issue security scheme set for the project as well.

    Just like other areas in Jira, security is fully customizable and allows administrators to match the needs of their team or organization, all the while keeping sensitive information safe.

    1. Ensure top security when integrating with other apps

    If you’re using more than one Jira instances at your organization, synchronizing projects or issues between them can be tricky.

    Imagine the following situation: A user creates an issue in Jira A. To make sure that the collaboration is smooth, it makes sense that you allow the user of Jira B to access the attachments, fields, comments, and workflows related to that issue.

    This user will not only be able to see these elements, but also perform operations on the issue together with its original creator.

    You can imagine how many security issues arise in that situation:

    • How should you regulate access to particular issues or projects for external users?
    • Is there a way to keep your Jira instance secure at the network level?
    • Is it possible to keep projects completely separated from each other and still be able to work together on issues between them?

    We developed our app IssueSYNC with these concerns in mind.

    The app offers a range of security features implemented to ensure maximum security when synchronizing internal and external Jira projects, issues and instances:

    • Firewall – synchronizing two Jira instances means establishing a line of communication between them. While Jira A may be located behind a firewall, Jira B may be on a public IP domain and accessible through the Internet or VPN. Push&Pull feature makes sure that Jira A isn’t exposed to that potentially dangerous network.
    • Secure isolation and sharing – if you work on a single Jira instance with many different clients separated in projects, you need to restrict them from viewing or accessing projects of other customers. But sometimes it makes sense to copy issues between projects. You can do that with our app, all the while maintaining a clear separation between projects.
    • Different synchronization triggers – you can choose between JQL trigger, workflow event-based trigger and on-demand trigger to ensure that synchronization happens exactly when you want.

    IssueSYNC is a great help in keeping two different Jira instances or projects secure during data synchronization. Have a look here to find out more about the security features in our app.

    Keep your Jira secure

    It pays to develop a security infrastructure for your Jira instance.

    Invest time in configuring the external environment and pay close attention to user permissions you’re granting for each project. Have a look at the Atlassian Marketplace to find apps that will help keep your Jira instance secure no matter what actions you’re performing.

    Do you know any other smart ways to keep Jira secure? Share them in comments, I’m always curious to learn more about best security practices.

    [contact-form-7 404 "Not Found"]