Ü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 Funktionen von Visual Studio Team Foundation Server mit zusätzlichen Clouddiensten verwaltet Azure DevOps Ihren Quellcode, Arbeitselemente, Builds und Tests. Es 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. Außerdem wird die Rolle beschrieben, die Sie spielen, um Ihre Projekte sicher und sicher zu halten.

Dieser Artikel richtet sich an Organisationsadministratoren und IT-Experten, die ihre Projektressourcen täglich verwalten. Dies ist besonders nützlich für Personen, die bereits mit Azure DevOps vertraut sind und mehr darüber erfahren möchten, wie Microsoft in Azure DevOps gespeicherte Ressourcen schützt.

Unsere Verpflichtung

Microsoft hilft, ohne Ausnahme sicherzustellen, dass Ihre Projekte sicher und sicher bleiben. Wenn Ihre Projekte in Azure DevOps gespeichert werden, profitieren Sie von mehreren Ebenen von Sicherheits- und Governancetechnologien, Betriebspraktiken und Konformitätsrichtlinien. Microsoft erzwingt Datenschutz und -integrität sowohl im Ruhezustand als auch während der Übertragung.

Die Bedrohungen, denen Sie ausgesetzt sind, sind vier grundlegende Kategorien: Datenverfügbarkeit, Dienstverfügbarkeit, Dienstsicherheit und Datenschutz. In diesem Artikel werden bestimmte Bedrohungen innerhalb der einzelnen Kategorien untersucht, und es wird erläutert, wie Azure DevOps gegen sie vorgeht. Zunächst wird in diesem Artikel beschrieben, wie Daten gespeichert werden und wie Azure DevOps den Zugriff auf Ihre Daten verwaltet.

Da ein ordnungsgemäßer Datenschutz auch die aktive Einbindung von Administratoren und Benutzern erfordert, müssen Sie die Schritte kennen, die Sie ergreifen sollten, um Ihre Projektressourcen vor unbefugter Offenlegung und Manipulation zu schützen. Sie müssen explizit Berechtigungen für Benutzerzugriffspunkte erteilen, um sicher sein zu können, dass nur die richtigen Personen innerhalb Azure DevOps auf Daten zugreifen.

Unabhängig von Ihrem Ansatz sollten Sie alle Daten berücksichtigen, die potenziell "gefährdet" sind, unabhängig davon, wo sie verwendet werden oder wo sie verwendet werden. Dies gilt sowohl für Daten in der Cloud als auch für Daten, die in einem privaten Rechenzentrum gespeichert sind. Daher ist es wichtig, Ihre Daten, ihre Vertraulichkeit und ihr Risiko sowie den Schaden zu klassifizieren, den sie bei einer Gefährdung verursachen können. Kategorisieren Sie Ihre Daten außerdem relativ zu einer allgemeinen Richtlinie für die Informationssicherheitsverwaltung.

Basiert auf Azure

Diagramm der Azure DevOps übergeordneten Architektur.

Azure DevOps Services wird vollständig in Azure-Rechenzentren gehostet und verwendet viele der wichtigsten Azure-Dienste, einschließlich Compute, Speicher, Netzwerk, Azure SQL, Identitäts- und Zugriffsverwaltung und Azure Service Bus.

Azure DevOps Services verwendet Azure Storage als primäres Repository für Dienstmetadaten und Kundendaten. Abhängig vom Datentyp und den Speicher- und Abrufanforderungen verwendet Azure DevOps Services Azure Blob Storage (für binäre große Objekte) und Azure SQL Datenspeicher. Um den Azure DevOps Services Datenschutzansatz 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. Diese Daten umfassen potenziell vertrauliche oder private Informationen, z. B. den Inhalt von Quelldateien und die Anlagen für Arbeitselemente. Bei den meisten Projekten wird der Großteil des verwendeten Speichers als unstrukturierter Blobspeicher verwendet. Weitere Informationen finden Sie unter Azure Blob Storage.

  • Azure SQL-Datenbank Speicher speichert die strukturierten und transaktionalen Aspekte Ihrer Organisation, z. B. Projektmetadaten, den Quellcodeverwaltungsverlauf mit Versionsangabe und Arbeitselementdetails. Der Datenbankspeicher bietet Ihnen schnellen Zugriff auf die wichtigen Elemente Ihres Projekts und stellt Indizes im Blobspeicher bereit, um Dateien und Anlagen zu suchen. 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 gewähren oder einschränken. Azure DevOps verwendet die Verbundauthentifizierung von Benutzeridentitäten über Azure Active Directory (Azure AD) und Microsoft-Konten.

Während der Authentifizierung wird der Benutzer an den Authentifizierungsanbieter weitergeleitet, wo er seine Anmeldeinformationen angibt. Nachdem der Authentifizierungsanbieter die Anmeldeinformationen des Benutzers überprüft hat, gibt Azure DevOps ein Authentifizierungscookie für den Benutzer aus, wodurch der Benutzer gegenüber Azure DevOps authentifiziert bleiben kann.

Auf diese Weise werden die Anmeldeinformationen des Benutzers nie direkt für Azure DevOps freigegeben. Für jede Azure DevOps Ressource, auf die der Benutzer zuzugreifen versucht, werden Berechtigungen basierend auf den expliziten Berechtigungen des Benutzers sowie den Berechtigungen überprüft, die durch die Gruppenmitgliedschaft geerbt wurden. Administratoren können Zugriffssteuerungen verwenden, um den Zugriff auf die Organisation,Projektsammlungen, Teamprojekte und daten- und teamumfangsierte Daten und Funktionen zu schützen. Administratoren können auch spezifischere Ressourcen wie Versionskontrollordner und Arbeitselementbereichspfade schützen.

Datenverfügbarkeit

Azure DevOps Services verwendet viele der Azure Storage Features, um die Datenverfügbarkeit bei Hardwarefehlern, Dienstunterbrechungen oder Regionsausfällen sicherzustellen. Darüber hinaus wendet das Azure DevOps-Team Verfahren an, um Daten vor dem versehentlichen oder böswilligen Löschen zu schützen.

Datenredundanz

Um Daten bei Hardware- oder Dienstausfällen zu schützen, repliziert Azure Storage Kundendaten zwischen zwei Regionen in derselben Geografie georepliziert. Beispielsweise kann Azure Daten zwischen Nord- und Westeuropa oder zwischen nord- und südosten USA georeplizieren.

Für Azure Blob Storage werden Kundendaten dreimal innerhalb einer einzelnen Region repliziert und asynchron in eine zweite Region in derselben Geografie repliziert. Daher verwaltet Azure immer die Entsprechung von sechs Kopien Ihrer Daten. Dadurch können Sie bei einem größeren Ausfall oder Notfall ein Failover in eine separate Region ausführen und gleichzeitig lokale Redundanz für Hardwareausfälle innerhalb einer Region verwenden. Für Azure SQL-Datenbank Speicher werden tägliche Sicherungen außerhalb des Standorts verwaltet, wenn es zu einem regionalen Notfall kommt.

Hinweis

Datenredundanz und Failover:

  • Es gibt ein inhärentes Delta, gemessen in Minuten, wenn Microsoft Ihre Daten zwischen der primären und sekundären Region repliziert.
  • Ein Failover in die sekundäre Region ist eine Entscheidung, die Microsoft zentral treffen muss, da es sich auf alle Kunden in der betroffenen Skalierungseinheit auswirkt. Mit Ausnahme extremer Umstände entscheidet sich Microsoft dafür, kein Failover zu unternehmen, damit Kundendaten nicht verlorengehen.
  • Azure DevOps bietet eine SLA-Garantie mit einer Betriebszeit von 99,9 Prozent und wird einen Teil der monatlichen Gebühren zurückerstattet, wenn diese SLA in einem bestimmten Monat ausgelassen wird.
  • Da es in Brasilien nur eine Region gibt, werden Kundendaten in Brasilien zur Notfallwiederherstellung in die Region "USA, Süden-Mitte" repliziert.

Fehler

Zum Schutz vor versehentlichem Löschen von Daten erstellt Microsoft auch Point-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, ist es nicht erforderlich, vorhandenen Speicher im Rahmen der Sicherungsverfahren neu zu schreiben.

Sicherungen sind ein Standardteil von Azure SQL-Datenbank, und Azure DevOps Services nutzt dies. In beiden Fällen werden diese Sicherungen auch in einer gekoppelten Region repliziert, um sicherzustellen, dass Sie nach einem regionalen Ausfall wiederhergestellt werden.

Ein weiterer Schutz besteht darin, dass Microsoft ganze Organisationen bis zu 28 Tage nach dem Löschen wiederherstellen kann. Dies liegt daran, dass Microsoft ein "soft delete" für Löschvorgänge der Organisation durchführt.

Praxis ist wichtig

Die Verwendung mehrerer redundanter Sicherungen Ihrer Daten ist gut, aber ohne Übung kann die Wiederherstellung unvorhersehbar sein. Es wurde gesagt, dass "Sicherungen nie fehlschlagen, es sind die Wiederherstellungen, die dies tun". Technisch gesehen ist die Stimmung richtig.

Microsoft arbeitet regelmäßig an der Wiederherstellung verschiedener Datasets aus der Sicherung. Georedundanter Speicher aus Azure wird regelmäßig getestet. Außerdem stellt Microsoft von Zeit zu Zeit Sicherungen wieder her, um nach menschlichen Fehlern wiederherzustellen, z. B. wenn ein Kunde versehentlich ein Projekt in Azure DevOps gelöscht hat. Es gibt viele Permutationen von Notfall- und Datenbeschädigungsszenarien, und Microsoft plant und führt regelmäßig neue Tests durch.

Dienstverfügbarkeit

Azure DevOps Services bietet verteilten Denial-of-Service-Schutz (DDoS) und Antworten auf Livewebsites, um sicherzustellen, dass Sie Zugriff auf Ihre Organisation und die zugehörigen 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, mit dem Angriffe auf unseren Dienst verhindert werden können. Es werden Standardmäßige Erkennungs- und Entschärfungstechniken wie SYN-Cookies, Ratenbegrenzungen und Verbindungsgrenzwerte verwendet. 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, richtet Azure DevOps Kontingente und Drosselung auf Anwendung- und Organisationsebene ein. Dies hilft, eine übermäßige Nutzung wichtiger Dienstressourcen während eines Angriffs oder versehentlichen Missbrauchs von Ressourcen zu verhindern.

Antwort der Livewebsite

In seltenen Fällen benötigen Sie möglicherweise eine Livewebsiteantwort auf ein Problem mit der Dienstverfügbarkeit. Microsoft verfügt rund um die Uhr über ein Betriebsteam, um das Problem schnell zu identifizieren und die erforderlichen Ressourcen des Entwicklungsteams einzubinden. Diese Ressourcen beheben dann das Problem. Außerdem soll die Dienststatusseite innerhalb weniger Minuten nach der Erkennung eines Problems aktualisiert werden, das sich auf den Dienst auswirkt. Nachdem das Team ein Problem behoben hat, identifiziert es die Grundursache des Problems und verfolgt die erforderlichen Änderungen nach, um ähnliche Probleme in Zukunft zu verhindern.

Azure DevOps Prozesse für die Livewebsiteverwaltung konzentrieren sich auf Ihre Erfahrung und die Integrität Ihres Diensts. Diese Prozesse minimieren die Zeit zum Erkennen, Reagieren auf und Beheben von Problemen. Alle Engineeringdisziplinen sind beteiligt und verantwortlich, sodass sich kontinuierlich Verbesserungen aus direkter Erfahrung entwickeln. Dies bedeutet, dass Überwachungs-, Diagnose-, Resilienz- und Qualitätssicherungsprozesse im Laufe der Zeit verbessert werden.

Die Livewebsiteverwaltung in Azure DevOps verfügt über drei verschiedene Spuren: Telemetrie, Incident Management und Livewebsiteüberprüfung. Dies ist die Folge dieser Spuren:

Abbildung des Azure DevOps Services Live-Websiteverwaltungsprozesses

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 Microsoft Sie sogar direkt kontaktieren, um Ihre Erfahrungen zu verstehen und mit Ihnen zusammenzuarbeiten, um den Dienst zu verbessern.

Microsoft veröffentlicht eine Vereinbarung zum Servicelevel (SLA) und bietet eine finanzielle Garantie, um sicherzustellen, dass diese Vereinbarung jeden Monat erfüllt wird. Weitere Informationen finden Sie unter SLA für Azure DevOps.

Manchmal weisen Partnerteams oder Abhängigkeiten Vorfälle auf, die sich auf Azure DevOps auswirken. Alle Partnerteams verfolgen ähnliche Ansätze zum Identifizieren, Beheben und Lernen aus diesen Dienstausfällen.

Dienstsicherheit

Die Dienstsicherheit erfordert konstante Sorgfalt, von richtigen Entwurfs- und Codierungstechniken bis hin zu betrieblichen Faktoren. Microsoft investiert aktiv in die Verhinderung von Sicherheitslücken und in die Erkennung von Sicherheitsverletzungen. Bei einer Sicherheitsverletzung verwendet Microsoft Sicherheitsreaktionspläne, um Datenlecks, Datenverluste oder Beschädigungen zu minimieren. Weitere Informationen finden Sie unter Informationen zu Sicherheit, Authentifizierung und Autorisierung.

Entwurfssicher

Azure DevOps Services ist auf Sicherheit ausgelegt. Es nutzt die Microsoft Security Development Lifecycle, die den Kern des Entwicklungsprozesses bildet, und das Microsoft Operational Security Assurance-Programm leitet die Verfahren für den Cloudbetrieb. Diese Methoden geben die folgenden Anforderungen an:

  • Bedrohungsmodellierung während des Dienstentwurfs.
  • Befolgen Sie die bewährten Methoden für Entwurf und Code.
  • Überprüfen der Sicherheit mit Standardtools und -tests
  • Beschränken des Zugriffs auf Betriebs- und Kundendaten.
  • Gating rollout of new features through a rigid approval process(Gating rollout of new features through a rigid approval process).

Das Azure DevOps Services-Team verfügt über jährliche Schulungsanforderungen für alle Techniker und Betriebsmitarbeiter sowie für die Von Microsoft-Technikern gehosteten informellen "Brown Bag"-Besprechungen. Nachdem sie ein Problem gelöst haben, das in einer Brown Bag-Besprechung ausgelöst wurde, teilen sie das Gelernte mit dem Rest des Teams.

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 Sicherheitsrisiken bereit. In Azure gehostete VMs verwenden Infrastructure-as-a-Service (IaaS), z. B. für einen gehosteten Builddienst. Solche Images erhalten regelmäßige Updates, um die neuesten Sicherheitspatches zu enthalten, die über Windows Update verfügbar sind. Die gleiche Update-Genauigkeit gilt für lokale Computer, einschließlich derjenigen, die für die Bereitstellung, Überwachung und Berichterstellung verwendet werden.

Das Azure DevOps Services-Team führt regelmäßige, sicherheitsorientierte Penetrationstests für Azure DevOps durch. Durch Penetrationstests werden die gleichen Techniken und Mechanismen wie böswillige Angreifer verwendet, um die Liveproduktionsdienste und die Infrastruktur von Azure DevOps zu nutzen. Ziel ist es, Sicherheitsrisiken, Konfigurationen, Fehler oder andere Sicherheitslücken in einem kontrollierten Prozess in der Praxis zu identifizieren. Das Team überprüft die Ergebnisse, um andere Verbesserungsbereiche zu identifizieren und die Qualität der vorbeugenden Systeme und Schulungen zu verbessern.

Sicherheit von Anmeldeinformationen

Ihre Anmeldeinformationen in Azure DevOps werden mithilfe bewährter Branchenmethoden gespeichert. Erfahren Sie mehr über den Anmeldeinformationsspeicher.

Melden von Sicherheitsproblemen

Wenn Sie während Ihrer Penetrationstests der Meinung sind, dass Sie einen potenziellen Sicherheitsfehler im Zusammenhang mit dem Azure DevOps-Dienst erkannt haben, melden Sie ihn innerhalb von 24 Stunden an Microsoft. Weitere Informationen finden Sie unter Melden eines Computersicherheitsrisikos.

Wichtig

Obwohl die Benachrichtigung von Microsoft über Penetrationstestaktivitäten nicht mehr erforderlich ist, müssen Sie dennoch die Microsoft Cloud Unified Penetration Testing Rules of Engagement (Microsoft Cloud Unified Penetration Testing Rules of Engagement)einhalten.

Bounty-Programm

Azure DevOps nimmt am Microsoft Online Services Bounty-Programmteil. Dieses Programm zeichnet Sicherheitsexperten aus, die Probleme melden, und fordert mehr Personen dazu auf, Azure DevOps zu schützen. Weitere Informationen finden Sie im Azure DevOps Bounty-Programm.

Einschränken des Zugriffs

Microsoft behält strenge Kontrolle darüber, wer Zugriff auf unsere Produktionsumgebung und Kundendaten erhält. Der Zugriff wird nur auf der Ebene der geringsten erforderlichen Rechte gewährt und erst nach ordnungsgemäßen Begründungen bereitgestellt und überprüft. Wenn ein Teammitglied Zugriff benötigt, um ein dringendes Problem zu lösen oder eine Konfigurationsänderung bereitzustellen, muss es just-in-time-Zugriff auf den Produktionsdienst beantragen. Der Zugriff wird widerrufen, sobald die Situation behoben ist.

Zugriffsanforderungen und Genehmigungen werden in einem separaten System nachverfolgt und überwacht. Der gesamte Zugriff auf das System korreliert mit diesen Genehmigungen, und wenn nicht genehmigter Zugriff erkannt wird, wird eine Warnung ausgelöst, die das Betriebsteam untersuchen soll.

Wenn der Benutzername und das Kennwort für einen unserer Entwickler oder Betriebsmitarbeiter gestohlen wurden, werden die Daten weiterhin geschützt, da wir die zweistufige Authentifizierung für den gesamten Remotesystemzugriff verwenden. Dies bedeutet, dass zusätzliche Authentifizierungsprüfungen per Smartcard oder Telefonanruf an eine vorab genehmigte Nummer erfolgen müssen, bevor ein Remotezugriff auf den Dienst zugelassen wird.

Darüber hinaus verwendet Microsoft Geheimnisse zum Verwalten und Verwalten des Diensts, z. B. RDP-Kennwörter, SSL-Zertifikate und Verschlüsselungsschlüssel. Diese werden alle über die Azure-Portal verwaltet, gespeichert und sicher übertragen. Jeder Zugriff auf diese Geheimnisse erfordert eine bestimmte Berechtigung, die auf sichere Weise protokolliert und aufgezeichnet wird. Alle Geheimnisse werden in regelmäßigen Abständen rotiert und können bei Bedarf bei einem Sicherheitsereignis rotiert werden.

Das Azure DevOps Betriebsteam verwendet arbeitsstationen mit gehärteten Administratoren, 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 angeben, um auf die Arbeitsstationen zugreifen zu können. Der gesamte Zugriff wird überwacht und sicher protokolliert. Anwendungen wie Outlook und Office, die häufig Ziele von Phishing und anderen Arten von Angriffen sind, sind in dieser Umgebung nicht zulässig, um den Dienst von externen Manipulationen zu isolieren.

Angriffsschutz und Reaktion

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

Außerdem werden Daten, die wir in Ihrem Namen in Azure DevOps speichern, wie folgt verschlüsselt:

  • Für Daten, die in Azure SQL-Datenbanken gespeichert sind, verwendet Azure DevOps Transparent Data Encryption (TDE). Dies schützt vor der Bedrohung durch schädliche Aktivitäten, indem die Datenbank, die zugehörigen Sicherungen und ruhende Transaktionsprotokolldateien in Echtzeit verschlüsselt werden.

  • Azure Blob Storage-Verbindungen werden verschlüsselt, um Ihre Daten während der Übertragung zu schützen. Zum Schützen ruher daten, die in Azure Blob Storage gespeichert sind, verwendet Azure DevOps Azure Storage Service Encryption (SSE).

Die Azure-Infrastruktur unterstützt das Azure DevOps Services-Team dabei, wichtige Aspekte des Diensts zu protokollieren und zu überwachen. Dadurch wird sichergestellt, dass Aktivitäten innerhalb des Diensts legitim sind, und Sicherheitsverletzungen oder versuchten Sicherheitsverletzungen erkannt. Darüber hinaus werden alle Bereitstellungs- und Administratoraktivitäten sicher protokolliert, ebenso 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 ein möglicher Angriff erkannt wurde oder ein Sicherheitsrisiko mit hoher Priorität erkannt wurde, verfügt das Team über einen eindeutigen Plan zur Reaktion auf Sicherheitsvorfälle. Dieser Plan beschreibt die verantwortlichen Parteien, die erforderlichen Schritte zum Schützen von Kundendaten und die Zusammenarbeit mit Sicherheitsexperten bei Microsoft. Das Team benachrichtigt auch alle Organisationsbesitzer, wenn Daten möglicherweise offengelegt oder beschädigt sind, damit sie geeignete Maßnahmen ergreifen können, um die Situation zu beheben.

Um neue Bedrohungen zu beseitigen, setzen Azure DevOps Services schließlich eine "Assume Breach"-Strategie ein. Eine hochspezialisierte Gruppe von Sicherheitsexperten in Microsoft, die als Red Team bezeichnet wird, übernimmt die Rolle anspruchsvoller Gegenierer. Dieses Team testet die Erkennung und Reaktion auf Sicherheitsverletzungen, um die Bereitschaft und die Auswirkungen realer Angriffe genau zu messen. Diese Strategie verstärkt die Bedrohungserkennung, -reaktion und -verteidigung des Diensts. Außerdem kann das Team die Effektivität des gesamten Sicherheitsprogramms überprüfen und verbessern.

Datenschutz

Sie sollten sicher sein, dass Ihre Daten ordnungsgemäß und für legitime Zwecke verarbeitet werden. Ein Teil dieser Zusicherung 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 die größte Änderung der Datenschutzrechte in Europa seit der Einführung der Datenschutzrichtlinie 95/46/EC der Europäischen Union (EU) im Jahr 1995. Weitere Informationen zur DSGVO-Regulierung finden Sie auf der Übersichtsseite im Microsoft Trust Center.

Datenresidenz und Datenhoheit

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

Azure DevOps werden Kundendaten nicht außerhalb der ausgewählten Geografischen Region verschoben oder repliziert. Stattdessen werden Ihre Daten georepliziert in eine zweite Region innerhalb derselben Geografie. Die einzige Ausnahme ist Brasilien, das Daten zur Notfallwiederherstellung in die Geografie "USA, Süden-Mitte" repliziert.

Hinweis

Für Builds und Releases, die auf von 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.

Zugriff auf Die Durchsetzung von Gesetzen

In einigen Fällen können dritte Parteien wie z. B. Rechtsdurchsetzungen Microsoft aufrufen, um Zugriff auf Kundendaten zu erhalten, die in Azure DevOps gespeichert sind. Microsoft versucht, die Anforderungen zur Lösung an den Organisationsbesitzer umzuleiten. Wenn Microsoft durch eine rechtliche Anordnung zur Offenlegung von Kundendaten gegenüber einem Drittanbieter gezwungen wird, unternimmt Microsoft einen angemessenen Aufwand, um den Besitzer der Organisation im Voraus zu benachrichtigen, es sei denn, dies ist rechtlich untersagt.

Einige Kunden benötigen ihre Datenspeicherung an einem bestimmten geografischen Standort, um eine bestimmte rechtliche Zuständigkeit für alle Aktivitäten der Rechtsdurchsetzung sicherzustellen. Alle Kundendaten, z. B. Quellcode, Arbeitselemente, Testergebnisse und georedundante Spiegel und externe Sicherungen, werden innerhalb der geografiebezogenen Regionen verwaltet, die im vorherigen Abschnitt erwähnt wurden.

Microsoft-Zugriff

Von Zeit zu Zeit müssen Microsoft-Mitarbeiter Zugriff auf Kundendaten erhalten, die in Azure DevOps gespeichert sind. Als Vorsichtsmaßnahme müssen alle Mitarbeiter, die Zugriff auf Kundendaten haben oder haben, eine Hintergrundüberprüfung bestehen, die frühere Arbeits- und verfolgungsvergehende Mitarbeiter überprüft. Darüber hinaus lassen wir den Zugriff auf die Produktionssysteme nur zu, wenn ein Live-Site-Incident oder eine andere genehmigte Wartungsaktivität vorhanden ist, die protokolliert und überwacht wird.

Da nicht alle Daten in unserem System gleich behandelt werden, werden Daten klassifiziert, um zwischen Kundendaten (was Sie in Azure DevOps hochladen), Organisationsdaten (Informationen, die bei der Registrierung für oder Verwaltung Ihrer Organisation verwendet werden) und Microsoft-Daten (Informationen, die für den Betrieb des Diensts erforderlich sind oder gesammelt werden) zu unterscheiden. Basierend auf der Klassifizierung steuert Microsoft Nutzungsszenarien, Anforderungen an geografische Standorte, Zugriffseinschrä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önnen. Da nicht alle Kunden über diese Angebote kontaktiert werden möchten, können Sie die Marketing-E-Mail-Kommunikation abonnieren und deaktivieren.

Microsoft verwendet niemals Kundendaten, um bestimmte Angebote für bestimmte Benutzer oder Organisationen als Ziel zu verwenden. Stattdessen verwenden wir Organisationsdaten und aggregieren Nutzungsstatistiken auf Organisationsebene, um Gruppen von Organisationen zu bestimmen, die bestimmte Angebote erhalten sollen.

Aufbau von Vertrauen

Zusätzlich zu diesen Schutzmaßnahmen können Sie auch bei anderen Maßnahmen vertrauen, die Microsoft im Auftrag Azure DevOps. Dazu gehören interne Einführungsrichtlinien bei Microsoft, das Maß an Transparenz, das für den Zustand unseres Diensts bereitgestellt wird, und der Fortschritt bei der Zertifizierung unserer Informationssicherheits-Verwaltungssysteme.

Interne Einführung

Teams von Microsoft übernehmen Azure DevOps intern. Das Azure DevOps-Team wurde 2014 in eine Organisation verschoben und verwendet es umfassend. Im Weiteren haben wir Richtlinien festgelegt, um die Einführungspläne für andere Teams zu ermöglichen.

Angesichts ihrer Investitionen in vorhandene DevOps Systeme bewegen sich große Teams natürlich schrittweise als kleinere Teams. Für Teams, die sich schnell bewegen können, haben wir einen Projektklassifizierungsansatz eingerichtet. Anhand der Projektmerkmale wird die Risikotoleranz bewertet, um zu bestimmen, 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.

Zusätzliche Anforderungen für interne Projekte umfassen das Zuordnen der Organisation zum Microsoft.com Azure Active Directory, um einen ordnungsgemäßen Lebenszyklus der Benutzeridentität und Kennwortkomplexität sicherzustellen. Bei sensibleren Projekten ist auch die zweistufige Authentifizierung erforderlich.

Compliancezertifizierungen

Einige von Ihnen möchten die Auswertung unserer Datensicherheitsverfahren durch Einen Drittanbieter verstehen. Azure DevOps hat die folgenden Zertifizierungen erreicht:

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

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 Portalverfügbar. Sie können auch eine Kopie dieser SOC-Berichte anfordern.

Schritte, die Sie ausführen können

Für den richtigen Schutz von Daten ist Ihr aktives Engagement sowie das Ihrer Administratoren und Benutzer erforderlich. Die in Azure DevOps gespeicherten Projektdaten sind nur so sicher wie die Endbenutzerzugriffspunkte. Es ist wichtig, den Grad der Striktheit und Granularität der Berechtigungen für diese Organisationen mit der VertraulichkeitSstufe Ihres Projekts abzugleichen.

Klassifizieren von Daten

Der erste Schritt besteht darin, Ihre Daten basierend auf ihrer Vertraulichkeit und ihrem Risikohorizont und dem Schaden zu klassifizieren, der auftreten kann, wenn sie kompromittiert werden. Viele Unternehmen verfügen über vorhandene Klassifizierungsmethoden, die wiederverwendet werden können, wenn Projekte in Azure DevOps verschoben werden. Weitere Informationen finden Sie im Dokument "Datenklassifizierung für Cloudbereitschaft" von Microsoft Trustworthy Computing.

Einführung Azure Active Directory

Eine weitere Möglichkeit zur Verbesserung der Sicherheit der Anmeldeinformationen Ihrer Endbenutzer besteht darin, Azure Active Directory (Azure AD) zu verwenden, um den Zugriff Ihrer Organisation auf Azure DevOps zu verwalten. Azure AD ermöglicht Es Ihrer IT-Abteilung, ihre Endbenutzerzugriffsrichtlinie zu verwalten, einschließlich Kennwortkomplexität, Kennwortaktualisierungen und Ablauf, wenn der Benutzer Ihre Organisation verlässt. Über den Active Directory-Verbund können Sie Azure AD direkt mit dem zentralen Verzeichnis Ihrer Organisation verknüpfen, sodass Sie nur einen Standort haben, an dem Sie diese Details für Ihr Unternehmen verwalten können.

In der folgenden Tabelle werden Microsoft-Konto und Azure AD Merkmale relativ zum Azure DevOps-Zugriff verglichen:

Eigenschaften Microsoft-Konto Azure AD
Identitätsersteller Benutzer Organization
Einzelner Benutzername/Kennwort für alle Arbeitsressourcen Nein Ja
Steuerung & der Komplexität der Kennwortlebensdauer Benutzer Organization
Azure DevOps Mitgliedschaftslimits Beliebige MSA Verzeichnis der Organisation
Nachverfolgbare Identität Nein Ja
&IP-Besitz der Organisation Unklar Organization
2-Faktor-Authentifizierungsregistrierung Benutzer Organization
Gerätebasierter bedingter Zugriff Nein Organization

Erfahren Sie mehr über das Konfigurieren dieser Unterstützung für Ihre Organisation.

Anfordern der zweistufigen Authentifizierung

In einigen Fällen sollten Sie den Zugriff auf Ihre Organisation einschränken, indem Sie mehr als einen Faktor für die Anmeldung benötigen. Sie können mehrere Faktoren mit Azure AD erfordern. Beispielsweise können Sie für alle Authentifizierungsanforderungen neben einem Benutzernamen und Kennwort auch eine Telefonauthentifizierung 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, verschlüsselt es automatisch alle Dateien, die Sie auf diesem Laufwerk speichern. Wenn Ihr Laptop oder Desktopcomputer in die falschen Hände fällt, verhindert BitLocker den nicht autorisierten Zugriff auf lokale Kopien von Daten aus Ihren Projekten.

Beschränken der Verwendung alternativer Authentifizierungsanmeldeinformationen

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

Sie können weiterhin Entscheidungen treffen, um die Sicherheit zu erhöhen. Beispielsweise wird die gesamte Kommunikation über HTTPS gesendet, und es gelten Anforderungen an die Kennwortkomplexität. Dennoch sollte Ihre Organisation auswerten, ob zusätzliche Richtlinien erforderlich sind, um die Sicherheitsanforderungen Ihres Projekts zu erfüllen. Sie können alternative Authentifizierungsanmeldeinformationen vollständig deaktivieren, wenn Sie entscheiden, dass sie die Sicherheitsanforderungen Ihrer Organisation nicht erfüllen. Weitere Informationen finden Sie unter Ändern von 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. 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 Azure DevOps client zugreifen, werden nur IP-basierte Richtlinien (nur IPv4-basiert) verwendet.

Zusätzliche Ressourcen