Architecture Atlassian Cloud et pratiques opérationnelles

Architecture d'hébergement Atlassian Cloud

Nous utilisons Amazon Web Services (AWS) comme fournisseur de services cloud et ses data centers hautement disponibles dans de nombreuses régions du monde. Chaque région AWS est un emplacement géographique distinct comprenant plusieurs groupes de data centers isolés et séparés physiquement, appelés zones de disponibilité (ZD).

Nous utilisons les services de calcul, de stockage, de mise en réseau et de données d'AWS pour créer nos produits et les composants de notre plateforme. Nous pouvons ainsi utiliser les capacités de redondance offertes par AWS, telles que les régions et les zones de disponibilité.

Zones de disponibilité

Chaque ZD est conçue pour être isolée des pannes dans d'autres zones et pour fournir une connectivité réseau peu coûteuse et à faible latence avec d'autres ZD de la même région. Cette haute disponibilité multizones constitue la première ligne de défense contre les risques régionaux et environnementaux, et signifie que les services fonctionnant dans des déploiements multi-ZD doivent être capables de résister aux pannes de ZD.

Jira et Confluence utilisent le mode de déploiement multi-ZD pour Amazon Relational Database Service (Amazon RDS). Dans un déploiement multi-ZD, Amazon RDS fournit et maintient une réplication synchrone de secours dans une autre ZD de la même région pour fournir une redondance et une capacité de basculement. Le basculement de ZD est automatisé et prend généralement de 60 à 120 secondes, de sorte que les opérations de la base de données impactée peuvent reprendre aussi rapidement que possible sans intervention administrative. Opsgenie, Statuspage, Trello et Jira Align utilisent des stratégies de déploiement similaires, avec de petites variations dans la synchronisation des réplications et des basculements.

Emplacement des données

Les données Jira et Confluence sont hébergées dans la région la plus proche de celle où se trouve la majorité de vos utilisateurs lors de leur inscription. Les données de Bitbucket se trouvent dans deux zones de disponibilité différentes de la région de l'est des États-Unis.

Cependant, nous comprenons que certains d'entre vous peuvent avoir besoin que leurs données soient hébergées dans un endroit particulier. C'est pourquoi nous proposons des options de résidence des données. Actuellement, la résidence des données est disponible pour Jira, Jira Service Management, Jira Product Discovery et Confluence dans 11 régions, dont les États-Unis, l'UE, le Royaume-Uni, l'Australie, le Canada, l'Allemagne, l'Inde, le Japon, Singapour, la Corée du Sud et la Suisse. Lisez notre documentation pour en savoir plus sur la résidence des données et les données pertinentes sur les produits. En outre, vous pouvez suivre notre feuille de route pour obtenir des mises à jour sur la résidence des données, y compris les extensions à de nouveaux produits, types de données et nouvelles régions.

Sauvegardes de données

We operate a comprehensive backup program at Atlassian. This includes our internal systems, where our backup measures are designed in line with system recovery requirements. With respect to our cloud apps, and specifically referring to you and your application data, we also have extensive backup measures in place. We use the snapshot feature of Amazon RDS (Relational database service) to create automated daily backups of each RDS instance.

Les instantanés Amazon RDS sont conservés pendant 30 jours avec prise en charge de la reprise à un instant de référence et sont chiffrés avec l'algorithme AES-256. Les données de sauvegarde ne sont pas stockées hors site, mais sont répliquées dans plusieurs data centers au sein d'une région AWS spécifique. Nous effectuons également des tests trimestriels de nos sauvegardes.

Pour Bitbucket, les instantanés de stockage sont conservés pendant 7 jours avec support pour restauration ponctuelle.

We don’t use these backups to revert customer-initiated destructive changes, such as fields overwritten using scripts, or deleted work items, projects, or sites. To avoid data loss, we recommend making regular backups. Learn more about creating backups in the support documentation for your product.

Sécurité des data centers

AWS maintient plusieurs certifications pour la protection de ses data centers. Ces certifications portent sur la sécurité physique et environnementale, la disponibilité des systèmes, l'accès au réseau et à la dorsale IP, le provisionnement des clients et la gestion des problèmes. L'accès aux data centers est limité au personnel autorisé et vérifié par des mesures biométriques de contrôle de l'identité. Les mesures de sécurité physique comprennent des gardes de sécurité sur place, une surveillance vidéo en circuit fermé, des pièges humains et des mesures supplémentaires de protection contre les intrusions.

Architecture de services distribuée

With this AWS architecture, we host a number of platform and product services that are used across our solutions. This includes platform capabilities that are shared and consumed across multiple Atlassian products, such as Media, Identity, and Commerce, experiences such as our Editor, and product-specific capabilities, like Jira Work Item service and Confluence Analytics.

Architecture multilocataire

On top of our cloud infrastructure, we built and operate a multi-tenant micro-service architecture along with a shared platform that supports our products. In a multi-tenant architecture, a single service serves multiple customers, including databases and compute instances required to run our cloud apps. Each shard (essentially a container – see figure 3 below) 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.

Provisionnement d'un locataire et cycle de vie

Lorsqu'un nouveau client est provisionné, une série d'événements déclenche l'orchestration des services distribués et le provisionnement des magasins de données. Ces événements peuvent généralement être mappés à l'une des sept étapes du cycle de vie :

1. Les systèmes commerciaux sont immédiatement mis à jour avec les dernières métadonnées et informations de contrôle d'accès pour ce client, puis un système d'orchestration du provisionnement aligne « l'état des ressources provisionnées » avec l'état de la licence par le biais d'une série d'événements liés au locataire et aux produits.

Événements liés au locataire

Ces événements affectent le locataire dans son ensemble et peuvent prendre deux formes :

• Création : un locataire est créé et utilisé pour de tout nouveaux sites
• Destruction : un locataire entier est supprimé

Événements liés aux produits

• Activation : après l'activation de produits sous licence ou d'apps tierces
• Désactivation : après la désactivation de certains produits ou de certaines apps
• Suspension : après la suspension d'un produit existant, désactivant ainsi l'accès à un site donné dont il est propriétaire
• Annulation de suspension : après l'annulation de la suspension d'un produit existant, permettant ainsi l'accès à un site dont il est propriétaire
• Mise à jour de licence : contient des informations concernant le nombre de postes de licence pour un produit donné ainsi que son état (actif/inactif)

2. Création du site client et activation de l'ensemble de produits approprié pour le client. Le concept d'un site est le conteneur de plusieurs produits concédés sous licence à un client spécifique. (p. ex. Confluence et Jira Software pour ＜nom-site＞.atlassian.net).

Isolement des locataires

While our customers share a common cloud-based infrastructure when using our cloud apps, 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.

L'approche d'Atlassian varie selon les applications. Pour Jira et Confluence Cloud, nous adoptons un concept appelé « Contexte de locataire » afin de parvenir à l'isolement logique de nos clients. Ce concept est implémenté à la fois dans le code applicatif et géré par ce que nous appelons un service de contexte de locataire (Tenant Context Service, TCS). Celui-ci assure que :

• les données de chaque client sont logiquement isolées de celles des autres locataires au repos ;
• toutes les demandes traitées par Jira ou Confluence offrent une vue propre au locataire afin que les autres locataires ne soient pas impactés.

Dans les grandes lignes, le TCS stocke un contexte pour les différents locataires du client. Le contexte de chaque locataire est associé à un ID unique stocké de façon centrale par le TCS et inclut diverses métadonnées associées à ce locataire, comme les bases de données dans lesquelles le locataire se trouve, les licences dont il dispose, les fonctionnalités auxquelles il a accès, et tout un éventail d'autres informations de configuration. Lorsqu'un client accède à Jira ou Confluence Cloud, le TCS utilise l'identifiant du locataire pour rassembler ces métadonnées, qui sont ensuite associées à toutes les opérations effectuées par le locataire dans l'app tout au long de sa session.

Limites Atlassian

Vos données sont également protégées par ce que nous appelons une « limite » : des murs virtuels que nous construisons autour de notre logiciel. Lorsqu'une demande arrive, elle est envoyée à la limite la plus proche. Via une série de validations, elle est ensuite autorisée ou refusée.

• Elle arrive à la limite Atlassian la plus proche de l'utilisateur. La limite vérifie la session et l'identité de l'utilisateur par l'intermédiaire de votre système d'identité.
• La limite détermine où se trouvent les données de vos produits, en fonction des informations du TCS.
• La limite transmet la demande à la région cible, où elle aboutit sur un nœud de calcul.
• Le nœud utilise le système de configuration du locataire pour déterminer des informations, comme l'emplacement de la licence et de la base de données, puis s'adresse à d'autres magasins de données et services (par exemple, la plateforme multimédia qui héberge les images et les pièces jointes) pour récupérer les informations requises afin de répondre à la demande.
• La demande initiale de l'utilisateur avec des informations rassemblées à partir de ses précédents appels à d'autres services.

Authentification et autorisation de services

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 allows you to have a consistent file upload and download experience across our cloud apps, 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.

Nous utilisons des jetons web JSON (JWT) pour garantir l'autorité de signature en dehors de l'app, afin que nos systèmes d'identité et le contexte du locataire soient la source de référence. Les jetons ne peuvent être utilisés à d'autres fins que celles pour lesquelles ils sont autorisés. Lorsque vous ou un membre de votre équipe appelez un microservice ou une partition, les jetons sont transmis à votre système d'identité et validés par rapport à celui-ci. Ce processus garantit que le jeton est à jour et signé avant tout partage des données appropriées. En cas de compromission d'un service, son périmètre est limité grâce à ce processus, combiné à l'autorisation et à l'authentification requises pour accéder à ces microservices.

Nous savons toutefois que les systèmes d'identité peuvent parfois être compromis. Pour atténuer ce risque, nous utilisons deux mécanismes. Tout d'abord, le TCS et les proxys d'identité sont hautement répliqués. Nous avons un TCS supplémentaire pour presque tous les microservices et nous utilisons des proxys supplémentaires qui émanent de l'autorité d'identité, de sorte que des milliers de ces services sont en cours d'exécution à tout moment. En cas de comportement anormal dans un ou plusieurs d'entre eux, nous pouvons intervenir rapidement et résoudre le problème.

De plus, nous n'attendons pas que quelqu'un découvre une vulnérabilité dans nos produits ou notre plateforme. Nous identifions activement ces scénarios afin qu'ils vous impactent au minimum, et nous exécutons un certain nombre de programmes de sécurité pour identifier et détecter les menaces de sécurité et pour y répondre.

Service de contexte de locataire (TCS)

Nous nous assurons que les demandes adressées à tous les microservices contiennent des métadonnées concernant le client (ou le locataire) qui demande l'accès. C'est ce que nous appelons le service de contexte de locataire (TCS). Il est directement renseigné à partir de nos systèmes de provisionnement. Lorsqu'une demande est initiée, le contexte est lu et internalisé dans le code de service en cours d'exécution, qui est utilisé pour autoriser l'utilisateur. Tous les accès au service (et donc aux données) dans Jira et Confluence nécessitent ce contexte de locataire, sinon la demande sera rejetée.

L'authentification et l'autorisation de services sont appliquées via le protocole Atlassian Service Authentication Protocol (ASAP). Une liste verte explicite détermine quels services peuvent communiquer, et des informations d'autorisation spécifient les commandes ainsi que les chemins disponibles. Cela limite tout mouvement latéral potentiel d'un service compromis.

L'authentification et l'autorisation de services, ainsi que la sortie, sont contrôlées par un ensemble de proxys dédiés. Ainsi, les vulnérabilités du code de l'app n'ont aucun impact sur ces contrôles. L'exécution de code arbitraire (RCE) nécessiterait de compromettre l'hôte sous-jacent et de contourner les limites du conteneur Docker, et pas seulement de pouvoir modifier la logique de l'app. Notre détection des intrusions au niveau de l'hôte signale plutôt les incohérences.

Ces proxys limitent le comportement de sortie en fonction du comportement prévu du service. Les services qui n'ont pas besoin d'émettre des webhooks ou de communiquer avec d'autres microservices ne sont pas autorisés à le faire.

Cryptage de données

Customer data in Atlassian cloud apps is encrypted during transmission utilizing TLS 1.2 or higher, incorporating perfect forward secrecy (PFS) to safeguard against unauthorized information disclosure and data modification. We adhere to NIST-recommended TLS 1.2+ protocols, which enforce the use of strong ciphers and key lengths as supported by the browser.

Les données clients, y compris les pièces jointes, stockées sur des services cloud tels que Jira Software Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie et Trello sont protégées par l'algorithme AES-256, un standard dans le secteur, pour le chiffrement au repos.

La transmission des informations d'identification personnelle (PII) est protégée par le chiffrement et de solides contrôles d'accès aux données, conçus pour garantir que les données sont acheminées en toute sécurité vers leur destination prévue. La politique de cryptographie et de chiffrement d'Atlassian décrit les principes de mise en œuvre du chiffrement et de la cryptographie afin d'atténuer les risques liés au stockage et à la transmission des PII. Les algorithmes de chiffrement destinés à protéger les PII sont conformes au niveau de classification des PII, comme spécifié par les politiques internes de gestion du cycle de vie des informations et de sécurité des données d'Atlassian. Cela garantit que les données sensibles sont correctement sécurisées en fonction de leur classification. Pour en savoir plus sur la façon dont nous collectons, partageons et utilisons les données des clients, consultez notre page relative à la confidentialité.

Pour vous tenir au courant des fonctionnalités supplémentaires de chiffrement des données, consultez notre feuille de route Cloud.