Vue d’ensemble de la protection des données

Azure DevOps Services

Azure DevOps Services est une application hébergée dans le cloud pour vos projets de développement, de la planification au déploiement. En fonction des fonctionnalités locales, avec des services cloud supplémentaires, nous gérons votre code source, vos éléments de travail, vos builds et vos tests. Azure DevOps utilise l’infrastructure PaaS (Platform as a Service) et de nombreux services Azure, y compris Azure SQL, pour fournir un service fiable et disponible à l’échelle mondiale pour vos projets de développement.

Cet article décrit les étapes que Microsoft prend pour garantir la sécurité, la disponibilité, la sécurité et la confidentialité de vos projets. Il décrit le rôle que vous jouez dans la sécurisation et la sécurité de vos projets.

Cet article est destiné aux administrateurs d’organisation et aux professionnels de l’informatique qui gèrent quotidiennement leurs ressources de projet. Il est très utile aux personnes qui connaissent déjà Azure DevOps et qui souhaitent en savoir plus sur la façon dont Microsoft protège les ressources stockées dans Azure DevOps.

Notre engagement

Microsoft permet de garantir que vos projets restent sécurisés, sans exception. Lorsque vous stockez vos projets dans Azure DevOps, ils bénéficient de plusieurs couches de technologies de sécurité et de gouvernance, de pratiques opérationnelles et de stratégies de conformité. Nous appliquons la confidentialité et l’intégrité des données au repos et en transit.

Les menaces que vous rencontrez se résument à quatre catégories de base : disponibilité des données, disponibilité des services, sécurité des services et confidentialité des données. Cet article explore des menaces spécifiques dans chaque catégorie et explique ce qu’azure DevOps fait pour les traiter. L’article commence par décrire comment les données sont stockées et comment Azure DevOps gère l’accès à vos données.

La protection des données nécessite l’engagement actif des administrateurs et des utilisateurs qui savent quelles mesures prendre pour protéger vos ressources contre la divulgation et la falsification non autorisées. Soyez explicite lorsque vous accordez des autorisations aux points d’accès utilisateur, de sorte que seules les personnes appropriées accèdent aux données dans Azure DevOps.

Vous devez considérer toutes les données potentiellement à risque, quel que soit l’endroit où elles sont utilisées ou la façon dont elles sont utilisées. Cette instruction est vraie pour les données stockées dans le cloud et les données stockées dans un centre de données privé. Il est important de classifier vos données, leur sensibilité et leur risque, ainsi que les dommages qu’il peut faire s’ils sont compromis. En outre, catégorisez vos données par rapport à une stratégie globale pour la gestion de la sécurité des informations.

Basé sur Azure

Diagram of the high-level architecture of Azure DevOps.

Nous hébergeons entièrement Azure DevOps dans les centres de données Azure. Azure DevOps utilise de nombreux services Azure de base, notamment le calcul, le stockage, la mise en réseau, la Azure SQL, la gestion des identités et des accès et Azure Service Bus.

Azure DevOps utilise le stockage Azure comme référentiel principal pour les métadonnées de service et les données client. En fonction du type de données et des exigences de stockage et de récupération, Azure DevOps utilise Stockage Blob Azure et le stockage Azure SQL Database.

Pour vous aider à comprendre l’approche d’Azure DevOps Services pour la protection des données, voici un arrière-plan sur les services de stockage :

  • Stockage Blob Azure stocke de gros morceaux de données non structurées. Tous les projets utilisent ce service. Les données incluent des informations potentiellement sensibles ou privées, telles que le contenu des fichiers sources et des pièces jointes pour les éléments de travail. Pour la plupart des projets, la majorité du stockage utilisé est ce type de stockage d’objets blob non structuré.

  • Azure SQL Database stocke les aspects structurés et transactionnels de votre organisation, notamment les métadonnées du projet, l’historique du contrôle de code source versionné et les détails des éléments de travail. Le stockage de base de données vous permet d’accéder rapidement aux éléments importants de votre projet. Il fournit des index dans le stockage d’objets blob pour rechercher des fichiers et des pièces jointes.

Les administrateurs peuvent gérer l’accès aux ressources en accordant ou en restreignant des autorisations sur des identités ou des groupes d’utilisateurs. Azure DevOps utilise l’authentification fédérée des identités utilisateur via l’ID Microsoft Entra et les comptes Microsoft.

Pendant l’authentification, l’utilisateur est routé vers le fournisseur d’authentification, où il fournit ses informations d’identification. Une fois que le fournisseur d’authentification vérifie les informations d’identification de l’utilisateur, Azure DevOps émet un cookie d’authentification à l’utilisateur. Ce cookie permet à l’utilisateur de rester authentifié auprès d’Azure DevOps.

De cette façon, les informations d’identification de l’utilisateur ne sont jamais partagées directement avec Azure DevOps. Pour chaque ressource Azure DevOps que l’utilisateur tente d’accéder, la validation des autorisations est basée sur les autorisations explicites de l’utilisateur et sur les autorisations héritées par l’utilisateur via l’appartenance au groupe.

Administration istrateurs peuvent utiliser des contrôles d’accès pour protéger l’accès à l’organisation, aux regroupements de projets, aux projets d’équipe et aux données et fonctionnalités étendues à l’équipe. Administration istrators peuvent également utiliser des contrôles d’accès pour des ressources spécifiques telles que des dossiers pour le contrôle de version et les chemins d’accès aux zones pour les éléments de travail.

Disponibilité des données

Azure DevOps utilise de nombreuses fonctionnalités de Stockage Azure pour garantir la disponibilité des données en cas de défaillance matérielle, d’interruption de service ou de sinistre régional. En outre, l’équipe Azure DevOps suit les procédures permettant de protéger les données contre la suppression accidentelle ou malveillante.

Redondance des données

Pour protéger les données pendant les défaillances matérielles ou de service, Stockage Azure géorépliquer les données client entre deux régions dans le même emplacement géographique. Par exemple, Stockage Azure peut géorépliquer des données entre l’Europe Nord et l’Europe Ouest ou entre le Nord et le Sud États-Unis.

Pour Stockage Blob Azure, les données client sont répliquées trois fois dans une seule région. Les données client sont répliquées de manière asynchrone vers une deuxième région dans le même emplacement géographique. Par conséquent, Azure conserve toujours l’équivalent de six copies de vos données.

La présence de plusieurs copies vous permet de basculer vers une région distincte en cas de panne ou de sinistre majeure, tout en ayant une redondance locale pour les défaillances matérielles au sein d’une région. Pour Azure SQL stockage de base de données, les sauvegardes quotidiennes sont conservées hors site en cas de sinistre régional.

Concernant la redondance et le basculement des données :

  • Il existe un delta inhérent, mesuré en minutes, lorsque Microsoft réplique vos données entre la région primaire et la région secondaire.
  • Le basculement vers la région secondaire est une décision que Microsoft doit prendre de manière centralisée, car il affecte tous les clients sur une unité d’échelle particulière. Sauf dans des circonstances extrêmes, Microsoft choisit d’éviter le basculement afin que les données client ne soient pas perdues.
  • Azure DevOps offre une garantie de niveau de service (SLA) de 99,9 %. Azure DevOps rembourse une partie des frais mensuels s’il manque ce contrat SLA dans un mois spécifique.
  • Étant donné qu’il n’existe qu’une seule région au Brésil, les données client au Brésil sont répliquées vers la région USA Centre Sud à des fins de récupération d’urgence.

Des erreurs se produisent

Pour vous protéger contre la suppression accidentelle de données, Microsoft prend également des sauvegardes à un point dans le temps des objets blob dans Stockage Blob Azure et les bases de données dans Azure SQL Database. Il existe une copie distincte de tous les objets blob, et les modifications sont ajoutées à chaque compte de stockage. Étant donné que ces données sont immuables, vous n’avez pas besoin de réécrire un stockage existant dans le cadre des procédures de sauvegarde.

Les sauvegardes sont une partie standard d’Azure SQL Database, et Azure DevOps utilise cette fonctionnalité. Nous maintenons vos données pendant 28 jours. Ces sauvegardes sont également répliquées dans une région jumelée pour faciliter la récupération à partir d’une panne régionale.

Les clients peuvent récupérer leurs organisations ou projets supprimés pendant jusqu’à 28 jours après la suppression. Après 28 jours, ces organisations et projets sont définitivement supprimés et ne peuvent pas être restaurés.

Important

La suppression accidentelle ici fait référence aux scénarios qui surviennent suite à un incident sur nos services. Il n’inclut pas la suppression accidentelle des ressources par les clients (par exemple, référentiels, éléments de travail, pièces jointes ou artefacts).

Nous ne prenons pas en charge la restauration des ressources que les clients suppriment accidentellement. Ces sauvegardes sont destinées uniquement à la continuité de l’activité et à faciliter la récupération à partir de scénarios de panne ou de sinistre.

La pratique est essentielle

L’utilisation de plusieurs sauvegardes de vos données est correcte, mais sans pratique, la restauration peut être imprévisible. Il a été dit que « les sauvegardes ne échouent jamais ; les restaurations le font. Bien que l’instruction soit techniquement incorrecte, le sentiment est correct.

Microsoft pratique régulièrement la restauration des jeux de données à partir de la sauvegarde. Nous testons régulièrement le stockage géoredondant à partir d’Azure. Il existe de nombreuses combinaisons de scénarios de sinistre et de corruption des données. Nous continuons à planifier et à exécuter régulièrement de nouveaux tests pour ces scénarios.

Disponibilité du service

Azure DevOps offre des protections contre le déni de service distribué (DDoS) et une réponse de site en direct pour vous assurer que vous avez accès à votre organization et aux ressources associées.

Protections DDoS

Dans certains cas, une attaque DDoS malveillante peut affecter la disponibilité du service. Azure dispose d’un système de défense DDoS qui permet de prévenir les attaques contre notre service. Il utilise des techniques de détection et d’atténuation standard telles que les cookies SYN, la limitation de débit et les limites de connexion. Le système est conçu pour résister aux attaques provenant non seulement de l’extérieur, mais également de l’intérieur d’Azure.

Pour les attaques spécifiques à l’application qui peuvent pénétrer les systèmes de défense Azure, Azure DevOps établit des quotas et des limitations au niveau de l’application. Cette pratique permet d’éviter toute surutilisation des ressources de service clés lors d’une attaque ou d’une mauvaise utilisation accidentelle des ressources.

Réponse de site en direct

Dans de rares cas, vous pouvez avoir besoin d’une réponse de site en direct à un problème de disponibilité du service. Nous disposons d’une équipe d’exploitation qui est constamment disponible pour identifier rapidement le problème et engager les ressources de l’équipe de développement nécessaires.

Les ressources de l’équipe de développement résolvent ensuite le problème. Ils visent également à mettre à jour la page d’état du service dans les minutes suivant la détection d’un problème qui affecte le service. Une fois que les ressources de l’équipe de développement résolvent un problème, elles identifient la cause racine et suivent les modifications nécessaires pour éviter des problèmes similaires à l’avenir.

Les processus Azure DevOps pour la gestion des sites en direct se concentrent sur votre expérience et l’intégrité du service. Ces processus réduisent le temps nécessaire à la détection, à la réponse et à l’atténuation des problèmes. Toutes les disciplines techniques sont impliquées et responsables, de sorte que les améliorations continues évoluent en dehors de l’expérience directe. La surveillance, les diagnostics, la résilience et les processus d’assurance qualité s’améliorent ensuite au fil du temps.

La gestion des sites en direct dans Azure DevOps comporte trois pistes distinctes : télémétrie, gestion des incidents et révision de site en direct. Voici ce qu’impliquent ces pistes :

Image of the Azure DevOps Services process for live site management.

L’équipe des opérations surveille également les métriques de disponibilité pour les organisations individuelles. Ces métriques fournissent des informations sur des conditions spécifiques qui peuvent affecter uniquement certains de nos clients. Les enquêtes sur ces données peuvent souvent aboutir à des améliorations ciblées pour résoudre les problèmes spécifiques du client. Dans certains cas, Microsoft peut même vous contacter directement pour comprendre votre expérience et travailler avec vous pour améliorer le service.

Microsoft publie un contrat SLA et fournit une garantie financière pour nous assurer que nous respectons ce contrat chaque mois. Pour plus d’informations, consultez SLA pour Azure DevOps.

Parfois, les équipes partenaires ou les dépendances ont des incidents qui affectent Azure DevOps. Toutes les équipes partenaires suivent des approches similaires pour identifier, résoudre et apprendre de ces pannes de service.

Sécurité du service

La sécurité du service nécessite une vigilance constante, des techniques de conception et de codage appropriées aux facteurs opérationnels. Microsoft investit activement dans la prévention des failles de sécurité et dans la détection des violations. En cas de violation, Microsoft utilise des plans de réponse de sécurité pour réduire la fuite, la perte ou l’altération des données. Pour plus d’informations, consultez À propos de la sécurité, de l’authentification et de l’autorisation.

Sécurité par conception

Azure DevOps est conçu pour être sécurisé. Azure DevOps utilise le cycle de vie du développement de la sécurité Microsoft au cœur de son processus de développement. Le programme Microsoft Operational Security Assurance guide les procédures d’opération cloud dans Azure DevOps.

L’équipe Azure DevOps a des exigences de formation annuelles pour tous les ingénieurs et le personnel des opérations. L’équipe parraine également des réunions informelles hébergées par les ingénieurs Microsoft. Une fois que l’équipe a résolu un problème qui s’affiche lors d’une réunion, elle partage les leçons apprises avec d’autres équipes.

Les méthodologies suivantes spécifient les exigences de formation :

  • Modélisation des menaces pendant la conception du service
  • Bonnes pratiques suivantes pour la conception et le code
  • Vérification de la sécurité avec des outils et des tests standard
  • Limitation de l’accès aux données opérationnelles et client
  • Déploiement de nouvelles fonctionnalités par le biais d’un processus d’approbation rigide

Un service cloud est aussi sécurisé que la plateforme hôte. Azure DevOps utilise PaaS pour une grande partie de son infrastructure. PaaS fournit automatiquement des mises à jour régulières pour les vulnérabilités de sécurité connues.

Les machines virtuelles hébergées dans Azure utilisent l’infrastructure en tant que service (IaaS), comme pour un service de build hébergé. Ces images reçoivent régulièrement des mises à jour pour inclure les derniers correctifs de sécurité disponibles à partir de Windows Update. La même rigueur de mise à jour s’applique aux machines locales, y compris celles utilisées pour le déploiement, la supervision et la création de rapports.

L’équipe Azure DevOps effectue régulièrement des tests de pénétration axés sur la sécurité d’Azure DevOps. Les tests d’intrusion tentent d’exploiter les services de production en direct et l’infrastructure d’Azure DevOps à l’aide des mêmes techniques et mécanismes que les attaquants malveillants utilisent. L’objectif est d’identifier les vulnérabilités réelles, les configurations, les erreurs ou d’autres lacunes de sécurité dans un processus contrôlé.

L’équipe examine les résultats de ces tests afin d’identifier d’autres domaines d’amélioration et d’accroître la qualité des systèmes préventifs et de la formation. Vous pouvez consulter les résultats des derniers tests d’intrusion d’Azure DevOps sur le portail d’approbation de service Microsoft.

Sécurité des informations d’identification

Nous utilisons les meilleures pratiques du secteur pour stocker vos informations d’identification dans Azure DevOps. En savoir plus sur le stockage des informations d’identification.

Signalement des failles de sécurité

Si vous pensez que vos tests d’intrusion ont révélé une faille de sécurité potentielle liée au service Azure DevOps, signalez-le à Microsoft dans les 24 heures. Pour plus d’informations, consultez la page web Microsoft pour signaler une vulnérabilité de sécurité informatique.

Important

Bien que vous n’ayez pas besoin d’informer Microsoft des activités de test d’intrusion, vous devez vous conformer aux règles d’engagement des tests d’intrusion Microsoft.

Programme de primes

Azure DevOps participe au programme Microsoft Bug Bounty. Ce programme récompense les chercheurs en sécurité qui nous signalent des problèmes, et encourage davantage de personnes à sécuriser Azure DevOps. Pour plus d’informations, consultez Microsoft Azure DevOps Bounty Program.

Restriction de l’accès

Microsoft contrôle strictement qui a accès à notre environnement de production et aux données client. Nous accordons l’accès au niveau des privilèges minimum requis, et seulement après vérification des justifications d’un utilisateur. Si un membre de l’équipe a besoin d’un accès pour résoudre un problème urgent ou déployer une modification de configuration, il doit demander un accès juste-à-temps au service de production. L’accès est révoqué dès que la situation est résolue.

Nous effectuons le suivi et le suivi des demandes d’accès et des approbations dans un système distinct. Tout l’accès au système est corrélé à ces approbations. Si nous détectons l’accès non approuvé, nous alertons l’équipe des opérations à examiner.

Nous utilisons l’authentification à deux facteurs pour tous les accès au système distant. Si le nom d’utilisateur et le mot de passe de l’un de nos développeurs ou du personnel des opérations sont volés, les données restent protégées. Des case activée d’authentification supplémentaires via un carte intelligent ou un appel téléphonique à un numéro préapprobé doivent se produire avant d’autoriser tout accès à distance au service.

Pour gérer et gérer le service, Microsoft utilise des secrets tels que les mots de passe RDP, les certificats SSL et les clés de chiffrement. Ces secrets sont tous gérés, stockés et transmis en toute sécurité via le Portail Azure. Tout accès à ces secrets nécessite une autorisation spécifique, enregistrée et enregistrée en toute sécurité. Tous les secrets sont pivotés régulièrement et nous pouvons les faire pivoter à la demande en cas d’événement de sécurité.

L’équipe des opérations Azure DevOps utilise des stations de travail administrateur renforcées pour gérer le service. Ces machines exécutent un nombre minimal d’applications et fonctionnent dans un environnement segmenté logiquement.

Les membres de l’équipe d’opérations doivent fournir des informations d’identification spécifiques avec une authentification à deux facteurs pour accéder aux stations de travail. Tous les accès sont surveillés et enregistrés de manière sécurisée. Pour isoler le service de falsification externe, nous n’autorisez pas les applications telles qu’Outlook et Bureau, car elles sont souvent des cibles de hameçonnage de lance et d’autres types d’attaques.

Protection et réponse aux intrusions

Nous chiffrerons les données via HTTPS et SSL pour vous assurer qu’elles ne sont pas interceptées ou modifiées pendant le transit entre vous et Azure DevOps. Les données que nous stockons pour votre compte dans Azure DevOps sont chiffrées comme suit :

  • Les données stockées dans les bases de données Azure SQL sont chiffrées via le chiffrement transparent des données. Cette fonctionnalité permet de protéger contre les activités malveillantes en effectuant un chiffrement en temps réel de la base de données, des sauvegardes associées et des fichiers journaux de transactions au repos.

  • Stockage Blob Azure connexions sont chiffrées pour protéger vos données en transit. Pour les données au repos stockées dans Stockage Blob Azure, Azure DevOps utilise le chiffrement côté service.

Remarque

Azure DevOps n’est pas conforme aux normes FIPS (Federal Information Processing Standards) 140-2 ou 140-3.

L’équipe Azure DevOps utilise l’infrastructure Azure pour consigner et surveiller les aspects clés du service. La journalisation et la surveillance permettent de s’assurer que les activités au sein du service sont légitimes et permettent de détecter les violations ou les tentatives de violations.

Toutes les activités de déploiement et d’administrateur sont journalisées en toute sécurité, car l’accès opérateur au stockage de production est utilisé. Les informations de journal sont automatiquement analysées et tout comportement potentiellement malveillant ou non autorisé déclenche des alertes en temps réel.

Lorsque l’équipe Azure DevOps identifie une vulnérabilité de sécurité à haute priorité ou d’intrusion possible, elle dispose d’un plan de réponse clair. Ce plan décrit les parties responsables, les étapes requises pour sécuriser les données client et des instructions sur la façon d’interagir avec des experts en sécurité chez Microsoft. L’équipe avertit également tous les propriétaires organization si des données ont été divulguées ou endommagées, afin qu’ils puissent prendre les mesures appropriées pour remédier à la situation.

Pour aider à lutter contre les menaces émergentes, Azure DevOps utilise une stratégie de violation de principe. Une équipe hautement spécialisée d’experts en sécurité au sein de Microsoft assume le rôle d’adversaires sophistiqués. Cette équipe teste la détection et la réponse aux violations pour mesurer avec précision la préparation et les impacts des attaques réelles. Cette stratégie renforce la détection des menaces, la réponse et la défense du service. Cela permet également à l’équipe de valider et d’améliorer l’efficacité de l’ensemble du programme de sécurité.

Protection contre les attaques par ransomware

Azure DevOps utilise des contrôles Azure pour aider à prévenir, détecter et répondre à une attaque par ransomware. Pour plus d’informations sur la façon dont Azure aide à protéger les clients contre les attaques par ransomware, consultez Protection contre les ransomwares dans Azure.

Confidentialité des données

Vous devez avoir confiance que nous gérons vos données de manière appropriée et pour des utilisations légitimes. Une partie de cette assurance implique de restreindre soigneusement l’utilisation.

Règlement général sur la protection des données

Le règlement général sur la protection des données (RGPD) est le plus grand changement dans les lois de protection des données en Europe depuis l’introduction en 1995 de la directive 95/46/EC sur la protection des données de l’Union européenne (UE). Pour plus d’informations sur le RGPD, consultez la page vue d’ensemble du Centre de gestion de la confidentialité Microsoft.

Résidence et souveraineté des données

Azure DevOps est disponible dans les huit emplacements géographiques suivants à travers le monde : États-Unis, Canada, Europe, Royaume-Uni, Inde, Australie, Asie Pacifique et Brésil. Par défaut, votre organisation est affectée à votre emplacement le plus proche. Toutefois, vous pouvez choisir un autre emplacement lorsque vous créez votre organisation. Si vous changez d’avis ultérieurement, vous pouvez migrer l’organisation vers un autre emplacement avec l’aide du support Microsoft.

Azure DevOps ne déplace pas ou ne réplique pas les données client en dehors de l’emplacement choisi. Au lieu de cela, vos données sont géorépliquées vers une deuxième région au sein du même emplacement. La seule exception est le Brésil, qui réplique les données vers la région USA Centre Sud à des fins de récupération d’urgence.

Remarque

Pour les builds et versions qui s’exécutent sur des agents macOS fournis par Microsoft, vos données sont transférées vers un centre de données GitHub dans le États-Unis.

Pour plus d’informations, consultez Emplacements des données pour Azure DevOps.

Accès aux forces de l’ordre

Dans certains cas, des tiers, tels que des entités d’application de la loi, peuvent approcher Microsoft pour obtenir l’accès aux données client stockées dans Azure DevOps. Nous essayons de rediriger les demandes vers le propriétaire d'organisation pour la résolution. Lorsqu’une ordonnance de justice oblige Microsoft à divulguer des données client à un tiers, Microsoft fait un effort raisonnable pour notifier l’propriétaire d'organisation à l’avance, sauf si nous sommes légalement interdits de le faire.

Certains clients ont besoin de leur stockage de données dans un emplacement géographique particulier pour garantir une juridiction juridique spécifique pour toutes les activités d’application de la loi. Toutes les données client, telles que le code source, les éléments de travail, les résultats des tests et les miroir géoredondants et les sauvegardes hors site, sont conservées dans l’un des emplacements mentionnés précédemment.

Accès Microsoft

De temps à autre, les employés de Microsoft doivent obtenir l’accès aux données client stockées dans Azure DevOps. Par précaution, tous les employés qui ont (ou peuvent avoir) accès aux données client doivent transmettre une case activée d’arrière-plan qui inclut des condamnations criminelles et d’emploi antérieures. Nous autoriseons l’accès aux systèmes de production uniquement lorsqu’il existe un incident de site en direct ou une autre activité de maintenance approuvée, qui est journalisée et surveillée.

Étant donné que toutes les données de notre système ne sont pas traitées de la même façon, nous classifions les données dans ces types :

  • Données client : ce que vous chargez dans Azure DevOps.
  • Données de l’organisation : informations que vous envoyez lors de l’inscription ou de l’administration de votre organisation.
  • Données Microsoft : informations requises pour ou collectées par le biais du service.

En fonction de la classification, nous contrôlons les scénarios d’utilisation, les exigences de géolocalisation, les restrictions d’accès et les exigences de rétention.

Utilisation promotionnelle de Microsoft

Microsoft souhaite parfois contacter les clients pour leur faire part de fonctionnalités et de services supplémentaires qui peuvent être utiles. Étant donné que tous les clients ne souhaitent pas être contactés au sujet de ces offres, vous pouvez accepter et refuser les communications par e-mail marketing.

Microsoft n’utilise jamais les données client pour cibler des offres spécifiques pour des utilisateurs ou des organisations spécifiques. Au lieu de cela, nous utilisons des données organization et agrégeons les statistiques d’utilisation au niveau organization pour déterminer les groupes qui doivent recevoir des offres spécifiques.

Renforcer la confiance

Vous pouvez être confiant dans d’autres efforts que Microsoft effectue au nom d’Azure DevOps. Ces efforts incluent des stratégies d’adoption interne chez Microsoft, le niveau de transparence dans l’état de notre service et la progression vers la réception de la certification de nos systèmes pour la gestion de la sécurité des informations.

Adoption interne

Les équipes de Microsoft adoptent Azure DevOps en interne. L’équipe Azure DevOps est passée à un organization en 2014 et l’utilise largement. Nous avons établi des directives pour permettre les plans d’adoption pour d’autres équipes.

Les grandes équipes se déplacent plus progressivement que les plus petites, en raison de leurs investissements dans les systèmes DevOps existants. Pour les équipes qui évoluent rapidement, nous avons établi une approche de classification de projet. Il évalue la tolérance au risque, en fonction des caractéristiques du projet, pour déterminer si le projet est approprié pour Azure DevOps. Pour les grandes équipes, l’adoption se produit généralement par phases, avec une planification accrue.

Les exigences supplémentaires pour les projets internes incluent l’association de l’organisation à l’ID Microsoft Entra pour garantir la complexité appropriée du cycle de vie de l’identité utilisateur et du mot de passe. Les projets plus sensibles nécessitent également une authentification à deux facteurs.

Certifications de conformité

Vous serez peut-être intéressé par la compréhension de l’évaluation tierce de nos procédures de sécurité des données. Azure DevOps a obtenu les certifications suivantes :

  • ISO 27001:2013
  • ISO 27018:2019
  • ISO 26262 :2023
  • HIPAA (Health Insurance Portability and Accountability Act)
  • Contrat d’association d’entreprise (BAA)
  • Clauses de modèle (UE)
  • Systèmes et contrôles d’organisation (SOC) 1 Type 2
  • SOC 2 Type 2
  • Allemagne C5
  • IRAP (Australie)
  • ENS-Espagne

L’audit SOC pour Azure DevOps couvre les contrôles de la sécurité, de la disponibilité, de l’intégrité du traitement et de la confidentialité des données. Les rapports SOC pour Azure DevOps sont disponibles via le portail d’approbation de services Microsoft.

Le questionnaire sur l’initiative d’évaluation de consensus (CAIQ) aide les organisations à évaluer et évaluer les pratiques de sécurité et les fonctionnalités des fournisseurs de services cloud. Conformément à notre engagement en matière de sécurité et de transparence, nous avons récemment terminé l’évaluation CAIQ pour Azure DevOps. Nous vous invitons à consulter le rapport complet sur le portail d’approbation de service Microsoft.

Étapes que vous pouvez effectuer

La protection des données appropriée nécessite un engagement actif de votre part, de vos administrateurs et de vos utilisateurs. Vos données de projet stockées dans Azure DevOps sont uniquement aussi sécurisées que les points d’accès utilisateur. Faites correspondre le niveau de rigueur et de granularité des autorisations pour ces organisations avec le niveau de sensibilité de votre projet.

Classifier vos données

La première étape consiste à classifier vos données. Classifiez les données en fonction de l’horizon de confidentialité et de risque, ainsi que les dommages qui peuvent se produire s’ils sont compromis. De nombreuses entreprises ont des méthodes de classification existantes qu’elles peuvent réutiliser lorsque les projets passent à Azure DevOps. Pour plus d’informations, vous pouvez télécharger la classification des données pour la préparation du cloud à partir de Microsoft Trustworthy Computing.

Adopter l’ID Microsoft Entra

Utilisez l’ID Microsoft Entra pour gérer l’accès de votre organisation à Azure DevOps. Microsoft Entra ID offre un autre moyen d’améliorer la sécurité des informations d’identification de vos utilisateurs.

Microsoft Entra ID permet à votre service informatique de gérer sa stratégie d’accès utilisateur, la complexité du mot de passe, les actualisations de mot de passe et l’expiration lorsque les utilisateurs quittent votre organisation. Par le biais de la fédération Active Directory, vous pouvez lier directement l’ID Microsoft Entra à l’annuaire central de votre organisation. Vous n’avez donc qu’un seul emplacement pour gérer ces détails pour votre entreprise.

Le tableau suivant compare les caractéristiques du compte Microsoft et de Microsoft Entra par rapport à l’accès Azure DevOps :

Propriété Compte Microsoft Microsoft Entra ID
Créateur d’identité Utilisateur Organisation
Nom d’utilisateur unique et mot de passe pour toutes les ressources professionnelles Non Oui
Contrôle de la durée de vie et de la complexité du mot de passe Utilisateur Organisation
Limites d’appartenance à Azure DevOps Tout compte Microsoft Répertoire de l’organisation
Identité traçable Non Oui
Propriété de l’organisation et de l’adresse IP Floue Organisation
Inscription à l’authentification à deux facteurs Utilisateur Organisation
Accès conditionnel basé sur les appareils Non Organisation

En savoir plus sur la configuration de cette prise en charge pour votre organisation.

Exiger une authentification à deux facteurs

Vous souhaiterez peut-être restreindre l’accès à votre organization en exigeant la connexion de plusieurs facteurs. Vous pouvez exiger plusieurs facteurs à l’aide de l’ID Microsoft Entra. Par exemple, vous pouvez exiger une authentification par téléphone, en plus d’un nom d’utilisateur et d’un mot de passe, pour toutes les demandes d’authentification.

Utiliser BitLocker

Pour les projets sensibles, vous pouvez utiliser BitLocker sur votre ordinateur portable Windows ou votre ordinateur de bureau. BitLocker chiffre l’ensemble du lecteur sur lequel Windows et vos données résident. Lorsque BitLocker est activé, il chiffre automatiquement tous les fichiers que vous enregistrez sur ce lecteur. Si votre ordinateur tombe entre les mauvaises mains, BitLocker empêche l’accès non autorisé des copies locales de données de vos projets.

Limiter l’utilisation d’autres informations d’identification d’authentification

Le mécanisme d’authentification par défaut pour les outils liés à Git est une autre authentification (parfois appelée authentification de base). Ce mécanisme permet à un utilisateur de configurer un autre nom d’utilisateur et mot de passe à utiliser pendant les opérations de ligne de commande Git. L’utilisateur peut utiliser cette combinaison nom d’utilisateur/mot de passe pour accéder à toutes les autres données pour lesquelles cet utilisateur dispose d’autorisations. De par leur nature, les informations d’identification d’authentification alternatives sont moins sécurisées que l’authentification fédérée par défaut.

Vous pouvez toujours faire des choix pour une sécurité accrue. Toutes les communications sont envoyées via HTTPS et il existe des exigences de complexité de mot de passe. Votre organisation doit continuer à évaluer s’il a besoin de stratégies supplémentaires pour répondre aux exigences de sécurité de vos projets.

Vous pouvez désactiver d’autres informations d’identification d’authentification si vous décidez qu’elles ne répondent pas aux exigences de sécurité de votre organisation. Pour plus d’informations, consultez Modifier les stratégies de connexion d’application et de sécurité pour votre organisation.

Sécuriser l’accès à votre organization

Administration istrators peuvent utiliser l’ID Microsoft Entra pour contrôler l’accès aux ressources et applications Azure, telles qu’Azure DevOps. Avec le contrôle d’accès conditionnel en place, l’ID Microsoft Entra case activée s pour les conditions spécifiques que vous définissez pour qu’un utilisateur accède à une application. Une fois que l’utilisateur répond aux exigences d’accès, l’utilisateur est authentifié et peut accéder à l’application.

Azure DevOps prend en charge l’application de certains types de stratégies d’accès conditionnel (par exemple, la clôture IP) pour les mécanismes d’authentification Azure DevOps personnalisés. Ces mécanismes incluent des jetons d’accès personnels, une authentification alternative, OAuth et des clés SSH (Secure Shell). Si vos utilisateurs accèdent à Azure DevOps via un client tiers, seules les stratégies IPv4 sont respectées.

Ressources supplémentaires