Übersicht zum Datenschutz

Azure DevOps Services

Azure DevOps Services ist eine in der Cloud gehostete Anwendung für Ihre Entwicklungsprojekte, von der Planung bis zur Bereitstellung. Basierend auf den lokalen Fähigkeiten, mit weiteren Cloud-Diensten, verwalten wir Ihren Quellcode, Arbeitsaufgaben, Erstellungen und Tests. Azure DevOps verwendet PaaS-Infrastruktur (Platform-as-a-Service) und viele Azure-Dienste, einschließlich Azure SQL, um einen zuverlässigen, global verfügbaren Dienst für Ihre Entwicklungsprojekte bereitzustellen.

In diesem Artikel werden die Schritte erläutert, die Microsoft unternimmt, um Ihre Projekte sicher, verfügbar, sicher und privat zu halten. Es beschreibt die Rolle, die Sie bei der Sicherung und Sicherheit Ihrer Projekte spielen.

Dieser Artikel richtet sich an Organisationsadministratoren und IT-Profis, die ihre Projektbestände täglich verwalten. Es ist am nützlichsten für Benutzer, die bereits mit Azure DevOps vertraut sind und mehr darüber erfahren möchten, wie Microsoft gespeicherte Bestände in Azure DevOps schützt.

Unser Ziel

Microsoft trägt dazu bei, dass Ihre Projekte ohne Ausnahme sicher bleiben. Wenn Sie Ihre Projekte in Azure DevOps speichern, profitieren sie von mehreren Schichten von IT-Sicherheit und Governance-Technologien, betrieblichen Praktiken und Kompatibilitätsrichtlinien. Wir erzwingen Datenschutz und Integrität sowohl im Ruhezustand als auch bei der Übertragung.

Die Bedrohungen, denen Sie gegenüberstehen, fallen in vier grundlegende Kategorien: Datenverfügbarkeit, Dienstverfügbarkeit, Dienstsicherheit und Datenschutz. Dieser Artikel untersucht spezifische Bedrohungen innerhalb jeder Kategorie und erklärt, was Azure DevOps tut, um sie zu adressieren. Der Artikel beginnt mit der Beschreibung, wie Daten gespeichert werden und wie Azure DevOps den Zugriff auf Ihre Daten verwaltet.

Schutz von Daten erfordert die aktive Bindung von Administratoren und Benutzern, die wissen, welche Schritte sie unternehmen müssen, um Ihre Aktiva vor unautorisierter Veröffentlichung und Manipulation zu schützen. Seien Sie explizit, wenn Sie Berechtigungen für Benutzerzugriffspunkte erteilen, damit nur die richtigen Kontakte auf Daten innerhalb von Azure DevOps zugreifen.

Sie sollten berücksichtigen, dass alle Daten potenziell gefährdet sind, unabhängig davon, wo sich die Daten befinden oder wie sie verwendet werden. Diese Anweisung gilt sowohl für Daten, die in der Cloud gespeichert sind, als auch für Daten, die in einem privaten Rechenzentrum gespeichert sind. Es ist wichtig, Ihre Daten, deren Sensibilität und Risiko sowie den Schaden, den sie verursachen könnten, wenn sie kompromittiert werden, zu klassifizieren. Außerdem sollten Sie Ihre Daten relativ zu einer übergeordneten Richtlinie für die Verwaltung der IT-Sicherheit kategorisieren.

Basierend auf Azure

Wir hosten Azure DevOps vollständig in Azure-Rechenzentren. Azure DevOps verwendet viele wichtige Azure-Dienste, einschließlich Compute, Speicher, Netzwerk, Azure SQL, Identitäts- und Zugriffsverwaltung und Azure Service Bus.

Azure DevOps verwendet Azure Storage als primäres Repository für Dienstmetadaten und Kundendaten. Abhängig vom Typ der Daten und den Speicher- und Abrufanforderungen verwendet Azure DevOps Azure Blob Storage und Azure SQL-Datenbank-Speicher.

Um Ihnen beim Verständnis des Azure DevOps-Dienstes Ansatzes zum Schutz von Daten zu helfen, hier ist etwas Hintergrund zu den Speicherdiensten:

• Azure Blob Speicher speichert sehr große Blöcke unstrukturierter Daten. Alle Projekte verwenden diesen Dienst. Daten umfassen potenziell vertrauliche oder private Informationen, z. B. den Inhalt von Quelldateien und Anlagen für Arbeitselemente. Für die meisten Projekte ist der meiste verwendete Speicher dieser Typ von unstrukturiertem Blob-Speicher.

• Azure SQL-Datenbank speichert die strukturierten und transaktionalen Aspekte Ihrer Organisation, einschließlich Projektmetadaten, des versionierten Quellcodeverwaltungsverlaufs und Details von Arbeitsaufgaben. Datenbankspeicher ermöglicht Ihnen schnellen Zugriff auf die wichtigen Elemente Ihres Projekts. Es bietet Indizes im Blob-Speicher, um Dateien und Anlagen nachzuschlagen.

Administratoren können den Zugriff auf Ressourcen verwalten, indem sie Berechtigungen für Benutzeridentitäten oder Gruppen erteilen oder einschränken . Azure DevOps verwendet Partner-Authentifizierung von Benutzeridentitäten über Microsoft Entra ID und Microsoft-Konten.

Während der Authentifizierung wird der Benutzer an den Authentifizierungsanbieter weitergeleitet, wo er seine Anmeldeinformationen angibt. Nachdem der Authentifizierungsanbieter die Benutzeranmeldeinformationen überprüft hat, stellt Azure DevOps dem Benutzer ein Authentifizierungs-Cookie aus. Dieses Cookie erlaubt es dem Benutzer, gegen Azure DevOps authentifiziert zu bleiben.

Auf diese Weise werden die Anmeldeinformationen des Benutzers nie direkt mit Azure DevOps freigegeben. Für jede Azure DevOps Ressource, auf die der Benutzer zugreifen möchte, basiert die Validierung der Berechtigungen auf den expliziten Berechtigungen des Benutzers und auf den Berechtigungen, die der Benutzer durch die Mitgliedschaft in einer Gruppe erbt.

Administratoren können Zugriffssteuerungen verwenden, um den Zugriff auf die Organisation, Projektsammlungen, Teamprojekte sowie teambezogene Daten und Funktionen zu schützen. Administratoren können auch Zugriffssteuerungen für spezifische Bestände wie Ordner für die Versionskontrolle und Bereichspfade für Arbeitsaufgaben verwenden.

Datenverfügbarkeit

Azure DevOps verwendet viele Azure Speicherfunktionen, um die Datenverfügbarkeit sicherzustellen, falls es zu einem Hardwarefehler, einer Dienstunterbrechung oder einer regionalen Katastrophe kommt. Außerdem folgt das Azure DevOps Team Prozeduren, um Daten vor versehentlichem oder böswilligem Löschen zu schützen.

Datenredundanz

Um Daten während Hardware- oder Dienstfehlern zu schützen, geo-repliziert Azure Speicher Debitor-Daten zwischen zwei Bereichen im gleichen geografischen Ort. Zum Beispiel kann Azure Speicher Daten zwischen Nord- und Westeuropa oder zwischen Nord- und Süd-United States geo-replizieren.

Für Azure Blob-Speicher werden Kundendaten dreimal innerhalb eines einzigen Bereichs repliziert. Kundendaten werden asynchron in einen zweiten Bereich im selben geografischen Ort repliziert. Daher verwaltet Azure immer das Äquivalent von sechs Kopien Ihrer Daten.

Das Vorhandensein mehrerer Kopien ermöglicht es Ihnen, bei einem größeren Ausfall oder einer Katastrophe auf einen separaten Bildbereich umzuschalten, während gleichzeitig eine lokale Redundanz für Hardwarefehler innerhalb eines Bereichs besteht. Für Azure SQL Datenbankspeicher werden tägliche Sicherungen außerhalb des Standorts verwaltet, wenn es zu einem regionalen Notfall kommt.

In Bezug auf Datenredundanz und Failover:

• Es gibt ein inhärentes Delta, das in Minuten gemessen wird, wenn Microsoft Ihre Daten zwischen der primären und der sekundären Region repliziert.
• Failover auf die sekundäre Region ist eine Entscheidung, die Microsoft zentral treffen muss, da sie alle Kunden in einer bestimmten Skalierungseinheit betrifft. Außer in Ausnahmefällen vermeidet Microsoft, ein Failover durchzuführen, damit Kundendaten nicht verloren gehen.
• Azure DevOps bietet eine Vereinbarung zum Servicelevel (SLA) mit einer Verfügbarkeit von 99,9 Prozent. Azure DevOps erstattet einen Teil der monatlichen Gebühren, wenn es in einem bestimmten Monat das SLA nicht einhält.
• Da es in Brasilien nur einen Bereich gibt, werden Debitorendaten in Brasilien zur Notfallwiederherstellung in den Bereich South Central US repliziert.

Fehler passieren

Um gegen versehentlichen Datenverlust zu schützen, setzt Microsoft auf Zeitpunktplan-Datensicherungen sowohl für Blobs, die im Azure Blob Speicher gespeichert sind, als auch für Datenbanken innerhalb der Azure SQL-Datenbank. Jedes Speicher-Konto hält eine separate Kopie aller Blobs, wobei Änderungen an die vorhandenen Daten angefügt werden. Diese Sicherungen sind unveränderlich, wodurch die Notwendigkeit entfällt, vorhandenen Speicher während der Sicherungsprozeduren neu zu schreiben.

Azure SQL-Datenbank beinhaltet standardmäßige Datensicherungsfunktionen, die von Azure DevOps genutzt werden. Ihre Daten werden für 28 Tage aufbewahrt, wobei diese Datensicherungen auch in einem gekoppelten Bereich repliziert werden, um die Wiederherstellung während eines regionalen Ausfalls zu erleichtern.

Sie können gelöschte Organisationen oder Projekte innerhalb des 28-Tage-Fensters nach dem Löschen wiederherstellen. Aber sobald dieser Zeitraum verstrichen ist, werden diese Entitäten endgültig gelöscht und können nicht wiederhergestellt werden. Während diese Datensicherungen als eine wesentliche Komponente für die Notfallwiederherstellung dienen, ist es für Kunden unerlässlich, geeignete Datenmanagement- und Sicherungsstrategien zu praktizieren, um einen umfassenden Schutz ihrer Daten zu gewährleisten.

Wichtig

• Unbeabsichtigtes Löschen bezieht sich hier auf Szenarien, die als Ergebnis eines Vorfalls auf unseren Diensten entstehen. Das versehentliche Löschen von Assets (z. B. Repositories, Arbeitselemente, Anhänge oder Artefakte) durch Kunden wird nicht berücksichtigt.
• Wir bieten keinen Support für die Wiederherstellung von Beständen, die Kunden versehentlich löschen. Diese Datensicherungen sind nur für die Geschäftskontinuität und zur Unterstützung der Wiederherstellung von Ausfällen oder Katastrophenszenarien gedacht.
• In seltenen Fällen kann unser Löschvorgang bis zu 70 Tage dauern, da Back-End-Wiederholungen erforderlich sind und die Daten aus mehreren Quellen gelöscht werden müssen.

Praxis ist entscheidend

Es ist gut, mehrere Sicherungen Ihrer Daten zu haben, aber ohne Übung kann die Wiederherstellung unvorhersehbar sein. Man sagt, dass „Backups nie versagen; die Wiederherstellung schon.“ Auch wenn diese Aussage technisch gesehen nicht korrekt ist, stimmt sie doch.

Microsoft übt regelmäßig die Wiederherstellung von Datasets aus der Datensicherung. Wir führen regelmäßig Tests des geo-redundanten Speichers von Azure durch. Es gibt viele Kombinationen von Katastrophen- und Datenbeschädigungs-Szenarien. Wir planen und führen regelmäßig neue Tests für diese Szenarien aus.

-Dienstverfügbarkeit

Azure DevOps bietet DDoS-Schutz (Distributed Denial-of-Service) und Live-Websiteantworten, um sicherzustellen, dass Sie Zugriff auf Ihre organization und zugehörigen Ressourcen haben.

DDoS-Schutz

In einigen Fällen kann ein böswilliger DDoS-Angriff die Dienstverfügbarkeit beeinträchtigen. Azure verfügt über ein DDoS-Verteidigungssystem, mit dem Angriffe auf unseren Dienst verhindert werden können. Es verwendet Standarderkennungs- und Entschärfungstechniken wie SYN-Cookies, Ratenbegrenzung und Verbindungslimits. Das System ist so konzipiert, dass es Angriffen nicht nur von außen, sondern auch innerhalb von Azure standhält.

Für anwendungsspezifische Angriffe, die die Azure-Verteidigungssysteme durchdringen können, legt Azure DevOps Vorgaben und Einschränkungen auf Anwendungsebene und Organisationsebene fest. Diese bewährte Methode hilft, jede Überfüllung von Schlüssel-Dienstressourcen während eines Angriffs oder bei versehentlicher Fehlverwendung von Ressourcen zu verhindern.

Live-Websiteantwort

In seltenen Fällen benötigen Sie möglicherweise eine Live-Websiteantwort auf ein Problem mit der Dienstverfügbarkeit. Wir haben ein Operationsteam, das ständig verfügbar ist, um das Problem schnell zu identifizieren und die notwendigen Teamressourcen der Entwickler zu engagieren.

Die Teamressourcen adressieren dann das Problem. Sie zielen auch darauf ab, die Servicequalität-Seite innerhalb von Minuten nach der Erkennung eines Problems, das den Dienst betrifft, zu aktualisieren. Nachdem Teamressourcen ein Problem adressieren, identifizieren sie die Ursache und verfolgen die notwendigen Änderungen, um ähnliche Probleme in der Zukunft zu verhindern.

Azure DevOps-Prozesse für das Management von Live Services konzentrieren sich auf Ihre Erfahrung und die Integrität des Dienstes. Diese Prozesse minimieren die Zeit zum Erkennen, Reagieren und Beheben von Problemen. Alle technischen Disziplinen sind beteiligt und verantwortlich, sodass kontinuierliche Verbesserungen aus direkter Erfahrung entstehen. Überwachungs-, Diagnose-, Resilienz- und Qualitätssicherungsprozesse verbessern sich dann im Laufe der Zeit.

Die Live-Websiteverwaltung in Azure DevOps verfügt über drei verschiedene Spuren: Telemetrie, Incidentverwaltung und Live-Websiteüberprüfung. Diese Tracks beinhalten Folgendes:

Das Betriebsteam überwacht auch die Verfügbarkeitsmetriken für einzelne Organisationen. Diese Metriken bieten Einblicke in bestimmte Bedingungen, die sich nur auf einige unserer Kunden auswirken können. Untersuchungen dieser Daten können häufig zu gezielten Verbesserungen führen, um kundenspezifische Probleme zu beheben. In einigen Fällen kann Sich Microsoft sogar direkt mit Ihnen in Verbindung setzen, um Ihre Erfahrung zu verstehen und gemeinsam mit Ihnen den Dienst zu verbessern.

Microsoft veröffentlicht ein SLA und bietet eine finanzielle Garantie, um sicherzustellen, dass wir diese Vereinbarung jeden Monat einhalten. Weitere Informationen finden Sie unter SLA für Azure DevOps.

Manchmal haben Partner-Teams oder Abhängigkeiten Vorfälle, die Azure DevOps beeinflussen. Alle Partnerteams verfolgen ähnliche Ansätze, um diese Dienstausfälle zu identifizieren, zu beheben und daraus zu lernen.

Dienstsicherheit

Die Dienstsicherheit erfordert eine ständige Wachsamkeit, von ordnungsgemäßen Entwurfs- und Codierungstechniken bis hin zu operativen Faktoren. Microsoft investiert aktiv in die Verhinderung von Sicherheitslücken und in die Erkennung von Sicherheitsverletzungen. Im Falle einer Sicherheitsverletzung verwendet Microsoft Sicherheitsreaktionspläne, um Datenlecks, -verluste oder -beschädigungen zu minimieren. Weitere Informationen finden Sie unter Informationen zu Sicherheit, Authentifizierung und Autorisierung.

Sicherheit durch Design

Azure DevOps ist so konzipiert, dass es sicher ist. Azure DevOps verwendet den Microsoft Security Development Lifecycle als Kern des Entwicklungsprozesses. Das Microsoft Operational Security Assurance Programm leitet die Cloud-Operation-Prozeduren in Azure DevOps.

Das Azure DevOps Team hat jährliche Training-Anforderungen für alle Modul- und Operation-Personal. Das Team sponsert auch informelle Besprechungen, die von Microsoft-Ingenieuren gehostet werden. Nachdem das Team ein Problem, das in einer Besprechung auftritt, löst, gibt es die gesammelten Erfahrungen an andere Teams weiter.

Die folgenden Methoden spezifizieren die Training-Anforderungen:

• Gefahrenmodell während des Dienstdesigns
• Folgen der bewährten Methode für Design und programmieren
• Überprüfung der IT-Sicherheit mit Standard-Tooling und Tests
• Begrenzung des Zugriffs auf operative und Kundendaten
• Begrenzung des Rollout neuer Funktionen durch einen strengen Genehmigungsprozess

Ein Clouddienst ist nur so sicher wie die Hostplattform. Azure DevOps verwendet PaaS für einen Großteil der Infrastruktur. PaaS stellt automatisch regelmäßige Updates für bekannte Sicherheitslücken bereit.

Virtuelle Maschinen, die in Azure gehostet werden, nutzen Infrastruktur als Dienst (IaaS), wie zum Beispiel für einen gehosteten Erstellungsdienst. Solche Images werden regelmäßig aktualisiert, um die neuesten Sicherheitspatches einzuschließen, die von Windows Update verfügbar sind. Das gleiche Aktualisierungsverfahren gilt für lokale Computer, einschließlich der Computer, die für die Bereitstellung, Überwachung und Berichterstellung verwendet werden.

Das Azure DevOps-Team führt regelmäßige, sicherheitsorientierte Penetrationstests von Azure DevOps durch. Penetrationstests versuchen, die Live-Produktionsdienste und die Infrastruktur von Azure DevOps auszunutzen, indem sie dieselben Techniken und Mechanismen verwenden, die böswillige Benutzer nutzen. Das Ziel besteht darin, reale Sicherheitsrisiken, Konfigurationen, Fehler oder andere Sicherheitslücken in einem kontrollierten Prozess zu identifizieren.

Das Team prüft die Ergebnisse dieser Tests, um andere Bereiche zur Verbesserung zu identifizieren und die Qualität der präventiven Systeme und des Trainings zu erhöhen. Sie können die Ergebnisse der aktuellen Azure DevOps-Penetrationstests auf dem Microsoft-Dienst-Vertrauensstellung-Portal prüfen.

Sicherheit von Anmeldeinformationen

Microsoft ist verpflichtet sicherzustellen, dass Ihre Projekte ohne Ausnahme sicher und geschützt bleiben. In Azure DevOps profitieren Ihre Projekte von mehreren Schichten von Sicherheit und Governance-Technologien, betrieblichen Praktiken und Einhaltung Richtlinien. Wir erzwingen Datenschutz und Integrität sowohl im Ruhezustand als auch bei der Übertragung. Darüber hinaus halten wir uns an die folgenden bewährten Methoden in Bezug auf die Anmeldeinformationen oder Geheimnisse, die Azure DevOps speichert. Um Weitere Info darüber zu erhalten, wie Sie den richtigen Zugriffsmechanismus auswählen, siehe Leitfaden für Authentifizierung.

Wichtig

Azure DevOps unterstützt keine alternativen Verfahren zur Authentifizierung von Anmeldeinformationen. Wenn Sie dennoch alternative Anmeldeverfahren verwenden, empfehlen wir Ihnen dringend, zu einer Authentifizierungsmethode zu wechseln, die mehr Sicherheit bietet.

Privat-Zugriffstoken (PATs)

• Wir speichern einen Hash des PAT.
• Raw-PATs werden auf der Serverseite im Arbeitsspeicher generiert. 32 zufällige Bytes werden durch den Kryptografiedienstanbieter generiert und als base-32-codierte Zeichenfolge mit dem Anrufer freigegeben. Dieser Wert wird NICHT gespeichert.
• Der PAT-Hash wird auf der Serverseite im Speicher als HMACSHA256Hash des raw-PAT unter Verwendung eines symmetrischen 64-Byte-Schlüssels erzeugt, der in unserem Schlüsseltresor gespeichert ist.
• Hash wird in unserer Datenbank gespeichert.

Sichere Shell (SSH) Schlüssel

• Wir speichern einen Hash der umgebenden Organisations-ID und des SSH-öffentlichen Schlüssels.
• Rohe öffentliche Schlüssel werden direkt vom Anrufer über SSL bereitgestellt.
• Der SSH-Hash wird serverseitig als HMACSHA256Hash der Organisations-ID und des öffentlichen raw-Schlüssels unter Verwendung eines symmetrischen 64-Byte-Schlüssels, der in unserem Schlüsseltresor gespeichert ist, im Speicher generiert.
• Hash wird in unserer Datenbank gespeichert.

OAuth-Anmeldeinformationen (JWTs)

• OAuth-Anmeldeinformationen werden als vollständig selbstbeschreibende JSON-Web-Token (JWTs) ausgegeben und nicht in unserem Dienst gespeichert.
• Die Ansprüche in JWTs, die ausgestellt und unserem Dienst präsentiert werden, werden mit einem Zertifikat überprüft, das in unserem Schlüssel-Tresor gespeichert ist.

Bericht über Sicherheitslücken

Wenn Sie glauben, dass Ihr Penetrationtest eine potenzielle Sicherheitslücke im Zusammenhang mit dem Azure DevOps-Dienst aufgedeckt hat, melden Sie dies innerhalb von 24 Stunden an Microsoft. Weitere Informationen finden Sie auf der Microsoft-Webseite zur Meldung eines Computersicherheitsrisikos.

Wichtig

Obwohl Sie Microsoft nicht über Penetrationtest-Aktivitäten benachrichtigen müssen, müssen Sie die Microsoft Penetration Testing Rules of Engagement einhalten.

Bounty-Programm

Azure DevOps nimmt am Microsoft-Fehler-Prämienprogramm teil. Dieses Programm belohnt Sicherheitsexperten, die uns Probleme melden, und ermutigt mehr Kontakte, dabei zu helfen, Azure DevOps sicher zu halten. Für weitere Informationen siehe Microsoft Azure DevOps Bounty Programm.

Einschränken des Zugriffs

Microsoft kontrolliert streng, wer Zugriff auf unsere Produktionsumgebung und Kundendaten erhält. Wir gewähren Zugriff auf der Ebene der geringsten erforderlichen Rechte und nur nach Überprüfung der Ausrichtungen eines Benutzers. Wenn ein Teammitglied auf ein dringendes Problem zugreifen muss oder eine Konfigurationsänderung bereitstellen muss, müssen sie Just-In-Time-Zugriff auf den Produktionsdienst anwenden. Der Zugriff wird widerrufen, sobald die Situation behoben ist.

Wir nachverfolgen und monitoren Zugriffsanforderungen und Genehmigungen in einem separaten System. Alle Zugriffe auf das System korrelieren mit diesen Genehmigungen. Wenn wir unbefugtes zugreifen auf erkennen, senden wir eine Benachrichtigung an das Operationsteam zur Untersuchung.

Wir verwenden die zweistufige Authentifizierung für den gesamten Remotesystemzugriff. Wenn der Benutzername und das Kennwort eines unserer Entwickler oder des Betriebspersonals gestohlen werden, bleiben die Daten geschützt. Weitere Authentifizierungsüberprüfungen über Smartcard oder einen Telefonanruf an eine genehmigte Nummer müssen erfolgen, bevor wir irgendeinen Remotezugriff auf den Dienst gestatten.

Um den Dienst zu verwalten und zu pflegen, verwendet Microsoft Geheimnisse wie RDP-Kennwörter, SSL-Zertifikate und Verschlüsselungsschlüssel. Diese Geheimnisse werden alle verwaltet, gespeichert und sicher über das Azure-Portal übertragen. Jeder Zugriff auf diese Geheimnisse erfordert eine spezifische Berechtigung, die protokolliert und sicher aufgezeichnet wird. Alle Geheimnisse werden in regelmäßigen Abständen rotiert, und wir können sie bei Bedarf rotieren, wenn es ein Sicherheitsereignis gibt.

Das Azure DevOps-Betriebsteam verwendet gehärtete Administratorarbeitsstationen, um den Dienst zu verwalten. Diese Computer führen eine minimale Anzahl von Anwendungen aus und arbeiten in einer logisch segmentierten Umgebung.

Mitglieder des Betriebsteams müssen bestimmte Anmeldeinformationen mit zweistufiger Authentifizierung bereitstellen, um auf die Arbeitsstationen zugreifen zu können. Der gesamte Zugriff wird überwacht und sicher protokolliert. Um den Dienst vor Manipulationen von außen zu schützen, erlauben wir keine Anwendungen wie Outlook und Office, da sie oft Ziele von Spear-Phishing und anderen Arten von Angriffen sind.

Angriffsschutz und Reaktion

Wir verschlüsseln Daten über HTTPS und SSL, um Hilfe sicherzustellen, dass sie nicht abgefangen oder während des Übergangs zwischen Ihnen und Azure DevOps verändert werden. Daten, die wir in Ihrem Namen in Azure DevOps speichern, werden wie folgt verschlüsselt:

• Daten, die in Azure SQL-Datenbanken gespeichert sind, werden durch transparente Datenverschlüsselung verschlüsselt. Diese Funktion hilft, gegen böswillige Aktivitäten zu schützen, indem sie die Echtzeit-Verschlüsselung der Datenbank, der zugeordneten Datensicherungen und der Transportprotokolldateien im Ruhezustand durchführt.

• Azure Blob-Speicherverbindungen sind verschlüsselt, um Ihre Daten während der Übertragung zu schützen. Für ruhende Daten, die im Azure Blob Speicher gespeichert sind, verwendet Azure DevOps die Dienst-Verschlüsselung.

Das Azure DevOps Team verwendet die Azure Infrastruktur, um wichtige Aspekte des Dienstes zu protokollieren und zu überwachen. Protokollierung und Überwachung helfen sicherzustellen, dass Aktivitäten innerhalb des Dienstes legitim sind, und sie helfen, Verstöße oder versuchte Verstöße zu erkennen.

Alle Bereitstellungs- und Administratoraktivitäten werden sicher protokolliert, ebenso wie der Operatorzugriff auf den Produktionsspeicher. Die Protokollinformationen werden automatisch analysiert, und jedes potenziell böswillige oder unautorisierte Verhalten löst Echtzeit-Benachrichtigungen aus.

Wenn das Azure DevOps Team eine mögliche Sicherheitslücke oder ein wichtiges Sicherheitsrisiko identifiziert, hat es einen klaren Plan zur Antwort. Dieser Plan enthält die zuständigen Parteien, erforderliche Schritte zur Sicherung der Kundendaten und Anweisungen, wie Sie mit den Sicherheitsexperten bei Microsoft in Kontakt treten können. Das Team benachrichtigt auch alle organization Besitzer, wenn Daten offengelegt oder beschädigt wurden, damit sie geeignete Maßnahmen ergreifen können, um die Situation zu beheben.

Um bei der Bekämpfung neuer Bedrohungen zu helfen, setzt Azure DevOps eine Annahme einer Verletzung-Strategie ein. Ein hochspezialisiertes Team von Sicherheitsexperten innerhalb von Microsoft übernimmt die Rolle von raffinierten Angreifern. Dieses Team testet die Erkennung und Reaktion auf Sicherheitsverletzungen, um die Bereitschaft und die Auswirkungen realer Angriffe genau zu messen. Diese Strategie stärkt die Bedrohungserkennung, -reaktion und -verteidigung des Diensts. Es ermöglicht dem Team auch, die Effektivität des gesamten Sicherheitsprogramms zu überprüfen und zu verbessern.

Schutz vor Ransomware-Angriffen

Azure DevOps nutzt Azure-Kontrollen, um bei der Prävention, Erkennung und Antwort auf einen Ransomware-Angriff zu helfen. Für weitere Informationen darüber, wie Azure hilft, Kunden vor Ransomware-Angriffen zu schützen, siehe Ransomware-Schutz in Azure.

Datenschutz

Sie sollten Vertrauen haben, dass wir Ihre Daten angemessen und für legitime Zwecke behandeln. Ein Teil dieser Qualitätssicherung besteht darin, den Verbrauch sorgfältig einzuschränken.

Datenschutz-Grundverordnung

Die Datenschutz-Grundverordnung (DSGVO) ist die größte Änderung der Datenschutzgesetze in Europa seit der Einführung der Datenschutzrichtlinie 95/46/EG der Europäischen Union (95/46/EG) im Jahr 1995. Für weitere Informationen über die DSGVO, siehe die Übersichtsseite im Microsoft Sicherheitscenter.

Datenresidenz und Souveränität

Azure DevOps ist an den folgenden acht Standorten weltweit verfügbar: USA, Kanada, Europa, Vereinigtes Königreich, Indien, Australien, Asien-Pazifik und Brasilien. Standardmäßig wird Ihrer Organisation Ihr nächster Ort zugewiesen. Sie können jedoch einen anderen Ort auswählen, wenn Sie Ihre Organisation erstellen. Wenn Sie später Ihre Meinung ändern, können Sie die Organisation mit Unterstützung von Microsoft-Support an einen anderen Ort migrieren.

Azure DevOps verschiebt oder repliziert keine Debitorendaten außerhalb des ausgewählten Ortes. Stattdessen werden Ihre Daten in einem zweiten Bereich innerhalb desselben Ortes geo-repliziert. Die einzige Ausnahme ist Brasilien, das Daten in den Bereich Süd-Zentral-USA für Notfallwiederherstellungszwecke repliziert.

Hinweis

Für Builds und Versionen, die auf von Microsoft bereitgestellten macOS-Agents ausgeführt werden, erfolgt die Datenübertragung zu einem GitHub-Rechenzentrum in den Vereinigten Staaten.

Für weitere Informationen siehe Datenorte für Azure DevOps.

Zugriff auf strafverfolgungsbezwingend

In einigen Anfragen könnten Drittanbieter wie Durchsetzungsentitäten Microsoft kontaktieren, um auf Debitorendaten zuzugreifen, die in Azure DevOps gespeichert sind. Wir versuchen, die Anforderungen zur Auflösung an den Organisationsbesitzer umzuleiten. Wenn eine gerichtliche Anordnung Microsoft zwingt, Kundendaten an einen Drittanbieter offenzulegen, unternimmt Microsoft angemessene Anstrengungen, den Organisationsbesitzer im Voraus zu benachrichtigen, es sei denn, wir sind gesetzlich daran gehindert.

Einige Kunden erfordern, dass ihr Speicher an einem bestimmten geografischen Ort erfolgt, um eine spezifische rechtliche Zuständigkeit für alle rechtlichen Durchsetzungen sicherzustellen. Alle Kundendaten, wie z. B. Quellcode, Arbeitselmente, Testergebnisse und georedundante Spiegelungen sowie Offsite-Backups, werden an einem der oben genannten Standorte aufbewahrt.

Microsoft Access

Von time zu time müssen Microsoft-Mitarbeiter auf Kundendaten zugreifen, die in Azure DevOps gespeichert sind. Als Vorsichtsmaßnahme müssen alle Mitarbeiter, die auf Kundendaten zugreifen können (oder jemals zugreifen könnten), eine Hintergrundüberprüfung bestehen, die frühere Beschäftigungen und strafrechtliche Verurteilungen umfasst. Wir erlauben den Zugriff auf die Produktionssysteme nur, wenn es einen Live-Standortvorfall oder eine andere genehmigte Wartungsaktivität gibt, die protokolliert und überwacht wird.

Da nicht alle Daten innerhalb unseres Systems gleich behandelt werden, klassifizieren wir Daten in diese Typen:

• Kundendaten: Was Sie zu Azure DevOps hochladen.
• Organisatorische Daten: Informationen, die Sie absenden, wenn Sie sich für Ihre Organisation registrieren oder diese verwalten.
• Microsoft-Daten: Informationen, die für die Operation des Dienstes erforderlich sind oder durch die Operation des Dienstes gesammelt werden.

Basierend auf der Klassifizierung steuern wir Nutzungsszenarien, Geografische Standortanforderungen, Zugriffsbeschränkungen und Aufbewahrungsanforderungen.

Microsoft-Werbenutzung

Microsoft möchte gelegentlich Kunden kontaktieren, um sie über weitere Funktionen und Dienste zu informieren, die nützlich sein könnten. Da nicht alle Kunden über diese Angebote kontaktiert werden möchten, können Sie die Marketing-E-Mail-Kommunikation deaktivieren und deaktivieren.

Microsoft verwendet niemals Kundendaten, um bestimmte Angebote für bestimmte Benutzer oder Organisationen anzusprechen. Stattdessen verwenden wir organization Daten und aggregierte Nutzungsstatistiken auf organization Ebene, um Gruppen zu ermitteln, die bestimmte Angebote erhalten sollen.

Verwalten von Datenschutzrichtlinien für Administratoren zum Steuern der Benutzerfeedbacksammlung

Mit dem Feedback-Umschalter-Feature können Besitzer der Azure DevOps-Organisation steuern, ob Benutzer aufgefordert werden, Feedback zu geben und sie zu übermitteln. Dieses Feature ist unerlässlich, um sicherzustellen, dass Feedbackpraktiken den Datenschutz- und Governancerichtlinien Ihrer Organisation entsprechen.

Vertrauensbildung

Sie können zuversichtlich in andere Bemühungen sein, die Microsoft im Namen von Azure DevOps unternimmt. Diese Bemühungen umfassen interne Richtlinien zur Annahme bei Microsoft, die Ebene der Transparenz in den Zustand unseres Dienstes und den Fortschritt in Richtung des Erhalts der Zertifizierung unserer Systeme zur Verwaltung der IT-Sicherheit.

Interne Einführung

Microsoft-Teams abonnieren intern Azure DevOps. Das Azure DevOps-Team ist 2014 in eine organization umgezogen und nutzt es ausführlich. Wir haben Richtlinien erstellt, um die Adoptionspläne für andere Teams zu aktivieren.

Größere Teams verschieben sich allmählicher als kleinere, aufgrund ihrer Investitionen in bestehende DevOps-Systeme. Für Teams, die sich schnell bewegen, haben wir einen Ansatz zur Projektklassifizierung etabliert. Es bewertet die Risikotoleranz basierend auf projektbezogenen Merkmalen, um zu ermitteln, ob das Projekt für Azure DevOps geeignet ist. Bei größeren Teams erfolgt die Einführung in der Regel in Phasen mit mehr Planung.

Weitere Anforderungen für interne Projekte umfassen die Zuordnung der Organisation mit Microsoft Entra ID, um den ordnungsgemäßen Identitätslebenszyklus der Benutzer und die Kennwortkomplexität sicherzustellen. Projekte, die sensibler sind, erfordern auch eine zweistufige Authentifizierung.

Compliancezertifizierungen

Sie könnten daran interessiert sein, die Auswertung von Drittanbietern unserer Prozeduren für IT-Sicherheit zu verstehen. Azure DevOps hat die folgenden Sicherheitszertifikate erreicht:

• ISO 27001:2022
• ISO 27018:2019
• ISO 26262:2023
• Health Insurance Portability and Accountability Act (HIPAA)
• Geschäftspartnervereinbarung (BAA)
• EU-Modellklauseln
• System- und Organisationssteuerungen (SOC) 1 Typ 2
• SOC 2, Typ 2
• Deutschland C5
• Australien IRAP
• ENS-Spanien

Die SOC-Überwachung für Azure DevOps umfasst Kontrollen für Datensicherheit, Verfügbarkeit, Verarbeitungsintegrität und Vertraulichkeit. Die SOC-Berichte für Azure DevOps sind über das Microsoft Service Trust Portal verfügbar.

Der Consensus Assessment Initiative Questionnaire (CAIQ) hilft Organisationen, die Sicherheitspraxis und Fähigkeiten von Cloud-Dienstanbietern zu bewerten und zu evaluieren. In Ausrichtung mit unserem Engagement für IT-Sicherheit und Transparenz haben wir kürzlich die CAIQ-Bewertung für Azure DevOps abgeschlossen. Wir laden Sie ein, den vollständigen Bericht auf dem Microsoft Service Trust Portal zu prüfen.

Schritte, die Sie ausführen können

Richtiger Schutz von Daten erfordert aktive Kundenbindung von Ihnen, Ihren Administratoren und Ihren Benutzern. Ihre Projektdaten, die in Azure DevOps gespeichert sind, sind nur so sicher wie die Benutzerzugriffspunkte. Passen Sie den Grad der Berechtigungsstrenz und Granularität für diese Organisationen mit der Vertraulichkeitsstufe Ihres Projekts ab.

Klassifizieren von Daten

Der erste Schritt besteht darin, Ihre Daten zu klassifizieren. Klassifizieren Sie Daten basierend auf Sensitivität und Risikohorizont sowie dem Schaden, der bei einer Kompromittierung auftreten könnte. Viele Unternehmen haben bestehende Klassifizierungsmethoden, die sie wiederverwenden können, wenn Projekte zu Azure DevOps verschoben werden. Für weitere Informationen können Sie Datenklassifizierung für die Cloud-Bereitschaft von Microsoft Trustworthy Computing herunterladen.

Microsoft Entra ID übernehmen

Verwenden Sie Microsoft Entra ID, um den Zugriff Ihrer Organisation auf Azure DevOps zu verwalten. Microsoft Entra ID bietet eine weitere Möglichkeit, die Sicherheit Ihrer Benutzeranmeldeinformationen zu verbessern.

Microsoft Entra ID ermöglicht Ihrer IT-Abteilung, die Benutzerzugriffsrichtlinie, die Kennwortkomplexität, das Aktualisieren der Kennwörter und den Ablauf zu verwalten, wenn Benutzer Ihre Organisation verlassen. Durch den Active Directory-Verbund können Sie Microsoft Entra ID direkt mit dem zentralen Verzeichnis Ihrer Organisation verknüpfen, sodass Sie nur einen Ort haben, um diese Details für Ihr Unternehmen zu verwalten.

Die folgende Tabelle vergleicht Microsoft Konto und Microsoft Entra Eigenschaften im Hinblick auf Azure DevOps zugreifen auf:

Eigenschaft	Microsoft-Konto	Microsoft Entra ID
Identitätsersteller	Benutzer	Organisation
Einzelner Benutzername und Kennwort für alle geschäftlichen Bestände	Nein	Ja
Kennwortlebensdauer und Komplexitätskontrolle	Benutzer	Organisation
Azure DevOps-Mitgliedschaftslimits	Jedes Microsoft-Konto	Verzeichnis der Organisation
Nachverfolgbare Identität	Nein	Ja
Organisation und IP-Besitz	Unklar	Organisation
Zweistufige Authentifizierungsregistrierung	Benutzer	Organisation
Gerätebasierter bedingter Zugriff	Nein	Organisation

Erfahren Sie mehr über das Konfigurieren dieses Supports für Ihre Organisation.

Anfordern der zweistufigen Authentifizierung

Möglicherweise möchten Sie den Zugriff auf Ihre organization einschränken, indem Sie mehr als einen Faktor für die Anmeldung benötigen. Sie können mehrere Faktoren mit Microsoft Entra ID verlangen. Beispielsweise können Sie die Telefonauthentifizierung zusätzlich zu einem Benutzernamen und kennwort für alle Authentifizierungsanforderungen anfordern.

Verwenden von BitLocker

Für sensible Projekte können Sie BitLocker auf Ihrem Windows-Laptop oder Desktopcomputer verwenden. BitLocker verschlüsselt das gesamte Laufwerk, auf dem sich Windows und Ihre Daten befinden. Wenn BitLocker aktiviert ist, werden alle Dateien, die Sie auf diesem Laufwerk speichern, automatisch verschlüsselt. Wenn Ihr Computer in die falschen Hände gerät, verhindert BitLocker den unautorisierten Zugriff auf lokale Kopien von Daten aus Ihren Projekten.

Einschränken der Verwendung alternativer Anmeldeinformationen für die Authentifizierung

Der Standard-Authentifizierungsmechanismus für Git-bezogene Tools ist die alternative Authentifizierung (manchmal auch Standardauthentifizierung genannt). Dieser Mechanismus ermöglicht es einem Benutzer, einen alternativen Benutzername und Kennwort für die Verwendung während Git-Befehlszeilenoperationen einzurichten. Der Benutzer kann diese Benutzername/Kennwort-Kombination verwenden, um auf alle anderen Daten zuzugreifen, für die dieser Benutzer Berechtigungen hat. Die Anmeldeinformationen für die alternative Authentifizierung sind naturerweise weniger sicher als die Standardverbundauthentifizierung.

Sie können weiterhin Entscheidungen für erhöhte Sicherheit treffen. Alle Kommunikation wird über HTTPS gesendet, und es gibt Anforderungen an die Kennwortkomplexität. Ihre Organisation sollte weiterhin auswerten, ob sie weitere Richtlinien benötigt, um die Sicherheitsanforderungen Ihrer Projekte zu erfüllen.

Sie können alternative Authentifizierungsanmeldeinformationen deaktivieren, wenn Sie feststellen, dass diese nicht den IT-Sicherheitsanforderungen Ihrer Organisation entsprechen. Weitere Informationen finden Sie unter Ändern von Anwendungsverbindungssicherheitsrichtlinien & für Ihre organization.

Schützen des Zugriffs auf Ihre organization

Administratoren können Microsoft Entra ID verwenden, um den Zugriff auf Azure-Ressourcen und Anwendungen wie Azure DevOps zu kontrollieren. Mit bedingter Zugriffssteuerung im Bereich prüft Microsoft Entra ID die spezifischen Bedingungen, die Sie für einen Benutzer festlegen, um auf eine Anwendung zuzugreifen. Nachdem der Benutzer die Zugriffsanforderungen erfüllt hat, wird der Benutzer authentifiziert und kann auf die Anwendung zugreifen.

Azure DevOps unterstützt das Erzwingen bestimmter Arten von Richtlinien für bedingten Zugriff (z. B. IP-Fencing) für benutzerdefinierte Azure DevOps-Authentifizierungsmechanismen. Diese Mechanismen umfassen Zugriffstoken, alternative Authentifizierung, OAuth und Secure Shell (SSH)-Schlüssel. Wenn Ihre Benutzer über einen Drittanbieter-Client auf Azure DevOps zugreifen, werden nur IPv4-basierte Richtlinien beachtet.

Weitere Ressourcen

• Azure DevOps Homepage
• Orte für Azure DevOps-Daten
• Datenschutzerklärung von Microsoft
• Azure DevOps-Support
• Funktionen und Dienste, die mit Azure DevOps enthalten sind
• Azure Trust Center
• Microsoft Security Development Lifecycle