In diesem Artikel wird beschrieben, wie Sie Ihre eigenen Schlüssel für die transparente Datenverschlüsselung (Transparent Data Encryption, TDE) für verwaltete SQL-Instanzen in einer regionsübergreifenden Autofailover-Gruppe mithilfe von Azure Key Vault verwalten können.
Aufbau
Laden Sie eine Visio-Datei dieser Architektur herunter.
Für eine höhere Redundanz der TDE-Schlüssel ist Azure SQL Managed Instance so konfiguriert, dass der Schlüsseltresor in seiner eigenen Region als primärer Schlüsseltresor und der Schlüsseltresor in der Remoteregion als sekundärer Schlüsseltresor verwendet wird.
Die sekundäre Schlüsseltresorinstanz verfügt in einer Remoteregion über einen privaten Endpunkt in derselben Region wie die verwaltete SQL-Instanz. Bei einer verwalteten SQL-Instanz befinden sich Anforderungen an primäre und sekundäre Schlüsseltresore also logisch innerhalb desselben virtuellen Netzwerks und derselben Region. Dieser Entwurf ermöglicht einfachere Firewall- oder Netzwerksicherheitsgruppen-Regeln. Viele Organisationen verwenden einen privaten Endpunkt, anstatt auf den öffentlichen Endpunkt zuzugreifen. Es wird empfohlen, einen privaten Endpunkt zu verwenden.
Datenfluss
Alle 10 Minuten überprüft SQL Managed Instance, ob der Zugriff auf den TDE-Wrapper in dem Schlüsseltresor möglich ist, der als primär definiert ist.
Wenn der primäre Schlüsseltresor von SQL Managed Instance nicht mehr verfügbar ist, überprüft diese Instanz den als sekundär festgelegten Schlüsseltresor. Wenn dieser Schlüsseltresor ebenfalls nicht verfügbar ist, kennzeichnet SQL Managed Instance die Datenbanken mit „Kein Zugriff“.
Komponenten
- Key Vault ist ein Clouddienst, mit dem Sie mit erhöhter Sicherheit Geheimnisse speichern und darauf zugreifen können. In dieser Architektur wird er zum Speichern von Schlüsseln verwendet, die von TDE verwendet werden. Sie können ihn auch zum Erstellen von Schlüsseln verwenden.
- SQL Managed Instance ist eine verwaltete Instanz in Azure, die auf der neuesten stabilen Version von SQL Server basiert. In dieser Architektur wird der Schlüsselverwaltungsprozess auf Daten angewendet, die in SQL Managed Instance gespeichert sind.
- Mit Azure Private Link können Sie über einen privaten Endpunkt in Ihrem virtuellen Netzwerk auf Azure-PaaS-Dienste sowie auf in Azure gehostete Dienste zugreifen.
Alternativen
Anstatt kundenseitig verwaltete TDE-Schlüssel zu verwenden, können Sie dienstseitig verwaltete TDE-Schlüssel verwenden. Wenn Sie dienstseitig verwaltete Schlüssel verwenden, übernimmt Microsoft das Sichern und Rotieren der Schlüssel. Der gesamte Prozess wird Ihnen abgenommen.
Eine Alternative zu Schlüsseltresoren in zwei Regionen besteht in nur einem Schlüsseltresor in einer einzigen Region. SQL Managed Instance kann auf Schlüssel aus einem Tresor in einer anderen Region zugreifen. Sie können weiterhin einen privaten Endpunkt verwenden. Der Datenverkehr zu Key Vault ist niedrig und selten, sodass keine Latenz erkennbar ist. SQL Managed Instance fragt den Tresor nur ab, um festzustellen, ob der Schlüssel vorhanden ist. Das Material wird nicht kopiert.
Szenariodetails
Wenn Sie kundenseitig verwaltete Schlüssel (Customer-Managed Keys, CMK) verwenden (wird auch als Bring Your Own Key (BYOK) bezeichnet), sind Sie für die Sicherheit, Verfügbarkeit und optionale Rotation der Schlüssel verantwortlich. Diese Verantwortlichkeiten sind von entscheidender Bedeutung, da bei einem verloren gegangenen Schlüssel auch die Datenbanken und Sicherungen dauerhaft verloren gehen. Dieser Artikel enthält eine Beschreibung des Schlüsselverwaltungsprozesses und bietet Optionen, damit Sie über die Informationen verfügen, die Sie benötigen, um eine fundierte Entscheidung über den besten Prozess für Ihr Unternehmen zu treffen.
Mögliche Anwendungsfälle
Viele Organisationen verfügen über Richtlinien, die es erforderlich machen, dass Zertifikate oder Verschlüsselungsschlüssel intern erstellt und verwaltet werden. Wenn Ihre Organisation über eine ähnliche Richtlinie verfügt, gilt diese Architektur möglicherweise für Sie. Wenn für Ihre Kunden eine interne Verwaltung dieser Elemente erforderlich ist, gilt die Architektur möglicherweise ebenfalls für Sie. Wenn keine dieser Situationen zutrifft, sollten Sie die Verwendung von systemseitig verwalteten Schlüsseln in Erwägung ziehen.
Überlegungen
Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.
Allgemeine Empfehlungen
Informationen hierzu finden Sie in diesen Artikeln:
- Empfehlungen zum Konfigurieren der kundenseitig verwalteten TDE
- Empfehlungen zum Konfigurieren der TDE-Schutzvorrichtung
Schlüsselverwaltung
Die Methode der Schlüsselrotation unterscheidet sich abhängig davon, was Sie zum Erstellen Ihrer asymmetrischen TDE-Schlüssel verwenden. Wenn Sie Ihren eigenen TDE-Wrapperschlüssel mitbringen, müssen Sie entscheiden, wie Sie diesen Schlüssel erstellen. Die Optionen sind wie folgt:
Verwenden Sie Key Vault, um die Schlüssel zu erstellen. Mit dieser Option wird sichergestellt, dass das Material für den privaten Schlüssel Key Vault niemals verlässt und nicht von Menschen oder Systemen gesehen werden kann. Die privaten Schlüssel sind nicht exportierbar, können aber in einem anderen Schlüsseltresor gesichert und wiederhergestellt werden. Dieser Punkt ist wichtig. Damit dasselbe Schlüsselmaterial in mehreren Schlüsseltresoren vorhanden ist, wie für diesen Entwurf erforderlich, müssen Sie das Feature „Sichern und Wiederherstellen“ verwenden. Für diese Option gelten mehrere Einschränkungen. Beide Schlüsseltresore müssen sich in derselben Azure-Geografie und in demselben Azure-Abonnement befinden. Andernfalls wird die Wiederherstellung nicht funktionieren. Die einzige Möglichkeit, diese Einschränkung zu umgehen, besteht darin, die Schlüsseltresore in separaten Abonnements zu behalten und ein Abonnement in eine andere Region zu verschieben.
Generieren Sie die asymmetrischen Schlüssel offline, indem Sie ein Hilfsprogramm wie OpenSSL verwenden, und importieren Sie die Schlüssel dann in Key Vault. Wenn Sie einen Schlüssel in Key Vault importieren, können Sie ihn als exportierbar markieren. In diesem Fall können Sie die Schlüssel entweder wegwerfen, nachdem Sie sie in Key Vault importiert haben, oder Sie können sie an einem anderen Ort speichern, z. B. lokal oder in einem anderen Schlüsseltresor. Diese Option bietet Ihnen die größte Flexibilität. Sie kann jedoch die am wenigsten sichere Option sein, wenn Sie nicht ordnungsgemäß sicherstellen, dass die Schlüssel nicht in die falschen Hände gelangen. Das System, das die Schlüssel generiert, und die Methode zum Ablegen der Schlüssel in Key Vault werden nicht von Azure gesteuert. Sie können diesen Prozess mithilfe von Azure DevOps, Azure Automation oder einem anderen Orchestrierungstool automatisieren.
Verwenden Sie ein unterstütztes lokales Hardwaresicherheitsmodul (HSM), um Ihre Schlüssel zu generieren. Mithilfe eines unterstützten HSM können Sie Schlüssel mit verbesserter Sicherheit in Key Vault importieren. Die weiter oben beschriebene Einschränkung hinsichtlich derselben Geografie gilt nicht, wenn Sie ein HSM verwenden. Diese Option bietet ein hohes Maß an Sicherheit für Ihre Schlüssel, da sich das Schlüsselmaterial an drei separaten Stellen befindet (zwei Schlüsseltresore in Azure und lokal). Diese Option bietet zudem dasselbe Maß an Flexibilität, wenn Sie ein unterstütztes HSM verwenden.
Verfügbarkeit
Wenn Sie Ihrer Architektur Key Vault hinzufügen, wird dies zu einer wichtigen Komponente. Auf mindestens einen der Schlüsseltresore im Entwurf muss zugegriffen werden können. Darüber hinaus muss auf die Schlüssel zugegriffen werden können, die für TDE erforderlich sind. Azure Monitor Insights bietet eine umfassende Überwachung von Key Vault. Weitere Informationen finden Sie unter Überwachen Ihres Schlüsseltresordiensts.
Optimaler Betrieb
Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.
Wenn Sie von dienstseitig verwalteten Schlüsseln zu kundenseitig verwalteten Schlüsseln wechseln, lauten Ihre Vorgänge wie folgt:
- Generieren von Schlüsseln oder Importieren von Schlüsseln in Key Vault
- Rotieren von Schlüsseln
- Sichern und Wiederherstellen von Schlüsseln
- Überwachen der kundenseitig verwalteten TDE
DevOps
Sie können Azure Pipelines in Azure DevOps verwenden, um den Schlüsselrotationsprozess zu automatisieren.
Effiziente Leistung
Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.
Die Leistung der Autofailover-Gruppen von SQL Managed Instance verbessert sich erheblich, wenn Sie Regionspaare verwenden.
SQL Managed Instance überprüft nur, ob der Schlüssel vorhanden ist, und führt diese Überprüfung nur alle 10 Minuten durch. Daher erfordert SQL Managed Instance keine Regionsaffinität mit Key Vault. Der Speicherort Ihrer TDE-Schlüssel hat keine Auswirkungen auf die Leistung.
Skalierbarkeit
Bei der Verwaltung Ihrer TDE-Schlüssel ist die Skalierung nicht von Bedeutung. Die Anforderungsgröße und -häufigkeit sind so gering, dass Sie nicht skalieren müssen.
Sicherheit
Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.
Der wichtigste Sicherheitsaspekt besteht darin, sicherzustellen, dass Sie Ihren TDE-Wrapperschlüssel sicher aufbewahren und er für SQL Managed Instance immer verfügbar ist. Auf Datenbanken, die über TDE verschlüsselt sind, kann nicht zugegriffen werden, wenn sie nicht auf den erforderlichen Schlüssel in Key Vault zugreifen können. Wenn Sie dienstseitig verwaltete Schlüssel verwenden, müssen Sie sich keine Gedanken über diesen Aspekt machen.
Resilienz
Jede verwaltete SQL-Instanz ist für die Verwendung von zwei Schlüsseltresoren konfiguriert. Wenn der primäre TDE-Schlüssel der verwalteten SQL-Instanz nicht verfügbar ist oder darauf nicht zugegriffen werden kann, versucht die Instanz, einen Schlüssel mit einem übereinstimmenden Fingerabdruck im sekundären Schlüsseltresor zu finden.
Kostenoptimierung
Informationen zu den zusätzlichen Kosten für die Verwaltung Ihrer eigenen TDE-Schlüssel, abgesehen von den zusätzlichen Betriebskosten, finden Sie in den folgenden Ressourcen:
Informationen zu den optionalen Komponenten finden Sie in den folgenden Ressourcen:
Bereitstellen dieses Szenarios
Sie können dieses Szenario mithilfe der folgenden ARM-Vorlagen bereitstellen:
Beitragende
Dieser Artikel wird von Microsoft aktualisiert und gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautor:
- Ahmet Arsan | Senior Cloud Solution Architect
Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.
Nächste Schritte
- Verschlüsselung von Sicherungsdaten mit von Kunden verwalteten Schlüsseln
- Was ist Azure SQL Managed Instance?
- Grundlegende Konzepte von Azure Key Vault