Atlassian Cloud Security Shared Responsibility Model: Who Is Responsible For Jira Data Backup?

[Daria Kulikova_GitProtect_io]

In the modern world, outages, cyber-attacks, and data loss have almost become an everyday reality. That’s why, it’s essential to know how to protect your valuable data to withstand those events of disaster. Yeap… Atlassian is a very reliable service provider with high standards of security. But, what security measures it has for your data? Have you heard about the Atlassian Cloud Security Shared Responsibility Model? Is there any responsibility on your shoulders? Let’s dive into this topic deeper and figure out the answers to the arisen questions.

Atlassian Security Measures

Atlassian assures that the cornerstone of its cloud apps and services is security. All the security measures the company applies can easily get divided into:

• security in development: the company uses agile development processes, builds in rigorous security from the early stages, continuously monitors each of its cloud services to be able to fix most challenges before they affect the software, and protects its services against common web application attacks. 
• product security: the service provider uses encryption-in-transit, product vulnerability & quality management, and product security testing to keep its products and its customers' data safe.
• penetration testing: Atlassian turns to specialized security consulting firms to conduct penetration tests (white box, code-assisted, threat-based tests) to see how its infrastructure is ready to withstand the risks. 
• physical infrastructure security: the company uses biometric measures for verification, on-premise security guards, closed-circuit video monitoring, and more.
• network security: dividing its infrastructure by zones, Atlassian implements controls at every level of the stack - VPC, firewall rules, multi-factor authentication, the use of proxies for sensitive network access, Zero-Trust system, etc. 
• backup: the company stores its backup on resilient storage that is replicated across data centers. 

All of that proves the reliability of the service, and if something goes wrong with Atlassian’s Jira, the service provider will easily recover its data for its continuous workflow and your data support. But are there any Atlassian data protection challenges? What if something will crop up with your own Jira infrastructure? Will it be the Atlassian’s responsibility?

Atlassian Cloud Security Shared Responsibility Model: the basics

As the name suggests, Atlassian shares security responsibilities with its customers. So, following this model, Atlassian is responsible for the hosting, system, and application focused on its own business and integrity, and the service provider customers should focus on their Jira data protection because account-level protection isn’t included in the service provider’s responsibility and competence list. 

Here is how Atlassian describes its Cloud Security Shared Responsibility Model: 

So, what about your own Jira data protection? Who should enable Jira backup for accessing and recovering Jira data in the event of a failure? No doubt… a customer. Here is what Atlassian states in its Security Practices: 

“We do not use these backups to revert customer-initiated destructive changes, such as fields overwritten using scripts, or deleted issues, projects, or sites. To avoid data loss, we recommend making regular backups.”

As you can see, Atlassian itself recommends its users back up their critical data to have peace of mind if something comes around. And if you think that disasters are a fairytale, even the biggest Data Centers like OVH or T-Mobile, have already experienced disasters in the past that impacted thousands of customers. So, it’s more common than you can imagine.  

Jira Backup Best Practices

So what should you know about backing up your Jira data which falls under your responsibility? To stay assured that your Jira data is safe and sound, meaning that it is accessible at any time and easy to recover in any event of failure, you should follow Jira backup best practices and:

• include full data coverage of your Jira environment (so to say, you should be able to back up projects, issues, roles, workflows, users, etc.).
• be able to assign a few storages with data replication to meet the 3-2-1 backup rule.
• have a possibility of unlimited retention (Atlassian keeps your deleted data only for a limited period of time) to meet legal, security, or compliance requirements.
• have AES encryption in-flight and at rest with an opportunity to create your own encryption key.
• have reliable ransomware protection features, such as immutable storage. So that, even if an attacker targets your storage, the malware won’t be spread within your data storage.
• guarantee restore & Disaster Recovery of your critical data when the disaster strikes.
• use Jira granular restore for daily operations to simply migrate your data between projects, separate them out, consolidate and instantly restore only chosen data in case of accidental deletion.

All those methodologies will help to build a reliable backup strategy to work peacefully and guarantee business continuity for your team. 

Conclusion: Your own backup script or a backup software

We have already mentioned that Atlassian has a backup of all its data, but those backups are aimed at ensuring its own business continuity and uninterrupted workflow. Yeap… the service provider makes a backup of your data as well, however, will it be enough for you if a disaster happens? Can you wait even two weeks to access your Jira data? Or its better to resume your work in a few minutes after the disaster and figure out what has happened without interrupting your team’s work?

And how about daily operations - don’t you need to simply migrate your data between project, separate them out, or consolidate from time to time? Just imagine, how much time and work it can safe to your entire team. 

Following Atlasssian’s recommendation to have your own backup, you have a few options - Jira backup script or third-party backup software. If you opt for the first option that may seem cheaper at first sight, you will need to deal with backup at every level - writing backup scripts, performing those scripts, cleaning the storage from no-more-needed backups, a lot of work which can distract your team from their core duties. Moreover, there is no guarantee that you will be able to recover your Jira data if there is a need. 

The third-party backup solution, like GitProtect for Jira Software, JSM, and JWM, can help to leverage your Shared Responsibility Model, as from the moment of application backup is the responsibility of the backup provider. What’s more, your DevOps and Project Management teams can fully focus on their core duties without being disturbed and vulnerable to human mistakes. 

What do you think?