Azure SQL-Datenbank Sicherheitsfunktionen

Azure SQL-Datenbank bietet einen relationalen Datenbankdienst in Azure. Um Kundendaten zu schützen und starke Sicherheitsfunktionen bereitzustellen, die Sie von einem relationalen Datenbankdienst erwarten, verfügt SQL Database über eigene Sicherheitsfunktionen. Diese Fähigkeiten bauen auf den Kontrollen auf, die Azure bereitstellt.

Sicherheitsfunktionen

Verwendung des TDS-Protokolls

Azure SQL-Datenbank unterstützt nur das Tabular Data Stream (TDS)-Protokoll, das erfordert, dass die Datenbank nur über den Standardport von TCP/1433 zugänglich ist.

Azure SQL-Datenbank Firewall

Um Kundendaten zu schützen, enthält die Azure SQL-Datenbank eine Firewall-Funktionalität, die standardmäßig jeglichen Zugriff auf die SQL-Datenbank verhindert.

Azure SQL-Datenbank firewall

Die Gateway-Firewall kann Adressen begrenzen, was Ihnen eine detaillierte Kontrolle zur Festlegung akzeptabler IP-Adressbereiche gibt. Die Firewall gewährt den Zugriff basierend auf der ursprünglichen IP-Adresse jeder Anfrage.

Sie können die Firewall über ein Management-Portal konfigurieren oder programmatisch über die Azure SQL-Datenbank Management REST API. Die Gateway-Firewall der Azure SQL-Datenbank verhindert standardmäßig jeglichen TDS-Zugriff des Kunden auf die Azure SQL-Datenbank. Sie müssen den Zugriff über Zugriffskontrolllisten (ACLs) konfigurieren, um Verbindungen zur Azure SQL-Datenbank nach Quell- und Ziel-Internetadressen, Protokollen und Portnummern zu ermöglichen.

DoSGuard

DosGuard, ein SQL-Datenbank-Gateway-Dienst, reduziert Denial-of-Service-(DoS)-Angriffe. DoSGuard verfolgt aktiv fehlgeschlagene Anmeldungen von IP-Adressen. Wenn innerhalb eines Zeitraums mehrere fehlgeschlagene Anmeldeversuche von einer IP-Adresse erfolgen, blockiert DoSGuard die IP-Adresse für einen vordefinierten Zeitraum daran, auf Ressourcen im Dienst zuzugreifen.

Das Azure SQL-Datenbank-Gateway führt ebenfalls folgende Aktionen aus:

  • Handelt die Fähigkeiten des sicheren Kanals aus, um beim Verbinden mit den Datenbankservern TDS-verschlüsselte Verbindungen zu ermöglichen, die nach FIPS 140-2 validiert sind.
  • Überprüft zustandsbehaftete TDS-Pakete, während es Verbindungen von Clients entgegennimmt. Das Gateway validiert die Verbindungsinformationen und leitet die TDS-Pakete basierend auf dem im Verbindungszeichenfolge angegebenen Datenbanknamen an den entsprechenden physischen Server weiter

Das übergeordnete Prinzip der Netzwerksicherheit von Azure SQL-Datenbank besteht darin, nur die Verbindungen und Kommunikation zuzulassen, die der Dienst zum Betrieb benötigt. Azure blockiert standardmäßig alle anderen Ports, Protokolle und Verbindungen. Azure verwendet virtuelle lokale Netzwerke (VLANs) und ACLs, um die Netzwerkkommunikation nach Quell- und Zielnetzwerken, Protokollen und Portnummern zu beschränken.

Genehmigte Mechanismen zur Implementierung netzwerkbasierter ACLs umfassen ACLs auf Routern und Lastverteilungssystemen. Azure-Netzwerke, die Gast-VM-Firewall und kundenkonfigurierte Azure SQL-Datenbank-Gateway-Firewall-Regeln verwalten diese Mechanismen.

Datentrennung und Kundenisolation

Azure strukturiert das Produktionsnetzwerk so, dass öffentlich zugängliche Systemkomponenten von internen Ressourcen getrennt werden. Physische und logische Grenzen bestehen zwischen Webservern, die Zugriff auf das öffentlich zugängliche Azure-Portal bieten, und der zugrundeliegenden virtuellen Azure-Infrastruktur, in der sich Kundenanwendungsinstanzen und Kundendaten befinden.

Azure verwaltet alle öffentlich zugänglichen Informationen innerhalb des Azure-Produktionsnetzwerks. Das Produktionsnetzwerk ist:

  • Vorbehaltlich von Zwei-Faktor-Authentifizierung und Grenzschutzmechanismen
  • Verwendet die im vorherigen Abschnitt beschriebenen Firewall- und Sicherheitsfunktionen
  • Verwendet Datenisolationsfunktionen, die in den nächsten Abschnitten erwähnt sind

Unautorisierte Systeme und Isolierung der FC

Da der Fabric Controller (FC) der zentrale Orchestrator des Azure-Fabrics ist, sind bedeutende Kontrollen vorhanden, um Bedrohungen zu mindern, insbesondere durch potenziell kompromittierte FAs innerhalb von Kundenanwendungen. Die FC erkennt keine Hardware, deren Geräteinformationen (zum Beispiel MAC-Adresse) nicht im FC vorinstalliert sind. Die DHCP-Server im FC führen konfigurierte Listen von MAC-Adressen der Knoten, die sie bereit sind zu booten. Selbst wenn unautorisierte Systeme eine Verbindung herstellen, nimmt die FC sie nicht in das Fabric-Inventar auf und verbindet sie nicht mit einem System innerhalb des Fabric-Inventars bzw. autorisiert sie nicht zur Kommunikation damit. Diese Einschränkung verringert das Risiko, dass unautorisierte Systeme mit dem FC kommunizieren und Zugang zu VLAN und Azure erhalten.

VLAN-Isolation

Das Azure-Produktionsnetzwerk ist logisch in drei primäre VLANs unterteilt:

  • Das Haupt-VLAN: Verbindet nicht vertrauenswürdige Kundenknoten.
  • Das FC-VLAN: Enthält vertrauenswürdige FCs und unterstützende Systeme.
  • Das Geräte-VLAN: Enthält vertrauenswürdige Netzwerk- und andere Infrastrukturgeräte.

Paketfilterung

Der IPFilter und die Software-Firewalls auf dem Root-OS und Gast-OS der Knoten erzwingen Konnektivitätsbeschränkungen und verhindern unbefugten Datenverkehr zwischen VMs.

Hypervisor, Root-Betriebssystem und Gast-VMs

Der Hypervisor und das Root-Betriebssystem verwalten die Isolierung des Root-Betriebssystems von den Gast-VMs und der Gast-VMs voneinander.

Arten von Regeln auf Firewalls

Azure definiert eine Regel als:

{Quell-IP, Quell-Port, Ziel-IP, Ziel-Port, Zielprotokoll, Ein/Aus, Mit Status/Ohne Status, Zeitüberschreitung für statusbehafteten Datenfluss}.

Regeln erlauben synchrone Idle-Character (SYN)-Pakete nur dann ein- oder aus, wenn eine der Regeln dies erlaubt. Für TCP verwendet Azure zustandslose Regeln, wobei das Prinzip nur Nicht-SYN-Pakete in oder aus der VM erlaubt. Die Sicherheitsprämisse ist, dass jeder Host-Stack widerstandsfähig ist, einen Nicht-SYN zu ignorieren, wenn er zuvor kein SYN-Paket gesehen hat. Das TCP-Protokoll selbst ist zustandsbehaftet und ergibt in Kombination mit der zustandslosen SYN-basierten Regel insgesamt das Verhalten einer zustandsbehafteten Implementierung.

Für User Datagram Protocol (UDP) verwendet Azure eine zustandsbehaftete Regel. Jedes Mal, wenn ein UDP-Paket mit einer Regel übereinstimmt, erzeugt Azure einen Reverse Flow in die entgegengesetzte Richtung. Dieser Fluss hat eine eingebaute Auszeit.

Du bist dafür verantwortlich, deine eigenen Firewalls zusätzlich zu den Firewalls einzurichten, die Azure bereitstellt. Du kannst die Regeln für eingehenden und ausgehenden Verkehr festlegen.

Produktionskonfigurationsmanagement

Die jeweiligen Betriebsteams in Azure und Azure SQL-Datenbank pflegen standardisierte sichere Konfigurationen. Ein zentrales Tracking-System dokumentiert und verfolgt alle Konfigurationsänderungen der Produktionssysteme. Das zentrale Tracking-System verfolgt Software- und Hardwareänderungen. Ein ACL-Managementdienst verfolgt Netzwerkänderungen, die sich auf ACL beziehen.

Teams entwickeln und testen alle Konfigurationsänderungen für Azure in der Staging-Umgebung und bereiten sie dann in der Produktionsumgebung bereit. Teams überprüfen Software-Builds im Rahmen des Tests. Teams überprüfen Sicherheits- und Datenschutzprüfungen als Teil der Kriterien für die Eintrittscheckliste. Das jeweilige Deployment-Team spielt Änderungen in festgelegten Intervallen ein. Das Personal des jeweiligen Einsatzteams überprüft und genehmigt Freigaben, bevor es in die Produktion geht.

Teams überwachen Veränderungen auf Erfolg. In einem Ausfallszenario setzen die Teams die Änderung in den vorherigen Zustand zurück oder setzen mit Zustimmung des zugewiesenen Personals einen Hotfix ein, um den Fehler zu beheben. Source Depot, Git, TFS, Master Data Services (MDS), Runner, Azure-Sicherheitsüberwachung, der FC und die WinFabric-Plattform verwalten, wenden und verifizieren zentral die Konfigurationseinstellungen in der virtuellen Azure-Umgebung an.

Ebenso bewerten etablierte Validierungsschritte Hardware- und Netzwerkänderungen auf die Einhaltung der Build-Anforderungen. Ein koordiniertes Änderungsbeirat (CAB) der jeweiligen Gruppen im gesamten Stack überprüft und autorisiert die Veröffentlichungen.

Nächste Schritte

Um mehr darüber zu erfahren, was Microsoft zur Sicherung der Azure-Infrastruktur tut, siehe:

  • Last updated on