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. Toutefois, nous savons que vous pouvez exiger que vos données soient hébergées dans un endroit particulier, c'est pourquoi nous proposons la résidence des données. Actuellement, nous proposons la résidence des données aux États-Unis et dans l'UE, ainsi qu'en Australie, et nous prévoyons d'ajouter d'autres régions. Pour en savoir plus et pour vous inscrire afin de recevoir des mises à jour, consultez notre page relative à la résidence des données.

Les données pour Bitbucket sont hébergées dans la région USA-Est, tandis que la région USA-Ouest est utilisée pour la reprise d'activité.

Sauvegardes de données

Atlassian met en œuvre un programme de sauvegarde complet. Celui-ci inclut nos systèmes internes, dans lesquels nos mesures de sauvegarde sont conçues conformément aux exigences de récupération du système. En ce qui concerne nos produits cloud et, plus particulièrement, en ce qui vous concerne, vous et vos données applicatives, nous avons également mis en place des mesures de sauvegarde étendues. Nous utilisons la fonctionnalité d'instantané Amazon RDS pour créer des sauvegardes quotidiennes automatisées de chaque instance RDS.

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 données sont répliquées vers une autre région AWS, et des sauvegardes indépendantes sont effectuées quotidiennement dans chaque région.

Nous n'utilisons pas ces sauvegardes pour annuler les changements destructeurs initiés par le client, comme l'écrasement de champs à l'aide de scripts ou la suppression de tickets, projets ou sites. Pour éviter la perte de données, nous vous recommandons de faire des sauvegardes régulières. Découvrez-en plus sur la création de sauvegardes dans la documentation de support propre à votre produit.

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.

Bitbucket utilise le système Cloud Volumes Service (CVS) de NetApp pour le stockage de fichiers de dépôts. CVS est un système de fichiers géré par NetApp et hébergé par un data center NetApp. NetApp respecte les exigences des lois internationales sur la sécurité des données qui exigent des mesures de sécurité raisonnables pour le stockage, la transmission et le traitement des données. En outre, NetApp s'appuie à la fois sur des auto-évaluations et sur des auditeurs tiers pour garantir le respect des exigences de conformité. Pour en savoir plus, consultez les pages sur les pratiques de sécurité et les certifications de conformité NetApp.

Architecture de services distribuée

Grâce à cette architecture AWS, nous hébergeons un certain nombre de services produit et de plateforme utilisés sur l'ensemble de nos solutions. Ces services incluent les fonctionnalités de la plateforme qui sont partagées et utilisées par plusieurs produits Atlassian (comme Media, Identity et Commerce), des expériences comme notre éditeur, ainsi que des fonctionnalités spécifiques des produits, notamment le service Jira Issue et Confluence Analytics.

Architecture multilocataire

En plus de notre infrastructure cloud, nous avons créé et utilisons une architecture de microservices multilocataire avec une plateforme partagée qui prend en charge nos produits. Dans une architecture multilocataire, un seul service dessert plusieurs clients, y compris les bases de données et les instances de calcul nécessaires à l'exécution de nos produits cloud. Chaque partition (essentiellement un conteneur, voir la figure 3 ci-dessous) contient les données de plusieurs locataires, mais les données de chaque locataire sont isolées et inaccessibles aux autres locataires. Il est important de noter que nous ne proposons pas une architecture à locataire unique.

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

Bien que nos clients partagent une infrastructure commune basée dans le cloud lorsqu'ils utilisent nos produits cloud, nous avons mis en place des mesures pour nous assurer qu'ils sont logiquement isolés afin que les actions d'un client ne puissent compromettre les données ou le service d'autres clients.

L'approche d'Atlassian varie selon les apps. 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

Notre plateforme utilise un modèle de moindre privilège pour accéder aux données. Autrement dit, toutes les données sont limitées au seul service chargé de les enregistrer, de les traiter ou de les récupérer. Par exemple, les services multimédias, qui vous permettent de bénéficier d'une expérience de chargement et de téléchargement de fichiers cohérente sur l'ensemble de nos produits cloud, disposent d'un stockage dédié auquel aucun autre service Atlassian ne peut accéder. Tout service nécessitant un accès au contenu multimédia doit interagir avec l'API des services multimédias. Par conséquent, une authentification et une autorisation fortes au niveau de la couche de service imposent également une forte séparation des tâches et un accès aux données conforme au principe du moindre privilège.

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

Les données client stockées dans les produits cloud Atlassian sont chiffrées en transit sur les réseaux publics à l'aide du protocole TLS (Transport Layer Security) 1.2+ avec PFS (Perfect Forward Secrecy) pour les protéger contre toute divulgation ou modification non autorisée. Notre implémentation de TLS impose l'utilisation de chiffrements forts et de longueurs de clé quand le navigateur les prend en charge.

Les disques de données sur les serveurs hébergeant des données client et des pièces jointes dans Jira Software Cloud, Jira Service Management Cloud, Jira Work Management, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie et Trello utilisent le chiffrement complet de disque au repos, lequel s'appuie sur l'algorithme de chiffrement AES avec une clé de 256 bits, un standard dans le secteur.

Les informations d'identification personnelle (PII) transmises à l'aide d'un réseau de transmission de données sont soumises à des contrôles appropriés conçus pour garantir que les données atteignent la destination prévue. La politique de cryptographie et de chiffrement interne d'Atlassian définit les principes généraux pour l'implémentation par Atlassian de mécanismes de cryptographie et de chiffrement afin de réduire les risques liés au stockage des PII et à leur transmission sur les réseaux. Le type d'algorithme de chiffrement utilisé pour chiffrer les PII doit tenir compte du niveau de classification des PII conformément aux principes de sécurité des données et de gestion du cycle de vie de l'information d'Atlassian. 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.

Gestion des clés

Chez Atlassian, nous utilisons le service AWS Key Management Service (KMS) pour la gestion des clés. Pour garantir davantage la confidentialité de vos données, KMS est l'initiateur et le magasin secret de ces clés. Le processus de chiffrement, de déchiffrement et de gestion des clés est inspecté et vérifié régulièrement en interne par AWS dans le cadre de ses processus de validation interne existants. Un propriétaire est assigné à chaque clé et est responsable de s'assurer qu'un niveau de contrôle de sécurité approprié est appliqué aux clés. Les clés gérées par Atlassian font l'objet d'une rotation en fonction des changements de rôles ou du statut professionnel.

Nous tirons également parti du chiffrement des enveloppes. AWS détient la clé principale que nous ne pouvons jamais voir, et toute demande de chiffrement ou de déchiffrement de clé nécessite les bons rôles et les bonnes autorisations AWS. Lorsque nous utilisons le chiffrement des enveloppes afin de créer ou de générer des clés pour des clients individuels, nous disposons de différentes clés de données pour différents types de données via nos magasins de données. En outre, nous avons adopté une approche de chiffrement de la couche applicative interne qui fournit des clés de données de sauvegarde dans d'autres régions AWS. Les clés font l'objet d'une rotation annuelle automatique, et la même clé de données n'est pas utilisée pour plus de 100 000 éléments de données.

Bientôt, nous proposerons le chiffrement BYOK, ce qui vous permettra de chiffrer les données de vos produits cloud avec des clés auto-gérées dans AWS KMS. Grâce au chiffrement BYOK, vous aurez un contrôle total sur la gestion de vos clés et serez en mesure d'accorder ou de révoquer l'accès à tout moment, à la fois pour vos propres utilisateurs finaux et pour les systèmes Atlassian.

AWS KMS peut être intégré à AWS CloudTrail dans votre compte AWS afin de vous fournir des journaux de toutes les utilisations des clés. Cette solution permet le chiffrement de vos données à différentes couches applicatives, comme les bases de données, le stockage de fichiers, ainsi que nos caches internes et la mise en file d'attente des événements. Tout au long du processus, il n'y aura aucun impact sur la convivialité du produit.