Szenario 2 – Lösung: Unternehmenskritische Anwendungen
In der vorherigen Lerneinheit haben Sie sich ein Szenario angesehen, bei dem es um Hochverfügbarkeit für ein System zum Absetzen von Notrufen ging. In dieser Lerneinheit überprüfen Sie eine mögliche Lösung für dieses Szenario und finden Informationen zu einigen weiteren zu beachtenden Punkten.
Bei der Überprüfung sollten Sie die bereitgestellte Lösung mit der von Ihnen in der vorherigen Lerneinheit entwickelten Lösung vergleichen. Oft gibt es mehr als eine richtige Lösung für ein Problem, immer sind jedoch Kompromisse nötig. Welche Punkte Ihrer Lösung unterscheiden sich vom Lösungsvorschlag? Gibt es Bereiche Ihrer Lösung, die Sie überdenken möchten? Gibt es Bereiche in der bereitgestellten Lösung, die in Ihrer Lösung noch besser aufgegriffen wurden?
Bereitstellungsoption und -konfiguration
Bei einem Szenario muss häufig zuerst einmal die am besten geeignete Azure SQL-Bereitstellungsoption gefunden werden. Allein schon für die Vereinbarung zum Servicelevel (Service Level Agreement, SLA) gilt die Anforderung von 99,995 Prozent, was nur mit Azure SQL-Datenbank erfüllt werden kann. Wenn Sie an dieser SLA interessiert sind, müssen Sie die Dienstebene „Unternehmenskritisch“ bereitstellen und die Verwendung von Verfügbarkeitszonen aktivieren.
Weitere Entscheidungen betreffen die Aktivierung von Georedundanz und die Verwaltung von Hochverfügbarkeit in Katastrophenfällen. Zwar sind sowohl Georeplikation als auch Autofailover-Gruppen Optionen für dieses Szenario, Autofailover-Gruppen ermöglichen es dem Kunden jedoch, bei Bedarf ein Failover durchzuführen, ohne Verbindungszeichenfolgen zu ändern. Dieses Setup kann möglicherweise unterstützend dafür sein, die Downtime für das Aktualisieren der Verbindungszeichenfolgen der Anwendungen zu reduzieren, da so kein Update erforderlich ist. Sie können auch Überwachungsabfragen konfigurieren, um den Status zu überprüfen. Auf diese Weise können Sie im Falle eines Fehlers ein Failover erzwingen.
In dieser Konfiguration sollten Sie sich auch Gedanken über die Rolle der Colocation machen. Zur Aufrechterhaltung der Hochverfügbarkeit muss sich Ihre Anwendung nächstmöglich an Ihrer Datenbank befinden, auf jeden Fall aber in derselben Region. Sie sollten dafür sorgen, dass Ihre Anwendung in beiden Regionen der Autofailover-Gruppe bereitgestellt wird, damit eine redundante Kopie der Anwendung (z. B. eine Web-App) besteht. Wenn ein Failover durchgeführt wird, können Sie Azure Traffic Manager verwenden, um den Datenverkehr zur Anwendung in der sekundären Region weiterzuleiten.
Datenbankadministratoren und vertrauliche Daten
Den Koordinatoren für das System zur Absetzung eines Notrufs ist es besonders wichtig, vertrauliche Daten zu schützen, beispielsweise Gesundheitsdaten und andere personenbezogene Informationen. Datenbankadministratoren sollen aber weiterhin ihre Aufgaben erledigen können.
Es gibt mehrere Azure SQL-Technologien, mit denen Sie sicherstellen können, dass DBAs in bestimmten Spalten gespeicherte vertrauliche Daten nicht anzeigen können und dass jeglicher Zugriff auf Tabellen mit vertraulichen Daten überwacht werden muss. Die Verwendung des SQL-Audits gilt als Best Practice für die Überwachung des Zugriffs. DBAs können die Daten jedoch weiterhin sehen. Eine Klassifizierung der vertraulichen Daten mit der Datenklassifizierung ist hier eine Möglichkeit, da die vertraulichen Daten Bezeichnungen erhalten und Sie sie so mithilfe des SQL-Audits überwachen können. Mit diesen Implementierungen können DBAs die vertraulichen Daten jedoch immer noch sehen. Sie können die dynamische Datenmaskierung verwenden, um vertrauliche Daten zu maskieren. Es ist jedoch nicht möglich, einen Datenbankbesitzer (db_owner) nur über Berechtigungen davon abzuhalten, sich die Daten anzusehen.
Wenn sich in einer Datenbank hochgradig vertrauliche Daten befinden, können Sie Always Encrypted verwenden, um selbst Datenbankbesitzer (db_owner) daran zu hindern, die Daten anzuzeigen. Sie können die Always Encrypted-Schlüssel mit getrennten Rollen verwalten, sodass der Sicherheitsadministrator keinen Zugriff auf die Datenbank hat, und der DBA hat keinen Zugriff auf die physischen Schlüssel in Klartext. Mit dieser Strategie in Kombination mit der Überwachung durch das SQL-Audit können Sie vertrauliche Daten überwachen, maskieren und den Zugriff überwachen. Dies ist sogar möglich für DBAs mit Berechtigungen eines Datenbankbesitzers (db_owner).
Vertrauliche Daten müssen für DBAs zwar maskiert werden, sie müssen jedoch weiterhin in der Lage sein, Leistungsprobleme über das Azure-Portal und SQL Server Management Studio oder Azure Data Studio zu beheben. Außerdem müssen sie in der Lage sein, neue Benutzer für eigenständige Datenbanken zu erstellen, die Microsoft Entra-Prinzipalen zugeordnet sein müssen.
Eine Lösung besteht darin, eine Microsoft Entra-Gruppe mit dem Namen „SQL-DBA“ für die DBAs der jeweiligen Instanz zu erstellen. Anschließend weisen Sie die Gruppe der Azure RBAC-Rolle (Role-Based Access Control, rollenbasierte Zugriffssteuerung) eines Mitwirkenden in SQL Server zu. Abschließend können Sie die Gruppe als Microsoft Entra-Administrator für den logischen Server festlegen.