Beschreiben von Sicherheitsfeatures

Abgeschlossen

Azure Database for MySQL – Flexible Server bietet mehrere Features, die zum Schutz und Schutz Ihrer Daten und Vorgänge konzipiert sind. Im Folgenden lernen Sie die einzelnen Features kennen.

Netzwerk

Azure Database for MySQL – Flexible Server bietet stabile Firewalleinstellungen zum Schutz der Datenbankkonnektivität für den öffentlichen Zugriff sowie für Virtuelle Azure-Netzwerke (VNets). Es gibt drei Einstellungen für die flexible MySQL-Serververbindung: öffentlicher Zugriff, privater Zugriff und ein privater Link. In allen Fällen müssen sich Verbindungen weiterhin mit dem Server authentifizieren.

Der öffentliche Zugriff bietet eine öffentlich auflösende DNS-Adresse, auf die über das Internet zugegriffen werden kann, indem eine Liste zulässiger IP-Adressbereiche verwendet wird. Standardmäßig sind keine IP-Adressen zugelassen. Sie können während oder nach der Erstellung IP-Adressen hinzufügen. Sie können auch den Zugriff von jeder Azure-IP-Adresse (einschließlich anderer Kundenabonnements in anderen Regionen) zulassen.

Beim privaten Zugriff wird ein delegiertes Subnetz zum Hosten flexibler MySQL-Server verwendet und eine DNS-Adresse bereitgestellt, die innerhalb des eigenen VNet oder eines Peer-VNet aufgelöst werden kann. Dadurch wird der Datenbankzugriff nur auf Ihre virtuelle Netzwerkinfrastruktur gesperrt. Sie können Firewallregeln für die Netzwerksicherheitsgruppe (Network Security Group, NSG) einrichten, um den Netzwerkdatenverkehr genauer zu filtern. Sie können den privaten Zugriff verwenden, um eine sichere Verbindung mit einem flexiblen MySQL-Server innerhalb desselben VNet, von einem anderen VNet mithilfe von Peering oder sogar über eine lokale Verbindung über eine ExpressRoute- oder VPN-Verbindung herzustellen.

Private Link stellt einen privaten IP-Adressendpunkt in einem VNet-Subnetz bereit, um eine direkte Verbindung mit dem flexiblen MySQL-Server herzustellen. Azure Private Link bringt im Wesentlichen Azure-Dienste in Ihrem privaten VNet über eine IP-Adresse wie jede andere VNet-Ressource. Sie können mehrere private Endpunkte erstellen, z. B. eine pro Verbindungsanwendung oder Azure PaaS-Ressource. In Kombination mit NSG-Firewallregeln bieten private Links eine differenzierte Kontrolle darüber, welche Dienste auf die Datenbank zugreifen können.

Microsoft Defender für Cloud

Microsoft Defender for Cloud überwacht Ihre Datenbank auf ungewöhnliche und potenziell schädliche Aktivitäten. Defender for Cloud wird als zusätzlicher Plan bereitgestellt, um potenzielle Bedrohungen zu behandeln, ohne die Sicherheitsüberwachung zu erstellen oder zu verwalten. Defender for Cloud verfügt über die Multicloudverfügbarkeit in Azure Database for MySQL – Flexible Server, zusätzlich zu MySQL in AWS Aurora und RDS. Defender for Cloud unterstützt auch PostgreSQL und MariaDB.

Defender for Cloud erkennt Datenbankbedrohungen wie:

  • Brute-Force-Angriffe: ungewöhnlich hohe Anmeldefehler und erfolgreiche Anmeldung nach vielen Fehlern
  • Ungewöhnliche Anmeldemuster: wenn sich ein Benutzer zum ersten Mal in mehr als zwei Monaten anmeldet
  • Ungewöhnliche Anmeldestandorte: wenn sich ein Benutzer aus einer ungewöhnlichen Azure-Datenbank oder einem anderen Cloudanbieter anmeldet oder von einer als verdächtig gekennzeichneten IP-Adresse

Defender for Cloud sendet Erkennungswarnungen an das Azure-Portal und über E-Mail. Warnungen umfassen:

  • Details der verdächtigen Aktivität.
  • Die zugeordneten MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge).
  • Vorschläge zur Untersuchung und Entschärfung des Angriffs.
  • Weitere Optionen zur Untersuchung mit Microsoft Sentinel.

Authentifizierung

Azure Database for MySQL bietet zwei Authentifizierungsmodi: MySQL-Authentifizierung (Benutzername/Kennwort) und Microsoft Entra ID-Authentifizierung. Sie können beide gleichzeitig aktivieren.

Die Microsoft Entra ID-Authentifizierung ermöglicht die identitätsbasierte Authentifizierung auf dem flexiblen MySQL-Server mithilfe von Identitäten, die von Microsoft Entra ID bereitgestellt werden. Dadurch wird die Benutzerverwaltung für die Datenbank und andere Microsoft-Dienste zentralisiert.

Standardmäßig ist ein flexibler MySQL-Server auf die Verwendung der MySQL-Authentifizierung (Benutzername/Kennwort) festgelegt. Sie können diese Einstellung ändern, um die Microsoft Entra ID-Authentifizierung nur (keine Datenbankbenutzer) zu verwenden oder verwaltete Identitäten mit MySQL-Authentifizierung zu kombinieren.

Wenn Sie die Microsoft Entra ID-Authentifizierung verwenden, gibt es zwei Administratorkonten: den ursprünglichen MySQL-Administrator und den Microsoft Entra ID-Administrator. Der Microsoft Entra ID-Administrator kann entweder ein Benutzer oder eine Benutzergruppe sein. Wenn der Administrator eine Gruppe ist, kann jedes Mitglied der Gruppe die Microsoft Entra ID-Authentifizierung verwalten. Administratorgruppen sind einfacher zu verwalten, da sie die Benutzerverwaltung in der Microsoft Entra-ID zentralisiert, anstatt MySQL-Benutzer oder Berechtigungen direkt aktualisieren zu müssen. Sie können nur einen Microsoft Entra ID-Administrator konfigurieren, unabhängig davon, ob es sich um einen einzelnen Benutzer oder eine einzelne Benutzergruppe handelt.

Das folgende Diagramm zeigt die beiden Modi zum Verwalten der Authentifizierung.

Diagramm, das zeigt, wie MySQL-Administratoren und Microsoft Entra-Administratoren für MySQL Benutzer erstellen und Azure Database for MySQL – Flexible Server verwalten können.

Wenn Benutzer oder Anwendungen versuchen, eine Verbindung mit einem flexiblen MySQL-Server mithilfe einer Microsoft Entra-Identität herzustellen, wird ein Token ausgegeben, um die Anmeldung zuzulassen. Die Identität wird einem Datenbankbenutzer über seine eindeutige Microsoft Entra-Benutzer-ID und nicht über seinen Namen oder andere Attribute zugeordnet.

Datenverschlüsselung

MySQL flexible Server verschlüsseln Daten während der Übertragung. Standardmäßig müssen Server eine Verbindung mit TLS 1.2 (Transport Layer Security) herstellen und unverschlüsselte Verbindungen oder Verbindungen mit den veralteten TLS 1.0- und 1.1-Protokollen verweigern. Sie können verschlüsselte Verbindungen deaktivieren (möglicherweise unterstützt eine ältere Anwendung keine Verschlüsselung). Versionen vor 1.2 zulassen oder TLS 1.3 verwenden. Dies ist die empfohlene Einstellung für die Entwicklung neuer Anwendungen.

Standardmäßig verschlüsselt Azure Database for MySQL – Flexible Server ruhende Daten (einschließlich Sicherungs- und temporäre Dateien, die bei der Ausführung von Abfragen erstellt wurden) mithilfe eines symmetrischen AES 256-Bit-Datenverschlüsselungsschlüssels (DEK). Mit vom Kunden verwalteten Schlüsseln (CMK) können Sie „Bring your own key“ (BYOK) nutzen, um eine weitere Verschlüsselungsebene hinzuzufügen, indem Sie den DEK des Diensts verschlüsseln.

BYOK bietet Ihnen die vollständige Kontrolle über die Datenverschlüsselung und den wichtigsten Lebenszyklus: Erstellung, Upload, Rotation und Löschung. Durch die Verwaltung des Schlüssellebenszyklus können Sie die Schlüsselrotation mit Unternehmensrichtlinien abstimmen und die Trennung von Sicherheitsteam-, DBA- und Systemadministrator-Verantwortlichkeiten ermöglichen.

Zum Aktivieren von CMK muss eine Datenbank mit einer benutzerseitig zugewiesenen verwalteten Identität (UMI) verknüpft und dann der Schlüssel angegeben werden, der in Azure Key Vault verwendet werden soll. Wenn Sie eine Kopie des Servers erstellen, wird die Kopie verschlüsselt, und Sie können auch verwaltete Identitäten und Schlüssel zu vorhandenen Replikaten hinzufügen.