Szenario 1 – Lösung: Entwerfen einer Architektur für globalen und sicheren Zugriff

  • 10 Minuten

In der vorherigen Lerneinheit haben Sie sich ein Szenario zu einem globalen Content Delivery Network angesehen. In dieser Lerneinheit überprüfen Sie eine mögliche Lösung für dieses Szenario und finden Informationen zu einigen 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

Die erste zu treffende Entscheidung ist die für eine Bereitstellungsoption für Azure SQL. SQL Server könnte zwar auf einer Azure-VM verwendet werden, ein PaaS-Angebot (Platform-as-a-Service) wäre jedoch eine bessere Lösung mit weniger Verwaltungsaufwand.

Der Kunde nutzt jedoch Common Language Runtime (CLR). Dabei handelt es sich um ein instanzspezifisches Feature. Azure SQL Managed Instance ist die einzige PaaS-Bereitstellungsoption, die instanzspezifische Features wie CLR, Service Broker und Datenbank-E-Mail unterstützt. Aus diesem Grund wäre es dem Kunden dank Azure SQL Managed Instance möglich, zu einem PaaS-Angebot zu wechseln, ohne seine CLR-Anwendungen in einer mit Azure SQL-Datenbank kompatiblen Lösung (wie Aufträge für die elastische Datenbank) neu schreiben zu müssen.

Die nächste Entscheidung betrifft die Dienstebene. Der Kunde möchte Lese- und Schreibworkloads isolieren. Die Dienstebene „Unternehmenskritisch“ ist dafür die einfachste Möglichkeit. Bei der Dienstebene „Unternehmenskritisch“ wird im Hintergrund eine Always On-Verfügbarkeitsgruppe ausgeführt. Eines dieser sekundären Replikate kann für schreibgeschützte Workloads verwendet werden.

Die Dienstebene „Unternehmenskritisch“ ist dabei aber nur eine Hälfte der Konfiguration, mit der Lese- und Schreibworkloads voneinander getrennt werden können. Das Szenario beinhaltet, dass der Kunde bei gleichzeitiger Ausführung mehrerer Abfragen die Skalierung für mehrere Regionen umsetzen können muss, dabei jedoch die Leseworkloads von Schreibworkloads abgrenzt.

Die zwei Optionen, die diese Anforderung möglicherweise erfüllen können, sind Georeplikation und Autofailover-Gruppen. Georeplikation wird in Azure SQL Managed Instance derzeit jedoch nicht unterstützt. Das Verwenden einer Autofailover-Gruppe ist deshalb die einzige mögliche Option für dieses Szenario, um globale Lesevorgänge zu ermöglichen.

Da beim Kunden Autofailover-Gruppen verwendet werden, hängt die Tatsache, ob die Dienstebene „Unternehmenskritisch“ benötigt wird oder nicht, davon ab, wie viele schreibgeschützte Endpunkte von der Analyseworkload erfordert werden. Bei einer Autofailover-Gruppe der Dienstebene „Unternehmenskritisch“ stünden drei lesbare Endpunkte zur Verfügung:

  • Ein sekundäres Replikat aus der Verfügbarkeitsgruppe der primären Region
  • Das sekundäre Replikat der Failovergruppe (d. h. das primäre Replikat der Datenbank in der sekundären Region)
  • Das sekundäre Replikat aus der Verfügbarkeitsgruppe der sekundären Region

Wenn für die Analyseworkloads keines dieser Lesereplikate erforderlich ist, wäre die Verwendung der Dienstebene „Universell“ vermutlich die kostengünstigere Lösung.

Auswählen der geeignetsten Authentifizierungsmethoden

Der andere Bestandteil des Szenarios beinhaltete es, die für die Anwendung/Person jeweils beste Möglichkeit der Verbindung zur Lösung zu ermitteln. Dabei musste die Anforderung berücksichtigt werden, die sichersten möglichen Technologien zu erstellen und zu nutzen. Wenn Sie sich das Szenario im Detail ansehen, fällt auf, dass es vier eigenständige Clients gibt, die auf die Azure SQL Managed Instance-Instanz zugreifen müssen:

  • Auf einer Azure-VM ausgeführte Anwendung
  • Auf einem in die Domäne eingebundenen Nicht-Azure-Computer ausgeführte Anwendung
  • DBAs oder andere Benutzer von SQL-Administratortools (SQL Server Management Studio, Azure Data Studio, PowerShell) auf einem Nicht-Azure-Computer, der nicht in die Domäne eingebunden ist
  • Ältere Anwendungen, die auf einem Nicht-Azure-Computer ausgeführt werden, auf dem Sie den Treiber oder die Verbindungszeichenfolge nicht ändern können

Sehen Sie sich diese Clients nun in Bezug darauf an, wie Sie die beste Authentifizierungsmethode identifizieren können. Außerdem finden Sie im Folgenden weitere Überlegungen und Einschränkungen.

Auf einer Azure-VM ausgeführte Anwendung

Verwaltete Identitäten für Azure-Ressourcen sind im Allgemeinen die empfohlene Form einer Authentifizierung ohne Kennwort für Anwendungen, die auf Azure-VMs ausgeführt werden.

Auf einem in die Domäne eingebundenen Nicht-Azure-Computer ausgeführte Anwendung

Für Nicht-Azure-Computer ist die Verwendung verwalteter Identitäten keine Option. Die integrierte Authentifizierung über Microsoft Entra ID ist die empfohlene Authentifizierungsmethode für Apps, die auf einer Domäne angehörigen Computern außerhalb von Azure ausgeführt werden, sofern die Domäne mit Microsoft Entra ID verknüpft wurde.

Wenn der Nicht-Azure-Computer nicht in die Domäne eingebunden ist, können Sie folgende Aktionen ausführen:

  1. Erstellen einer Anwendungsidentität für Ihre Anwendung in Microsoft Entra ID
  2. Zuordnen eines Zertifikats zur Anwendungsidentität
  3. Ändern der Anwendung, sodass ein Token für Azure SQL-Datenbank abgerufen werden kann, indem eine Client-ID angegeben und ein Zertifikat bereitgestellt wird

Obwohl das Zertifikat einen privaten Schlüssel enthalten muss und auf dem Computer, der Ihre Anwendung hostet, bereitgestellt werden muss, vermeiden Sie dadurch zumindest das Hartcodieren eines Anwendungsgeheimnisses im Anwendungscode oder der Konfiguration. (Sie müssen die App mit dem Zertifikatfingerabdruck konfigurieren.)

DBAs oder andere Benutzer von SQL-Administratortools auf einem nicht in die Domäne eingebundenen Nicht-Azure-Computer

Für Benutzer außerhalb von Azure sollte wenn möglich die Verwendung von Kennwörtern vermieden werden. Die Verwendung von Kennwörtern können Sie ausschließen, indem Sie mit SQL-Tools und der in Microsoft Entra integrierten Authentifizierung arbeiten. Die Tools müssen jedoch auf einem in die Domäne eingebundenen Computer ausgeführt werden, und die Domäne muss einen Verbund mit Microsoft Entra bilden. Dies ist in diesem Szenario nicht der Fall.

Da die Umgebung die oben genannten Voraussetzungen für die integrierte Authentifizierung nicht erfüllt, sollten Sie die interaktive Authentifizierung in Microsoft Entra mit mehrstufiger Authentifizierung verwenden. Diese Lösung wird von den meisten SQL-Tools unterstützt.

Ältere Anwendungen, die auf einem Nicht-Azure-Computer ausgeführt werden, auf dem Sie den Treiber oder die Verbindungszeichenfolge nicht ändern können

In Szenarios, in denen der Treiber oder die Verbindungszeichenfolge nicht geändert werden kann, gibt es derzeit keine Möglichkeit, die Verwendung von Kennwörtern auszuschließen. Bei diesen älteren Anwendungen muss weiterhin die SQL-Authentifizierung verwendet werden. Sie können jedoch die Einschränkungen im Detail betrachten, um zu ermitteln, wie diese behoben werden können, um einen sichereren und geschützten Ansatz für die Authentifizierung von Anwendungen zu implementieren.