Partager via

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. Sur la base des fonctionnalités locales, avec davantage de services cloud, nous gérons votre code source, vos éléments de travail, vos builds et vos tests. Azure DevOps utilise une infrastructure PaaS (Platform as a Service) et de nombreux services Azure, notamment Azure SQL, pour fournir un service fiable et disponible à l’échelle mondiale pour vos projets de développement.

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

Cet article s’adresse aux administrateurs d’organisation et aux professionnels de l’informatique qui gèrent quotidiennement les ressources de leurs projets. Il est particulièrement utile aux personnes qui connaissent déjà Azure DevOps et souhaitent en savoir plus sur la manière dont Microsoft protège les ressources stockées dans Azure DevOps.

Notre engagement

Microsoft vous aide à garantir la sécurité de vos projets, 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 garantissons la confidentialité et l’intégrité des données au repos et en transit.

Les menaces auxquelles vous êtes confronté se répartissent en quatre catégories principales : disponibilité des données, disponibilité des services, sécurité des services et confidentialité des données. Cet article explore les menaces spécifiques à chaque catégorie et explique comment Azure DevOps les traite. Il 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 non autorisée et la falsification. Soyez explicite lorsque vous accordez des permissions aux points d’accès utilisateur, afin que seules les personnes autorisées puissent accéder aux données dans Azure DevOps.

Vous devez considérer toutes les données potentiellement à risque, quel que soit l’emplacement où elles se trouvent ou la façon dont elles sont utilisées. Cette instruction s’applique aussi bien aux données stockées dans le cloud qu’aux données stockées dans un centre de données privé. Il est important de classer vos données, leur sensibilité et leur risque, ainsi que les dommages qu’elles pourraient causer si elles étaient compromises. Classez également vos données par rapport à une stratégie globale de gestion de la sécurité des informations.

Basée sur Azure

Diagramme de l’architecture de haut niveau d’Azure DevOps.

Nous hébergeons Azure DevOps entièrement dans des centres de données Azure. Azure DevOps utilise de nombreux services Azure de base, notamment la capacité de calcul, le stockage, la mise en réseau, Azure SQL, la gestion des identités et des accès, ainsi qu’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 en matière de stockage et de récupération, Azure DevOps utilise Azure Blob Storage et Azure SQL Database Storage.

Pour vous aider à comprendre l’approche d’Azure DevOps Services en matière de protection des données, voici quelques informations générales sur les services de stockage :

  • Azure Blob Storage stocke de gros segments 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 majeure partie du stockage utilisé est ce type de stockage blob non structuré.

  • Azure SQL Database stocke les aspects structurés et transactionnels de votre organisation, y compris les métadonnées de projet, l’historique de contrôle de source versionné et les détails des éléments de travail Le stockage de base de données vous offre un accès rapide aux éléments importants de votre projet Il fournit des index dans le stockage 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 les permissions sur les identités ou les groupes d’utilisateurs. Azure DevOps utilise l’authentification fédérée des identités utilisateur via Microsoft Entra ID et les comptes Microsoft.

Lors de l’authentification, l’utilisateur est redirigé vers le fournisseur d’authentification, où il fournit ses informations d’identification. Une fois que le fournisseur d’authentification a vérifié 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 manière, les informations d’identification de l’utilisateur ne sont jamais partagées directement avec Azure DevOps. Pour chaque ressource Azure DevOps à laquelle l’utilisateur tente d’accéder, la validation des permissions est basée sur les permissions explicites de l’utilisateur et sur les permissions dont il a hérité via son appartenance à un groupe.

Les administrateurs peuvent utiliser les contrôles d’accès pour protéger l’accès à l’organisation, aux collections de projets, aux projets d’équipe et aux données et fonctionnalités au niveau de l’équipe. Les administrateurs peuvent également utiliser les contrôles d’accès pour des ressources spécifiques telles que les 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 d’Azure Storage pour garantir la disponibilité des données en cas de panne matérielle, d’interruption de service ou de sinistre régional. En outre, l’équipe Azure DevOps suit des procédures visant à protéger les données contre toute suppression accidentelle ou malveillante.

Redondance des données

Pour aider à protéger les données en cas de panne matérielle ou de service, Azure Storage géo-réplique les données des clients entre deux régions situées dans la même zone géographique. Par exemple, Azure Storage peut géo-répliquer des données entre l’Europe du Nord et l’Europe de l’Ouest ou entre le nord et le sud des États-Unis.

Pour Azure Blob Storage, les données des clients sont répliquées trois fois dans une seule région. Les données des clients sont répliquées de manière asynchrone vers une deuxième région située dans la même zone géographique. Ainsi, Azure conserve toujours l’équivalent de six copies de vos données.

Le fait de disposer de plusieurs copies vous permet de basculer vers une région distincte en cas de panne majeure ou de sinistre, tout en bénéficiant d’une redondance locale en cas de défaillance matérielle au sein d’une région. Pour le stockage Azure SQL Database, des sauvegardes quotidiennes sont conservées hors site en cas de sinistre régional.

En ce qui concerne la redondance des données et le basculement :

  • Il existe un décalage 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 elle affecte tous les clients d’une unité d’échelle particulière. Sauf dans des circonstances extrêmes, Microsoft choisit d'éviter le basculement afin que les données des clients ne soient pas perdues.
  • Azure DevOps offre un contrat de niveau de service (SLA) garantissant une disponibilité de 99,9 %. Azure DevOps rembourse une partie des frais mensuels si ce contrat SLA n’est pas respecté au cours d’un mois donné.
  • Comme il n’y a qu’une seule région au Brésil, les données des clients brésiliens sont répliquées dans la région Centre-Sud des États-Unis à des fins de reprise après sinistre.

Des erreurs peuvent survenir

Pour se prémunir contre toute perte accidentelle de données, Microsoft utilise des sauvegardes ponctuelles pour les blobs stockés dans Azure Blob Storage et les bases de données dans Azure SQL Database. Chaque compte de stockage conserve une copie distincte de tous les blobs, les modifications étant ajoutées aux données existantes. Ces sauvegardes sont immuables, ce qui élimine le besoin de réécrire le 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, et ces sauvegardes sont également répliquées dans une région appairée afin de faciliter la récupération en cas de panne régionale.

Vous pouvez récupérer les organisations ou les projets supprimés dans les 28 jours suivant leur suppression. Cependant, une fois ce délai écoulé, ces entités sont définitivement supprimées et ne peuvent plus être restaurées. Bien que ces sauvegardes constituent un élément essentiel de la reprise après sinistre, il est essentiel que les clients mettent en œuvre des stratégies appropriées de gestion et de sauvegarde des données afin de garantir une protection complète de leurs données.

Importante

  • La suppression accidentelle fait ici référence aux scénarios résultant d’un incident sur nos services. Cela n’inclut pas la suppression accidentelle de ressources par les clients (par exemple, des référentiels, des éléments de travail, des pièces jointes ou des artefacts).
  • Nous ne prenons pas en charge la restauration des ressources supprimées accidentellement par les clients. Ces sauvegardes sont uniquement destinées à assurer la continuité des activités et à faciliter la reprise après une panne ou une catastrophe.
  • Dans de rares cas, notre processus de suppression peut prendre jusqu’à 70 jours en raison de nouvelles tentatives du backend et de la nécessité de supprimer les données de plusieurs sources.

La pratique est essentielle

Il est judicieux de disposer de plusieurs sauvegardes de vos données, mais sans pratique, la restauration peut s’avérer imprévisible. On dit souvent que « les sauvegardes ne tombent jamais en panne, ce sont les restaurations qui échouent ». Bien que cette instruction soit techniquement incorrecte, le sentiment est juste.

Microsoft pratique régulièrement la restauration d’ensembles de données à partir de sauvegardes. Nous testons régulièrement le stockage géo-redondant à 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 les attaques par déni de service distribué (DDoS) et une réponse en direct du site pour vous garantir l’accès à votre organisation et aux ressources associées.

Protections contre les attaques 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 aide à prévenir les attaques contre notre service. Azure utilise des techniques de détection et d'atténuation standard, telles que les cookies SYN, les seuils limites et les limites de connexion. Le système est conçu pour résister aux attaques venues de l'extérieur et des autres clients dans Azure.

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

Réponse en direct sur le site

Dans de rares cas, vous pouvez avoir besoin d’une réponse en direct sur le site pour résoudre un problème de disponibilité du service. Nous disposons d’une équipe opérationnelle disponible en permanence pour identifier rapidement le problème et mobiliser les ressources nécessaires de l’équipe de développement.

Les ressources de l’équipe de développement s’occupent ensuite du problème. Elles s’efforcent également de mettre à jour la page d’état du service dans les minutes qui suivent la détection d’un problème affectant le service. Une fois qu’elles ont résolu un problème, elles identifient la cause première et suivent les modifications nécessaires pour éviter que des problèmes similaires ne se reproduisent à l’avenir.

Les processus Azure DevOps pour la gestion de sites en direct se concentrent sur votre expérience et l’intégrité du service. Ces processus réduisent le temps nécessaire pour détecter, répondre et atténuer les problèmes. Toutes les disciplines d’ingénierie sont impliquées et responsables, de sorte que des améliorations continues découlent de l’expérience directe. Les processus de surveillance, de diagnostic, de résilience et d’assurance qualité s’améliorent ensuite au fil du temps.

La gestion de sites en direct dans Azure DevOps comporte trois volets distincts : la télémétrie, la gestion des incidents et la révision des sites en direct. Voici ce que ces volets impliquent :

Image du processus Azure DevOps Services pour la gestion de sites en direct.

L’équipe des opérations surveille également les mesures de disponibilité pour chaque organisation. Ces mesures fournissent des aperçus des conditions spécifiques susceptibles d’affecter uniquement certains de nos clients. L’analyse de ces données permet souvent d’apporter des améliorations ciblées afin de résoudre les problèmes spécifiques aux clients. Dans certains cas, Microsoft peut même vous contacter directement pour comprendre votre expérience et collaborer avec vous afin d’améliorer le service.

Microsoft publie un contrat SLA et fournit une garantie financière afin de garantir le respect de cet accord chaque mois. Pour plus d’informations, consultez Contrat SLA pour Azure DevOps.

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

Sécurité du service

La sécurité du service nécessite une vigilance constante, depuis la conception et les techniques de codage appropriées jusqu’aux facteurs opérationnels. Microsoft investit activement dans la prévention des failles de sécurité et la détection des violations. En cas de violation, Microsoft utilise des plans d’intervention de sécurité pour minimiser les fuites, les pertes ou la corruption des données. Pour plus d’informations, consultez À propos de la sécurité, de l’authentification et de l’autorisation.

Sécurité dès la conception

Azure DevOps est conçu pour être sécurisé. Azure DevOps utilise le cycle de vie de 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’exploitation du cloud dans Azure DevOps.

L’équipe Azure DevOps impose des exigences de formation annuelle à tous les ingénieurs et au personnel d’exploitation. Elle parraine également des réunions informelles organisées par des ingénieurs Microsoft. Une fois qu’elle a résolu un problème soulevé lors d’une réunion, l’équipe partage les enseignements tirés avec les autres équipes.

Les méthodologies suivantes spécifient les exigences en matière de formation :

  • Modélisation des menaces pendant la conception du service
  • Respect des meilleures pratiques en matière de conception et de code
  • Vérification de la sécurité à l’aide d’outils et de tests standard
  • Limitation de l’accès aux données opérationnelles et client
  • Gating rollout of new features through a rigid approval process (processus d'approbation rigide)

La sécurité d’un service cloud dépend de celle de la plateforme hôte. Azure DevOps utilise PaaS pour une grande partie de son infrastructure. PaaS fournit automatiquement des mises à jour régulières des failles de sécurité connues.

Les machines virtuelles hébergées dans Azure utilisent l’infrastructure en tant que service (IaaS), par exemple pour un service de compilation hébergé. Ces images reçoivent des mises à jour régulières afin d’inclure les derniers correctifs de sécurité disponibles via Windows Update. La même rigueur en matière 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 de pénétration tentent d’exploiter les services de production en direct et l’infrastructure d’Azure DevOps en utilisant les mêmes techniques et mécanismes que ceux utilisés par des attaquants malveillants. L’objectif est d’identifier les vulnérabilités, les configurations, les erreurs ou autres failles de sécurité réelles dans un processus contrôlé.

L’équipe examine les résultats de ces tests afin d’identifier d’autres domaines à améliorer et d’augmenter la qualité des systèmes préventifs et de la formation. Vous pouvez consulter les résultats des derniers tests de pénétration Azure DevOps sur le portail Microsoft Service Trust.

Sécurité des informations d’identification

Microsoft s’engage à garantir la sécurité et la confidentialité de vos projets, sans exception. Dans Azure DevOps, vos projets bénéficient de plusieurs couches de technologies de sécurité et de gouvernance, ainsi que de pratiques opérationnelles et de stratégies de conformité. Nous garantissons la confidentialité et l’intégrité des données au repos et en transit. Nous respectons également les pratiques suivantes concernant les informations d’identification ou les secrets stockés par Azure DevOps. Pour en savoir plus sur le choix du mécanisme d’authentification approprié, consultez les conseils d’authentification.

Importante

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ûre.

Jetons d’accès personnels (PAT)

  • Nous stockons un hachage du PAT.
  • Les jetons PAT bruts sont générés en mémoire côté serveur. 32 octets sont générés de manière aléatoire via RNGCryptoServiceProvider et partagés avec l’appelant sous la forme d’une chaîne codée en base 32. Cette valeur n’est pas stockée.
  • Le hachage PAT est généré en mémoire côté serveur sous la forme d’un HMACSHA256Hash du PAT brut à l’aide d’une clé de signature symétrique de 64 octets stockée dans notre coffre-fort de clés.
  • Le hachage est stocké dans notre base de données.

Clés Secure Shell (SSH)

  • Nous stockons également un hachage de l’identifiant de l’organisation englobante et de la clé publique SSH.
  • Les clés publiques brutes sont fournies directement par l’appelant via SSL.
  • Le hachage SSH est généré en mémoire côté serveur sous la forme d’un HMACSHA256Hash de l’ID de l’organisation et de la clé publique brute à l’aide d’une clé de signature symétrique de 64 octets stockée dans notre coffre-fort de clés.
  • Le hachage est stocké dans notre base de données.

Informations d’identification OAuth (JWT)

  • Les informations d’identification OAuth sont émises sous la forme de jetons Web JSON (JWT) entièrement auto-descriptifs et ne sont pas stockées 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-fort de clés.

Signalement des failles de sécurité

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

Importante

Bien que vous ne soyez pas tenu d’informer Microsoft de vos activités de test d’intrusion, vous devez respecter les règles d’engagement relatives à ces tests.

Programme de prime :

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 à contribuer à la sécurité d’Azure DevOps. Pour plus d’informations, consultez le programme de prime Microsoft Azure DevOps.

Restriction de l’accès

Microsoft contrôle strictement l’accès à son environnement de production et aux données de ses clients. Nous n’accordons l’accès qu’au niveau de privilège le plus bas requis, et uniquement après vérification des justifications de l’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 suivons et surveillons les requêtes d’accès et les approbations dans un système distinct. Tous les accès au système sont corrélés à ces approbations. Si nous détectons un accès non approuvé, nous alertons l’équipe des opérations afin qu’elle mène une enquête.

Nous utilisons l’authentification à deux facteurs pour tous les accès à distance au système. Si le nom d’utilisateur et le mot de passe d’un de nos développeurs ou membres 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 vers un numéro préapprouvé doivent être effectuées avant que nous autorisions tout accès à distance au service.

Pour gérer et maintenir le service, Microsoft utilise des secrets tels que des mots de passe RDP, des certificats SSL et des clés de chiffrement. Tous ces secrets sont gérés, stockés et transmis de manière sécurisée via le portail Azure. Tout accès à ces secrets nécessite une autorisation spécifique consignée et enregistrée de manière sécurisée. Tous les secrets sont remplacés à intervalles réguliers et nous pouvons également les remplacer à la demande en cas d’incident 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 logique segmenté.

Les membres de l’équipe des opérations doivent fournir des informations d’identification spécifiques, ainsi qu’une authentification à deux facteurs, pour accéder aux stations de travail. Tous les accès sont surveillés et consignés de manière sécurisée. Afin d’isoler le service de toute altération externe, nous n’autorisons pas les applications telles qu’Outlook et Office, car elles sont souvent la cible d’attaques par spear phishing et d’autres types d’attaques.

Protection contre les intrusions et réponse

Nous chiffrons les données via HTTPS et SSL pour garantir qu’elles ne soient pas interceptées ou modifiées lors de leur transfert entre vous et Azure DevOps. Les données que nous stockons pour vous dans Azure DevOps sont chiffrées de la manière suivante :

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

  • Les connexions Azure Blob Storage sont chiffrées pour protéger vos données en transit. Pour les données stockées en mémoire dans Azure Blob Storage, 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 garantir la légitimité des activités au sein du service et de détecter les violations ou les tentatives de violation.

Toutes les activités de déploiement et d’administration sont consignées de manière sécurisée, tout comme l’accès des opérateurs au stockage de production. Les informations des journaux d’activité sont automatiquement analysées et des alertes en temps réel sont déclenchées en cas de comportement potentiellement malveillant ou non autorisé.

Lorsque l’équipe Azure DevOps identifie une intrusion potentielle ou une vulnérabilité de sécurité hautement prioritaire, elle dispose d’un plan d’intervention clair. Ce plan définit les parties responsables, les mesures à prendre pour sécuriser les données des clients et les instructions à suivre pour contacter les experts en sécurité de Microsoft. L’équipe informe également les propriétaires de l’organisation en cas de divulgation ou de corruption de donné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 d’hypothèse de violation. Une équipe hautement spécialisée d’experts en sécurité de Microsoft joue le rôle d’adversaires sophistiqués. Cette équipe teste la détection et la réponse aux violations afin d’évaluer avec précision l’état de préparation et l’impact des attaques réelles. Cette stratégie renforce la détection des menaces, la réponse et la défense du service. Elle permet également à l’équipe de valider et d’améliorer l’efficacité de l’ensemble du programme de sécurité.

Protection contre les ransomwares

Azure DevOps utilise les contrôles Azure pour aider à prévenir, détecter et répondre à une telle attaque. Pour en savoir plus sur la manière dont Azure protège les clients contre les ransomwares, consultez la page Protection contre les ransomwares dans Azure.

Confidentialité des données

Vous devez avoir l’assurance que nous traitons vos données de manière appropriée et à des fins légitimes. Cette assurance passe notamment par une restriction rigoureuse de l’utilisation des données.

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 la plus grande évolution des lois sur la protection des données en Europe depuis l’introduction, en 1995, de la directive 95/46/CE sur la protection des données de l’Union européenne (UE). Pour plus d’informations sur le RGPD, consultez la page de présentation dans le Centre de confiance Microsoft.

Résidence et souveraineté des données

Azure DevOps est disponible dans les huit zones géographiques suivantes : États-Unis, Canada, Europe, Royaume-Uni, Inde, Australie, Asie-Pacifique et Brésil. Par défaut, votre organisation est affectée à la zone la plus proche. Toutefois, vous pouvez sélectionner un autre emplacement lors de la création de 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 ni ne réplique les données client en dehors de l’emplacement sélectionné. Vos données sont plutôt géo-répliquées vers une deuxième région au sein de la même emplacement. La seule exception concerne le Brésil, où les données sont répliquées dans la région Centre-Sud des États-Unis à des fins de reprise après sinistre.

Remarque

Pour les builds et les 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 aux États-Unis.

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

Accès des autorités chargées de l’application de la loi

Dans certains cas, des tiers tels que les autorités chargées de l’application de la loi peuvent contacter Microsoft afin d’obtenir l’accès aux données client stockées dans Azure DevOps. Nous essayons de rediriger les requêtes vers le propriétaire de l’organisation pour qu’il puisse résoudre la situation. Lorsqu’une décision de justice oblige Microsoft à divulguer les données d’un client à un tiers, Microsoft fait tout son possible pour en informer le propriétaire de l’organisation à l’avance, sauf si la loi nous l’interdit.

Certains clients exigent que leurs données soient stockées dans une zone géographique particulière afin de garantir une juridiction spécifique en cas d’activité d’application de la loi. Toutes les données client, telles que le code source, les éléments de travail, les résultats de test, les miroirs géo-redondants 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 accéder aux données client stockées dans Azure DevOps. Par mesure de précaution, tous les employés qui ont (ou pourraient avoir) accès aux données des clients doivent se soumettre à une vérification de leurs antécédents, notamment en matière d’emploi et de condamnations pénales. Nous n’autorisons l’accès aux systèmes de production qu’en cas d’incident sur un site en ligne ou d’autre activité de maintenance approuvée, consignée et surveillée.

Étant donné que toutes les données de notre système ne sont pas traitées de la même manière, nous les classons dans les types suivants :

  • les données client, c’est-à-dire les données que vous chargez sur Azure DevOps ;
  • les données d’organisation, c’est-à-dire les informations que vous soumettez lorsque vous vous inscrivez ou administrez votre organisation ;
  • Données Microsoft : informations requises pour le fonctionnement du service ou collectées dans le cadre de celui-ci.

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 conservation.

Promotion par Microsoft

Microsoft peut occasionnellement contacter ses clients pour les informer de fonctionnalités et de services supplémentaires susceptibles de les intéresser. Étant donné que tous les clients ne souhaitent pas être contactés à propos de ces offres, vous pouvez choisir de recevoir ou non des communications marketing par e-mail.

Microsoft n’utilise jamais les données client pour cibler des offres spécifiques à des utilisateurs ou des organisations. Nous utilisons plutôt les données de l’organisation et les statistiques d’utilisation agrégées au niveau de l’organisation pour déterminer les groupes qui devraient recevoir des offres spécifiques.

Gestion des stratégies de confidentialité pour les administrateurs afin de contrôler la collecte des commentaires des utilisateurs

La fonctionnalité bascule de commentaires permet aux propriétaires d’organisations Azure DevOps de contrôler si les utilisateurs sont invités à fournir des commentaires et à les envoyer. Cette fonctionnalité est essentielle pour garantir que les pratiques de commentaires s’alignent sur les stratégies de confidentialité et de gouvernance de votre organisation.

Renforcement de la confiance

Vous pouvez également avoir confiance dans les autres efforts déployés par Microsoft au nom d’Azure DevOps. Ces efforts comprennent les stratégies d’adoption interne chez Microsoft, le niveau de transparence sur l’état de notre service et les progrès réalisés en vue de l’obtention de la certification de nos systèmes de gestion de la sécurité des informations.

Adoption interne

Les équipes Microsoft adoptent Azure DevOps en interne. L’équipe Azure DevOps a intégré une organisation en 2014 et utilise largement cette solution. Nous avons établi des directives pour permettre à d’autres équipes d’adopter cette solution selon des plans adaptés.

Les grandes équipes évoluent plus progressivement que les petites, en raison des investissements qu’elles ont réalisés dans les systèmes DevOps existants. Pour les équipes qui évoluent rapidement, nous avons mis en place une approche de classification des projets. Cette approche évalue la tolérance au risque en fonction des caractéristiques du projet afin de déterminer si celui-ci est adapté à Azure DevOps. Pour les équipes plus importantes, l’adoption se fait généralement par étapes, avec une planification plus poussée.

Les projets internes doivent également respecter d’autres exigences, notamment s’associer à Microsoft Entra ID pour garantir le cycle de vie approprié des identités utilisateur et la complexité des mots de passe. Les projets plus sensibles nécessitent également une authentification à deux facteurs.

Certifications de conformité

Vous souhaiterez peut-être connaître l’évaluation de nos procédures de sécurité des données par un organisme tiers. Azure DevOps a obtenu les certifications suivantes :

  • ISO 27001:2022
  • ISO 27018:2019
  • ISO 26262:2023
  • HIPAA (Health Insurance Portability and Accountability Act)
  • Contrat d’association d’entreprise (BAA)
  • Clauses de modèle (UE)
  • Contrôles des systèmes et de l’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 relatifs à la sécurité, à la disponibilité, à l’intégrité du traitement et à la confidentialité des données. Les rapports SOC pour Azure DevOps sont disponibles via le Microsoft Service Trust Portal.

Le questionnaire CAIQ (Consensus Assessment Initiative Questionnaire) aide les organisations à évaluer les pratiques et les capacités des fournisseurs de services cloud en matière de sécurité. Conformément à notre engagement en faveur de la sécurité et de la transparence, nous avons récemment achevé l’évaluation CAIQ pour Azure DevOps. Nous vous invitons à consulter le rapport complet sur le Microsoft Service Trust Portal.

Voici les mesures que vous pouvez prendre :

Une protection adéquate des données nécessite une participation active de votre part ainsi que de celle de vos administrateurs et utilisateurs. La sécurité des données de votre projet stockées dans Azure DevOps dépend du niveau de sécurité des points d’accès des utilisateurs. Adaptez le niveau de rigueur et de granularité des permissions pour ces organisations en fonction du niveau de sensibilité de votre projet.

Classifier vos données

La première étape consiste à classer vos données. Classez les données en fonction de leur sensibilité et de leur horizon de risque, ainsi que des dommages qui pourraient survenir en cas de compromission. De nombreuses entreprises disposent déjà de méthodes de classification qu’elles peuvent réutiliser lorsque leurs projets migrent vers Azure DevOps. Pour plus d’informations, vous pouvez télécharger le document Classification des données pour la préparation au cloud à partir de Microsoft Trustworthy Computing.

Adoptez Microsoft Entra ID

Utilisez Microsoft Entra ID 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é des mots de passe, leur actualisation et leur expiration lorsque les utilisateurs quittent votre organisation. Grâce à la fédération Active Directory, vous pouvez lier directement Microsoft Entra ID au répertoire central de votre organisation, de sorte que vous ne disposez que d’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 (système d'identification de Microsoft)
Créateur d’identité Utilisateur Organisation
Nom d’utilisateur et mot de passe uniques pour toutes les ressources professionnelles Non Oui
Contrôle de la durée de vie et de la complexité des mots de passe Utilisateur Organisation
Limites d’adhésion à 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 Manque de clarté 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 pouvez restreindre l’accès à votre organisation en exigeant plusieurs facteurs pour la connexion. Vous pouvez exiger plusieurs facteurs à l’aide de Microsoft Entra ID. 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 requêtes d’authentification.

Utiliser BitLocker

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

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

Le mécanisme d’authentification par défaut pour les outils liés à Git est l’authentification alternative (parfois appelée authentification de base). Ce mécanisme permet à un utilisateur de configurer un nom d’utilisateur et un mot de passe alternatifs à utiliser lors des 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 il dispose des permissions. De par leur nature, les informations d’identification d’authentification alternative sont moins sécurisées que l’authentification fédérée par défaut.

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

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

Sécuriser l’accès à votre organisation

Les administrateurs peuvent utiliser Microsoft Entra ID pour contrôler l’accès aux ressources et aux applications Azure, telles qu’Azure DevOps. Grâce au contrôle d’accès conditionnel, Microsoft Entra ID vérifie les conditions spécifiques que vous avez définies pour qu’un utilisateur puisse accéder à une application. Une fois que l’utilisateur remplit les conditions d’accès, il 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, le cloisonnement IP) pour les mécanismes d’authentification Azure DevOps personnalisés. Ces mécanismes incluent les jetons d’accès personnels, l’authentification alternative, OAuth et les clés Secure Shell (SSH). Si vos utilisateurs accèdent à Azure DevOps via un client tiers, seules les stratégies basées sur IPv4 sont respectées.

Plus de ressources