| Principe 1 : Protection des données en transit |
| 1.1 Chiffrement | Atlassian assure le chiffrement du réseau sans fil interne, notamment en modifiant les paramètres par défaut du fournisseur. L'équipe Workplace Technology d'Atlassian protège nos réseaux sans fil en utilisant l'authentification WPA2-AES et le chiffrement PEAP-EAP-MSCHAPv2. Nous nous authentifions sur notre réseau sans fil via 802.1x en utilisant notre magasin d'identités interne. Nous recherchons régulièrement des points d'accès sans fil indésirables et nous tenons à jour une liste de ces points.
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 en savoir plus, consultez la page : https://www.atlassian.com/fr/trust/security/security-practices#encryption-of-data | Nos politiques de sécurité et de confidentialité des données
Chiffrement des données | Données de l'Atlassian Trust Center
Chiffrement | Architecture et pratiques opérationnelles d'Atlassian Cloud |
| 1.2 Protection du réseau | Le Policy Management Program (PMP) d'Atlassian inclut une politique de sécurité des communications qui définit la responsabilité de la gestion du réseau.
Pour accéder au réseau, Atlassian utilise un annuaire LDAP centralisé qui implémente un contrôle d'accès basé sur les rôles qui repose sur des profils définis. 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. Les règles d'accès au réseau de production interne sont maintenues à l'aide de groupes de sécurité explicitement désignés au sein des environnements AWS VPC.
L'équipe Workplace Technology d'Atlassian protège les réseaux sans fil en utilisant l'authentification WPA2-AES et le chiffrement PEAP-EAP-MSCHAPv2. Nous nous authentifions sur notre réseau sans fil via 802.1x en utilisant notre magasin d'identités interne.
Atlassian Network Engineering utilise des technologies IPS intégrées à nos pare-feux cloud et bureautiques, et nous avons 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. L'implémentation du protocole TLS par Atlassian impose l'utilisation de chiffrements puissants. | Notre politique de sécurité et de confidentialité des données
Intégrer la sécurité à notre infrastructure réseau | Atlassian Trust Center |
| 1.3 Authentification | 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.
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. Pour en savoir plus, consultez la page : https://www.atlassian.com/fr/software/access | Nos politiques de sécurité et de confidentialité des données
Sécurisation de l'accès à nos réseaux grâce à l'approche ZeroTrust | Service Atlassian Trust Center
Authentification et autorisation | Architecture et pratiques opérationnelles d'Atlassian Cloud |
| Principe 2 : Protection des actifs et résilience |
| 2.1 Emplacement physique et juridiction | Emplacement physique
Aujourd'hui, Atlassian gère des data centers et héberge des données en Allemagne, en Australie, aux États-Unis, en Irlande et à Singapour. Nous fournissons à tous nos clients des services sécurisés, rapides et fiables en hébergeant leur contenu dans de nombreuses régions du monde.
Tous les systèmes de production Atlassian Cloud se trouvent dans les régions Amazon AWS USA-Est et USA-Ouest, dans la région AWS d'Irlande, dans la région AWS de Francfort, dans la région AWS de Sydney et dans la région AWS de Singapour.
Après inscription, la plateforme Atlassian optimise l'emplacement de stockage des données client en fonction de l'origine de l'accès. Elle assure ainsi des performances plus fiables et une latence réduite.
Actuellement, la résidence des données est disponible dans le cadre de nos offres Cloud Standard, Premium et Enterprise pour Jira Software, Confluence et Jira Service Management. Vous pouvez choisir d'héberger certaines données produit en Australie, aux États-Unis ou en Europe. En savoir plus sur les contrôles de résidence des données.
Gardez un œil sur notre feuille de route Cloud pour voir les dernières mises à jour, comme la résidence des données pour des emplacements supplémentaires, la résidence des données pour les apps, et plus encore. | Emplacement physique
Sécurisation des données | Atlassian Trust Center
Infrastructure d'hébergement Atlassian Cloud | Architecture et pratiques opérationnelles d'Atlassian Cloud |
| Utilisation de vos données
Reportez-vous au Contrat client Atlassian, à la Politique de confidentialité et à l'Avenant sur le traitement des données d'Atlassian. | Utilisation de vos données
Contrat client Atlassian | Atlassian
Politique de confidentialité | Atlassian
Avenant sur le traitement des données | Atlassian |
| Considérations supplémentaires
Reportez-vous à l'engagement d'Atlassian en faveur du RGPD et d'autres lois sur la protection des données. | Considérations supplémentaires
Engagement en faveur du RGPD | Atlassian | Atlassian |
| 2.2 Sécurité des data centers | Ce point est abordé dans l'Avenant sur le traitement des données d'Atlassian, dans lequel Atlassian s'engage à protéger vos données, notamment en ce qui concerne la sécurité des data centers, du réseau et des données.
Atlassian anticipe les menaces physiques qui pèsent sur ses data centers et a implémenté des mesures correctives pour prévenir ou limiter l'impact de ces menaces.
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.
AWS maintient plusieurs certifications pour la protection de ses data centers. Les informations relatives à l'assurance de protection physique d'AWS se trouvent à l'adresse suivante : https://aws.amazon.com/fr/compliance/ | Voir
https://www.atlassian.com/fr/trust/security/securitypractices#physical-security |
| 2.3 Chiffrement des données | Atlassian assure le chiffrement du réseau sans fil interne, notamment en modifiant les paramètres par défaut du fournisseur. L'équipe Workplace Technology d'Atlassian protège nos réseaux sans fil en utilisant l'authentification WPA2-AES et le chiffrement PEAP-EAP-MSCHAPv2. Nous nous authentifions sur notre réseau sans fil via 802.1x en utilisant notre magasin d'identités interne. Nous recherchons régulièrement des points d'accès sans fil indésirables et nous tenons à jour une liste de ces points.
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 en savoir plus, consultez la page : https://www.atlassian.com/fr/trust/security/security-practices#encryption-of-data | Nos politiques de sécurité et de confidentialité des données
Chiffrement des données | Chiffrement des données
Atlassian Trust Center | Architecture et pratiques opérationnelles d'Atlassian Cloud |
| 2.4 Nettoyage des données et élimination du matériel | 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/ | Conservation et suppression des données | Atlassian Trust Center
Suivi du stockage et déplacement de données entre les produits | Support Atlassian |
| 2.5 Résilience physique et disponibilité | 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. Cette politique couvre des domaines tels que les zones de travail sécurisées, la sécurisation de notre équipement informatique où qu'il se trouve, la restriction de l'accès à nos immeubles et bureaux au personnel approprié, ainsi que la surveillance des points d'entrée et de sortie physiques. Nos pratiques de sécurité physique englobent la présence de réceptionnistes pendant les heures de travail, l'inscription obligatoire des visiteurs, l'accès aux badges dans tous les espaces non publics. Par ailleurs, nous collaborons avec le service de gestion de notre immeuble pour l'accès en dehors des heures d'ouverture et l'enregistrement vidéo aux points d'entrée et de sortie, tant pour les entrées principales que pour les zones de chargement.
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.
En plus des mesures ci-dessus, nous publions également l'état de disponibilité de nos services en temps réel pour nos clients à l'aide de notre produit Statuspage. En cas de problème avec l'un de nos produits, nos clients en seront informés en même temps que nous. | Sécurité physique | Atlassian Trust Center |
| Principe 3 : Isolement des clients |
| | Bien que nos clients partagent une infrastructure informatique commune basée dans le cloud lorsqu'ils utilisent des produits Atlassian, nous avons mis en place des mesures pour nous assurer qu'ils sont logiquement isolés afin que les actions d'un client ne puissent compromettre les données ou le service d'autres clients.
L'approche d'Atlassian varie selon les applications. Pour Jira et Confluence Cloud, nous adoptons un concept appelé « Contexte de locataire » pour parvenir à l'isolement logique de nos clients. Ce concept est implémenté à la fois dans le code applicatif et géré par ce que nous appelons un service de contexte de locataire (Tenant Context Service, TCS). Celui-ci assure que :
- les données de chaque client sont logiquement isolées de celles des autres locataires au repos ;
- toutes les demandes traitées par Jira ou Confluence offrent une vue « propre au locataire » afin que les autres locataires ne soient pas impactés.
Dans les grandes lignes, le TCS stocke un « contexte » pour les différents locataires du client. Le contexte de chaque locataire est associé à un ID unique stocké de façon centrale par le TCS et inclut diverses métadonnées associées à ce locataire (comme les bases de données dans lesquelles le locataire se trouve, les licences dont il dispose, les fonctionnalités auxquelles il a accès, et tout un éventail d'autres informations de configuration). Lorsqu'un client accède à Jira ou Confluence Cloud, le TCS utilise l'identifiant du locataire pour rassembler ces métadonnées, qui sont ensuite associées à toutes les opérations effectuées par le locataire dans l'application tout au long de sa session.
Le contexte fourni par le TCS fait office d'« objectif » par l'intermédiaire duquel ont lieu toutes les interactions avec les données client, et cet objectif est toujours limité à un locataire donné. Ainsi, nous avons la certitude qu'un locataire du client n'a pas accès aux données d'un autre locataire ou qu'un locataire ne peut affecter le service d'un autre locataire par ses actions.
Retrouvez plus d'informations sur notre architecture cloud dans nos ressources de support relatives au cloud. | Architecture et pratiques opérationnelles d'Atlassian Cloud | Atlassian Trust Center |
| Principe 4 : Framework de gouvernance |
| | Atlassian reconnaît que des entités réglementées doivent examiner nos contrôles internes, nos systèmes, la sécurité des données et la protection de la confidentialité des services dans le cadre de leurs évaluations des risques. Atlassian fait chaque année l'objet de plusieurs audits indépendants par des tiers afin de vérifier nos opérations et nos contrôles internes.
Pour consulter notre programme de conformité actuel, rendez-vous sur notre Centre de ressources dédié à la conformité où vous trouverez toutes les vérifications et certifications téléchargeables de nos produits.
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. | Nos politiques de sécurité et de confidentialité des données
Gestion des risques et de la conformité | Atlassian Trust Center
Notre système ATMS (Atlassian Trust Management System) | Atlassian Trust Center
Avenant sur le traitement des données | Atlassian Trust Center |
| Principe 5 : Sécurité opérationnelle |
| 5.1 Gestion des vulnérabilités | Atlassian s'efforce constamment de réduire la gravité et la fréquence des vulnérabilités dans ses produits, services et infrastructures, et de s'assurer que les vulnérabilités identifiées sont corrigées le plus rapidement possible. Pour faciliter ce processus, nous appliquons une approche multidimensionnelle et en constante évolution de la gestion des vulnérabilités qui fait à la fois appel à des processus automatisés et manuels pour identifier, suivre et corriger les vulnérabilités dans nos applications et notre infrastructure.
Pour toutes nos offres de produits et de services, nous avons mis en place un processus complet de correction des bugs (en utilisant notre propre produit Jira, qui détecte les tickets et nous aide à gérer les demandes de résolution). Ce processus repose sur de nombreuses politiques de correction des bugs de sécurité, des services de conseil et des SLO que nous respectons. Nous recevons les rapports de bug via notre canal de support, notre programme Bug Bounty et l'adresse security@atlassian.com. De plus amples informations sont disponibles sur notre Trust Center (https://www.atlassian.com/fr/trust/) à propos de nos SLO de correction des bugs de sécurité (https://www.atlassian.com/fr/trust/security/bug-fix-policy).
Notre équipe Atlassian chargée de la sécurité utilise plusieurs méthodes pour détecter les vulnérabilités des infrastructures internes et externes. 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.
De plus amples informations sont disponibles dans notre document consacré à l'approche d'Atlassian en matière de gestion des vulnérabilités.
Pour plus d'informations sur notre approche des tests de sécurité, consultez également notre Trust Center ici : Notre approche en matière de tests de sécurité externes | Atlassian | Gestion des vulnérabilités | Atlassian Trust Center
Politique de correction des bugs de sécurité | Atlassian Trust Center
Notre approche en matière de tests de sécurité externes | Atlassian Trust Center
Notre approche de la gestion des vulnérabilités | Atlassian Trust Center |
| 5.2 Surveillance de protection | Reconnaissant la nécessité de miser sur notre approche de la gestion des incidents dans un contexte de menaces de plus en plus complexe, Atlassian a introduit ce qu'il appelle son « Security Detections Program ». Les détections sont des recherches qui s'exécutent de manière proactive et sur une base planifiée sur la plateforme de gestion des incidents de sécurité et des événements d'Atlassian afin de détecter les activités malveillantes ciblant Atlassian et ses clients.
Notre équipe chargée de la détection et de l'intervention se concentre sur la création régulière de détections, l'adaptation et l'amélioration des détections existantes et l'automatisation des réponses aux détections. Elle procède ainsi dans un certain nombre de dimensions, y compris les produits, les types d'attaques et les sources de journaux afin de s'assurer que la couverture de nos détections est aussi efficace et complète que possible.
Le programme a pour objectif de s'assurer que nous sommes prêts à affronter les menaces auxquelles nous sommes confrontés aujourd'hui, mais également d'anticiper les menaces futures et de nous y préparer suffisamment. Notre équipe chargée de la détection et de l'intervention a également créé un outil pour standardiser les détections que nous créons afin de garantir un niveau élevé de cohérence et de qualité parmi les détections exécutées, ce qui est selon nous une première dans le secteur.
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é. 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 | L'Atlassian Detections Program | Atlassian Trust Center
Utilisation des journaux | Atlassian Trust Center
Avenant sur le traitement des données | Atlassian Trust Center |
| 5.3 Gestion des incidents | Atlassian adopte une approche globale de la gestion des incidents de sécurité. Nous considérons comme incident de sécurité toute situation ayant des répercussions négatives sur la confidentialité, l'intégrité ou la disponibilité des données de nos clients, des données d'Atlassian ou des services d'Atlassian.
Nous disposons d'un framework interne clairement défini qui comprend des stratégies d'équipe documentées pour différents types d'incident. Ce framework couvre les mesures que nous devons prendre à toutes les étapes de la réponse aux incidents afin de nous assurer que nos processus sont cohérents, reproductibles et efficaces. Il s'agit notamment de la détection et de l'analyse des incidents, de la catégorisation des incidents, de la maîtrise, de l'éradication et de la reprise. Cette cohérence est renforcée par l'utilisation de nos propres produits, notamment Confluence, Jira et Bitbucket, dans le cadre de nos processus de réponse aux incidents :
- Confluence permet de créer, de documenter et de mettre à jour nos processus de réponse dans un emplacement central.
- Jira permet de créer des tickets pour suivre l'avancement du processus de réponse aux incidents de sécurité (potentiels et réels) de bout en bout.
- Bitbucket est utilisé dans les cas où nous développons des solutions basées sur le code pour répondre à certains problèmes périphériques survenant lors de certains incidents.
Nous avons mis en place une journalisation et une surveillance complètes et centralisées de nos produits et de notre infrastructure pour nous assurer que nous détectons rapidement les incidents potentiels. Celles-ci sont soutenues par une équipe de gestionnaires d'incident d'astreinte hautement qualifiés, qui justifient d'une grande expérience dans la coordination d'une réponse efficace. Nous avons également accès à tout un éventail d'experts externes pour nous aider à enquêter et à intervenir le plus efficacement possible.
Nous avons mis en place des processus de notification pour nos clients dans le cas où leurs données sont impliquées dans un incident confirmé, ainsi qu'un processus robuste de revue post-incident qui nous permet de tirer des leçons d'un incident afin d'améliorer nos pratiques et de compliquer le travail des personnes malveillantes à l'avenir. Pour plus d'informations, veuillez consulter notre document distinct Notre approche de la gestion des incidents de sécurité sur l'Atlassian Trust Center. | Gestion des incidents | Atlassian Trust Center
Avenant sur le traitement des données | Atlassian Trust Center |
| 5.4 Gestion des configurations et des changements | Notre processus de gestion des changements est légèrement différent d'un processus traditionnel. Les processus traditionnels de gestion des changements reposent sur une hiérarchie de contrôle des changements de type pyramidale. Cela signifie que quand quelqu'un souhaite apporter un changement, il doit le présenter à un conseil qui l'approuve ou le refuse tôt ou tard.
Nous avons adopté une approche de type « open source » que nous qualifions de « Peer Review, Green Build » (PRGB). Contrairement à un processus traditionnel de gestion des changements, l'approche PRGB exige que chaque changement, qu'il s'agisse d'un changement de code ou d'une modification de l'infrastructure, soit examiné par un ou plusieurs pairs afin d'identifier les problèmes qu'il pourrait impliquer. Nous augmentons le nombre de réviseurs en fonction de la criticité du changement ou de celle des systèmes impactés par celui-ci, et nous faisons confiance à nos ingénieurs pour identifier les problèmes et les signaler avant que le changement ne soit implémenté. Ce processus est idéal pour assurer la gestion dynamique et flexible des changements dans notre environnement. La partie « Green Build » de ce contrôle fait référence à un build fructueux ou propre dans notre système de CI/CD qui inclut les nouveaux changements. Si le changement introduit des composants qui ne réussissent pas les tests d'intégration, de fonction, unitaires ou de sécurité, le build est rejeté, et nous revenons à la demande de changement d'origine pour résoudre les problèmes éventuels.
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 | Gestion des changements dans notre environnement | Atlassian Trust Center
Passer de l'assurance qualité à l'assistance qualité |
| Principe 6 : Sécurité du personnel |
| | Valeurs de l'entreprise
Vous trouverez plus d'informations sur les valeurs de l'entreprise Atlassian ici : https://www.atlassian.com/fr/company/values
| Valeurs de l'entreprise
Valeurs de l'entreprise | Atlassian
|
| Vérifications des antécédents des employés
Les antécédents des nouveaux employés d'Atlassian du monde entier doivent être vérifiés. 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é. | Vérifications des antécédents des employés
Vérifications des antécédents | Atlassian Trust Center |
| Formation à la sécurité pour tous les employés Atlassian
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é. Sensibilisation à la sécurité | Atlassian Trust Center | Formation à la sécurité pour tous les employés d'Atlassian
Sensibilisation à la sécurité | Atlassian Trust Center |
| Principe 7 : Développement sécurisé | 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é appropriées 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 (Programme Bug Bounty d'Atlassian | Bugcrowd) pour garantir l'assurance continue de nos applications.
En outre, vous pouvez consulter le rapport SOC 2 d'Atlassian. Celui-ci a pour objectif d'évaluer les systèmes d'une organisation en termes de sécurité, de disponibilité, d'intégrité du traitement, de confidentialité et de respect de la vie privée. | Avenant sur le traitement des données | Atlassian Trust Center |
| Principe 8 : Sécurité de la chaîne d'approvisionnement | Lorsque nous engageons des fournisseurs tiers (y compris des sous-traitants et des fournisseurs de services cloud), nous veillons à ce que ces recrutements ne compromettent en aucune façon nos clients ou leurs données. Pour cela, nos équipes juridiques et d'approvisionnement procèdent à un examen pour toute proposition de recrutement d'un fournisseur tiers. Tous les recrutements qui, selon nous, présentent un risque élevé ou critique, font l'objet d'examens supplémentaires de la part de nos équipes de sécurité, de gestion des risques et de conformité. Nous faisons également preuve d'une diligence raisonnable continue en effectuant des examens ultérieurs, soit au moment du renouvellement du contrat, soit chaque année, selon le niveau de risque du recrutement.
Atlassian exige également de ses fournisseurs qu'ils respectent les exigences minimales de sécurité dans le cadre de leur engagement auprès de nous. Ces exigences sont incluses à nos contrats fournisseur. Elles varient en fonction du niveau de risque associé et incluent :
- l'intégration SAML à la plateforme d'authentification unique d'Atlassian ;
- le chiffrement des données en transit et au repos à l'aide d'algorithmes non obsolètes ;
- la mise en place de mécanismes de journalisation suffisants pour fournir à Atlassian des informations pertinentes concernant les incidents de sécurité potentiels.
| Gestion des risques fournisseur | Atlassian Trust Center
Rapport SOC2 d'Atlassian | Page 29 (Gestion des fournisseurs) |
| Principe 9 : Gestion sécurisée des utilisateurs |
| 9.1 Authentification des utilisateurs auprès des interfaces de gestion et des canaux de support | Chez Atlassian, nous pensons qu'il s'agit d'une responsabilité partagée entre le client et Atlassian.
Utilisateurs authentifiés
Nous traitons toutes les données client comme également sensibles et avons mis en place des contrôles stricts régissant ces données. Une formation de sensibilisation est dispensée à nos employés internes et à nos sous-traitants pendant le processus d'intégration. Celle-ci couvre l'importance des données client et les bonnes pratiques de traitement.
Au sein d'Atlassian, seuls les employés autorisés ont accès aux données client stockées dans nos applications. L'authentification se fait par l'intermédiaire de clés publiques individuelles protégées par mot de passe, et les serveurs n'acceptent que les connexions SSH entrantes provenant de data centers Atlassian et internes. Tous les accès sont restreints à des groupes autorisés, sauf s'ils font l'objet d'une demande et d'un examen, et nécessitent une authentification supplémentaire à l'aide d'un deuxième facteur.
Grâce aux contrôles d'authentification et d'autorisation stricts mis en place, notre équipe de support mondial facilite les processus de maintenance et de support. L'accès aux applications et aux données hébergées n'est possible qu'à 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. Nos clients disposent également d'options de consentement explicite pour déterminer les ingénieurs de support appropriés susceptibles d'accéder à leurs données via notre outil de contrôle du consentement.
Tout accès non autorisé ou inapproprié aux données client est traité comme un incident de sécurité et est géré par notre processus de gestion des incidents. Celui-ci comprend des instructions pour informer les clients concernés si une violation de la politique est observée. | Contrôle des accès aux données client | Atlassian Trust Center
Avenant sur le traitement des données | Atlassian Trust Center |
| 9.2 Séparation et contrôle des accès au sein des interfaces de gestion | Grâce à cette architecture AWS, nous hébergeons un certain nombre de services produit et de plateforme utilisés sur l'ensemble de nos solutions. Ces services incluent les fonctionnalités de la plateforme qui sont partagées et utilisées par plusieurs produits Atlassian (comme Media, Identity et Commerce), des expériences comme notre éditeur, ainsi que des fonctionnalités spécifiques des produits, notamment le service Jira Issue et Confluence Analytics.
Les développeurs Atlassian fournissent ces services via une Platform as a Service (PaaS) développée en interne, appelée Micros, qui orchestre automatiquement le déploiement des services partagés, de l'infrastructure, des magasins de données et de leurs capacités de gestion, y compris les exigences de contrôle de la sécurité et de la conformité (voir la figure 1 ci-dessus). En général, un produit Atlassian se compose de plusieurs services « conteneurisés » déployés sur AWS à l'aide de Micros. Les produits Atlassian utilisent les fonctionnalités de base de la plateforme (voir la figure 2 ci-dessous) qui vont du routage des demandes aux magasins d'objets binaires, en passant par l'authentification/autorisation, le contenu généré par l'utilisateur (CGU) transactionnel et les magasins de relations entre entités, les data lakes (lacs de données), la journalisation commune, le suivi des demandes, l'observabilité et les services d'analyse.
En plus de notre infrastructure cloud, nous avons créé et utilisons une architecture de microservices multilocataire avec une plateforme partagée qui prend en charge nos produits. Dans une architecture multilocataire, un seul service dessert plusieurs clients, y compris les bases de données et les instances de calcul nécessaires à l'exécution de nos produits cloud. Chaque partition (essentiellement un conteneur, voir la figure 3 ci-dessous) contient les données de plusieurs locataires, mais les données de chaque locataire sont isolées et inaccessibles aux autres locataires. Il est important de noter que nous ne proposons pas une architecture à locataire unique.
Pour en savoir plus, consultez la page https://www.atlassian.com/fr/trust/reliability/cloud-architecture-and-operational-practices#cloud-infrastructure | Architecture multilocataire | Architecture et pratiques opérationnelles d'Atlassian Cloud
Avenant sur le traitement des données | Atlassian Trust Center |
| Principe 10 : Identité et authentification |
| | Reportez-vous aux sections 9.1 et 9.2 pour en savoir plus sur l'authentification et la gestion des accès. | S. O. |
| Principe 11 : Protection de l'interface externe |
| | Reportez-vous au Principe 5 pour en savoir plus sur la manière dont Atlassian Trust protège ses clients cloud. | S. O. |
| Principe 12 : Administration sécurisée des services |
| | Dans l'Avenant sur le traitement des données d'Atlassian, nous nous engageons à protéger les données des clients, y compris en matière de contrôle d'accès et de gestion des privilèges.
Reportez-vous aux sections 9.1 et 9.2 pour en savoir plus sur l'authentification et la gestion des accès. | S. O. |
| Principe 13 : Informations d'audit destinées aux utilisateurs |
| | Tous les accès à l'application cliente sont enregistrés. Chaque interaction avec l'interface utilisateur est consignée dans le journal d'audit de l'application.
Atlassian restreint, consigne et surveille l'accès privilégié à l'Atlassian Account Identity Store et à d'autres systèmes de gestion de la sécurité des informations.
Les journaux sont stockés dans un système logiquement distinct, et l'accès en écriture aux journaux est limité aux membres de l'équipe de sécurité. Des alertes sont envoyées à l'équipe de sécurité ou au centre de services lorsque des actions ou des événements spécifiques sont identifiés dans les journaux. Notre service de journalisation centralisé (couvrant la plateforme Atlassian Cloud, Jira, Confluence et Bamboo) est intégré à notre infrastructure d'analyse de sécurité pour des analyses automatisées, et des alertes sont créées pour identifier les problèmes potentiels.
Pour Bitbucket, les journaux d'audit sont utilisés pour les enquêtes post-incident. La configuration de services gérée par Puppet et en tant que format de configuration déclaratif garantit que toutes les configurations système gérées par ses manifestes sont correctement configurées à chaque exécution. Des alertes de surveillance sont mises en place si Puppet ne fonctionne pas sur un serveur donné. Nos scanners de vulnérabilité internes et externes incluent des alertes en cas d'ouverture inattendue de ports ou d'autres changements de configuration (par exemple, les profils TLS des serveurs d'écoute).
Reportez-vous à Atlassian Access. Pour plus d'informations, voir : Atlassian Access | Sécurité et authentification unique pour Jira, Confluence, et bien plus
En interne, pour Atlassian, les journaux sont stockés dans un système logiquement distinct, et l'accès en écriture aux journaux est réservé aux membres de l'équipe de sécurité et de notre équipe d'observabilité. Notre service de journalisation centralisé est intégré à notre infrastructure d'analyse de sécurité pour des analyses automatisées, et des alertes sont créées pour identifier les problèmes potentiels.
Pour les clients Atlassian Cloud, les journaux d'audit relatifs aux changements apportés à l'organisation sont disponibles dans le cadre d'Atlassian Access. Grâce à ces journaux d'audit, vous avez une visibilité sur les actions de l'administrateur concernant les utilisateurs, les groupes, les autorisations, et plus encore. Pour plus d'informations : https://support.atlassian.com/security-and-access-policies/docs/track-organization-activities-from-the-audit-log/
Les produits cloud d'Atlassian disposent également de leur propre journal d'audit pour les changements spécifiques des produits. | S. O. |
| Principe 14 : Utilisation sécurisée du service |
| | Chez Atlassian, nous pensons qu'il s'agit d'une responsabilité partagée entre le client et Atlassian.
Vous pouvez consulter une série d'autres ressources, en partie évoquées dans cet article, pour obtenir plus d'informations sur notre approche de la gestion des vulnérabilités, ainsi que de la sécurité en général.
| S. O. |