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.

4 comments

Comment

Log in or Sign up to comment
Sri Kumar
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 17, 2022

Hi @Sandy ,

Thanks for sharing this useful information. 

nealfisc June 22, 2022

@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 

Roger Friederich October 12, 2022

Hi @Sandy Thanks for sharing this detail which is extremely helpful.
You mention that soon Atlassian will be offering BYOK based on AWS KMS. Is this publicly available yet? And does it require an Enterprise plan or is Premium sufficient?

We do have specific questions from one of our prospects working in the government sector where i couldn't find answers so far. Where can we adress these questions?

- Can EU data locations be pinned to either Germany or Ireland?
- Are EU data centers C5 compliant and is there an audit report?
- Data stored in relation to certain professions in Germany (Doctors, Auditors, Police etc) is considered as a "professional secret" (§203 StGB). Hence data storage for these professions must follow certain compliance rules. Do Atlassian cloud services comply with these regulations?

It would be great to either get an answer if you could please point me in the right direction!
Thanks!

marc -Collabello--Phase Locked-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 12, 2022

Hi @Roger Friederich ,

You can find more information about data residency here: https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/ .  Especially if you store professional secrets, you should be aware of in-scope data, and data out of scope (especially the heading "Why we don't pin user account information data").

Like Roger Friederich likes this
TAGS
AUG Leaders

Atlassian Community Events