Übersicht zum Datenschutz

Azure DevOps Services

Azure DevOps Services ist eine in der Cloud gehostete Anwendung für Ihre Entwicklungsprojekte, von der Planung bis hin zur Bereitstellung. Basierend auf den lokalen Funktionen mit zusätzlichen Clouddiensten verwalten wir Ihren Quellcode, Arbeitselemente, Builds und Tests. Azure DevOps verwendet die Plattform als Serviceinfrastruktur (PaaS) 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 ausführt, um Ihre Projekte sicher, verfügbar, sicher und privat zu halten. Außerdem beschreibt es die Rolle, die Sie spielen, um Ihre Projekte sicher und sicher zu halten.

Dieser Artikel ist für Organisationsadministratoren und IT-Experten vorgesehen, die ihre Projektressourcen täglich verwalten. Es ist am nützlichsten für Einzelpersonen, die bereits mit Azure DevOps vertraut sind und mehr darüber wissen möchten, wie Microsoft gespeicherte Ressourcen in Azure DevOps schützt.

Unser Engagement

Microsoft hilft, sicherzustellen, dass Ihre Projekte sicher und sicher bleiben, ohne Ausnahme. Wenn Sie in Azure DevOps gespeichert sind, profitieren Ihre Projekte von mehreren Sicherheits- und Governancetechnologien, betrieblichen Praktiken und Compliancerichtlinien. Wir erzwingen Datenschutz und Integrität sowohl im Ruhezustand als auch bei der Übertragung.

Die Bedrohungen, die Sie sehen, sind auf vier grundlegende Kategorien: Datenverfügbarkeit, Dienstverfügbarkeit, Dienstsicherheit und Datenschutz. In diesem Artikel werden bestimmte Bedrohungen in jeder Kategorie erläutert und erläutert, was Azure DevOps zur Behebung dieser Bedrohungen tut. Zunächst beschreibt der Artikel, wie Daten gespeichert werden und wie Azure DevOps den Zugriff auf Ihre Daten verwaltet.

Der Datenschutz erfordert ein aktives Engagement von Administratoren und Benutzern, die wissen müssen, welche Schritte zum Schutz Ihrer Ressourcen vor unbefugter Offenlegung und Manipulation erforderlich sind. Seien Sie explizit, wenn Sie Benutzern Zugriffspunkte erteilen, sodass nur die richtigen Personen innerhalb Azure DevOps auf Daten zugreifen.

Unabhängig von Ihrem Ansatz sollten Sie alle Daten potenziell "gefährdet" berücksichtigen, unabhängig davon, wo es sich befindet oder wie sie verwendet wird. Dies gilt sowohl für Daten in der Cloud als auch für Daten, die in einem privaten Rechenzentrum gespeichert sind. Es ist wichtig, Ihre Daten, ihre Vertraulichkeit und ihr Risiko zu klassifizieren, und die Schäden, die es tun könnte, wenn sie kompromittiert wird. Kategorisieren Sie Ihre Daten auch relativ zu einer allgemeinen Richtlinie zur Informationssicherheitsverwaltung.

Basiert auf Azure

Diagram of Azure DevOps high-level architecture.

Wir hosten Azure DevOps vollständig in Azure-Rechenzentren. Azure DevOps verwendet viele kerne 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 von der Art der Daten und der Speicher- und Abrufanforderungen verwendet Azure DevOps entsprechend Azure Blob Storage (für Binary Large Objects) und Azure SQL-Datenspeicher. Um den Azure DevOps Services-Ansatz für den Schutz von Daten zu verstehen, sind einige Hintergrundinformationen zu diesen Elementen wichtig.

  • Azure Blob Storage speichert große Blöcke unstrukturierter Daten. Alle Projekte verwenden den Azure Blob Storage-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 Großteil des verwendeten Speichers dieser Art unstrukturierter Blobspeicher. Weitere Informationen finden Sie unter Azure Blob Storage.

  • Azure SQL-Datenbank Speicher speichert die strukturierten und transaktionsalen Aspekte Ihrer Organisation, einschließlich Projektmetadaten, den versionsierten Quellcodeverwaltungsverlauf und Arbeitsaufgabendetails. Der Datenbankspeicher ermöglicht Ihnen schnellen Zugriff auf die wichtigen Elemente Ihres Projekts und stellt Indizes im Blobspeicher bereit, um Dateien und Anlagen nachzuschlagen. Weitere Informationen finden Sie unter Azure SQL-Datenbank.

Administratoren können den Zugriff auf Ressourcen verwalten, indem Sie Berechtigungen für Benutzeridentitäten oder Gruppen erteilen oder einschränken . Azure DevOps die Verbundauthentifizierung von Benutzeridentitäten über Azure Active Directory (Azure AD) und Microsoft-Konten verwendet.

Während der Authentifizierung wird der Benutzer an den Authentifizierungsanbieter weitergeleitet, wo er seine Anmeldeinformationen bereitstellt. Nachdem der Authentifizierungsanbieter die Anmeldeinformationen des Benutzers überprüft hat, stellt Azure DevOps dem Benutzer ein Authentifizierungscookies aus, wodurch der Benutzer bei Azure DevOps authentifiziert bleiben kann.

Auf diese Weise werden die Anmeldeinformationen des Benutzers nie direkt mit Azure DevOps geteilt. Für jede Azure DevOps Ressource, auf die der Benutzer zugreifen möchte, werden Berechtigungen basierend auf den expliziten Berechtigungen des Benutzers sowie über die Gruppenmitgliedschaft geerbten Berechtigungen überprüft. Administratoren können Zugriffssteuerungen verwenden, um den Zugriff auf die Organisation, Projektsammlungen, Teamprojekte und Funktionen im Teambereich zu schützen. Administratoren können auch spezifischere Ressourcen wie Versionsverwaltungsordner und Arbeitsaufgabenbereichspfade schützen.

Datenverfügbarkeit

Azure DevOps verwendet viele Azure Storage Features, um die Verfügbarkeit von Daten sicherzustellen, wenn ein Hardwarefehler, eine Dienstunterbrechung oder ein Regionsausfall vorliegt. Außerdem folgt das Azure DevOps Team Verfahren zum Schutz von Daten vor versehentlichem oder schädlichem Löschen.

Datenredundanz

Um Daten während Hardware- oder Dienstfehlern zu schützen, repliziert Azure Storage Kundendaten zwischen zwei Regionen in derselben Geografie. Beispielsweise kann Azure Daten zwischen Nord- und Westeuropa oder zwischen Nord- und Süd-USA replizieren.

Für Azure Blob Storage werden Kundendaten dreimal innerhalb einer einzelnen Region repliziert und asynchron in eine zweite Region in derselben Geographie repliziert. Azure behält daher immer die Äquivalente von sechs Kopien Ihrer Daten bei. Auf diese Weise können Sie zu einer separaten Region fehlschlagen, wenn es einen großen Ausfall oder eine Katastrophe gibt, während auch lokale Redundanzen für Hardwarefehler innerhalb einer Region vorhanden sind. Für Azure SQL-Datenbank Speicher werden tägliche Sicherungen vor Ort beibehalten, wenn es eine regionale Katastrophe gibt.

Hinweis

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 sekundären Region repliziert.
  • Failover in die sekundäre Region ist eine Entscheidung, die Microsoft zentral treffen muss, da es sich auf alle Kunden auf die betroffene Skalierungseinheit auswirkt. Außer unter extremen Umständen tritt Microsoft die Möglichkeit auf, nicht zu scheitern, sodass Kundendaten nicht verloren gehen.
  • Azure DevOps bietet eine 99,9 Prozent Uptime SLA-Garantie und erstattet einen Teil der monatlichen Gebühren, wenn diese SLA in einem bestimmten Monat verpasst wird.
  • Da nur eine Region in Brasilien vorhanden ist, werden Kundendaten in Brasilien zur Notfallwiederherstellung in die Region Süd-Zentral-USA repliziert.

Fehler auftreten

Um vor versehentlicher Löschung von Daten zu schützen, übernimmt Microsoft auch Punkt-in-Time-Sicherungen sowohl der Blobs in Azure Blob Storage als auch der Datenbanken in Azure SQL-Datenbank. Es gibt eine separate Kopie aller Blobs, und Änderungen werden an jedes Speicherkonto angefügt. Da diese Daten unveränderlich sind, müssen Sie keinen vorhandenen Speicher als Teil der Sicherungsprozeduren neu schreiben.

Sicherungen sind ein Standardteil von Azure SQL-Datenbank, und Azure DevOps verwendet diese. Wir erhalten 28 Tage Wert Ihrer Daten. In beiden Fällen werden diese Sicherungen auch in einem gekoppelten Bereich repliziert, um sicherzustellen, dass Sie aus einem regionalen Ausfall wiederherstellen.

Ein weiterer Schutz besteht darin, dass Microsoft ganze Organisationen bis zu 28 Tage nach dem Löschen wiederherstellen kann. Dies liegt daran, dass wir einen "soft delete" für Organisationslöschvorgänge ausführen.

Praxis ist wichtig

Wenn Sie mehrere, redundante Sicherungen Ihrer Daten haben, ist jedoch ohne Praxis unvorhergesehen, dass die Wiederherstellung unvorhersehbar sein kann. Es wurde gesagt, dass "Sicherungen niemals fehlschlagen, die Wiederherstellungen tun." Obwohl technisch falsch, ist die Stimmung richtig.

Microsoft praktiziert regelmäßig das Wiederherstellen verschiedener Datasets aus der Sicherung. Geo-redundanter Speicher aus Azure wird regelmäßig getestet. Außerdem stellen wir von Zeit zu Zeit Sicherungen wieder her, um aus menschlichem Fehler wiederherzustellen, z. B. wenn ein Kunde versehentlich ein Projekt in Azure DevOps gelöscht hat. Es gibt viele Kombinationen aus Notfall- und Datenbeschädigungsszenarien, die wir weiterhin planen und regelmäßig neue Tests ausführen.

Dienstverfügbarkeit

Azure DevOps bietet verteilten Denial-of-Service -Schutz (DDoS) und Live Site Response, um sicherzustellen, dass Sie Zugriff auf Ihre Organisation und zugeordnete Ressourcen haben.

DDoS-Schutz

In einigen Fällen kann sich ein böswilliger DDoS-Angriff auf die Dienstverfügbarkeit auswirken. Azure verfügt über ein DDoS-Verteidigungssystem, das hilft, Angriffe gegen unseren Dienst zu verhindern. Es verwendet Standarderkennungs- und Entschärfungstechniken wie SYN-Cookies, Ratelimits und Verbindungsgrenzwerte. Das System ist so konzipiert, dass Angriffe nicht nur von außen, sondern auch aus Azure bestehen.

Bei anwendungsspezifischen Angriffen, die in die Azure-Verteidigungssysteme eindringen können, Azure DevOps Kontingente auf Anwendungs- und Organisationsebene und Drosselung einrichten. Dadurch wird verhindert, dass wichtige Dienstressourcen während eines Angriffs oder versehentlichen Missbrauchs von Ressourcen überlastt werden.

Reaktion auf Livewebsites

In seltenen Fällen benötigen Sie möglicherweise eine Livewebsiteantwort auf ein Problem mit der Dienstverfügbarkeit. Wir verfügen über ein Betriebsteam, das 24x7 zur Verfügung steht, um das Problem schnell zu identifizieren und die erforderlichen Entwicklungsteamressourcen zu nutzen. Diese Ressourcen beheben dann das Problem. Sie zielen auch darauf ab, die Dienststatusseite innerhalb von Minuten zu aktualisieren, um ein Problem zu erkennen, das sich auf den Dienst auswirkt. Nachdem das Team ein Problem behoben hat, identifizieren sie die Ursache des Problems und verfolgen die erforderlichen Änderungen, um ähnliche Probleme in zukunft zu verhindern.

Azure DevOps Live Site Management-Prozesse konzentrieren sich auf Ihre Erfahrung und den Status Ihres Diensts. Diese Prozesse minimieren die Zeit zum Erkennen, Reagieren und Beheben von Problemen. Alle Technischen Disziplinen sind involviert und verantwortlich, sodass sich kontinuierliche Verbesserungen außerhalb der direkten Erfahrung entwickeln. Dies bedeutet, dass Überwachung, Diagnose, Resilienz und Qualitätssicherungsprozesse im Laufe der Zeit verbessert werden.

Die Livewebsiteverwaltung in Azure DevOps verfügt über drei verschiedene Spuren: Telemetrie, Vorfallverwaltung und Live site Review. Hier sind die folgenden Spuren:

Image of the Azure DevOps Services live site management process.

Das Operationsteam ü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önnten. Untersuchungen zu diesen Daten können häufig zu gezielten Verbesserungen führen, um kundenspezifische Probleme zu beheben. In einigen Fällen kontaktieren Sie Microsoft möglicherweise sogar direkt, um Ihre Erfahrung zu verstehen und mit Ihnen zu arbeiten, um den Dienst zu verbessern.

Microsoft veröffentlicht einen Service-Level-Vertrag (SLA) und stellt eine finanzielle Garantie bereit, um sicherzustellen, dass wir diese Vereinbarung jeden Monat erfüllen. Weitere Informationen finden Sie unter SLA für Azure DevOps.

Manchmal haben Partnerteams oder Abhängigkeiten Vorfälle, die sich auf Azure DevOps auswirken. Alle Partnerteams folgen ähnlichen Ansätzen zum Identifizieren, Auflösen und Lernen von diesen Dienstausfällen.

Dienstsicherheit

Die Servicesicherheit erfordert eine konstante Überwachung, von ordnungsgemäßen Entwurfs- und Codierungstechniken bis hin zu betriebsrelevanten Faktoren. Microsoft investiert aktiv in die Verhinderung von Sicherheitslöchern und in der Erkennung von Verstößen. Wenn eine Verletzung vorhanden ist, verwendet Microsoft Sicherheitsantwortpläne, um Datenlecks, Verlust oder Korruption zu minimieren. Weitere Informationen finden Sie unter "Informationen zu Sicherheit, Authentifizierung und Autorisierung".

Sicher nach Entwurf

Azure DevOps ist so konzipiert, dass sie sicher sein soll. Azure DevOps verwendet den Microsoft Security Development Lifecycle im Kern des Entwicklungsprozesses. Das Microsoft Operational Security Assurance-Programm führt seine Cloudbetriebsverfahren. Die folgenden Methoden geben die folgenden Anforderungen an:

  • Bedrohungsmodellierung während des Dienstdesigns.
  • Folgen Sie den bewährten Methoden für Design und Code.
  • Überprüfen der Sicherheit mit Standardtools und Tests.
  • Einschränken des Zugriffs auf Betriebs- und Kundendaten.
  • Die Einführung neuer Features durch einen starren Genehmigungsprozess.

Das Azure DevOps Team verfügt über jährliche Schulungsanforderungen für alle Techniker und Betriebsmitarbeiter und sponsoren informelle "Brown Bag"-Besprechungen, die von Microsoft-Technikern gehostet werden. Nachdem sie ein Problem gelöst haben, das in einer braunen Bag-Besprechung ausgelöst wurde, teilen sie, was sie mit dem Rest des Teams gelernt haben.

Ein Clouddienst ist nur so sicher wie die Hostplattform. Azure DevOps verwendet PaaS für viele seiner Infrastruktur. PaaS stellt automatisch regelmäßige Updates für bekannte Sicherheitsrisiken bereit. VMs, die in Azure gehostet werden, verwenden Infrastruktur als Dienst (IaaS), z. B. für einen gehosteten Builddienst. Solche Bilder erhalten regelmäßige Updates, um die neuesten Sicherheitspatches zu enthalten, die von Windows Update verfügbar sind. Die gleiche Update-Rigor gilt für lokale Computer, einschließlich derer, die für Die Bereitstellung, Überwachung und Berichterstellung verwendet werden.

Das Azure DevOps Team führt regelmäßige, sicherheitsorientierte Penetrationstests von Azure DevOps durch. Mit den gleichen Techniken und Mechanismen wie böswilligen Angreifern versucht die Penetrationstests, die Live-Produktionsdienste und die Infrastruktur von Azure DevOps auszunutzen. Ziel ist es, reale Sicherheitsrisiken, Konfigurationen, Fehler oder andere Sicherheitslücken in einem kontrollierten Prozess zu identifizieren. Das Team überprüft die Ergebnisse, um andere Bereiche der Verbesserung zu identifizieren und die Qualität der Präventionssysteme und Schulungen zu erhöhen. Sie können die Ergebnisse der letzten Azure DevOps Penetrationstests im Service Trust Portal überprüfen.

Sicherheit der Anmeldeinformationen

Ihre Anmeldeinformationen in Azure DevOps werden mithilfe bewährter Methoden der Branche gespeichert. Erfahren Sie mehr über den Speicher von Anmeldeinformationen.

Melden von Sicherheitsproblemen

Wenn Sie während Ihrer Penetrationstests glauben, dass Sie einen potenziellen Sicherheitsfehler im Zusammenhang mit dem Azure DevOps-Dienst entdeckt haben, melden Sie sie innerhalb von 24 Stunden an Microsoft. Weitere Informationen finden Sie unter Melden eines Sicherheitsrisikos für Computer.

Wichtig

Obwohl microsoft über Penetrationstests nicht mehr informiert wird, müssen Sie weiterhin die Microsoft Cloud Unified Penetration Testing Rules of Engagement einhalten.

Bounty-Programm

Azure DevOps teilnimmt an dem Microsoft Online Services Bounty Program. Dieses Programm belohnt Sicherheitsforscher, die Probleme an uns melden, und fordert mehr Menschen auf, Azure DevOps sicher zu halten. Weitere Informationen finden Sie im Azure DevOps Bounty Program.

Einschränken des Zugriffs

Microsoft verwaltet strenge Kontrolle darüber, wer Zugriff auf unsere Produktionsumgebung und Kundendaten erhält. Access wird auf der Ebene der wenigsten Berechtigungen gewährt, die erforderlich sind und nur nach ordnungsgemäßen Begründungen bereitgestellt und überprüft werden. Wenn ein Teammitglied Zugriff auf ein dringendes Problem benötigt oder eine Konfigurationsänderung bereitstellt, muss er für den Zugriff auf den Produktionsdienst "just-in-time" gelten. Der Zugriff wird widerrufen, sobald die Situation aufgelöst wird.

Zugriffsanforderungen und Genehmigungen werden in einem separaten System nachverfolgt und überwacht. Jeder Zugriff auf das System korreliert mit diesen Genehmigungen und wenn wir nicht genehmigten Zugriff erkennen, wird das Operationsteam benachrichtigt, um zu untersuchen.

Wir verwenden zweistufige Authentifizierung für alle Remotesystemzugriffe. Wenn also der Benutzername und das Kennwort für einen unserer Entwickler oder Betriebsmitarbeiter gestohlen wurden, bleibt die Daten geschützt. Dies bedeutet, dass zusätzliche Authentifizierungsüberprüfungen über Smartcard oder ein Telefonanruf an eine vorab genehmigte Nummer auftreten müssen, bevor der Remotezugriff auf den Dienst zulässig ist.

Darüber hinaus verwendet Microsoft Geheime, um den Dienst zu verwalten und zu verwalten, z. B. RDP-Kennwörter, SSL-Zertifikate und Verschlüsselungsschlüssel. Diese werden alle verwaltet, gespeichert und sicher über die Azure-Portal übertragen. Jeder Zugriff auf diese Geheimnisse erfordert bestimmte Berechtigungen, die protokolliert und auf sichere Weise aufgezeichnet werden. Alle Geheimnisse werden in regelmäßigen Kadenz gedreht und können nach Bedarf gedreht werden, wenn ein Sicherheitsereignis vorhanden ist.

Das Azure DevOps Operations-Team verwendet härtete Administratorarbeitsstationen, um den Dienst zu verwalten. Diese Computer führen eine minimale Anzahl von Anwendungen aus und funktionieren in einer logischen segmentierten Umgebung. Mitglieder des Operations-Teams müssen bestimmte Anmeldeinformationen mit zweistufiger Authentifizierung bereitstellen, um auf die Arbeitsstationen zuzugreifen. Der gesamte Zugriff wird überwacht und sicher protokolliert. Um den Dienst außerhalb von Manipulationen zu isolieren, erlauben wir Anwendungen wie Outlook und Office nicht, da sie häufig auf Speer-Phishing und andere Arten von Angriffen ausgerichtet sind.

Angriffsschutz und Reaktion

Wir verschlüsseln Daten über HTTPS und SSL, um sicherzustellen, dass sie während der Übertragung zwischen Ihnen und Azure DevOps nicht abgefangen oder geändert wird.

Außerdem werden daten, die wir im Auftrag in Azure DevOps speichern, wie folgt verschlüsselt:

  • In Azure SQL-Datenbanken gespeicherte Daten werden mithilfe von Transparent Data Encryption (TDE) verschlüsselt. TDE schützt vor der Bedrohung durch schädliche Aktivitäten, indem es die Datenbank, die zugehörigen Sicherungen und die ruhenden Transaktionsprotokolldateien in Echtzeit verschlüsselt.

  • Azure Blob Storage-Verbindungen werden verschlüsselt, um Ihre Daten bei der Übertragung zu schützen. Um in Azure Blob Storage gespeicherte ruhende Daten zu schützen, verwendet Azure DevOps entsprechend SSE (Azure-Speicherdienstverschlüsselung) an.

Die Azure-Infrastruktur hilft dem Azure DevOps Team, wichtige Aspekte des Diensts zu protokollieren und zu überwachen. Dadurch wird sichergestellt, dass Aktivitäten innerhalb des Diensts legitim sind und Verstöße oder versuchte Verstöße erkennen. Darüber hinaus werden alle Bereitstellungs- und Administratoraktivitäten sicher protokolliert, wie der Operatorzugriff auf den Produktionsspeicher. Echtzeitwarnungen werden ausgelöst, da die Protokollinformationen automatisch analysiert werden, um potenziell schädliches oder nicht autorisiertes Verhalten aufzudecken.

Wenn eine mögliche Angriffs- oder Sicherheitsrisiken mit hoher Priorität identifiziert werden, verfügt das Team über einen klaren Antwortplan. Dieser Plan beschreibt verantwortliche Parteien, Schritte, die zum Sichern von Kundendaten erforderlich sind und wie Sie mit Sicherheitsexperten bei Microsoft interagieren. Das Team benachrichtigt auch alle Organisationsbesitzer, wenn Daten offengelegt oder beschädigt wurden, damit sie geeignete Schritte ergreifen können, um die Situation zu beheben.

Schließlich verwendet Azure DevOps zur Bekämpfung von neuen Bedrohungen eine Strategie für "Angenommene Verletzung". Eine hoch spezialisierte Gruppe von Sicherheitsexperten innerhalb von Microsoft, bekannt als rotes Team, nimmt die Rolle anspruchsvoller Gegner an. Dieses Team testet die Erkennung und Reaktion von Verstößen, um die Bereitschaft und die Auswirkungen von realen Angriffen genau zu messen. Diese Strategie stärkt Bedrohungserkennung, Reaktion und Verteidigung des Diensts. Außerdem ermöglicht es dem Team, die Wirksamkeit des gesamten Sicherheitsprogramms zu überprüfen und zu verbessern.

Datenschutz

Sie sollten vertrauen, dass Ihre Daten angemessen und für berechtigte Zwecke behandelt werden. Ein Teil dieser Sicherung umfasst eine angemessene Einschränkung der Nutzung, sodass Ihre Daten nur aus legitimen Gründen verwendet werden.

Datenschutz-Grundverordnung (DSGVO)

Die Datenschutz-Grundverordnung (DSGVO) ist seit der Einführung der Datenschutzrichtlinie (EU) 95/46/EG die größte Änderung in Europa. Weitere Informationen zur DSGVO-Verordnung finden Sie auf der Übersichtsseite im Microsoft Trust Center.

Datenbewahrung und Souveränität

Azure DevOps ist in den folgenden acht Regionen auf der ganzen Welt verfügbar: USA, Kanada, Europa, Vereinigtes Königreich, Indien, Australien, Asien-Pazifik und Brasilien. Standardmäßig wird Ihre Organisation Ihrer nächstgelegenen Geographie zugewiesen, aber Sie haben die Möglichkeit, eine andere Geographie auszuwählen. Wenn Sie ihre Meinung später ändern, ist es möglich, Ihre Organisation zu einer anderen Geographie zu migrieren, mit Hilfe des Microsoft-Supports.

Azure DevOps keine Kundendaten außerhalb der ausgewählten Geographie verschieben oder replizieren. Stattdessen werden Ihre Daten in einer zweiten Region innerhalb derselben Geographie geo repliziert. Die einzige Ausnahme ist Brasilien, die Daten für Notfallwiederherstellungszwecke im Süden der USA repliziert.

Hinweis

Für Builds und Versionen, die auf microsoft bereitgestellten macOS-Agents ausgeführt werden, werden Ihre Daten in ein GitHub Rechenzentrum in den USA übertragen.

Weitere Informationen finden Sie unter Azure DevOps Datenspeicherort.

Zugang zur Strafverfolgung

In einigen Fällen können Dritte, wie z. B. Strafverfolgungsstellen, Microsoft den Zugriff auf Kundendaten erhalten, die in Azure DevOps gespeichert sind. Wir versuchen, die Anforderungen an den Organisationsbesitzer zur Lösung umzuleiten. Wenn sie vom Gericht aufgefordert werden, Kundendaten an einen Dritten offenzulegen, macht Microsoft einen angemessenen Aufwand, um den Organisationsbesitzer vorab zu benachrichtigen, es sei denn, wir sind gesetzlich verboten, dies zu tun.

Einige Kunden benötigen ihren Datenspeicher an einem bestimmten geografischen Ort, um eine bestimmte rechtliche Zuständigkeit für alle Strafverfolgungsaktivitäten sicherzustellen. Alle Kundendaten, z. B. Quellcode, Arbeitselemente, Testergebnisse und geo redundante Spiegel und Offsite-Sicherungen, werden innerhalb einer der zuvor erwähnten Regionen beibehalten.

Microsoft-Zugriff

Von Zeit zu Zeit müssen Microsoft-Mitarbeiter Zugriff auf Kundendaten erhalten, die innerhalb Azure DevOps gespeichert sind. Als Vorsichtsmaßnahme müssen alle Mitarbeiter, die zugriff auf Kundendaten haben oder jemals Zugriff haben, eine Hintergrundüberprüfung übergeben, die frühere Beschäftigung und strafrechtliche Verurteilungen überprüft. Wir ermöglichen 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, um zwischen den folgenden Datentypen zu unterscheiden:

  • Kundendaten – was Sie in Azure DevOps hochladen.
  • Organisationsdaten – Informationen, die beim Registrieren für Oder Verwalten Ihrer Organisation verwendet werden.
  • Microsoft-Daten – Informationen, die über den Betrieb des Diensts benötigt oder gesammelt werden.

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

Microsoft-Werbenutzung

Microsoft möchte gelegentlich Kunden kontaktieren, um sie über zusätzliche Features und Dienste zu informieren, die nützlich sein könnten. Da nicht alle Kunden über diese Angebote kontaktiert werden möchten, können Sie sich anmelden und die Marketing-E-Mail-Kommunikation abmelden.

Microsoft verwendet niemals Kundendaten, um bestimmte Angebote für bestimmte Benutzer oder Organisationen zu erreichen. Stattdessen verwenden wir Organisationsdaten und aggregierte Nutzungsstatistiken auf Organisationsebene, um Gruppen zu bestimmen, die bestimmte Angebote erhalten sollten.

Vertrauen schaffen

Sie können sicher sein, dass Microsoft im Auftrag von Azure DevOps andere Anstrengungen durchführt. Diese Bemühungen umfassen interne Einführungsrichtlinien bei Microsoft, die Transparenz, die im Zustand unseres Diensts bereitgestellt wird, und fortschritte beim Empfang der Zertifizierung unserer Informationssicherheitssysteme.

Interne Einführung

Teams über Microsoft hinweg Azure DevOps intern übernehmen. Das Azure DevOps Team wurde 2014 in eine Organisation verschoben und verwendet sie umfassend. Allgemein haben wir Richtlinien eingerichtet, um die Einführungspläne für andere Teams zu ermöglichen.

Offensichtlich bewegen sich große Teams schrittweiser als kleinere, da ihre Investitionen in vorhandene DevOps Systeme investiert werden. Für Teams, die schnell wechseln können, haben wir einen Projektklassifizierungsansatz eingerichtet. Sie bewertet die Risikotoleranz basierend auf Projekteigenschaften, um festzustellen, ob das Projekt für Azure DevOps geeignet ist. Bei größeren Teams tritt die Einführung in der Regel in Phasen mit mehr Planung auf.

Zusätzliche Anforderungen für interne Projekte umfassen das Zuordnen der Organisation zu Azure AD, um eine ordnungsgemäße Lebenszyklus- und Kennwortkomplexität des Benutzers sicherzustellen. Für vertraulichere Projekte ist auch die zweistufige Authentifizierung erforderlich.

Compliancezertifizierungen

Einige von Ihnen möchten die Bewertung unserer Datenschutzverfahren von Drittanbietern verstehen. Azure DevOps hat die folgenden Zertifizierungen erreicht:

  • ISO 27001:2013
  • ISO 27018:2019
  • HIPAA (Health Insurance Portability and Accountability Act)
  • BAA (Business Associate Agreement)
  • EU-Modellklauseln
  • SOC 1, Typ 2
  • SOC 2, Typ 2
  • Germany C5

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

Schritte, die Sie ausführen können

Der richtige Datenschutz erfordert ihr aktives Engagement sowie die Ihrer Administratoren und Benutzer. Ihre Projektdaten, die in Azure DevOps gespeichert sind, sind nur so sicher wie die Zugriffspunkte des Endbenutzers. Stimmen Sie mit der Vertraulichkeitsstufe ihres Projekts mit der Vertraulichkeitsstufe für Berechtigungen und Granularität für diese Organisationen überein.

Klassifizieren von Daten

Der erste Schritt besteht darin, Ihre Daten zu klassifizieren. Klassifizieren Sie Daten basierend auf Vertraulichkeits- und Risikohorizont, und die Schäden, die auftreten können, wenn sie kompromittiert werden. Viele Unternehmen verfügen über vorhandene Klassifizierungsmethoden, die wiederverwendet werden können, wenn Projekte zu Azure DevOps wechseln. Weitere Informationen finden Sie im Dokument "Datenklassifizierung für Cloudbereitschaft" von MicrosoftVertrauenswürdiges Computing.

Azure Active Directory annehmen

Verwenden Sie Azure Active Directory (Azure AD), um den Zugriff Ihrer Organisation auf Azure DevOps zu verwalten. Azure AD bietet eine weitere Möglichkeit, die Sicherheit der Anmeldeinformationen Ihrer Benutzer zu verbessern. Azure AD ermöglicht Es Ihrer IT-Abteilung, ihre Endbenutzerzugriffsrichtlinie, Kennwortkomplexität, Kennwortaktualisierungen und Ablauf zu verwalten, wenn der Benutzer Ihre Organisation verlässt. Mithilfe des Active Directory-Verbunds können Sie direkt Azure AD mit dem zentralen Verzeichnis Ihrer Organisation verknüpfen, sodass Sie nur einen Speicherort zum Verwalten dieser Details für Ihr Unternehmen haben.

Die folgende Tabelle vergleicht Microsoft-Konto und Azure AD Merkmale relativ zu Azure DevOps Zugriff:

Eigenschaften Microsoft-Konto Azure AD
Identitätsersteller Benutzer Organization
Einzelner Benutzername / Kennwort für alle Arbeitsressourcen Nein Ja
Kennwortlebensdauer-Komplexitätssteuerelement & Benutzer Organization
Azure DevOps Mitgliedschaftsbeschränkungen Jedes Microsoft-Konto (MSA) Verzeichnis der Organisation
Nachverfolgbare Identität Nein Ja
Organisations-IP-Besitz & Unklar Organization
Zweistufige Authentifizierungsregistrierung Benutzer Organization
Gerätebasierter bedingter Zugriff Nein Organization

Weitere Informationen zum Konfigurieren dieser Unterstützung für Ihre Organisation.

Anfordern der zweistufigen Authentifizierung

Möglicherweise möchten Sie den Zugriff auf Ihre Organisation einschränken, indem Sie mehr als einen Faktor benötigen, um sich anzumelden. Sie können mehrere Faktoren mit Azure AD benötigen. Sie können beispielsweise eine Telefonauthentifizierung sowie einen Benutzernamen und ein Kennwort für alle Authentifizierungsanforderungen benötigen.

Verwenden von BitLocker

Für vertrauliche 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, verschlüsselt sie automatisch jede Datei, die Sie auf diesem Laufwerk speichern. Wenn Ihr Laptop oder Desktopcomputer in die falschen Hände fällt, verhindert BitLocker nicht autorisierten Zugriff auf lokale Kopien von Daten aus Ihren Projekten.

Einschränken der Verwendung alternativer Authentifizierungsanmeldeinformationen

Der Standardauthentifizierungsmechanismus für Git-bezogene Tools ist eine alternative Authentifizierung (manchmal als Standardauthentifizierung bezeichnet). Mit diesem Mechanismus kann der Endbenutzer einen alternativen Benutzernamen und ein Kennwort für die Verwendung bei Git-Befehlszeilenvorgängen einrichten. Diese Kombination aus Benutzername und Kennwort kann auch verwendet werden, um auf alle anderen Daten zuzugreifen, für die dieser Benutzer über Berechtigungen verfügt. Alternative Authentifizierungsanmeldeinformationen sind aufgrund ihrer Natur weniger sicher als die Standardverbundauthentifizierung.

Sie können weiterhin Entscheidungen für erhöhte Sicherheit treffen. Alle Kommunikationen werden über HTTPS gesendet, und es gibt Kennwortkomplexitätsanforderungen. Ihre Organisation sollte weiterhin bewerten, ob zusätzliche Richtlinien erforderlich sind, um Ihre Projektsicherheitsanforderungen zu erfüllen. Sie können alternative Authentifizierungsanmeldeinformationen vollständig deaktivieren, wenn Sie entscheiden, dass sie die Sicherheitsanforderungen Ihrer Organisation nicht erfüllt. Weitere Informationen finden Sie unter Ändern der Sicherheitsrichtlinien für Anwendungsverbindung & für Ihre Organisation.

Sicherer Zugriff auf Ihre Organisation

Azure AD bietet Administratoren die Möglichkeit, den Zugriff auf Azure-Ressourcen und -Anwendungen wie Azure DevOps zu steuern. Bei Verwendung der bedingten Zugriffssteuerung prüft Azure AD auf bestimmte Bedingungen, die Sie für einen Benutzer festlegen, damit dieser auf eine Anwendung zugreifen kann. Wenn diese Zugriffsanforderungen erfüllt sind, wird der Benutzer authentifiziert und erhält Zugriff auf die Anwendung.

Azure DevOps unterstützt das Erzwingen bestimmter Arten von Richtlinien für bedingten Zugriff (z. B. IP-Fencing) für benutzerdefinierte Azure DevOps Authentifizierungsmechanismen. Zu diesen Mechanismen gehören persönliche Zugriffstoken, alternative Authentifizierung, OAuth und SSH-Schlüssel. Wenn Ihre Benutzer über einen Drittanbieterclient auf Azure DevOps zugreifen, werden nur IP-basierte Richtlinien (nur IPv4 basiert) berücksichtigt.

Zusätzliche Ressourcen