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 plus de services cloud, 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 sont dans quatre catégories de base : disponibilité des données, disponibilité du service, 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
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 plupart des stockages utilisés sont ce type de stockage d’objets blob non structurés.
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.
Les administrateurs 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. Les administrateurs 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 un contrat de niveau de service (SLA) de 99,9 % de temps d’activité. 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 perte accidentelle de données, Microsoft utilise des sauvegardes ponctuelles dans le temps pour les objets blob stockés dans Stockage Blob Azure et les bases de données dans Azure SQL Database. Chaque compte de stockage conserve une copie distincte de tous les objets blob, avec des modifications ajoutées aux données existantes. Ces sauvegardes sont immuables, ce qui élimine la nécessité de réécrire tout stockage existant pendant les procédures de sauvegarde.
Azure SQL Database inclut des fonctionnalités de sauvegarde standard utilisées par Azure DevOps. Vos données sont conservées pendant 28 jours, ces sauvegardes étant également répliquées dans une région jumelée pour faciliter la récupération lors d’une panne régionale.
Vous pouvez récupérer des organisations ou des projets supprimés dans la fenêtre de 28 jours après la suppression. Toutefois, une fois cette période écoulée, ces entités sont définitivement supprimées et ne peuvent pas être restaurées. Bien que ces sauvegardes servent de composant crucial pour la récupération d’urgence, il est essentiel que les clients pratiquent des stratégies appropriées de gestion et de sauvegarde des données pour garantir une protection complète de leurs données.
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.
- Dans de rares cas, notre processus de suppression peut prendre jusqu’à 70 jours en raison de nouvelles tentatives back-end et de la nécessité de supprimer des données de plusieurs sources.
La pratique est essentielle
L’utilisation de plusieurs sauvegardes de vos données est correcte, mais sans pratique, la restauration peut être imprévisible. Les gens disent 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 :
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 surveillance 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
Microsoft s’engage à garantir que vos projets restent sécurisés et sécurisés, sans exception. Dans Azure DevOps, vos projets 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. En outre, nous respectons les pratiques suivantes en ce qui concerne les informations d’identification ou les secrets qu’Azure DevOps stocke. Pour en savoir plus sur la façon de choisir le mécanisme d’authentification approprié, consultez Conseils pour l’authentification.
Important
Azure DevOps ne prend pas en charge l’authentification d’autres informations d’identification. Si vous utilisez toujours d’autres informations d’identification, nous vous encourageons vivement à passer à une méthode d’authentification plus sécurisée.
Jetons d’accès personnels (PAT)
- Nous stockons un hachage du PAT.
- Les paT bruts génèrent en mémoire côté serveur. 32 octets générés de manière aléatoire par le biais du RNGCryptoServiceProvider et sont partagés avec l’appelant en tant que chaîne encodée en base 32. Cette valeur n’est PAS stockée.
- Le hachage PAT génère en mémoire côté serveur en tant que HMACSHA256Hash du pat brut à l’aide d’une clé de signature symétrique de 64 octets stockée dans notre coffre de clés.
- Le hachage est stocké dans notre base de données.
Clés SSH (Secure Shell)
- Nous stockons un hachage de l’ID d’organisation englobant et de la clé publique SSH.
- Les clés publiques brutes sont fournies directement par l’appelant via SSL.
- Le hachage SSH génère en mémoire côté serveur en tant que HMACSHA256Hash de l’ID d’organisation et de la clé publique brute à l’aide d’une clé de signature symétrique de 64 octets stockée dans notre coffre de clés.
- Le hachage est stocké dans notre base de données.
Informations d’identification OAuth (JWTs)
- Problème d’informations d’identification OAuth en tant que jetons web JSON entièrement auto-décrivant (JWT) et ne sont pas stockés dans notre service.
- Les revendications dans les JWT émis et présentés à notre service sont validées à l’aide d’un certificat stocké dans notre coffre de clés.
Signalement des failles de sécurité
Si vous pensez que votre test d’intrusion a 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 la 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. D’autres vérifications d’authentification via une carte à puce 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 Office, 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.
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 judiciaire oblige Microsoft à divulguer des données client à un tiers, Microsoft fait un effort raisonnable pour notifier le 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 miroirs 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 ont peut-être jamais) accès aux données client doivent passer une vérification en arrière-plan qui inclut l’emploi précédent et les condamnations criminelles. 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 de l’opération 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 indiquer plus de fonctionnalités et de services susceptibles d’ê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 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.
D’autres exigences 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 susceptibles de se produire en cas de compromission. 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 d’un plus grand nombre de stratégies 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
Les administrateurs 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 vérifie 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.