Informationen zur Hochverfügbarkeit und Disaster-Recovery für Secrets Manager
HochverfügbarkeitDie Fähigkeit eines Dienstes oder einer Arbeitslast, Ausfällen standzuhalten und die Verarbeitungsfähigkeit gemäß einem vordefinierten Servicelevel weiterhin bereitzustellen. (HA) ist die Fähigkeit eines Dienstes, auch bei unerwarteten Ausfällen betriebsbereit und zugänglich zu bleiben. Unter Disaster RecoveryDie Fähigkeit eines Dienstes oder einer Arbeitslast, sich von seltenen, schwerwiegenden Vorfällen und großflächigen Ausfällen, wie z. B. Dienstunterbrechungen, zu erholen. Dies umfasst eine Naturkatastrophe, die eine ganze Region betrifft, die Beschädigung einer Datenbank oder den Verlust eines Dienstes, der zu einer Arbeitsbelastung beiträgt. Die Auswirkungen übersteigen die Fähigkeit des Hochverfügbarkeitsdesigns, sie zu bewältigen. versteht man die Wiederherstellung eines funktionierenden Zustands der Service-Instanz.
Secrets Manager ist ein regionaler Dienst, der die definierten Service Level Objectives(SLO ) mit dem Standardplan erfüllt. Weitere Informationen zu den verfügbaren IBM Cloud Regionen und Rechenzentren für Secrets Manager finden Sie unter Service- und Infrastrukturverfügbarkeit nach Standort.
Architektur für hohe Verfügbarkeit
Eine Secrets Manager Dienstinstanz wird in drei Zonen in einer Multizonenregion ohne Single Point of Failure bereitgestellt. API-Anfragen werden über einen globalen Load Balancer an drei HA-Instanzknoten weitergeleitet, die sich jeweils in einer anderen Verfügbarkeitszone befinden.
Wenn eine Verfügbarkeitszone ausfällt, läuft der Dienst weiter, wobei die API-Anforderungen über einen globalen Load Balancer an die überlebenden HA-Instanzknoten weitergeleitet werden. Zwischen dem Ausfall und dem Erkennen des Fehlers durch den globalen Load Balancer kann eine kurze Zeitspanne (Sekunden) liegen, in der Anfragen an die ausgefallene Instanz gesendet werden. Workloads, die programmatisch auf die Service-Instanz zugreifen, sollten der Wiederholungslogik für die Client-Verfügbarkeit folgen, um die Verfügbarkeit aufrechtzuerhalten. Bei einem zonalen Ausfall kommt es zu keiner spürbaren Beeinträchtigung des Dienstes.
{Die Instanzen IBM Cloud® Secrets Manager sind hochverfügbar und müssen nicht konfiguriert werden.
Architektur zur Wiederherstellung im Katastrophenfall
Zur Wiederherstellung nach einem Ausfall einer Service-Instanz sollte eine Recovery-Service-Instanz in einer Recovery-Region erstellt werden. Im Allgemeinen sollte die Wiederherstellungsdienstinstanz mit denselben Daten wie die Quelldienstinstanz konfiguriert werden, aber es gibt Ausnahmen von dieser Richtlinie.
Einige Geheimnisse müssen für die Wiederherstellungsregion angepasst werden, z. B. können Verbindungszeichenfolgen oder API-Schlüssel auf regionalspezifische Dienstinstanzen verweisen. Diese Werte werden in der Instanz des Wiederherstellungsdienstes unterschiedlich sein.
Die Secret Manager-Dienstinstanz kann vom Kunden erstellte Abhängigkeiten von diesen optionalen Diensten haben. Stellen Sie sicher, dass diese in der wiederhergestellten Region vorhanden sind.
Eine solche Instanz sollte im Vorfeld (vor einer möglichen Katastrophe) erstellt und mit der Quellinstanz synchronisiert werden.
Funktionen zur Wiederherstellung im Katastrophenfall
Secrets Manager unterstützt die folgenden Disaster-Recovery-Funktionen:
Planen Sie den Aufschwung in einer Aufschwungregion. The recovery instance should align with the workload konzepte für die Wiederherstellung im Katastrophenfall innerhalb von " IBM Cloud. Die Wiederherstellungsinstanz sollte Datenänderungen an der primären Serviceinstanz für Daten wie Gruppen, Geheimnisse, geheime Versionen, Zertifikate und Ereignisbenachrichtigungen verfolgen.
Wenn sich die Katastrophe nicht auf die Produktionsinstanz des Dienstes auswirkt, z. B. bei einer Datenbeschädigung, kann ein Kunde die Daten in der vorhandenen Serviceinstanz reparieren.
Der Dienst unterstützt die folgenden Wiederherstellungsoptionen:
| Feature | Beschreibung | Hinweis |
|---|---|---|
| Rotation | Vorherige geheime Version wiederherstellen | Die Produktionsdienstinstanz muss verfügbar sein. Es gibt eine begrenzte Anzahl von Versionen in der Versionsgeschichte. Siehe bekannte Probleme und Einschränkungen. |
Alle anderen Wiederherstellungsoptionen werden vom Kunden erstellt und unterstützt.
| Feature | Beschreibung | Hinweis |
|---|---|---|
| Externe Quelle der Wahrheit | Alle Geheimnisse werden über ein Skript erstellt, das weiter unten beschrieben wird. | Der Kunde muss das Skript erstellen und die Konfiguration dort aufbewahren, wo sie im Katastrophenfall verwendet werden kann |
| Sichern und Wiederherstellen | Sicherung einer Dienstinstanz mit einem vom Kunden geschriebenen Skript. | Der Kunde muss das Skript erstellen und die Sicherungskopie dort aufbewahren, wo sie während der Wiederherstellung verwendet werden kann |
| Live-Synchronisierung | Geheime Änderungen in der Produktion werden automatisch beobachtet und an die wiederherzustellende Serviceinstanz weitergegeben, siehe Beschreibung unten | Der Kunde muss Werkzeuge erstellen und pflegen. Beschädigte Daten werden mit der Wiederherstellungsinstanz synchronisiert. |
Merkmal Rotation
Secret Manager-Geheimnisse werden im Allgemeinen durch "Rotation" aktualisiert, wobei das Schreiben eines Wertes zur Erstellung einer neuen Version des Geheimnisses führt. Es kann möglich sein, beschädigte Daten wiederherzustellen, indem Geheimnisse aus älteren Versionen in der Produktionsinstanz wiederhergestellt werden. Es wird nur eine bestimmte Anzahl von Versionen beibehalten. Siehe Verwaltung geheimer Versionen.
Externe Wahrheitsquelle - vom Kunden bereitgestelltes Merkmal
Der Kunde muss eine Kombination aus Terraform, Skript oder Programm als Quelle der Wahrheit erstellen und verwenden. Aktualisieren Sie zunächst die Wahrheitsquelle und verwenden Sie dann die Wahrheitsquelle, um die primäre Serviceinstanz und die Wiederherstellungsdienstinstanz zu erstellen/zu aktualisieren. Die Quelle muss für die Wiederherstellungsversion zur Verfügung stehen und ist ein Single Point of Failure.
Wenn ein Kunde eine Katastrophe in der primären Instanz meldet, wird der Dienst in der Wiederherstellungsregion genutzt (minimaler Betrieb) oder der neue Dienst erstellt (Zero Footprint). Leiten Sie Ihre Workload-Komponenten auf die wiederhergestellte Instanz um oder fügen Sie optional in den Wiederholungscode innerhalb Ihrer Anwendung ein, um Anfragen auf die zweite Instanz umzuleiten (Minimaloperation).
Das Repository, das die Quelle der Wahrheit enthält, sollte über eine zeitpunktgenaue Wiederherstellung verfügen, z. B. Object Storage Buckets mit Versionierung oder Github-Repositories.
Sicherung und Wiederherstellung der vom Kunden bereitgestellten Funktion
Wenn Sie Ihre geheimen Schlüssel regionsübergreifend manuell sichern möchten, benötigen Sie zunächst eine Instanz von Secrets Manager in einer anderen Region. Führen Sie anschließend die folgenden Schritte aus, um die regionsübergreifende Verfügbarkeit sicherzustellen.
Sie können geheime Schlüssel über die Secrets Manager -API oder die Befehlszeilenschnittstelle aus Ihrer Instanz auflisten und herunterladen.
Wenn Sie in Ihrer Instanz bereits Konfigurationen für Secrets-Engines haben, können Sie die Informationen auch programmatisch abrufen, damit sie in einer neuen Instanz neu erstellt werden können. Weitere Informationen finden Sie unter Abrufen der Konfiguration eines Geheimnistyps API.
Fügen Sie Ihre heruntergeladenen geheimen Schlüssel zur neu erstellten Instanz hinzu.
Sie können eine automatische Sicherung Ihrer geheimen Schlüssel erstellen, indem Sie den manuellen Ablauf automatisieren. Dies kann auf verschiedene Arten erfolgen. Schauen Sie sich die folgenden Beispiele an, um herauszufinden, ob eines davon für Sie in Frage kommt.
Live-Synchronisation - eine vom Kunden bereitgestellte Funktion
Der Kunde kann ein Skript oder Programm erstellen, um mithilfe der Secrets Manager-API Geheimnisse von Ihrer primären Service-Instanz herunterzuladen oder die Wiederherstellungs-Service-Instanz mit den Daten zu füllen. Das Skript kann die Prüfereignisse von IBM Cloud Logs der primären Instanz nutzen, um die Wiederherstellungsinstanz mit Code Engine synchron zu halten. Vom Kunden verwaltete Sicherungskopien sollten aufbewahrt werden, um nach einer Katastrophe wiederhergestellt werden zu können.
Erstellen Sie ein Skript, das in regelmäßigen Abständen Ihre Geheimnisse herunterlädt und sie dann in Ihre Sicherungsinstanz importiert.
Erstellen Sie ein Ziel und ein Abonnement in Event Notifications, das auf eine IBM Cloud Code Engine Aktion verweist. Konfigurieren Sie die Aktion so, dass sie auf Lebenszyklusereignisse wie secret_created und secret_rotated wartet. Wenn die Aktion dann das Ereignis empfängt, lädt sie den geheimen Schlüssel von einer Instanz herunter und fügt ihn der Sicherungsinstanz hinzu.
Secrets Manager unterstützt Benachrichtigungen für die verschiedenen Arten von Geheimnissen, die es bietet. Informationen zu den verschiedenen verfügbaren Lebenszyklusereignistypen finden Sie unter Ereignisbenachrichtigungen aktivieren.
Disaster-Recovery planen
Die Wiederherstellungsmaßnahmen müssen regelmäßig geübt werden. Berücksichtigen Sie bei der Erstellung Ihres Plans die folgenden Fehlerszenarien und Lösungen.
| Fehler | Lösung |
|---|---|
| Hardware-Ausfall (einzelner Punkt) | IBM stellt eine Instanz zur Verfügung, die gegen einen einzelnen Hardwareausfall innerhalb einer Zone gefeit ist - keine Konfiguration erforderlich. |
| Zonenfehler | IBM stellt eine Instanz zur Verfügung, die auch bei einem Zonenausfall ausfallsicher ist - eine Konfiguration ist nicht erforderlich. |
| Datenbeschädigung | Verwenden Sie die Rotation, um die vorherige geheime Version in einer verfügbaren Dienstinstanz wiederherzustellen. |
| Datenbeschädigung | Wiederherstellung einer nicht beschädigten Version zu einem bestimmten Zeitpunkt aus der externen Quelle der Wahrheit oder der Sicherung und Wiederherstellung. |
| Regionales Versagen | Wechseln Sie kritische Workloads zur Verwendung der wiederhergestellten Version in einer Wiederherstellungsregion. Wiederherstellung der Instanz mit Hilfe einer externen Wahrheitsquelle, Sicherung und Wiederherstellung oder Live-Synchronisation. |
Ihre Verantwortlichkeiten für HA und DR
Die folgende Checkliste für jedes Merkmal kann Ihnen bei der Erstellung und Umsetzung Ihres Plans helfen.
- Rotation
- Erstellen Sie eine Testressourceninstanz und üben Sie das Rotieren von Geheimversionen und die Wiederherstellung einer Geheimversion.
- Externe Quelle der Wahrheit
- Stellen Sie sicher, dass sich die Quelle der Wahrheit in einem Repository befindet, das am Wiederherstellungsort verfügbar ist.
- Vergewissern Sie sich, dass die Quelle der Wahrheit nicht von der Katastrophenregion abhängig ist, um eine Abhängigkeit von einer ausgefallenen Region zu vermeiden.
- Sichern und Wiederherstellen
- Stellen Sie sicher, dass sich die Sicherung in einem Repository befindet, das am Wiederherstellungsort verfügbar ist.
- Überprüfen Sie, ob das vom Kunden geschriebene Skript zur Wiederherstellung der Daten in der Wiederherstellungsregion verfügbar ist.
- Stellen Sie sicher, dass das Skript und die Sicherung nicht von der Katastrophenregion abhängig sind, um eine Abhängigkeit von einer ausgefallenen Region zu vermeiden. Betrachten Sie einen Object Storage überregionalen Eimer.
- Live-Syncrhonisation
- Überprüfen Sie, ob die Wiederherstellungsdienstinstanz in der Wiederherstellungsregion aktuell verfügbar ist
- Sowohl für die externe Quelle der Wahrheit als auch für die Live-Synchronisation:
- Überprüfen Sie, ob die Wiederherstellungs-Workloads in der Wiederherstellungsregion in die Wiederherstellungsdienstinstanz integriert sind
- Überprüfen Sie, ob regionalspezifische Geheimnisse in der Wiederherstellungsdienstinstanz verfügbar sind.
Um mehr über die Verantwortlichkeiten zwischen dem Kunden und IBM Cloud bei der Nutzung von Secrets Manager zu erfahren, lesen Sie bitte den Abschnitt Über Ihre Verantwortlichkeiten bei der Nutzung von Secrets Manager.
Die Schritte zur Wiederherstellung im Katastrophenfall müssen regelmäßig geübt werden. Berücksichtigen Sie bei der Erstellung Ihres Plans die folgenden Fehlerszenarien und Lösungen.
Kundenerholung bei BYOK-Verlust
Wenn Ihre Serviceinstanz unter Verwendung des Root-Schlüssels von IBM® Key Protect for IBM Cloud® oder Hyper Protect Crypto Services bereitgestellt wurde und Sie den Root-Schlüssel versehentlich gelöscht haben, öffnen Sie einen Supportfall für den Dienst und fügen Sie die folgenden Informationen bei:
- Die CRN Ihrer Dienstinstanz
- Die CRN Ihrer Key Protect oder HPCS-Instanz
- Die neue Key Protect oder HPCS-Root-Key-ID
- Die ursprüngliche CRN der Key Protect oder HPCS-Instanz und die Schlüssel-ID, falls verfügbar
Siehe Wiederherstellung nach einem versehentlichen Schlüsselverlust für die Autorisierung in den Key Protect und HPCS-Dokumenten.
Wiederherstellungszeit-Ziel (RTO) und Wiederherstellungspunkt-Ziel (RPO)
| Feature | RTO und RPO |
|---|---|
| Vorherige geheime Version wiederherstellen | RTO = Minuten, Übung und möglicherweise Skripting werden die RTO-Zeiten verbessern, RPO = 0. |
| Externe Quelle der Wahrheit - kein Fußabdruck | RTO = wenige Minuten. Zeitaufwand für die Bereitstellung und Befüllung mit Daten. Berücksichtigen Sie auch die Zeit, die für die Anpassung der wiederhergestellten Arbeitslasten an den neuen Endpunkt der Service-Instanz benötigt wird. RPO = 0, wird die Quelle der Wahrheit geändert, bevor Produktionsänderungen vorgenommen werden. |
| Externe Quelle der Wahrheit - voll funktionsfähiges Backup | RTO = wenige Sekunden, RPO = 0. Erweitern Sie die Zero-Footprint-Beschreibung, um eine Live-Service-Instanz in der Wiederherstellungsregion zu behalten. |
| Sichern und Wiederherstellen | RTO = wenige Minuten. Zeitaufwand für die Bereitstellung und Befüllung mit Daten. Berücksichtigen Sie auch die Zeit, die für die Anpassung der wiederhergestellten Arbeitslasten an den neuen Endpunkt der Service-Instanz benötigt wird. RPO = Zeitpunkt der letzten Sicherung. |
| Live-Synchronisierung | RTO = Minuten, RPO = Minuten bei ereignisgesteuerten Sicherungen oder der Zeitraum, z. B. täglich, bei periodischen Sicherungen. |
Bei der Erstellung einer neuen Serviceinstanz umfasst die RTO der Arbeitslast unter Verwendung von Secrets Manager die Zeit, die erforderlich ist, um wiederhergestellte Arbeitslasten an den Endpunkt der neuen Serviceinstanz anzupassen.
Änderungsmanagement
Die Änderungsverwaltung umfasst Aufgaben wie Upgrades, Konfigurationsänderungen und Löschungen.
Es wird empfohlen, Benutzern und Prozessen die IAM-Rollen und -Aktionen mit den geringsten für ihre Arbeit erforderlichen Berechtigungen zu gewähren.
Schränken Sie zum Beispiel die Möglichkeit ein, Produktionsressourcen zu löschen.
Wie IBM® die Wiederherstellung im Katastrophenfall unterstützt
{{{site.data.keyword.IBM}} ergreift im Falle einer Katastrophe spezifische Wiederherstellungsmaßnahmen.
Wie IBM® sich von Zonenausfällen erholt
Im Falle eines Zonenausfalls behebt IBM Cloud den Ausfall der Zone. Sobald die Zone wieder online ist, sendet der globale Load Balancer wieder API-Anfragen an den wiederhergestellten Instanzknoten, ohne dass der Kunde eingreifen muss.
Wie IBM® sich von regionalen Ausfällen erholt
Wenn eine Region nach einem Ausfall wiederhergestellt wird, versucht IBM, die Service-Instanz aus dem regionalen Zustand heraus wiederherzustellen, was zu keinem Datenverlust führt und die Service-Instanz mit denselben Verbindungsstrings wiederherstellt.
- RTO = wenige Minuten
- RPO = 0 Minuten
Wenn der regionale Status beschädigt ist, wird der Dienst auf dem Stand der letzten internen Sicherung wiederhergestellt. Alle mit dem Dienst verbundenen Daten werden einmal täglich vom Dienst in einem vom Dienst verwalteten regionsübergreifenden Cloud Object Storage Bucket gesichert. Es besteht die Gefahr eines Datenverlustes im Wert von 24 Stunden. Diese Backups sind nicht für die vom Kunden verwaltete Notfallwiederherstellung verfügbar. Wenn ein Dienst aus Backups wiederhergestellt wird, wird auch die Instanz-ID wiederhergestellt, so dass Clients, die den Endpunkt verwenden, nicht mit neuen Verbindungszeichenfolgen aktualisiert werden müssen.
- RTO = 2 Stunden
- RPO = maximal 24 Stunden
Falls IBM die Service-Instanz nicht wiederherstellen kann, muss der Kunde die Wiederherstellung wie im Abschnitt Disaster Recovery beschrieben durchführen.
Wie IBM® Dienste unterhält
Alle Upgrades folgen den IBM® Service Best Practices und verfügen über einen Wiederherstellungsplan und einen Rollback-Prozess. Regelmäßige Upgrades für neue Funktionen und Wartungsarbeiten sind Teil des normalen Betriebs. Solche Wartungsarbeiten können gelegentlich zu kurzen Unterbrechungen führen, die von der Wiederholungslogik für die Client-Verfügbarkeit behandelt werden. Die Änderungen werden schrittweise eingeführt, Region für Region und Zone für Zone innerhalb einer Region. Aktualisierungen werden beim ersten Anzeichen eines Fehlers zurückgenommen.
Komplexe Änderungen werden mit Funktionskennzeichen aktiviert und deaktiviert, um die Exposition zu steuern.
Änderungen, die sich auf die Arbeitsbelastung der Kunden auswirken, werden in Benachrichtigungen detailliert aufgeführt. Weitere Informationen finden Sie unter Benachrichtigungen und Statusüberwachung für geplante Wartungsarbeiten, Ankündigungen und Versionshinweise, die sich auf diesen Dienst auswirken.