ENISA : Agence de l'Union européenne chargée de la sécurité des réseaux et de l'information

L'Agence européenne chargée de la sécurité des réseaux et de l'information (ENISA) est un centre d'expertise en la matière. Elle collabore étroitement avec les États membres de l'UE et le secteur privé pour fournir des conseils et des recommandations sur les bonnes pratiques en matière de cybersécurité. L'ENISA participe également à l'élaboration et à la mise en œuvre des politiques et lois de l'UE relatives à la sécurité de l'information au niveau national.

Le Cloud Computing Information Assurance Framework (IAF) de l'ENISA constitue un ensemble de critères que les organisations peuvent examiner avec les fournisseurs de services cloud (CSP) afin de s'assurer que les données client soient suffisamment protégées. L'IAF a pour but d'évaluer les risques liés à l'adoption du cloud et de réduire le fardeau des assurances qui pèse sur les CSP.

Atlassian respecte l'IAF grâce à son adhésion à la Cloud Controls Matrix (CCM) de Cloud Security Alliance (CSA), qui aligne les domaines et les contrôles de la CCM sur les critères d'assurance de l'IAF, ainsi qu'à la certification ISO 27001.

Atlassian gère les assurances suivantes sur la base de la CCM :

• Auto-évaluation CSA STAR 1

Les conseils suivants fournissent des critères d'assurance destinés à aider les entreprises à choisir un fournisseur de services cloud. Si vous avez des questions concernant des informations spécifiques, contactez notre équipe commerciale Enterprise à l'adresse https://www.atlassian.com/enterprise/contact?formType=product-features.

6.01

La majorité des questions concernant le personnel seront similaires à celles que vous poseriez à votre personnel informatique ou à tout autre personnel qui s'occupe de votre infrastructure informatique. Comme pour la plupart des évaluations, il existe un équilibre entre les risques et les coûts.

6.01. (a)

Quelles politiques et procédures avez-vous mises en place lorsque vous recrutez vos administrateurs informatiques ou d'autres personnes ayant accès au système ? Il convient d'inclure ce qui suit :

• Vérifications préalables à l'embauche (identité, nationalité ou état, expérience et références professionnelles, condamnations pénales et contrôles (pour les cadres occupant des postes très privilégiés)).

Conformément à la législation en vigueur dans leur pays de résidence, les antécédents des nouveaux employés d'Atlassian doivent être vérifiés. Conformément à la législation en vigueur dans leur pays de résidence, les employés embauchés à la suite d'une acquisition sont soumis à une vérification de leurs antécédents après la date d'acquisition. Les nouvelles recrues et les sous-traitants indépendants font l'objet d'un contrôle du casier judiciaire. Une vérification des diplômes, et une vérification des références professionnelles ou de la solvabilité sont ajoutées si le poste ou le niveau du poste l'exige. Nous procédons à des vérifications complètes des antécédents pour les postes de cadre supérieur et les postes liés à la comptabilité.

6.01. (b)

Existe-t-il des politiques différentes selon l'endroit où les données sont stockées ou selon l'endroit où les applications sont exécutées ?

• Par exemple, les politiques de recrutement d'une région peuvent être différentes de celles d'une autre.
• Les pratiques doivent être cohérentes d'une région à l'autre.
• Il se peut que des données sensibles soient stockées dans une région en particulier avec le personnel approprié.

Atlassian impose des restrictions au personnel qui a besoin d'accéder à nos systèmes, à nos applications et à notre infrastructure dans le cadre de son rôle et de ses responsabilités selon le principe du moindre privilège, et ce, par le biais de nos processus d'authentification. Tous les accès se font par le biais de sessions authentifiées et sur la base d'autorisations établies.

Tous les systèmes de niveau 1 sont gérés via une solution d'authentification unique (SSO) et d'annuaire centralisée Atlassian. Les utilisateurs disposent de droits d'accès appropriés en fonction de ces profils, conformément au workflow de notre système de gestion des ressources humaines. Atlassian utilise l'authentification multifacteur pour accéder à tous les systèmes de niveau 1. Nous avons activé l'authentification à deux facteurs pour la console de gestion de l'hyperviseur et l'API AWS, ainsi qu'un rapport d'audit quotidien sur tous les accès aux fonctions de gestion de l'hyperviseur. Les listes d'accès à la console de gestion de l'hyperviseur et à l'API AWS sont revues tous les trimestres. Nous assurons également une synchronisation de 8 heures entre notre système RH et notre magasin d'identités.

D'une manière plus générale, les contrôles liés à l'accès sont couverts par la politique de gestion des accès, dont un extrait est disponible ici : https://www.atlassian.com/trust

6.01. (c)

Quel programme de formation à la sécurité proposez-vous à l'ensemble du personnel ?

Atlassian propose une formation à la sécurité de l'information dans le cadre de sa formation d'intégration (« premier jour ») pour les nouvelles recrues et de manière continue, à l'ensemble du personnel.

En plus de cette formation générale sur la sécurité de l'information, nous proposons à nos développeurs des formations plus ciblées sur la programmation sécurisée, lesquelles sont renforcées par notre programme d'ingénieurs de sécurité intégrés.

Nous proposons également des formations thématiques continues sur les logiciels malveillants, le hameçonnage et d'autres problèmes de sécurité. Pour en savoir plus, consultez la page  https://www.atlassian.com/trust/security/security-practices#security-awareness-training

Nous tenons des registres officiels indiquant le suivi de la formation interne du personnel. Les employés sont tenus de prendre connaissance du Code de conduite et de l'accepter chaque année. Cette politique est communiquée à tous les employés. Les exigences en matière de sensibilisation à la sécurité, de confidentialité et de respect de la vie privée sont présentées dans le cadre de leurs formations quotidiennes et sont accessibles à tous les employés dans Confluence.

6.01. (d)

Existe-t-il un processus d'évaluation continue ?

• À quelle fréquence se déclenche-t-il ?
• Autres entretiens.
• Accès sécurisé et évaluation des privilèges.
• Révisions des politiques et des procédures.

Atlassian a obtenu les certifications SOC2, ISO27001 et ISO27018 pour ses services cloud. Nous réalisons à la fois des audits internes/de préparation et des audits externes au moins une fois par an. Atlassian a obtenu une certification ISO pour de nombreux produits, ce qui nécessite des évaluations des risques et une révision des pratiques en matière de données régulières.

Pour plus d'informations, rendez-vous sur : https://www.atlassian.com/trust/compliance. Nous conseillons à nos clients de télécharger et de consulter régulièrement les mises à jour de nos certificats et rapports de conformité publiés sur ce site.

Atlassian dispose d'un framework de politiques documentées, dont la principale est notre politique de sécurité. Notre Policy Management Program (PMP) a été défini et inclut la propriété, la disponibilité et le cycle de révision. Il décrit également nos objectifs généraux. Nos politiques sont revues au moins une fois par an et approuvées par la haute direction. Pour plus d'informations sur notre PMP, rendez-vous sur : https://www.atlassian.com/trust/security/security-management-program

Nous avons également publié des extraits de chacune de nos politiques de haut niveau ainsi qu'un résumé à l'adresse suivante : https://www.atlassian.com/trust/security/ismp-policies

Tous les systèmes et projets font l'objet d'une évaluation d'impact en ce qui concerne les informations d'identification personnelle.

Les accords d'Atlassian avec des tiers comprennent des dispositions relatives à la sécurité et à la protection de la vie privée, le cas échéant. Les nouveaux fournisseurs d'Atlassian sont tenus d'accepter les politiques de confidentialité et de sécurité de nos contrats. Nos équipes juridiques et d'approvisionnement passent en revue les contrats, les SLA et les politiques internes des fournisseurs afin de gérer les risques liés à la sécurité, à la disponibilité et à la confidentialité. Le programme de gestion des risques de l'entreprise (ERM) d'Atlassian procède à une évaluation annuelle des risques qui tient compte de la probabilité et de l'impact de l'ensemble des catégories de risques et s'aligne sur le modèle de risque COSO. Nous effectuons également des évaluations des risques fonctionnels selon les besoins sur la base du profil de risque. Les évaluations des risques sont passées en revue dans le cadre du renouvellement de la politique et chaque fois que la relation avec le fournisseur change de manière significative.

6.02.

Les questions suivantes doivent être posées lorsque le fournisseur de cloud sous-traite certaines opérations essentielles à la sécurité des opérations à des tiers (par exemple, un fournisseur de SaaS externalise la plateforme sous-jacente à un fournisseur tiers, un fournisseur de cloud sous-traite les services de sécurité à un fournisseur de services de sécurité gérés, en cas de recours à un fournisseur externe pour la gestion des identités des systèmes d'exploitation, etc.). Elles se posent également pour les tiers qui bénéficient d'un accès physique ou distant à l'infrastructure du fournisseur de cloud. Par principe, l'ensemble de ce questionnaire s'adresse de manière récursive à tout fournisseur de services cloud tiers.

6.02. (a)

Définit les services externalisés ou sous-traités de votre chaîne d'approvisionnement de services qui sont essentiels à la sécurité (y compris la disponibilité) de vos opérations.

Atlassian travaille avec des sous-traitants tiers pour fournir des sites web, le développement d'apps, l'hébergement, la maintenance, la sauvegarde, le stockage, l'infrastructure virtuelle, le traitement des paiements, l'analyse, ainsi que d'autres services. La liste des sous-traitants actuellement engagés par Atlassian et autorisés par le client est disponible sur https://www.atlassian.com/fr/legal/sub-processors.

6.02. (b)

Détaille les procédures utilisées pour garantir l'accès des tiers à votre infrastructure (physique et/ou logique).

• Auditez-vous vos sous-traitants et si oui, à quelle fréquence ?

Nos équipes juridiques et d'approvisionnement passent en revue les contrats, les SLA et les politiques internes des fournisseurs afin de gérer les risques liés à la sécurité, à la disponibilité et à la confidentialité. Nous effectuons également des évaluations des risques fonctionnels selon les besoins sur la base du profil de risque. Les évaluations des risques sont passées en revue dans le cadre du renouvellement de la politique et chaque fois que la relation avec le fournisseur change de manière significative. Notre politique de gestion des données des fournisseurs et des tiers couvre ce processus. Un extrait de cette politique est disponible ici : https://www.atlassian.com/trust/security/ismp-policies

6.02. (c)

Les SLA garantis par les sous-traitants sont-ils moins significatifs que ceux que vous proposez à vos clients ? Si ce n'est pas le cas, avez-vous mis en place un système de redondance des fournisseurs ?

En fonction de l'accord de licence, nos conditions du cloud pour les clients doivent être revues lors du renouvellement de l'abonnement mensuel ou annuel. Nos équipes juridiques et d'approvisionnement passent en revue les contrats, les SLA et les politiques internes des fournisseurs afin de gérer les risques liés à la sécurité, à la disponibilité et à la confidentialité. Le programme de gestion des risques de l'entreprise (ERM) d'Atlassian procède à une évaluation annuelle des risques qui tient compte de la probabilité ainsi que de l'impact de l'ensemble des catégories de risques et s'aligne sur le modèle de risque COSO. Nous effectuons également des évaluations des risques fonctionnels selon les besoins sur la base du profil de risque. Les évaluations des risques sont passées en revue dans le cadre du renouvellement de la politique et chaque fois que la relation avec le fournisseur change de manière significative.

6.02. (d)

Quelles mesures ont été prises pour garantir l'atteinte et le maintien des niveaux de service des tiers ?

Nos équipes juridiques et d'approvisionnement passent en revue les contrats, les SLA et les politiques internes des fournisseurs afin de gérer les risques liés à la sécurité, à la disponibilité et à la confidentialité. Nous effectuons également des évaluations des risques fonctionnels selon les besoins sur la base du profil de risque. Les évaluations des risques sont passées en revue dans le cadre du renouvellement de la politique et chaque fois que la relation avec le fournisseur change de manière significative. Notre politique de gestion des données des fournisseurs et des tiers couvre ce processus. Un extrait de cette politique est disponible ici : https://www.atlassian.com/trust/security/ismp-policies

6.02. (e)

Le fournisseur de cloud peut-il confirmer que ses fournisseurs tiers sont soumis au respect de la politique de sécurité et tenus de conduire des contrôles de sécurité selon les dispositions du contrat ?

Tous les systèmes et projets font l'objet d'une évaluation d'impact des PII. Les accords d'Atlassian avec des tiers comprennent des dispositions relatives à la sécurité et à la protection de la vie privée, le cas échéant. Les nouveaux fournisseurs d'Atlassian sont tenus d'accepter les politiques de confidentialité et de sécurité de nos contrats.

Nos équipes juridiques et d'approvisionnement passent en revue les contrats, les SLA et les politiques internes des fournisseurs afin de gérer les risques liés à la sécurité, à la disponibilité et à la confidentialité. Le programme de gestion des risques de l'entreprise (ERM) d'Atlassian procède à une évaluation annuelle des risques qui tient compte de la probabilité ainsi que de l'impact de l'ensemble des catégories de risques et s'aligne sur le modèle de risque COSO. Nous effectuons également des évaluations des risques fonctionnels selon les besoins sur la base du profil de risque. Les évaluations des risques sont passées en revue dans le cadre du renouvellement de la politique et chaque fois que la relation avec le fournisseur change de manière significative.

6.03.

Tout accord commercial avec des fournisseurs externes devrait être décliné en plusieurs niveaux de service pour l'ensemble des services de réseau. Toutefois, en plus de l'accord défini, le client final doit s'assurer que le fournisseur effectue des contrôles appropriés en vue de limiter toute divulgation non autorisée.

6.03. (a)

Détaillez votre procédure ainsi que votre politique de contrôle des changements. Indiquez également le processus utilisé pour réévaluer les risques à la suite de changements et précisez si les résultats sont mis à la disposition des clients finaux.

Atlassian met en œuvre un Enterprise Risk Management Program (ERM) aligné sur le modèle de risque COSO et sur la norme ISO 31000. Ce programme ERM applique un framework et une méthodologie de gestion des risques dans Atlassian, et réalise des évaluations annuelles des risques, des évaluations périodiques des risques propres à l'environnement d'un produit et des évaluations des risques fonctionnels selon les besoins en fonction du profil de risque.

Le framework de gestion des risques d'Atlassian fournit notamment des normes, des processus, des rôles et des responsabilités, des tolérances au risque acceptables et des directives pour la réalisation des activités d'évaluation des risques. Nos processus et pratiques de gestion des risques nous permettent de réaliser nos évaluations des risques, lesquelles sont reproductibles et produisent des résultats valides, cohérents et comparables. Les évaluations des risques effectuées par Atlassian intègrent la probabilité et l'impact pour toutes les catégories de risques, et le traitement de tous les risques par rapport à notre appétence pour le risque définie en interne. À toutes les étapes du programme ERM, l'équipe en charge des risques et de la conformité communique avec les parties prenantes concernées et consulte les experts en la matière concernés.

Les membres du personnel qui jouent un rôle dans les processus de gestion des risques d'Atlassian sont correctement informés, connaissent leurs responsabilités et sont formés à l'exercice de leurs fonctions. Tous les risques sont suivis et gérés à l'aide de notre propre outil Jira. Leur responsabilité est assumée par la direction et des plans de traitement ainsi que des projets associés sont mis en œuvre. Pour en savoir plus, rendez-vous sur : https://www.atlassian.com/trust/security/security-management-program ou https://www.atlassian.com/trust/compliance/risk-management-program

Notre processus de gestion du changement Atlassian diffère légèrement des processus habituels. Nous suivons le processus Peer Review, Green Build (Examen par les pairs, build vert ou PRGB) pour tous les changements, qu'il s'agisse de code, d'application ou d'infrastructure. L'examen par les pairs est configuré dans notre outil de CD, où les branches critiques doivent être dotées de plusieurs examinateurs pour chaque pull request. Elles sont généralement constituées de deux développeurs et du chef d'équipe. La partie « build vert » du contrôle vérifie que l'intégration effectuée pendant la phase de CI a passé tous les tests d'intégration, de fonction et de sécurité mis en place, ainsi que tout autre test requis. Si ces tests échouent (red build), le code ne sera pas fusionné et devra être revu afin de corriger les erreurs. Quand un build vert a été effectué avec succès, le fichier binaire est signé de manière cryptographique et notre environnement de production n'exécute que les fichiers binaires signés avec notre clé. Notre processus de test comprend des éléments d'évaluation automatisés et manuels. Nous adorons publier des articles au sujet de nos réussites. Notre approche privilégiant l'« assistance qualité » (plutôt que de la traditionnelle « assurance qualité ») nous passionne : https://www.atlassian.com/fr/inside-atlassian/quality-assurance-vs-quality-assistance

6.03. (b)

Définissez la politique d'accès à distance.

Les exigences en matière d'accès à distance sont définies dans la politique de gestion des accès ainsi que les normes associées. Les données des clients peuvent être répliquées sur les postes de travail des employés à des fins d'assistance ou de migration ainsi qu'avec un ticket d'assistance client actif. Des règles strictes de pare-feu sont en place afin de limiter l'accès à l'environnement de production à notre réseau VPN et aux systèmes autorisés. Notre accès au VPN requiert une authentification multifacteur.

Tous les appareils (appartenant à Atlassian ou BYOD) utilisés par les employés d'Atlassian et susceptibles d'accéder à l'ensemble des outils d'Atlassian sont enregistrés dans la liste des appareils gérés à l'aide des profils de sécurité ainsi que du processus de vérification des pratiques de sécurité du logiciel de gestion des appareils mobiles (mobile device management, MDM). Tous les appareils Atlassian suivent le modèle de sécurité « Zero Trust ». Pour en savoir plus, rendez-vous à cette adresse : https://www.atlassian.com/trust/compliance/resources/eba/eba-guidance

6.03. (c)

Les systèmes d'information du fournisseur sont-ils dotés de procédures opérationnelles documentées ?

Les principes de base de la sécurité des opérations d'Atlassian comprennent l'élaboration de documents de procédures opérationnelles standard. Nous avons également publié des extraits de chacune de nos politiques de haut niveau ainsi qu'un résumé à l'adresse suivante : https://www.atlassian.com/trust/security/ismp-policies

6.03. (d)

Existe-t-il un environnement échelonné visant à réduire les risques, par exemple des environnements de développement, de test et d'exploitation ? Sont-ils distincts ?

Atlassian applique des politiques de sécurité de l'information interdisant l'utilisation de données de production dans les environnements hors production, et toute tentative de migration de données entre les environnements serait localisée par le biais du processus de gestion des changements. Le code passe d'un système de build centralisé à un système de tests unitaires, puis à la validation de la branche de fonctionnalité. Une automatisation supplémentaire des tests et des examens est réalisée par le gestionnaire de projet, le développeur et l'équipe d'assurance qualité. Les tests d'acceptation des utilisateurs (UAT), de sécurité et de validation des performances sont ensuite réalisés. Les développeurs ne peuvent pas passer directement du code à la production. De plus amples informations sont disponibles à l'adresse suivante https://www.atlassian.com/trust/security/security-practices#managing-changes-in-our-environment

Nous maintenons également un cloisonnement logique et physique entre les environnements de production et hors production (développement). Des méthodes sont également employées pour les isoler.

Notre environnement de staging est séparé logiquement, mais pas physiquement. Il est géré par des processus de contrôle des changements et d'accès de niveau production. Pour en savoir plus sur nos pratiques en matière de sécurité des codes, rendez-vous sur : https://www.atlassian.com/trust/security/security-in-development.

6.03. (e)

Définissez les contrôles de l'hôte et du réseau utilisés pour protéger les systèmes qui hébergent les applications et les informations destinées au client final. Ceux-ci devraient inclure des informations sur les normes externes ayant fait l'objet d'une certification (par exemple, ISO 27001/2).

Atlassian Network Engineering utilise des technologies IPS intégrées à nos pare-feux cloud et bureautiques, et Atlassian a implémenté des technologies IDS dans nos environnements de bureau. La protection contre les menaces réseau est assurée par AWS, y compris la protection contre les attaques DDoS et certaines fonctionnalités de pare-feu pour apps web.

Toutes les données de nos services sont chiffrées pendant leur transit à l'aide du protocole TLS. Elles sont ainsi protégées contre toute divulgation ou modification non autorisée, que ce soit via HTTPS ou SMTPS.

Atlassian a obtenu les certifications SOC2, ISO27001 et ISO27018 pour ses services cloud. Nous réalisons à la fois des audits internes/de préparation et des audits externes au moins une fois par an.

Pour plus d'informations, rendez-vous sur : https://www.atlassian.com/trust/compliance. Nous conseillons à nos clients de télécharger et de consulter régulièrement les mises à jour de nos certificats et rapports de conformité publiés sur ce site.

6.03. (f)

Précise les contrôles utilisés pour assurer la protection contre les codes malveillants.

Atlassian a implémenté Crowdstrike Falcon (https://www.crowdstrike.com/falcon-platform/) pour notre parc Windows et Mac. Nous n'utilisons pas de logiciel anti-programme malveillant sur nos machines Linux. Le logiciel anti-programme malveillant est inclus dans notre politique de gestion des vulnérabilités.

Nous appliquons une politique de gestion des menaces et des vulnérabilités. Notre Policy Management Program (PMP) inclut des obligations liées à la propriété, à la disponibilité et au cycle de révision. Il décrit également nos objectifs généraux. Nos politiques sont revues au moins une fois par an et approuvées par la haute direction. Pour plus d'informations sur notre PMP, rendez-vous sur : https://www.atlassian.com/trust/security/security-management-program

Nous avons également publié des extraits de chacune de nos politiques de haut niveau ainsi qu'un résumé à l'adresse suivante : https://www.atlassian.com/trust/security/ismp-policies

6.03. (g)

Des configurations sécurisées sont-elles déployées pour permettre uniquement l'exécution du code mobile et des fonctionnalités autorisés (par exemple, uniquement l'exécution de commandes spécifiques) ?

Tous les serveurs sont configurés à l'aide de notre système de configuration Puppet centralisé dans notre environnement d'exploitation standard, y compris pour la suppression de certains packages de l'image par défaut et les mises à jour de packages critiques. Tous les rôles serveur sont refusés par défaut aux demandes réseau entrantes. Par ailleurs, certains ports ne sont accessibles que par les rôles serveur qui doivent accéder à ce port pour fonctionner.

Notre réseau d'entreprise est séparé de notre réseau de production, et les images de nos machines sont renforcées pour n'autoriser que les ports et protocoles nécessaires. Tous les systèmes de production sont actuellement hébergés dans les régions américaines de notre fournisseur de cloud. Toutes les données qui transitent en dehors des réseaux cloud privés virtuels (VPC) renforcés sont chiffrées sur des canaux standard de l'industrie.

Un système de détection d'intrusion est en outre installé sur tous les serveurs de production. Celui-ci effectue une surveillance en temps réel et envoie des alertes en cas de modification des fichiers ou de la configuration du système de production ainsi que d'événements de sécurité anormaux.

Nous avons également mis en place une solution de gestion centralisée du système (https://www.jamf.com/lp/apple-mobile-device-management-mdm-jamf/) pour notre parc d'ordinateurs portables Mac. Nous chiffrons intégralement les disques de nos ordinateurs portables. Nous avons également mis en place une solution de gestion des appareils mobiles pour nos smartphones (https://www.vmware.com/products/workspace-one.html). Tous les appareils doivent avoir été enregistrés afin d'accéder aux systèmes et applications internes. Les appareils mobiles non enregistrés n'ont accès à aucune ressource interne et font partie d'un réseau invité qui ne peut accéder qu'à Internet. L'accès est géré par le biais de contrôles d'accès basés sur les rôles afin de veiller à ce que seuls les utilisateurs qui ont besoin d'accéder aux données des clients/locataires le puissent.

6.03. (h)

Préciser les politiques et les procédures de sauvegarde. Celles-ci devront inclure les procédures de gestion des supports amovibles et les méthodes pour détruire en toute sécurité les supports devenus inutiles. (Il est possible que le client souhaite mettre en place une stratégie de sauvegarde indépendante en fonction des besoins de son entreprise. Ce choix se révèle particulièrement pertinent lorsqu'un accès urgent aux sauvegardes est requis).

Atlassian met en œuvre un programme de sauvegarde complet. Ce dernier 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. Concernant 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. Les clients doivent également effectuer leurs propres sauvegardes périodiques afin de pouvoir annuler les changements qu'ils ont initiés. Pour plus d'informations, consultez la page : https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/#Can-Atlassian%E2%80%99s-RDS-backups-be-used-to-roll-back-changes.

Atlassian applique une norme de conservation et de destruction des données, qui indique la durée pendant laquelle nous devons conserver des données de différents types. Les données sont classées conformément à la politique relative à la sécurité des données et à la gestion du cycle de vie de l'information Atlassian, et des contrôles sont implémentés sur cette base.

Pour les données client, à la fin d'un contrat Atlassian, les données appartenant à une équipe client seront supprimées de la base de données de production en direct, et toutes les pièces jointes importées directement sur Atlassian seront supprimées dans les 14 jours. Les données de l'équipe seront conservées dans des sauvegardes chiffrées jusqu'à ce que ces sauvegardes soient supprimées après la période de conservation des données de 90 jours et soient détruites conformément à la politique de conservation des données Atlassian. Si une restauration de la base de données est nécessaire dans les 90 jours suivant la demande de suppression des données, l'équipe des opérations supprimera à nouveau les données dès que possible après la restauration complète du système de production en direct. Pour en savoir plus, consultez la page : https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

Les journaux d'audit sont utilisés en cas d'incident nécessitant une enquête ainsi que pour le dépannage. À ces fins, le client final devra avoir l'assurance que ces informations sont disponibles.

6.03. (i)

Le fournisseur peut-il détailler les informations enregistrées dans les journaux d'audit ?

• Pendant combien de temps ces données sont-elles conservées ?
• Est-il possible de segmenter les données dans les journaux d'audit de manière à ce que le client final et/ou les autorités policières puissent y accéder sans compromettre d'autres clients, et que ces données restent recevables devant les tribunaux ?
• Quels sont les contrôles employés pour protéger les journaux contre toute altération ou tout accès non autorisés ?
• Quelle méthode est utilisée pour vérifier et protéger l'intégrité des journaux d'audit ?

Les journaux système clés sont transférés à partir de chaque système vers une plateforme de journaux centralisée où ils sont disponibles en lecture seule. L'équipe Atlassian chargée de la sécurité crée des alertes sur notre plateforme d'analyse de sécurité (Splunk) et surveille les indicateurs de compromission. Nos équipes SRE utilisent cette plateforme pour surveiller les problèmes de disponibilité ou de performance. Les journaux sont conservés pendant 30 jours en sauvegarde à chaud et pendant 365 jours en sauvegarde à froid.

Atlassian limite la possibilité de visualiser et de lire les journaux d'audit au personnel autorisé sur notre plateforme de journalisation centralisée.

Atlassian applique une norme de conservation et de destruction des données, qui indique la durée pendant laquelle nous devons conserver des données de différents types. Les données sont classées conformément à la politique relative à la sécurité des données et à la gestion du cycle de vie de l'information Atlassian, et des contrôles sont implémentés sur cette base.

Pour les données client, à la fin d'un contrat Atlassian, les données appartenant à une équipe client seront supprimées de la base de données de production en direct, et toutes les pièces jointes importées directement sur Atlassian seront supprimées dans les 14 jours. Les données de l'équipe seront conservées dans des sauvegardes chiffrées jusqu'à ce que ces sauvegardes soient supprimées après la période de conservation des données de 90 jours et soient détruites conformément à la politique de conservation des données Atlassian. Si une restauration de la base de données est nécessaire dans les 90 jours suivant la demande de suppression des données, l'équipe des opérations supprimera à nouveau les données dès que possible après la restauration complète du système de production en direct. Pour en savoir plus, consultez la page : https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

6.03. (j)

Comment sont revus les journaux d'audit ? Quels sont les événements enregistrés qui donnent lieu à une action ?

Les journaux système clés sont transférés à partir de chaque système vers une plateforme de journaux centralisée où ils sont disponibles en lecture seule. L'équipe Atlassian chargée de la sécurité crée des alertes sur notre plateforme d'analyse de sécurité (Splunk) et surveille les indicateurs de compromission. Nos équipes SRE utilisent cette plateforme pour surveiller les problèmes de disponibilité ou de performance. Les journaux sont conservés pendant 30 jours en sauvegarde à chaud et pendant 365 jours en sauvegarde à froid.

Atlassian limite la possibilité de consulter et de lire les journaux d'audit au personnel autorisé sur notre plateforme de journalisation centralisée.

6.03. (k)

Quelle source de temps est utilisée pour synchroniser les systèmes et fournir un horodatage précis des journaux d'audit ?

Atlassian Cloud utilise AWS Time Sync pour toutes les instances déployées.

6.03.01. (a)

Définir les contrôles utilisés pour protéger l'intégrité du système d'exploitation et des logiciels applicatifs utilisés. Inclure toutes les normes qui ont été observées, par exemple OWASP, liste de contrôle SANS, SAFECode.

Notre équipe d'ingénieurs en sécurité procède en permanence à une revue de l'ensemble du code source de nos produits dans le cadre de notre cycle de développement. Des techniques automatisées et manuelles sont employées. Nous utilisons également un processus obligatoire de double revue par des pairs, au cours duquel plusieurs développeurs expérimentés ou développeurs chefs examinent toutes les commits apportés au master. Les flux de travail agiles nous permettent d'identifier et de corriger rapidement les vulnérabilités, en particulier pour nos services cloud.

Le processus de revue de code sécurisé d'Atlassian comprend une analyse automatisée (c'est-à-dire l'analyse de la composition des logiciels) pour détecter les vulnérabilités connues, y compris celles qui sont exploitées dans des attaques réelles. En outre, notre programme de gestion des vulnérabilités analyse les hôtes et les images de conteneurs pour détecter les vulnérabilités connues à l'aide de Snyk. Pour en savoir plus, consultez la page : https://www.atlassian.com/trust/security/vulnerability-management.

Nous travaillons avec BugCrowd pour maintenir un programme Bug Bounty, afin de mener des évaluations continues des vulnérabilités de nos Applications et Services accessibles au public. Le programme est disponible à l'adresse suivante : https://bugcrowd.com/atlassian. Nous partageons les résultats des tests de pénétration en cours de notre programme Bug Bounty à l'adresse suivante : https://www.atlassian.com/trust/security/security-testing.

6.03.01. (b)

Comment vérifiez-vous que les nouvelles versions sont adaptées à leur usage ou qu'elles ne présentent pas de risques (portes dérobées, chevaux de Troie, etc.) ? Sont-elles examinées avant utilisation ?

Notre processus de gestion des changements Atlassian diffère légèrement des processus habituels. Nous suivons le processus Peer Review, Green Build (Examen par les pairs, build vert ou PRGB) pour tous les changements, qu'il s'agisse de code, d'application ou d'infrastructure. L'examen par les pairs est configuré dans notre outil de CD, où les branches critiques doivent être dotées de plusieurs examinateurs pour chaque pull request. Elles sont généralement constituées de deux développeurs et du chef d'équipe. La partie « build vert » du contrôle vérifie que l'intégration effectuée pendant la phase de CI a passé tous les tests d'intégration, de fonction et de sécurité mis en place, ainsi que tout autre test requis. Si ces tests échouent (red build), le code ne sera pas fusionné et devra être revu afin de corriger les erreurs. Quand un build vert a été effectué avec succès, le fichier binaire est signé de manière cryptographique et notre environnement de production n'exécute que les fichiers binaires signés avec notre clé. Notre processus de test comprend des éléments d'évaluation automatisés et manuels. Nous adorons publier des articles au sujet de nos réussites. Notre approche privilégiant l'« assistance qualité » (plutôt que de la traditionnelle « assurance qualité ») nous passionne : https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance.

Après le déploiement, nous utilisons régulièrement une analyse automatisée des vulnérabilités ainsi que le programme Bug Bounty leader dans le secteur (https://bugcrowd.com/atlassian) pour garantir l'assurance continue de nos applications. Les changements apportés à la configuration du système sont gérés par un processus automatisé qui comporte une revue.

Le processus de revue de code sécurisé d'Atlassian comprend une analyse automatisée (c'est-à-dire l'analyse de la composition des logiciels) pour détecter les vulnérabilités connues, y compris celles qui sont exploitées dans des attaques réelles. En outre, notre programme de gestion des vulnérabilités analyse les hôtes et les images de conteneurs pour détecter les vulnérabilités connues à l'aide de Snyk. Pour en savoir plus, consultez la page : https://www.atlassian.com/trust/security/vulnerability-management.

6.03.01. (c)

Quelles sont les pratiques suivies pour assurer la sécurité des applications ?

Nos applications nécessitent un « Peer Review and Green Build » (revue par les pairs, build vert ou PRGB), à la suite duquel les artefacts des applications sont signés cryptographiquement, déployés automatiquement par notre pipeline CI/CD, et seules les applications signées Atlassian peuvent être exécutées dans notre environnement de production.

Atlassian applique des pratiques de développement sécurisées à toutes les phases du cycle de vie du développement. Consultez la page : https://www.atlassian.com/fr/trust/security/security-in-development pour en savoir plus.

Lors de la phase de design, les pratiques comprennent la modélisation des menaces, la revue de design ainsi que notre bibliothèque de normes de sécurité régulièrement mise à jour, qui garantit que les exigences de sécurité sont prises en compte.

Lors du développement, nous comptons sur un processus de revue par les pairs obligatoire comme première ligne d'examen de la sécurité. Cette approche est soutenue par des contrôles automatisés d'analyse statique (SAST) et des tests de sécurité manuels (réalisés par des équipes internes et des experts tiers, comme l'exige notre processus d'évaluation des risques). Le développement est également appuyé par des programmes de formation à la sécurité des applications ainsi que par une base de connaissances sur la sécurité gérée par l'équipe de sécurité.

Des processus formels de préparation opérationnelle et de contrôle des changements garantissent ensuite que seuls les changements approuvés sont déployés en production. Après le déploiement, nous utilisons régulièrement une analyse automatisée des vulnérabilités ainsi que le programme Bug Bounty leader dans le secteur (https://bugcrowd.com/atlassian) pour garantir l'assurance continue de nos applications. Les modifications de la configuration du système sont gérées par un processus automatisé qui comprend une revue de tous les changements avant leur déploiement en production. Atlassian Service Operations peut déployer des correctifs dès qu'un risque important est identifié. Nous disposons de critères internes pour déterminer la rapidité de mise en œuvre des correctifs, et nous pouvons les appliquer dans les 12 heures pour toutes les machines. Un système IDS est également en place et comprend la surveillance des fichiers de configuration du système.

6.03.01. (d)

La version d'un logiciel fait-elle l'objet d'un test de pénétration pour s'assurer qu'elle ne contient pas de vulnérabilités ? Si des vulnérabilités sont découvertes, quel est le processus suivi pour y remédier ?

Atlassian applique des pratiques de développement sécurisées à toutes les phases du cycle de vie du développement. Consultez la page : https://www.atlassian.com/fr/trust/security/security-in-development pour en savoir plus.

Lors du développement, nous comptons sur un processus de revue par les pairs obligatoire comme première ligne d'examen de la sécurité. Cette approche est soutenue par des contrôles automatisés d'analyse statique (SAST) et des tests de sécurité manuels (réalisés par des équipes internes et des experts tiers, comme l'exige notre processus d'évaluation des risques). Le développement est également appuyé par des programmes de formation à la sécurité des applications ainsi que par une base de connaissances sur la sécurité gérée par l'équipe de sécurité.

Des processus formels de préparation opérationnelle et de contrôle des changements garantissent ensuite que seuls les changements approuvés sont déployés en production. Après le déploiement, nous utilisons régulièrement une analyse automatisée des vulnérabilités ainsi que le programme Bug Bounty leader dans le secteur (https://bugcrowd.com/atlassian) pour garantir l'assurance continue de nos applications.

6.03.02. (a)

Pouvez-vous fournir des détails sur la procédure de gestion des correctifs suivie ?

Nous appliquons une politique de gestion des menaces et des vulnérabilités. Notre Policy Management Program (PMP) inclut des obligations liées à la propriété, à la disponibilité et au cycle de révision. Il décrit également nos objectifs généraux. Nos politiques sont revues au moins une fois par an et approuvées par la haute direction. Pour plus d'informations sur notre PMP, rendez-vous sur : https://www.atlassian.com/trust/security/security-management-program

Nous avons également publié des extraits de chacune de nos politiques de haut niveau ainsi qu'un résumé à l'adresse suivante : https://www.atlassian.com/trust/security/ismp-policies

Atlassian combine des méthodologies de gestion des terminaux pour déployer des mises à jour et des correctifs sur les systèmes d'exploitation et les apps clés de son parc de terminaux. Nous avons également implémenté plusieurs solutions de protection des terminaux pour nous prémunir contre les menaces telles que les logiciels malveillants. Pour plus de détails, consultez la page : https://www.atlassian.com/trust/security/security-practices#keeping-track-of-information-assets

6.03.02. (b)

Pouvez-vous garantir que le processus de gestion des correctifs couvre toutes les couches des technologies de cloud computing, c'est-à-dire le réseau (composants d'infrastructure, routeurs et commutateurs, etc.), les systèmes d'exploitation des serveurs, les logiciels de virtualisation, les applications et les sous-systèmes de sécurité (pare-feu, passerelles antivirus, systèmes de détection d'intrusion, etc.)

Les modifications de la configuration du système sont gérées par un processus automatisé qui comprend une revue de tous les changements avant leur déploiement en production. Atlassian Service Operations peut déployer des correctifs dès qu'un risque important est identifié. Nous disposons de critères internes pour déterminer la rapidité de mise en œuvre des correctifs, et nous pouvons les appliquer dans les 12 heures pour toutes les machines. Un système IDS est également en place et comprend la surveillance des fichiers de configuration du système.


Les produits Atlassian Cloud peuvent être mis à jour vers la dernière AMI aussi rapidement que nécessaire. Nos applications SaaS sont mises à jour plusieurs fois par semaine. Nous disposons de mécanismes de déploiement rapides et contrôlés pour les mises à jour apportées aux configurations de notre code et de notre système. Atlassian utilise activement un contrôle des changements pour les changements non programmés et les changements d'urgence.

6.03.03. (a)

Définissez les contrôles utilisés pour atténuer les attaques DDoS (déni de service distribué).

• Défense en profondeur (analyse approfondie des paquets, étranglement du trafic, blocage des paquets, etc.)
• Disposez-vous de moyens de défense contre les attaques « internes » (provenant des réseaux des fournisseurs de services dans le cloud) et contre les attaques externes (provenant d'Internet ou des réseaux des clients) ?
<

Les exigences de sécurité réseau sont définies dans la politique de sécurité des communications, qui est revue chaque année conformément à notre Policy Management Program (PMP). Pour en savoir plus sur notre PMP, consultez la page : https://www.atlassian.com/trust/security/security-management-program

Notre plateforme Atlassian Cloud est très peu exposée par le biais des pare-feux. Nous revoyons régulièrement les règles de pare-feu. Nous avons déployé un système de détection des intrusions (IDS) sur nos sites de bureau et dans notre environnement d'hébergement dans le cloud. Pour la plateforme Atlassian Cloud, le transfert des journaux est intégré à une plateforme d'analyse de sécurité. Au niveau du conteneur de la plateforme Cloud, l'intégrité des fichiers est préservée, car les instances ne peuvent pas être modifiées. Atlassian Network Engineering utilise des technologies IPS intégrées à nos pare-feux, et nous avons implémenté des technologies IDS dans nos environnements de bureau et cloud. Les fonctionnalités DDoS sont fournies par notre fournisseur de service Internet/opérateur.

Les performances de nos pare-feux sont également évaluées régulièrement par le biais de nos programmes d'évaluation des vulnérabilités (https://www.atlassian.com/trust/security/vulnerability-management) et de tests d'intrusion (https://www.atlassian.com/trust/security/security-testing).

6.03.03. (b)

Quels sont les niveaux d'isolement utilisés ?

• Pour les machines virtuelles, les machines physiques, le réseau, le stockage (par exemple, les réseaux de stockage), les réseaux de gestion et les systèmes de support à la gestion, et plus encore.
<

Atlassian est une application SaaS multilocataire. La multilocation est une fonctionnalité clé d'Atlassian Cloud qui permet à plusieurs clients de partager une instance de la couche applicative Jira ou Confluence, tout en isolant les données d'application du locataire de chaque client. Atlassian Cloud y parvient grâce au service de contexte de locataire (Tenant Context Service ou TCS). Chaque ID utilisateur est associé à un seul locataire, qui permet ensuite d'accéder aux applications Atlassian Cloud. Pour en savoir plus, consultez la page : https://www.atlassian.com/trust/security/security-practices#tenant-isolation

Nous maintenons également un cloisonnement logique et physique entre les environnements de production et hors production (développement). Des méthodes sont également employées pour les isoler.

Notre environnement de staging est séparé logiquement, mais pas physiquement. Il est géré par des processus de contrôle des changements et d'accès de niveau production.

6.03.03. (c)

L'architecture permet-elle une opération continue depuis le cloud lorsque l'entreprise est séparée du fournisseur de services et vice versa (par exemple, y a-t-il une dépendance critique à l'égard du système LDAP du client) ?

Une politique et un plan de continuité de l'activité et de reprise d'activité sont en place et sont examinés chaque année par le comité directeur qui en est chargé. Pour en savoir plus, consultez les pages : https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e et https://www.atlassian.com/trust/security/data-management.

Atlassian utilise les data centers hautement disponibles d'AWS dans de nombreuses régions du monde pour garantir la continuité des opérations. Pour en savoir plus, consultez la page : https://www.atlassian.com/trust/security/data-management.

6.03.03. (d)

L'infrastructure réseau virtuelle utilisée par les fournisseurs de cloud (dans le cadre de l'architecture PVLAN et VLAN 802.1q) est-elle sécurisée conformément aux normes spécifiques des fournisseurs et/ou des bonnes pratiques (par exemple, l'usurpation d'adresse MAC, l'usurpation d'adresse ARP, et autres attaques, sont-elles évitées grâce à une configuration de sécurité spécifique) ?

Les exigences de sécurité réseau sont définies dans la politique de sécurité des communications, qui est revue chaque année conformément à notre Policy Management Program (PMP). Pour en savoir plus sur notre PMP, consultez la page : https://www.atlassian.com/trust/security/security-management-program

Notre plateforme Atlassian Cloud est très peu exposée par le biais des pare-feux. Nous revoyons régulièrement les règles de pare-feu. Nous avons déployé un système de détection des intrusions (IDS) sur nos sites de bureau et dans notre environnement d'hébergement dans le cloud. Pour la plateforme Atlassian Cloud, le transfert des journaux est intégré à une plateforme d'analyse de sécurité. Au niveau du conteneur de la plateforme Cloud, l'intégrité des fichiers est préservée, car les instances ne peuvent pas être modifiées. Atlassian Network Engineering utilise des technologies IPS intégrées à nos pare-feux, et nous avons implémenté des technologies IDS dans nos environnements de bureau et cloud. Les fonctionnalités DDoS sont fournies par notre fournisseur de service Internet/opérateur.

Les performances de nos pare-feux sont également évaluées régulièrement par le biais de nos programmes d'évaluation des vulnérabilités (https://www.atlassian.com/trust/security/vulnerability-management) et de tests d'intrusion (https://www.atlassian.com/trust/security/security-testing).

En outre, Atlassian surveille la configuration de nos environnements AWS par rapport aux références de configuration établies.

6.03.04. (a)

Le fournisseur s'assure-t-il que les images virtuelles sont renforcées par défaut ?

Tous les serveurs sont configurés à l'aide de notre système de configuration Puppet centralisé dans notre environnement d'exploitation standard, y compris pour la suppression de certains packages de l'image par défaut et les mises à jour de packages critiques. Tous les rôles serveur sont refusés par défaut aux demandes réseau entrantes. Par ailleurs, certains ports ne sont accessibles que par les rôles serveur qui doivent accéder à ce port pour fonctionner.

Notre réseau d'entreprise est séparé de notre réseau de production, et les images de nos machines sont renforcées pour n'autoriser que les ports et protocoles nécessaires. Tous les systèmes de production sont actuellement hébergés dans les régions américaines de notre fournisseur de cloud. Toutes les données qui transitent en dehors des réseaux cloud privés virtuels (VPC) renforcés sont chiffrées sur des canaux standard de l'industrie.

Un système de détection d'intrusion est en outre installé sur tous les serveurs de production. Celui-ci effectue une surveillance en temps réel et envoie des alertes en cas de modification des fichiers ou de la configuration du système de production ainsi que d'événements de sécurité anormaux.

Dans la plateforme Atlassian Cloud, les conteneurs individuels ne possèdent pas d'image. Lorsque le conteneur est lancé, une image est sélectionnée dans un dépôt standard. Nous procédons à un audit continu pour chacune des images et proposons une nouvelle application des images par nos outils de configuration, si nécessaire. Par conséquent, aucun changement n'est apporté aux images de la machine virtuelle.

Les builds d'image du système d'exploitation de base AWS Linux AMI présentent des ports, des protocoles et des services limités. Nous comparons nos builds à la version AMI actuelle afin de garantir des paramètres appropriés.

Nos images Docker sont gérées dans un environnement de changement étroitement contrôlé afin de garantir un examen et une approbation adéquats de tous les changements.

6.03.04. (b)

L'image virtuelle renforcée est-elle protégée contre tout accès non autorisé ?

Tous les serveurs sont configurés à l'aide de notre système de configuration Puppet centralisé dans notre environnement d'exploitation standard, y compris pour la suppression de certains packages de l'image par défaut et les mises à jour de packages critiques. Tous les rôles serveur sont refusés par défaut aux demandes réseau entrantes. Par ailleurs, certains ports ne sont accessibles que par les rôles serveur qui doivent accéder à ce port pour fonctionner.

Notre réseau d'entreprise est séparé de notre réseau de production, et les images de nos machines sont renforcées pour n'autoriser que les ports et protocoles nécessaires. Tous les systèmes de production sont actuellement hébergés dans les régions américaines de notre fournisseur de cloud. Toutes les données qui transitent en dehors des réseaux cloud privés virtuels (VPC) renforcés sont chiffrées sur des canaux standard de l'industrie.

Un système de détection d'intrusion est en outre installé sur tous les serveurs de production. Celui-ci effectue une surveillance en temps réel et envoie des alertes en cas de modification des fichiers ou de la configuration du système de production ainsi que d'événements de sécurité anormaux.

Dans la plateforme Atlassian Cloud, les conteneurs individuels ne possèdent pas d'image. Lorsque le conteneur est lancé, une image est sélectionnée dans un dépôt standard. Nous procédons à un audit continu pour chacune des images et proposons une nouvelle application des images par nos outils de configuration, si nécessaire. Par conséquent, aucun changement n'est apporté aux images de la machine virtuelle.

Les builds d'image du système d'exploitation de base AWS Linux AMI présentent des ports, des protocoles et des services limités. Nous comparons nos builds à la version AMI actuelle afin de garantir des paramètres appropriés.

Nos images Docker sont gérées dans un environnement de changement étroitement contrôlé afin de garantir un examen et une approbation adéquats de tous les changements.

Notre équipe de support mondiale gère un compte sur l'ensemble des systèmes et applications hébergés à des fins de maintenance et de support. L'équipe de support accède uniquement aux applications et aux données hébergées à des fins de surveillance de l'intégrité des applications et de maintenance du système ou des applications, et sur demande des clients via notre système de support.

6.03.04. (c)

Le fournisseur peut-il confirmer que l'image virtualisée ne contient pas les informations d'authentification ?

Tous les serveurs sont configurés à l'aide de notre système de configuration Puppet centralisé dans notre environnement d'exploitation standard, y compris pour la suppression de certains packages de l'image par défaut et les mises à jour de packages critiques. Tous les rôles serveur sont refusés par défaut aux demandes réseau entrantes. Par ailleurs, certains ports ne sont accessibles que par les rôles serveur qui doivent accéder à ce port pour fonctionner.

Notre réseau d'entreprise est séparé de notre réseau de production, et les images de nos machines sont renforcées pour n'autoriser que les ports et protocoles nécessaires. Tous les systèmes de production sont actuellement hébergés dans les régions américaines de notre fournisseur de cloud. Toutes les données qui transitent en dehors des réseaux cloud privés virtuels (VPC) renforcés sont chiffrées sur des canaux standard de l'industrie.

Un système de détection d'intrusion est en outre installé sur tous les serveurs de production. Celui-ci effectue une surveillance en temps réel et envoie des alertes en cas de modification des fichiers ou de la configuration du système de production ainsi que d'événements de sécurité anormaux.

Dans la plateforme Atlassian Cloud, les conteneurs individuels ne possèdent pas d'image. Lorsque le conteneur est lancé, une image est sélectionnée dans un dépôt standard. Nous procédons à un audit continu pour chacune des images et proposons une nouvelle application des images par nos outils de configuration, si nécessaire. Par conséquent, aucun changement n'est apporté aux images de la machine virtuelle.

Les builds d'image du système d'exploitation de base AWS Linux AMI présentent des ports, des protocoles et des services limités. Nous comparons nos builds à la version AMI actuelle afin de garantir des paramètres appropriés.

Nos images Docker sont gérées dans un environnement de changement étroitement contrôlé afin de garantir un examen et une approbation adéquats de tous les changements.

Notre équipe de support mondiale gère un compte sur l'ensemble des systèmes et applications hébergés à des fins de maintenance et de support. L'équipe de support accède uniquement aux applications et aux données hébergées à des fins de surveillance de l'intégrité des applications et de maintenance du système ou des applications, et sur demande des clients via notre système de support.

6.03.04. (d)

Le pare-feu hôte fonctionne-t-il uniquement avec le minimum de ports nécessaires pour prendre en charge les services de l'instance virtuelle ?

Tous les serveurs sont configurés à l'aide de notre système de configuration Puppet centralisé dans notre environnement d'exploitation standard, y compris pour la suppression de certains packages de l'image par défaut et les mises à jour de packages critiques. Tous les rôles serveur sont refusés par défaut aux demandes réseau entrantes. Par ailleurs, certains ports ne sont accessibles que par les rôles serveur qui doivent accéder à ce port pour fonctionner.

Notre réseau d'entreprise est séparé de notre réseau de production, et les images de nos machines sont renforcées pour n'autoriser que les ports et protocoles nécessaires. Tous les systèmes de production sont actuellement hébergés dans les régions américaines de notre fournisseur de cloud. Toutes les données qui transitent en dehors des réseaux cloud privés virtuels (VPC) renforcés sont chiffrées sur des canaux standard de l'industrie.

Notre plateforme Atlassian Cloud est très peu exposée par le biais des pare-feux. Nous revoyons régulièrement les règles de pare-feu. Nous avons déployé un système de détection des intrusions (IDS) sur nos sites de bureau et dans notre environnement d'hébergement dans le cloud. Pour la plateforme Atlassian Cloud, le transfert des journaux est intégré à une plateforme d'analyse de sécurité. Au niveau du conteneur de la plateforme Cloud, l'intégrité des fichiers est préservée, car les instances ne peuvent pas être modifiées. Atlassian Network Engineering utilise des technologies IPS intégrées à nos pare-feux, et nous avons implémenté des technologies IDS dans nos environnements de bureau et cloud. Les fonctionnalités DDoS sont fournies par notre fournisseur de service Internet/opérateur.

Les performances de nos pare-feux sont également évaluées régulièrement par le biais de nos programmes d'évaluation des vulnérabilités (https://www.atlassian.com/trust/security/vulnerability-management) et de tests d'intrusion (https://www.atlassian.com/trust/security/security-testing).

6.03.04. (e)

Un service de prévention des intrusions (IPS) basé sur l'hôte peut-il être exécuté dans l'instance virtuelle ?

Cela ne s'applique pas, car Atlassian utilise un modèle Software as a Service (SaaS).

6.03.05.

D'une manière générale, les fournisseurs de services PaaS sont responsables de la sécurité de la stack logicielle de la plateforme. Par ailleurs, les recommandations formulées dans ce document constituent une bonne base pour garantir qu'un fournisseur PaaS tient compte des principes de sécurité lors de la conception et de la gestion de sa plateforme PaaS. Il est souvent difficile d'obtenir des informations détaillées auprès des fournisseurs PaaS sur la manière exacte dont ils sécurisent leurs plateformes. Cependant, les questions suivantes, ainsi que d'autres sections de ce document, devraient vous aider à évaluer leurs offres.

6.03.05. (a)

Demande d'informations sur la manière dont les applications multilocataires sont isolées les unes des autres. Une description générale des mesures de confinement et d'isolation est requise.

Cela ne s'applique pas, car Atlassian utilise un modèle Software as a Service (SaaS).

6.03.05. (b)

Comment le fournisseur PaaS peut-il garantir que l'accès à vos données est réservé aux utilisateurs de votre entreprise et aux applications que vous possédez ?

Cela ne s'applique pas, car Atlassian utilise un modèle Software as a Service (SaaS).

6.03.05. (c)

L'architecture de la plateforme devrait être une « sandbox » classique. Le fournisseur veille-t-il à ce que la sandbox de la plateforme PaaS soit surveillée pour détecter de nouveaux bugs et vulnérabilités ?

Cela ne s'applique pas, car Atlassian utilise un modèle Software as a Service (SaaS).

6.03.05. (d)

Les fournisseurs PaaS doivent être en mesure de proposer un ensemble de fonctionnalités de sécurité (réutilisables par leurs clients). Ces fonctionnalités incluent-elles l'authentification des utilisateurs, l'authentification unique, l'autorisation (gestion des privilèges) et le protocole SSL/TLS (disponible via une API) ?

Cela ne s'applique pas, car Atlassian utilise un modèle Software as a Service (SaaS).

6.03.06.

Le modèle SaaS impose au fournisseur de gérer l'ensemble des applications proposées aux utilisateurs finaux. Les fournisseurs SaaS sont donc principalement responsables de la sécurisation de ces applications. Les clients sont normalement responsables des processus de sécurité opérationnelle (gestion des utilisateurs et des accès). Les questions suivantes, ainsi que d'autres sections de ce document, vous aideront à évaluer leurs offres :

6.03.06. (a)

Quels sont les contrôles administratifs fournis, et peuvent-ils être utilisés pour attribuer des privilèges de lecture et d'écriture à d'autres utilisateurs ?

Les clients de nos offres Enterprise et Premium Cloud ont accès à un panneau de contrôle d'administration centralisé. Les administrateurs de votre organisation peuvent gérer l'accès et les autorisations des utilisateurs sur toutes les instances de vos produits. Consultez notre billet de blog ici : https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Les clients Atlassian peuvent utiliser le fournisseur d'identité tiers de leur choix si ce dernier est pris en charge par Atlassian. Une page du support Atlassian détaille ces fonctionnalités et présente la marche à suivre pour connecter le fournisseur d'identité de votre choix : https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/.

6.03.06. (b)

Le contrôle d'accès SaaS est-il granulaire et peut-il être personnalisé conformément à la politique de votre organisation ?

Les clients de nos offres Enterprise et Premium Cloud ont accès à un panneau de contrôle d'administration centralisé. Les administrateurs de votre organisation peuvent gérer l'accès et les autorisations des utilisateurs sur toutes les instances de vos produits. Consultez notre billet de blog ici : https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Les clients Atlassian peuvent utiliser le fournisseur d'identité tiers de leur choix si ce dernier est pris en charge par Atlassian. Une page du support Atlassian détaille ces fonctionnalités et présente la marche à suivre pour connecter le fournisseur d'identité de votre choix : https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/.

6.03.07. (a)

En cas de surprovisionnement des ressources (traitement, mémoire, stockage, réseau) :

• Quelles informations sont fournies sur la priorité relative attribuée à ma demande en cas d'échec de provisionnement ?
• Y a-t-il un délai en ce qui concerne les niveaux de service et l'évolution des exigences ?
<

Atlassian planifie ses capacités 6 à 12 mois à l'avance, avec une planification stratégique globale sur 36 mois.

Atlassian effectue des analyses de l'évolutivité verticale et horizontale de l'architecture du cloud AWS et d'Azure, et utilise ces données pour assurer la croissance des produits Atlassian. Cependant, ces données ne sont pas fournies aux clients pour le moment.

6.03.07. (b)

Dans quelle mesure pouvez-vous évoluer ? Le fournisseur offre-t-il des garanties sur le maximum de ressources disponibles sur une période minimale ?

Atlassian planifie ses capacités 6 à 12 mois à l'avance, avec une planification stratégique globale sur 36 mois.

Atlassian effectue des analyses de l'évolutivité verticale et horizontale de l'architecture du cloud AWS et d'Azure, et utilise ces données pour assurer la croissance des produits Atlassian. Cependant, ces données ne sont pas fournies aux clients pour le moment.

6.03.07. (c)

À quelle vitesse pouvez-vous évoluer ? Le fournisseur offre-t-il des garanties quant à la disponibilité de ressources supplémentaires sur une période minimale ?

Atlassian planifie ses capacités 6 à 12 mois à l'avance, avec une planification stratégique globale sur 36 mois.

Atlassian effectue des analyses de l'évolutivité verticale et horizontale de l'architecture du cloud AWS et d'Azure, et utilise ces données pour assurer la croissance des produits Atlassian. Cependant, ces données ne sont pas fournies aux clients pour le moment.

6.03.07. (d)

Quels sont les processus mis en place pour gérer les tendances à grande échelle en matière d'utilisation des ressources (par exemple, les effets saisonniers) ?

Atlassian planifie ses capacités 6 à 12 mois à l'avance, avec une planification stratégique globale sur 36 mois.

Atlassian effectue des analyses de l'évolutivité verticale et horizontale de l'architecture du cloud AWS et d'Azure, et utilise ces données pour assurer la croissance des produits Atlassian. Cependant, ces données ne sont pas fournies aux clients pour le moment.

6.04.01.

Les contrôles suivants s'appliquent aux systèmes de gestion des identités et des accès du fournisseur de cloud (ceux qui sont sous son contrôle).

6.04.01. (a)

Certains comptes bénéficient-ils de privilèges sur l'ensemble du système cloud, et si oui, pour quelles opérations (lecture/écriture/suppression) ?

Notre équipe de support mondiale gère un compte sur l'ensemble des systèmes et applications hébergés à des fins de maintenance et de support. L'équipe de support accède uniquement aux applications et aux données hébergées à des fins de surveillance de l'intégrité des applications et de maintenance du système ou des applications, et sur demande des clients via notre système de support.

6.04.01. (b)

Comment les comptes bénéficiant du plus haut niveau de privilèges sont-ils authentifiés et gérés ?

Atlassian impose des restrictions au personnel qui a besoin de cet accès dans le cadre de son travail, de son rôle et de ses responsabilités. Tous les systèmes de niveau 1 sont gérés via une solution d'authentification unique (SSO) et d'annuaire centralisée Atlassian. Les utilisateurs disposent de droits d'accès appropriés en fonction de ces profils, conformément au workflow de notre système de gestion des ressources humaines. Atlassian utilise l'authentification multifacteur pour accéder à tous les systèmes de niveau 1. Nous avons activé l'authentification à deux facteurs pour la console de gestion de l'hyperviseur et l'API AWS, ainsi qu'un rapport d'audit quotidien sur tous les accès aux fonctions de gestion de l'hyperviseur. Les listes d'accès à la console de gestion de l'hyperviseur et à l'API AWS sont revues tous les trimestres. Nous assurons également une synchronisation de 8 heures entre notre système RH et notre magasin d'identités.

6.04.01. (c)

Comment sont autorisées les décisions les plus critiques (par exemple, le déprovisionnement simultané de grands blocs de ressources) (authentification unique ou à deux facteurs, et par quels rôles au sein de l'organisation) ?

Atlassian impose des restrictions au personnel qui a besoin de cet accès dans le cadre de son travail, de son rôle et de ses responsabilités. Tous les systèmes de niveau 1 sont gérés via une solution d'authentification unique (SSO) et d'annuaire centralisée Atlassian. Les utilisateurs disposent de droits d'accès appropriés en fonction de ces profils, conformément au workflow de notre système de gestion des ressources humaines. Atlassian utilise l'authentification multifacteur pour accéder à tous les systèmes de niveau 1. Nous avons activé l'authentification à deux facteurs pour la console de gestion de l'hyperviseur et l'API AWS, ainsi qu'un rapport d'audit quotidien sur tous les accès aux fonctions de gestion de l'hyperviseur. Les listes d'accès à la console de gestion de l'hyperviseur et à l'API AWS sont revues tous les trimestres. Nous assurons également une synchronisation de 8 heures entre notre système RH et notre magasin d'identités.

Des contrôles de séparation des tâches sont en place pour nos principaux produits et incluent notamment les éléments suivants :

• Révision des contrôles d'accès
• Groupes de sécurité gérés par les applications RH
• Approbation des changements/revue par des pairs/implémentation (PRGB)
• Contrôles de workflow

6.04.01. (d)

Les rôles disposant d'un niveau de privilèges élevé sont-ils attribués à la même personne ? Ce modèle d'attribution va-t-il à l'encontre des principes de séparation des tâches ou du moindre privilège ?

Atlassian impose des restrictions au personnel qui a besoin de cet accès dans le cadre de son travail, de son rôle et de ses responsabilités. Tous les systèmes de niveau 1 sont gérés via une solution d'authentification unique (SSO) et d'annuaire centralisée Atlassian. Les utilisateurs disposent de droits d'accès appropriés en fonction de ces profils, conformément au workflow de notre système de gestion des ressources humaines. Atlassian utilise l'authentification multifacteur pour accéder à tous les systèmes de niveau 1. Nous avons activé l'authentification à deux facteurs pour la console de gestion de l'hyperviseur et l'API AWS, ainsi qu'un rapport d'audit quotidien sur tous les accès aux fonctions de gestion de l'hyperviseur. Les listes d'accès à la console de gestion de l'hyperviseur et à l'API AWS sont revues tous les trimestres. Nous assurons également une synchronisation de 8 heures entre notre système RH et notre magasin d'identités.

Des contrôles de séparation des tâches sont en place pour nos principaux produits et incluent notamment les éléments suivants :

• Révision des contrôles d'accès
• Groupes de sécurité gérés par les applications RH
• Approbation des changements/revue par des pairs/implémentation (PRGB)
• Contrôles de workflow

6.04.01. (e)

Utilisez-vous le contrôle d'accès basé sur les rôles (RBAC) ? Le principe du moindre privilège est-il respecté ?

Atlassian a mis en place un workflow reliant nos systèmes de gestion des ressources humaines et de provisionnement des accès. Nous utilisons un contrôle d'accès basé sur des profils utilisateur prédéfinis. Tous les comptes utilisateur doivent être approuvés par la direction avant d'avoir accès aux données, aux applications, à l'infrastructure ou aux composants réseau.

Atlassian impose des restrictions au personnel qui a besoin d'accéder à nos systèmes, à nos applications et à notre infrastructure dans le cadre de son rôle et de ses responsabilités selon le principe du moindre privilège, et ce, par le biais de nos processus d'authentification.

6.04.01. (f)

Quelles modifications, le cas échéant, ont été apportées aux privilèges et aux rôles des administrateurs afin de permettre un accès extraordinaire en cas d'urgence ?

Notre équipe de support mondiale gère un compte sur l'ensemble des systèmes et applications hébergés à des fins de maintenance et de support. L'équipe de support accède uniquement aux applications et aux données hébergées à des fins de surveillance de l'intégrité des applications et de maintenance du système ou des applications, et sur demande des clients via notre système de support.

6.04.01. (g)

Existe-t-il un rôle d'administrateur pour le client ? Par exemple, l'administrateur côté client a-t-il un rôle à jouer dans l'ajout de nouveaux utilisateurs (sans qu'il ne lui soit possible de modifier le stockage sous-jacent) ?

Atlassian attribue aux clients le rôle d'« administrateur de l'organisation », qui est chargé de gérer les utilisateurs et les groupes pour les produits du client. Pour plus d'informations, rendez-vous sur https://support.atlassian.com/user-management/docs/give-users-admin-permissions/.

6.04.02. (a)

Quels contrôles sont en place pour vérifier l'identité des comptes utilisateur lors de l'inscription ? Certaines normes sont-elles respectées ? Par exemple, l'e-Government Interoperability Framework (eGIF) ?

• Existe-t-il différents niveaux de contrôles d'identité en fonction des ressources requises ?

Quel que soit le pays, une vérification des antécédents est réalisée pour chaque nouveau collaborateur qui rejoint les équipes Atlassian. Les employés embauchés à la suite d'une acquisition sont soumis à une vérification de leurs antécédents après la date d'acquisition. Les nouvelles recrues et les sous-traitants indépendants font l'objet d'un contrôle du casier judiciaire. Une vérification des diplômes, et une vérification des références professionnelles ou de la solvabilité sont ajoutées si le poste ou le niveau du poste l'exige. Nous procédons à des vérifications complètes des antécédents pour les postes de cadre supérieur et les postes liés à la comptabilité.

Atlassian a mis en place un workflow reliant nos systèmes de gestion des ressources humaines et de provisionnement des accès. Nous utilisons un contrôle d'accès basé sur des profils utilisateur prédéfinis. Tous les comptes utilisateur doivent être approuvés par la direction avant d'avoir accès aux données, aux applications, à l'infrastructure ou aux composants réseau.

6.04.02. (b)

Quels sont les processus mis en place pour le déprovisionnement des identifiants ?

Notre processus de déprovisionnement inclut actuellement la résiliation d'un contrat de travail, d'un contrat ou d'un accord. Les utilisateurs qui évoluent en interne conservent généralement leurs droits d'accès afin de permettre un engagement et une assistance continus. Afin de permettre à l'équipe d'être très réactive, flexible et concentrée sur les besoins des clients, conformément aux valeurs de notre entreprise, nous préférons la détection de toute utilisation non autorisée d'un accès à la restriction des accès, qui pourrait avoir un impact sur notre réactivité.

6.04.02. (c)

Les identifiants sont-ils provisionnés et déprovisionnés simultanément dans le système cloud, et leur déprovisionnement sur plusieurs sites géographiques présente-t-il des risques ?

Atlassian a mis en place un workflow reliant nos systèmes de gestion des ressources humaines et de provisionnement des accès. Nous utilisons un contrôle d'accès basé sur des profils utilisateur prédéfinis. Tous les comptes utilisateur doivent être approuvés par la direction avant d'avoir accès aux données, aux applications, à l'infrastructure ou aux composants réseau.

Notre application RH est synchronisée avec notre boutique d'identités interne toutes les 8 heures, supprimant ainsi tous les comptes des employés ou sous-traitants qui ne sont plus employés.

6.04.03. (a)

Quels contrôles de stockage et de protection des données s'appliquent à l'annuaire des utilisateurs (par exemple, AD, LDAP) et à son accès ?

Les données sont classées et traitées conformément à notre politique de cycle de vie des informations et de sécurité des données, et des contrôles sont implémentés sur cette base. Pour plus d'informations, consultez la page : https://www.atlassian.com/trust/security/security-practices#tenant-isolation.

Tous les systèmes et projets font l'objet d'une évaluation d'impact des PII. Les accords d'Atlassian avec des tiers comprennent des dispositions relatives à la sécurité et à la confidentialité, le cas échéant. Les nouveaux fournisseurs d'Atlassian sont tenus d'accepter les politiques de confidentialité et de sécurité de nos contrats.

Atlassian a obtenu une certification ISO pour de nombreux produits. Des évaluations des risques et une révision des pratiques en matière de données doivent donc être effectuées régulièrement.

Notre évaluation de l'impact du transfert de données est disponible sur la page : https://www.atlassian.com/legal/data-transfer-impact-assessment.

Atlassian applique une norme de conservation et de destruction des données, qui indique la durée pendant laquelle nous devons conserver des données de différents types. Les données sont classées conformément à la politique relative à la sécurité des données et à la gestion du cycle de vie de l'information Atlassian, et des contrôles sont implémentés sur cette base.

Pour les données client, à la fin d'un contrat Atlassian, les données appartenant à une équipe client seront supprimées de la base de données de production en direct, et toutes les pièces jointes importées directement sur Atlassian seront supprimées dans les 14 jours. Les données de l'équipe seront conservées dans des sauvegardes chiffrées jusqu'à ce que ces sauvegardes soient supprimées après la période de conservation des données de 90 jours et soient détruites conformément à la politique de conservation des données Atlassian. Si une restauration de la base de données est nécessaire dans les 90 jours suivant la demande de suppression des données, l'équipe des opérations supprimera à nouveau les données dès que possible après la restauration complète du système de production en direct. Pour en savoir plus, consultez la page : https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

6.04.03. (b)

Les données de l'annuaire des utilisateurs sont-elles exportables dans un format interopérable ?

Les administrateurs peuvent exporter l'annuaire des utilisateurs depuis le panneau d'administration. Des guides sont disponibles sur le site de support d'Atlassian sur la page https://support.atlassian.com/organization-administration/docs/export-users-from-a-site/.

6.04.03. (c)

L'accès aux données client est-il limité au personnel du fournisseur cloud ayant besoin d'y accéder ?

Atlassian impose des restrictions au personnel qui a besoin de cet accès dans le cadre de son travail, de son rôle et de ses responsabilités. Tous les systèmes de niveau 1 sont gérés via une solution d'authentification unique (SSO) et d'annuaire centralisée Atlassian. Les utilisateurs disposent de droits d'accès appropriés en fonction de ces profils, conformément au workflow de notre système de gestion des ressources humaines. Atlassian utilise l'authentification multifacteur pour accéder à tous les systèmes de niveau 1. Nous avons activé l'authentification à deux facteurs pour la console de gestion de l'hyperviseur et l'API AWS, ainsi qu'un rapport d'audit quotidien sur tous les accès aux fonctions de gestion de l'hyperviseur. Les listes d'accès à la console de gestion de l'hyperviseur et à l'API AWS sont revues tous les trimestres. Nous assurons également une synchronisation de 8 heures entre notre système RH et notre magasin d'identités.

Des contrôles de séparation des tâches sont en place pour nos principaux produits et incluent notamment les éléments suivants :

• Révision des contrôles d'accès
• Groupes de sécurité gérés par les applications RH
• Approbation des changements/revue par des pairs/implémentation (PRGB)
• Contrôles de workflow

6.04.04.

Concernant les clés qui se trouvent sous le contrôle du fournisseur de cloud :

6.04.04. (a)

Des contrôles de sécurité sont-ils en place concernant la lecture et l'écriture de ces clés ? Par exemple, des politiques de mots de passe strictes, des clés stockées dans un système distinct, des modules de sécurité matériels (HSM) pour les clés des certificats racines, une authentification par carte à puce, un accès direct et protégé au stockage, une durée de validité courte pour les clés, etc.

Atlassian applique des politiques de chiffrement et de cryptographie, ainsi que des règles d'implémentation. Ces politiques sont revues et mises à jour chaque année, conformément à notre Policy Management Program (PMP). Pour plus d'informations, consultez la page https://www.atlassian.com/fr/trust/security/security-management-program.

Atlassian tient à jour des procédures documentées de gestion des clés pour notre infrastructure cloud. Les clés de chiffrement relatives aux pièces jointes Amazon, stockées dans le stockage à long terme S3, sont gérées par Amazon KMS. Le processus de chiffrement, de gestion des clés et de déchiffrement est inspecté et vérifié en interne sur une base régulière par Amazon dans le cadre de son processus d'audit. 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. Le service AWS KMS est conforme aux normes SOC 1, SOC 2 et SOC 3. Pour plus d'informations, consultez la page : https://aws.amazon.com/kms/.

6.04.04. (b)

Des contrôles de sécurité sont-ils en place pour utiliser ces clés pour signer et chiffrer des données ?

Atlassian tient à jour des procédures documentées de gestion des clés pour notre infrastructure cloud. Les clés de chiffrement relatives aux pièces jointes Amazon, stockées dans le stockage à long terme S3, sont gérées par Amazon KMS. Le processus de chiffrement, de gestion des clés et de déchiffrement est inspecté et vérifié en interne sur une base régulière par Amazon dans le cadre de son processus d'audit. Une fonction de rotation automatique permet de générer de nouveaux éléments de clé chaque année pour les clés principales créées dans le KMS.

6.04.04. (c)

Des procédures sont-elles prévues en cas de compromis majeur ? Il peut s'agir de listes de révocation clés, par exemple.

Atlassian est responsable des procédures documentées de gestion des clés pour notre infrastructure cloud. Les clés de chiffrement relatives aux pièces jointes Amazon, stockées dans le stockage à long terme S3, sont gérées par Amazon KMS. Le processus de chiffrement, de gestion des clés et de déchiffrement est inspecté et vérifié en interne et à fréquence régulière par Amazon dans le cadre de son processus d'audit existant. 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. Le service AWS KMS est conforme aux normes SOC 1, SOC 2 et SOC 3. Pour de plus amples informations, consultez la section suivante : https://aws.amazon.com/kms/

6.04.04. (c)

Des procédures sont-elles prévues en cas de compromis majeur ? Il peut s'agir de listes de révocation clés, par exemple.

Atlassian est responsable des procédures documentées de gestion des clés pour notre infrastructure cloud. Les clés de chiffrement relatives aux pièces jointes Amazon, stockées dans le stockage à long terme S3, sont gérées par Amazon KMS. Le processus de chiffrement, de gestion des clés et de déchiffrement est inspecté et vérifié en interne et à fréquence régulière par Amazon dans le cadre de son processus d'audit existant. 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. Le service AWS KMS est conforme aux normes SOC 1, SOC 2 et SOC 3. Pour de plus amples informations, consultez la section suivante : https://aws.amazon.com/kms/

6.04.04. (d)

La révocation des clés permet-elle de faire face aux problèmes de simultanéité entre plusieurs sites ?

Atlassian est responsable des procédures documentées de gestion des clés pour notre infrastructure cloud. Les clés de chiffrement relatives aux pièces jointes Amazon, stockées dans le stockage à long terme S3, sont gérées par Amazon KMS. Le processus de chiffrement, de gestion des clés et de déchiffrement est inspecté et vérifié en interne et à fréquence régulière par Amazon dans le cadre de son processus d'audit existant. 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. Le service AWS KMS est conforme aux normes SOC 1, SOC 2 et SOC 3. Pour de plus amples informations, consultez la section suivante : https://aws.amazon.com/kms/

6.04.04. (e)

Les images des systèmes clients sont-elles protégées ou chiffrées ?

Atlassian applique la norme industrielle Transport Layer Security (« TLS ») version 1.2 pour créer une connexion sécurisée à l'aide du chiffrement ­Advanced Encryption Standard (« AES ») 256 bits. Les serveurs contenant les données utilisateur utiliseront l'algorithme AES, un standard dans le secteur, pour le chiffrement de disque complet. Les données des locataires sont chiffrées dans les sauvegardes AWS RDS ou RDS, et sont également chiffrées dans le stockage à long terme (S3) ainsi que dans toutes les pièces jointes. Pour de plus amples informations, consultez la page suivante : https://www.atlassian.com/fr/trust/security/security-practices#our-approach

Toutes les données client stockées dans les produits et services Atlassian Cloud 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 Desk Cloud, Jira Core Cloud, 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.

Pour le chiffrement au repos, nous chiffrons spécifiquement les données client stockées sur un disque comme les données des tickets Jira (détails, commentaires, pièces jointes) ou les données de page Confluence (contenu des pages, commentaires, pièces jointes). Le chiffrement des données au repos aide à prévenir tout accès non autorisé et garantit que les données ne sont accessibles que par des rôles et des services autorisés avec accès contrôlé aux clés de chiffrement.

6.04.05. (a)

Le chiffrement peut être utilisé à différents endroits : où est-il utilisé dans votre cas ?

• Sur des données en transit ?
• Sur des données stockées ?
• Sur des données du processeur ou de la mémoire ?

Atlassian applique des politiques de chiffrement et de cryptographie, ainsi que des règles de mise en œuvre. Ces politiques sont revues et mises à jour chaque année conformément à notre Policy Management Program. Pour en savoir plus, consultez la page suivante : https://www.atlassian.com/trust/security/security-management-program .

Atlassian est responsable des procédures documentées de gestion des clés pour notre infrastructure cloud. Les clés de chiffrement relatives aux pièces jointes Amazon, stockées dans le stockage à long terme S3, sont gérées par Amazon KMS. Le processus de chiffrement, de gestion des clés et de déchiffrement est inspecté et vérifié en interne et à fréquence régulière par Amazon dans le cadre de son processus d'audit existant. 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.

Toutes les données client stockées dans les produits et services Atlassian Cloud 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 Desk Cloud, Jira Core Cloud, 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.

Pour le chiffrement au repos, nous chiffrons spécifiquement les données client stockées sur un disque comme les données des tickets Jira (détails, commentaires, pièces jointes) ou les données de page Confluence (contenu des pages, commentaires, pièces jointes). Le chiffrement des données au repos aide à prévenir tout accès non autorisé et garantit que les données ne sont accessibles que par des rôles et des services autorisés avec accès contrôlé aux clés de chiffrement.

6.04.05. (b)

Existe-t-il une politique bien définie concernant les éléments devant ou non être chiffrés ?

Atlassian applique des politiques de chiffrement et de cryptographie, ainsi que des règles de mise en œuvre. Ces politiques sont revues et mises à jour chaque année conformément à notre Policy Management Program. Pour en savoir plus, consultez la page suivante : https://www.atlassian.com/fr/trust/security/security-management-program

Atlassian est responsable des procédures documentées de gestion des clés pour notre infrastructure cloud. Les clés de chiffrement relatives aux pièces jointes Amazon, stockées dans le stockage à long terme S3, sont gérées par Amazon KMS. Le processus de chiffrement, de gestion des clés et de déchiffrement est inspecté et vérifié en interne et à fréquence régulière par Amazon dans le cadre de son processus d'audit existant. 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.

6.04.05. (d)

Qui détient les clés d'accès ?

Atlassian utilise le service AWS Key Management Service (KMS) pour la gestion des 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 affecté à chaque clé et est responsable de s'assurer qu'un niveau de contrôle de sécurité approprié est appliqué aux clés.

6.04.05. (e)

Comment les clés sont-elles protégées ?

Atlassian utilise le service AWS Key Management Service (KMS) pour la gestion des 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 affecté à chaque clé et est responsable de s'assurer qu'un niveau de contrôle de sécurité approprié est appliqué aux clés.

6.04.06. (a)

Quelles formes d'authentification sont-elles utilisées pour les opérations nécessitant un niveau d'assurance élevé ? Il peut s'agir d'identifiants pour la connexion aux interfaces de gestion, la création de clés, l'accès à plusieurs comptes utilisateurs, la configuration du pare-feu, l'accès à distance, etc.

• L'authentification à deux facteurs est-elle utilisée pour gérer les composants critiques de l'infrastructure (pare-feux, etc.) ?

Nous appliquons les recommandations détaillées dans la publication spéciale 800-63B du NIST. Voir : https://pages.nist.gov/800-63-3/sp800-63b.html

Le processus d'attribution des mots de passe est détaillé dans la politique de mot de passe d'Atlassian. Les nouveaux mots de passe ne seront pas communiqués par voie électronique, sauf lorsqu'un mot de passe à usage unique est envoyé en tant que première étape de réinitialisation. Dans ce cas, l'utilisateur sera obligé de modifier le mot de passe à usage unique lors de la première utilisation.

D'une manière plus générale, les contrôles liés à l'accès sont couverts par la politique de gestion des accès, dont un extrait est disponible ici : https://www.atlassian.com/fr/trust/security/ismp-policies#policy-risk-governance

Atlassian impose des restrictions au personnel qui a besoin d'accéder à nos systèmes, à nos applications et à notre infrastructure dans le cadre de son rôle et de ses responsabilités selon le principe du moindre privilège, et ce, par le biais de nos processus d'authentification. Tous les accès se font par le biais de sessions authentifiées et sur la base d'autorisations établies.

Atlassian impose des restrictions au personnel qui a besoin de cet accès dans le cadre de son travail, de son rôle et de ses responsabilités. Tous les systèmes de niveau 1 sont gérés via une solution d'authentification unique (SSO) et d'annuaire centralisée Atlassian. Les utilisateurs disposent de droits d'accès appropriés en fonction de ces profils, conformément au workflow de notre système de gestion des ressources humaines. Atlassian utilise l'authentification multifacteur pour accéder à tous les systèmes de niveau 1. Nous avons activé l'authentification à deux facteurs pour la console de gestion de l'hyperviseur et l'API AWS, ainsi qu'un rapport d'audit quotidien sur tous les accès aux fonctions de gestion de l'hyperviseur. Les listes d'accès à la console de gestion de l'hyperviseur et à l'API AWS sont revues tous les trimestres. Nous assurons également une synchronisation de 8 heures entre notre système RH et notre magasin d'identités.

6.04.07. (a)

Proposez-vous un système de détection des anomalies (capacité à détecter des situations inhabituelles et potentiellement malveillantes au niveau du trafic IP ainsi que des comportements des utilisateurs ou de l'équipe d'assistance) ? Cela peut se faire par une analyse des connexions échouées et réussies, des connexions effectuées à des heures inhabituelles, des connexions multiples, etc.

Notre plateforme Atlassian Cloud est très peu exposée par le biais des pare-feux. Nous revoyons régulièrement les règles de pare-feu. Nous avons déployé un système de détection des intrusions (IDS) sur nos sites de bureau et dans notre environnement d'hébergement dans le cloud. Pour la plateforme Atlassian Cloud, le transfert des journaux est intégré à une plateforme d'analyse de sécurité. Au niveau du conteneur de la plateforme Cloud, l'intégrité des fichiers est préservée, car les instances ne peuvent pas être modifiées. Atlassian Network Engineering utilise des technologies IPS intégrées à nos pare-feux, et nous avons implémenté des technologies IDS dans nos environnements de bureau et cloud. Les fonctionnalités DDoS sont fournies par notre fournisseur de service Internet/opérateur.

Les journaux système clés sont transférés à partir de chaque système vers une plateforme de journaux centralisée où ils sont disponibles en lecture seule. L'équipe Atlassian chargée de la sécurité crée des alertes sur notre plateforme d'analyse de sécurité (Splunk) et surveille les indicateurs de compromission. Nos équipes SRE utilisent cette plateforme pour surveiller les problèmes de disponibilité ou de performance. Les journaux sont conservés pendant 30 jours en sauvegarde à chaud et pendant 365 jours en sauvegarde à froid.

6.04.07. (b)

Quelles sont les dispositions existantes en cas de vol des identifiants d'un client (détection, révocation, preuve d'action) ?

Dans le cadre des services cloud d'Atlassian, nos clients peuvent être responsables d'une partie ou de la totalité de la gestion des accès pour les utilisateurs des services qu'ils contrôlent.

Par conséquent, Atlassian permet à ses clients de gérer les accès pour les utilisateurs du service qui sont sous le contrôle du client, par exemple en leur accordant des droits d'administrateur permettant de gérer ou de résilier les accès. Atlassian vérifie également que les identifiants des clients ne soient pas présents dans les bases de données relatives aux identifiants divulgués et oblige les utilisateurs à mettre à jour leur mot de passe.

Atlassian ne propose pas de protection contre la perte de données (DLP) directement dans le cadre des déploiements cloud. Il existe cependant sur Atlassian Marketplace des fournisseurs recommandés par Atlassian aux clients qui souhaitent bénéficier de cette fonctionnalité DLP. Pour consulter la page produit de Nightfall sur Marketplace, consultez la section suivante : https://marketplace.atlassian.com/vendors/1217783/nightfall. Nightfall comporte une fonctionnalité de recherche automatique des informations sensibles, notamment des identifiants, des secrets et des clés API.

Par ailleurs, Atlassian a lancé Beacon, qui est actuellement en version bêta et propose des fonctionnalités DLP supplémentaires. Tant que Beacon demeurera en version bêta, Atlassian recommandera d'utiliser Nightfall. Pour de plus amples informations concernant Atlassian Beacon, consultez la page suivante : https://www.atlassian.com/fr/software/beacon.

Nous disposons d'une politique et d'un plan de réponse aux incidents de sécurité documentés, dont les principes clés sont les suivants :

• Anticiper les incidents de sécurité et préparer la réponse aux incidents
• Maîtriser les incidents, les éradiquer et redevenir opérationnel
• Investir dans notre personnel, nos processus et nos technologies pour nous assurer d'être en mesure de détecter et d'analyser un incident de sécurité lorsqu'il se produit
• Faire de la protection des données personnelles et des données client la priorité absolue durant les incidents de sécurité
• Exécuter régulièrement le processus de réponse aux incidents de sécurité
• Tirer des leçons et améliorer la fonction de gestion des incidents de sécurité
• Communiquer les incidents de sécurité critiques à l'Atlassian Leadership Group

6.04.08.

Les questions suivantes concernent les systèmes de gestion des identités et des accès proposés par le fournisseur de services cloud et pouvant être utilisés et contrôlés par le client des services cloud.

6.04.08.01. (a)

Le système permet-il de mettre en place une infrastructure de gestion d'identités fédérées interopérable à la fois pour bénéficier d'une assurance élevée (systèmes avec mot de passe à usage unique, si besoin) ainsi que d'une assurance moins élevée (ex. : nom d'utilisateur et mot de passe) ?

Atlassian Access applique des normes de fédération des identités pour tous nos produits Atlassian (Confluence, Jira, Jira Align, Bitbucket, etc.). Atlassian Access peut automatiquement synchroniser vos comptes Active Directory et Atlassian avec Okta, Azure AD ou OneLogin. Pour plus d'informations, rendez-vous sur : https://www.atlassian.com/fr/trust/compliance. Configuration spéciale pour l'authentification unique aux produits (Generic SAML v2.0, Google, Okta, OneLogin, PingIdentity, ADFS) :

• Opsgenie prend en charge plusieurs fournisseurs d'authentification unique. Pour plus d'informations, rendez-vous sur : https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/
• Trello prend en charge plusieurs fournisseurs d'authentification unique. Pour plus d'informations, rendez-vous sur : https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization
• Statuspage prend en charge plusieurs fournisseurs d'authentification unique. Pour plus d'informations, rendez-vous sur : https://help.statuspage.io/knowledge_base/categories/single-sign-on-2

6.04.08.01. (b)

Le fournisseur de services cloud est-il interopérable avec des fournisseurs d'identité tiers ?

Les clients d'Atlassian peuvent utiliser le fournisseur d'identité tiers de leur choix à condition que celui-ci soit pris en charge par Atlassian. Une page du support Atlassian détaille ces fonctionnalités et explique la marche à suivre pour connecter le fournisseur d'identité de votre choix. Voir : https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.04.08.01. (c)

Est-il possible d'intégrer un système d'authentification unique ?

Atlassian prend en charge l'utilisation des identités Google, Microsoft et Apple pour l'authentification auprès de la plupart des produits. Nous prenons également en charge SAML pour les services cloud Atlassian via Atlassian Access. Voir : https://www.atlassian.com/fr/enterprise/cloud/access.

6.04.08.02. (a)

Le système d'identifiants du client permet-il de séparer les rôles et les responsabilités, ainsi que de séparer plusieurs domaines ? Ou bien existe-t-il une clé unique pour différents domaines, rôles et responsabilités ?

Atlassian est une application SaaS multilocataire. La multilocation est une fonctionnalité clé d'Atlassian Cloud qui permet à plusieurs clients de partager une instance de la couche applicative Jira ou Confluence, tout en isolant les données d'application du locataire de chaque client. Atlassian Cloud y parvient grâce au service de contexte de locataire (Tenant Context Service ou TCS). Chaque ID utilisateur est associé à un seul locataire, qui permet ensuite d'accéder aux applications Atlassian Cloud. Pour en savoir plus, consultez la page : https://www.atlassian.com/trust/security/security-practices#tenant-isolation

Les clients de nos offres cloud Enterprise et Premium ont accès à un panneau centralisé de contrôle des administrateurs. Les administrateurs de votre organisation peuvent gérer les accès et les autorisations des utilisateurs sur toutes les instances de vos produits. Consultez notre billet de blog à l'adresse suivante : https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Atlassian attribue aux clients le rôle d' « administrateur de l'organisation », qui est chargé de gérer les utilisateurs et les groupes pour les produits du client. Pour plus d'informations, rendez-vous sur : https://support.atlassian.com/user-management/docs/give-users-admin-permissions/

6.04.08.02. (b)

Comment gérez-vous les accès aux images du système du client ? Veillez-vous à ce qu'elles ne contiennent aucune clé d'authentification et de chiffrement ?

Notre équipe de support mondiale gère un compte sur l'ensemble des systèmes et applications hébergés à des fins de maintenance et de support. L'équipe de support accède uniquement aux applications et aux données hébergées à des fins de surveillance de l'intégrité des applications et de maintenance du système ou des applications, et sur demande des clients via notre système de support.

6.04.08.03. (a)

Comment le fournisseur de services cloud s'identifie-t-il auprès du client ? En d'autres termes, une authentification mutuelle existe-t-elle ?

• Quand le client envoie des commandes API ?
• Quand le client se connecte à l'interface de gestion ?

Atlassian utilise l'authentification mutuelle pour s'identifier auprès du client. La documentation d'Atlassian concernant l'API est disponible à l'adresse suivante : https://developer.atlassian.com/cloud/. Le protocole Atlassian Service Authentication Protocol (ASAP) est un protocole d'authentification de service à service ; il utilise un jeton d'accès implémenté à l'aide d'un jeton Web JSON (JWT) et signé à l'aide d'une clé RSA délivrée par une autorité de confiance Atlassian. Pour en savoir plus, consultez le protocole Atlassian Service Authentication Protocol. Nous n'utilisons pas les notions classiques de « comptes de service » mais nous appuyons sur l'authentification et l'autorisation de service à service.

6.04.08.03. (b)

Prenez-vous en charge un mécanisme fédéré pour l'authentification ?

Atlassian Access applique des normes de fédération des identités pour tous nos produits Atlassian (Confluence, Jira, Jira Align, Bitbucket, etc.). Atlassian Access peut automatiquement synchroniser vos comptes Active Directory et Atlassian avec Okta, Azure AD ou OneLogin. Pour plus d'informations, rendez-vous sur : https://www.atlassian.com/fr/trust/compliance. Configuration spéciale pour l'authentification unique aux produits (Generic SAML v2.0, Google, Okta, OneLogin, PingIdentity, ADFS) :

• Opsgenie prend en charge plusieurs fournisseurs d'authentification unique. Pour plus d'informations, rendez-vous sur : https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/
• Trello prend en charge plusieurs fournisseurs d'authentification unique. Pour plus d'informations, rendez-vous sur : https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization
• Statuspage prend en charge plusieurs fournisseurs d'authentification unique. Pour plus d'informations, rendez-vous sur : https://help.statuspage.io/knowledge_base/categories/single-sign-on-2

6.05.

Il est important de s'assurer que le fournisseur tient à jour une liste des actifs matériels et logiciels (applications) sous le contrôle du fournisseur de cloud. Cela permet de garantir que tous les systèmes sont soumis à des contrôles adéquats et qu'ils ne peuvent pas être utilisés comme porte dérobée pour pénétrer dans l'infrastructure.

6.05. (a)

Le fournisseur dispose-t-il d'un moyen automatisé d'inventorier tous les actifs, afin de faciliter leur gestion adéquate ?

Nos systèmes de production sont hébergés dans l'infrastructure qui est mise à notre disposition par les fournisseurs de services cloud. Ces systèmes ne sont pas suivis au niveau matériel en raison de la nature du service. Les microservices sous-jacents sur lesquels s'exécutent nos produits sont suivis dans une base de données de « services » personnalisée. Cette base de données est mise à jour automatiquement lorsqu'un service est déployé.

Notre équipe chargée des technologies dans l'espace de travail tient à jour un inventaire des actifs de tous les terminaux à l'aide de notre propre logiciel Jira à des fins de suivi.

6.05. (b)

Existe-t-il une liste des actifs que le client a utilisés au cours d'une période donnée ?

Atlassian est une application SaaS multi-locataires. La multi-location est une caractéristique clé d'Atlassian Cloud qui permet à plusieurs clients de partager une instance de la couche d'application Jira ou Confluence, tout en isolant les données de l'application de chaque client locataire. Atlassian Cloud y parvient grâce au service de contexte de locataire (Tenant Context Service, TCS). Chaque identifiant d'utilisateur est associé à un seul locataire, qui permet ensuite d'accéder aux applications d'Atlassian Cloud. Pour en savoir plus, consultez la page : https://www.atlassian.com/trust/security/security-practices#tenant-isolation

Les questions suivantes doivent être posées lorsque le client final déploie des données nécessitant une protection supplémentaire (c'est-à-dire des données jugées sensibles).

6.05. (c)

Les actifs sont-ils classés en fonction de leur sensibilité et de leur degré d'importance ?

• Si tel est le cas, le fournisseur applique-t-il une séparation appropriée entre les systèmes ayant des classifications différentes et pour un client unique qui a des systèmes ayant des classifications de sécurité différentes ?

Atlassian maintient une classification à 4 niveaux pour nos actifs et nos services, avec des exigences de temps de disponibilité, de niveau de service et de continuité définies pour chaque niveau. Pour plus d'informations, reportez-vous à la page : https://www.atlassian.com/trust/security/data-management.

6.06.

Cette série de questions doit être prise en compte afin de comprendre les risques liés à la dépendance vis-à-vis d'un fournisseur.

6.06. (a)

Existe-t-il des procédures et des API documentées pour exporter des données depuis le cloud ?

Les données des clients sont disponibles via l'application Web et l'API. Vous trouverez ci-dessous des informations détaillées sur des produits spécifiques.

• Confluence, Jira et Jira Align : des informations sur notre API Atlassian sont disponibles sur : https://developer.atlassian.com/cloud/jira/platform/rest/v3/
• Trello : les données du tableau peuvent être exportées par les membres du tableau au format JSON via l'API REST de Trello. Les pièces jointes peuvent être récupérées individuellement directement depuis Amazon S3 via l'hyperlien unique du fichier. Les versions Trello Business Class et Enterprise offrent un processus d'exportation de données simplifié pour toutes les données de l'organisation et les pièces jointes. Chaque organisation Business Class et Enterprise comprend l'exportation en un clic de tous les tableaux de l'organisation. En option, les pièces jointes téléchargées directement sur Trello peuvent être incluses dans le fichier d'exportation. Lors de l'exportation, les données de chaque tableau sont incluses à la fois au format JSON et au format « CSV » (valeurs séparées par des virgules).
• Opsgenie : l'API est disponible à l'adresse suivante : https://docs.opsgenie.com/docs/api-overview
• Statuspage : l'API est disponible à l'adresse suivante : https://doers.statuspage.io/api/v1/
• Bitbucket : n'importe quel code source ou dépôt peut être téléchargé ou exporté depuis Bitbucket à des fins d'interopérabilité. Voir : https://confluence.atlassian.com/bitbucket/does-bitbucket-backup-my-repositories-288658413.html
• Halp : dispose d'une fonction d'exportation au format CSV. Pour plus d'informations, consultez la page : https://plz.halp.com/article/5790zlyrun-export-to-csv

6.06. (b)

Le fournisseur propose-t-il des formats d'exportation interopérables pour toutes les données stockées dans le cloud ?

Atlassian répond aux demandes des clients concernant l'exportation de leurs données, si elles sont hébergées sur des produits Atlassian. De solides outils de portabilité et de gestion des données sont disponibles pour exporter les données des produits et des utilisateurs. Pour plus d'informations sur l'exportation de données Atlassian Cloud, consultez notre documentation sur l'importation et l'exportation ici : https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Pour plus de détails sur l'exportation de données dans des formats courants tels que CSV, HTML et XML, consultez la page : https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/.

6.06. (c)

Dans le cas du SaaS, les interfaces API utilisées sont-elles standardisées ?

Pour plus d'informations sur nos API Atlassian Cloud, rendez-vous sur : https://developer.atlassian.com/explore-the-apis/

Informations spécifiques sur l'API du produit :

• Trello : la documentation de l'API est disponible à l'adresse suivante : https://developer.atlassian.com/cloud/trello
• Jira Align : l'API est disponible à l'adresse suivante : https://help.jiraalign.com/hc/en-us/articles/360045371954-Getting-started-with-the-REST-API-2-0
• Statuspage : l'API est disponible à l'adresse suivante : https://doers.statuspage.io/api/v1
• Opsgenie : l'API est disponible à l'adresse suivante : https://docs.opsgenie.com/docs/api-overview
• Halp : ne possède pas d'API publique pour le moment.

6.06. (d)

Existe-t-il des dispositions concernant l'exportation des applications créées par les utilisateurs dans un format standard ?

Cela ne s'applique pas, car Atlassian utilise un modèle Software as a Service (SaaS).

6.06. (e)

Existe-t-il des processus permettant de vérifier que les données peuvent être exportées vers un autre fournisseur de cloud ? Le client souhaite-t-il changer de fournisseur, par exemple ?

Atlassian répond aux demandes des clients concernant l'exportation de leurs données, si elles sont hébergées sur des produits Atlassian. De solides outils de portabilité et de gestion des données sont disponibles pour exporter les données des produits et des utilisateurs. Pour plus d'informations sur l'exportation de données Atlassian Cloud, consultez notre documentation sur l'importation et l'exportation ici : https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Pour plus de détails sur l'exportation de données dans des formats courants tels que CSV, HTML et XML, consultez la page : https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/.

6.06. (f)

Le client peut-il extraire ses propres données pour vérifier que le format est universel et qu'il peut être migré vers un autre fournisseur de cloud ?

Atlassian répond aux demandes des clients concernant l'exportation de leurs données, si elles sont hébergées sur des produits Atlassian. De solides outils de portabilité et de gestion des données sont disponibles pour exporter les données des produits et des utilisateurs. Pour plus d'informations sur l'exportation de données Atlassian Cloud, consultez notre documentation sur l'importation et l'exportation ici : https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Pour plus de détails sur l'exportation de données dans des formats courants tels que CSV, HTML et XML, consultez la page : https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/.

6.07.

Il est important pour une organisation d'assurer la continuité. Bien qu'il soit possible de définir des accords de niveau de service détaillant la durée minimale de disponibilité des systèmes, il reste un certain nombre de considérations supplémentaires à prendre en compte.

6.07. (a)

Le fournisseur dispose-t-il d'une méthode documentée qui détaille l'impact d'une interruption de service ?

• Quels sont les RPO (objectif de point de récupération) et RTO (objectif de temps de récupération) pour les services ? Précisez en fonction de l'importance du service.
• Les activités relatives à la sécurité des informations sont-elles abordées de manière appropriée dans le cadre du processus de restauration ?
• Quelles sont les lignes de communication avec les clients finaux en cas d'interruption ?
• Les rôles et les responsabilités des équipes sont-ils clairement identifiés en cas d'interruption ?

Une politique et un plan de continuité des activités et de reprise après sinistre sont en place et sont examinés chaque année par le comité directeur qui en est chargé. Pour plus d'informations (notamment en ce qui concerne les RPO, les RTO et la résilience via l'utilisation de zones de disponibilité), consultez les pages : https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management et https://www.atlassian.com/trust/security/data-management.

Les data centers de nos partenaires disposent de nombreuses certifications de conformité. Ces certifications portent sur la sécurité physique, 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. Les informations relatives à l'assurance de protection physique d'AWS se trouvent à l'adresse suivante : https://aws.amazon.com/fr/compliance/

6.07. (b)

Le fournisseur a-t-il défini la priorité en matière de reprise et quelle serait notre priorité relative (le client final) en matière de restauration ? Remarque : il peut s'agir d'une catégorie (HIGH/MED/LOW).

Tous les propriétaires de systèmes, de processus ou de services essentiels à la mission assurent la continuité des activités et/ou la reprise d'activité après sinistre en fonction de la tolérance aux perturbations en cas de sinistre. Les plans de continuité des activités et de reprise après sinistre sont testés tous les trimestres et tout problème identifié est résolu. Pour plus d'informations, consultez les pages : https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management et https://www.atlassian.com/trust/security/data-management.

6.07. (c)

Quelles sont les dépendances liées au processus de restauration ? Incluez les fournisseurs et les partenaires d'externalisation.

Atlassian dispose d'une procédure et d'un journal des efforts de restauration des données. À un niveau élevé, cette procédure figure dans notre politique interne relative aux sauvegardes et à la continuité des activités et à la reprise des activités en cas de sinistre. Cependant, pour chaque service Atlassian, nous disposons de divers documents internes, notamment des annuaires, des calendriers et des procédures pour les restaurations initiées par le client et celles initiées par Atlassian.

6.07. (d)

En cas d'indisponibilité du site principal, quelle est la séparation minimale pour l'emplacement du site secondaire ?

Les data centers de nos partenaires disposent de nombreuses certifications de conformité. Ces certifications portent sur la sécurité physique, 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. Les informations relatives à l'assurance de protection physique d'AWS se trouvent à l'adresse suivante : https://aws.amazon.com/fr/compliance/

6.07.01.

La gestion et la réponse aux incidents font partie de la gestion de la continuité des activités. L'objectif de ce processus est de limiter l'impact des événements inattendus et potentiellement perturbateurs à un niveau acceptable pour une organisation. Pour évaluer la capacité d'une organisation à minimiser la probabilité qu'un incident de sécurité informatique se produise ou à réduire l'impact négatif d'un incident de sécurité informatique, les questions suivantes doivent être posées à un fournisseur de cloud :

6.07.01. (a)

Le fournisseur a-t-il mis en place un processus officiel de détection, d'identification, d'analyse et de réponse aux incidents ?

Nous disposons d'une politique et d'un plan de réponse aux incidents de sécurité documentés, dont les principes clés sont les suivants :

• Anticiper les incidents de sécurité et préparer la réponse aux incidents
• Maîtriser les incidents, les éradiquer et redevenir opérationnel
• Investir dans notre personnel, nos processus et nos technologies pour nous assurer d'être en mesure de détecter et d'analyser un incident de sécurité lorsqu'il se produit
• Faire de la protection des données personnelles et des données client la priorité absolue durant les incidents de sécurité
• Exécuter régulièrement le processus de réponse aux incidents de sécurité
• Tirer des leçons et améliorer la fonction de gestion des incidents de sécurité
• Communiquer les incidents de sécurité critiques à l'Atlassian Leadership Group


Dans le cadre de cette politique, Atlassian met en place un plan de réponse aux incidents de sécurité. Pour plus d'informations sur notre processus de réponse aux incidents de sécurité, rendez-vous sur : https://www.atlassian.com/trust/security/security-incident-management

Les journaux système clés sont transférés à partir de chaque système vers une plateforme de journaux centralisée où ils sont disponibles en lecture seule. L'équipe Atlassian chargée de la sécurité crée des alertes sur notre plateforme d'analyse de sécurité (Splunk) et surveille les indicateurs de compromission. Nos équipes SRE utilisent cette plateforme pour surveiller les problèmes de disponibilité ou de performance. Les journaux sont conservés pendant 30 jours en sauvegarde à chaud et pendant 365 jours en sauvegarde à froid.

Pour en savoir plus sur notre programme de détections, consultez la page : https://www.atlassian.com/fr/trust/security/detections-program

6.07.01. (b)

Ce processus est-il répété pour vérifier l'efficacité des processus de gestion des incidents ? Le fournisseur veille-t-il également, pendant les répétitions, à ce que tous les membres de l'organisation d'assistance du fournisseur de cloud soient au courant du processus et de leurs rôles dans la gestion des incidents (à la fois pendant l'incident et après l'analyse) ?

Concernant nos services Atlassian Cloud, les plans de continuité des activités et de reprise après sinistre sont testés au moins une fois par trimestre. La disponibilité de plusieurs régions est surveillée en temps réel. Des tests automatisés de basculement de région sont effectués chaque semaine sur l'environnement de pré-production. Des tests automatisés de restauration des données de configuration sont effectués quotidiennement sur l'environnement de production. Tous les services Atlassian effectuent des tests de résilience de la zone de disponibilité sur l'environnement de pré-production tous les trimestres. Pour plus d'informations sur notre programme de continuité des activités, consultez la page : https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

Nos plans de reprise d'activité sont testés et validés par nos auditeurs externes dans le cadre de notre programme de conformité. Pour plus d'informations, rendez-vous sur : https://www.atlassian.com/trust/compliance/resources

Nous avons testé notre plan de réponse aux incidents de sécurité dans le cadre d'une activité d'incident réelle. Nous appliquons une approche d'amélioration continue afin d'optimiser nos capacités de réponse.

Une fois qu'un incident de gravité 1 ou 2 a été résolu, le ticket d'incident initial est clôturé et un processus d'examen post-incident (PIR) est lancé. Pour les incidents très graves, l'équipe de sécurité effectue une analyse des causes profondes et propose des améliorations potentielles au système et/ou à la gestion du problème.

6.07.01. (c)

Comment les capacités de détection sont-elles structurées ?

• Comment le client du cloud peut-il signaler des anomalies et des événements de sécurité au fournisseur ?
• Quels moyens le fournisseur met-il à la disposition des services RTSM tiers choisis par le client pour intervenir dans leurs systèmes (le cas échéant) ou pour coordonner les capacités de réponse aux incidents avec le fournisseur de cloud ?
• Existe-t-il un service de surveillance de la sécurité en temps réel (RTSM) ? Ce service est-il externalisé ? Quels types de paramètres et de services sont surveillés ?
• Fournissez-vous (sur demande) un rapport périodique sur les incidents de sécurité (par ex., selon la définition ITIL) ?
• Pendant combien de temps les journaux de sécurité sont-ils conservés ? Ces journaux sont-ils conservés de manière sécurisée ? Qui y a accès ?
• Est-il possible pour le client de créer un système HIPS/HIDS à partir de l'image de la machine virtuelle ? Est-il possible d'intégrer les informations collectées par les systèmes de détection et de prévention des intrusions du client dans le service RTSM du fournisseur de cloud ou dans celui d'un tiers ?

Notre plateforme Atlassian Cloud est très peu exposée par le biais des pare-feux. Nous revoyons régulièrement les règles de pare-feu. Nous avons déployé un système de détection des intrusions (IDS) sur nos sites de bureau et dans notre environnement d'hébergement dans le cloud. Pour la plateforme Atlassian Cloud, le transfert des journaux est intégré à une plateforme d'analyse de sécurité. Au niveau du conteneur de la plateforme Cloud, l'intégrité des fichiers est préservée, car les instances ne peuvent pas être modifiées. Atlassian Network Engineering utilise des technologies IPS intégrées à nos pare-feux, et nous avons implémenté des technologies IDS dans nos environnements de bureau et cloud. Les fonctionnalités DDoS sont fournies par notre fournisseur de service Internet/opérateur. Pour en savoir plus sur notre programme de détections, consultez la page : https://www.atlassian.com/fr/trust/security/detections-program Les journaux système clés sont transférés à partir de chaque système vers une plateforme de journaux centralisée où ils sont disponibles en lecture seule. L'équipe Atlassian chargée de la sécurité crée des alertes sur notre plateforme d'analyse de sécurité (Splunk) et surveille les indicateurs de compromission. Nos équipes SRE utilisent cette plateforme pour surveiller les problèmes de disponibilité ou de performance. Les journaux sont conservés pendant 30 jours en sauvegarde à chaud et pendant 365 jours en sauvegarde à froid. Atlassian limite la possibilité de visualiser et de lire les journaux d'audit au personnel autorisé sur notre plateforme de journalisation centralisée. Atlassian tient à jour des canaux de rapport externes par lesquels nous pouvons prendre connaissance des vulnérabilités ou des incidents, y compris par le biais de notre programme Bug Bounty, notre portail de support client, ainsi que des boîtes de réception et des numéros de téléphone de sécurité définis. Atlassian encourage ses clients à signaler tout accès non autorisé ou tout comportement malveillant. Pour en savoir plus, consultez les pages https://www.atlassian.com/fr/trust/security/security-incident-management et https://www.atlassian.com/fr/trust/security/security-incident-responsibilities.

6.07.01. (d)

Comment les niveaux de gravité sont-ils définis ?

Atlassian utilise le système CVSS (Common Vulnerability Scoring System) pour évaluer les risques de sécurité et prioriser chaque vulnérabilité découverte. Les niveaux de sécurité utilisés reposent sur le score CVSS auto-calculé d'Atlassian, notamment :

• Critique
• Élevé
• Moyen
• Faible


Pour en savoir plus, consultez la page : https://www.atlassian.com/fr/trust/security/security-severity-levels.

6.07.01. (e)

Comment les procédures de remontée sont-elles définies ? Quand le client cloud est-il impliqué (le cas échéant) ?

Nous disposons d'une politique et d'un plan de réponse aux incidents de sécurité documentés, dont les principes clés sont les suivants :

• Anticiper les incidents de sécurité et préparer la réponse aux incidents
• Maîtriser les incidents, les éradiquer et redevenir opérationnel
• Investir dans notre personnel, nos processus et nos technologies pour nous assurer d'être en mesure de détecter et d'analyser un incident de sécurité lorsqu'il se produit
• Faire de la protection des données personnelles et des données client la priorité absolue durant les incidents de sécurité
• Exécuter régulièrement le processus de réponse aux incidents de sécurité
• Tirer des leçons et améliorer la fonction de gestion des incidents de sécurité
• Communiquer les incidents de sécurité critiques à l'Atlassian Leadership Group


Dans le cadre de cette politique, Atlassian met en place un plan de réponse aux incidents de sécurité. Pour en savoir plus sur notre processus de réponse aux incidents de sécurité, consultez la page : https://www.atlassian.com/fr/trust/security/security-incident-management

Atlassian comprend à quel point il est important que vous soyez informé rapidement de toute violation de données. C'est pourquoi Atlassian a mis en place une équipe et un processus interfonctionnels complets pour gérer les incidents de sécurité, comme décrit sur notre page : https://www.atlassian.com/fr/trust/security/security-incident-management.

Atlassian a une solide réputation en matière de notification rapide et proactive des incidents et de collaboration avec ses clients sur les mesures d'atténuation nécessaires.

Comme il est essentiel que les équipes de réponse aux incidents de sécurité d'Atlassian se concentrent immédiatement sur le triage et l'atténuation d'un incident au fur et à mesure qu'il se développe, nous ne pouvons pas nous accorder sur un calendrier de 72 heures. Au lieu de cela, nous informons les clients « dans un délai raisonnable », conformément à l'obligation légale découlant du RGPD pour les sous-traitants de données, qui répond aux besoins juridiques de la plupart de nos clients.

Les incidents peuvent être simples ou incroyablement complexes. Bien que nous puissions proposer ce qui est nécessaire conformément à la loi, nous ne pouvons pas nous accorder sur un calendrier « universel ».

6.07.01. (f)

Comment les incidents sont-ils documentés et les preuves collectées ?

Des tickets Jira sont créés à des fins de suivi et de remédiation, et les dates d'échéance sont assignées conformément à notre SLO en fonction de la gravité et de la source de la vulnérabilité. Nous avons un processus continu pour envoyer aux propriétaires de systèmes des tickets concernant les vulnérabilités identifiées, et notre équipe de gestion de la sécurité examine toutes les vulnérabilités signalées et veille à ce que des mesures soient prises pour y remédier.

Une fois qu'un incident de gravité 1 ou 2 a été résolu, le ticket d'incident initial est clôturé et un processus d'examen post-incident (PIR) est lancé. Pour les incidents très graves, l'équipe de sécurité effectue une analyse des causes profondes et propose des améliorations potentielles au système et/ou à la gestion du problème.

6.07.01. (g)

Outre l'authentification, la comptabilité et l'audit, quels autres contrôles sont en place pour empêcher les activités malveillantes menées par des initiés (ou en limiter l'impact) ?

Atlassian a déployé un système de détection des intrusions (IDS) sur nos sites de bureau et dans notre environnement d'hébergement dans le cloud. Le transfert de journaux s'intègre à une plateforme d'analyse de sécurité pour la plateforme Atlassian Cloud. Les journaux système clés sont transférés à partir de chaque système vers une plateforme de journaux centralisée où ils sont disponibles en lecture seule. L'équipe Atlassian chargée de la sécurité crée des alertes sur notre plateforme d'analyse de sécurité (Splunk) et surveille les indicateurs de compromission. Pour en savoir plus sur notre programme de détections, consultez la page : https://www.atlassian.com/fr/trust/security/detections-program

6.07.01. (h)

Le fournisseur collecte-t-il des métriques et des indicateurs sur les incidents (c'est-à-dire, le nombre d'incidents détectés ou signalés par mois, le nombre d'incidents causés par les sous-traitants du fournisseur de cloud et le nombre total de tels incidents, le délai moyen de réponse et de résolution, etc.) ?

• Lequel de ces éléments le fournisseur met-il à la disposition du public (NB : les données relatives aux remontées d'incidents ne peuvent pas toutes être rendues publiques, car elles peuvent compromettre la confidentialité des clients et révéler des informations critiques de sécurité) ?

Pour le moment, nous ne publions pas nos métriques internes, mais nous partageons les actions post-incident pour les incidents opérationnels de gravité 0 ou 1 sur notre page Statuspage : https://status.atlassian.com/.

6.07.01. (j)

À quelle fréquence le fournisseur teste-t-il les plans de reprise d'activité et de continuité d'activité ?

Concernant nos services Atlassian Cloud, les plans de continuité de l'activité et de reprise d'activité sont testés au moins une fois par trimestre. La disponibilité de plusieurs régions est surveillée en temps réel. Des tests automatisés de basculement de région sont effectués chaque semaine sur l'environnement de pré-production. Des tests automatisés de restauration des données de configuration sont effectués quotidiennement sur l'environnement de production. Tous les services Atlassian effectuent des tests de résilience de la zone de disponibilité sur l'environnement de pré-production tous les trimestres. Pour plus d'informations sur notre programme de continuité de l'activité, consultez la page : https://www.atlassian.com/fr/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

Nos plans de reprise d'activité sont testés et validés par nos auditeurs externes dans le cadre de notre programme de conformité. Pour en savoir plus, consultez la page : https://www.atlassian.com/fr/trust/compliance/resources

6.07.01. (k)

Le fournisseur collecte-t-il des données sur le niveau de satisfaction à l'égard des SLA ?

Nous surveillons les performances et la disponibilité de toutes les instances Cloud, mais nous ne proposons pas de SLA de disponibilité des applications officiel pour le moment. Notre équipe de support fournit un SLA sur le temps de réponse initial, et bien que nous n'ayons pas de SLA officiel de résolution du support, notre objectif interne est de résoudre tous les cas assignés dans les 48 heures. Atlassian affiche les statistiques sur l'état actuel de notre système Cloud sur la page : https://status.atlassian.com.

Si vous décidez d'utiliser nos offres Premium ou Enterprise, alors oui, nous offrons des garanties SLA.

6.07.01. (l)

Le fournisseur effectue-t-il des tests du centre d'assistance ? Par exemple :

• Tests d'usurpation d'identité (est-ce que la personne au bout du fil qui demande une réinitialisation de mot de passe est vraiment celle qu'elle prétend être ?) ou attaques dites « d'ingénierie sociale ».

Atlassian propose une formation à la sécurité de l'information dans le cadre de sa formation d'intégration (« premier jour ») pour les nouveaux employés et de manière continue, à l'ensemble du personnel.

En plus de cette formation générale sur la sécurité de l'information, nous proposons à nos développeurs des formations plus ciblées sur la programmation sécurisée, lesquelles sont renforcées par notre programme d'ingénieurs de sécurité intégrés.

Nous proposons également des formations thématiques continues sur les logiciels malveillants, le hameçonnage et d'autres problèmes de sécurité. https://www.atlassian.com/fr/trust/security/security-practices#security-awareness-training

Nous tenons des registres officiels indiquant le suivi de la formation interne du personnel. Les employés sont tenus de prendre connaissance du Code de conduite et de l'accepter chaque année. Cette politique est communiquée à tous les employés. Les exigences en matière de sensibilisation à la sécurité, de confidentialité et de respect de la vie privée sont présentées dans le cadre de leurs formations quotidiennes et sont accessibles à tous les employés dans Confluence.

6.07.01. (m)

Le fournisseur effectue-t-il des tests d'intrusion ? À quelle fréquence ? Qu'est-ce qui est réellement testé lors du test d'intrusion ? Par exemple, l'isolation de sécurité de chaque image pour s'assurer qu'il n'est pas possible de « passer » d'une image à une autre et d'accéder à l'infrastructure hôte ? Les tests devraient également vérifier s'il est possible d'accéder, via l'image virtuelle, aux systèmes de gestion et de support des fournisseurs de cloud (par ex., les systèmes de provisionnement et de contrôle d'accès des administrateurs).

Nous disposons d'une Red Team interne qui effectue des tests d'intrusion continus sur l'ensemble de notre infrastructure, de nos services cloud et de notre personnel.

Nous faisons appel à des services de conseil tiers pour effectuer des tests d'intrusion annuels sur des applications externes. Nous complétons également ces tests par des tests de sécurité continus de moindre envergure réalisés par notre équipe interne de test de sécurité. Pour obtenir les lettres d'évaluation de ces tests d'intrusion, ainsi que pour en savoir plus sur notre processus de test et notre approche en matière de tests de sécurité externes, consultez la page : https://www.atlassian.com/fr/trust/security/security-testing.

6.07.01. (n)

Le fournisseur effectue-t-il des tests de vulnérabilité ? À quelle fréquence ?

Notre équipe de sécurité Atlassian effectue des analyses de vulnérabilité réseau continues pour notre infrastructure interne et externe en s'appuyant sur un analyseur de vulnérabilité reconnu en permanence par le secteur. Pour en savoir plus sur notre programme de gestion des vulnérabilités, consultez la page : https://www.atlassian.com/fr/trust/security/vulnerability-management.

6.07.01. (o)

Quel est le processus pour corriger les vulnérabilités (correctifs, reconfiguration, passage aux dernières versions logicielles, etc.) ?

Des tickets Jira sont créés à des fins de suivi et de remédiation, et les dates d'échéance sont assignées conformément à notre SLO en fonction de la gravité et de la source de la vulnérabilité. Nous avons un processus continu pour envoyer aux propriétaires de systèmes des tickets concernant les vulnérabilités identifiées, et notre équipe de gestion de la sécurité examine toutes les vulnérabilités signalées et veille à ce que des mesures soient prises pour y remédier.

Pour en savoir plus sur notre programme de gestion des vulnérabilités, consultez la page : https://www.atlassian.com/fr/trust/security/vulnerability-management.

6.08.

En ce qui concerne la sécurité du personnel, la plupart des problèmes potentiels sont dus au fait que l'infrastructure informatique est contrôlée par un tiers. Comme pour l'externalisation traditionnelle, une faille de sécurité physique peut avoir un impact sur plusieurs clients (organisations).

6.08. (a)

Quelle assurance donnez-vous au client concernant la sécurité physique de l'emplacement ? Veuillez fournir des exemples et toutes les normes respectées (par ex., la Section 9 de la norme ISO 27001/2).

Les contrôles de sécurité physique dans nos bureaux sont axés sur notre politique de sécurité physique et environnementale, laquelle garantit l'implémentation de mécanismes de sécurité physique robustes dans nos environnements sur site et dans le cloud.

Nos data centers partenaires sont au minimum conformes à la norme SOC2. Ces certifications portent sur un éventail de contrôles de sécurité, y compris la sécurité physique et environnementale ainsi que la protection. 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.

6.08. (a) (i)

Qui, à part le personnel informatique autorisé, dispose d'un accès (physique) sans escorte à l'infrastructure informatique ?

• Par exemple, les nettoyeurs, les managers, le personnel de « sécurité physique », les sous-traitants, les consultants, les fournisseurs, et plus encore.

Les bureaux Atlassian sont régis par notre politique interne sur la sécurité physique et environnementale, y compris la surveillance des points d'entrée et de sortie physiques. Nous avons publié des extraits de chacune de nos opérations technologiques internes et de nos politiques de sécurité à l'adresse suivante : https://www.atlassian.com/fr/trust/security/ismp-policies

Les bureaux d'Atlassian sont dotés de dispositifs de contrôle d'accès, notamment des lecteurs de badges et des caméras de surveillance, par lesquels il est possible de restreindre les accès à des heures et à des jours spécifiques, en fonction des besoins. Les journaux des accès aux immeubles de l'entreprise sont gérés par le service de gestion de notre immeuble et sont mis à la disposition des équipes Workplace Experience en cas d'enquête.

Les data centers de nos partenaires disposent de nombreuses certifications de conformité. Ces certifications portent sur la sécurité physique, 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. Les informations relatives à l'assurance de protection physique d'AWS se trouvent à l'adresse suivante : https://aws.amazon.com/fr/compliance/

6.08. (a) (ii)

À quelle fréquence les droits d'accès sont-ils revus ?

• En combien de temps les droits d'accès peuvent-ils être révoqués ?

Atlassian évalue les performances et l'efficacité de son système de management de la sécurité de l'information (SMSI) à l'aide de métriques appropriées. Nous surveillons les performances du système Atlassian Trust Management System (ATMS) et les contrôles pertinents par le biais d'audits internes et externes. L'équipe de conformité d'Atlassian gère à la fois notre calendrier d'audits de préparation internes/internes et notre calendrier d'audits externes (qui est documenté en interne sur notre page de feuilles de route d'audit). Les audits internes se concentrent sur les domaines à risque élevé d'Atlassian et sont réalisés régulièrement selon des calendriers prédéterminés et conformément au calendrier d'audit d'entreprise convenu entre l'équipe des risques et de la conformité et l'équipe d'audit interne. Pour le moment, nous ne publions pas nos métriques internes. Le système ATMS est évalué sur une base annuelle par des tiers indépendants, et également en cas de changement significatif. Atlassian a obtenu les certifications SOC2, ISO27001 et ISO7018 pour chacun de nos principaux services cloud. Atlassian surveille également chacun des piliers du système ATMS par le biais de réunions d'évaluation opérationnelle périodiques, y compris des métriques spécifiques pour chacun d'entre eux. Cela inclut les examens hebdomadaires de la conformité du système ATMS et d'autres réunions qui sont documentées en interne sur notre page ATMS : examen de l'intégrité de la sécurité et sur notre page ATMS : notes de réunion. Pour en savoir plus, consultez la page : https://www.atlassian.com/fr/trust/compliance.

Nous avons un programme officiel de gestion de la sécurité et nous revoyons notre programme de gestion de la sécurité de l'information (ISMP) chaque année. Pour en savoir plus sur notre programme de gestion de la sécurité, consultez la page : https://www.atlassian.com/fr/trust/security/security-management-program.

6.08. (a) (iii)

Procédez-vous régulièrement à une évaluation des risques de sécurité ainsi qu'à une analyse des périmètres ?

• À quelle fréquence ?

Atlassian évalue les performances et l'efficacité de son système de management de la sécurité de l'information (SMSI) à l'aide de métriques appropriées. Nous surveillons les performances du système Atlassian Trust Management System (ATMS) et les contrôles pertinents par le biais d'audits internes et externes. L'équipe de conformité d'Atlassian gère à la fois notre calendrier d'audits de préparation internes/internes et notre calendrier d'audits externes (qui est documenté en interne sur notre page de feuilles de route d'audit). Les audits internes se concentrent sur les domaines à risque élevé d'Atlassian et sont réalisés régulièrement selon des calendriers prédéterminés et conformément au calendrier d'audit d'entreprise convenu entre l'équipe des risques et de la conformité et l'équipe d'audit interne. Pour le moment, nous ne publions pas nos métriques internes. Le système ATMS est évalué sur une base annuelle par des tiers indépendants, et également en cas de changement significatif. Atlassian a obtenu les certifications SOC2, ISO27001 et ISO7018 pour chacun de nos principaux services cloud. Atlassian surveille également chacun des piliers du système ATMS par le biais de réunions d'évaluation opérationnelle périodiques, y compris des métriques spécifiques pour chacun d'entre eux. Cela inclut les examens hebdomadaires de la conformité du système ATMS et d'autres réunions qui sont documentées en interne sur notre page ATMS : examen de l'intégrité de la sécurité et sur notre page ATMS : notes de réunion. Pour en savoir plus, consultez la page : https://www.atlassian.com/fr/trust/compliance.

Nous avons un programme officiel de gestion de la sécurité et nous revoyons notre programme de gestion de la sécurité de l'information (ISMP) chaque année. Pour en savoir plus sur notre programme de gestion de la sécurité, consultez la page : https://www.atlassian.com/fr/trust/security/security-management-program.

6.08. (a) (iv)

Procédez-vous régulièrement à des évaluations des risques incluant des éléments tels que les bâtiments voisins ?

Atlassian évalue les performances et l'efficacité de son système de management de la sécurité de l'information (SMSI) à l'aide de métriques appropriées. Nous surveillons les performances du système Atlassian Trust Management System (ATMS) et les contrôles pertinents par le biais d'audits internes et externes. L'équipe de conformité d'Atlassian gère à la fois notre calendrier d'audits de préparation internes/internes et notre calendrier d'audits externes (qui est documenté en interne sur notre page de feuilles de route d'audit). Les audits internes se concentrent sur les domaines à risque élevé d'Atlassian et sont réalisés régulièrement selon des calendriers prédéterminés et conformément au calendrier d'audit d'entreprise convenu entre l'équipe des risques et de la conformité et l'équipe d'audit interne. Pour le moment, nous ne publions pas nos métriques internes. Le système ATMS est évalué sur une base annuelle par des tiers indépendants, et également en cas de changement significatif. Atlassian a obtenu les certifications SOC2, ISO27001 et ISO7018 pour chacun de nos principaux services cloud. Atlassian surveille également chacun des piliers du système ATMS par le biais de réunions d'évaluation opérationnelle périodiques, y compris des métriques spécifiques pour chacun d'entre eux. Cela inclut les examens hebdomadaires de la conformité du système ATMS et d'autres réunions qui sont documentées en interne sur notre page ATMS : examen de l'intégrité de la sécurité et sur notre page ATMS : notes de réunion. Pour en savoir plus, consultez la page : https://www.atlassian.com/fr/trust/compliance.

Nous avons un programme officiel de gestion de la sécurité et nous revoyons notre programme de gestion de la sécurité de l'information (ISMP) chaque année. Pour en savoir plus sur notre programme de gestion de la sécurité, consultez la page : https://www.atlassian.com/fr/trust/security/security-management-program.

6.08. (a) (v)

Avez-vous établi des mesures de contrôle ou de surveillance du personnel ayant accès à des espaces sécurisés, notamment au niveau des tiers ?

Les bureaux Atlassian sont régis par notre politique interne sur la sécurité physique et environnementale, y compris la surveillance des points d'entrée et de sortie physiques. Nous avons publié des extraits de chacune de nos opérations technologiques internes et de nos politiques de sécurité à l'adresse suivante : https://www.atlassian.com/trust/security/ismp-policies

Les bureaux d'Atlassian sont dotés de dispositifs de contrôle d'accès, notamment des lecteurs de badges et des caméras de surveillance, par lesquels il est possible de restreindre les accès à des heures et à des jours spécifiques, en fonction des besoins. Les journaux des accès aux immeubles de l'entreprise sont gérés par le service de gestion de notre immeuble et sont mis à la disposition des équipes Workplace Experience en cas d'enquête.

Les data centers de nos partenaires disposent de nombreuses certifications de conformité. Ces certifications portent sur la sécurité physique, 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. Les informations relatives à l'assurance de protection physique d'AWS se trouvent à l'adresse suivante : https://aws.amazon.com/fr/compliance/

6.08. (a) (vi)

Quelles politiques ou procédures appliquez-vous en matière de chargement, de déchargement et d'installation du matériel ?

Dans les bureaux d'Atlassian, les zones de mise à quai sont séparées des zones de travail et surveillées en continu par des caméras de vidéosurveillance ainsi que par le personnel du bâtiment. Ce sont nos partenaires d'hébergement de data centers qui gèrent la sécurité des infrastructures, et nous nous basons sur leurs certifications de conformité afin de valider l'efficacité des contrôles.

6.08. (a) (vii)

Les livraisons sont-elles inspectées afin de détecter les risques potentiels avant l'installation de matériel ?

Dans les bureaux d'Atlassian, les zones de mise à quai sont séparées des zones de travail et surveillées en continu par des caméras de vidéosurveillance ainsi que par le personnel du bâtiment. Ce sont nos partenaires d'hébergement de data centers qui gèrent la sécurité des infrastructures, et nous nous basons sur leurs certifications de conformité afin de valider l'efficacité des contrôles.

6.08. (a) (viii)

Existe-t-il un inventaire actualisé des éléments physiques présents dans le data center ?

Un extrait de notre politique de gestion des actifs est disponible à l'adresse https://www.atlassian.com/trust/security/ismp-policies. Atlassian tient un inventaire de tous les actifs de production ainsi que de leurs propriétaires. Tous nos systèmes se situent dans des centres de données reposant sur AWS. Nos systèmes AWS ne sont pas suivis au niveau matériel en raison de la nature du service.

Chaque microservice est suivi dans le cadre d'une base de données de services personnalisée, laquelle est mise à jour à chaque nouveau déploiement d'un service. L'équipe chargée des technologies dans l'espace de travail (WPT) tient à jour un inventaire des actifs de tous les terminaux à l'aide de notre propre logiciel Jira à des fins de suivi.

Les microservices sont tous classés en différents niveaux associés à différentes attentes en matière de disponibilité, de RTO et de RPO. Si vous souhaitez obtenir des exemples, consultez la section suivante : https://www.atlassian.com/trust/security/data-management

6.08. (a) (ix)

Les câbles réseau traversent-ils des zones d'accès public ?

• Utilisez-vous des câbles ou des conduits blindés ?

Les bureaux Atlassian sont régis par notre politique interne sur la sécurité physique et environnementale, y compris la surveillance des points d'entrée et de sortie physiques. Nous avons publié des extraits de chacune de nos opérations technologiques internes et de nos politiques de sécurité à l'adresse suivante : https://www.atlassian.com/trust/security/ismp-policies

Les bureaux d'Atlassian sont dotés de dispositifs de contrôle d'accès, notamment des lecteurs de badges et des caméras de surveillance, par lesquels il est possible de restreindre les accès à des heures et à des jours spécifiques, en fonction des besoins. Les journaux des accès aux immeubles de l'entreprise sont gérés par le service de gestion de notre immeuble et sont mis à la disposition des équipes Workplace Experience en cas d'enquête.

6.08. (a) (x)

Réalisez-vous des inspections régulières de vos locaux afin de vérifier l'absence de matériel non autorisé ?

Un extrait de notre politique de gestion des actifs est disponible à l'adresse https://www.atlassian.com/trust/security/ismp-policies. Atlassian tient un inventaire de tous les actifs de production ainsi que de leurs propriétaires. Tous nos systèmes se situent dans des centres de données reposant sur AWS. Nos systèmes AWS ne sont pas suivis au niveau matériel en raison de la nature du service.

Chaque microservice est suivi dans le cadre d'une base de données de services personnalisée, laquelle est mise à jour à chaque nouveau déploiement d'un service. L'équipe chargée des technologies dans l'espace de travail (WPT) tient à jour un inventaire des actifs de tous les terminaux à l'aide de notre propre logiciel Jira à des fins de suivi.

6.08. (a) (xi)

Du matériel est-il situé en dehors de votre site ?

• Comment est-il protégé ?

Un extrait de notre politique de gestion des actifs est disponible à l'adresse https://www.atlassian.com/trust/security/ismp-policies. Atlassian tient un inventaire de tous les actifs de production ainsi que de leurs propriétaires. Tous nos systèmes se situent dans des centres de données reposant sur AWS. Nos systèmes AWS ne sont pas suivis au niveau matériel en raison de la nature du service.

Chaque microservice est suivi dans le cadre d'une base de données de services personnalisée, laquelle est mise à jour à chaque nouveau déploiement d'un service. L'équipe chargée des technologies dans l'espace de travail (WPT) tient à jour un inventaire des actifs de tous les terminaux à l'aide de notre propre logiciel Jira à des fins de suivi.

6.08. (a) (xii)

Votre personnel utilise-t-il des équipements portables (ex : ordinateurs portables, smartphones) pouvant donner accès au data center ?

• Comment sont-ils protégés ?

Les data centers de nos partenaires disposent de nombreuses certifications de conformité. Ces certifications portent sur la sécurité physique, 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. Les informations relatives à l'assurance de protection physique d'AWS se trouvent à l'adresse suivante : https://aws.amazon.com/fr/compliance/

Des membres dûment autorisés et formés des équipes d'ingénierie d'Atlassian, ayant fait l'objet d'une vérification de leurs antécédents, s'authentifient sur le VPN à l'aide de mots de passe forts uniques ainsi que d'une authentification à deux facteurs (2FA) reposant sur un mot de passe à usage unique basé sur le temps (TOTP), puis accèdent à l'environnement de production uniquement via des connexions de terminaux SSH utilisant des certificats RSA personnels protégés par mot de passe. Un système de détection d'intrusion est installé sur tous les serveurs de production. Celui-ci effectue une surveillance en temps réel et envoie des alertes en cas de modification des fichiers ou de la configuration du système de production ainsi que d'événements de sécurité anormaux. Pour les membres autorisés et formés de l'équipe opérationnelle ayant accès au système de production, tous les postes de travail s'exécutant sur Windows ou OS X utilisés pour l'accès SSH du terminal à l'environnement de production doivent être équipés d'un logiciel antivirus à jour et actif. Les données clients ne sont pas diffusées sur les postes de travail ou les appareils mobiles des employés.

6.08. (a) (xiii)

Quelles sont les mesures mises en place pour contrôler les cartes d'accès ?

Les bureaux Atlassian sont régis par notre politique interne sur la sécurité physique et environnementale, y compris la surveillance des points d'entrée et de sortie physiques. Nous avons publié des extraits de chacune de nos opérations technologiques internes et de nos politiques de sécurité à l'adresse suivante : https://www.atlassian.com/trust/security/ismp-policies

Les bureaux d'Atlassian sont dotés de dispositifs de contrôle d'accès, notamment des lecteurs de badges et des caméras de surveillance, par lesquels il est possible de restreindre les accès à des heures et à des jours spécifiques, en fonction des besoins. Les journaux des accès aux immeubles de l'entreprise sont gérés par le service de gestion de notre immeuble et sont mis à la disposition des équipes Workplace Experience en cas d'enquête.

6.08. (a) (xiv)

Quels sont les processus ou procédures mis en place afin de détruire les anciens supports ou systèmes lorsque cela est nécessaire ?

• Données remplacées ?
• Destruction physique ?

Ce processus est géré par Workplace Technology : les équipements sont nettoyés et démagnétisés de manière appropriée. Atlassian n'est pas responsable de la gestion des supports physiques utilisés avec nos produits et services cloud.

6.08. (a) (xv)

Quels sont les processus d'autorisation mis en place pour le déplacement de matériel d'un site à un autre ?

• Comment déterminez-vous les employés (ou les sous-traitants) autorisés à procéder à ces opérations ?

Les partenaires d'hébergement de data centers d'Atlassian (AWS) sont chargés de la sécurité des infrastructures, et nous nous appuyons sur leurs rapports SOC2 pour valider l'efficacité de leurs contrôles.

Les produits Atlassian Cloud ne transfèrent pas physiquement les données des clients. Les disques durs contenant des données clients sont détruits ou nettoyés avant de quitter nos data centers AWS sécurisés. Pour les systèmes hébergés sur AWS, les données peuvent être déplacées d'une région à une autre dans un scénario de redondance, mais elles ne seront jamais diffusées à l'extérieur d'AWS. Pour plus d'informations sur nos régions AWS, consultez la section suivante : https://www.atlassian.com/trust/reliability/infrastructure.

6.08. (a) (xvi)

À quelle fréquence des audits sont-ils effectués concernant le matériel en vue de vérifier s'il est nécessaire de retirer du matériel non autorisé ?

Les partenaires d'hébergement de data centers d'Atlassian (AWS) sont chargés de la sécurité des infrastructures, et nous nous appuyons sur leurs rapports SOC2 pour valider l'efficacité de leurs contrôles.

Les produits Atlassian Cloud ne transfèrent pas physiquement les données des clients. Les disques durs contenant des données clients sont détruits ou nettoyés avant de quitter nos data centers AWS sécurisés. Pour les systèmes hébergés sur AWS, les données peuvent être déplacées d'une région à une autre dans un scénario de redondance, mais elles ne seront jamais diffusées à l'extérieur d'AWS. Pour plus d'informations sur nos régions AWS, consultez la section suivante : https://www.atlassian.com/trust/reliability/infrastructure.

6.08. (a) (xvii)

À quelle fréquence effectuez-vous des contrôles afin de vous assurer que l'environnement est conforme aux exigences légales et réglementaires adéquates ?

Notre équipe juridique et nos équipes de conformité Atlassian gèrent nos obligations réglementaires. Rendez-vous sur la page https://www.atlassian.com/legal/ pour consulter notre programme juridique. Pour plus d'informations sur notre programme de conformité, rendez-vous à l'adresse suivante : https://www.atlassian.com/trust/compliance.

6.09. (a)

Quelles sont les procédures ou politiques mises en place pour garantir qu'aucun problème environnemental n'interrompra le service ?

Les bureaux Atlassian sont régis par notre politique interne sur la sécurité physique et environnementale, y compris la surveillance des points d'entrée et de sortie physiques.

Les data centers de nos partenaires disposent de nombreuses certifications de conformité. Ces certifications portent sur la sécurité physique, 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. Les informations relatives à l'assurance de protection physique d'AWS se trouvent à l'adresse suivante : https://aws.amazon.com/fr/compliance/

Une politique et un plan de continuité de l'activité et de reprise d'activité sont en place et sont examinés chaque année par le comité directeur qui en est chargé. Tous les propriétaires de systèmes, de processus ou de services essentiels à la mission assurent la continuité des activités et/ou la reprise d'activité après sinistre en fonction de la tolérance aux perturbations en cas de sinistre. Les plans de continuité des activités et de reprise après sinistre sont testés tous les trimestres et tout problème identifié est résolu. Pour plus d'informations, consultez les pages : https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management et https://www.atlassian.com/trust/security/data-management.

6.09. (b)

Quelles méthodes utilisez-vous pour prévenir les dommages potentiels qui seraient causés par un incendie, une inondation, un tremblement de terre, etc. ?

• En cas de catastrophe, quelles mesures de sécurité supplémentaires sont mises en place pour protéger l'accès physique ?
• Sur le site principal comme sur les sites secondaires ?

Atlassian s'appuie sur ses partenaires d'hébergement des données pour valider la sécurité et les contrôles environnementaux de leurs data centers. Concernant AWS, consultez la page https://aws.amazon.com/compliance/programs.

6.09. (c)

Surveillez-vous la température et l'humidité du data center ?

• Prise en compte ou surveillance de la climatisation ?

Atlassian s'appuie sur ses partenaires d'hébergement des données pour valider la sécurité et les contrôles environnementaux de leurs data centers. Concernant AWS, consultez la page https://aws.amazon.com/compliance/programs.

6.09. (d)

Vos bâtiments sont-ils protégés contre la foudre ?

• Cela inclut-il les lignes électriques et les lignes de télécommunication ?

Atlassian s'appuie sur ses partenaires d'hébergement des données pour valider la sécurité et les contrôles environnementaux de leurs data centers. Concernant AWS, consultez la page https://aws.amazon.com/compliance/programs.

6.09. (e)

Disposez-vous de groupes électrogènes autonomes en cas de panne de courant ?

• Combien de temps ceux-ci peuvent-ils fonctionner ?
• Les réserves de carburant sont-elles suffisantes ?
• Disposez-vous de générateurs de secours ?
• À quelle fréquence vérifiez-vous vos onduleurs ?
• À quelle fréquence vérifiez-vous vos groupes électrogènes ?
• Disposez-vous de plusieurs fournisseurs d'électricité ?

Atlassian s'appuie sur ses partenaires d'hébergement des données pour valider la sécurité et les contrôles environnementaux de leurs data centers. Concernant AWS, consultez la page https://aws.amazon.com/compliance/programs.

6.09. (f)

Vos installations de services publics (électricité, eau, etc.) sont-elles toutes capables de soutenir votre environnement ?

• À quelle fréquence sont-elles réévaluées et testées ?

Atlassian s'appuie sur ses partenaires d'hébergement des données pour valider la sécurité et les contrôles environnementaux de leurs data centers. Concernant AWS, consultez la page https://aws.amazon.com/compliance/programs.

6.09. (g)

Votre système de climatisation est-il adapté à votre environnement ?

• À quelle fréquence est-il testé ?

Atlassian s'appuie sur ses partenaires d'hébergement des données pour valider la sécurité et les contrôles environnementaux de leurs data centers. Concernant AWS, consultez la page https://aws.amazon.com/compliance/programs.

6.09. (h)

Appliquez-vous les calendriers de maintenance recommandés par les fabricants ?

Atlassian s'appuie sur ses partenaires d'hébergement des données pour valider la sécurité et les contrôles environnementaux de leurs data centers. Concernant AWS, consultez la page https://aws.amazon.com/compliance/programs.

6.09. (i)

Accordez-vous l'accès à vos sites uniquement à du personnel de maintenance ou de réparation dûment autorisé ?

• Comment procédez-vous pour vérifier l'identité du personnel ?

L'accès physique aux bureaux est protégé via les mesures suivantes : accès par badge électronique, accueil pendant les heures de bureau et identification obligatoire à l'entrée, et présence d'un système de vidéosurveillance à tous les points d'entrée et de sortie du bâtiment. Les zones de mise à quai sont surveillées en continu par des caméras de vidéosurveillance ainsi que par le personnel du bâtiment. Ce sont nos partenaires d'hébergement de data centers qui gèrent la sécurité des infrastructures, et nous nous basons sur leurs certifications de conformité afin de valider l'efficacité des contrôles.

6.09. (j)

Lorsque du matériel est expédié pour être réparé, les données sont-elles nettoyées au préalable ?

• Comment s'effectue ce processus ?

Ce processus est géré par Workplace Technology : les équipements sont nettoyés et démagnétisés de manière appropriée. Atlassian n'est pas responsable de la gestion des supports physiques utilisés avec nos produits et services cloud.

6.10.

Les clients actuels ainsi que les clients potentiels des fournisseurs de services cloud doivent tenir compte de leurs obligations nationales et supranationales respectives en matière de conformité avec les cadres réglementaires, et veiller à que ces obligations soient respectées de façon adéquate.

Les principales questions juridiques que le client doit poser au fournisseur de services cloud sont les suivantes :

6.10. (a)

Dans quel pays se situe le fournisseur de services cloud ?

Atlassian possède 12 bureaux dans 8 pays : Sydney, Amsterdam, Ankara, Boston, Bangalore, San Francisco, Mountain View, Austin, New York, Manille, Gdansk et le Japon. Pour plus d'informations, consultez la section suivante : https://www.atlassian.com/company/contact.

6.10. (b)

L'infrastructure du fournisseur de services cloud est-elle située dans un même pays ou dans plusieurs pays différents ?

Concernant Atlassian Cloud, nous sommes actuellement hébergés dans des zones de disponibilité AWS redondantes. Pour plus d'informations sur nos régions spécifiques, consultez la section suivante : https://www.atlassian.com/trust/reliability/infrastructure.

6.10. (c)

Le fournisseur de services cloud fera-t-il appel à d'autres sociétés dont l'infrastructure est située en dehors la sienne ?

Les produits et données cloud d'Atlassian sont hébergés par Amazon Web Services (AWS), le fournisseur cloud leader du secteur. Nos produits fonctionnent sur un environnement PaaS (Platform as a Service) divisé en deux ensembles principaux d'infrastructures que nous appelons « micros » et « non micros ». Jira, Confluence, Statuspage, Access et Bitbucket s'exécutent sur la plateforme Micros, tandis qu'Opsgenie et Trello s'exécutent sur la plateforme non micros.

6.10. (d)

Où se trouveront physiquement les données ?

Atlassian utilise Amazon Web Services (AWS) dans les régions USA Est, USA Ouest, en Irlande, à Francfort, à Singapour et à Sydney (Confluence et Jira).

Informations spécifiques sur le produit :

• Trello : disponible dans AWS pour la région USA Est (Ohio).
• Jira Align : la localisation physique des données des clients peut être demandée via un ticket de support. Voir : https://support.atlassian.com/jira-align/.
• Statuspage : disponible dans AWS pour les régions USA Ouest (Oregon, Californie) et USA-Est (Ohio).
• Opsgenie : dispose de comptes AWS aux États-Unis et en Europe. Le client doit s'abonner à AWS pour les États-Unis (Oregon, Californie) ou pour l'Europe (Francfort) lors de son inscription.
• Halp : hébergé par AWS dans les régions USA Est-2 et USA Ouest-2.
• Bitbucket : les dépôts et les principales fonctionnalités de l'application sont hébergés par AWS pour les régions USA Est et USA Ouest.


Pour en savoir plus sur la résidence des données, rendez-vous sur : https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/.

6.10. (e)

La juridiction en matière de conditions de contrat et de données sera-t-elle partagée ?

La loi qui régit par défaut le contrat client Atlassian est la loi californienne. Pour plus d'informations, veuillez contacter notre équipe commerciale Enterprise.

6.10. (f)

Certains services du fournisseur de cloud seront-ils sous-traités ?

Atlassian travaille avec des sous-traitants pour dans le cadre de la fourniture de site web, le développement d'apps, l'hébergement, la maintenance, la sauvegarde, le stockage, l'infrastructure virtuelle, le traitement des paiements, l'analyse, ainsi que d'autres services. Ces fournisseurs de services peuvent avoir accès à des informations d'identification personnelle (PII) ou en traiter dans le cadre de la prestation de ces services pour nous.

Atlassian divulgue à ses clients concernés tout recours à des sous-traitants susceptibles de traiter leurs informations personnelles, par le biais d'une notification préalable au traitement. Une liste externe des sous-traitants avec lesquels Atlassian travaille est disponible sur la page Atlassian Subprocessors à l'adresse : https://www.atlassian.com/legal/sub-processors. Sur cette page, les visiteurs sont invités à s'abonner à un flux RSS pour être avertis lorsque nous ajouterons de nouveaux sous-traitants Atlassian.

6.10. (g)

Certains services du fournisseur de cloud seront-ils externalisés ?

Lorsque nous engageons des fournisseurs tiers, nous veillons à ce que ces recrutements ne compromettent en aucune façon nos clients ou leurs données. Le service juridique et le service des achats d'Atlassian examinent les contrats, les SLA et les politiques internes des fournisseurs afin de déterminer s'ils répondent aux exigences de sécurité, de disponibilité et de confidentialité. Pour en savoir plus, rendez-vous sur la page : https://www.atlassian.com/fr/trust/security/security-practices#supplier-risk-management.

6.10. (h)

Comment les données fournies par le client et ses propres clients seront-elles collectées, traitées et transférées ?

Atlassian traite les informations conformément aux fins desquelles elles ont été collectées ou autorisées ultérieurement par l'individu, et notamment à la politique de confidentialité externe d'Atlassian.

Le respect de la vie privée des utilisateurs est au cœur des priorités d'Atlassian, tout comme la transparence sur nos processus de collecte, d'utilisation et de partage des informations des utilisateurs. Pour en savoir plus, consultez notre page « Confidentialité chez Atlassian » de l'Atlassian Trust Center sur https://www.atlassian.com/fr/trust/privacy, et notre Politique de confidentialité sur https://www.atlassian.com/fr/legal/privacy-policy.

6.10. (i)

Qu'advient-il des données envoyées au fournisseur de cloud à la fin du contrat ?

Atlassian applique une norme de conservation et de destruction des données, qui indique la durée pendant laquelle nous devons conserver des données de différents types. Les données sont classées conformément à la politique relative à la sécurité des données et à la gestion du cycle de vie de l'information Atlassian, et des contrôles sont implémentés sur cette base. Pour les données client, à la fin d'un contrat Atlassian, les données appartenant à une équipe client seront supprimées de la base de données de production en direct, et toutes les pièces jointes importées directement sur Atlassian seront supprimées dans les 14 jours. Les données de l'équipe seront conservées dans des sauvegardes chiffrées jusqu'à ce que ces sauvegardes soient supprimées après la période de conservation des données de 90 jours et soient détruites conformément à la politique de conservation des données Atlassian. Si une restauration de la base de données est nécessaire dans les 90 jours suivant la demande de suppression des données, l'équipe des opérations supprimera à nouveau les données dès que possible après la restauration complète du système de production en direct. Pour en savoir plus, consultez la page : https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/