Ü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 Funktionen mit weiteren Clouddiensten verwalten wir Ihren Quellcode, Arbeitsaufgaben, Builds 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 spielen, um Ihre Projekte sicher und sicher zu halten.
Dieser Artikel richtet sich an Organisationsadministratoren und IT-Experten, die ihre Projektressourcen täglich verwalten. Es ist am nützlichsten für Personen, die bereits mit Azure DevOps vertraut sind, und möchten mehr darüber wissen, wie Microsoft gespeicherte Ressourcen 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 Ebenen von Sicherheits- und Governancetechnologien, betrieblichen Praktiken und Compliancerichtlinien. Wir erzwingen Datenschutz und Integrität sowohl im Ruhezustand als auch bei der Übertragung.
Die Bedrohungen, denen Sie begegnen, sind in vier grundlegenden 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 tut, um sie zu beheben. Der Artikel beschreibt zunächst, wie Daten gespeichert werden und wie Azure DevOps den Zugriff auf Ihre Daten verwaltet.
Der Datenschutz erfordert das aktive Engagement von Administratoren und Benutzern, die wissen, welche Schritte sie unternehmen müssen, um Ihre Ressourcen vor unbefugter Offenlegung und Manipulation zu schützen. Seien Sie explizit, wenn Sie Berechtigungen für Benutzerzugriffspunkte erteilen, sodass nur die richtigen Personen in Azure DevOps auf Daten zugreifen.
Sie sollten berücksichtigen, dass alle Daten potenziell gefährdet sind, unabhängig davon, wo es sich befindet oder wie sie verwendet wird. Diese Aussage gilt sowohl für daten, die in der Cloud gespeichert sind als auch daten, die in einem privaten Rechenzentrum gespeichert sind. Es ist wichtig, Ihre Daten, ihre Vertraulichkeit und ihr Risiko zu klassifizieren und den Schaden, den sie möglicherweise tun kann, wenn sie kompromittiert wird. Kategorisieren Sie Ihre Daten auch relativ zu einer allgemeinen Richtlinie für die Verwaltung der Informationssicherheit.
Basiert 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. Je nach Art der Daten und den Speicher- und Abrufanforderungen verwendet Azure DevOps Azure Blob Storage und Azure SQL-Datenbank Speicher.
Um Ihnen zu helfen, den Azure DevOps Services-Ansatz zum Datenschutz zu verstehen, finden Sie hier einige Hintergrundinformationen zu den Speicherdiensten:
Azure Blob Storage speichert 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. Bei den meisten Projekten wird der meiste Speicher verwendet, der diese Art unstrukturierter BLOB-Speicher ist.
Azure SQL-Datenbank speichert die strukturierten und transaktionsbezogenen Aspekte Ihrer Organisation, einschließlich Projektmetadaten, des versionsgesteuerten Quellcodeverwaltungsverlaufs und Details von Arbeitsaufgaben. Der Datenbankspeicher ermöglicht Ihnen schnellen Zugriff auf die wichtigen Elemente Ihres Projekts. Es stellt Indizes im BLOB-Speicher bereit, 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 die Verbundauthentifizierung 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 Anmeldeinformationen des Benutzers überprüft hat, gibt Azure DevOps dem Benutzer ein Authentifizierungscookies aus. Mit diesem Cookie kann der Benutzer bei Azure DevOps authentifiziert 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 Überprüfung der Berechtigungen auf den expliziten Berechtigungen des Benutzers und auf Berechtigungen, die der Benutzer über die Gruppenmitgliedschaft geerbt hat.
Administratoren können Zugriffssteuerungen verwenden, um den Zugriff auf die Organisation, Projektsammlungen, Teamprojekte und teamweite Daten und Funktionen zu schützen. Administratoren können auch Zugriffssteuerungen für bestimmte Objekte wie Ordner für die Versionssteuerung und Bereichspfade für Arbeitsaufgaben verwenden.
Datenverfügbarkeit
Azure DevOps verwendet viele Azure Storage-Features, um die Datenverfügbarkeit sicherzustellen, wenn ein Hardwarefehler, Dienstunterbrechung oder regionales Notfall auftritt. Außerdem folgt das Azure DevOps-Team Verfahren, um Daten vor versehentlichem oder böswilligen Löschen zu schützen.
Datenredundanz
Um Daten während Hardware- oder Dienstfehlern zu schützen, repliziert Azure Storage Kundendaten zwischen zwei Regionen am selben geografischen Standort. Beispielsweise kann Azure Storage Daten zwischen Nord- und Westeuropa oder zwischen Nord- und Süd-USA georeplikatieren.
Bei Azure Blob Storage werden Kundendaten dreimal innerhalb einer einzelnen Region repliziert. Kundendaten werden asynchron in eine zweite Region am selben geografischen Standort repliziert. Daher verwaltet Azure immer das Äquivalent von sechs Kopien Ihrer Daten.
Wenn mehrere Kopien vorhanden sind, können Sie zu einem separaten Bereich fehlschlagen, wenn ein großer Ausfall oder ein großes Notfall auftritt, während auch lokale Redundanzen für Hardwarefehler innerhalb einer Region auftreten. 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 in die sekundäre Region ist eine Entscheidung, die Microsoft zentral treffen muss, da es sich auf alle Kunden auf eine bestimmte Skalierungseinheit auswirkt. Mit Ausnahme von extremen Umständen verhindert Microsoft einen Ausfall, sodass Kundendaten nicht verloren gehen.
- Azure DevOps bietet eine Sla (Service Level Agreement) von 99,9 Prozent Uptime. Azure DevOps erstattet einen Teil der monatlichen Gebühren zurück, wenn diese SLA in einem bestimmten Monat fehlt.
- Da es nur eine Region in Brasilien gibt, werden Kundendaten in Brasilien für Notfallwiederherstellungszwecke in die Region Süd-Zentral-USA repliziert.
Fehler passieren
Um einen versehentlichen Datenverlust zu gewährleisten, verwendet Microsoft Point-in-Time-Sicherungen für blob-Speicher gespeicherte Blobs und Datenbanken in Azure SQL-Datenbank. Jedes Speicherkonto verwaltet eine separate Kopie aller Blobs, wobei Änderungen an die vorhandenen Daten angefügt werden. Diese Sicherungen sind unveränderlich, ohne dass vorhandene Speicher während der Sicherungsverfahren neu geschrieben werden müssen.
Azure SQL-Datenbank umfasst standardmäßige Sicherungsfunktionen, die von Azure DevOps verwendet werden. Ihre Daten werden 28 Tage lang aufbewahrt, wobei diese Sicherungen auch in einer gekoppelten Region 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. Sobald dieser Zeitraum abgelaufen ist, werden diese Entitäten jedoch endgültig gelöscht und können nicht wiederhergestellt werden. Während diese Sicherungen als wichtige Komponente für die Notfallwiederherstellung dienen, ist es wichtig, dass Kunden geeignete Datenverwaltungs- und Sicherungsstrategien üben, um einen umfassenden Schutz ihrer Daten sicherzustellen.
Wichtig
- Versehentliches Löschen bezieht sich hier auf Szenarien, die infolge eines Vorfalls auf unseren Diensten entstehen. Es umfasst nicht das versehentliche Löschen von Ressourcen (z. B. Repositorys, Arbeitsaufgaben, Anlagen oder Artefakte).
- Das Wiederherstellen von Ressourcen, die Kunden versehentlich löschen, wird nicht unterstützt. Diese Sicherungen sind nur für Geschäftskontinuität vorgesehen und dienen der Wiederherstellung von Ausfall- oder Notfallszenarien.
- In seltenen Fällen kann unser Löschvorgang aufgrund von Back-End-Wiederholungen bis zu 70 Tage dauern und die Notwendigkeit, Daten aus mehreren Quellen zu löschen.
Praxis ist entscheidend
Das Erstellen mehrerer Sicherungen Ihrer Daten ist gut, aber ohne Praxis kann die Wiederherstellung unvorhersehbar sein. Die Leute sagen, dass "Sicherungen niemals scheitern; die Wiederherstellungen tun." Obwohl die Aussage technisch falsch ist, ist die Stimmung richtig.
Microsoft praktiziert regelmäßig das Wiederherstellen von Datasets aus der Sicherung. Wir testen regelmäßig georedundanten Speicher aus Azure. Es gibt viele Kombinationen aus Notfall- und Datenbeschädigungsszenarien. 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 in die Azure-Verteidigungssysteme eindringen können, richtet Azure DevOps Kontingente auf Anwendungsebene und Kontingente auf Organisationsebene und Drosselung ein. Mit dieser Vorgehensweise können Sie verhindern, dass wichtige Dienstressourcen während eines Angriffs oder versehentlichen Missbrauch von Ressourcen überlasten.
Live-Websiteantwort
In seltenen Fällen benötigen Sie möglicherweise eine Live-Websiteantwort auf ein Problem mit der Dienstverfügbarkeit. Wir verfügen über ein Betriebsteam, das ständig verfügbar ist, um das Problem schnell zu identifizieren und die erforderlichen Ressourcen des Entwicklungsteams zu nutzen.
Die Ressourcen des Entwicklungsteams 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 die Ressourcen des Entwicklungsteams ein Problem behoben haben, identifizieren sie die Ursache und verfolgen die erforderlichen Änderungen, um ähnliche Probleme in Der Zukunft zu verhindern.
Azure DevOps-Prozesse für die Verwaltung von Livewebsites konzentrieren sich auf Ihre Erfahrung und den Status des Diensts. Diese Prozesse minimieren die Zeit zum Erkennen, Reagieren und Beheben von Problemen. Alle Ingenieurdisziplinen sind beteiligt und verantwortlich, sodass sich kontinuierliche Verbesserungen aus direkter Erfahrung entwickeln. Überwachung, 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 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 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 nach Entwurf
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 führt Cloudbetriebsverfahren in Azure DevOps durch.
Das Azure DevOps-Team verfügt über jährliche Schulungsanforderungen für alle Techniker und Betriebsmitarbeiter. Das Team fördert auch informelle Besprechungen, die von Microsoft-Technikern gehostet werden. Nachdem das Team ein Problem gelöst hat, das in einer Besprechung angezeigt wird, teilt es die gelernten Erkenntnisse mit anderen Teams.
Die folgenden Methoden geben die Schulungsanforderungen an:
- Bedrohungsmodellierung während des Dienstentwurfs
- Folgen bewährter Methoden für Entwurf und Code
- Überprüfen der Sicherheit mit standardmäßigen Tools und Tests
- Einschränken des Zugriffs auf Betriebs- und Kundendaten
- Gating rollout of new features through a rigid approval process
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 Computer, die in Azure gehostet werden, verwenden die Infrastruktur als Dienst (IaaS), z. B. für einen gehosteten Builddienst. Solche Images werden regelmäßig aktualisiert, um die neuesten Sicherheitspatches einzuschließen, die von Windows Update verfügbar sind. Derselbe Update-Rigor 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 zu nutzen, indem dieselben Techniken und Mechanismen verwendet werden, die böswillige Angreifer verwenden. Das Ziel besteht darin, reale Sicherheitsrisiken, Konfigurationen, Fehler oder andere Sicherheitslücken in einem kontrollierten Prozess zu identifizieren.
Das Team überprüft die Ergebnisse dieser Tests, um andere Verbesserungsbereiche zu identifizieren und die Qualität der präventiven Systeme und Schulungen zu erhöhen. Sie können die Ergebnisse der letzten Azure DevOps-Penetrationstests im Microsoft Service Trust Portal überprüfen.
Sicherheit von Anmeldeinformationen
Microsoft verpflichtet sich, sicherzustellen, dass Ihre Projekte ohne Ausnahme sicher und sicher bleiben. In Azure DevOps profitieren Ihre Projekte von mehreren Ebenen von Sicherheits- und Governancetechnologien, betrieblichen Praktiken und Compliancerichtlinien. Wir erzwingen Datenschutz und Integrität sowohl im Ruhezustand als auch bei der Übertragung. Darüber hinaus halten wir uns an die folgenden Praktiken in Bezug auf die Anmeldeinformationen oder geheimen Schlüssel, die Azure DevOps speichert. Weitere Informationen zum Auswählen des richtigen Authentifizierungsmechanismus finden Sie unter "Anleitungen für die Authentifizierung".
Wichtig
Azure DevOps unterstützt keine alternative Anmeldeinformationenauthentifizierung. Wenn Sie noch alternative Anmeldeinformationen verwenden, empfehlen wir Ihnen dringend, zu einer sichereren Authentifizierungsmethode zu wechseln.
Persönliche Zugriffstoken (PATs)
- Wir speichern einen Hash des PAT.
- Unformatierte PATs generieren im Arbeitsspeicher auf der Serverseite. 32 Bytes werden zufällig über den RNGCryptoServiceProvider generiert und als base-32-codierte Zeichenfolge für den Aufrufer freigegeben. Dieser Wert wird NICHT gespeichert.
- PAT-Hash generiert auf serverseitiger Seite als HMACSHA256Hash des rohen PAT unter Verwendung eines symmetrischen 64-Byte-Signierschlüssels, der in unserem Key Vault gespeichert ist.
- Hash wird in unserer Datenbank gespeichert.
Secure Shell (SSH)-Schlüssel
- Wir speichern einen Hash der eingeschlossenen Organisations-ID und des öffentlichen SSH-Schlüssels.
- Unformatierte öffentliche Schlüssel werden direkt vom Anrufer über SSL bereitgestellt.
- SSH-Hash generiert auf serverseitiger Seite als HMACSHA256Hash der Organisations-ID und eines unformatierten öffentlichen Schlüssels unter Verwendung eines symmetrischen 64-Byte-Signaturschlüssels, der in unserem Schlüsseltresor gespeichert ist.
- Hash wird in unserer Datenbank gespeichert.
OAuth-Anmeldeinformationen (JWTs)
- Problem mit OAuth-Anmeldeinformationen als vollständig selbst beschreibende JSON-Webtoken (JWTs) und werden nicht in unserem Dienst gespeichert.
- Die Ansprüche in JWTs, die für unseren Dienst ausgestellt und präsentiert wurden, werden anhand eines zertifikats validiert, das in unserem Schlüsseltresor gespeichert ist.
Melden von Sicherheitsfehlern
Wenn Sie glauben, dass Ihre Penetrationstests einen potenziellen Sicherheitsfehler im Zusammenhang mit dem Azure DevOps-Dienst offenbart haben, melden Sie ihn innerhalb von 24 Stunden an Microsoft. Weitere Informationen finden Sie auf der Microsoft-Webseite, um eine Sicherheitslücke für Computer zu melden.
Wichtig
Obwohl Sie Microsoft nicht über Penetrationstests benachrichtigen müssen, müssen Sie die Microsoft-Penetrationstestregeln für Engagement einhalten.
Bounty-Programm
Azure DevOps nimmt am Microsoft Bug Bounty-Programm teil. Dieses Programm belohnt Sicherheitsforscher, die Uns Probleme melden, und es ermutigt mehr Personen, azure DevOps sicher zu halten. Weitere Informationen finden Sie im 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 Berechtigungen, die erforderlich sind, und erst nach der Überprüfung der Begründungen eines Benutzers. Wenn ein Teammitglied Zugriff benötigt, um ein dringendes Problem zu beheben oder eine Konfigurationsänderung bereitzustellen, muss er für just-in-time-Zugriff auf den Produktionsdienst gelten. Der Zugriff wird widerrufen, sobald die Situation behoben ist.
Wir verfolgen und überwachen Zugriffsanforderungen und Genehmigungen in einem separaten System. Der gesamte Zugriff auf das System korreliert mit diesen Genehmigungen. Wenn wir den nicht genehmigten Zugriff erkennen, benachrichtigen wir das Operationsteam, das untersucht werden soll.
Wir verwenden die zweistufige Authentifizierung für den gesamten Remotesystemzugriff. Wenn der Benutzername und das Kennwort für einen unserer Entwickler oder Betriebsmitarbeiter gestohlen werden, bleiben die Daten geschützt. Weitere Authentifizierungsprüfungen über Smartcard oder einen Telefonanruf an eine genehmigte Nummer müssen erfolgen, bevor wir einen Remotezugriff auf den Dienst zulassen.
Um den Dienst zu verwalten und zu verwalten, verwendet Microsoft geheime Schlüssel wie RDP-Kennwörter, SSL-Zertifikate und Verschlüsselungsschlüssel. Diese geheimen Schlüssel werden alle über die Azure-Portal verwaltet, gespeichert und sicher übertragen. Jeder Zugriff auf diese geheimen Schlüssel erfordert eine bestimmte Berechtigung, die sicher protokolliert und aufgezeichnet wird. Alle geheimen Schlüssel werden in regelmäßigen Abständen gedreht, und wir können sie bei Bedarf drehen, wenn ein Sicherheitsereignis vorhanden ist.
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 von außerhalb von Manipulationen zu isolieren, erlauben wir keine Anwendungen wie Outlook und Office, da sie häufig auf Spearphishing 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. Daten, die wir in Ihrem Auftrag in Azure DevOps speichern, werden wie folgt verschlüsselt:
In Azure SQL-Datenbanken gespeicherte Daten werden über eine transparente Datenverschlüsselung verschlüsselt. Dieses Feature trägt zum Schutz vor bösartigen Aktivitäten bei, indem eine Echtzeitverschlüsselung der Datenbank, der zugehörigen Sicherungen und der ruhenden Transaktionsprotokolldateien durchgeführt wird.
Azure Blob Storage-Verbindungen werden verschlüsselt, um Ihre Daten während der Übertragung zu schützen. Für ruhende Daten, die in Azure Blob Storage gespeichert sind, verwendet Azure DevOps dienstseitige Verschlüsselung.
Das Azure DevOps-Team verwendet die Azure-Infrastruktur, um wichtige Aspekte des Diensts zu protokollieren und zu überwachen. Die Protokollierung und Überwachung tragen dazu bei, sicherzustellen, dass Aktivitäten innerhalb des Diensts legitim sind und sie dabei 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 schädliche oder nicht autorisierte Verhalten löst Echtzeitwarnungen aus.
Wenn das Azure DevOps-Team einen möglichen Angriffs- oder Sicherheitsrisiko mit hoher Priorität identifiziert, verfügt es über einen klaren Antwortplan. Dieser Plan beschreibt die verantwortlichen Parteien, die erforderlichen Schritte zum Sichern von Kundendaten und Anweisungen zum Umgang mit Sicherheitsexperten bei Microsoft. 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 neue Bedrohungen zu bekämpfen, setzt Azure DevOps eine Strategie für Sicherheitsverletzungen ein . Ein hochspezialisiertes Team von Sicherheitsexperten in Microsoft übernimmt die Rolle anspruchsvoller Gegner. 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.
Ransomware-Angriffsschutz
Azure DevOps verwendet Azure-Steuerelemente, um einen Ransomware-Angriff zu verhindern, zu erkennen und darauf zu reagieren. Weitere Informationen dazu, wie Azure Kunden vor Ransomware-Angriffen schützt, finden Sie unter Ransomware-Schutz in Azure.
Datenschutz
Sie sollten vertrauen, dass wir Ihre Daten angemessen und für legitime Zwecke verarbeiten. Ein Teil dieser Sicherheit beinhaltet eine sorgfältige Einschränkung der Nutzung.
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. Weitere Informationen zur DSGVO finden Sie auf der Übersichtsseite im Microsoft Trust Center.
Datenresidenz und Souveränität
Azure DevOps ist in den folgenden acht geografischen Standorten auf der ganzen Welt verfügbar: USA, Kanada, Europa, Vereinigtes Königreich, Indien, Australien, Asien-Pazifik und Brasilien. Standardmäßig wird Ihre Organisation Ihrem nächstgelegenen Standort zugewiesen. Sie können jedoch einen anderen Speicherort auswählen, wenn Sie Ihre Organisation erstellen. Wenn Sie ihre Meinung später ändern, können Sie die Organisation an einen anderen Ort mit Unterstützung des Microsoft-Supports migrieren.
Azure DevOps verschebt oder repliziert keine Kundendaten außerhalb des ausgewählten Standorts. Stattdessen werden Ihre Daten geo-repliziert in eine zweite Region innerhalb desselben Standorts repliziert. Die einzige Ausnahme ist Brasilien, das Daten für Notfallwiederherstellungszwecke in die Region Süd-Zentral-USA repliziert.
Hinweis
Für Builds und Versionen, die auf von Microsoft bereitgestellten macOS-Agents ausgeführt werden, werden Ihre Daten in ein GitHub-Rechenzentrum im USA übertragen.
Weitere Informationen finden Sie unter "Datenspeicherorte für Azure DevOps".
Zugriff auf strafverfolgungsbezwingend
In einigen Fällen können Dritte wie Strafverfolgungsbehörden Microsoft angehen, um Zugriff auf kundendaten zu erhalten, die in Azure DevOps gespeichert sind. Wir versuchen, die Anforderungen zur Lösung an die Organisationsbesitzer umzuleiten. Wenn ein Gerichtsbeschluss Microsoft dazu zwingt, Kundendaten an Dritte weiterzugeben, bemüht sich Microsoft, die Organisationsbesitzer im Voraus zu benachrichtigen, es sei denn, wir sind gesetzlich verboten, dies zu tun.
Einige Kunden benötigen ihre Datenspeicherung an einem bestimmten geografischen Standort, um eine bestimmte rechtsrechtliche Zuständigkeit für alle Strafverfolgungsaktivitäten sicherzustellen. Alle Kundendaten, z. B. Quellcode, Arbeitsaufgaben, Testergebnisse und georedundante Spiegel und offsite-Sicherungen, werden an einem der oben genannten Standorte verwaltet.
Microsoft Access
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 jemals haben), eine Hintergrundüberprüfung bestehen, die frühere Arbeits- 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 in unserem System auf die gleiche Weise behandelt werden, klassifizieren wir Daten in diese Typen:
- Kundendaten: Was Sie in Azure DevOps hochladen.
- Organisationsdaten: Informationen, die Sie übermitteln, wenn Sie sich für Ihre Organisation registrieren oder verwalten.
- Microsoft-Daten: Informationen, die für den Betrieb des Diensts erforderlich oder 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 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 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.
Vertrauensbildung
Sie können sich auf andere Anstrengungen verlassen, die Microsoft im Auftrag von Azure DevOps durchführt. Zu diesen Bemühungen gehören interne Einführungsrichtlinien bei Microsoft, die Transparenz in den Status unseres Diensts und fortschritte bei der Zertifizierung unserer Systeme für die Verwaltung der Informationssicherheit.
Interne Einführung
Microsoft Teams übernehmen Azure DevOps intern. Das Azure DevOps-Team ist 2014 in eine organization umgezogen und nutzt es ausführlich. Wir haben Richtlinien festgelegt, um die Einführungspläne für andere Teams zu ermöglichen.
Große Teams bewegen sich aufgrund ihrer Investitionen in bestehende DevOps-Systeme schrittweiser als kleinere. Für Teams, die sich schnell bewegen, haben wir einen Ansatz für die Projektklassifizierung eingerichtet. 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 das Zuordnen der Organisation zu Microsoft Entra-ID, um die ordnungsgemäße Benutzeridentitätslebenszyklus und kennwortkomplexität sicherzustellen. Projekte, die sensibler sind, erfordern auch die zweistufige Authentifizierung.
Compliancezertifizierungen
Möglicherweise sind Sie daran interessiert, die Bewertung unserer Verfahren zur Datensicherheit von Drittanbietern zu verstehen. Azure DevOps hat die folgenden Zertifizierungen erreicht:
- ISO 27001:2013
- ISO 27018:2019
- ISO 26262:2023
- Health Insurance Portability and Accountability Act (HIPAA)
- Business Associate Agreement (BAA)
- EU-Modellklauseln
- System- und Organisationssteuerelemente (SOC) 1 Typ 2
- SOC 2, Typ 2
- Germany C5
- Australia 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 Fragebogen zur Konsensbewertungsinitiative (Consensus Assessment Initiative, CAIQ) hilft Organisationen dabei, die Sicherheitspraktiken und -funktionen von Clouddienstanbietern zu bewerten und zu bewerten. Im Einklang mit unserem Engagement für Sicherheit und Transparenz haben wir kürzlich die CAIQ-Bewertung für Azure DevOps abgeschlossen. Wir laden Sie ein, den vollständigen Bericht über das Microsoft Service Trust Portal zu überprüfen.
Schritte, die Sie ausführen können
Der richtige Datenschutz erfordert ein aktives Engagement von Ihnen, Ihren Administratoren und Ihren Benutzern. Ihre in Azure DevOps gespeicherten Projektdaten sind nur so sicher wie die Zugriffspunkte des Benutzers. 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 Vertraulichkeits- und Risikohorizont zusammen mit dem Schaden, der bei Kompromittierung auftreten kann. Viele Unternehmen verfügen über vorhandene Klassifizierungsmethoden, die sie wiederverwenden können, wenn Projekte zu Azure DevOps wechseln. Weitere Informationen können Sie die Datenklassifizierung für die Cloudbereitschaft von Microsoft Vertrauenswürdiges Computing herunterladen.
Microsoft Entra-ID übernehmen
Verwenden Sie die Microsoft Entra-ID, um den Zugriff Ihrer Organisation auf Azure DevOps zu verwalten. Die Microsoft Entra-ID bietet eine weitere Möglichkeit, die Sicherheit der Anmeldeinformationen Ihrer Benutzer zu verbessern.
Mit der Microsoft Entra-ID kann Ihre IT-Abteilung ihre Benutzerzugriffsrichtlinie, Kennwortkomplexität, Kennwortaktualisierungen und Ablauf verwalten, wenn Benutzer Ihre Organisation verlassen. Über den Active Directory-Verbund können Sie die Microsoft Entra-ID direkt mit dem zentralen Verzeichnis Ihrer Organisation verknüpfen, sodass Sie nur einen Speicherort zum Verwalten dieser Details für Ihr Unternehmen haben.
In der folgenden Tabelle werden die Microsoft-Konto- und Microsoft Entra-Merkmale im Verhältnis zum Azure DevOps-Zugriff verglichen:
| Eigenschaft | Microsoft-Konto | Microsoft Entra ID |
|---|---|---|
| Identitätsersteller | Benutzer | Organisation |
| Einzelner Benutzername und Kennwort für alle Arbeitsressourcen | No | Ja |
| Kennwortlebensdauer und Komplexitätskontrolle | Benutzer | Organization |
| Azure DevOps-Mitgliedschaftslimits | Jedes Microsoft-Konto | Verzeichnis der Organisation |
| Nachverfolgbare Identität | Nein | Ja |
| Organisation und IP-Besitz | Unklar | Organization |
| Zweistufige 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
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 benötigen, indem Sie die Microsoft Entra-ID verwenden. 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 fällt, verhindert BitLocker den nicht autorisierten Zugriff auf lokale Kopien von Daten aus Ihren Projekten.
Einschränken der Verwendung alternativer Anmeldeinformationen für die Authentifizierung
Der Standardauthentifizierungsmechanismus für Git-bezogene Tools ist eine alternative Authentifizierung (manchmal als Standardauthentifizierung bezeichnet). Mit diesem Mechanismus kann ein Benutzer einen alternativen Benutzernamen und ein kennwort für die Verwendung bei Git-Befehlszeilenvorgängen einrichten. Der Benutzer kann diese Kombination aus Benutzername/Kennwort verwenden, um auf alle anderen Daten zuzugreifen, für die dieser Benutzer über Berechtigungen verfügt. 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 Kommunikationen werden über HTTPS gesendet, und es gibt Anforderungen an die Kennwortkomplexität. Ihre Organisation sollte weiterhin bewerten, ob weitere Richtlinien erforderlich sind, um die Sicherheitsanforderungen Ihrer Projekte zu erfüllen.
Sie können alternative Authentifizierungsanmeldeinformationen deaktivieren, wenn Sie entscheiden, dass sie die Sicherheitsanforderungen Ihrer Organisation nicht erfüllt. Weitere Informationen finden Sie unter Ändern von Anwendungsverbindungs- und Sicherheitsrichtlinien für Ihre Organisation.
Schützen des Zugriffs auf Ihre organization
Administratoren können die Microsoft Entra-ID verwenden, um den Zugriff auf Azure-Ressourcen und -Anwendungen wie Azure DevOps zu steuern. Mit aktivierter Steuerung des bedingten Zugriffs überprüft die Microsoft Entra-ID die spezifischen Bedingungen, die Sie für einen Benutzer für den Zugriff auf eine Anwendung festgelegt haben. 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 persönliche Zugriffstoken, alternative Authentifizierung, OAuth und Secure Shell (SSH)-Schlüssel. Wenn Ihre Benutzer über einen Drittanbieterclient auf Azure DevOps zugreifen, werden nur IPv4-basierte Richtlinien berücksichtigt.