Dela via


Översikt över dataskydd

Azure DevOps Services

Azure DevOps Services är ett molnbaserat program för dina utvecklingsprojekt, från planering till distribution. Baserat på de lokala funktionerna hanterar vi källkod, arbetsobjekt, byggen och tester med fler molntjänster. Azure DevOps använder paaS-infrastruktur (plattform som en tjänst) och många Azure-tjänster, inklusive Azure SQL, för att leverera en tillförlitlig, globalt tillgänglig tjänst för dina utvecklingsprojekt.

I den här artikeln beskrivs de steg som Microsoft vidtar för att skydda dina projekt, vara tillgängliga, säkra och privata. Den beskriver vilken roll du spelar när det gäller att skydda dina projekt.

Den här artikeln är avsedd för organisationsadministratörer och IT-proffs som hanterar sina projekttillgångar dagligen. Det är mest användbart för personer som redan är bekanta med Azure DevOps och vill veta mer om hur Microsoft skyddar lagrade tillgångar i Azure DevOps.

Vårt åtagande

Microsoft hjälper till att säkerställa att dina projekt förblir säkra och säkra, utan undantag. När du lagrar dina projekt i Azure DevOps drar de nytta av flera lager av säkerhets- och styrningstekniker, driftsrutiner och efterlevnadsprinciper. Vi tillämpar datasekretess och integritet både i vila och under överföring.

Hoten som du står inför finns i fyra grundläggande kategorier: datatillgänglighet, tjänsttillgänglighet, tjänstsäkerhet och datasekretess. Den här artikeln utforskar specifika hot inom varje kategori och förklarar vad Azure DevOps gör för att åtgärda dem. Artikeln börjar med att beskriva hur data lagras och hur Azure DevOps hanterar åtkomst till dina data.

Dataskydd kräver aktivt engagemang av administratörer och användare som vet vilka åtgärder som ska vidtas för att skydda dina tillgångar från obehörigt avslöjande och manipulering. Var explicit när du beviljar behörigheter till användaråtkomstpunkter, så att endast rätt personer får åtkomst till data i Azure DevOps.

Du bör betrakta alla data som potentiellt utsatta för risk, oavsett var de är eller hur de används. Den här instruktionen gäller både för data som lagras i molnet och data som lagras i ett privat datacenter. Det är viktigt att klassificera dina data, dess känslighet och risk samt den skada som de kan göra om de komprometteras. Kategorisera även dina data i förhållande till en övergripande princip för hantering av informationssäkerhet.

Byggt på Azure

Diagram över arkitekturen på hög nivå i Azure DevOps.

Vi är helt värd för Azure DevOps i Azure-datacenter. Azure DevOps använder många grundläggande Azure-tjänster, inklusive beräkning, lagring, nätverk, Azure SQL, identitets- och åtkomsthantering och Azure Service Bus.

Azure DevOps använder sig av Azure Storage som primär lagringsplats för tjänstmetadata och kunddata. Beroende på typen av data och kraven på lagring och hämtning använder Azure DevOps Azure Blob Storage och Azure SQL Database Storage.

Här är några bakgrunder om lagringstjänster som hjälper dig att förstå Azure DevOps Services-metoden för dataskydd:

  • Azure Blob Storage lagrar stora delar av ostrukturerade data. Alla projekt använder den här tjänsten. Data innehåller potentiellt känslig eller privat information, till exempel innehållet i källfiler och bifogade filer för arbetsobjekt. För de flesta projekt används den här typen av ostrukturerad bloblagring i de flesta projekt.

  • Azure SQL Database lagrar organisationens strukturerade och transaktionsmässiga aspekter, inklusive projektmetadata, versionshistorik för källkontroll och information om arbetsobjekt. Databaslagring ger dig snabb åtkomst till de viktiga elementen i projektet. Den tillhandahåller index i bloblagringen för att söka efter filer och bifogade filer.

Administratörer kan hantera åtkomst till resurser genom att bevilja eller begränsa behörigheter för användaridentiteter eller grupper. Azure DevOps använder federerad autentisering av användaridentiteter via Microsoft Entra-ID och Microsoft-konton.

Under autentiseringen dirigeras användaren till autentiseringsprovidern, där de anger sina autentiseringsuppgifter. När autentiseringsprovidern verifierar användarens autentiseringsuppgifter utfärdar Azure DevOps en autentiseringscookie till användaren. Med den här cookien kan användaren förbli autentiserad mot Azure DevOps.

På så sätt delas aldrig användarens information om autentiseringsuppgifter direkt med Azure DevOps. För varje Azure DevOps-resurs som användaren försöker komma åt baseras verifieringen av behörigheter på användarens explicita behörigheter och på behörigheter som användaren ärvt genom gruppmedlemskap.

Administratörer kan använda åtkomstkontroller för att skydda åtkomsten till organisationen, projektsamlingar, teamprojekt och teamomfattande data och funktioner. Administratörer kan också använda åtkomstkontroller för specifika tillgångar som mappar för versionskontroll och områdessökvägar för arbetsobjekt.

Datatillgänglighet

Azure DevOps använder många Azure Storage-funktioner för att säkerställa datatillgänglighet om det uppstår maskinvarufel, avbrott i tjänsten eller en regional katastrof. Dessutom följer Azure DevOps-teamet procedurer för att skydda data från oavsiktlig eller skadlig borttagning.

Dataredundans

För att skydda data vid maskinvaru- eller tjänstfel replikerar Azure Storage kunddata mellan två regioner på samma geografiska plats. Azure Storage kan till exempel geo-replikera data mellan Europa, norra och västra eller mellan norra och södra USA.

För Azure Blob Storage replikeras kunddata tre gånger inom en enda region. Kunddata replikeras asynkront till en andra region på samma geografiska plats. Därför behåller Azure alltid motsvarande sex kopior av dina data.

Om du har flera kopior kan du redundansväxla till en separat region om det uppstår ett större avbrott eller haveri, samtidigt som du har lokal redundans för maskinvarufel i en region. För Azure SQL Database-lagring underhålls dagliga säkerhetskopieringar utanför plats om det uppstår ett regionalt haveri.

Angående dataredundans och redundans:

  • Det finns ett inbyggt delta, mätt i minuter, när Microsoft replikerar dina data mellan den primära och sekundära regionen.
  • Redundansväxling till den sekundära regionen är ett beslut som Microsoft måste fatta centralt, eftersom det påverkar alla kunder i en viss skalningsenhet. Förutom under extrema omständigheter väljer Microsoft att undvika redväxlar så att kunddata inte går förlorade.
  • Azure DevOps erbjuder ett serviceavtal (SLA) på 99,9 procent drifttid. Azure DevOps återbetalar en del av de månatliga avgifterna om det missar serviceavtalet under en viss månad.
  • Eftersom det bara finns en region i Brasilien replikeras kunddata i Brasilien till regionen USA, södra centrala i haveriberedskapssyfte.

Misstag inträffar

För att skydda mot oavsiktlig dataförlust använder Microsoft säkerhetskopieringar till tidpunkt för både blobar som lagras i Azure Blob Storage och databaser i Azure SQL Database. Varje lagringskonto har en separat kopia av alla blobar, där ändringar läggs till i befintliga data. Dessa säkerhetskopior är oföränderliga, vilket eliminerar behovet av att skriva om befintlig lagring under säkerhetskopieringen.

Azure SQL Database innehåller standardfunktioner för säkerhetskopiering som används av Azure DevOps. Dina data bevaras i 28 dagar, och dessa säkerhetskopior replikeras också i en parad region för att underlätta återställning under ett regionalt avbrott.

Du kan återställa borttagna organisationer eller projekt inom 28-dagarsfönstret efter borttagningen. Men när den här tidsperioden har gått tas dessa entiteter bort permanent och kan inte återställas. Även om dessa säkerhetskopior fungerar som en viktig komponent för haveriberedskap är det viktigt att kunderna använder lämpliga strategier för datahantering och säkerhetskopiering för att säkerställa ett omfattande skydd av sina data.

Viktigt!

  • Oavsiktlig borttagning här avser scenarier som uppstår till följd av en incident på våra tjänster. Den inkluderar inte kunders oavsiktliga borttagning av tillgångar (till exempel lagringsplatser, arbetsobjekt, bifogade filer eller artefakter).
  • Vi stöder inte återställning av tillgångar som kunder oavsiktligt tar bort. Dessa säkerhetskopior är endast avsedda för affärskontinuitet och för att underlätta återställning från avbrott eller katastrofscenarier.
  • I sällsynta fall kan borttagningsprocessen ta upp till 70 dagar på grund av serverdelsförsök och behovet av att ta bort data från flera källor.

Övningen är kritisk

Det är bra att ha flera säkerhetskopior av dina data, men det kan vara oförutsägbart att återställa utan några metoder. Folk säger att "säkerhetskopieringar misslyckas aldrig; återställningarna gör." Även om instruktionen är tekniskt felaktig är sentimentet rätt.

Microsoft använder regelbundet metoder för att återställa datauppsättningar från säkerhetskopior. Vi testar regelbundet geo-redundant lagring från Azure. Det finns många kombinationer av katastrof- och datakorruptionsscenarier. Vi fortsätter att planera och köra nya tester för dessa scenarier regelbundet.

Tjänstetillgänglighet

Azure DevOps erbjuder DDoS-skydd (Distributed Denial-of-Service) och svar på livewebbplatser för att säkerställa att du har åtkomst till din organisation och tillhörande tillgångar.

DDoS-skydd

I vissa fall kan en skadlig DDoS-attack påverka tjänstens tillgänglighet. Azure har ett DDoS-skyddssystem som hjälper till att förhindra attacker mot vår tjänst. Den använder standardmetoder för identifiering och minskning, till exempel SYN-cookies, hastighetsbegränsning och anslutningsgränser. Systemet är utformat för att motstå attacker inte bara utifrån utan även inifrån Azure.

För programspecifika attacker som kan tränga in i Azures försvarssystem upprättar Azure DevOps kvoter och begränsningar på programnivå och organisationsnivå. Den här metoden hjälper till att förhindra överanvändning av viktiga tjänstresurser vid angrepp eller oavsiktligt missbruk av resurser.

Svar på livewebbplats

I sällsynta fall kan du behöva ett live-webbplatssvar på ett problem med tjänstens tillgänglighet. Vi har ett driftsteam som ständigt är tillgängligt för att snabbt identifiera problemet och engagera nödvändiga utvecklingsteamresurser.

Utvecklingsteamets resurser åtgärdar sedan problemet. De syftar också till att uppdatera tjänststatussidan inom några minuter efter att ett problem som påverkar tjänsten har upptäckts. När utvecklingsteamets resurser har åtgärdat ett problem identifierar de rotorsaken och spårar de nödvändiga ändringarna för att förhindra liknande problem i framtiden.

Azure DevOps-processer för hantering av livewebbplatser fokuserar på din upplevelse och tjänstens hälsa. Dessa processer minimerar tiden för att identifiera, svara på och åtgärda problem. Alla tekniska discipliner är involverade och ansvarsfulla, så ständiga förbättringar utvecklas av direkt erfarenhet. Övervaknings-, diagnostik-, återhämtnings- och kvalitetssäkringsprocesser förbättras sedan med tiden.

Hantering av livewebbplatser i Azure DevOps har tre olika spår: telemetri, incidenthantering och granskning av livewebbplatser. Det här är vad dessa spår innebär:

Bild av Azure DevOps Services-processen för hantering av livewebbplatser.

Driftteamet övervakar även tillgänglighetsmåtten för enskilda organisationer. Dessa mått ger insikter om specifika villkor som bara kan påverka vissa av våra kunder. Undersökningar av dessa data kan ofta resultera i riktade förbättringar för att åtgärda kundspecifika problem. I vissa fall kan Microsoft till och med kontakta dig direkt för att förstå din upplevelse och arbeta med dig för att förbättra tjänsten.

Microsoft publicerar ett serviceavtal och tillhandahåller en ekonomisk garanti för att säkerställa att vi uppfyller detta avtal varje månad. Mer information finns i Serviceavtal för Azure DevOps.

Ibland har partnerteam eller beroenden incidenter som påverkar Azure DevOps. Alla partnerteam följer liknande metoder för att identifiera, lösa och lära sig av dessa tjänststopp.

Tjänstsäkerhet

Tjänstsäkerhet kräver konstant vaksamhet, från rätt design- och kodningstekniker till driftsfaktorer. Microsoft investerar aktivt i förebyggande av säkerhetshål och intrångsidentifiering. Om det uppstår ett intrång använder Microsoft säkerhetshanteringsplaner för att minimera dataläckage, förlust eller skada. Mer information finns i Om säkerhet, autentisering och auktorisering.

Säkerhet efter design

Azure DevOps är utformat för att vara säkert. Azure DevOps använder Microsoft Security Development Lifecycle i kärnan av utvecklingsprocessen. Microsoft Operational Security Assurance-programmet vägleder procedurer för molndrift i Azure DevOps.

Azure DevOps-teamet har årliga utbildningskrav för alla tekniker och driftpersonal. Teamet sponsrar också informella möten som anordnas av Microsoft-tekniker. När teamet har löst ett problem som uppstår i ett möte delar det lärdomarna med andra team.

Följande metoder anger träningskraven:

  • Hotmodellering under tjänstdesign
  • Följa metodtips för design och kod
  • Verifiera säkerhet med standardverktyg och testning
  • Begränsa åtkomsten till drift- och kunddata
  • Skapa distribution av nya funktioner genom en strikt godkännandeprocess

En molntjänst är bara lika säker som värdplattformen. Azure DevOps använder PaaS för mycket av sin infrastruktur. PaaS tillhandahåller automatiskt regelbundna uppdateringar för kända säkerhetsrisker.

Virtuella datorer som finns i Azure använder infrastruktur som en tjänst (IaaS), till exempel för en värdbaserad byggtjänst. Sådana avbildningar får regelbundna uppdateringar för att inkludera de senaste säkerhetskorrigeringarna som är tillgängliga från Windows Update. Samma uppdateringstrygghet gäller för lokala datorer, inklusive de datorer som används för distribution, övervakning och rapportering.

Azure DevOps-teamet utför regelbundna, säkerhetsfokuserade intrångstester av Azure DevOps. Intrångstestning försöker utnyttja liveproduktionstjänster och infrastruktur i Azure DevOps med hjälp av samma tekniker och mekanismer som skadliga angripare använder. Målet är att identifiera verkliga säkerhetsrisker, konfigurationer, fel eller andra säkerhetsluckor i en kontrollerad process.

Teamet granskar resultaten av dessa tester för att identifiera andra förbättringsområden och för att öka kvaliteten på de förebyggande systemen och utbildningen. Du kan granska resultaten från de senaste Azure DevOps-intrångstesterna på Microsoft Service Trust Portal.

Säkerhet för autentiseringsuppgifter

Microsoft strävar efter att säkerställa att dina projekt förblir säkra och säkra, utan undantag. I Azure DevOps drar dina projekt nytta av flera lager av säkerhets- och styrningstekniker, operativa metoder och efterlevnadsprinciper. Vi tillämpar datasekretess och integritet både i vila och under överföring. Dessutom följer vi följande metoder när det gäller de autentiseringsuppgifter eller hemligheter som Azure DevOps lagrar. Mer information om hur du väljer rätt autentiseringsmekanism finns i Vägledning för autentisering.

Viktigt!

Azure DevOps stöder inte autentisering med alternativa autentiseringsuppgifter. Om du fortfarande använder alternativa autentiseringsuppgifter rekommenderar vi starkt att du byter till en säkrare autentiseringsmetod.

Personliga åtkomsttoken (PAT)

  • Vi lagrar en hash av PAT.
  • Råa PAT:er genererar minnesinternt på serversidan. 32 byte genereras slumpmässigt via RNGCryptoServiceProvider och delas med anroparen som en base-32-kodad sträng. Det här värdet lagras INTE.
  • PAT-hash genererar minnesinternt på serversidan som en HMACSHA256Hash av den råa PAT med hjälp av en symmetrisk signeringsnyckel på 64 byte som lagras i vårt nyckelvalv.
  • Hash lagras i vår databas.

SSH-nycklar (Secure Shell)

  • Vi lagrar en hash av det omslutande organisations-ID:t och den offentliga SSH-nyckeln.
  • Råa offentliga nycklar tillhandahålls direkt av anroparen via SSL.
  • SSH-hash genererar minnesinternt på serversidan som en HMACSHA256Hash för organisations-ID och rå offentlig nyckel med en symmetrisk signeringsnyckel på 64 byte som lagras i vårt nyckelvalv.
  • Hash lagras i vår databas.

OAuth-autentiseringsuppgifter (JWTs)

  • Problem med OAuth-autentiseringsuppgifter som helt självbeskrivande JSON-webbtoken (JWT) och lagras inte i vår tjänst.
  • Anspråken i JWT:er som utfärdas och presenteras för vår tjänst verifieras med hjälp av ett certifikat som lagras i vårt nyckelvalv.

Rapportera säkerhetsbrister

Om du tror att intrångstestningen visade en potentiell säkerhetsbrist relaterad till Azure DevOps-tjänsten rapporterar du den till Microsoft inom 24 timmar. Mer information finns på Microsofts webbsida för att rapportera en säkerhetsrisk för datorer.

Viktigt!

Även om du inte behöver meddela Microsoft om intrångstestningsaktiviteter måste du följa Microsofts regler för intrångstestning.

Bounty-program

Azure DevOps deltar i Microsoft Bug Bounty-programmet. Det här programmet belönar säkerhetsforskare som rapporterar problem till oss, och det uppmuntrar fler att hjälpa till att hålla Azure DevOps säkert. Mer information finns i Microsoft Azure DevOps Bounty Program.

Begränsa åtkomst

Microsoft har strikt kontroll över vem som får åtkomst till vår produktionsmiljö och våra kunddata. Vi beviljar åtkomst på den lägsta behörighetsnivå som krävs och först efter verifiering av en användares motiveringar. Om en teammedlem behöver åtkomst för att lösa ett brådskande problem eller distribuera en konfigurationsändring måste de ansöka om just-in-time-åtkomst till produktionstjänsten. Åtkomsten återkallas så snart situationen har lösts.

Vi spårar och övervakar åtkomstbegäranden och godkännanden i ett separat system. All åtkomst till systemet korrelerar mot dessa godkännanden. Om vi identifierar ej godkänd åtkomst varnar vi åtgärdsteamet för att undersöka den.

Vi använder tvåfaktorautentisering för all fjärrsystemåtkomst. Om användarnamnet och lösenordet för en av våra utvecklare eller driftspersonal blir stulna förblir data skyddade. Fler autentiseringskontroller via smartkort eller ett telefonsamtal till ett förgodkänt nummer måste ske innan vi tillåter fjärråtkomst till tjänsten.

För att hantera och underhålla tjänsten använder Microsoft hemligheter som RDP-lösenord, SSL-certifikat och krypteringsnycklar. Alla dessa hemligheter hanteras, lagras och överförs säkert via Azure Portal. All åtkomst till dessa hemligheter kräver specifik behörighet, som loggas och registreras på ett säkert sätt. Alla hemligheter roteras regelbundet och vi kan rotera dem på begäran om det finns en säkerhetshändelse.

Azure DevOps-driftsteamet använder härdade administratörsarbetsstationer för att hantera tjänsten. Dessa datorer kör ett minimalt antal program och fungerar i en logiskt segmenterad miljö.

Medlemmar i driftteamet måste ange specifika autentiseringsuppgifter med tvåfaktorautentisering för att få åtkomst till arbetsstationerna. All åtkomst övervakas och loggas på ett säkert sätt. För att isolera tjänsten från extern manipulering tillåter vi inte program som Outlook och Office, eftersom de ofta är mål för nätfiske med spjut och andra typer av attacker.

Intrångsskydd och -svar

Vi krypterar data via HTTPS och SSL för att säkerställa att de inte fångas upp eller ändras under överföring mellan dig och Azure DevOps. Data som vi lagrar åt dig i Azure DevOps krypteras på följande sätt:

  • Data som lagras i Azure SQL-databaser krypteras via transparent datakryptering. Den här funktionen hjälper till att skydda mot skadlig aktivitet genom att utföra realtidskryptering av databasen, associerade säkerhetskopior och transaktionsloggfiler i vila.

  • Azure Blob Storage-anslutningar krypteras för att skydda dina data under överföring. För vilande data som lagras i Azure Blob Storage använder Azure DevOps kryptering på tjänstsidan.

Azure DevOps-teamet använder Azure-infrastrukturen för att logga och övervaka viktiga aspekter av tjänsten. Loggning och övervakning hjälper till att säkerställa att aktiviteter inom tjänsten är legitima och de hjälper till att identifiera överträdelser eller försök till överträdelser.

Alla distributions- och administratörsaktiviteter loggas på ett säkert sätt, liksom operatoråtkomst till produktionslagring. Logginformationen analyseras automatiskt och eventuellt skadligt eller obehörigt beteende skapar realtidsaviseringar.

När Azure DevOps-teamet identifierar ett möjligt intrång eller högprioriterad säkerhetsrisk har det en tydlig svarsplan. Den här planen beskriver ansvariga parter, nödvändiga steg för att skydda kunddata och instruktioner om hur du interagerar med säkerhetsexperter på Microsoft. Teamet meddelar också eventuella organisationsägare om data har avslöjats eller skadats, så att de kan vidta lämpliga åtgärder för att åtgärda situationen.

För att bekämpa nya hot använder Azure DevOps en strategi för att anta intrång . Ett högt specialiserat team av säkerhetsexperter inom Microsoft tar på sig rollen som avancerade angripare. Det här teamet testar identifiering och svar av överträdelser för att korrekt mäta beredskapen och effekterna av verkliga attacker. Den här strategin stärker hotidentifiering, svar och skydd av tjänsten. Det gör det också möjligt för teamet att verifiera och förbättra effektiviteten i hela säkerhetsprogrammet.

Skydd mot utpressningstrojaner

Azure DevOps använder Azure-kontroller för att förhindra, identifiera och svara på en utpressningstrojanattack. Mer information om hur Azure hjälper till att skydda kunder från utpressningstrojanattacker finns i Skydd mot utpressningstrojaner i Azure.

Datasekretess

Du bör vara säker på att vi hanterar dina data på rätt sätt och för legitim användning. En del av den försäkran handlar om att noggrant begränsa användningen.

Allmän dataskyddsförordning

Den allmänna dataskyddsförordningen (GDPR) är den största förändringen i dataskyddslagstiftningen i Europa sedan Europaparlamentets dataskyddsdirektiv 95/46/EG infördes 1995. Mer information om GDPR finns på översiktssidan i Microsoft Trust Center.

Datahemvist och suveränitet

Azure DevOps är tillgängligt på följande åtta geografiska platser över hela världen: USA, Kanada, Europa, Storbritannien, Indien, Australien, Asien och Stillahavsområdet och Brasilien. Som standard tilldelas din organisation till din närmaste plats. Du kan dock välja en annan plats när du skapar din organisation. Om du ändrar dig senare kan du migrera organisationen till en annan plats med hjälp av Microsoft-supporten.

Azure DevOps flyttar eller replikerar inte kunddata utanför den valda platsen. I stället geo-replikeras dina data till en andra region på samma plats. Det enda undantaget är Brasilien, som replikerar data till regionen USA, södra centrala i haveriberedskapssyfte.

Kommentar

För versioner och versioner som körs på MacOS-agenter som tillhandahålls av Microsoft överförs dina data till ett GitHub-datacenter i USA.

Mer information finns i Dataplatser för Azure DevOps.

Åtkomst till brottsbekämpning

I vissa fall kan tredje part, till exempel brottsbekämpande entiteter, kontakta Microsoft för att få åtkomst till kunddata som lagras i Azure DevOps. Vi försöker omdirigera begäranden till organisationens ägare för lösning. När ett domstolsbeslut tvingar Microsoft att lämna ut kunddata till en tredje part gör Microsoft en rimlig ansträngning för att meddela organisationens ägare i förväg, såvida vi inte är lagligt förbjudna att göra det.

Vissa kunder behöver sin datalagring på en viss geografisk plats för att säkerställa en specifik rättslig jurisdiktion för alla brottsbekämpande aktiviteter. Alla kunddata, till exempel källkod, arbetsobjekt, testresultat och geo-redundanta speglar och säkerhetskopieringar utanför platsen, underhålls på någon av de tidigare nämnda platserna.

Microsoft-åtkomst

Då och då måste Microsoft-anställda få åtkomst till kunddata som lagras i Azure DevOps. Som en försiktighetsåtgärd måste alla anställda som har (eller kanske någonsin har) åtkomst till kunddata klara en bakgrundskontroll som inkluderar tidigare anställnings- och brottmålsdomar. Vi tillåter endast åtkomst till produktionssystemen när det finns en liveplatsincident eller annan godkänd underhållsaktivitet som loggas och övervakas.

Eftersom inte alla data i vårt system behandlas på samma sätt klassificerar vi data i följande typer:

  • Kunddata: Vad du laddar upp till Azure DevOps.
  • Organisationsdata: Information som du skickar när du registrerar dig för eller administrerar din organisation.
  • Microsoft-data: Information som krävs för eller samlas in genom driften av tjänsten.

Baserat på klassificeringen kontrollerar vi användningsscenarier, geoplatskrav, åtkomstbegränsningar och kvarhållningskrav.

Microsofts kampanjanvändning

Microsoft vill ibland kontakta kunder för att informera dem om fler funktioner och tjänster som kan vara användbara. Eftersom inte alla kunder vill bli kontaktade om dessa erbjudanden kan du välja att inte använda e-postkommunikation för marknadsföring.

Microsoft använder aldrig kunddata för att rikta in sig på specifika erbjudanden för specifika användare eller organisationer. I stället använder vi organisationsdata och sammanställd användningsstatistik på organisationsnivå för att fastställa grupper som ska ta emot specifika erbjudanden.

Skapa förtroende

Du kan vara säker på andra ansträngningar som Microsoft gör för Azure DevOps. Dessa insatser omfattar interna implementeringsprinciper på Microsoft, insyn i tjänstens tillstånd och framsteg mot att få certifiering av våra system för hantering av informationssäkerhet.

Intern implementering

Microsoft-team implementerar Azure DevOps internt. Azure DevOps-teamet flyttade till en organisation 2014 och använder den i stor utsträckning. Vi har upprättat riktlinjer för att möjliggöra implementeringsplaner för andra team.

Stora team rör sig mer gradvis än mindre på grund av sina investeringar i befintliga DevOps-system. För team som rör sig snabbt etablerade vi en metod för projektklassificering. Den utvärderar risktolerans, baserat på projektegenskaper, för att avgöra om projektet är lämpligt för Azure DevOps. För större team sker implementeringen vanligtvis i faser, med mer planering.

Fler krav för interna projekt är att associera organisationen med Microsoft Entra-ID för att säkerställa rätt livscykel för användaridentitet och lösenordskomplexitet. Projekt som är känsligare kräver också tvåfaktorautentisering.

Certifieringar för efterlevnad

Du kanske är intresserad av att förstå utvärderingar från tredje part av våra procedurer för datasäkerhet. Azure DevOps har uppnått följande certifieringar:

  • ISO 27001:2013
  • ISO 27018:2019
  • ISO 26262:2023
  • HIPAA (Health Insurance Portability and Accountability Act)
  • Business Associate Agreement (BAA)
  • EU:s modellklausuler
  • System- och organisationskontroller (SOC) 1 typ 2
  • SOC 2-typ 2
  • Tyskland C5
  • Australia IRAP
  • ENS-Spanien

SOC-granskningen för Azure DevOps omfattar kontroller för datasäkerhet, tillgänglighet, bearbetningsintegritet och konfidentialitet. SOC-rapporterna för Azure DevOps är tillgängliga via Microsoft Service Trust Portal.

Caiq (Consensus Assessment Initiative Questionnaire) hjälper organisationer att utvärdera säkerhetsrutiner och funktioner hos molntjänstleverantörer. I enlighet med vårt engagemang för säkerhet och transparens slutförde vi nyligen CAIQ-utvärderingen för Azure DevOps. Vi inbjuder dig att granska den fullständiga rapporten på Microsoft Service Trust Portal.

Steg som du kan vidta

Korrekt dataskydd kräver aktivt engagemang från dig, dina administratörer och dina användare. Dina projektdata som lagras i Azure DevOps är bara lika säkra som användarens åtkomstpunkter. Matcha behörighetsnivån strikthet och kornighet för dessa organisationer med projektets känslighetsnivå.

Klassificera dina data

Det första steget är att klassificera dina data. Klassificera data baserat på känslighet och riskhorisont, tillsammans med de skador som kan uppstå om de komprometteras. Många företag har befintliga klassificeringsmetoder som de kan återanvända när projekt flyttas till Azure DevOps. Mer information finns i Ladda ned Dataklassificering för molnberedskap från Microsoft Trustworthy Computing.

Anta Microsoft Entra-ID

Använd Microsoft Entra-ID för att hantera din organisations åtkomst till Azure DevOps. Microsoft Entra-ID är ett annat sätt att förbättra säkerheten för dina användares autentiseringsuppgifter.

Med Microsoft Entra-ID kan IT-avdelningen hantera sin användaråtkomstprincip, lösenordskomplexitet, lösenordsuppdateringar och upphörande när användarna lämnar organisationen. Via Active Directory-federation kan du direkt länka Microsoft Entra-ID:t till organisationens centrala katalog, så att du bara har en plats för att hantera den här informationen för ditt företag.

I följande tabell jämförs Microsoft-konto- och Microsoft Entra-egenskaper i förhållande till Azure DevOps-åtkomst:

Property Microsoft-konto Microsoft Entra ID
Identitetsskapare User Organisation
Enskilt användarnamn och lösenord för alla arbetstillgångar Nej Ja
Lösenordslivslängd och komplexitetskontroll User Organisation
Begränsningar för Azure DevOps-medlemskap Alla Microsoft-konton Organisationens katalog
Spårningsbar identitet Nej Ja
Organisations- och IP-ägarskap Oklar Organisation
Registrering av tvåfaktorsautentisering User Organisation
Enhetsbaserad villkorsstyrd åtkomst Nej Organisation

Läs mer om hur du konfigurerar det här stödet för din organisation.

Kräva tvåfaktorautentisering

Du kanske vill begränsa åtkomsten till din organisation genom att kräva mer än en faktor för att logga in. Du kan kräva flera faktorer med hjälp av Microsoft Entra-ID. Du kan till exempel kräva telefonautentisering, förutom ett användarnamn och lösenord, för alla autentiseringsbegäranden.

Använda BitLocker

För känsliga projekt kan du använda BitLocker på din bärbara Windows-dator eller stationära dator. BitLocker krypterar hela enheten där Windows och dina data finns. När BitLocker är aktiverat krypteras automatiskt alla filer som du sparar på enheten. Om datorn hamnar i fel händer förhindrar BitLocker obehörig åtkomst till lokala kopior av data från dina projekt.

Begränsa användningen av alternativa autentiseringsuppgifter

Standardautentiseringsmekanismen för Git-relaterade verktyg är alternativ autentisering (kallas ibland grundläggande autentisering). Med den här mekanismen kan en användare konfigurera ett alternativt användarnamn och lösenord för användning under Git-kommandoradsåtgärder. Användaren kan använda den här kombinationen av användarnamn/lösenord för att komma åt andra data som användaren har behörighet för. Till sin natur är alternativa autentiseringsuppgifter mindre säkra än standard federerad autentisering.

Du kan fortfarande göra val för ökad säkerhet. All kommunikation skickas via HTTPS och det finns krav på lösenordskomplexitet. Din organisation bör fortsätta att utvärdera om den behöver fler principer för att uppfylla dina projekts säkerhetskrav.

Du kan inaktivera alternativa autentiseringsuppgifter om du bestämmer dig för att de inte uppfyller organisationens säkerhetskrav. Mer information finns i Ändra programanslutning och säkerhetsprinciper för din organisation.

Säker åtkomst till din organisation

Administratörer kan använda Microsoft Entra-ID för att styra åtkomsten till Azure-resurser och program, till exempel Azure DevOps. Med villkorsstyrd åtkomstkontroll på plats söker Microsoft Entra-ID efter de specifika villkor som du har angett för att en användare ska få åtkomst till ett program. När användaren uppfyller åtkomstkraven autentiseras användaren och kan komma åt programmet.

Azure DevOps stöder framtvingande av vissa typer av principer för villkorlig åtkomst (till exempel IP-stängsel) för anpassade Azure DevOps-autentiseringsmekanismer. Dessa mekanismer omfattar personliga åtkomsttoken, alternativ autentisering, OAuth- och SSH-nycklar (Secure Shell). Om dina användare får åtkomst till Azure DevOps via en klient från tredje part respekteras endast IPv4-baserade principer.

Fler resurser