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 meer 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, bevinden zich in 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
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 de meeste opslag in gebruik dit type ongestructureerde blobopslag.
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.
Beheerders kunnen de toegang tot resources beheren door machtigingen voor gebruikersidentiteiten of -groepen te verlenen 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.
Beheerders kunnen toegangsbeheer gebruiken om de toegang tot de organisatie, projectverzamelingen, teamprojecten en teamgegevens en -functionaliteit te beveiligen. Beheerders 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 (Service Level Agreement) 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
Ter bescherming tegen onbedoeld gegevensverlies maakt Microsoft gebruik van point-in-time back-ups voor zowel blobs die zijn opgeslagen in Azure Blob Storage als databases in Azure SQL Database. Elk opslagaccount onderhoudt een afzonderlijke kopie van alle blobs, waarbij wijzigingen worden toegevoegd aan de bestaande gegevens. Deze back-ups zijn onveranderbaar, waardoor er geen bestaande opslag meer hoeft te worden herschreven tijdens back-upprocedures.
Azure SQL Database bevat standaardback-upfuncties die worden gebruikt door Azure DevOps. Uw gegevens worden 28 dagen bewaard, waarbij deze back-ups ook worden gerepliceerd in een gekoppelde regio om het herstel tijdens een regionale storing te vergemakkelijken.
U kunt verwijderde organisaties of projecten herstellen binnen het 28-daagse venster na verwijdering. Maar zodra deze periode is verstreken, worden deze entiteiten definitief verwijderd en kunnen ze niet meer worden hersteld. Hoewel deze back-ups fungeren als een cruciaal onderdeel voor herstel na noodgevallen, is het essentieel dat klanten de juiste strategieën voor gegevensbeheer en back-ups oefenen om uitgebreide bescherming van hun gegevens te garanderen.
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.
- In zeldzame gevallen kan het verwijderen tot 70 dagen duren vanwege nieuwe pogingen van de back-end en de noodzaak om gegevens uit meerdere bronnen te verwijderen.
Praktijk is essentieel
Het herstellen van meerdere back-ups van uw gegevens is goed, maar zonder de praktijk kan het herstellen onvoorspelbaar zijn. Mensen zeggen 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:
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, met inbegrip van die 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
Microsoft streeft ernaar om ervoor te zorgen dat uw projecten veilig en veilig blijven, zonder uitzondering. In Azure DevOps profiteren uw projecten van meerdere lagen van beveiligings- en governancetechnologieën, operationele procedures en nalevingsbeleid. We dwingen privacy en integriteit van gegevens af, zowel at-rest als in transit. Daarnaast houden we ons aan de volgende procedures met betrekking tot de referenties of geheimen die door Azure DevOps worden opgeslagen. Zie Richtlijnen voor verificatie voor meer informatie over het kiezen van het juiste verificatiemechanisme.
Belangrijk
Azure DevOps biedt geen ondersteuning voor verificatie van alternatieve referenties. Als u nog steeds alternatieve referenties gebruikt, raden we u sterk aan over te schakelen naar een veiligere verificatiemethode.
Persoonlijke toegangstokens (PAT's)
- We slaan een hash van de PAT op.
- Onbewerkte PAW's genereren in het geheugen aan de serverzijde. 32 bytes genereren willekeurig via de RNGCryptoServiceProvider en worden gedeeld met de aanroeper als een met base-32 gecodeerde tekenreeks. Deze waarde wordt NIET opgeslagen.
- PAT-hash genereert in-memory aan de serverzijde als een HMACSHA256Hash van de onbewerkte PAT met behulp van een symmetrische ondertekeningssleutel van 64 byte die is opgeslagen in onze sleutelkluis.
- Hash wordt opgeslagen in onze database.
SSH-sleutels (Secure Shell)
- We slaan een hash op van de organisatie-id en de openbare SSH-sleutel.
- Onbewerkte openbare sleutels worden rechtstreeks door de aanroeper via SSL verstrekt.
- SSH-hash genereert in-memory aan de serverzijde als een HMACSHA256Hash van de organisatie-id en onbewerkte openbare sleutel met behulp van een symmetrische ondertekeningssleutel van 64 byte die is opgeslagen in onze sleutelkluis.
- Hash wordt opgeslagen in onze database.
OAuth-referenties (JWT's)
- Probleem met OAuth-referenties als volledig zelfbeschrijfde JSON-webtokens (JWT's) en worden niet opgeslagen in onze service.
- De claims in JWT's die zijn uitgegeven en aan onze service worden gepresenteerd, worden gevalideerd met behulp van een certificaat dat is opgeslagen in onze sleutelkluis.
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 dat is vereist, 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. Meer 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.
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 meer 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
Microsoft-teams 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.
Meer 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 er inbreuk optreedt. 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 meer 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
Beheerders 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.