Freigeben über

Neuer DBA in der Cloud – Verwalten von Azure SQL-Datenbank nach der Migration

  • Artikel

Gilt für: Azure SQL-Datenbank

Der Umstieg von der herkömmlichen, selbstverwalteten, automatisch gesteuerten Umgebung auf eine PaaS-Umgebung kann anfangs eine Herausforderung darstellen. Als App-Entwickler oder DBA möchten Sie wissen, welche Plattformfunktionen in erster Linie dafür sorgen, dass Ihre Anwendung verfügbar, leistungsfähig, sicher und zuverlässig ist – und zwar zu jeder Zeit. Dieser Artikel soll Aufklärung leisten. Hier werden die Ressourcen kurz zusammengefasst, und Sie erhalten hilfreiche Informationen zur optimalen Verwendung der wichtigsten Funktionen von Azure SQL-Datenbank mit Einzel- und Pooldatenbanken. So können Sie Ihre Anwendung effizient verwalten und ausführen, um optimale Ergebnisse in der Cloud zu erzielen. Die typische Zielgruppe für diesen Artikel sind Nutzer, die:

  • Die Migration ihrer Anwendung(en) zu Azure SQL Database evaluieren – Ihre Anwendung(en) modernisieren.
  • Sind im Begriff, ihre Anwendung(en) zu migrieren – Laufendes Migrationsszenario.
  • Wir haben vor kurzem die Migration zu Azure SQL Database abgeschlossen – Neue DBA in der Cloud.

Dieser Artikel behandelt einige der Hauptmerkmale der Azure SQL-Datenbank als Plattform, die Sie bei der Arbeit mit Einzel- und Pooldatenbanken in Pools für elastische Datenbanken mühelos nutzen können. In Einzelnen sind das die folgenden:

  • Überwachen von Datenbanken über das Azure-Portal
  • Geschäftskontinuität und Notfallwiederherstellung (Business Continuity Disaster Recovery, BCDR)
  • Sicherheit und Compliance
  • Intelligente Datenbanküberwachung und -wartung
  • Datenverschiebung

Hinweis

Microsoft Entra ID war zuvor als Azure Active Directory (Azure AD) bekannt.

Überwachen von Datenbanken über das Azure-Portal

Weitere Informationen zu Metriken und Warnungen von Azure Monitor, einschließlich empfohlener Warnungsregeln, finden Sie unter Überwachen der Azure SQL-Datenbank mit Metriken und Warnungen. In den Artikeln DTU-basiertes Kaufmodell für Azure SQL-Datenbank und vCore-basiertes Kaufmodell finden Sie weitere Informationen zu Dienstebenen.

Sie können Warnungen für die Leistungsmetriken konfigurieren. Wählen Sie im Fenster Metrik die Schaltfläche Warnung hinzufügen aus. Befolgen Sie die Anweisungen des Assistenten, um die Benachrichtigung zu konfigurieren. Sie haben die Möglichkeit, Benachrichtigungen für den Fall zu konfigurieren, dass Metriken einen Schwellenwert überschreiten oder unterschreiten.

Wenn Sie beispielsweise einen Anstieg der Workload Ihrer Datenbank erwarten, können Sie eine E-Mail-Benachrichtigung konfigurieren, die immer dann gesendet wird, wenn eine der Leistungsmetriken der Datenbank 80 % erreicht. Sie können dies als Frühwarnung verwenden, um zu ermitteln, wann Sie eventuell zur nächsthöheren Computegröße wechseln müssen.

Anhand der Leistungsmetriken können Sie auch ermitteln, ob Sie möglicherweise eine Herabstufung auf eine niedrigere Computegröße vornehmen können. Bevor Sie sich für einen Wechsel zu einer niedrigeren Computegröße entscheiden, müssen Sie aber auch Workloads berücksichtigen, die Spitzen oder Schwankungen aufweisen können.

Geschäftskontinuität und Notfallwiederherstellung (Business Continuity Disaster Recovery, BCDR)

Dank der Funktionen für Geschäftskontinuität und Notfallwiederherstellung können Sie Ihre Geschäfte in einem Notfall wie gewohnt fortführen. Ein Notfall könnte auf Datenbankebene auftreten (ein Nutzer löscht z. B. versehentlich eine unternehmenswichtige Tabelle) oder das gesamte Datencenter betreffen (bei einer regionalen Katastrophe wie einem Tsunami).

Wie werden Sicherungen für SQL-Datenbank erstellt und verwaltet?

Sie erstellen unter Azure SQL-Datenbank keine Sicherungen, weil dies nicht erforderlich ist. Ihre Datenbanken werden von SQL-Datenbank automatisch gesichert, sodass Sie sich nicht länger um das Planen, Erstellen und Verwalten von Sicherungen kümmern müssen. Die Plattform führt jede Woche eine vollständige Sicherung, alle paar Stunden eine differenzielle Sicherung und alle fünf Minuten eine Transaktionsprotokollsicherung durch. So ist gewährleistet, dass Daten nach einem Notfall effizient wiederhergestellt werden können und Datenverluste gering bleiben. Die erste vollständige Sicherung erfolgt direkt nach dem Erstellen einer Datenbank. Diese Sicherungen stehen Ihnen während eines bestimmten Zeitraums zur Verfügung, dem sogenannten „Aufbewahrungszeitraum“, der je nach ausgewählter Dienstebene variiert. SQL-Datenbank bietet mit der Zeitpunktwiederherstellung (Point in Time Recovery, PITR) die Möglichkeit, Daten bis zu einem beliebigen Zeitpunkt innerhalb dieser Beibehaltungsdauer wiederherzustellen.

Außerdem können Sie über das Feature für die langfristige Aufbewahrung (Long-Term Retention, LTR) Sicherungsdateien über einen wesentlich längeren Zeitraum (bis zu zehn Jahre) aufbewahren und Daten zu einem beliebigen Zeitpunkt innerhalb dieser Frist aus den Sicherungen wiederherstellen. Darüber hinaus werden Datenbanksicherungen in georeplizierten Speichersystemen vorgehalten, um bei einer regionalen Katastrophe Datenresilienz zu gewährleisten. Die Sicherungen können auch in jeder Azure-Region zu einem beliebigen Zeitpunkt innerhalb der Beibehaltungsdauer wiederhergestellt werden. Weitere Informationen finden Sie unter Konfigurationsübersicht.

Wie wird Geschäftskontinuität bei einem Notfall in den Datencentern oder einer regionalen Katastrophe gewährleistet?

Da Ihre Datenbanksicherungen in einem georeplizierten Speicher gespeichert werden, ist sichergestellt, dass Sie die Sicherungen bei einem regionalen Notfall in einer anderen Azure-Region wiederherstellen können. Dieser Vorgang wird als Geowiederherstellung bezeichnet. Die RPO (Recovery Point Objective) dafür beträgt im Allgemeinen < 1 Stunde und die geschätzte Wiederherstellungszeit (Estimated Recovery Time, ERT) wenige Minuten bis Stunden.

Für unternehmenskritische Datenbanken bietet Azure SQL-Datenbank eine aktive Georeplikation, die eine georeplizierte sekundäre Kopie Ihrer ursprünglichen Datenbank in einer anderen Region erstellt. Wenn Ihre Datenbank beispielsweise ursprünglich in der Azure-Region West US gehostet wird und Sie eine regionale Ausfallsicherheit wünschen, erstellen Sie eine aktive Geo-Replik der Datenbank von den West- zu den Ost-USA. Wenn der Westen der USA von einer Katastrophe heimgesucht wird, können Sie auf die Region Osten der USA ausweichen.

Zusätzlich zur aktiven Georeplikation bieten Failovergruppen eine bequeme Möglichkeit zum Verwalten der Replikation und des Failovers einer Gruppe von Datenbanken. Sie können eine Failovergruppe erstellen, die mehrere Datenbanken in denselben oder verschiedenen Regionen enthält. Anschließend können Sie ein Failover aller Datenbanken in der Failovergruppe in die sekundäre Region initiieren. Weitere Informationen finden Sie unter Failovergruppen.

Um Ausfallsicherheit für Ausfall von Rechenzentren oder Verfügbarkeitszonen zu erzielen, stellen Sie sicher, dass Zonenredundanz für die Datenbank oder den elastischen Pool aktiviert ist.

Überwachen Sie Ihre Anwendung aktiv auf ein Notfall, und initiieren Sie ein Failover auf die sekundäre. Sie können bis zu vier aktive geografische Replikate in verschiedenen Azure-Regionen erstellen. Allerdings haben Sie noch weitere Möglichkeiten. Sie können auch schreibgeschützt auf diese sekundären aktiven geografischen Replikate zugreifen. Dies ist sehr praktisch, um die Latenz bei einem Szenario mit einer geografisch verteilten Anwendung zu reduzieren.

Wie sieht die Notfallwiederherstellung mit SQL-Datenbank

Die Konfiguration und die Verwaltung der Notfallwiederherstellung können mit nur wenigen Schritten in der Azure SQL-Datenbank erfolgen, wenn Sie die aktive Georeplikation oder Failovergruppen verwenden. Sie müssen die Anwendung und deren Datenbank weiterhin auf regionale Katastrophen überwachen und an die sekundäre Region fehlschlagen, um die Geschäftskontinuität wiederherzustellen.

Weitere Informationen zur Notfallwiederherstellung finden Sie unter Notfallwiederherstellung für Azure SQL-Datenbank 101.

Sicherheit und Compliance

Sicherheit und Datenschutz haben in SQL-Datenbank einen hohen Stellenwert. Die Sicherheit in SQL-Datenbank kann auf Datenbankebene und auf Plattformebene angewendet werden und lässt sich am besten anhand der verschiedenen Ebenen erklären. Sie haben auf jeder Ebene die Möglichkeit, Ihre Anwendung zu kontrollieren und optimal zu schützen. Die Ebenen lauten:

Microsoft Defender für Cloud bietet eine zentralisierte Sicherheitsverwaltung über verschiedene Workloads hinweg an, die in Azure-Clouds und in lokalen sowie anderen Clouds ausgeführt werden können. Sie können nachvollziehen, ob grundlegende Schutzmaßnahmen von SQL-Datenbank, wie Überwachung und Transparent Data Encryption [TDE] für alle Ressourcen konfiguriert wurden, und anhand Ihrer eigenen Anforderungen Richtlinien erstellen.

Welche Benutzerauthentifizierungsmethoden werden in SQL-Datenbank angeboten?

SQL-Datenbank bietet zwei Authentifizierungsmethoden:

Die Windows-Authentifizierung wird nicht unterstützt. Microsoft Entra ID ist ein zentraler Identitäts- und Zugriffsverwaltungsdienst. Er ermöglicht sämtlichen Mitarbeitenden Ihrer Organisation den bequemen Zugriff per einmaliger Anmeldung (SSO, Single Sign-On). Dies vereinfacht die Authentifizierung, da die Anmeldeinformationen für Azure-Dienste gemeinsam genutzt werden.

Microsoft Entra ID unterstützt Multi-Faktor-Authentifizierung und kann auf einfache Weise in Windows Server Active Directory integriert werden. Dadurch können SQL-Datenbank und Azure Synapse Analytics außerdem Multi-Faktor-Authentifizierung und Gastbenutzerkonten innerhalb einer Microsoft Entra-Domäne anbieten. Wenn Sie bereits ein lokales Active Directory verwenden, können Sie einen Partnerverbund zwischen diesem Verzeichnis und Microsoft Entra ID einrichten und das Verzeichnis auf Azure erweitern.

Die SQL-Authentifizierung unterstützt nur Benutzername und Kennwort zum Authentifizieren von Benutzern bei einer Datenbank auf einem bestimmten Server.

Wenn Sie... SQL-Datenbank/Azure Synapse Analytics
AD auf einem lokalen SQL-Server verwendet haben, richten Sie einen Partnerverbund zwischen AD und Microsoft Entra ID ein, und verwenden Sie die Microsoft Entra-Authentifizierung. Mithilfe des Verbunds können Sie Single Sign-On verwenden.
Multi-Faktor-Authentifizierung durchsetzen müssen Multi-Faktor-Authentifizierung als Richtlinie über bedingten Zugriff von Microsoft erfordern und die Multi-Faktor-Authentifizierung in Microsoft Entra verwenden.
Sie sind mit Ihren Microsoft Entra-Anmeldeinformationen aus einer Verbunddomäne bei Windows angemeldet Die integrierte Microsoft Entra-Authentifizierung verwenden.
Mit Ihren Anmeldeinformationen aus einer Domäne, die nicht mit Azure verbunden ist, bei Windows angemeldet Die integrierte Microsoft Entra-Authentifizierung verwenden.
über Dienste auf mittlerer Ebene verfügen, die eine Verbindung mit SQL-Datenbank oder Azure Synapse Analytics herstellen müssen, Die integrierte Microsoft Entra-Authentifizierung verwenden.
Eine technische Anforderung für die Verwendung der SQL-Authentifizierung haben Verwenden Sie SQL-Authentifizierung

Wie werden Verbindungen mit der Datenbank beschränkt oder kontrolliert?

Es gibt mehrere Methoden, um Verbindungszugriffe für Ihre Anwendung optimal zu organisieren.

  • Firewallregeln
  • VNET-Dienstendpunkte
  • Reservierte IP-Adressen

Firewall

Eine Firewall verhindert externe Zugriffe auf Ihren Server, indem nur bestimmten Entitäten Zugang zu Ihrem Server gewährt wird. Standardmäßig sind alle Verbindungen mit dem Server und darauf enthaltenen Datenbanken unzulässig – es sei denn (optionally7), es handelt sich um Verbindungen von anderen Azure-Diensten. Mit einer Firewallregel können Sie den Serverzugriff auf bestimmte Entitäten(z. B. einen Entwicklercomputer) begrenzen, indem Sie zulassen, dass der Computer mit der jeweiligen IP-Adresse die Firewall passieren darf. Zudem können Sie einen Bereich von IP-Adressen angeben, über die Sie den Zugriff auf den Server gewähren möchten. Beispielsweise können Sie die IP-Adressen aller Entwicklercomputer in Ihrer Organisation in einem Schritt hinzufügen, indem Sie auf der Seite für Firewalleinstellungen einen Bereich angeben.

Firewallregeln können auf Server- oder auf Datenbankebene erstellt werden. IP-Firewallregeln auf Serverebene können mithilfe des Azure-Portals oder mit SSMS erstellt werden. Weitere Informationen zum Festlegen von Firewallregeln auf Server- und Datenbankebene finden Sie unter: Erstellen von IP-Firewallregeln in SQL-Datenbank.

Dienstendpunkte

Die Datenbank ist standardmäßig so konfiguriert, dass die Option „Azure-Diensten und Ressourcen Zugriff auf diesen Server erlauben“ aktiviert ist. Das bedeutet, dass alle virtuellen Maschinen in Azure versuchen können, eine Verbindung mit der Datenbank herzustellen. Die Verbindungsversuche müssen jedoch noch authentifiziert werden. Wenn Sie nicht möchten, dass Ihre Datenbank für Azure-IPs zugänglich ist, können Sie die Option „Azure-Diensten und Ressourcen Zugriff auf diesen Server erlauben“ deaktivieren. Außerdem können Sie VNET-Dienstendpunkte konfigurieren.

Mit Dienstendpunkten können Sie wichtige Azure-Ressourcen ausschließlich für Ihr eigenes privates virtuelles Netzwerk in Azure verfügbar machen. Auf diese Weise verhindern Sie praktisch den öffentlichen Zugriff auf Ihre Ressourcen. Der Datenverkehr zwischen Ihrem virtuellen Netzwerk und Azure erfolgt weiterhin über das Azure-Backbonenetzwerk. Ohne Dienstendpunkte würden Pakete mit erzwungenem Tunneling geroutet werden. Ihr virtuelles Netzwerk erzwingt, dass der an Ihre Organisation gerichtete Internetdatenverkehr und der Datenverkehr der Azure-Dienste über dieselbe Route transportiert werden. Mit Dienstendpunkten können Sie das Routing verbessern, da die Pakete direkt von Ihrem virtuellen Netzwerk zum Dienst im Azure-Backbonenetzwerk transportiert werden.

Reservierte IP-Adressen

Sie können auch reservierte IP-Adressen für Ihre virtuellen Computer bereitstellen und diese IP-Adressen für spezifische virtuelle Computer den Firewalleinstellungen des Servers hinzufügen. Das Zuweisen von reservierten IP-Adressen erspart Ihnen das Aktualisieren von Firewallregeln, wenn sich die IP-Adressen ändern.

Über welchen Port werden Verbindungen mit SQL-Datenbank hergestellt?

Über Port 1433. SQL-Datenbank kommuniziert über diesen Port. Um Verbindungen aus einem Unternehmensnetzwerk herzustellen, müssen Sie in den Firewalleinstellungen Ihrer Organisation eine ausgehende Regel hinzufügen. Port 1433 sollte grundsätzlich nicht außerhalb von Azure verfügbar gemacht werden.

Wie werden Aktivitäten auf dem Server und in der Datenbank in SQL-Datenbank überwacht und geregelt?

SQL-Datenbanküberwachung

In SQL-Datenbank kann die Überwachung aktiviert werden, um Datenbankereignisse nachzuverfolgen. Die SQL-Datenbanküberwachung zeichnet Datenbankereignisse auf und schreibt sie in eine Überwachungsprotokolldatei unter Ihrem Azure Storage-Konto. Die Überwachung bietet optimale Unterstützung bei der Verfolgung möglicher Sicherheitsverletzungen und Richtlinienverstöße, bei der Einhaltung gesetzlicher Bestimmungen usw. Sie können bestimmte Ereigniskategorien definieren und konfigurieren, die Sie überwachen möchten, und auf Grundlage Ihrer Definitionen vorkonfigurierte Berichte abrufen oder ein Dashboard nutzen, um sich eine Übersicht über die in der Datenbank auftretenden Ereignisse zu verschaffen. Die Überwachungsrichtlinien können auf Datenbank- oder auf Serverebene angewendet werden. Einen Leitfaden zum Aktivieren der Überwachung für Ihre Server/Datenbank finden Sie unter: Aktivieren der SQL-Datenbanküberwachung.

Bedrohungserkennung

Die Bedrohungserkennung bietet eine einfache Möglichkeit, auf die von der Überwachung erkannten Sicherheits- oder Richtlinienverletzungen zu reagieren. Sie müssen kein Sicherheitsexperte sein, um potenzielle Bedrohungen oder Verstöße in Ihrem System zu beseitigen. Die Bedrohungserkennung ist auch in der Lage, die Einschleusung von SQL-Befehlen zu erkennen. Mit der Einschleusung von SQL-Befehlen wird versucht, Daten zu manipulieren oder zu kompromittieren. Die Methode wird im Allgemeinen für Angriffe auf Datenbankanwendungen eingesetzt. Die Bedrohungserkennung führt mehrere verschiedene Algorithmen aus, die potentielle Sicherheitsrisiken, Angriffe mit Einschleusung von SQL-Befehlen und ungewöhnliche Muster für den Zugriff auf die Datenbank (wie der Zugriff von einem ungewöhnlichen Ort oder einem unbekannten Prinzipal aus) ermitteln. Sicherheitsbeauftragte oder andere vorgesehene Administratoren erhalten eine E-Mail-Benachrichtigung, wenn eine Bedrohung auf der Datenbank erkannt wird. Jede Benachrichtigung enthält Details zur verdächtigen Aktivität und Empfehlungen zur weiteren Untersuchung und Abwendung der Bedrohung. Informationen zum Aktivieren der Bedrohungserkennung finden Sie unter: Aktivieren der Bedrohungserkennung.

Welchen grundsätzlichen Schutz bietet SQL-Datenbank für Daten?

Die Verschlüsselung bietet wirkungsvollen Schutz vor unbefugten Zugriffen auf sensible Daten. Ohne Entschlüsselungsschlüssel sind verschlüsselte Daten für Angreifer wertlos. Auf diese Weise bietet sie zusätzlichen Schutz und ergänzt die bereits in SQL-Datenbank integrierten Sicherheitsstufen. Der Schutz Ihrer Daten in SQL-Datenbank umfasst zwei Datenkategorien:

  • In Daten- und Protokolldateien „ruhende“ Daten
  • Aktive Daten

Ruhende Daten in den Daten- und Protokolldateien auf einem Speichersubsystem sind in SQL-Datenbank standardmäßig per Transparent Data Encryption [TDE] jederzeit vollständig verschlüsselt. Ihre Sicherungen werden ebenfalls verschlüsselt. Bei Verwendung von TDE sind keine Änderungen an den Anwendungen erforderlich, die auf diese Daten zugreifen. Wie der Name erkennen lässt, erfolgen die Verschlüsselung und Entschlüsselung transparent. Zum Schutz sensibler Daten, die aktiv oder ruhend sein können, bietet SQL-Datenbank eine Funktion namens Always Encrypted (AE). AE ist eine Form der clientseitigen Verschlüsselung, die sensible Spalten in Ihrer Datenbank verschlüsselt (sodass sie für Datenbankadministratoren und nicht autorisierte Benutzer als Chiffretext dargestellt werden). Der Server empfängt zunächst die verschlüsselten Daten. Der Schlüssel für die Always Encrypted-Verschlüsselung wird ebenfalls auf Clientseite gespeichert, damit die sensiblen Spalten nur von autorisierten Clients entschlüsselt werden können. Server- und Datenadministratoren haben keinen Zugriff auf die sensiblen Daten, da die Verschlüsselungsschlüssel auf dem Client gespeichert sind. AE wendet eine End-to-End-Verschlüsselung auf sensible Tabellenspalten an – von nicht autorisierten Clients bis zum physischen Datenträger. Da AE aktuell Übereinstimmungsvergleiche unterstützt, können DBAs im Rahmen ihrer SQL-Befehle weiterhin verschlüsselte Spalten abfragen. Diese Verschlüsselungsmethode kann mit einer Vielzahl von Schlüsselspeicheroptionen wie Azure Key Vault, dem Windows-Zertifikatspeicher sowie lokalen Hardware-Sicherheitsmodulen verwendet werden.

Merkmale Always Encrypted Transparente Datenverschlüsselung (TDE)
Umfang der Verschlüsselung Komplettlösung Ruhende Daten
Server kann auf sensible Daten zuzugreifen Nein Ja, da die Verschlüsselung ruhende Daten betrifft
Zulässige T-SQL-Vorgänge Gleichheitsvergleich Die gesamte T-SQL-Oberfläche ist verfügbar
Sind zur Verwendung der Funktion Änderungen an Apps erforderlich? Wenig Sehr wenig
Granularität der Verschlüsselung Spaltenebene Datenbankebene

Wie wird der Zugriff auf sensible Daten in der Datenbank beschränkt?

Jede Anwendung verfügt zu einem gewissen Grad über sensible Daten in der Datenbank, die vor unbefugtem Zugriff geschützt werden müssen. Bestimmte Personen innerhalb der Organisation müssen diese Daten anzeigen können, während sie anderen verborgen bleiben sollten. Ein Beispiel sind Mitarbeitergehälter. Vorgesetzte müssen auf die Gehaltsinformationen ihrer Mitarbeiter zugreifen können, doch einzelne Teammitglieder dürfen keinen Zugang zu den Gehaltsinformationen ihrer Kollegen haben. In einem weiteren Szenario könnten Datenentwickler in der Entwicklungs- oder Testphase mit sensiblen Daten interagieren, z. B. mit Sozialversicherungsnummern von Kunden. Auch diese Informationen müssen dem Entwickler nicht verfügbar gemacht werden. In diesen Fällen müssen Ihre sensiblen Daten entweder maskiert oder überhaupt nicht bereitgestellt werden. SQL-Datenbank bietet zwei Methoden, um nicht autorisierten Benutzern den Zugang zu sensiblen Daten zu verweigern:

Die dynamische Datenmaskierung ist eine Funktion zum Maskieren von Daten, mit der Sie die Offenlegung sensibler Daten beschränken können. So werden die Daten auf der Anwendungsschicht für nicht berechtigte Benutzer maskiert. Sie definieren eine Maskierungsregel, die ein Maskierungsmuster erstellen (z.B. zum Anzeigen nur der letzten vier Ziffern einer nationalen ID-SSN in der Form: XXX-XX-0000 und Markieren des größten Teils als „X“) und ermitteln kann, welche Benutzer von der Maskierungsregel ausgeschlossen werden sollen. Die Daten werden dynamisch maskiert. Für die verschiedenen Datenkategorien stehen mehrere Maskierungsfunktionen zur Verfügung. Dank der dynamischen Datenmaskierung können sensible Daten in Ihrer Datenbank automatisch erkannt und maskiert werden.

Durch die Sicherheit auf Zeilenebene können Sie den Zugriff auf Zeilenebene steuern. Dies bedeutet, dass bestimmte Zeilen in einer Datenbanktabelle basierend auf dem Benutzer ausgeblendet werden, der die Abfrage ausführt (Gruppenmitgliedschaft oder Ausführungskontext). Die Zugangsbeschränkung wird nicht auf Anwendungsebene, sondern auf Datenbankebene festgelegt, damit die App-Logik vereinfacht wird. Zunächst erstellen Sie ein Filterprädikat, das Zeilen herausfiltert, die nicht angezeigt werden sollen. Als Nächstes erstellen Sie die Sicherheitsrichtlinie, die definiert, wer Zugang zu den Zeilen erhält. Zuletzt führt der Endbenutzer seine Abfrage aus und kann diese eingeschränkten Zeilen – abhängig von seinen Benutzerberechtigungen – entweder anzeigen oder nicht.

Wie werden Verschlüsselungsschlüssel in der Cloud verwaltet?

Es gibt sowohl für die Methode Always Encrypted (clienstseitige Verschlüsselung) als auch für Transparent Data Encryption (Verschlüsselung ruhender Daten) Optionen zur Schlüsselverwaltung. Es wird empfohlen, Verschlüsselungsschlüssel regelmäßig zu rotieren. Die Rotationsfrequenz sollte sowohl die internen Bestimmungen Ihrer Organisation als auch die Complianceanforderungen erfüllen.

TDE (Transparent Data Encryption)

In TDE liegt eine Zwei-Schlüssel-Hierarchie vor: Die Daten in allen Benutzerdatenbanken werden mit einem in der Datenbank eindeutigen symmetrischen AES 256-Datenbankverschlüsselungsschlüssel verschlüsselt, der wiederum von einem auf dem Server eindeutigen asymmetrischen RSA 2048-Masterschlüssel verschlüsselt wird. Der Hauptschlüssel kann wie folgt verwaltet werden:

  • Automatisch von der Plattform – SQL-Datenbank.
  • Unter Verwendung von Azure Key Vault als Schlüsselspeicher.

Der Masterschlüssel für die Transparent Data Encryption-Methode wird der Einfachheit halber vom SQL-Datenbank-Dienst verwaltet. Wenn Ihre Organisation den Masterschlüssel überwachen möchte, können Sie Azure Key Vault als Schlüsselspeicher verwenden. Dadurch hat Ihre Organisation die Kontrolle über die Schlüsselbereitstellung, die Rotation und die Berechtigungen. Die Rotation oder der Typwechsel des TDE-Masterschlüssels geht schnell vonstatten, da nur Verschlüsselungsschlüssel wieder verschlüsselt werden. Für Organisationen, die die Funktionen der Sicherheits- und Datenverwaltung trennen, kann ein Sicherheitsadministrator das Schlüsselmaterial für den TDE-Hauptschlüssel in Azure Key Vault bereitstellen und dem Datenbankadministrator eine Azure Key Vault-Schlüsselkennung zur Verfügung stellen, die er zur Verschlüsselung ruhender Daten auf einem Server verwenden soll. Key Vault ist dafür ausgelegt, dass Microsoft Verschlüsselungsschlüssel weder anzeigt noch extrahiert. Zusätzlich können Sie eine zentrale Schlüsselverwaltung für Ihre Organisation nutzen.

Always Encrypted

Es gibt auch eine Zwei-Schlüssel-Hierarchie in Always Encrypted: Eine Spalte mit vertraulichen Daten wird mit einem AES 256-Spaltenverschlüsselungsschlüssel verschlüsselt, der wiederum mit einem Spaltenmasterschlüssel verschlüsselt wird. Die Clienttreiber, die für die Always Encrypted-Methode zur Verfügung gestellt werden, haben keine Beschränkungen im Hinblick auf die Länge des Spaltenhauptschlüssels. Der verschlüsselte Wert des Spaltenverschlüsselungsschlüssel wird in der Datenbank gespeichert, und der Spaltenhauptschlüssel wird in einem vertrauenswürdigen Schlüsselspeicher wie dem Windows-Zertifikatspeicher, Azure Key Vault oder einem Hardware-Sicherheitsmodul gespeichert.

  • Sowohl der Spaltenverschlüsselungsschlüssel als auch der Spaltenhauptschlüssel können gedreht werden.
  • Die Rotation des Spaltenverschlüsselungsschlüssels ist datenintensiv und kann abhängig von der Größe der Tabellen, die die verschlüsselten Spalten enthalten, zeitaufwendig sein. Daher empfiehlt es sich, Rotationen von Spaltenverschlüsselungsschlüsseln entsprechend zu planen.
  • Die Rotation des Spaltenhauptschlüssels beeinträchtigt die Datenbankleistung dagegen nicht und kann mit getrennten Rollen durchgeführt werden.

Das folgende Diagramm stellt eine Übersicht über die wichtigsten Schlüsselspeicheroptionen für die Spaltenhauptschlüssel bei der Always Encrypted-Methode dar

Diagramm der Always Encrypted-Speicheranbieter für den Spaltenhauptschlüssel.

Wie wird der Datenverkehr zwischen der Organisation und SQL-Datenbank optimiert und geschützt?

Der Netzwerkdatenverkehr zwischen Ihrer Organisation und SQL-Datenbank würde normalerweise über das öffentliche Netzwerk geroutet werden. Wenn Sie diesen Pfad jedoch optimieren und sicherer gestalten möchten, sollten Sie Azure ExpressRoute in Betracht ziehen. Mit ExpressRoute lässt sich Ihr Unternehmensnetzwerk über eine private Verbindung praktisch auf die gesamte Azure-Plattform ausweiten. Auf diese Weise werden keine Daten über das öffentliche Internet übertragen. Zusätzlich erhöhen sich die Sicherheit und Zuverlässigkeit, und das Routing wird optimiert. So erzielen Sie geringere Netzwerklatenzen und höhere Geschwindigkeiten, als das öffentliche Internet normalerweise bietet. Wenn Sie beabsichtigen, einen erheblichen Datenblock zwischen Ihrer Organisation und Azure zu übertragen, bietet ExpressRoute möglicherweise Kostenvorteile. Für Verbindungen zwischen Ihrer Organisation und Azure stehen drei Konnektivitätsmodelle zur Auswahl:

Mit ExpressRoute können Sie Ihre kostenpflichtige Bandbreite ohne zusätzliche Gebühren bis auf das Doppelte steigern. Außerdem ist es möglich, die Verbindung regionsübergreifend mithilfe von ExpressRoute zu konfigurieren. Eine Liste von ExpressRoute-Konnektivitätsanbietern finden Sie unter: ExpressRoute-Partner und Peeringstandorte. In den folgenden Artikeln wird ExpressRoute ausführlicher beschrieben:

Ist SQL-Datenbank mit allen gesetzlichen Anforderungen kompatibel, und inwiefern hilft dies dabei, die Kompatibilitätsvorgaben meiner eigenen Organisation einzuhalten?

Von SQL-Datenbank werden verschiedene gesetzliche Bestimmungen erfüllt. Im Microsoft Trust Center erfahren Sie, welche Compliancestandards von SQL-Datenbank derzeit erfüllt werden. Dort können Sie sich informieren, ob die Complianceanforderungen Ihrer Organisation erfüllt werden, und ermitteln, ob SQL-Datenbank zu den konformen Azure-Diensten gehört. Wichtiger Hinweis: Obwohl die SQL-Datenbank als konformer Dienst zertifiziert ist, unterstützt sie den Dienst Ihrer Organisation lediglich bei der Umsetzung der Compliancestandards, ohne deren Einhaltung automatisch zu gewährleisten.

Intelligente Datenbanküberwachung und -wartung nach der Migration

Nachdem Sie Ihre Datenbank zu SQL-Datenbank migriert haben, möchten Sie sie überwachen (z. B. die Ressourcenverwendung überprüfen oder DBCC-Überprüfungen durchführen) und regelmäßige Wartungsaufgaben durchführen (z. B. Indizes, Statistiken usw. neu erstellen oder neu organisieren). SQL-Datenbank arbeitet in dem Sinne intelligent, dass der Dienst historische Trends und aufgezeichnete Metriken und Statistiken nutzt, um proaktive Unterstützung bei der Datenbanküberwachung und -wartung zu leisten und zu gewährleisten, dass die Anwendung immer optimal funktioniert. In einigen Fällen können Wartungsaufgaben abhängig von der Konfiguration von Azure SQL-Datenbank automatisch ausgeführt werden. Die Überwachung Ihrer Datenbank in SQL-Datenbank umfasst drei Aspekte:

  • Leistungsüberwachung und -optimierung.
  • Sicherheitsoptimierung.
  • Kostenoptimierung.

Leistungsüberwachung und -optimierung

Query Performance Insight liefert maßgeschneiderte Empfehlungen zur Datenbankworkload, damit Anwendungen immer optimal ausgeführt werden. Sie können die Funktion auch so konfigurieren, dass die Empfehlungen automatisch angewendet werden und Sie sich keine Gedanken um Wartungsaufgaben machen müssen. Mit dem SQL Database Advisor können Sie automatisch Indexempfehlungen basierend auf Ihrer Workload implementieren. Dieser Vorgang wird als automatische Optimierung bezeichnet. Die Empfehlungen ändern sich parallel zur Arbeitsauslastung Ihrer Anwendung, sodass Sie immer relevante Vorschläge erhalten. Sie können diese Empfehlungen auch manuell überprüfen und nach Ihrem Ermessen anwenden.

Sicherheitsoptimierung

Die SQL-Datenbank bietet handlungsrelevante Sicherheitsempfehlungen, die Sie beim Schutz Ihrer Daten unterstützen, sowie eine Bedrohungserkennung, mit der verdächtige Datenbankaktivitäten, die die Datenbank u. U. gefährden, ermittelt und untersucht werden. Bei der Bewertung von Sicherheitsrisiken handelt es sich um einen Überprüfungs- und Berichterstellungsdienst für Datenbanken, mit dessen Hilfe Sie den Sicherheitsstatus Ihrer Datenbanken effektiv überwachen sowie Sicherheitsrisiken und Abweichungen von der von Ihnen definierten Sicherheitsbaseline ermitteln können. Nach jeder Überprüfung wird neben einer benutzerdefinierte Liste mit zur Umsetzung empfohlenen Schritten und Wiederherstellungsskripts auch ein Bewertungsbericht zur Verfügung gestellt, der zur Einhaltung von Kompatibilitätsanforderungen verwendet werden kann.

Mit Microsoft Defender für Cloud können Sie die Sicherheitsempfehlungen generell ermitteln und schnell anwenden.

Kostenoptimierung

Die Azure SQL-Plattform analysiert den Nutzungsverlauf übergreifend über die Datenbanken auf einem Server, um Optionen zur Kostenoptimierung zu bewerten und zu empfehlen. Die Analyse und Formulierung umsetzbarer Empfehlungen dauert normalerweise einige Wochen.

Wie wird die Leistung und Ressourcenverwendung in SQL-Datenbank überwacht?

Sie können die Leistung und Ressourcenverwendung in SQL-Datenbank mithilfe der folgenden Methoden überwachen:

Datenbank-Watcher

Der Datenbankwatcher erfasst detaillierte Workload-Überwachungsdaten und vermittelt Ihnen detaillierte Einblicke in die Datenbankleistung, Konfiguration und Integrität. Dashboards im Azure-Portal vermitteln einen umfassenden Überblick über Ihre Azure SQL-Umgebung und Detailansichten aller überwachten Ressourcen. Die Daten werden in einem zentralen Datenspeicher in Ihrem Azure-Abonnement erfasst. Die erfassten Daten können Sie abfragen, analysieren, exportieren und visualisieren und in nachgelagerte Systeme integrieren.

Weitere Informationen zum Datenbank-Watcher finden Sie in den folgenden Artikeln:

Azure-Portal

Im Azure-Portal zeigen Sie die Nutzung einer Datenbank an, indem Sie sie auswählen und im Bereich „Übersicht“ das Diagramm auswählen. Sie können das Diagramm ändern, sodass mehrere Metriken z.B. zum CPU-, DTU- und Data IO-Prozentsatz sowie zu den Sitzungen und Datenbankgrößen in Prozent angezeigt werden.

Screenshot eines Überwachungsdiagramms einer Datenbank-DTU aus dem Azure-Portal.

In diesem Diagramm können Sie außerdem Warnungen nach Ressourcen konfigurieren. Die Warnungen ermöglichen es Ihnen, auf Ressourcenbedingungen mit einer E-Mail oder einer Benachrichtigung an einen HTTPS-/HTTP-Endpunkt zu reagieren oder eine Aktion auszuführen. Weitere Informationen finden Sie unter Warnungen erstellen.

Dynamische Verwaltungssichten

Sie können die dynamische Verwaltungssicht sys.dm_db_resource_stats abfragen, um den statistischen Verlauf des Ressourcenverbrauchs der letzten Stunde zurückzugeben. Ebenso können Sie die Systemkatalogsicht sys.resource_stats abfragen, um den Verlauf der letzten 14 Tage zurückzugeben.

Statistik zur Abfrageleistung

Über Statistik zur Abfrageleistung können Sie den Verlauf der Abfragen, die den höchsten Ressourcenverbrauch aufweisen, und die Abfragen mit langer Laufzeit für eine bestimmte Datenbank einsehen. Sie können schnell Abfragen mit der höchsten Ressourcenverwendung, Dauer und Ausführungshäufigkeit identifizieren. Sie können Abfragen nachverfolgen und Regressionen erkennen. Für Dieses Feature muss der Abfragespeicher aktiviert und für die Datenbank aktiv sein.

Screenshot einer Statistik zur Abfrageleistung aus dem Azure-Portal.

Es fallen Probleme mit der Leistung auf: Wie unterscheiden sich die Methoden zur Problembehandlung bei SQL-Datenbank von den Methoden bei SQL Server?

Viele Problembehandlungen zur Diagnose von Problemen bei der Abfrage- und Datenbankleistung bleiben unverändert. Schließlich wird die Cloud von derselben Datenbank-Engine unterstützt. Die Plattform – Azure SQL-Datenbank – verfügt jedoch über integrierte „Intelligenz“. So lassen sich Leistungsprobleme noch einfacher diagnostizieren und beheben. Außerdem können einige Korrekturmaßnahmen für Sie ausgeführt und in einigen Fällen automatisch proaktiv behoben werden.

Die Behandlung von Leistungsproblemen kann von der kombinierten Nutzung intelligenter Features wie Statistik zur Abfrageleistung und Database Advisor erheblich profitieren. Daher unterscheidet sich der Ansatz in der Hinsicht, dass Sie die grundlegenden Details, die Sie bei der Behandlung des vorliegenden Problems unterstützen können, nicht mehr manuell erarbeiten müssen. Diese Arbeit leistet die Plattform für Sie. Ein Beispiel hierfür ist QPI. Mit QPI können Sie Problemen bis auf die Abfrageebene nachgehen und mithilfe historischer Trends herausfinden, wann die Abfrageleistung nachgelassen hat. Database Advisor gibt Empfehlungen, die zur allgemeinen Verbesserung der Gesamtleistung beitragen können, beispielsweise, wenn Indizes fehlen oder gelöscht wurden bzw. bei parametrisierten Abfragen usw.

Bei der Behandlung von Leistungsproblemen muss unbedingt festgestellt werden, ob die Anwendungsleistung lediglich durch die Anwendung oder die zugrunde liegende Datenbank beeinträchtigt wird. Häufig wird das Leistungsproblem durch die Anwendungsschicht verursacht, beispielsweise durch die Architektur oder das Datenzugriffsmuster. Angenommen, Sie verfügen über eine „sehr kommunikative“ Anwendung, die empfindlich auf Netzwerklatenz reagiert. In diesem Fall wird die Anwendung beeinträchtigt, da in einem überlasteten Netzwerk zwischen der Anwendung und dem Server viele kurze Anforderungen übertragen würden. Diese Roundtrips könnten sich schnell summieren. Um in diesem Fall die Leistung zu verbessern, verwenden Sie Batchabfragen. Batches sind sehr hilfreich, da Ihre Anforderungen jetzt in einem Batch verarbeitet werden, wodurch die Roundtriplatenz gesenkt und die Anwendungsleistung verbessert werden.

Wenn Sie außerdem eine Verringerung der Gesamtleistung der Datenbank beobachten, können Sie anhand der dynamischen Verwaltungssichten sys.dm_db_resource_stats und sys.resource_stats die CPU-, E/A- und Speichernutzung nachvollziehen. Die Leistung kann beeinträchtigt sein, da der Datenbank nicht genügend Ressourcen zur Verfügung stehen. Möglicherweise müssen Sie die Computegröße und/oder Dienstebene abhängig von zu- oder abnehmenden Workloadanforderungen ändern.

Umfassende Empfehlungen zur Behebung von Leistungsproblemen finden Sie unter: Optimieren der Datenbank.

Wie kann sichergestellt werden, dass die geeignete Dienstebene und Computegröße verwendet wird?

Die SQL-Datenbank bietet zwei verschiedene Kaufmodelle: das ältere DTU-Modell und das anpassungsfähigere Kaufmodell mit virtuellen Kernen. Die Unterschiede zwischen beiden Modellen finden Sie unter Auf virtuellen Kernen basierende und DTU-basierte Kaufmodelle der Azure SQL-Datenbank im Vergleich.

Zur Gewährleistung der richtigen Computegröße können Sie die Nutzung von Abfragen und Datenbankressourcen in beiden Kaufmodellen überwachen. Weitere Informationen finden Sie unter Überwachung und Leistungsoptimierung. Falls Sie feststellen, dass die Abfragen/Datenbanken ständig ausgelastet sind, sollten Sie den Wechsel zu einer höheren Computegröße in Erwägung ziehen. Wenn Sie feststellen, dass die Ressourcen sogar während Spitzenzeiten nicht ausgelastet sind, erwägen Sie ein Herunterskalieren von der aktuellen Computegröße. Ziehen Sie die Nutzung von Azure Automation in Betracht, um die SQL-Datenbanken nach einem Zeitplan zu skalieren.

Falls Sie ein SaaS-App-Muster oder ein Szenario zur Datenbankkonsolidierung nutzen, wäre zur Kostenoptimierung ein Pool für elastische Datenbanken empfehlenswert. Ein Pool für elastische Datenbanken bietet optimale Voraussetzungen für die Datenbankkonsolidierung und Kostenoptimierung. Weitere Informationen zur Verwaltung mehrerer Datenbanken mit Pools für elastische Datenbanken finden Sie unter Verwalten von Pools und Datenbanken.

Wie oft müssen Integritätsprüfungen für Datenbanken ausgeführt werden?

SQL-Datenbank nutzt intelligente Technologien, mit denen bestimmte Datenbeschädigungen automatisch ohne Datenverluste behandelt werden können. Diese Technologien sind in den Dienst integriert und kommen bei Bedarf zum Einsatz. Ihre Datenbanksicherungen werden im gesamten Dienst regelmäßig getestet, indem sie wiederhergestellt und mit DBCC CHECKDB überprüft werden. Dabei werden Probleme von SQL-Datenbank proaktiv behoben. Mithilfe der automatischen Seitenreparatur werden Seiten repariert, die beschädigt sind oder Probleme mit der Datenintegrität aufweisen. Datenbankseiten werden immer mit der standardmäßigen CHECKSUM-Einstellung auf ihre Integrität überprüft. Die Datenintegrität Ihrer Datenbank wird von SQL-Datenbank proaktiv überwacht und überprüft. Auftretende Probleme werden mit der höchsten Priorität behandelt. Zusätzlich dazu können Sie nach Belieben eigene Integritätsprüfungen ausführen. Weitere Informationen finden Sie im Thema zur Datenintegrität in SQL-Datenbank

Datenverschiebung nach der Migration

Wie werden Daten als BACPAC-Dateien in SQL-Datenbank mithilfe des Azure-Portals exportiert und importiert?

  • Export: Sie können Ihre Datenbank in Azure SQL-Datenbank als BACPAC-Datei aus dem Azure-Portal exportieren

Screenshot der Schaltfläche „Datenbank exportieren“ für eine Azure SQL-Datenbank aus dem Azure-Portal.

  • Import: Sie können Daten im Azure-Portal auch als BACPAC-Datei in Ihre Datenbank in Azure SQL-Datenbank importieren.

Screenshot der Schaltfläche „Datenbank importieren“ für einen Azure SQL-Server aus dem Azure-Portal.

Wie werden Daten zwischen SQL-Datenbank und SQL Server synchronisiert?

Hier gibt mehrere Möglichkeiten:

  • Datensynchronisierung – Dieses Feature unterstützt Sie bei der bidirektionalen Synchronisierung von Daten zwischen mehreren SQL Server-Datenbanken und SQL-Datenbank. Um Daten mit SQL Server-Datenbanken zu synchronisieren, müssen Sie den Synchronisierungs-Agent auf einem lokalen Computer oder einem virtuellen Computer installieren und konfigurieren und den ausgehenden TCP-Port 1433 öffnen.
  • Transaktionsreplikation – Mit der Transaktionsreplikation können Sie Ihre Daten von einer SQL Server-Datenbank mit Azure SQL Datenbank synchronisieren. Dabei stellt die SQL Server-Instanz den Verleger und Azure SQL-Datenbank den Abonnenten dar. Zurzeit wird nur dieses Szenario unterstützt. Weitere Informationen dazu, wie Sie Daten mit minimaler Ausfallzeit von einer SQL Server-Datenbank zu Azure SQL migrieren, finden Sie unter: Verwenden der Transaktionsreplikation

Zugehöriger Inhalt