Overzicht van gegevensbescherming

Azure DevOps Services

Azure DevOps Services is een in de cloud gehoste toepassing voor uw ontwikkelprojecten, van planning tot implementatie. Op basis van de on-premises mogelijkheden, met aanvullende cloudservices, beheren we uw broncode, werkitems, builds en tests. Azure DevOps maakt gebruik van PaaS-infrastructuur (Platform as a Service) en veel Azure-services, waaronder Azure SQL, om een betrouwbare, wereldwijd beschikbare service te leveren voor uw ontwikkelprojecten.

In dit artikel worden de stappen besproken die Microsoft neemt om uw projecten veilig, beschikbaar, veilig en privé te houden. Hierin wordt de rol beschreven die u speelt bij het veilig en veilig houden van uw projecten.

Dit artikel is bedoeld voor organisatiebeheerders en IT-professionals die hun projectassets dagelijks beheren. Het is het handigst voor personen die al bekend zijn met Azure DevOps en meer willen weten over hoe Microsoft opgeslagen assets in Azure DevOps beveiligt.

Onze commitment

Microsoft helpt ervoor te zorgen dat uw projecten veilig en veilig blijven, zonder uitzondering. Wanneer u uw projecten opslaat in Azure DevOps, profiteren ze van meerdere beveiligings- en governancetechnologieën, operationele procedures en nalevingsbeleid. We dwingen privacy en integriteit van gegevens af, zowel at-rest als in transit.

De bedreigingen die u ondervindt, komen overeen met vier basiscategorieën: beschikbaarheid van gegevens, servicebeschikbaarheid, servicebeveiliging en gegevensprivacy. In dit artikel worden specifieke bedreigingen binnen elke categorie verkend en wordt uitgelegd wat Azure DevOps doet om deze te verhelpen. Het artikel begint met een beschrijving van hoe gegevens worden opgeslagen en hoe Azure DevOps de toegang tot uw gegevens beheert.

Voor gegevensbescherming zijn beheerders en gebruikers die weten welke stappen moeten worden uitgevoerd om uw assets te beschermen tegen onbevoegde openbaarmaking en manipulatie. Wees expliciet wanneer u machtigingen verleent aan gebruikerstoegangspunten, zodat alleen de juiste personen toegang hebben tot gegevens in Azure DevOps.

U moet rekening houden met alle gegevens die mogelijk risico lopen, ongeacht waar deze zich bevinden of hoe ze worden gebruikt. Deze bewering geldt voor zowel gegevens die zijn opgeslagen in de cloud als gegevens die zijn opgeslagen in een privédatacenter. Het is belangrijk om uw gegevens, de vertrouwelijkheid en het risico ervan te classificeren en de schade die het kan veroorzaken als deze wordt aangetast. Categoriseer ook uw gegevens ten opzichte van een algemeen beleid voor het beheren van informatiebeveiliging.

Gebouwd op Azure

Diagram of the high-level architecture of Azure DevOps.

Azure DevOps wordt volledig gehost in Azure-datacenters. Azure DevOps maakt gebruik van veel kernservices van Azure, waaronder compute, opslag, netwerken, Azure SQL, identiteits- en toegangsbeheer en Azure Service Bus.

Azure DevOps gebruikt Azure Storage als de primaire opslagplaats voor servicemetagegevens en klantgegevens. Afhankelijk van het type gegevens en de opslag- en ophaalvereisten, maakt Azure DevOps gebruik van Azure Blob Storage en Azure SQL Database-opslag.

Hier volgt een aantal achtergrondinformatie over de opslagservices om inzicht te hebben in de benadering van Azure DevOps Services voor gegevensbeveiliging:

  • In Azure Blob Storage worden grote segmenten van ongestructureerde gegevens opgeslagen. Alle projecten gebruiken deze service. Gegevens omvatten mogelijk gevoelige of privégegevens, zoals de inhoud van bronbestanden en bijlagen voor werkitems. Voor de meeste projecten is het merendeel van de opslag die in gebruik is, dit type ongestructureerde blob-opslag.

  • Azure SQL Database slaat de gestructureerde en transactionele aspecten van uw organisatie op, waaronder projectmetagegevens, de versiegeschiedenis van broncodebeheer en details van werkitems. Met databaseopslag hebt u snel toegang tot de belangrijke elementen van uw project. Het biedt indexen in de blobopslag om bestanden en bijlagen op te zoeken.

Beheer istrators kunnen de toegang tot resources beheren door machtigingen voor gebruikersidentiteiten of -groepen toe te kennen of te beperken. Azure DevOps maakt gebruik van federatieve verificatie van gebruikersidentiteiten via Microsoft Entra ID en Microsoft-accounts.

Tijdens verificatie wordt de gebruiker doorgestuurd naar de verificatieprovider, waar ze hun referenties opgeven. Nadat de verificatieprovider de referenties van de gebruiker heeft geverifieerd, geeft Azure DevOps een verificatiecooky uit aan de gebruiker. Met deze cookie kan de gebruiker worden geverifieerd bij Azure DevOps.

Op deze manier worden de referentiegegevens van de gebruiker nooit rechtstreeks gedeeld met Azure DevOps. Voor elke Azure DevOps-resource waartoe de gebruiker toegang probeert te krijgen, is validatie van machtigingen gebaseerd op de expliciete machtigingen van de gebruiker en op machtigingen die de gebruiker heeft overgenomen via groepslidmaatschap.

Beheer istrators kunnen toegangsbeheer gebruiken om de toegang tot de organisatie, projectverzamelingen, teamprojecten en gegevens en functionaliteit binnen het teambereik te beveiligen. Beheer istrators kunnen ook toegangsbeheer gebruiken voor specifieke assets, zoals mappen voor versiebeheer en gebiedspaden voor werkitems.

Beschikbaarheid van gegevens

Azure DevOps maakt gebruik van veel Azure Storage-functies om de beschikbaarheid van gegevens te garanderen als er een hardwarestoring, serviceonderbreking of regionale noodgeval is. Het Azure DevOps-team volgt ook procedures om gegevens te beschermen tegen onbedoelde of schadelijke verwijdering.

Gegevensredundantie

Azure Storage repliceert klantgegevens tussen twee regio's in dezelfde geografische locatie om gegevens tijdens hardware- of servicefouten te beschermen. Azure Storage kan bijvoorbeeld gegevens geo-repliceren tussen Noord- en West-Europa of tussen Noord- en Zuid-Verenigde Staten.

Voor Azure Blob Storage worden klantgegevens drie keer binnen één regio gerepliceerd. Klantgegevens worden asynchroon gerepliceerd naar een tweede regio in dezelfde geografische locatie. Als zodanig onderhoudt Azure altijd het equivalent van zes kopieën van uw gegevens.

Als u meerdere exemplaren hebt, kunt u een failover naar een afzonderlijke regio uitvoeren als er sprake is van een grote storing of noodgeval, terwijl u ook lokale redundantie hebt voor hardwarefouten in een regio. Voor Azure SQL Database-opslag worden dagelijkse back-ups offsite onderhouden als er sprake is van een regionale ramp.

Met betrekking tot gegevensredundantie en failover:

  • Er is een inherente delta, gemeten in minuten, wanneer Microsoft uw gegevens repliceert tussen de primaire en secundaire regio.
  • Failover naar de secundaire regio is een beslissing die Microsoft centraal moet nemen, omdat dit van invloed is op alle klanten op een bepaalde schaaleenheid. Behalve in extreme omstandigheden kiest Microsoft ervoor om failover te voorkomen, zodat klantgegevens niet verloren gaan.
  • Azure DevOps biedt een SLA-garantie (serviceniveau) van 99,9 procent uptime. Azure DevOps retourneert een deel van de maandelijkse kosten als deze SLA in een specifieke maand mist.
  • Omdat er slechts één regio in Brazilië is, worden klantgegevens in Brazilië gerepliceerd naar de regio VS - zuid-centraal voor herstel na noodgevallen.

Fouten treden op

Om te voorkomen dat gegevens per ongeluk worden verwijderd, maakt Microsoft ook gebruik van back-ups van zowel de blobs in Azure Blob Storage als de databases in Azure SQL Database. Er is een afzonderlijke kopie van alle blobs en wijzigingen worden toegevoegd aan elk opslagaccount. Omdat deze gegevens onveranderbaar zijn, hoeft u geen bestaande opslag opnieuw te schrijven als onderdeel van de back-upprocedures.

Back-ups zijn een standaardonderdeel van Azure SQL Database en Azure DevOps maakt gebruik van deze mogelijkheid. We onderhouden uw gegevens gedurende 28 dagen. Deze back-ups worden ook gerepliceerd in een gekoppelde regio, om te helpen bij het herstellen van een regionale storing.

Klanten kunnen hun verwijderde organisaties of projecten tot 28 dagen na verwijdering herstellen. Na 28 dagen worden deze organisaties en projecten definitief verwijderd en kunnen ze niet meer worden hersteld.

Belangrijk

Onbedoeld verwijderen hier verwijst naar scenario's die zich voordoen als gevolg van een incident op onze services. Het bevat niet het onbedoeld verwijderen van assets van klanten (bijvoorbeeld opslagplaatsen, werkitems, bijlagen of artefacten).

We bieden geen ondersteuning voor het herstellen van assets die klanten per ongeluk verwijderen. Deze back-ups zijn alleen bedoeld voor bedrijfscontinuïteit en ter ondersteuning van herstel na storingen of noodscenario's.

Praktijk is essentieel

Het herstellen van meerdere back-ups van uw gegevens is goed, maar zonder de praktijk kan het herstellen onvoorspelbaar zijn. Er wordt gezegd dat back-ups nooit mislukken; de herstelbewerkingen wel. Hoewel de instructie technisch onjuist is, is het gevoel juist.

Microsoft werkt regelmatig met het herstellen van gegevenssets vanuit een back-up. We testen regelmatig geografisch redundante opslag vanuit Azure. Er zijn veel combinaties van scenario's voor noodgeval en beschadiging van gegevens. We blijven regelmatig nieuwe tests voor deze scenario's plannen en uitvoeren.

Beschikbaarheid van service

Azure DevOps biedt DDoS-beveiliging (Distributed Denial-of-Service) en live site-respons om ervoor te zorgen dat u toegang hebt tot uw organisatie en bijbehorende assets.

DDoS-beveiligingen

In sommige gevallen kan een schadelijke DDoS-aanval van invloed zijn op de beschikbaarheid van de service. Azure heeft een DDoS-verdedigingssysteem waarmee aanvallen tegen onze service worden voorkomen. Het maakt gebruik van standaarddetectie- en beperkingstechnieken zoals SYN-cookies, frequentiebeperking en verbindingslimieten. Het systeem is ontworpen om aanvallen van buitenaf, maar ook vanuit Azure te weerstaan.

Voor toepassingsspecifieke aanvallen die de Azure-verdedigingssystemen kunnen binnendringen, brengt Azure DevOps quota en beperkingen op toepassingsniveau en organisatieniveau vast. Deze procedure helpt voorkomen dat belangrijke servicebronnen worden gebruikt tijdens een aanval of onbedoeld misbruik van resources.

Antwoord van livesite

In zeldzame gevallen hebt u mogelijk een live site-reactie nodig op een probleem met de beschikbaarheid van de service. We hebben een operations-team dat voortdurend beschikbaar is om het probleem snel te identificeren en de benodigde resources van het ontwikkelteam te betrekken.

De resources van het ontwikkelteam lossen vervolgens het probleem op. Ze streven er ook naar om de servicestatuspagina binnen enkele minuten bij te werken na het detecteren van een probleem dat van invloed is op de service. Nadat resources van het ontwikkelteam een probleem hebben opgelost, identificeren ze de hoofdoorzaak en volgen ze de benodigde wijzigingen om soortgelijke problemen in de toekomst te voorkomen.

Azure DevOps-processen voor live sitebeheer richten zich op uw ervaring en de status van de service. Deze processen minimaliseren de tijd om problemen te detecteren, erop te reageren en te verhelpen. Alle technische disciplines zijn betrokken en verantwoordelijk, dus voortdurende verbeteringen ontwikkelen zich uit de directe ervaring. Bewakings-, diagnose-, tolerantie- en kwaliteitscontroleprocessen worden vervolgens in de loop van de tijd verbeterd.

Live sitebeheer in Azure DevOps heeft drie verschillende sporen: telemetrie, incidentbeheer en live sitebeoordeling. Dit houdt het volgende in:

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

Het operations-team bewaakt ook de metrische beschikbaarheidsgegevens voor afzonderlijke organisaties. Deze metrische gegevens bieden inzicht in specifieke voorwaarden die alleen van invloed kunnen zijn op enkele van onze klanten. Onderzoeken naar deze gegevens kunnen vaak leiden tot gerichte verbeteringen om klantspecifieke problemen op te lossen. In sommige gevallen kan Microsoft zelfs rechtstreeks contact met u opnemen om uw ervaring te begrijpen en met u samen te werken om de service te verbeteren.

Microsoft publiceert een SLA en biedt een financiële garantie om ervoor te zorgen dat we elke maand aan deze overeenkomst voldoen. Zie SLA voor Azure DevOps voor meer informatie.

Soms hebben partnerteams of afhankelijkheden incidenten die van invloed zijn op Azure DevOps. Alle partnerteams volgen vergelijkbare benaderingen voor het identificeren, oplossen en leren van deze serviceonderbrekingen.

Servicebeveiliging

Servicebeveiliging vereist constante bewaking, van de juiste ontwerp- en coderingstechnieken tot operationele factoren. Microsoft investeert actief in de preventie van beveiligingsgaten en in de detectie van schendingen. Als er sprake is van een inbreuk, gebruikt Microsoft beveiligingsantwoordplannen om het lekken van gegevens, verlies of beschadiging te minimaliseren. Zie Voor meer informatie over beveiliging, verificatie en autorisatie.

Beveiliging op ontwerp

Azure DevOps is ontworpen om veilig te zijn. Azure DevOps maakt gebruik van de levenscyclus van Microsoft Security Development in de kern van het ontwikkelproces. Het Microsoft Operational Security Assurance-programma begeleidt procedures voor cloudbewerkingen in Azure DevOps.

Het Azure DevOps-team heeft jaarlijkse trainingsvereisten voor alle technici en operationele medewerkers. Het team sponsort ook informele vergaderingen die worden gehost door Microsoft-technici. Nadat het team een probleem heeft opgelost dat zich in een vergadering voordoet, deelt het de lessen die zijn geleerd met andere teams.

De volgende methodologieën geven de trainingsvereisten op:

  • Bedreigingsmodellering tijdens serviceontwerp
  • Aanbevolen procedures voor ontwerp en code volgen
  • Beveiliging controleren met standaardhulpprogramma's en testen
  • De toegang tot operationele en klantgegevens beperken
  • Implementatie van nieuwe functies beperken via een star goedkeuringsproces

Een cloudservice is alleen zo veilig als het hostplatform. Azure DevOps maakt gebruik van PaaS voor een groot deel van de infrastructuur. PaaS biedt automatisch regelmatige updates voor bekende beveiligingsproblemen.

Virtuele machines die worden gehost in Azure maken gebruik van IaaS (Infrastructure as a Service), zoals voor een gehoste buildservice. Dergelijke installatiekopieën ontvangen regelmatig updates om de nieuwste beveiligingspatches op te nemen die beschikbaar zijn via Windows Update. Dezelfde update-rigor is van toepassing op on-premises machines, inclusief de machines die worden gebruikt voor implementatie, bewaking en rapportage.

Het Azure DevOps-team voert regelmatig, beveiligingsgerichte penetratietests van Azure DevOps uit. Penetratietests proberen de live productieservices en infrastructuur van Azure DevOps te benutten met behulp van dezelfde technieken en mechanismen die kwaadwillende aanvallers gebruiken. Het doel is om beveiligingsproblemen, configuraties, fouten of andere beveiligingsproblemen in een beheerd proces te identificeren.

Het team beoordeelt de resultaten van deze tests om andere gebieden van verbetering te identificeren en de kwaliteit van de preventieve systemen en training te verhogen. U kunt de resultaten van recente Azure DevOps-penetratietests bekijken in de Microsoft Service Trust Portal.

Referentiebeveiliging

We gebruiken aanbevolen procedures voor de branche om uw referenties op te slaan in Azure DevOps. Meer informatie over referentieopslag.

Beveiligingsfouten rapporteren

Als u denkt dat uw penetratietests een mogelijke beveiligingsfout met betrekking tot de Azure DevOps-service hebben ontdekt, meldt u deze binnen 24 uur aan Microsoft. Zie de Microsoft-webpagina voor het melden van een beveiligingsprobleem met een computer voor meer informatie.

Belangrijk

Hoewel u Microsoft niet hoeft op de hoogte te stellen van activiteiten voor penetratietests, moet u voldoen aan de Regels voor penetratietests van Microsoft.

Bounty-programma

Azure DevOps neemt deel aan het Microsoft Bug Bounty-programma. Dit programma beloont beveiligingsonderzoekers die problemen aan ons melden en moedigt meer mensen aan om Azure DevOps veilig te houden. Zie Microsoft Azure DevOps Bounty Program voor meer informatie.

Toegang beperken

Microsoft houdt strikte controle over wie toegang krijgt tot onze productieomgeving en klantgegevens. We verlenen toegang op het niveau van minimale bevoegdheden die vereist zijn, en pas na verificatie van de redenen van een gebruiker. Als een teamlid toegang nodig heeft om een urgent probleem op te lossen of een configuratiewijziging te implementeren, moet deze een Just-In-Time-toegang tot de productieservice aanvragen. De toegang wordt ingetrokken zodra de situatie is opgelost.

We volgen en bewaken toegangsaanvragen en goedkeuringen in een afzonderlijk systeem. Alle toegang tot het systeem correleert met deze goedkeuringen. Als we niet-goedgekeurde toegang detecteren, waarschuwen we het operations-team om dit te onderzoeken.

We gebruiken tweeledige verificatie voor alle externe systeemtoegang. Als de gebruikersnaam en het wachtwoord voor een van onze ontwikkelaars of operationele medewerkers worden gestolen, blijven de gegevens beveiligd. Aanvullende verificatiecontroles via smartcard of een telefoongesprek naar een vooraf goedgekeurd nummer moeten plaatsvinden voordat we externe toegang tot de service toestaan.

Voor het beheren en onderhouden van de service gebruikt Microsoft geheimen zoals RDP-wachtwoorden, SSL-certificaten en versleutelingssleutels. Deze geheimen worden allemaal veilig beheerd, opgeslagen en verzonden via Azure Portal. Voor elke toegang tot deze geheimen is een specifieke machtiging vereist, die veilig wordt geregistreerd en vastgelegd. Alle geheimen worden regelmatig geroteerd en we kunnen ze op aanvraag draaien als er een beveiligingsgebeurtenis is.

Het Azure DevOps Operations-team maakt gebruik van beperkte beheerderswerkstations om de service te beheren. Deze machines voeren een minimaal aantal toepassingen uit en werken in een logisch gesegmenteerde omgeving.

Leden van het operations-team moeten specifieke referenties met tweeledige verificatie opgeven voor toegang tot de werkstations. Alle toegang wordt bewaakt en veilig geregistreerd. Als u de service wilt isoleren van manipulatie buiten, staan we toepassingen zoals Outlook en Office niet toe, omdat ze vaak doelen zijn van spear phishing en andere soorten aanvallen.

Bescherming en reactie tegen inbraak

We versleutelen gegevens via HTTPS en SSL om ervoor te zorgen dat deze niet worden onderschept of gewijzigd tijdens de overdracht tussen u en Azure DevOps. Gegevens die we namens u opslaan in Azure DevOps, worden als volgt versleuteld:

  • Gegevens die zijn opgeslagen in Azure SQL-databases, worden versleuteld via transparante gegevensversleuteling. Deze functie beschermt tegen schadelijke activiteiten door realtime versleuteling van de database, gekoppelde back-ups en transactielogboekbestanden in rust uit te voeren.

  • Azure Blob Storage-verbindingen worden versleuteld om uw gegevens in transit te beveiligen. Voor data-at-rest die zijn opgeslagen in Azure Blob Storage, maakt Azure DevOps gebruik van versleuteling aan de servicezijde.

Notitie

Azure DevOps is niet compatibel met FIPS (Federal Information Processing Standards) 140-2 of 140-3.

Het Azure DevOps-team maakt gebruik van de Azure-infrastructuur om belangrijke aspecten van de service te registreren en te bewaken. Logboekregistratie en bewaking zorgen ervoor dat activiteiten binnen de service legitiem zijn en ze helpen bij het detecteren van schendingen of pogingen tot schendingen.

Alle implementatie- en beheerdersactiviteiten worden veilig geregistreerd, omdat operatortoegang tot productieopslag is. De logboekgegevens worden automatisch geanalyseerd en mogelijk schadelijk of niet-geautoriseerd gedrag genereert realtime waarschuwingen.

Wanneer het Azure DevOps-team een mogelijk beveiligingsprobleem met een inbraak of beveiligingsprobleem met hoge prioriteit identificeert, heeft het een duidelijk reactieplan. Dit plan bevat een overzicht van verantwoordelijke partijen, vereiste stappen voor het beveiligen van klantgegevens en instructies voor het communiceren met beveiligingsexperts bij Microsoft. Het team meldt ook eigenaren van organisaties als er gegevens zijn vrijgegeven of beschadigd, zodat ze de juiste stappen kunnen nemen om de situatie te verhelpen.

Om opkomende bedreigingen te helpen bestrijden, maakt Azure DevOps gebruik van een inbreukstrategie . Een zeer gespecialiseerd team van beveiligingsexperts binnen Microsoft neemt de rol van geavanceerde aanvallers aan. Dit team test de detectie en reactie van schendingen om de gereedheid en de gevolgen van echte aanvallen nauwkeurig te meten. Deze strategie versterkt de detectie, reactie en verdediging van de service. Hiermee kan het team ook de effectiviteit van het hele beveiligingsprogramma valideren en verbeteren.

Bescherming tegen ransomware-aanvallen

Azure DevOps maakt gebruik van Azure-besturingselementen om ransomware-aanvallen te voorkomen, te detecteren en erop te reageren. Zie Ransomware-beveiliging in Azure voor meer informatie over hoe Azure klanten helpt beschermen tegen ransomware-aanvallen.

Gegevensprivacy

U moet er zeker van zijn dat we uw gegevens op de juiste wijze en voor legitiem gebruik verwerken. Een deel van deze zekerheid omvat zorgvuldig het beperken van het gebruik.

Algemene verordening gegevensbescherming

De Algemene Verordening Gegevensbescherming (AVG) is de grootste wijziging in de wetgeving inzake gegevensbescherming in Europa sinds de introductie van de Europese Unie (EU) Data Protection Richtlijn 95/46/EG. Zie de overzichtspagina in het Vertrouwenscentrum van Microsoft voor meer informatie over avg.

Gegevenslocatie en soevereiniteit

Azure DevOps is beschikbaar op de volgende acht geografische locaties over de hele wereld: Verenigde Staten, Canada, Europa, Verenigd Koninkrijk, India, Australië, Azië en Stille Oceaan en Brazilië. Uw organisatie is standaard toegewezen aan uw dichtstbijzijnde locatie. U kunt echter een andere locatie kiezen wanneer u uw organisatie maakt. Als u later van gedachten verandert, kunt u de organisatie migreren naar een andere locatie met ondersteuning van Microsoft.

Azure DevOps verplaatst of repliceert geen klantgegevens buiten de gekozen locatie. In plaats daarvan worden uw gegevens geografisch gerepliceerd naar een tweede regio binnen dezelfde locatie. De enige uitzondering hierop is Brazilië, dat gegevens repliceert naar de regio VS - zuid-centraal voor herstel na noodgevallen.

Notitie

Voor builds en releases die worden uitgevoerd op door Microsoft geleverde macOS-agents, worden uw gegevens overgebracht naar een GitHub-datacenter in de Verenigde Staten.

Zie Gegevenslocaties voor Azure DevOps voor meer informatie.

Toegang tot rechtshandhaving

In sommige gevallen kunnen derden, zoals rechtshandhavingsentiteiten, Microsoft benaderen om toegang te krijgen tot klantgegevens die zijn opgeslagen in Azure DevOps. We proberen de aanvragen om te leiden naar de eigenaar van de organisatie voor oplossing. Wanneer een gerechtelijk bevel Microsoft verplicht om klantgegevens bekend te maken aan een derde partij, doet Microsoft een redelijke inspanning om de eigenaar van de organisatie vooraf op de hoogte te stellen, tenzij dit wettelijk verboden is.

Sommige klanten vereisen hun gegevensopslag op een bepaalde geografische locatie om een specifieke juridische jurisdictie te garanderen voor eventuele rechtshandhavingsactiviteiten. Alle klantgegevens, zoals broncode, werkitems, testresultaten en geografisch redundante spiegels en back-ups van offsite, worden onderhouden binnen een van de eerder genoemde locaties.

Microsoft Access

Van tijd tot tijd moeten Microsoft-werknemers toegang krijgen tot klantgegevens die zijn opgeslagen in Azure DevOps. Als voorzorgsmaatregel moeten alle werknemers die toegang hebben (of ooit hebben) tot klantgegevens een achtergrondcontrole doorgeven die eerdere arbeids- en strafrechtelijke veroordelingen omvat. We staan alleen toegang tot de productiesystemen toe wanneer er een livesite-incident of andere goedgekeurde onderhoudsactiviteit is, die wordt geregistreerd en bewaakt.

Omdat niet alle gegevens in ons systeem op dezelfde manier worden behandeld, classificeren we gegevens in deze typen:

  • Klantgegevens: wat u uploadt naar Azure DevOps.
  • Organisatiegegevens: informatie die u indient wanneer u zich registreert voor of uw organisatie beheert.
  • Microsoft-gegevens: informatie die is vereist voor of verzameld via de werking van de service.

Op basis van de classificatie beheren we gebruiksscenario's, geolocatievereisten, toegangsbeperkingen en retentievereisten.

Microsoft-promotiegebruik

Microsoft wil af en toe contact opnemen met klanten om hen te laten weten over aanvullende functies en services die nuttig kunnen zijn. Omdat niet alle klanten contact willen opnemen met deze aanbiedingen, kunt u zich aanmelden en afmelden voor marketing-e-mailcommunicatie.

Microsoft gebruikt nooit klantgegevens om specifieke aanbiedingen te richten voor specifieke gebruikers of organisaties. In plaats daarvan gebruiken we organisatiegegevens en aggregeren we gebruiksstatistieken op organisatieniveau om groepen te bepalen die specifieke aanbiedingen moeten ontvangen.

Vertrouwen opbouwen

U kunt vertrouwen in andere inspanningen die Microsoft namens Azure DevOps doet. Deze inspanningen omvatten interne acceptatiebeleid bij Microsoft, het transparantieniveau in de status van onze service en de voortgang van het ontvangen van certificering van onze systemen voor het beheren van informatiebeveiliging.

Interne acceptatie

Teams binnen Microsoft gebruiken Azure DevOps intern. Het Azure DevOps-team is in 2014 overgestapt naar een organisatie en gebruikt het uitgebreid. We hebben richtlijnen opgesteld om de acceptatieplannen voor andere teams mogelijk te maken.

Grote teams verplaatsen zich geleidelijker dan kleinere teams vanwege hun investeringen in bestaande DevOps-systemen. Voor teams die snel gaan, hebben we een benadering voor projectclassificatie vastgesteld. Het evalueert risicotolerantie, op basis van projectkenmerken, om te bepalen of het project geschikt is voor Azure DevOps. Voor grotere teams vindt de acceptatie meestal plaats in fasen, met meer planning.

Aanvullende vereisten voor interne projecten omvatten het koppelen van de organisatie aan Microsoft Entra ID om de juiste levenscyclus van gebruikersidentiteiten en wachtwoordcomplexiteit te garanderen. Voor projecten die gevoeliger zijn, is ook tweeledige verificatie vereist.

Nalevingscertificeringen

Mogelijk bent u geïnteresseerd in het begrijpen van de evaluatie door derden van onze procedures voor gegevensbeveiliging. Azure DevOps heeft de volgende certificeringen behaald:

  • ISO 27001:2013
  • ISO 27018:2019
  • ISO 26262:2023
  • Health Insurance Portability and Accountability Act (HIPAA)
  • Business Associate Agreement (BAA)
  • EU-modelclausules
  • Systeem- en organisatiebesturingselementen (SOC) 1 Type 2
  • SOC 2 Type 2
  • Duitsland C5
  • IRAP in Australië
  • ENS-Spanje

De SOC-controle voor Azure DevOps bevat besturingselementen voor gegevensbeveiliging, beschikbaarheid, verwerkingsintegriteit en vertrouwelijkheid. De SOC-rapporten voor Azure DevOps zijn beschikbaar via de Microsoft Service Trust Portal.

De Consensus Assessment Initiative Vragenlijst (CAIQ) helpt organisaties bij het beoordelen en evalueren van de beveiligingsprocedures en mogelijkheden van cloudserviceproviders. In overeenstemming met onze toezegging tot beveiliging en transparantie hebben we onlangs de CAIQ-evaluatie voor Azure DevOps voltooid. We nodigen u uit om het volledige rapport te bekijken in de Microsoft Service Trust Portal.

Stappen die u kunt uitvoeren

Voor de juiste gegevensbescherming zijn actieve betrokkenheid van u, uw beheerders en uw gebruikers vereist. Uw projectgegevens die zijn opgeslagen in Azure DevOps, zijn alleen zo veilig als de gebruikerstoegangspunten. Komt overeen met het machtigingsniveau en de granulariteit voor deze organisaties met het gevoeligheidsniveau van uw project.

Uw gegevens classificeren

De eerste stap is het classificeren van uw gegevens. Gegevens classificeren op basis van gevoeligheid en risico horizon, samen met de schade die kan optreden als deze wordt aangetast. Veel ondernemingen hebben bestaande classificatiemethoden die ze kunnen hergebruiken wanneer projecten worden verplaatst naar Azure DevOps. Voor meer informatie kunt u gegevensclassificatie voor cloudgereedheid downloaden van Microsoft Trustworthy Computing.

Microsoft Entra-id aannemen

Gebruik De Microsoft Entra-id om de toegang van uw organisatie tot Azure DevOps te beheren. Microsoft Entra ID biedt een andere manier om de beveiliging van de referenties van uw gebruikers te verbeteren.

Met Microsoft Entra ID kan uw IT-afdeling het gebruikerstoegangsbeleid, wachtwoordcomplexiteit, wachtwoordvernieuwing en verlooptijd beheren wanneer gebruikers uw organisatie verlaten. Via Active Directory-federatie kunt u microsoft Entra-id rechtstreeks koppelen aan de centrale adreslijst van uw organisatie, zodat u slechts één locatie hebt om deze gegevens voor uw onderneming te beheren.

In de volgende tabel worden de kenmerken van Het Microsoft-account en Microsoft Entra vergeleken ten opzichte van Azure DevOps-toegang:

Eigenschappen Microsoft-account Microsoft Entra ID
Maker van identiteit User Organisatie
Eén gebruikersnaam en wachtwoord voor alle werkassets Nr. Ja
Beheer van levensduur en complexiteit van wachtwoorden User Organisatie
Limieten voor Azure DevOps-lidmaatschap Een Microsoft-account Adreslijst van de organisatie
Traceerbare identiteit Nr. Ja
Eigendom van organisatie en IP Onduidelijk Organisatie
Registratie van tweeledige verificatie User Organisatie
Voorwaardelijke toegang op basis van het apparaat Nee Organisatie

Meer informatie over het configureren van deze ondersteuning voor uw organisatie.

Tweeledige verificatie vereisen

Mogelijk wilt u de toegang tot uw organisatie beperken door meerdere factoren te vereisen om u aan te melden. U kunt meerdere factoren vereisen met behulp van Microsoft Entra-id. U kunt bijvoorbeeld telefoonverificatie vereisen, naast een gebruikersnaam en wachtwoord, voor alle verificatieaanvragen.

BitLocker gebruiken

Voor gevoelige projecten kunt u BitLocker gebruiken op uw Windows-laptop of -desktopcomputer. BitLocker versleutelt het hele station waarop Windows en uw gegevens zich bevinden. Wanneer BitLocker is ingeschakeld, wordt elk bestand dat u op dat station opslaat, automatisch versleuteld. Als uw computer in verkeerde handen valt, voorkomt BitLocker onbevoegde toegang tot lokale kopieën van gegevens uit uw projecten.

Gebruik van alternatieve verificatiereferenties beperken

Het standaardverificatiemechanisme voor Git-gerelateerde hulpprogramma's is alternatieve verificatie (ook wel basisverificatie genoemd). Met dit mechanisme kan een gebruiker een alternatieve gebruikersnaam en een alternatief wachtwoord instellen voor gebruik tijdens git-opdrachtregelbewerkingen. De gebruiker kan deze combinatie van gebruikersnaam en wachtwoord gebruiken om toegang te krijgen tot alle andere gegevens waarvoor die gebruiker machtigingen heeft. Alternatieve verificatiereferenties zijn van nature minder veilig dan de standaard federatieve verificatie.

U kunt nog steeds keuzes maken voor betere beveiliging. Alle communicatie wordt verzonden via HTTPS en er zijn vereisten voor wachtwoordcomplexiteit. Uw organisatie moet blijven evalueren of er aanvullende beleidsregels nodig zijn om te voldoen aan de beveiligingsvereisten van uw projecten.

U kunt alternatieve verificatiereferenties uitschakelen als u besluit dat deze niet voldoet aan de beveiligingsvereisten van uw organisatie. Zie Toepassingsverbinding en beveiligingsbeleid voor uw organisatie wijzigen voor meer informatie.

Beveiligde toegang tot uw organisatie

Beheer istrators kunnen Microsoft Entra ID gebruiken om de toegang tot Azure-resources en -toepassingen, zoals Azure DevOps, te beheren. Met voorwaardelijk toegangsbeheer controleert Microsoft Entra ID op de specifieke voorwaarden die u instelt voor een gebruiker voor toegang tot een toepassing. Nadat de gebruiker aan de toegangsvereisten voldoet, wordt de gebruiker geverifieerd en heeft deze toegang tot de toepassing.

Azure DevOps ondersteunt het afdwingen van bepaalde typen beleidsregels voor voorwaardelijke toegang (bijvoorbeeld IP-fencing) voor aangepaste Azure DevOps-verificatiemechanismen. Deze mechanismen omvatten persoonlijke toegangstokens, alternatieve verificatie, OAuth en SSH-sleutels (Secure Shell). Als uw gebruikers toegang hebben tot Azure DevOps via een client van derden, worden alleen op IPv4 gebaseerde beleidsregels toegepast.

Aanvullende bronnen