Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,293,588
Community Members
 
Community Events
165
Community Groups

Atlassian Cloud Data Architecture

Hello everyone!

My name is Sandy and I’m on the Trust product marketing team. I wanted to share more about the Atlassian Cloud data architecture.

We understand your data is highly valuable and is what makes your company the business it is today. It is critical to know how your data is stored and managed so you have a strategy that allows you to empower your teams while staying on top of regulatory standards.

At Atlassian, we use industry-leading cloud provider Amazon Web Services (AWS) for our hosting architecture. This includes using their compute, storage, network, and data services to build our products and platform components. We provision those services through an internally developed platform as a service (PaaS) called Micros. Jira Software, Jira Work Management, Jira Service Management, and Confluence are supported on the Micros platform.

How data is stored

With AWS, we have availability zones (AZ) in multiple regions worldwide. The multi-zone high availability is the first line of defense for geographic and environmental risks. Jira and Confluence data is located in the region closest to where the majority of your users are located upon sign-up. We currently offer data residency in the US and EU regions, as well as Australia, with plans to add additional regions.

We use the snapshot feature of Amazon Relational Database Service (RDS) to create automated daily backups of each RDS instance. Amazon RDS snapshots are retained for 30 days with support for point-in-time recovery and encrypted with AES-256 encryption. Backup data is stored and replicated to multiple data centers within a particular AWS region.

Learn more about our cloud infrastructure.

How data flows

We host a number of platform and product services that are used across our solutions. This includes platform capabilities that are shared across multiple Atlassian products, such as Media and Identity, and experiences such as our Editor, and product-specific capabilities, like Jira Issue service and Confluence Analytics. Typically, an Atlassian product consists of multiple "containerized" services that are deployed on AWS using Micros.

Overview of Atlassian micro-services

On top of our cloud infrastructure, we built and operate a multi-tenant micro-service architecture. In a multi-tenant architecture, a single service serves multiple customers, including databases and compute instances required to run our cloud products. Each shard (essentially a container) contains the data for multiple tenants, but each tenant's data is isolated and inaccessible to other tenants. It is important to note that we do not offer a single-tenant architecture. 

How we store data in a multi-tenant architecture

While our customers share a common cloud-based infrastructure when using our cloud products, we have measures in place to ensure they are logically separated so that the actions of one customer cannot compromise the data or service of other customers.

Learn more about our cloud platform architecture.

As a company with a global customer base and operations, Atlassian must be able to transfer and access data around the world. We comply with the General Data Protection Regulation (GDPR) and offer customers a robust international data transfer framework as part of our Data Processing Addendum to ensure lawful data transfer outside of the European Economic Area (EEA).

Atlassian is also committed to protecting customer data privacy and rights by only responding to law enforcement requests after a comprehensive legal review. We publish an annual Transparency Report about government requests for users' data.

Learn more about our GDPR compliance and Privacy Policy.

How data is secured

Since we leverage a multi-tenant architecture, we can layer additional security controls into the decoupled application logic. We’ve also built additional preventative controls into our products that are fully hosted on our Atlassian platform. The primary preventative controls include:

  • Service authentication and authorization
  • Tenant context service
  • Key management
  • Data encryption

Our platform uses a least privilege model for accessing data. This means that all data is restricted to only the service responsible for saving, processing, or retrieving it. For example, the media services, which allow you to have a consistent file upload and download experience across our cloud products, have dedicated storage provisioned that no other services at Atlassian can access. Any service that requires access to the media content needs to interact with the media services API. As a result, strong authentication and authorization at the service layer also enforces strong separation of duties and least privilege access to data. We use JSON web tokens to ensure signing authority outside of the application, so our identity systems and tenant context are the source of truth. Tokens can’t be used for anything other than what they are authorized for.

The tenant context service (TCS) ensures requests to any microservices contain metadata about the customer - or tenant - that is requesting access. Service authentication and authorization is applied, where an explicit allowlist determines which services may communicate and authorization details specify which commands and paths are available. This limits potential lateral movement of a compromised service. Your data is also safeguarded through something that we call an edge - virtual walls that we build around our software. When a request comes in, it is sent to the nearest edge. Through a series of validations, the request is either allowed or denied.

At Atlassian, we use the AWS Key Management Service (KMS) for key management. To further ensure the privacy of your data, KMS is the originator and secret store for these keys. An owner is assigned for each key and is responsible for ensuring the appropriate level of security controls is enforced on keys. Atlassian-managed keys are rotated upon relevant changes of roles or employment status. Soon, we will offer bring your own key (BYOK) encryption, giving you the ability to encrypt your cloud product data with self-managed keys in AWS KMS.

Customer data in our Atlassian cloud products is encrypted in transit over public networks using TLS 1.2+ with perfect forward secrecy (PFS) to protect it from unauthorized disclosure or modification. Data drives on AWS servers holding customer data and attachments use full disk, industry-standard AES-256 encryption at rest. PII transmitted using a data-transmission network are subject to appropriate controls designed to ensure that data reaches its intended destination.

Learn more about security controls.

Did you find this information helpful? Please share your thoughts below – we’d love to hear from you! Be sure to take a look at other community members’ comments/questions and up-vote those you find interesting.

2 comments

SriKumar P Atlassian Team May 17, 2022

Hi @Sandy ,

Thanks for sharing this useful information. 

@Sandy  Thank you for posting this information.  Can you share your opinion on my observations ?

Atlassian products are offered on both cloud and private on-premise deployments (i.e Jira Data Center).  The use of file attachments by users to complete daily workflows is a feature common to both deployment models.  Atlassian previewer (Aspose) provides document conversion (Office to PDF/PNG) enabling file previewing. Frequently file attachments contains company sensitive and employee subject data regulated by GDPR and US privacy laws requiring businesses to delete the requestor's personal information from all of its data stores. 

My observations for your comment -With today's increasing remote workforce,  secure file-in-place file attachment viewing is needed to prevent data loss by accidental or intentional acts.   

While PDF and static image attachments can be safely viewed in modern browsers.  Microsoft Office formats are more problematic.  The Atlassian previewer has challenges to accurately preview the original file.  Often the same file viewed on Atlassian mobile clients is different than when displayed on the Atlassian web client, lacking content and layout preservation.   .  Users have the option to download a copy of the attachment on their local devices and use MS365 as a viewer.  For Atlassian Data Center users a previewer is not offered, users must download company content.  Sadly, Office files are preferred channel to deliver malware targeting today's global enterprises

Please see comments from over 90 other Jira users that seek improved UX, however I believe the privacy trust risk is important part of this feature request. I welcome your support to address secure Office file format previewing. https://jira.atlassian.com/browse/JRACLOUD-59685 

Comment

Log in or Sign up to comment
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you